<[RoX]Tobi> I assume zerver and daftalx (who's been invited for the OS X stuff) will join later
<[RoX]Tobi> lets start then
== Review meeting minutes past meeting ==
<[RoX]Tobi> any comments?
<[RoX]Tobi> ok, no comments
<[CoW]Kloot> hmm didn't we agree that point could be removed last meeting?
<[RoX]Tobi> that was the other point, about etherpad
<[RoX]Tobi> but I guess this doesn't add really much either
<[CoW]Kloot> ah right
<[RoX]Tobi> shall we remove it next time?
<[LCC]jK> +1
<zerver> perhaps better to make a new point on the agenda if someone wants to discuss something from last meeting
<[ARP]hoijui_g5> yeah, remove next time
<[RoX]Tobi> ok
<[ARP]hoijui_g5> yeah that
Conclusion:
* We don't review last meetings minutes, point has been removed from the agenda
== Progress of stuff to be done before release ==
first subpoint: ===Do not flush output in sim thread (patch by SirMaverick)===
<[LCC]jK> zero here
<[RoX]Tobi> zero progress or zero work to be done?
<[LCC]jK> zero work to be done
<[RoX]Tobi> ok, great
<[ARP]hoijui_g5> Kloot had a look at that patch
<[ARP]hoijui_g5> if i remember right, it should not be used
<[ARP]hoijui_g5> just flush should be removed
<[ARP]hoijui_g5> ?
<[RoX]Tobi> I had a look too, I put some comments in the commit on github before I even noticed the mantis report
<zerver> output is buffered anyway, so if we just dont force flush...
<[ARP]hoijui_g5> mm
<[RoX]Tobi> yeah IMO the correct 'solution' is not flushing, as it's way easier as a thread to flush
<[LCC]jK> isn't it possible to flush in the crashhandler?
<[CoW]Kloot> I read through the patch but didn't consider the buffered aspect until I noticed the discussion
<[RoX]Tobi> and with both solutions it isn't guaranteed anyway everything appears on disk on a crash that bypasses crash handler in some way
<[RoX]Tobi> which is the entire point of the flush
<[RoX]Tobi> [LCC]jK: no need to flush there when it could just close the file cleanly
<[LCC]jK> k
<zerver> if process crashes, are not all steams auto flushed?
<[RoX]Tobi> (which it already does, I think)
<[RoX]Tobi> not that I know
<[ARP]hoijui_g5> yeah, Linux crash handler already does close logOutput
<[RoX]Tobi> probably OS level buffers are, but buffers in memory (i.e. in libc functions) aren't
<zerver> ah
<[ARP]hoijui_g5> would the best solution not be, to limit logging to a usefull level?
<[ARP]hoijui_g5> and keep it as it is?
<[RoX]Tobi> nah, I think just not flushing is ok atm
<[RoX]Tobi> crash handler seems to work most of the time, right?
<[ARP]hoijui_g5> ok
<[LCC]jK> hmmm only endless loops may bypass the crashhandler
<[ARP]hoijui_g5> yes
<[RoX]Tobi> shouldn't the hang detection trigger then?
<[RoX]Tobi> or is that only compiled in in MT builds?
<zerver> only enabled in mt
<zerver> but compiled always
<zerver> should this be changed?
<[ARP]hoijui_g5> default enabled in MT? but cna be enabled through config in normal build?
<zerver> yes
<[ARP]hoijui_g5> what is the downside of having it on?
<zerver> one extra thread
<[LCC]jK> Spring already has >6-8 threads, one more or less doesn't matter imo
<[ARP]hoijui_g5> hye, daftalx is around
<[LCC]jK> esp. when it doesn't use much cpu time
<[ARP]hoijui_g5> but i can not send him a PM in chat
<[ARP]hoijui_g5> as he is on IRC only..
<[ARP]hoijui_g5> ah is ok...
<[RoX]Tobi> I'm fine with enabling it
<zerver> thread wakes up once a second and executes 5 instructions or so
<zerver> ok, can do it
<[LCC]jK> so move flush to hand detection thread and remove it from sim?
<[ARP]hoijui_g5> :D
<zerver> llol
<[RoX]Tobi> I'd even say just remove flush completely, or maybe completely after loading finished
<[RoX]Tobi> (i.e. only flush during loading)
<[ARP]hoijui_g5> mmm good idea!
<[RoX]Tobi> or only keep it in debug builds :)
<[ARP]hoijui_g5> ahh.. also good
<[ARP]hoijui_g5> both things
<[LCC]jK> so flush in myGL.h::PrintLoadMsg
<[ARP]hoijui_g5> hm?
<[RoX]Tobi> good
<[RoX]Tobi> who will do this?
<zerver> So if we remove the flush, isnt there risk of missing output after crash?
<zerver> or do we close logOutput in hang and crash handlers?
<[RoX]Tobi> I think that's done
<zerver> better check it
<[RoX]Tobi> yup
<[RoX]Tobi> should I move the flush?
<zerver> Plz
<[RoX]Tobi> ok I'll do that
<[ARP]hoijui_g5> yes..
<[ARP]hoijui_g5> in linux it surely is done
<[ARP]hoijui_g5> in crash handler
<[ARP]hoijui_g5> it has to close log output to be able to write the stack trace to the same file
Conclusion
* We don't apply the patch by SirMaverick
* Instead we remove flushing in Sim thread and verify streams are closed in crash handling (Tobi)
* Hang handing should be default enabled in single thread build (zerver)
== Do not build dedicated with "all"? ==
<[RoX]Tobi> I agree
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> i guess it is best if you do this too, so you can coordinate it with buildbot
<[ARP]hoijui_g5> (as you have to add ti again there, i guess)
<[RoX]Tobi> ok
<[RoX]Tobi> I might ask you how to change cmake things but that's for after meeting
<[ARP]hoijui_g5> ok
<[RoX]Tobi> anyone who doesn't agree?
<[LCC]jK> is there any reason for this?
<[RoX]Tobi> oops
<[CoW]Kloot> "all" does imply every buildtarget
<[RoX]Tobi> [LCC]jK: consistency with spring-gml / spring-hl
<[ARP]hoijui_g5> becuase practically nobody needs dedidcated, but everyone that compiles spring, builds it
<[LCC]jK> and how do ppl get currently dedicated binaries?
<[ARP]hoijui_g5> yeah and that
<[RoX]Tobi> although I tend to agree with kloot that all implies every buildtarget :)
<zerver> Could you please name it spring-mt instead of spring-gml ?
<zerver> GML is just my lib and may be discarded any time :)
<[ARP]hoijui_g5> i thoug hthe consensus was, that it is gml, not MT
<[CoW]Kloot> just change "all" to "almost-everything" and problem solved ^^
<[ARP]hoijui_g5> as MT woudl be if Sim was MT
<[ARP]hoijui_g5> yeah.. the problem is, that all is auto generated by cmake
<[ARP]hoijui_g5> we could only have a "really-all"
<zerver> Okay, not a big deal call it gml then
** daftalx joined the channel.
<[ARP]hoijui_g5> hello!
<[CoW]Kloot> or mt-gml?
<daftalx> hi (sorry for the time shift...)
<[RoX]Tobi> welcome daftalx
<[LCC]jK> welcome
<zerver> I'm not sure Sim will ever be MT though
<[ARP]hoijui_g5> yeah..
<[CoW]Kloot> yeah probably not
<[LCC]jK> not in near future
<zerver> It's one of those things you can try to invent if you have too much brain cells for the moment
<[LCC]jK> maybe someday part of it could be optimized with OMP
<[ARP]hoijui_g5> in my eyes, ebst woudl be, if we call it gml, and somethign like "MT (GML)" wherever the user will see it
<[ARP]hoijui_g5> eg in the lobby, or in the instalelr
<zerver> I promised thefatcontroller that the version string would contain "MT" earlier
<[ARP]hoijui_g5> hehe
<[ARP]hoijui_g5> ..why?
<[ARP]hoijui_g5> or why does he care?
<zerver> he wants to detect it and auto disable widgets
<[RoX]Tobi> zerver: isn't that already put in it in GameVersion.cpp ?
<[ARP]hoijui_g5> ah
<[RoX]Tobi> (independent of how the makefile target is called)
<zerver> yeah, version is independent i think
<[RoX]Tobi> daftalx: this is agenda btw: http://pastebin.com/cmZ6DZCN
<[ARP]hoijui_g5> hmm.. so it is just overall a bit inconsistent now :D
<[ARP]hoijui_g5> should we change that?
<[ARP]hoijui_g5> to all MT or all GML
<zerver> Use spring-mt.exe if it isn't too much work to change
<[ARP]hoijui_g5> ok
<zerver> I don't think we will have different MT variants in the future, even if we find a way to make Sim threaded.
<[RoX]Tobi> [ARP]hoijui_g5: you change it ?
<[ARP]hoijui_g5> yes, i can do that
<zerver> thanks
<[ARP]hoijui_g5> anyone agiasnt it?
<[ARP]hoijui_g5> i would preffer gml but i do not care too much
<[RoX]Tobi> I fine with anything
<[RoX]Tobi> next point?
<[ARP]hoijui_g5> yeah
<zerver> mt is a term the average user may understand, gml is not
Conclusion
* We don't build dedicated with all (I assume Tobi can fix this)
* Multithreaded binary should be renamed to spring-mt (hoi)
* Multithreaded binary has "MT" in the version string already
=== engine: fix malformed attack command crashing all players in game ===
<[RoX]Tobi> important enough to completely fix this before release?
<[LCC]jK> don't think so
<zerver> no, but it is incredible how spring lacks error handling
<[LCC]jK> if I understood it correctly, it can happen with nearly any command
<[RoX]Tobi> yes, as far as I have seen
<[LCC]jK> at best the error handling may happen per CMDTYPE
<[CoW]Kloot> and there have been plenty of crashes due to them in the past
<[RoX]Tobi> probably yeah
<zerver> Same with network probably
<[CoW]Kloot> but properly encapsulating Command is a _lot_ of work
<[RoX]Tobi> yup
<[ARP]hoijui_g5> it can be done gradually
<[ARP]hoijui_g5> does not have to be all at once
<[RoX]Tobi> just pasting if (ci->params.size() > X) is easy, but boring
<[LCC]jK> it would clutter sim-code, too
<[CoW]Kloot> and with that approach you're never quite sure if you have all cases covered
<[ARP]hoijui_g5> hmm?
<[RoX]Tobi> true that
<[ARP]hoijui_g5> why clutter sim code?
<[ARP]hoijui_g5> it is under Game/
<zerver> Maybe validate already when packet arrives...
<[RoX]Tobi> there are lots of candidate places
<[CoW]Kloot> not really possible
<[CoW]Kloot> since the sim determines context of command params
<[LCC]jK> yeah, it needs to be checked in the same simframe
<[RoX]Tobi> the particular case I fixed was lua widget - the input could there be checked already if there is some table somewhere with data about how many params each command type allows
<[RoX]Tobi> and indeed it needs recheck in sim, but once such data is in place that would be relatively easy
<[RoX]Tobi> anyway, all in all I agree that it's too much work for now to do before rc
<[LCC]jK> I do
<zerver> Maybe change the container type from vector to some other class that throws exception when out of bounds?
<zerver> And then catch exception in sim
<[LCC]jK> much work too
<[LCC]jK> also vectors have such a operator already .at()
<[RoX]Tobi> [LCC]jK: what do you mean with `I do' ?
<[RoX]Tobi> you do agree ?
<[LCC]jK> I agree
<[RoX]Tobi> kk
<[CoW]Kloot> for now we could overload operator [] to do boundschecking
<[CoW]Kloot> since that is used pretty much everywhere
<[LCC]jK> it may cause a noticeable slowdown
<[RoX]Tobi> that would be a bit of a hack (overloading std::vector) but it would work
<[ARP]hoijui_g5> i preffer doing nothign, and then do it right
<[RoX]Tobi> :)
<zerver> Only do it for cmd.params
<[CoW]Kloot> or only in debug builds
<zerver> and then one big try...catch around everything
<[LCC]jK> yeah, for debug builds it would be nice
<[ARP]hoijui_g5> dont think it is usefull in debug builds
<[ARP]hoijui_g5> i thoug the problem is, that this can be exploited?
<[RoX]Tobi> IMO such big try catch will just result in very un-understandable flows, and since it doesn't crash anymore no one will fix it :)
<zerver> The only important thing wrt Sim is that all clients behave the same
<[ARP]hoijui_g5> .. yes, what Tobi said
<zerver> So try catch could be in SimFrame() even
<[RoX]Tobi> besides, I completely don't trust exception handling in C++ (seen too many cases of exceptions passing straight through catch blocks etc.)
<[ARP]hoijui_g5> they say, that since mingw gcc 4.4, dwarf2 exception are good
<[ARP]hoijui_g5> and should not do that anymore
<[RoX]Tobi> then I'll need to upgrade mingw on buildbot
<[ARP]hoijui_g5> since that, everyone is moving to dwarf2
<[ARP]hoijui_g5> :D
<zerver> Anyway, I can make a class from vector and overload [] and make the try catch thing
<[ARP]hoijui_g5> .. or we do nothing
<[ARP]hoijui_g5> and start a discussion fo a nice way to encapsulate
<[RoX]Tobi> I think I agree with [ARP]hoijui_g5, do nothing until we have good solution
<[LCC]jK> +1
<daftalx> (+1, though i don't get the big picutre yet...)
<zerver> Only good solution may be to clutter sim code with checks
<[ARP]hoijui_g5> if it is encapsulated, checks can be called from wherever, no?
<[ARP]hoijui_g5> easy switching
<[ARP]hoijui_g5> if it is done well
<[LCC]jK> imo a good solution would be to just check all cmds before a simframe
<[RoX]Tobi> all cmds of all units?
<[LCC]jK> maybe it could be optimized somehow to detect if cmds aren't used in that simframe
<zerver> -1
<[RoX]Tobi> I think that will have way bigger performance impact then just checking on every access to operator[]
<[ARP]hoijui_g5> i though we are talkign about the giant command handling switch/if-elseif-elseif .. stuff in Game.cpp?
<[RoX]Tobi> heh, no, the Command::params member
<[ARP]hoijui_g5> ahh
<[RoX]Tobi> and how everything uses it without checking there are enough params
<[RoX]Tobi> either way
<[ARP]hoijui_g5> ahaa..
<[ARP]hoijui_g5> ok
<zerver> we are talking about every cmd.params[] access
<[RoX]Tobi> maybe we better take rest of this out of meeting sometime?
<[ARP]hoijui_g5> mmm
<[LCC]jK> k
<[RoX]Tobi> and just consider it non-blocking for the moment
<[ARP]hoijui_g5> ok..
<[RoX]Tobi> after all it's been like this for ages already
<[ARP]hoijui_g5> i have the crashes in CMiniMap::Draw()
<[ARP]hoijui_g5> that shoudl be fixed before release
<[LCC]jK> can be fixed during RC
<[ARP]hoijui_g5> http://springrts.com/mantis/view.php?id=1937
<[LCC]jK> we will get some more of those issues I assume
<[ARP]hoijui_g5> mm
<[ARP]hoijui_g5> ok
<[RoX]Tobi> ok
<[ARP]hoijui_g5> and AI desync.. same i guess
<[ARP]hoijui_g5> not even sure if it still happens, just got one report so far
<[LCC]jK> yup, that's what RCs are for :)
<[ARP]hoijui_g5>
<[ARP]hoijui_g5> anything else that needs to be done before RC?
<[RoX]Tobi> anything else that blocks RC then?
<[RoX]Tobi> :)
<[LCC]jK> OpenAl32.dll
<[RoX]Tobi> changelog?
<[LCC]jK> oh changelog
<[LCC]jK> good point
<[RoX]Tobi> more things I don't know right now
<[ARP]hoijui_g5> :D
<[LCC]jK> should one person do it? or should each dev fill his stuff into it?
<[RoX]Tobi> each dev IMO, to spread work
<[RoX]Tobi> going through >1000 revisions on your own is booooooooring
<zerver> just copy paste from git :)
<[RoX]Tobi> nah those changelog copied from git are incredibly bad IMO, it should be nice summary
<[RoX]Tobi> and not include all the fix typo here, fix compile there
<[ARP]hoijui_g5> :D the drughead russian guy is priceless :D he still thinks you are talkign to him, jk :D
<[ARP]hoijui_g5> next point?
<[RoX]Tobi> you can see what you did using e.g. git log --author=Name
<zerver> each dev then, hopefully you remember your main changes
<[RoX]Tobi> so what's the plan then, each adds his stuff to change log before next week ?
<[RoX]Tobi> and then we make rc ?
<[ARP]hoijui_g5> ok
<zerver> yes
<[RoX]Tobi> which also provides some time to fix some more bugs, fix the OpenAL thing, maybe do some internal testing, maybe upgrade mingw, etc.
<[RoX]Tobi> [LCC]jK, [CoW]Kloot, agree with that?
<[LCC]jK> kk
<[CoW]Kloot> yeah that works too
<[RoX]Tobi> did you have other plan?
<[CoW]Kloot> make RC now, get some early feedback and update changelog in the interim
<[LCC]jK> first OpenAL32.dll needs to be fixed
<daftalx> glitches with the sound ?
<[LCC]jK> so a RC could be tagged already midweek
<[LCC]jK> daftalx, no, it's a dll linking issue on windows builds
<daftalx> k
<[RoX]Tobi> what do we consider RC btw? same as past ones, e.g. http://springrts.com/phpbb/viewtopic.php?f=2&t=21737 ?
<[RoX]Tobi> (that does have complete changelog)
<[RoX]Tobi> or just 'appoint' one of latest test builds from buildbot as RC with post in dev forum ?
<[ARP]hoijui_g5> yeah,,
<[ARP]hoijui_g5> not too official if we alreayd know it has qutie osme bugs that need to be fixed before a release
<[LCC]jK> hmmm mod devs still need to fix their mods, they need a changelog to do this
<[ARP]hoijui_g5> as this.. what you linked.. we though about it as good enough for release
<[RoX]Tobi> yeah
<[RoX]Tobi> that is what RC usually means IMO, "we think it's good enough for release but surely we missed lots of bugs
"<[ARP]hoijui_g5> post in dev forum with at least the stuff important for mod devs ?
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> maybe just call it differently then
<[ARP]hoijui_g5> to make clear it will not be released like that
<[CoW]Kloot> the important (mod-breaking, eg the unit spawning changes) points are already on the forum
<[ARP]hoijui_g5> and announce only in dev forum, not news forum
<[RoX]Tobi> k
<[ARP]hoijui_g5> yeah.. but we need to put pressure on mod devs
<[ARP]hoijui_g5> .. maybe have a cross post in mods forum
<[RoX]Tobi> I'll put out a test build asap (tonight or tomorrow) in dev forum, that will just be a random build I select from buildbot
<[RoX]Tobi> and next week we have finished changelog and make real rc, k ?
<zerver> good
<[ARP]hoijui_g5> ahh.. good
<[LCC]jK> no more modinfo.tdf support
<[LCC]jK> no support for LightingCannon(sic) anymore
<[RoX]Tobi> otherwise meeting becomes way too long again :)
<[CoW]Kloot> that was announced even earlier
<[CoW]Kloot> http://springrts.com/phpbb/viewtopic.php?f=14&t=21811
<[LCC]jK> sure it was announced, but there wasn't a release between
<[LCC]jK> so you can expect that modders fixed their mods yet
Conclusion
* Malformed commands crash is not blocking and will not be fixed now
* The obvoius way to fix the bug bloats the Sim code quite a lot, may need a new approach
* Each dev should update the changelog ASAP
* OpenAL32 issue must be fixed before RC
==GPL (progress)==
<[ARP]hoijui_g5> in a week, AF shoudl release his source
<[RoX]Tobi> http://pastebin.com/ksz03LSi <-heres what I have now
<[ARP]hoijui_g5> .. i mean.. does not have to till then, but he said he will, most likely
<[RoX]Tobi> quick modification of the other thread
<[RoX]Tobi> I'm still messing around with the other/dual license points
<[RoX]Tobi> if you have input (now or later on) you can say it here or pm me later on
<[ARP]hoijui_g5> i would like if we recommended dual licencing over licensing eg under BSD
<[RoX]Tobi> also added it as etherpad on my to do list on the main etherpad
<[ARP]hoijui_g5> as it is more clear then that it is GPL in spring context
<[ARP]hoijui_g5> ahh
<[RoX]Tobi> anyway thats progress for now
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> next?
<[RoX]Tobi> you can also add comments in the etherpad if you want
Conclusion
* Work on the license statements is still in progress
==== * OS X (progress)====
<[RoX]Tobi> daftalx, your turn I suppose
<daftalx> right
<daftalx> so I now have a fully operationnal build of the latest (or almost) source
<[ARP]hoijui_g5> nice
<daftalx> and managed to pull out a portfile this morning
<[ARP]hoijui_g5> whats that?
<daftalx> so now spring can be installed in one line
<[ARP]hoijui_g5> ahh
<daftalx> itÔö£Ôòús the equivalent of rpm / apt-get etc.
<[ARP]hoijui_g5> nice
<daftalx> now i'd like to set up a builbot on my server, as my participation can be very variable at times
<[ARP]hoijui_g5> did you also test GML and headless?
<daftalx> not yet
<daftalx> i have to make a list of stuff to test with you guys
<daftalx> is there any plugin i need to install on top of buildbot btw ?
<[RoX]Tobi> no
<daftalx> ok then, will just need a quick hand in setting up the slave
<[RoX]Tobi> I can help you with that, I'll need to configure master to accept it & to know what it can run on the slave anyway
<[ARP]hoijui_g5> where wil you set it up, your machine?
<daftalx> yeah, got q mqc mini hooked in 24/7
<daftalx> (and a freakin french kb lol)
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> no idea what q mqc mini is
<[RoX]Tobi> aegis has also offered a 24/7 mac machine
<[RoX]Tobi> I'll try to also continue setting up buildslave there
<daftalx> used as slave ?
<[ARP]hoijui_g5> hmm
<[RoX]Tobi> with remote slaves you never know how long / when they are online etc. so a bit of redudancy can not hurt
<daftalx> it's a core2duo 2.2GHz with 2GB RAM
<daftalx> agree
<[RoX]Tobi> but he'll probably need instructions on how to build spring from you first
<daftalx> I use it to access my data from anywhere as i travel a lot
<daftalx> well if i manage to push the portfile to macports, he'll be happy
<daftalx> then i can push a portfile for each build type you mentioned (gml / headless)
<daftalx> are these separate git branches ?
<zerver> no
<[RoX]Tobi> no
<[RoX]Tobi> gml and headless are since a week ago or so separate build targets
<[RoX]Tobi> e.g. make spring-gml, make spring-hl
<daftalx> ok, that's perfect actually
<daftalx> so what's your plan for now ? want to go for a .app right away, or use the linux-like alternative for the short-term ?
<[ARP]hoijui_g5> the alternative is gentoo like?
<[ARP]hoijui_g5> downlaoding source and then building, for each client?
<[RoX]Tobi> I don't know how hard either is
<daftalx> well now it's in 3 steps : 1) install xcode (gcc etc.); 2) install MacPorts; 3) hit "sudo install springrts"
<daftalx> that's as simple as i managed to get it
<daftalx> but for every official release i could come up with a full binary, but the dependency libs are still needed..
<daftalx> i'd say it's already a substancial improvement over the exisiting tutorials :)
<[RoX]Tobi> and with .app you have everything at once?
<daftalx> that's the thing, i'll have to look into more details, but there are really a lot of stuff to bundle in
<[RoX]Tobi> ok lets keep with the macports thing for now I'd say
<[RoX]Tobi> indeed it would be a lot better then now already
<[ARP]hoijui_g5> mm
<daftalx> we just have to make sure what release is pushed to the repos
<daftalx> and the repo system allows to build different targets at once
<daftalx> so the gml and headless as well
<[ARP]hoijui_g5> mmm
<daftalx> i can also set up the repo to do a git pull before even compiling...
<daftalx> that would be a special "springrts-devel" package then
<[ARP]hoijui_g5> .. sounds good.. you will know what makes sense
<[RoX]Tobi> hmm I gtg already (meeting took too long again
)<daftalx> well the only thing is that versions should be the same over all oses
<daftalx> and the lobby still has issues
<daftalx> but working on it
<zerver> which lobby?
<[ARP]hoijui_g5> ok.. bye Tobi!
<daftalx> SL
<[RoX]Tobi> if I've time I'll PM you after dinner daftalx
<[LCC]jK> bye
<zerver> ok
<[RoX]Tobi> (and you have time too)
<daftalx> ok bye
<[RoX]Tobi> then we can see about buildbot
<daftalx> ok cool
<zerver> there is also qtlobby which you may compile directly on mac i think
<daftalx> thought that one was abandoned
<[RoX]Tobi> wrt buildbot, short update to handle that point too: stacktrace translator is running ( http://springrts.com:8000/ ), buildbot running ok too, still need to work on something to force builds properly
<zerver> abandoned, well no active dev atm but it works fairly ok
<[ARP]hoijui_g5> mmm
<[RoX]Tobi> will read rest of meeting in log :)
<[ARP]hoijui_g5> QTLobby is nto the way to go
<[RoX]Tobi> oh, and unfortunately next week at this time I can not be here
<daftalx> actually SL compiled at some point, but the wxWidgets is the tricky part
<[ARP]hoijui_g5> it lacks too much
<[RoX]Tobi> laters
<[ARP]hoijui_g5> eg.. AI
<[ARP]hoijui_g5> byee
<[CoW]Kloot> laters
<daftalx> they're hacking their build every now and then
<daftalx> bye
<daftalx> qt has no QI support ???
<daftalx> AI
<zerver> nope
<daftalx> grr
<zerver> but not everyone likes to play with AI
<zerver> im using qtlobby now
<daftalx> how about sync problems?
<[ARP]hoijui_g5> hm?
<zerver> of the lobbies i tried it is the one with least flaws for my specific requirements
<[ARP]hoijui_g5> the lobby can not cuase sync prblems
<daftalx> i heard about a few issues about unitsync
<daftalx> but i may be confusing (that was early last week)
<[ARP]hoijui_g5> yeah... but unitsync does not cause desyncs
<daftalx> i'll have a look into qtlobby then, but i'll keep working on SL qs well
<[ARP]hoijui_g5> it is not used during a game
<[LCC]jK> lobby syncing and ingame syncing are not the same
<daftalx> ok, then it's a lobby sync issue
<[ARP]hoijui_g5> unitsync just has a very stupid name
<daftalx> yeah figured..
<[ARP]hoijui_g5> it should be called ExternalSpringDataAccessLib or somethign liek that
<[ARP]hoijui_g5> anythign else about OS X?
<daftalx> but it did work once: http://imagebin.ca/view/aMlEzW5G.html
<[LCC]jK> who merges the changes into master?
<daftalx> right no changes for OS X
<daftalx> and i have full sound support and everything
<daftalx> so it's cool
<[LCC]jK> O_O
<zerver> great
<daftalx> the lobbies are more problematic
<[ARP]hoijui_g5> mmm
<daftalx> so by next time i'll try the gml and headless builds
<[ARP]hoijui_g5> nice
<daftalx> and setup the buildbot with Tobi
<[ARP]hoijui_g5> we are stll simplifying the headless build
<daftalx> well...guess i'm done for now
<daftalx> can't be of much more help for the moment
Conclusion
* OSX compiles without any changes (!)
* OSX buildbot slave will be set up (Tobi and daftalx)
* OSX needs to test the MT and HL builds (daftalx)
* qtlobby might be an alternative to springlobby on OSX
* unitsync is a confusing name and may need to be changed
==== * MT official build (progress) ====
<daftalx> i'm only dicovering the code
<[ARP]hoijui_g5>
<[LCC]jK> we could need a new dev btw
<[ARP]hoijui_g5> yeah.. daf, you want to be spring dev.. officially?
<[ARP]hoijui_g5> with commit access to main repo?
<[ARP]hoijui_g5> (girls love it!)
<zerver> so MT integration in the installer is basically done now?
<daftalx> well... i'd say until i don't need to commit stuff i don't need
<daftalx> though modding the Mac OS forum could be a good start
<daftalx> but hell yeah, whatever :p
<[ARP]hoijui_g5> :D
<daftalx> the lobby guys need me more apparently :)
<[ARP]hoijui_g5> mm ok
<[LCC]jK> zerver, your any progress with non-drawable contexts
<[ARP]hoijui_g5> well.. tell us if you have osmething to commit
<[LCC]jK> -your +?
<[ARP]hoijui_g5> zerver, i did the integration code for the installer, but i never loked at a genrated installer
<[ARP]hoijui_g5> did you?
<zerver> no :)
<zerver> jK: you mean glShareLists?
<[LCC]jK> yup
<zerver> i have not done anything on that side
<[LCC]jK> k
<zerver> it will complicate some things if there are still contexts in which gl is not allowed
<zerver> For instance, can you do actual rendering in Sim now?
<zerver> or would that fail?
<[LCC]jK> you can render it a displaylist
<[LCC]jK> *in
<zerver> Indeed, but I mean rendering to screen
<[LCC]jK> no, those are disallowed even in singlethreaded
<zerver> OK
<zerver> So basically I could use glShareLists but then I would have to disable most of GML
<zerver> Which I might do anyway because the gain is so small
<[LCC]jK> yeah, you could even compile display list in the other threads and use those instead of GML
<[LCC]jK> e.g. for terrain rendering
<zerver> I will look at it
<zerver> next point?
Conclusion
* MT and HL are integrated in the installer but installer not tested yet
* Use glShareLists to improve MT build compatibility with mods (zerver)
== Buildbot progress ==
<[LCC]jK> finished already?
<daftalx> i'm interested... especially if it gets "simple"
<[ARP]hoijui_g5> i think Tobi is pretty far there, yes
<[ARP]hoijui_g5> zydox told me he incorporated debug symbol translation already
<[ARP]hoijui_g5> (only werks for crashes from builds of new buildbot)
<[ARP]hoijui_g5> lets define somewhen during the week, when to have next meeitng?
<[ARP]hoijui_g5> as Tobi is not here, and wont be at same tiem next week
Conclusion
* There is good progress (at least we think so)
* Debug symbol translation is working
=== Next meeting ===
<[LCC]jK> yeah, next week will be 100% RC
<zerver> ok
<[LCC]jK> and some of you requested a longer delay
<daftalx> unfortunately i'll be off next week
<[LCC]jK> so may decide this during the week while RC is made
<[ARP]hoijui_g5> daftalx, off all weekend?
<daftalx> actually away from this wed to next tue
<daftalx> my first holiday week since christmas...
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5>
<zerver> end of meeting then
== End ==
Conclusion
* Next week will be largely dedicated to work on the release candidate
