Present: zerver, jK, abma, Kloot
_Agenda_____________________________________________________________________
- Release plan
- how to continue with the nsis-installer?
- Use "safe" vector for Command.params? (mantis 2193 et al)
- Chained eventHandler calls (MT issue)
- next scheduled engine version will still be based on the 0.82 branch
- current NSIS installer is becoming too bloated & hard to maintain
- abma will try to provide a release through his customizable online installer
<abma> hey!
<Kloot> hi
<abma> kloot: thanks for the fixes
<abma> i couldn't test it yet, i've only a ultra-slow faulty mac
<Kloot> np
<abma> jk is in etherpad...hm
<Kloot> he's on the lobby server too
<Kloot> maybe just busy
[21:14:02] ** jK joined the channel
<abma> hey jk!
<zerver> hi
<jK> hi
<abma> so... start?
<Kloot> sure
<abma> sorry for moving my topic on top, i'm short in time today :-/
<abma> so, who makes minutes?
<Kloot> I'll do them
<abma> thanks
Release plan
<abma> anything new about that? afaik not...
<jK> we would need a check list for that
<jK> I know that the ZK devs claim a lot of bugs in the current release
<abma> like: critical bugs fixed?
<jK> but I don't know which exactly
<Kloot> so would this be 82.8 or 83.0?
<jK> still 82
<jK> 83 is far far far away
<Kloot> hmm
<jK> there are soo many issues in the current master ...
<zerver> orly?
<jK> yup :p
<abma> hmm, the bug tracker says no
<abma> would it make sense to make a "alpha release" from master?
<Kloot> are all those issues on mantis? or does that also include non-documented ones?
<jK> dynamic sun is broken (terrain is too dark & it is always in dynamic mode) and I still have the feeling that the exception is still broken
<zerver> you mean the thread exception stuff?
<jK> duno if it just happens in other threads than the mainthread
<jK> need to test it
<jK> just had multiple cases where it hard crashed in exceptions
<abma> that means, no stacktrace? (only with attached gdb)
<zerver> when i tested dynamic sun it looked fine
<jK> for all others it doesn't
<jK> (known from me, licho & gf)
<abma> zerver: how to test it?
<Kloot> that reminds me, dynsun needs to be disabled for arb-only clients (because it does not update the shading tex)
<zerver> just run the master build?
<abma> ok
<abma> what needs to be enabled that it works?
<zerver> nothing, i put it on by default
<abma> if low graphic settings because i've on a slow ati
<jK> I would say dynsun is still in early development stage
<abma> i ask so stupid, because it was a bit dark, too
<jK> that's why I didn't reported the issues
<jK> (thought you were still working on it)
<zerver> so its extremely dark terrain or?
<jK> not extremly just 50%
<zerver> kk will check it
<abma> tomorrow i can make some screenshots
<abma> + test a bit
<abma> hm... for a testing-release, maybe a new build would be enough?
<abma> + make a news post?
<zerver> dynsun is easier to see if you put shadows on
<Kloot> yeah, would be a good idea to get more early feedback
<zerver> or crank up the game speed, because sun motion is pretty slow
<abma> zerver: this hints will help :) what about the dynamic lightning?
<abma> is that video from you? http://www.youtube.com/watch?v=H5je8TKDfNA
<jK> it should be disabled by default (and reallyu disabled with zero workload), and only enabled by the map/mod
<abma> if so, how to test + enable that?
<Kloot> that is my video
<Kloot> you'd need to write a gadget if you want to test it
<zerver> yeah, maybe should be disable by default
<zerver> need to fix bugs first though
<abma> ok
<zerver> dynamic lighting has the sun defined as a static light?
<zerver> if so, that needs to be fixed for dynsun too
<Kloot> no, DL simply doesn't touch light0 or light1
<zerver> ah
<zerver> next?
<abma> yep...
how to continue with the nsis-installer?
<jK> :<
<abma> hm?
<jK> hope hoij still finds some source of motivation to continue
<abma> i hope so too
<zerver> yeah
<abma> hm... ok: the current installer imo is in a stage where it is getting a bit unmaintable, it adds files with *.* and some remove-commands (on uninstall) do that, too
<abma> that is really ugly, for example, if you install spring: configure some stuff in the AI/ directory and uninstall it.. all files will be removed
<abma> to fix that, most parts of the installer have to be changed
<zerver> i have never uninstalled spring
<abma> don't do that
<zerver> so i have no opinion really :)
<abma> hm.. i try to make it short
<abma> i've written an online-installer that can be customized by some text-files
<abma> my suggestion is, to leave the old installer as it is and use the new installer in parallel for the next releases
<abma> it is so written, that if the files are fetched once, they are stored in a subfolder and won't be refetched
<jK> stored where?
<abma> <installer exename> - files\<download filename>
<jK> bad idea
<abma> in the same folder where the installer was downloaded
<jK> you normallu expect that installers don't touch the current folder
<jK> e.g. many ppl download it to the desktop and run it from there
<abma> then use temp?
<jK> better :)
<abma> ok, thats really easy to change...
<jK> does it support already all the features from the old one? e.g. running external installers (needed by zk lobby)
<abma> yep... i hope i missed none
<jK> nice :D
<abma> in general i want to remove the generationg of the installer from the buildbot and make it more external
<abma> with added features, so the game-devs + lobby devs can use it
<jK> we use the buildbot for release builds
<zerver> noobs must not be allowed to give up on spring and uninstall
<jK> lol
<abma> :-D
<zerver> so we make a shortcut to spring.exe and disguise it as uninstaller
<jK> you sound like Licho >_<
<zerver> :)
<abma> maybe as april-fool...
<zerver> uninstaller runs: spring.exe --noob-friendly-mode
<Kloot> that's a script to a BA8v8DSD game right?
<zerver> yes, instant
<abma> hm... then i try to make something like a release for this installer and get more feedback
<zerver> sure
<abma> than thanks
<abma> next point?
<zerver> we should thank u, provided that it works
Use "safe" vector for Command.params? (mantis 2193 et al)
<abma> + sorry i've to leave soon
<zerver> i thought a vector that allows access out of bound would be good until this issue is fixed
<zerver> it return 0 when command.params[x] is out of bounds
<jK> I would prefer a OOP approach
<zerver> and when you assign out of bounds nothing happens
<jK> like cmd.GetParam(1)
<abma> sorry, bye :-/
[22:05:26] ** abma left the channel
<zerver> and in both cases prints a stack trace
<zerver> https://github.com/spring/spring/commit ... dfbc9c2877
<zerver> yeah, GetParam or whatever, but that requires lots of files to be changed
<jK> but may be faster and more general solution
<jK> e.g. you could check the type when setting the params
<jK> so when too less params are set for a type -> throw error
<jK> so handling the error on write instead of on read
<zerver> yeah
<zerver> do you want to do that now, or shall we put this safe_vector in master as an intermediate solution?
<zerver> performance wise it is maybe 4 instruction instead of 2 per access
<jK> give me one week
<zerver> sure
Chained eventHandler calls (MT issue)
<zerver> in MT branch there is now one mutex per lua_State
<zerver> this is needed to reduce the slowdown problem with lua rendering
<zerver> but makes deadlocks like this:
<zerver> Script.LuaUI.XXX: LuaRules -> LuaUI
<jK> why is that a deadlock?
<zerver> and then LuaRules --> LuaUI by other thread:
<zerver> CEventHandler::DrawScreen -> LuaUI -> LuaOpenGL::DrawMiniMap -> CMiniMap::DrawForReal -> CEventHandler::DrawInMiniMap -> LuaRules
<zerver> so there is a chain of two eventhandler calls
<jK> how is that a problem?
<zerver> one thread locks LuaRules -> LuaUI and the other one LuaUI --> LuaRules
<jK> recmutex?
<zerver> yes all mutexes are recursive
<jK> so this shouldn't lock?
<zerver> if one thread locks A-->B and the other B-->A then we have a deadlock
<jK> why does it lock the other one?
<jK> and what is run in what thread?
<jK> you just showed the event queue, no the threads they are running in
<jK> *not
<zerver> does not matter but Script.LuaUI that has to be sim thread right
<zerver> and the other one is draw thread then
<jK> does it?
<zerver> CEventHandler::DrawScreen, obviously draw thread
<zerver> only way to solve this that i can think of is to limit the eventhandler chain
<jK> starting from begin, you have: (unsynced)LuaRules -> Script.LuaUI -> gl.DrawMinimap(in LuaUI) -> DrawInMiniMap(unsynced LuaRules)
<zerver> no
<zerver> one thread: (unsynced)LuaRules -> Script.LuaUI
<zerver> second thread: CEventHandler::DrawScreen -> LuaUI -> LuaOpenGL::DrawMiniMap -> CMiniMap::DrawForReal -> CEventHandler::DrawInMiniMap -> LuaRules
<jK> ah
<jK> :D
<jK> yeah, you need a queue for that
<jK> so only lock if at top of the queue
<zerver> queue in which thread?
<jK> shared
<zerver> i thought of disallowing eventhandler chains altogether
<jK> disallowing and then what?
<jK> no gl.DrawMiniMap?
<jK> -> no solution
<zerver> so if eventhandler invokes LuaUI and then LuaUI calls eventhandler again, then no other LuaHandles than LuaUI will be invoked
<jK> causing even more problems
<jK> a mutex queue is better
<zerver> luckily i think DrawMiniMap is one of the few calls that have this problem
<jK> UnitCreated and many other events?
<jK> near all synced events can cause such chains
<zerver> i didnt experience any deadlocks with those
<jK> but they are possible trust me
<jK> a mutex queue should be the work of 3h
<zerver> you have any links where i can read on that?
<jK> hmmm after further thinking it wouldn't solve the problem
<jK> but there are 2 other ones
<jK> 1. making Scruipt.LuaUI an event
<zerver> does it not return anthing to the caller?
<jK> 2. splitting the events for each eventClient (so the LuaRules-DrawInMinimap event would be moved after the Script.LuaUI)
<jK> no Script.LuaUI doesn't support data sharing
<zerver> ok
<zerver> then 1 is best i think
<zerver> i have nothing more
<jK> I have a request :D
<jK> regarding this commit: "move Sound* to its own namespace for #2342" by Kloot
<jK> Could you revert it? and just rename SoundSource to CSoundSource? I am currently working on the code, also the commit is quite a mess into my mind
<zerver> now i realize that my threaded luaui fails, because it disables all the batching you suggested, darn it
<zerver> so those deadlocks will be all over
