Dev meeting minutes 2011-05-02

Dev meeting minutes 2011-05-02

Minutes of the meetings between Spring developers are archived here.
Post Reply
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Dev meeting minutes 2011-05-02

Post by zerver »

Present: <hoijui>, <jk>, <tobi>, <zerver>
Maybe present: <kloot>



<jk> <abma> sorry, i have to go, good night and good luck! :)



=== Welcome ===
<zerver> thx



=== Who makes minutes? ===
<zerver> k, I'll do
<jk> thx



=== Release plan ===
<zerver> so, we are waiting for the pathing fixes, and after that make a release branch?
<jk> release branch?
<zerver> for 0.83 ?
<jk> bad idea imo, it just cause merging problems
<zerver> so u want to release directly from master?
<jk> yup, worked fine in the past
<tobi> just need to branch lazily, i.e. only when some new big stuff started in master that shouldn't go in 0.83.X
<zerver> yeah
<tobi> I think that is best tradeoff between stability and merge conflicts ;p



=== Find something to do for halcyon = Cheesecan ===
<jk> http://springrts.com/phpbb/viewforum.php?f=60
<zerver> the projectile events, good idea
<zerver> even though the amount of projectiles active at any given time even in big games is pretty small
<jk> not true
<jk> imagine 50 versus 50 flashes
<jk> or 100 corak
<jk> or 1000 scouts ...
<zerver> yeah, but they die like flies
<jk> can cause events doing so!
<jk> the amount of events can easily be hundred times bigger than the amount of drawframes
<zerver> u mean simframes
<jk> simframes are normally less a problem than drawframes in lua
<jk> (you normally got more draw ones than sim ones)
<zerver> but projectilecreated is once per projectile?
<jk> but here the problem is that the event overhead is stalling the engine in situations (huge fight of units) where it needs each single cpu cycle
<jk> <zerver> but projectilecreated is once per projectile? > yeah?
<zerver> I just didn't see the relationship between drawframes and the events
<zerver> because I thought sim fires the events
<hoijui> i told halcyon go be here for the meeting, seems not to be online
<jk> it's the amount of in-lua calls per second
<hoijui> for the next release and branching.. we already decided how to do it
<jk> the more calls you do into lua -> the slower the engine is
<hoijui> master will be the release branch, and we woudl have a develop branch
<hoijui> or alternatively, keep master as the dev branch, and have a new release branch (for all releases)
<jk> ah yeah totally forgot that switch
<jk> and yeah, a dev branch is easier to handle
<hoijui> would it help to run spring in valgrind to find the stack corruption bug, maybe?
<hoijui> i might do that sometime these days, if it might
<zerver> yeah, tedious work to wait for valgrind :P
<hoijui> mm
<hoijui> its not just the waiting, but also.. the lots of useless reports
<hoijui> you have to run it many times.. until you got all the useless stuff on hte ignore list
<hoijui> i have a big list from .. maybe 3/4 years ago, so it may take me not too long to ignore new useless reports
<hoijui> useless or uninteresting for now...
<zerver> we are off topic, unless halcyon wants to play with valgrind
<hoijui> !!!!!
<hoijui> good idea!
<hoijui> to get him in the mood
<jk> lol
<hoijui> well.. we can go next, as he is not here



=== remove StdAfx.h completely? ===
<jk> what?
<hoijui> aehh.. what what?
<jk> don't understand the topic
<zerver> not a good idea, will cause tons of compile errors with msvc
<hoijui> it is only useful on VS, no?
<zerver> no
<zerver> not the way it is designed now
<hoijui> it creates artificial interdependencies
<zerver> the current stdafx is more like a "spring basics" include
<zerver> if we remove that, some other h file must take its place
<hoijui> mm ok
<hoijui> i just saw it bascially includes nothign on non VS
<hoijui> next then!
<jk> why does my gcc creates a StdAfx.h.gch with >13MB then?
<zerver> USE_PRECOMPILED_HEADER ?
<jk> yup
<jk> but it seems to be everything else than unused to me
<hoijui> mmm :/
<hoijui> USE_PRECOMPILED_HEADER is not defined in CMakeLists.txt (the root one)
<hoijui> neither the one in rts
<hoijui> i coudl only imaigne that gcc uses that file automatically, due to its name
<zerver> :)
<zerver> automagic
<zerver> well, i see no benefit in removing it atm
<zerver> and if we remove it, it must be done by some msvc user
<hoijui> ?
<hoijui> as muhc as i remember, the only reason to have it is for faster compiles in MSVC
<zerver> no, it generates lots of ambiguous caller stuff without it
<zerver> excatly why, i have not investigated though
<hoijui> lots of ambiguous caller?
<hoijui> dont know what you mean
<hoijui> (i do not have StdAfx.h.gch in my build dir)
<hoijui> SCons seems to have used USE_PRECOMPILED_HEADER
<hoijui> is your StdAfx.h.gch recent, jk?
<hoijui> hmm well you got a relatively new machine.. so i guess yes :D
<jk> hmmm didn't got recreated when I deleted it
<hoijui> ok
<jk> our cmake doesn't use precompiled headers?
<hoijui> i think not
<hoijui> coudl not find it
<jk> hmmm might worth to readd it
<hoijui> it would have to be in the root or the rts/ CMakeLists.txt
<hoijui> yeah?
<hoijui> well yeah.. is no biggie
<hoijui> but default off, right?
<jk> in scons is was default enabled afaik, but always caused troubles with buildbot (which had it disabled)
<hoijui> mm ok
<hoijui> as i remember, i got told that it even slows down compiling on gcc
<zerver> that was before someone cleaned it up
<zerver> maybe auswasch
<hoijui> yeah.. ok.. so we readd it to cmake as default off, then do some tests, and make it default on if it works well>
<hoijui> ?
<zerver> yup
<tobi> yeah I think I measured that sometime, if you make pch include a lot of STL stuff on gcc it will just make compiles slower
<tobi> not sure that is still true of course
<hoijui> i will not do that testing ;-)
<tobi> probably because we have lots of source files that don't really need all the stuff the pch drags in
<tobi> (on msvc)
<jk> hmmm true, also cpp compilation isn't the slow part in spring's compilation progress
<tobi> linking beats it nowadays?
<jk> for me it is file modification checking + dependency checking
<zerver> not on a complete rebuild :P
<hoijui> i would say, incremental builds are muhc pore important to optimize
<hoijui> much more*
<jk> a complete rebuild would need further profiling (IIRC there are some specific files that compile slowly)
<hoijui> shoudl we really spent so much time on this?
<tobi> no
<jk> but yeah, full compilation is not worth to optimize
<tobi> compile will automagically get faster as code gets structured better (with less spaghetti dependencies between files etc.)
<jk> we need a good tool to identify such dependencies
<hoijui> yeah thats also what i would bet for
<jk> tried some but all failed :<
<hoijui> mm :/
<zerver> spaghetti that compiles is better than macaroni that doesn't
<tobi> unless the macaroni can be made to compile by just adding some cheese
<hoijui> :D :D
<zerver> lol



=== How close to merge is Kloot's path finding branch? ===
<hoijui> one important thing woudl be, an external logging lib
<hoijui> i am following that.. none in sight yet
<hoijui> ping Kloot
<hoijui> next
<zerver> hm, no 0.83 release today
<hoijui> :D



=== Why not add ./ & ../ as data-dir? ===
<hoijui> becasue one file woudl be available multiple times under different paths
<hoijui> why add both?
<jk> not true
<jk> or semi ture
<jk> but with just ../ it breaks current one-folder setups under windows
<hoijui> they should not have ../ added
<zerver> with my solution, files would only be available one time
<hoijui> why do you get ../ added, jk?
<jk> ../ check recursively!
<hoijui> do you have the 3 dirs in ../ that it checks for?
<hoijui> mmm...
<jk> e.g. ../spring.gir/games/*.*
<hoijui> hae?
<jk> it won't check spring.git nor will it spring.git/games
<jk> it will just check ../games etc.
<hoijui> yes.. but only if they exist
<hoijui> which should not be the case in current one dir setups on windows
<jk> ?
<hoijui> i mean:
<hoijui> it checks if ../games ../maps and ../engines exist
<jk> the archivedirs of the curdir are totally ignored! Always!
<hoijui> if so, then it adds ../ as data-dir
<hoijui> otherwise ./
<hoijui> ah..
<hoijui> so i made a mistake then :D
<jk> ^^
<zerver> Ôû╝
<hoijui> but i can not see why
<hoijui> it does not work as i explained it?
<hoijui> damn.. i fail at most simple if else-if stuff already
<hoijui> its this btw: https://github.com/spring/spring/commit ... er.cpp-P36
<jk> erm isn't FileSystemHandler VFS?
<jk> you should just check the raw fs
<hoijui> it is raw FS
<hoijui> so you say, it does add ../ for you on windows?
<jk> linux
<hoijui> ok
<hoijui> mm
<jk> hah dd_curWorkDirParent is empty
<hoijui> but can you explain how?
<hoijui> ah :/
<zerver> hm
<hoijui> now i am even more confused
<jk> so you should invert the if-clause for safity
<jk> replace (dd_curWorkDirParent != "") && LooksLikeMultiVersionDataDir(dd_curWorkDirParent)
<jk> erm
<jk> no
<hoijui> :/
<hoijui> both these conditions should be false, right?
<jk> the "} else if (IsPortableMode()) {" is wrong!
<zerver> no, empty parent is fail
<jk> if dd_curWorkDirParent.empty() it should ALWAYS add ./ to the datadirs
<hoijui> no
<jk> not only if portable is enabled
<hoijui> portable means, unitsync and spring binary are in the same dir
<hoijui> that is nothign new
<hoijui> wihtout this, unitsync and spring will have different set of data-dirs, which is fail
<jk> not the case here
<zerver> u can revert and use my version, im pretty sure it works :P
<jk> it is the cmake builddir
<jk> and I always run "make spring"
<hoijui> zerver, i gave a lsit of issues with your solution.
<jk> adding ./ has nothing to do with unitsync location imo ...
<zerver> i dont care which one, but it must work
<hoijui> what i say is, that IsPOrtableMode() is nothgin new.. it was so before.. is evne in current release
<hoijui> it has someting to do with taht
<hoijui> we did not do that check in hte past
<hoijui> and had issues with it
<hoijui> i dont get what you want to say with:
<hoijui> [23:00:32] <jk> it is the cmake builddir
<hoijui> [23:00:40] <jk> and I always run "make spring"
<jk> I have /home/../spring.git/ as my cmake builddir
<jk> and I run spring from it
<hoijui> ok...
<jk> and added links to my map/mod archives in that dir too
<hoijui> my build dir contains both spring and libunitsync.so
<hoijui> so it adds the ./ dir as data-dir
<hoijui> i think.. that shoudl also be the case for you
<hoijui> you do not have them both in hte same dir?
<jk> erm ... GetParent() expects an absolute path!
<jk> your input is relative
<jk> and I obviously start spring with "./spring"
<jk> so the path is "./"
<jk> GetParent("./") == "."
<hoijui> ah
<zerver> fail
<zerver> ././././spring
<jk> we really need a clean interface to cleanup such paths
<hoijui> ?
<hoijui> you mean.. cleanupt the filesystem classes?
<hoijui> cleanup*
<jk> it is a never ending issue with those (the whole VFS is dumped with these)
<hoijui> and the solution here is, having a GetParent that works wiht relative paths?
<hoijui> or make the path absolute first?
<jk> all over the engine raw paths are used
<jk> instead we need a path class which auto translate to absolute etc.
<jk> to prevent adding/loading files duplicated
<hoijui> mm..
<jk> e.g. we need a function to check if two paths are pointing to the same file
<jk> but this still doesn't explain why my paths were added before and now they aren't
<hoijui> yeah true :D
<zerver> before the path was "./" and now it is ""
<hoijui> no.. what was ./ before is still ./ now
<hoijui> what shoudl be ../ is ""
<jk> adding a AddDirs(dd_curWorkDir); outside of the if-clauses helps
<hoijui> but it shoudl wall through, IsPortableMode should return true and add ./
<hoijui> ok :/
<hoijui> so IsPortableMode returns false?
<jk> yup, no unitsync
<jk> or wai
<jk> not true, I got a unitsync
<hoijui> :/
<hoijui> and that functions did not change..
<zerver> use gdb ffs
<hoijui> i bet he already does
<hoijui> :O
<hoijui> ;-)
<jk> gdb?
<hoijui> :D
<jk> never learned to use haltpoints in gdb
<jk> I am using logOutput.Print
<hoijui> :D
<hoijui> use ddd!
<zerver> lol
<hoijui> you can just doubleclick on hte linenumber
<jk> ddd?
<hoijui> to add a breakpoint
<hoijui> yes
<hoijui> emerge -s ddd
<hoijui> simple GUI for gdb
<hoijui> ddd spring
<jk> erm
<jk> dd_curWorkDir '/home/jk/spring.git/'
<jk> dd_curWorkDirParent ''
<jk> >>>>>>>>>>>
<hoijui> mmm :/ ok
<hoijui> get parent is fail then
<hoijui> but still does not explain
<jk> so GetParent is differently broken
<jk> and it finds the unitsync
<jk> ah wait
<jk> GetParent might be broken cause of a local change
<jk> k found a typo in GetParent
<hoijui> good :-)
<hoijui> now.. everything works perfect again?
<jk> O_O
<jk> now it is added
<hoijui> mm :/
<zerver> oh lol
<jk> there must be a gremlin in my computer
<hoijui> :D
<jk> still I found a bug in GetParent this way
<hoijui> yeah.. at least that :D
<hoijui> next then?
<jk> yeah, next
<hoijui> well.. i wanted to talk about KAIK stuff but ... as Kloot seems not to be present.
<hoijui> that makes no sense
<hoijui> weil discuss it in github comemnts
<hoijui> will*
<hoijui> we seems to be very busy since some weeks
<hoijui> cant remember a commit from him, or beeing in a meeting for real
<hoijui> anythign else?
<tobi> on the tools front, a random tip for anyone who still uses grep: use ack
<hoijui> never heard of :D
<jk> yesterday he made 2 maginal ones
<hoijui> ah yeah .. that about KAIK
Post Reply

Return to “Meeting Minutes”