Present: <abma>, <jk>, <kloot>, <tobi>, <zerver>


== Welcome ==

== who makes minutes? ==
<zerver> ok, I will make em



== Release plan ==
<zerver> we should release on friday
<abma> why friday?
<abma> or... why not?
<jk> releases on fridays always failed
<zerver> im kidding, but we need a few days to nuke some remaing crashbugs
<jk> in 99% there are bugs and spring is unplayable for 1week
<abma> ok
<zerver> :)



== Sync ==
<abma> [RoX]Tobi: maybe we should talk first about the sync problem?
<tobi> yeah, don't know how many noticed
<tobi> but on Fedora 15 I noticed neither distro built package nor self built package syncs with release
<jk> btw I would still find a better solution for this: https://github.com/spring/spring/commit ... 6#comments
<tobi> also a yesterday or so a similar bug was reported in Debian
<jk> -would +want
<tobi> [AG]abma said it didn't sync in recent Ubuntu either
<jk> GCC4.6 ...
<tobi> koshi synced with gcc 4.6
<jk> I wonder why so many distros switched so early
<tobi> self built gcc 4.6 and self built spring
<jk> gcc build with -march/mtune?
<tobi> in any case it will be a major issue
<tobi> not in the output of -v afaihs
<tobi> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checki
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --dis
-with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
h=i686 --build=i686-redhat-linux
<tobi> with self built gcc 4.5 I desync too
<tobi> didn't try any older yet
<tobi> so I actually think it isn't gcc or isn't only gcc
<jk> k
<jk> needs a few debug matches then
<tobi> yeah, syncdebug and/or more matches on slightly older platforms to see where it started breaking exactly
<zerver> instant desync ?
<abma> no
<tobi> nearly instant (within a few min)
<jk> assimp can be a cause
<tobi> I observed this in current release
<tobi> so no assimp involved yet
<jk> k so 300,000 LOC left ^^
<abma> in other words 0.82.7.1 desyncs, too when built on ubuntu 11.04
<tobi> and abma and I sync (i.e. Ubuntu 11.04 vs Fedora 15)
<jk> time to setup an enviroment for a syncdebug build
<tobi> ya guess so
<tobi> suppose I'll make a mantis too
<zerver> k, so this is the biggest obstacle for the release
<abma> next week i can help with compile/testing... currently i've only a bad computer
<tobi> abma: did ubuntu 11.04 package sync?
<abma> stable ubuntu 11.04 package does sync
<tobi> ok
<abma> i don't know if there is a package of spring/master
<tobi> I understood from koshi that is gcc 4.5
<tobi> strangely his 4.6 seemed to sync too (desynced from us at least)
<tobi> [AG]abma: so what was it again what we tested? self-built spring with packages gcc 4.6 ?
<tobi> *packaged
<abma> the packaged 0.82.7.1 in ubuntu 11.04 syncs
<tobi> yeah
<tobi> but you also tested something that made you desync, right?
<abma> my spring master compiled with gcc 4.6 synced with tobi, but didn't sync with koshi
<abma> self-compiled stable didn't sync
<tobi> k
<abma> it took some time until it desynced
<tobi> and it was a gcc 4.6 package?
<abma> self-compiled was with gcc 4.6
<abma> i also tried 4.5 that desynced, too
<tobi> yeah but I mean, did you compile gcc 4.6 yourself
<abma> no
<tobi> or did you use a gcc-4.6 package?
<abma> that was from a ppa
<tobi> ok
<tobi> you can check here: http://springrts.com/mantis/view.php?id=2459
<tobi> maybe I still need to try to build gcc 4.5 with gcc 4.5 and then build spring with that
<tobi> instead of trying gcc 4.5 built with gcc 4.6 :)
<abma> hopefully we didn't mix stuff
<tobi> i.e. more complete bootstrap
<abma> next week i can check with ubuntu 10.04 again + gcc 4.6
<tobi> sucks to trace this down since I didn't even play online since before I upgraded to F14
<jk> I will try to setup a syncdebug enviroment today
<tobi> so could have even been broken in F14/gcc 4.5 already
<tobi> ok
<tobi> with master?
<jk> with git
<jk> switching between branches/tags shouldn't be a problem once I set it up
<tobi> ok
<jk> gcc switching could be a bit more compilicated, but should be doable too
<jk> -i
<zerver> if there is something I can help with, shout, but I have no unix box
<zerver> otherwise imma continue the crashbug hunt
<tobi> I guess continuing other things is better choice in this case :)
<zerver> next?



== Remove remaining .n's or re-add them? http://springrts.com/mantis/view.php?id=2456 ==
<abma> [LCC]jK: are there pro/cons for that?
<abma> con is, that some games don't work with spring/master
<tobi> I don't really mind what will be the solution to this
<jk> I prefer removing them, but if doing so we should remove ALL of them
<abma> is that.. ehm.. doable with something grep-like? maybe grep for "n" ?
<abma> + how to fix the lua code?
<tobi> are there cases where the returned table is not an array?
<jk> sure
<tobi> for all arrays you can replace it with # operator
<tobi> for non-arrays you need to write a loop / call a function to count the elements in the table
<jk> but it for non-arrays the .n isn't used afaik
<jk> -it
<tobi> ok
<zerver> so is adding the # acceptable or will modders raeg about this change?
<jk> some very old widgets may fail
<jk> the amount of incompability should be very limited
<abma> especially unit-morph... but afaik fix should be very easy
<abma> the fix will work on current release?
<abma> if so, i'll see no problem with this change
<abma> with "the fix", i mean the the fix for the lua-script
<tobi> [AG]abma: yeah should work



== Can the 0.8* branches be removed? guys still seem to start with non-master-branches to ==
<tobi> IMO they can go, we can just make new branches of tags if desired
<abma> ok, then i'll anoy some of the game-devs about that, if i see this problem
<zerver> k
<tobi> just keep that branch I made past week, 0.82.7.1-gcc-4.6
<abma> ok, i'll ask hoijui about that, he is the git-guru + remove then
<jk> btw abma that `guy` intentionaly used the 0.82 branch
<abma> so.. hmm
<abma> yes, this is why i want it to make a bit "harder" to use an old branch/tag
<jk> 1. he wanted to play online with his build 2. he didn't wanted any merge conflicts
<zerver> :)
<abma> so..



== Next meeting ==
<abma> shall we start half an hour later?
<zerver> if we do, will it have the desired effect?
<abma> i don't know :-/
<abma> so, kloot, zerver: why where you late? would starting half an hour later help? :)
<kloot> I just had late dinner :)
<abma> i was late because i was busy in the garden a bit and forgot time :D
<zerver> it is national day of Sweden today, late dinner with champagne
<abma> [RoX]Tobi: [LCC]jK: what do you think? imo, if it fails next week, we keep it at 21:00
<tobi> so next week 21:30 ?
<jk> fine
<abma> ok
<zerver> sweden and some other countries use "academic quarter" http://en.wikipedia.org/wiki/Academic_q ... _timing%29
<zerver> so it is deeply rooted in my mind that being 15mins late is OK
<abma> so: zerver: next week its 21:00 for you
<zerver> lol
<abma> ok, fine
<zerver> fine



== Anything else? (WVTTK) ==
<zerver> i'd like jk to clarify the fixme https://github.com/spring/spring/commit ... d77d372d4a
<jk> you put the set_threadnum in a if-clause - very likely because if loadscreen is not threaded it would get called twice from the same thread causing undesired behaviours
<jk> now this should be solved in set_threadnum itself
<jk> so you can call it multiple times from the same thread w/o any undesired behav.
<jk> e.g. Watchdog works fine if you do so
<zerver> but CGame::LoadGame is only called once
<jk> doesn't matter
<jk> set_threadnum is unsafe currently, don't try to fix it with hacks
<zerver> sry, still don't get it
<zerver> and where is the hack? am I now allowed to set a thread number for that loading thread?
<jk> sure you are, but please without making mt_loading public
<zerver> OK, so GetLoadingMT()
<jk> no
<jk> fix set_threadnum!
<jk> make set_threadnum work when called twice from the same thread, so you don't need a if-clause at all!
<zerver> i don't see how, the loading thread needs a number
<jk> save multiple numbers per thread?
<zerver> you mean, i should fix the set_threadnum so only the first call has any effect?
<jk> or that
<jk> there are many solutions
<zerver> kk,will check
<zerver> but without that if clause, it is a bit ugly imo, because that is not the loading thread unless mt_loading is true
<jk> it is the loading thread
<tobi> can't the thread num be set at the place the thread is created or so?
<jk> it's always the loading thread that calls that function
<zerver> no, in that case loading thread == main thred
<jk> but sometimes loading thread & mainthread are the same
<jk> still it is the loading thread
<zerver> kk, fine
<zerver> im a bit fraid my attempts will produce a much worse solution
<zerver> it will require some form of TLS or indexing by thread ID, and with the portability issues that come with that...
<jk> depends on your needs
<jk> if you do this: <zerver> you mean, i should fix the set_threadnum so only the first call has any effect?
<jk> nothing special is needed
<jk> if you save a list of numbers, it becomes a bit more complex
<zerver> set_threadnum is the "root" for all TLS that GML uses
<zerver> and now I may have to make another separate TLS mechnism
<zerver> im just thinking this just delays our release
<jk> so get_threadnum isn't safe either?
<jk> -> if called from a unregistered thread it returns bogus?
<zerver> yep
<zerver> garbage
<zerver> it uses some ASM and the FS register
<jk> you still can use posix threadids
<jk> setthreadnum is called such rarely
<jk> you could even play with gcc's `thread static` vars
<zerver> ok, index a map by posix thread id
<zerver> __thread etc isnt portable
<jk> on gcc it is and afaik it is part of c++0x
<jk> but yeah, MSVC is slow and special ...
<zerver> :)

I got desyncs on Fedora 15 64bit with current version of Spring from fedora repo. I thought that this issue only of 64bit version. I am very happy that you know about this problem and I hope you will fix it Thanks!