Present: hoijui, abma, zerver, jK, Kloot, Tobi
=== Welcome ===
<Kloot> ping
<hoijui> hey
<hoijui> guess zerver wont come.. not seen online today yet, or any git or mantis activity
<hoijui> byt him
<hoijui> by*
<hoijui> nice stuff you committed today, Kloot :D
<Kloot> thanks
<hoijui>
<Kloot> thought it would be a better use of my time than arguing with a horde of ignorant forum loudmouths
<Tobi> =)
<hoijui> yeah :D that is fine
<hoijui> i can deal with that
<hoijui> or well.. if nobody does.. also fine
<Kloot> someone should just refer them to some clauses from the gpl
<hoijui> :D
<Kloot> specifically those pertaining to warranty
<hoijui> yeah true... i tired to do that in a muhc more inneficient way, kind of
<hoijui> mmm
<hoijui> so.. whos gonna do the minutes?
<Kloot> I can do them
<hoijui> thanks
=== Release Plan ===
<hoijui> yeah.. depending on how the testing will go.. will maybe make a .7 soon
<hoijui> guess.. not much more to say.. is there anythign else that should go in and is not yet ready?
<Kloot> I have one more pathing tweak in the queue, but it is not critical
<hoijui> ok
<hoijui> will wait some
<hoijui> do you plan to do it in a week or so?
<Kloot> dunno, when I feel like it really
<hoijui> ok
<hoijui> could still do a .8 :D
<hoijui> next..
=== communication enhancement with mod-devs ===
<abma> what's missing there?
<hoijui> guess that is covered with http://answers.springlobby.info
<Tobi> _koshi_ has set up answers.springlobby.info
<abma> aah, ok :)
<abma> perfect
<hoijui> the plan is, that we put our sample questions in there
<hoijui> i had only one, and cant answer it myself
<hoijui> Tobi put his in too
<Tobi> ..and promote it as more persistent / higher quality place for modder<->modder and engine<->modder Q&A
<hoijui> mmm
<abma> make sticky in php forum?
<Tobi> could make a news post
<jK> make a link on the website
<hoijui> we also shoudl edit the about page there
<hoijui> didnt we have some introduction text for this somewhere, intended for the subforum
<hoijui> ?
<Tobi> if anywere it should be in the etherpad, right?
<abma> all we have is on the q/a etherpad i think...
<hoijui> mm ok
<hoijui> mixed it up wiht something else then
<hoijui> lets just gradually edit the default About text then, until it needs no more change :D
<hoijui> soo.. we shoudl do strict moderation there, yeah?
<hoijui> if a question does not fit.. delete, and tell to re-ask in forum eg?
<Tobi> we should direct it so it becomes as much self moderated as possible
<Tobi> e.g. so also modders vote down bad question and vote up good ones
<hoijui> sounds better, yeah
<Tobi> also just close bad questions
<hoijui> mm
<Kloot> if one of us spots a bad answer (that's factually wrong fex), should we vote it down or be even stricter?
<hoijui> and.. if there is a question which is good, but.. eg the title is way longer then should be
<Tobi> vote down, with preferably a comment as to why it's wrong
<hoijui> heyy!
<zerver> hi
<Tobi> I hope we can get enough people to participate :)
<hoijui> mm
<abma> (we still need more promoteing)
<Tobi> since spring community is tiny compared to many others
<Tobi> yup
<Tobi> I will post a news post
<hoijui>
<hoijui> does everyone here already have an admin account on there?
<hoijui> or .. whatever rights we shoudl have
<jK> no?
<hoijui> do we need more then normal rights?
<jK> oh I don't have a acoount at all yet
<jK> ^^
<hoijui> :D
<zerver> me neither
<hoijui> Tobi.. do we need more then normal user rights?
<hoijui> i do, cause i was second user, to test some...
<hoijui> for changeing about page eg, you need admin, i think
<Tobi> hmm, I think we shouldn't, although it might be necessary for bootstrapping the site
<Tobi> (since with enough reputation you automatically get some moderation rights)
<hoijui> ahh ok
<hoijui> we will see
<Tobi> we should definitely review how it works out in the next few meetings imo
<hoijui> mm ok
<hoijui> next?
<abma> yep...
=== lua state split (EXPORT and Script.XXX) ===
<hoijui> finally, jka AND zerver are around :D
<zerver> yeah
<hoijui> jk*
<zerver> Just need to discuss how it should work when we have split states
<zerver> I think it is fairly straightforward for gadget <---> gadget calls
<zerver> synced should always call into synced and vice versa
<zerver> gadget --> luaui is more interesting
<zerver> if luaui isnt split though, it is not much to choose from :)
<jK> "synced should always call into synced and vice versa" ?
<jK> any lua instance can run in a separate thread
<zerver> yeah, synced gadget code does Script.LuaRules.XXX
<jK> no
<jK> Script.XYZ is for inter-instance communication
<jK> LuaRules(synced) <-> LuaGaia(synced)
<zerver> yeah
<zerver> thats what i meant
<jK> LuaRules(unsynced) <-> LuaGaia(unsynced) -> LuaUI
<zerver> and LuaUI --> ?
<jK> LuaUI can't call into gadgets
<zerver> ok
<zerver> GOOOD
<zerver> I think my branch does what it should then
<zerver> did you work any on this? otherwise try my branch...
<zerver> next?
=== have a spring_last_version.tar.gz to avoid changing the scripts each time you update the game ===
<hoijui> yeah, the current(new) Slackware repo maintainer requested this
<hoijui> aehm.. guessi just should have asked Tobi :D
<hoijui> would need a symlink in springrts.com/dl/ ?
<hoijui> or can it be done in SF.net?
<hoijui> will check sf..
<hoijui> next
<abma> hm... next
=== do this for buildbot master builds too, something like: spring_last_version.exe + spring_last_stable.exe ===
<abma> ...next :)
<abma> as note: this would be for an auto-downloader to test current builds
<zerver> mmm
<abma> windows builds...
<zerver> good idea
<abma> just fetch latest installer and install portable + silently
<hoijui> hmm.. maybe an other way of doing this, is hosting soem file that only contains the version
<abma> this would allow easier testing for modders
<abma> yep, that was my other idea
<hoijui> ah
<abma> but this file should be updated by the buildbot, too
<hoijui> no
<hoijui> when it is set live
<hoijui> has to be manual
<abma> i mean master builds
<abma> not stable
<abma> ok, both
<abma>
<hoijui> ah... ok
<abma> one by hand and the one of master by buildbot...
<hoijui> shoudl be easier for latest master
<hoijui> mm
<hoijui> what do you think Tobi?
<abma> i'm unsure what's better for wget
<Tobi> a file / folder / link for latest is more standard then a separate file for it, I think
<abma> hm, do it like in the installer? wget -N http://...latestlobby.exe
<abma> a link should be also easy to setup in the buildbot.. i hope so
<Tobi> yeah that's what I mean
<Tobi> anything should be reasonably easy on buildbot
<hoijui> yeah true
<hoijui> i'll put it on my TODO list then, yeah?
<abma> ok, thanks
<abma> then next :)
<Tobi> that is ok for now - after thursday I can look at buildbot too if you want
<hoijui> ok..
<hoijui> yeah.. then you do it
=== Next Meeting ===
<Tobi> sidenote: I put a draft news post in the Q&A etherpad. good to post?
<Tobi> same day/time is fine for me
<Tobi> I'll post it in 10 mins or so unless someone really wants to rewrite it
<jK> looks very nice
<Tobi> thx
<hoijui> ditto
<hoijui> yeah.. also like this monday meeting
<abma> yep, looks nice
<abma> i liked it too
<abma> and time is fine...
<Kloot> yeah, for me monday >>> sunday
=== Anything else? (WVTTK) ===
<Tobi> sounds like we are a bit closer to the Pareto optimum for the meeting time then
<hoijui> :D
<hoijui> no idea what pareto is
<Kloot> game theory
<hoijui> ok
<hoijui> well.. i have a small thing i could use your help
<hoijui> when the Java AI Interface is used, it starts the JVM
<hoijui> that one needs a certain ammoutn of continous (virtual) memory space
<hoijui> depending on the settings
<hoijui> if this is not available in the process, it can not start
<hoijui> this seems to be possible under windows at least, as cranphin was able to get there a few times
<hoijui> one solution would be, to reserve some memory soon after process start
<hoijui> free it right before JVM invocation
<jK> or to defrage the memory >_<
<jK> -e
<hoijui> and only do this if a Java AI is used of course
<hoijui> yeah..
<Tobi> would it allocate more memory from the OS in that case anyway?
<hoijui> is that possible?
<hoijui> no, not more
<jK> back in w98se days there were tools for it
<Tobi> or is the problem that actually the OS memory space is too fragmented to give the desired chunk
<Tobi> (which seems strange to me)
<hoijui> i think, it is only the processes memory space
<hoijui> virtual memory is process local, right?
<Tobi> depends on the context
<hoijui> i remember that the one that matters here, is process local
<hoijui> an other solution is, running the JVM in a separate process
<hoijui> but.. that would be a very work intensive thing of course, and possibly very buggy
<Tobi> then it will have to marshal all calls using some remote procedure call thingie?
<hoijui> exactly
<Kloot> how much does it need in the worst case? since spring allocates huge chunks of its own too
<hoijui> i dont know in the owrst case, but i think it is somewhere between 64 and 256MB
<Tobi> news posted
<hoijui>
<Kloot> ok, 256 might be pushing it
<hoijui> the thing with reserving early in process live is, that this kind of violates the "rule" that interfaces are initialized at game start.
<Tobi> but with the JVM you always have to specify the max right?
<hoijui> i sure could somehow wrapp it in a kind of.. modular way, whihc is not used by anythign else then Java AI Interface..
<Tobi> and just to check: the problem isn't that it doesn't allocate all at once, and then later wants to realloc e.g. 32M to 64M, which then fails due to heap fragmentation?
<hoijui> yeah max
<Tobi> because if so, the solution might simply be to force the JVM to allocate all at once (e.g. by saying min heap size == max heap size)
<hoijui> yeah, it does try to do it all at once
<Tobi> pl
<hoijui> not in stages
<Tobi> *ok
<Tobi> seems fine to me then (to allocate up front)
<Tobi> (if indeed that solves the issue)
<hoijui> easiest would be, if there is some defragmentHeap(int wantedcontinousMax) function
<Tobi> just need to take care to free it also if jvm isn't running
<hoijui> yeah :D
<hoijui> ok..
<hoijui> thanks then
<Tobi> with regards to memory allocation, did someone ever try to use multiple heaps, i.e. one per thread?
<Tobi> I think for Lua that runs in multiple threads at the same time that could easily give a 10% or more performance improvement
<hoijui> is that possible? is it like.. an extra heap for the process, or just dividing the current one, kind of... virtually?
<jK> I remember to read a paper about this
<Tobi> as Lua does many allocs and with single heap (almost?) every allocation means locking a mutex AFAIK.. (those deadlocks inside malloc made me think of this)
<jK> it is possible with TLS
<jK> but TLS is slower, on the other side it doesn't need to lock heap allocations
<Tobi> slower than normal globals?
<jK> and yeah, the paper said it was something around 10% faster
<jK> yup
<Tobi> what kind of allocation load did they use?
<Tobi> (cause I think Lua is very heavy on memory allocator, many tiny allocations)
<Tobi> at least I recall Roberto writing something like that in a design doc / paper about Lua
<jK> I always thought Lua would rarelly alloc huge blocks
<Tobi> checking
<jK> can't find the paper anymore
<jK> but this one looks similar: http://www.cs.tau.ac.il/~tvla/sa/theses/msc-yair.pdf
<zerver> Does it cause any ill effects to allocate a huge amount of virtual memory?
<zerver> If the memory isnt used, the OS tends to handle it very well IIRC
<Tobi> Lua really does lots of small allocations
<Tobi> we use lua_open, which is luaL_newstate, which calls lua_newstate with a standard allocator that simply calls realloc
<Tobi> that allocator luaM_realloc_ is used in #defines luaM_malloc, luaM_free, luaM_freemem, luaM_realloc that are really used in single strings, tables, when a closure is created, etc.
<Tobi> => it's easy to make Lua use it's own heap if desired
<Tobi> don't even need TLS for it, as you can simply pass different allocator to different states
<Tobi> and one state should always allocate from same heap anyway
<Tobi> anyway that's just an idea
<abma> does an daily updated cppcheck help anyone?
<Tobi> it seems to me that by not exploring that while continuing to do complex other stuff to make things faster with multithreading, we might skip some low hanging fruit
<Kloot> hmm, we could finally have a purpose for that crappy cmempool class
<jK> first we need to have a multithreaded lua, only then we could test the performance
<Tobi> Kloot: doesn't mempool only do blocks of equal size?
<zerver> CMempool is not thread safe
<Tobi> [LCC]jK: yeah, but only having LuaUI run in a different thread than sim would already be enough to potentially allow a measurable performance improvement when using separate heaps for separate Lua states, I think
<Tobi> zerver: point of using separate heaps is that the heaps do not need to be thread safe, so can be faster
<zerver> yeah
<Tobi> (though maybe for robustness real ones might be thread safe but just revert to slow locking behaviour when called from the wrong thread?)
<jK> tobi, atm LuaUI still runs in the same thread :)
<Tobi> hmm no that would completely miss the point
<Tobi> ya I know
<Kloot> each thread should only be allowed to know about its own pool anyyway
<Tobi> ideally, yes
<Tobi> I doubt in Spring that would be true at the moment, if we were to use different heaps in different threads
<Kloot> yeah
<Tobi> abma_irc: would definitely help
<Tobi> as IIRC jK already fixed few bugs sometimes with cppcheck?
<abma> http://spring.abma.de/logs/cppcheck.log
<abma> it is daily updated
<Tobi> nice
<jK> yup
<jK> cppcheck is very usefull
<jK> -l
<jK> but I run it myself quite often
<jK> the GUI is much easier to use than such a log
<Kloot> ugh, false-positive flood
<abma> i enabled all params, thats why there are so many messages
<abma> if the gui opens directly the file/line... then yes
<jK> it has a very low false-positive rate
<Kloot> is there a way to split the log up?
<jK> use the GUI
<Kloot> eg. one for code under rts/Sim, one for AI/, etc
<jK> the GUI has a nice tree
<hoijui> the only false positives i had so far, were "variable could be moved to more strict space"
<hoijui> or somethign liek that
<hoijui> when it was code with lots of #ifdef
<jK> and the crash commands
<hoijui> crash commands?
<jK> /crash
<jK> /divbyzero
<hoijui> ahh yeah
<Kloot> it also complains about variables not being initialized, when they are (just not in constructors where it wants them to be)
<jK> and that's good, kloot!
<jK> variables should be initialized in the constructor
<Kloot> not really, it's just spam in 90% of all cases
<jK> else code can read from it, and crash randomly
<jK> esp. in synced code this is very very important
<hoijui> i agree with jk
<jK> and it a real design problem in huge parts of spring's code
<jK> that's what I did with UnitDef(const LuaTable& udTable, const std::string& unitName, int id)
<Kloot> I see tons of references to unsynced code, few to synced code (where I agree it is important)
<Tobi> but unless you measure it to be a bottleneck that is not a good reason to not init them there of course
<jK> before it created the UnitDef and then filled the members (and leaving many members uninitialized!!!), I moved all this into the constructor
<hoijui> mm
<hoijui> jk and me already fixed a lot of these missing inits
<hoijui> thats why theres few in synced
<jK> yup
<jK> we already solved >70% of all issues
<hoijui> of course you cant blame the tool for displayign them in unsynced :D
<abma> the next eyecandy is: doxygen: http://spring.abma.de/doc-spring/
<abma> [RoX]Tobi: would it make sense to push this somewhere to the spring-server?
<abma> my server is only a very slow low-budget v-server
<Tobi> yeah
<Tobi> I've been looking actually at hudson, to possibly replace buildbot
<Tobi> it's a lot easier to configure and has a lot of plugins
<Tobi> but I don't really have time until after thursday to actually do something
<Tobi> (paper deadline)
<abma> aaah, ok
<abma> then talk about that after thursday :)
