== 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-220.127.116.11/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!
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum