Present: hoijui, jK, Kloot, Tobi
=== Agenda ===
Release plan
Version numbering
big re-factor
Next meeting
Main Conclusions:
* path-follower seems to work fine
* odd mayor version numbers will be used to test releases, eg 0.83.X.Y will all the RCs for 0.84
* Tobi will eventually make a web-app for querying the new stack-trace translator
=== Release plan ===
Tobi: as I wrote in the release post, plan is to put last RC live on thursday, unless major bugs have been found
Tobi: any such bugs found, or fixes after the rc that should also be in release?
Kloot: yeah
hoijui: hey
Kloot: the recent objparser fixes
jk: IMO the healthbars thingy shouldn't be in the release
hoijui: i get no healthbars in BA 7.14 now
Kloot: oh right that
Kloot: I had already assumed that would not be included in the release
Tobi: I can cherrypick if master is already in `post release' state :)
hoijui: i see about 4 commits that should be in still
hoijui: ah and jk.. your changes with X window state saving.. dont work well here :/
hoijui: have to do further testing, btu sometimes it saves only the width, and keeps the height at full-screen
jk: how doesn't it? I tested it myself and it worked fine
hoijui: hmm.. maybe that is not solvable...
hoijui: i usually have it at 800x600
jk: it doesn't save the width & height at all
hoijui: then sometimes make it maximized
hoijui: ok..
jk: that was before too
jk: I wondered a bit too
jk: but was too lazy to reoarganize that
hoijui: when starting next game, and de-maximizing, it is at 800x<full>
hoijui: ok
hoijui: path-finder seems to be fine now
hoijui: *follower
Tobi: I've included these now:
Tobi: d84a15 * OBJParser: fix misinterpretation of the OBJ spec
Tobi: 41667fc * second fix; attributes can be shared
Tobi: 6e9b783 * OBJParser: fix incorrect handling of negative references
Tobi: 370a973 get rid of two warnings [minor]
Tobi: f739eea fix compile error [fix]
Tobi: 8dc5ba8 E323AI: reference latest version (version bump) [AI]
Tobi: 6ff2852 add missing OS X include [fix]
Tobi: b726c43 * forgot to setup the DrawFeature event
Tobi: f631958 * ASSERT_SYNCED_PRIMITIVE is not defined for const types (#2022)
Tobi: e44e8db make boost::asio::ip::address::from_string sync safe on win2k
Tobi: c6e73e9 fix for source package compile [fix]
Tobi: 939a9ad fix a CppCheck warning
Tobi: 65a24df fix invalid FPU flags after boost::asio::ip::address::from_string in Connection::Connection (LuaLobby) with precompiled boost libs from mingwlibs git repo
Tobi: 009e8e4 fix lineending
Tobi: c19f0b0 who needs an editor when you have awk
Kloot: hoijui: glad to hear that
hoijui:
Tobi: I left out the X11 changes since that seems quite a big risky change (lots of fixes on the initial commit also)
jk: the X11 isn't risjy
Tobi: same for healthbars + that requires mod changes ofc
hoijui: looks good
jk: those following commits were just because I couldn't find the needed X11 headers
jk: also the DrawFeature fix should be in too
Tobi: [16:13:38] Tobi: b726c43 * forgot to setup the DrawFeature event <- this ?
jk: ah nvm
Tobi: is that X11 stuff really required/important for this release?
jk: else the spring window shifts with each start
jk: and a lot ppl say they don't use fullscreen mode under linux
jk: so it affects a lot ppl
Tobi: yeah I don't use full screen either
Tobi: never noticed window shifts every start tho
jk: Gnome or KDE?
Tobi: KDE
jk: here it does with KDE4
hoijui: same here
hoijui: KDE, no shifts noticed
hoijui: shift*
Tobi: didn't say it doesn't happen, just never noticed
Tobi: maybe I don't care enough about that
hoijui: same
Tobi: anyway I'll cherrypick them in then
Tobi: anything else wrt release plan?
hoijui: maybe we should link spring-headless and dedicated to SDL again, under OS X, as they still do not compile as it is now..
hoijui: and.. i do not care a lot for them being totally headless on OS X really
hoijui: problem seems to be, that it always links to a lib that is SDL dependent anyway (cocoa, i think)
Tobi: seems fine to me
hoijui: ok
hoijui: will do that then
Tobi: ok
Conclusions:
* health bars handled by Lua commit will not be in release
* path-follower seems to work fine
* hoijui should fix OS X linking of DS and HL
=== Version numbering ===
Tobi: once again I like to bring up this point, because I think it wasn't really handled yet a few weeks ago. I propose that (like e.g. Linux) we use odd version numbers for unstable/testing/rc builds and even numbers for stable
Tobi: so after this 0.82 we could make a lot of test builds / RCs for 0.84 using 0.83.X.Y
Tobi: anyone against or any details I'm missing that will make this not work?
Kloot: what is/are the main advantage(s) of that convention?
Kloot: besides decreasing rate at which version number increase
hoijui: it would have more benefits if we had proper multi-version support
Tobi: mostly we get full releases at a nice .0.0 number
hoijui: i mean.. by lobby servers and clients.. so people could have current stable and latest test version setup simultaneously in their lobby
hoijui: then it would help identifying test/stable games
jk: I still prefer to use RC post-fix than hidden informations in the version number itself
Kloot: I do not see how ensuring even==stable and odd==test facilitates multi-version support for lobbies
hoijui: is ok for me
Kloot: that is just some silly server limitation
hoijui: it does not faciliate this, but when we have this, it does faciliate identifying which games are stable and which RC
hoijui: as long as versions are only numbers
Kloot: but who or what would need the help in identifying stable/test games?
hoijui: the users
jk: the server limitation was because new spring versions were delivered/downloaded via TASClient ages ago
jk: but we don't use that system anymore so this `feature` can be removed
Kloot: no, lobbies could just filter out games for engine versions that did not match the user's
jk: that's now
hoijui: :D
Tobi: I wasn't intending to enforce anything technical using these change btw
Kloot: so again why would users need help if lobbies take care of not letting them join game for other versions?
hoijui: aehm..
Tobi: just prefer to have a range of numbers available for making more official (than nightlies) test builds and release candidates
hoijui: i said.. when we would have propper multi version support
jk: it doesn't help the user when he must now that odd numbers are test build and even numbers are releases
hoijui: if it was easy for a user to auto get latest RC
jk: *know
Tobi: it helps way more already than if it's essentially random for every version number
hoijui: it is better then now, worse the nif there was an RC prefix
hoijui: ..exactly
jk: just 1% of the users would knwo such stuff
Tobi: prefixes and suffixes often have issues when you want to sort by them in code
hoijui: and ther is really only the "downside" of having the version increase faster, which.. i cant see as an issue
hoijui: lobbies coudl use that, to color odd number games differently
Kloot: well to be clear, I don't care either way unless there are definite programmatic advantages of one scheme over the other
hoijui: and .. users willign to run test games, sure would nto have much problem to learn that
Tobi: pre/suffix requires changes in buildbot, stacktrace translator, and maybe in Zydox' bug collecter
Tobi: (trying to) use odd/even consistently requires no changes anywhere
jk: btw how does the stacktrace translator work with the new buildbot?
Tobi: it has it's own, that is integrated into Zydox' bug collecter
hoijui: i have a small java app to query it.
Tobi: or, http://springrts.com:8000/
hoijui: btw.. as SL seems to crash for many/all users on windows, when it tries to send a bug report, they will/did disable that :/
Tobi: if there is demand I suppose I can add a simple web interface too at some point
hoijui: so yeah.. i guess that is needed, some app or web page to directly translate
Tobi: k I'll add one web form
hoijui:
jk: thx :)
hoijui: related to version: github decided to not full-fill my request
hoijui: http://support.github.com/discussions/f ... iving-hook
Tobi: so odd/even is ok as simple `fix' to make it clearer what are test builds and what are real releases?
Tobi: +to actually support making test builds with a decent version number
hoijui: +1
jk: -0.5
Kloot: +0.75
Tobi: <_<
hoijui: .. this means, if we rely fully on git-tags for the version, there will be a problem when downloading source as package from github
hoijui: (can that be disabled?)
hoijui: :D
hoijui: checking..
hoijui: not possible, will do an other request
Tobi: ok
Tobi: jk: you're only against because there is a better way that takes more effort, right, not because the suggested way is wrong by itself?
jk: that + the user won't know that odd/even number scheme, so it won't give an advantage imo
hoijui: next?
Conclusions:
* odd mayor version numbers will be used to test releases, eg 0.83.X.Y will all the RCs for 0.84
* Tobi will eventually make a web-app for querying the new stack-trace translator
* github will not allow pre-processing of source package downloads
related: as we know by now (13.08.2010), github will neither allow disabling source package downloads
=== big re-factor (see "New Structure" etherpad) ? ===
Kloot: glhf whoever picks up that tab ^^
jk: Why new eventlistener system?
jk: trepan's eventhandler works fine
hoijui: it is mainly meant for new events
jk: also your's is much slower (empty virtual funcs)
jk: so if an eventclient uses just uses one event all others are called too but redirected to an empty virtual func -> slow
hoijui: how deos current work?
jk: it creates arrays for each event and just call the eventclients which want this event
jk: *for each event an array
jk: +s
Tobi: where is this new event system described / mentioned?
Tobi: oh nm
hoijui: is ther ereally a difference? i mean... cause of the virtual
jk: yeah
hoijui: both systems use virtual
Tobi: no significant difference in what is in the ehterpad page
jk: spring already has a performance problem with virtual functions in MoveData and other synced code
Tobi: only a func to query what evens the class is interested in makes it the same, performance wise, as the current code
hoijui: does it check which function to call each time you call it?
hoijui: you only register for events you are interested in
hoijui: or say..
hoijui: when you are interested in unti creation, you will also be interested in unit death
Tobi: the nice thing about this is actually that *without* such registering (which is duplication of information => bad) this design has way less performance impact than huge-monolithic-event-system design
hoijui: if there is no strong connection, then the events would not be in the same listener class
Tobi: because events are split per type in small interfaces
hoijui: without registering -> how works?
hoijui: send events to all classes that implement the interface?
Tobi: yes
hoijui: ok
Tobi: that is what I assume jK assumes the event sender code would do in your example
hoijui: that works, if ther is only one place that sends the events
Tobi: you will have one class that manages them, right?
hoijui: UnitLiveState change events would be managed by one class only i guess, inside the engine
hoijui: but .. well no
hoijui: imagine:
hoijui: there is the unit handler, which sends out UnitLiveState events
hoijui: then you have filters for these events, eg for AIs
hoijui: which filter out events that are not in LOS
hoijui: the engine internal AI instance handler would then only receive part of the UnitLiveState events, and therefore .. there would not be a single UnitLiveState event handler
Tobi: right, didn't know you wanted to add filters too
hoijui: maybe there is a way to use both..
hoijui: eg, the listener auto-registers on the default handler, and it can be changed later on
Tobi: well as I see it there will still be a single class that *initially* dispatches the events
hoijui: .not very nice though but..
hoijui: yes true
hoijui: then agian... maybe this is not true for all events
hoijui: event-types*
Tobi: then on that class some filtering handler+dispatcher (at same time) could listen for events, and only re-dispatch an event if it matches the predicate
hoijui: so you would register a listener together with an event-filter?
hoijui: dont get it
Tobi: hmm, I really need an uml or inkscape etherpad I guess :)
hoijui: :D
hoijui: yeah, would be nice
hoijui: what i meant: in the interface constructor, we register to the main event manager
jk: and still it is much slower than trepan's system
hoijui: then we have an other ctor in the event-listener interface, which takes an argument, which can be NULL or an other event manager
hoijui: but.. he also uses virtual function
jk: also the current one could even simplified with helper classes
Tobi: jk: why?
hoijui: yeah why
jk: becuase it would call empty events
Tobi: one empty function call per unit creation/destroy event
Tobi: thats _nothing_ compared to the amount of vfunc calls in e.g. pathfinder/MoveData
jk: one function call for each unitdamage, heightmap update, ...
Tobi: no
hoijui: it would also do this very seldomly, as i explained before
Tobi: because it's split up in small interfaces
hoijui: as there would practically be no empty functions
hoijui: yep
Tobi: this overhead that you think there is would only be for UnitCreated vs UnitDestroyed, for example
Tobi: but not for UnitCreated vs UnitDamaged
jk: then it would split up in 20 different event handlers
jk: -> spaghetti code
hoijui: .... no
hoijui: it is spegetti code now
jk: no, atm it is everything is managed at one place
hoijui: it is totally bad to have all events in one class.. never seen that been used anywhere else.. only makes sense in C possible
jk: and just one function is called for all events
hoijui: yeah.. everythign.. even if it has no relation to each other
Tobi: the nice thing is even that if _after measurements_ it appears these empty vfuncs are eating all CPU, the interfaces can be made finer grained easily (by splitting up one)
hoijui: mmm
jk: ?
Tobi: even if the events are in multiple interfaces it is a separate choice whether the event dispatcher is implemented as one class or several classes
jk: the current system doesn't need such a maintenance at all
jk: also finding vfunc performance issues isn't easy at all because they aren't shown in the gprof
jk: -the
hoijui: i start to believe yo udo not know how my system is meant to work
jk: I do very well
hoijui: as we explained, there are practically no empty functions called
hoijui: the current system also uses virtual functions
hoijui: so...
jk: you want multiple small eventhandlers which integrate 3-6 events and then other classes can include those and automatically receive those events
hoijui: why you start coming up with that again and again?
hoijui: no
hoijui: thats wrong
jk: the current system filter out EMPTY vfuncs
hoijui: it is about small event listener interfaces
hoijui: not event handlers (as in, senders)
jk: eventhandler isn't a sender ...
hoijui: mm ok
hoijui: :D
Tobi: the current system has the disadvantage that you need to specify in two ways that you want to listen for an event, by registering your class and by telling it which methods you want to listen to (right?)
jk: yeah, but that can be simplified if really needed
Tobi: design wise I prefer hoijui's proposed solution (or rather, how I perceive it), although the current solution has the advantage that it exists already
hoijui: can you tell me where to look at, how it is done now? (where it specifies which events to get
hoijui: :D
Tobi: in any case it would be good if everywhere where there are 2 calls to 2 different event dispatchers it is made into 1 call to 1 dispatcher
jk: System/EventClient & System/EventHandler
jk: atm if you want to call an event you always know how to call it: eventHandler->MyEvent(foobar)
jk: with such small eventhandler you always had to check the eventhandlers name first
jk: +s
jk: +'
Tobi: Tobi: even if the events are in multiple interfaces it is a separate choice whether the event dispatcher is implemented as one class or several classes
Tobi: so there could be one dispatcher, while still not needing to inherit from a class with 80 methods just to implement something that happens when a unit is created
Tobi: at least that's what I understood hoijui suggests
hoijui: yeah.. you cant do modularization/separation of the parts of the engine (which should be one of our goals), and keep everything in one place
jk: how does that differ from making abstract classes with the current system, which can be used via multiple inheritance?
hoijui: i dont suggest the central dispatcher (even doh it is easily possible, as Tobi said)
hoijui: ??
hoijui: that is my system, not the current system
Tobi: it doesn't differ, that is exactly (one part) of the suggestion
hoijui: for unitlisestate events eg, only the unit handler should ever dispatch them, no?
hoijui: everythign else would be cheese somehow
Tobi: to clarify how I use the terms, dispatcher: current EventHandler, the thing that has a method UnitCreated and calls a list of methods of all event listeners
Tobi: I don't think unit handler itself should have this event dispatching code, that should be responsibility of a different class
hoijui: one common for all events?
hoijui: i can not see a way how to do that nicely
jk: btw how would such system interact with lua?
Tobi: not all, I think I would take one per module, sort of, i.e. one for all sim events, one for system events (if we get/have any), etc.
hoijui: the unit handler handles units, alsoe their death, and it should inform others about that
jk: lua decides dynamically if it wants a event, with such static eventhandlers this isn't possible
jk: so it would get all events w/o using most of them
hoijui: register/deregister?
jk: lol then you get what we have atm ...
hoijui: no
jk: sure
hoijui: in my system, you register a listener instance
Tobi: you get a lot of special case code there though
hoijui: not an event method
jk: you would get an even larger if-clause function
jk: something like in game.cpp
hoijui: ??
hoijui: no
Tobi: if (globals table has "UnitCreated" symbol or globals table has "UnitDestroyed" symbol or ...) { eventHandler->RegisterUnitLifeStateListener(this); } etc.
hoijui: ah
jk: because you would check for the eventname and then get the corresponding eventhandler and then check if there are other events which are shared with this one
hoijui: map.add("liveState", {"UnitCreated", "UnitDestroyed", ...})
hoijui: then check with that
Tobi: how do you know where/how to register if you have a function of the category "liveState" ?
jk: you would need to create bi-directional maps and current linked status maps
hoijui: no wait.. not getting it... the way you describe it.. iw ould not wokr with current system
Tobi: hoijui: have you seen WantsEvent functionality?
jk: this doesn't sound any better than the current code
hoijui: the C++ part that receives the events, to redirect to Lua
Tobi: WantsEvent and HasCallIn specifically
hoijui: no
Tobi: for C++ code, design wise what hoijui suggests is clearly better imo, but indeed it doesn't seem to map easily onto current Lua design
hoijui: the C++ part receives all events, adn then desiced which to redirect to which widgets, right?
hoijui: decides*
Tobi: the point is that the C++ part should not decide this every time an event is received, but only once when it is created
Tobi: I gtg eat dinner though
hoijui: bye then
jk: yeah, that could be simplified
hoijui: only once, hwen a Lua thing is loaded?
jk: still I don't see a reason to drop the current system
hoijui: my proposal was meant for the refactor, to be used for new events
hoijui: mainly
jk: UnitCreated is new?
hoijui: to rework the olds stuff will possibly happen over time
jk: also having two system next each other isn't better at all
hoijui: ok then we should change current first
hoijui: before it gets even bigger
jk: the problem isn't its size
hoijui: cause it is really bad for splitting things up
jk: the problem is HOW eventclients register their events
hoijui: it combines stuff that is not related
hoijui: which makes it harder to splitt of stuff
jk: why split at all??
hoijui: and events are one of the primary techniques to split up stuff
jk: the events are separated
hoijui: separate functions in one class
hoijui: i kind of feel like.....
hoijui: as if i was trying to explain OpenGL to you
hoijui: i know how high level design is done
hoijui: that is one of my strengths
hoijui: and you always come with very low level arguments, which in the end, are always solvable somehow
hoijui: and if not, usually still worth the sacrifice
jk: you just don't want to see the problems, nor do you know how the current system works ...
jk: so you can't know the problems with the current system
jk: so you just want to create something new with to improve existing things
hoijui: which does not* ?
jk: *with out
hoijui: ahh k
hoijui: my design does improve
hoijui: not in the very low level view, but in a bigger one
hoijui: higher*
hoijui: which for you seems irrelevant
jk: no, but your way of doing it creates new problems
hoijui: the one with Lua?
jk: also your pro-arguments for such a system can be easily integrated in th current system
hoijui: have to look at that...
hoijui: if i look at LuaHandle.cpp
hoijui: and there at eg...
hoijui: CLuaHandle::TeamChanged
hoijui: where is this code that would require the many else if's?
jk: WantsEvent
hoijui: each wdget/gadget has its own handle?
jk: each lua instance
jk: widgets and gadgets are objects created by the widgetHandler/gadgetHandler -> unknow to the engine
hoijui: and what does that mean? :D how many are there?
hoijui: ah k
jk: LuaUI, LuaRules (synced), LuaRules (unsynced), LuaGaia (synced), LuaGaia (unsynced), ...
hoijui: ok
hoijui: brain stopped working, also need food
jk: me too :)
hoijui: :D
Tobi: I suppose this can be discussed further on later
Conclusions:
* should have a look at how to make hoijui's event system work with Engine -> Lua events (see WantsEvent)
=== Next meeting ===
Tobi: I don't know if I can be there next week, have 2 conflicting RL plans already, depending on which one I pick I may have a bit of time for the meeting
