Present: abma, zerver, hoijui, Kloot, Tobi
Missing: jk
_Agenda_____________________________________________________________________
- Welcome
- Release plan
- repatched current Lua to fit into spring with some fixed bugs; merge?
https://github.com/abma/spring/tree/lua-update
http://www.lua.org/bugs.html#5.1.4 - SDL_XXX in main thread
- merge lua split?
- does anyone know a nice duplicated code finder for C++?
https://secure.wikimedia.org/wikipedia/ ... code#Tools - possible bug in lua usage?
http://www.lua.org/manual/5.1/manual.html#7.3
https://github.com/spring/spring/blob/m ... le.cpp#L71
luaL_checkudata was/is used too - remove AI-project from mantis + add AI-category to spring?
- remove lobby-project from mantis?
- Next meeting
- Anything else? (WVTTK)
_Release plan_______________________________________________________________
<hoijui> Kloot, you saw the comments on github?
<Kloot> no
<Kloot> ok, read them
<hoijui> yeah.. so.. i would be glad if you could port these two commits
<Kloot> sure
<hoijui> thanks :D
<hoijui> i would only screw up anyway
Conclusions
- Kloot will merge his two commits into the release branch (done)
_repatched current lua to fit into spring with some fixed bugs; merge?______
<hoijui> so i guess first question is:
<hoijui> why should we want new lua
<hoijui> and second, if this is done right
<zerver> to remove hacks/workarounds in current code?
<abma> it's not new, it is repatched from "ground"
<abma> yep... thats the idea
<abma> to allow easier updating in the future
<Kloot> what hacks?
<hoijui> with this patch, it is more similar to the official lua release?
<zerver> jK did some hacks with lua GC start/stop iIRC, that should be removed if possible
<Kloot> those are in LuaHandle
<zerver> RunCallIn maybe
<Kloot> yes
<abma> the lua currently in spring should contain this bugs: http://www.lua.org/bugs.html#5.1.4
<Kloot> but how would a new lua version be able to remove the need for that?
<zerver> yeah, RunCallInTraceback it seems
<zerver> bugs fixed?
<abma> yep...
<hoijui> i noticed a lot of "possible memory loss" reports in string related lua functions when running spring in valgrind
<hoijui> so benefits are:
<hoijui> * possibly fixed memory-leaks
<hoijui> * easier upgrading to future lua releases
<hoijui> reasons not to upgrade?
<zerver> new bugs?
<hoijui> mmm
<zerver> don't try to fix it if it ain't broken
<hoijui> yeah.. though as said.. it seems to be broken (memory leaks)
<zerver> yeah, there definitely are some probs
<hoijui> even though it is nothing urgent
<hoijui> are all the changes contained within rts/lib/lua/ ?
<hoijui> i mean.. if so.. it should be easy to revert, in case we find problems
<zerver> i vote to upgrade lua until it works perfectly, then no more upgrades unless they announce "100% performance gain" or something incredible that we must have
<abma> yep, all is in rts/lib/lua
<hoijui> ok
<hoijui> so i guess thats +3 from abma, zerver and me so far
<hoijui> Kloot, Tobi?
<Kloot> I don't mind (so long as all spring-specific necessary changes have been reapplied of course)
<abma> yep, they have... and it seems to work... but i did only ehm... a generic test
<abma> run BA with some AI's
<hoijui> :D
<hoijui> maybe, test 2 more lua intensive mods
<hoijui> or.. lets do that when it is in master
<abma> i didn't want to waste more time if it won't be merged
<hoijui> i'll run it through valgrind
<abma> ok
<hoijui> hmm ok
<abma> than thanks
<abma> i will test it then more, if it really makes problems... revert
<hoijui> so.. you are free to merge then, i would say
<hoijui> mmm
<abma> ok, thanks, then next point
Conclusions
- abma will put new Lua patches into spring master (done)
- in case it cuases any problems, we will revert
_SDL_XXX in main thread_____________________________________________________
<hoijui> thats yours, zerver?
<zerver> yeah, we had this discussion about SDL_SetVideoMode that must be in main thread
<zerver> because single threaded load screen didn't work or whatever
<hoijui> i remember, we agreed to revert the separate thread for main
<zerver> yeah, but single threaded load screen problem was not related
<zerver> so I wonder, what other issues are there?
<zerver> if there are no issues, I wont revert
<hoijui> it hangs on exception
<zerver> ok
<zerver> i will have a look then
Conclusions
- zerver will try to fix hang on exception in spring master
_merge lua split____________________________________________________________
<hoijui> .. i have not tested it, and.. jk is not here :/
<zerver> great
<zerver> basically, only need to agree on the method used
<zerver> if there are some bugs, that is less of a problem
<hoijui> mm true
<zerver> it was only jK that didn't like my split, or was there someone else too?
<hoijui> yeah jk mainly
<zerver> a split in LuaHandle gives more flexibility, compared to a split in LuaHandleSynced
<Kloot> lets not start rehashing every argument when jK isn't here
<zerver> ok, so the rest of you have no opinion, or?
<zerver> all blank votes?
<Kloot> I do have one, which is
<hoijui> makes no sense to discuss without jk
<Kloot> that the way lua is integrated into the engine is complex enough with one ST code path
Conclusions
- postphoned till next meeting in which both zerver and jk are present
_does anyone know a nice duplicated code finder for C++?____________________
<hoijui> https://secure.wikimedia.org/wikipedia/ ... code#Tools
<hoijui> so there is a list in that wiki page
<hoijui> i updated it a few minutes ago
<hoijui> i tried to compile CCFidner for linux, but ... you don't want to try it
<hoijui> you need to get a zip, a 7z and a tar.gz
<hoijui> extract them in one dir
<hoijui> and then do a lot of manual edits in makefiles
<hoijui> it has no dependency checks
<hoijui> ... no go
<hoijui> so the question was more...
<Tobi> I made my own once but it's WinForms/.NET so it probably won't be better on linux (also it wasn't really advanced anyway)
<hoijui> has anyone of you used a duplicate code finder, or even a whole code-quality measurement suite or something, in a C++ project yet?
<hoijui> mm
<Tobi> not in a C++ project
<zerver> never
<Tobi> I know CCFinder was a popular one in a course on refactoring, but that was for Java
<hoijui> CloneDigger and ConQAT seem to be the best on the list for us, from my short readings
<hoijui> the first being simpler, the later being more of a suite
<hoijui> yeah.. CCFinder.. might have some nice algorithms, but if you see the page and docu.. it seems .. like old mans software
<hoijui> mm i guess i will try the two i mentioned then
<hoijui> next?
<hoijui> aehm...
<hoijui> abma, please use some meaningful titles for agenda entries
<abma> ehm...
<abma> gimme a sec :)
<hoijui> sure
Conclusions
- still no real candiadate for this task
- CCFinder is ugly to build on non-windows OS
- CloneDigger is Java & Python only
- ConQAT is too heavy & complex and failed miserably on my system (hoijui)
- rest on that list has no C++ support, is commercial or failes for other reasons
- find others! any suggestions?
_possible bug in lua usage?_________________________________________________
<abma> in the change-log of lua-API, there are some notes
<abma> http://www.lua.org/manual/5.1/manual.html#7.3
<abma> and we are using luaopen_debug(L);
<abma> + luaL_checkudata()
<abma> and we already have lua 5.1
<abma> IMHO 5.1.4 (but without the current patches)
<abma> i'm unsure if this could make some problems
<hoijui> you mean the "luaopen_* functions cannot be called directly, like a regular C function"?
<abma> they are there, but as the docu says, they shouldn't be called...
<hoijui> mmm
<abma> i got " PANIC: unprotected error in call to Lua API (attempt to index a nil value)" in combination with shrad
<abma> i didn't know, who i should ask...
<hoijui> this call is loading libL.so?
<Tobi> quite probably its fine as long as the lua stack is setup properly with the necessary arguments and the return values (if any) are popped off the stack
<Tobi> shrad?
<hoijui> Shard
<Kloot> that PANIC error just means some lua code was not pcall()'ed
<abma> Shard.. sorry
<Tobi> ah
<Tobi> yeah
<abma> yep, when i googled for that, i found that changelog, to not use luaopen_*
<Kloot> but in my experience it's quite unrelated to use of luaopen_debug
<abma> ok
<hoijui> well.. is there a short test to see if it makes a difference?
<hoijui> calling a lua script that calls this functions from lua?
<abma> yep, it is, i tried, but it made no difference
<Tobi> in that case setting up the stack properly should have the exact same effect
<Tobi> because Lua doesn't do more
<abma> ok...
<abma> i think we can go to the next point, sounds like its shard fault or an other problem...
Conclusions
- abma and AF will try to sort out this problem within Shard (done)
_remove AI-project from mantis + add AI-category to spring?_________________
<hoijui> hmm
<hoijui> yeah i agree.. the "projects" thing under mantis is kind of.. not nice.. or at least, does not fit us, the way we use it now
<abma> pro: category can be changed in mantis, project not
<abma> and it doesn't confuse reporters
<abma> con: hopefully no/few work
<hoijui> sometimes i see only AI bugs.. and i wonder why they are all on top.. until i realise i have the AI project set
<hoijui> or more likely, i have the engine project set, and wont see the AI reports
<abma> yep...
<hoijui> next to categories, there are also tags
<hoijui> but.. i guess categories are better for that
<abma> yes, better for search/filter/report i think
<hoijui> mmm
<hoijui> i guess the problem would be, .. how to do the change.
<hoijui> could imagine mantis has no nice way to convert project to category
<abma> sounds like a few sql-commands
<hoijui> mmm
<hoijui> :D
<hoijui> well.. Tobi?
<abma> uhh
<abma> there is a "move"...
<hoijui> i guess little mood for such things? :D
<abma> but this don't change category i think
<hoijui> yeah.. also, doing it for each report individually would not be nice
<abma> ehm
<abma> there is an "move all"
<abma> http://springrts.com/mantis/view_all_bug_page.php
<abma> bottom...
<abma> then just create the category ai
<abma> i would do it, but i can't
<hoijui> i think only Tobi can
<abma> then next, i'll talk to tobi?
<hoijui> ok
Conclusions
- meanwhile, this got fixed by abma
_remove lobby-project from mantis?__________________________________________
<abma> is this used any more?
<hoijui> Satirik is not using it?
<hoijui> if it is, then by him
<abma> ah, ok
<abma> then its fine
<abma> next
<abma>
Conclusions
- ask Satirik if he uses the (engine) mantis still for bug reports
_Anything else? (WVTTK)_____________________________________________________
<zerver> btw hoi, this hang on exception does not have to be solved by reverting the boost thread thing
<zerver> it has to be a programming error
<hoijui> yeah i can imagine it can be solved differently
<hoijui> i still do not think this separate thread move is good, but if you can solve this without a revert, we can probably wait with the revert till other problems come up
<zerver> just need a _CATCH_ALL wrapped around the extra thread, then pass that exception to the real main thread an let it throw it
<hoijui> isn't that done already?
<hoijui> wont that hide the location of the real exception?
<zerver> maybe is
<hoijui> i though this is meant to make exception/error handling better
<zerver> yeah, by giving the main thread a boost ID
Conclusions
- bla bla continuation from SDL_XXX in main thread