Present: abma, hoijui, jK, Kloot, Tobi
_Agenda_____________________________________________________________________
- what about the assimp branch?
- revert separate main thread
- disable hang detection by default?
- add <meta http-equiv="refresh" content="30" /> to buildbot's html page?
_Main Conclusions___________________________________________________________
- Hangcheck/Watchdog should be improved during LoadingStage
_The meeting________________________________________________________________
abma: hi! start meeting? :)
hoijui: yeah..
hoijui: hello!
hoijui: !ring
Tobi: hey
Kloot: hey
what about the assimp branch?
hoijui: thats from you, abma?
abma: yep
hoijui: spliff is from australia.. so not online now (sleeping i guess)
hoijui: i dont know his branch... he said it is ready?
hoijui: i though it needs testing still
abma: no, it's not ready
hoijui: ok
abma: but i only wanted to ask if you all know about it?
abma: as imo its very interesting for merging (if it works a bit better...)
abma: thats it from me for that point
hoijui: ok..
hoijui: you also mention..
hoijui: we may try to not change parts of the codes it relies uppon to much
abma: yep, try to avoid big changes to allow easier merging, if possible
hoijui: thats mainly rts/Sim/Models/ ?
hoijui: aehh.. no :D
hoijui: rts/Rendering/Models/ it would be
abma: if i look at the commits.. yep, there are most of the changes
hoijui: ok
hoijui: next then
revert separate main thread
hoijui: i am quite convinced by now, that the answer should be: yes
hoijui: as even the reason why we have it seems not to make sense
hoijui: reason: to be able ot catch exceptions
hoijui: we should catch exceptions in more local parts of the code, and even if we do not...
hoijui: we foudn out that it does more harm then good
hoijui: zerver, you here?
<< zerver left!
abma: hm, i would say, no :)
hoijui: doh!
hoijui: now.. did he leave cause he is mad?
hoijui: is anyone else against reverting? or better said.. lets vote for reverting:
hoijui: +1
abma: i would say connection problmes, but don't know
jK: he quit
jK: he didn't lost connection
abma: hm...let's see if he comes back
abma: ehm, before i vote... what is sperate from the main thread?
abma: afaik stuff like sdl_* functions?
abma: if it is so, some of the strange problems should be gone, like hang on start/exit in sdl_quitvideo(?)
hoijui: yes
hoijui: basically, everythign is in that thread
hoijui: its like:
abma: then +1 from me, as it seems to be the prefered way for the sdl_* stuff
hoijui: main() { runInThread(EVERYTHING); }
abma: ok..
hoijui: guess we'll go next, and if the same happens again next week ... we may decide wihtout zerver
disable hang detection by default?
hoijui: abma again?
Kloot: no, that is mine
Kloot: HD seems to generate far too many false positives
Kloot: fex when loading large maps, or Lua-heavy games
Kloot: so I'd like to default-disable it for release builds
hoijui: mm... i can't remember that we ever foudn a real problem wiht it since it is enabled by default
jK: it should really disabled for loadingstage
hoijui: that is a zerver thing agian though :/
Kloot: mantis 2295 is one example
Kloot: also http://springrts.com/phpbb/viewtopic.php?f=13&t=25129
Kloot: other reports here & there
jK: also the deadtime should be upped a lot (10s or something like that)
hoijui: it is 10s now
Tobi: isn't it a config setting?
hoijui: yes
hoijui: default is 10
hoijui: 10s
Tobi: that was set to 10ms or so for one release?
hoijui: yep
Tobi: so that implies theres a whole userbase for whom its set to 10ms
Tobi: as changes of default config values don't migrate to existing users
Tobi: or was that prevented someway?
jK: I assume so
jK: zerver used a strange system
jK: so the default value is 0 and if it is 0 then it sets the timeout to 10s
Tobi: ah ok, if it was always like that it would be fine
jK: afaik 90% of the incorrect positives are during the loadingstage
Kloot: unfortunately even 10s is too short for pathing calculations on maps > 32x32
jK: so imo, just disable it there
jK: it doesn't make sense to have it enabled during loadingstage
hoijui: so we vote?
jK: zerver isn't here ...
hoijui: mmm :/
jK: these stuff is his job
jK: (except kloot wants to fix it himself)
Kloot: zerver's motivation afaik was to find out when/where spring hangs for users during loading
Kloot: but this way the whole thing is not very useful
jK: then up the timeout time during loading to a insane high value?
jK: 180s?
Kloot: that was the plan yes
jK: hmm better 300s
jK: ah
jK: it also has a design fault
jK: it doesn't reset the watchdog during the whole loadingstage at all
jK: instead it should reset it in loadscreen->SetLoadMessage()
jK: this way even pathing wouldn't be a problem
Kloot: yup
hoijui: as zerver is not here, lets go to the next (and last) topic. we can still discuss this later
add <meta http-equiv="refresh" content="30" /> to buildbot's html page?
abma: which one exactly? the waterfall?
abma: in general this could be very anoying if you can't switch it off
jK: how can it be annoying?
abma: if you scroll down and want to click somewhere and then comes the reload
jK: most of the time you wait that a compile is finished
jK: opera saves the scrollpos over a reload
abma: hm.. then why no irc-message?
abma: polling vs notify
jK: because of simplicity?
abma: afaik waterfall is a python script in the buildbot
abma: so changing that..hm
abma: [RoX]Tobi: afaik you did most config-stuff at the buildbot?
abma: http://buildbot.net/buildbot/docs/latest/IRC-Bot.html
abma: hm, i'm unsure if it still works: /msg BuildServ !notify
abma: ehm... ok this is the old buildbot
abma: *DONGDONGDONG* wake up guys, this is our last point
jK: I have zero knowledge of the buildbot, sorry
Tobi: waterfall is just default functionality in buildbot
Tobi: although probably I can customise the html somewhere if that is desired
Tobi: but I don't readily know how
abma: if that easy hack is enough? http://spring.abma.de/waterfall/
abma: maybe, the notify in chat is preferable...(if not to hard, to configure)
Tobi: I've had it before
Tobi: but only for IRC
Tobi: one reason I didn't really bother with it now is that it seems lobby is used more often for communication
hoijui: guess that is ok, as jk uses IRC too, and he is hte one that wants this
hoijui: mm
jK: IRC would be a lot spam
jK: except you limit it to failed builds
Tobi: in the past it never said anything unless you asked it to notify you
jK: yeah, but the old buildbot had a different usage
Tobi: I mean the old buildbot buildbot :)
jK: the notifying was there, so you download the build
jK: now the notifying is to notice failed builds
Tobi: ah config suggests that is possible
Tobi: suppose I can poke a bit at that if that is desired
hoijui: i consider this the end
Anything else? (WVTTK)
hoijui: ouh.. was there soemthign to be discussed between jk and kloot?
hoijui: related to what was going on on the git log
jK: sorry, but I can't live with unsynced data in synced context
jK: it is a nog-go
jK: *no-go
jK: and you always revert it over and over again w/o accepting that it is wrong
jK: sure GetUserMode was wrong but than 30% of the functions in the API are broken
jK: and need to be fixed and not reverted
Kloot: there is no more unsynced data in synced context!
jK: you still returned values in synced context
Kloot: read the code better
Kloot: all those functions have a if (synced || !fullread) { return 0; }
jK: then it is wrong, too
jK: synced should be able to write to unsynced data
Kloot: there is nothing to
Kloot: "write"
jK: "write" = ["set", "execute", "write"]
Kloot: and that makes no sense here since light handles are needed to do one of those things
jK: no, your system has a ttl
jK: so you don't need to access once created lights
Kloot: there is no logical reason why synced lua should be allowed to create-and-forget a light like that
jK: easier implementation of explosion lights?
Kloot: easier? just SetWatchWeapon and SendToUnsynced when the Explosion callin runs
jK: you would save the SendToUnsynced
Kloot: it's three lines max
jK: no, even the body of that is ~50 (with whitspaces)
Kloot: you need that for sending over unit &projectile id's anyway
Kloot: 50? have you written such a gadget already then?
Kloot: (I have)
jK: I wrote many gadgets, much more than you
jK: And my only interest is the consistence of the API
Kloot: then you should start by fixing all of the functions that check for usermode
jK: I will
Kloot: also how do you think declaring code broken and inserting your "fixes" into it without discussion that then introduce new bugs is interpreted?
Kloot: and out-of-the-blue changes like making arguments optional
Kloot: and as for consistency, having 10 functions related to topic X in an unsynced API of which 9 do nothing / silently fail when called in synced context but 1 leaves a side-effect (that synced doesn't know about) is inconsistent to the extreme
<< hoijui left!
<< Tobi left!
jK: you were the one who had it 100% in synced ...
jK: so don't come with such lame arguments
Kloot: I had it in synced to prevent an exploit, and repaired that another way
Kloot: after which _you_ broke it for unsynced luarules
Kloot: maybe try not to treat everyone as know-nothing amateurs when you don't know all the details yourself, and refrain from arguments like "I wrote many gadgets, much more than you"
Kloot: gn
<< Kloot left!
abma: good night!
<< abma left!
PS: "Sorry for dropping from the 17/1 meeting. All my networking equipment is located outdoors, and there was a sudden rain storm so I had to rush out and disconnect everything." from zerver.