Dev Meeting Minutes (2011-01-17)

Dev Meeting Minutes (2011-01-17)

Minutes of the meetings between Spring developers are archived here.
Post Reply
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Dev Meeting Minutes (2011-01-17)

Post by jK » 18 Jan 2011, 19:55

Date: 2011-01-17
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.
0 x

User avatar
MidKnight
Posts: 2650
Joined: 10 Sep 2008, 03:11

Re: Dev Meeting Minutes (2011-01-17)

Post by MidKnight » 18 Jan 2011, 20:05

Ooh, yay! Another one of these!

I miss the conclusions section after each topic, though.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev Meeting Minutes (2011-01-17)

Post by AF » 18 Jan 2011, 22:43

That waterfall page is bugged, the padding/margin around the iframe is causing the main viewport itself to scroll, resulting in a double scrollbar. It may not happen under some browsers, but an easy fix is:

Code: Select all

<body style="margin:0;">
since thats going to fail anyway under iOS and other touch interfaces, I reccomend replacing the whole page with a php redirect to http://springrts.com:7778/waterfall
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6109
Joined: 29 Apr 2005, 01:14

Re: Dev Meeting Minutes (2011-01-17)

Post by FLOZi » 18 Jan 2011, 23:39

Good to see hang detection issues being addressed. :-)
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev Meeting Minutes (2011-01-17)

Post by AF » 19 Jan 2011, 00:19

The loading screen isn't the only time that hang detection might trigger a false positive. Feature placer on a machine under load triggers it, as would a lengthy first intialisation of an AI
0 x

User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev Meeting Minutes (2011-01-17)

Post by lurker » 19 Jan 2011, 00:23

If you put in something to reset the loading timer, it should be usable by non-spring code. LogOutput, for example, but hidden effects are a bit unsavory.

Firefox extensions and Opera can do auto refresh pretty easily, building it into the page could get annoying.
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: Dev Meeting Minutes (2011-01-17)

Post by smoth » 19 Jan 2011, 03:03

Ca's icon generator also can easily trigger hang detection when doing a buildicons all

Undesired trigger or there is an issue with the operations in the gadget?
0 x

User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev Meeting Minutes (2011-01-17)

Post by lurker » 19 Jan 2011, 05:24

Undesired.
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: Dev Meeting Minutes (2011-01-17)

Post by smoth » 19 Jan 2011, 06:59

AF wrote:The loading screen isn't the only time that hang detection might trigger a false positive. Feature placer on a machine under load triggers it, as would a lengthy first intialisation of an AI
Just pointing out that the feature placer thing was addressed in the meeting.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Dev Meeting Minutes (2011-01-17)

Post by jK » 19 Jan 2011, 08:51

smoth wrote:Ca's icon generator also can easily trigger hang detection when doing a buildicons all

Undesired trigger or there is an issue with the operations in the gadget?
lurker wrote:Undesired.
Not true, in this case it is desired. The gadget renders a lot of images in one videoframe and so it cause a huge lag (upto 30mins!!!). And for this case the watchdog is written (detecting neverending loops), excluding lua from it is a very bad idea imo.
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: Dev Meeting Minutes (2011-01-17)

Post by smoth » 19 Jan 2011, 09:00

so how can I run the icon generator? what patch should be done to it?
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Dev Meeting Minutes (2011-01-17)

Post by jK » 19 Jan 2011, 09:26

Afaik you shouldn't need to do anything. The watchdog just prints the stacktrace(s) in the infolog.txt. But it doesn't halt the program or anything like that. It's just informative and not executive.
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev Meeting Minutes (2011-01-17)

Post by zerver » 19 Jan 2011, 17:12

Assuming it is bug free, the hang detection is cosmetic only. Maybe the clear watchdog timer function should be exported to Lua?
0 x

User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev Meeting Minutes (2011-01-17)

Post by lurker » 20 Jan 2011, 04:09

From spring's current point of view, yes it is hung. I didn't mean to say it shouldn't trigger in the current version. But the fact of the matter is that it's not hung. It's slow. The gadget should be able to reset the watchdog after each unit gets processed.



Huh, somebody told me that hang detection aborted things. Good to know that wasn't true.
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14606
Joined: 17 Nov 2005, 02:43

Re: Dev Meeting Minutes (2011-01-17)

Post by Forboding Angel » 20 Jan 2011, 08:29

lurker wrote:Huh, somebody told me that hang detection aborted things. Good to know that wasn't true.
No, but it causes whatever is happing to happen 3x as slow, which is not cool.
0 x

User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev Meeting Minutes (2011-01-17)

Post by lurker » 20 Jan 2011, 19:08

You're telling me that dumping a stack trace makes it take three times as long to complete?
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14606
Joined: 17 Nov 2005, 02:43

Re: Dev Meeting Minutes (2011-01-17)

Post by Forboding Angel » 21 Jan 2011, 08:40

In my experience, when hang detection triggers, it slows everything down to a crawl for a while until it gets done doing it's thing, and then goes back to normal... sort of.
0 x

zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev Meeting Minutes (2011-01-17)

Post by zerver » 21 Jan 2011, 23:36

The thread will be suspended during stack trace output, this is required. So a short pause, yes, and it may trigger once every 10 seconds by default.
0 x

User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev Meeting Minutes (2011-01-17)

Post by lurker » 22 Jan 2011, 05:24

But that's spring locking up entirely for fraction of a second. Not slowdown. Things should be 100% speed for ten seconds, single stutter, 100% speed for ten seconds, single stutter, 100% speed for ten seconds.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Dev Meeting Minutes (2011-01-17)

Post by AF » 22 Jan 2011, 15:11

Whereas in the tests where the old versions of featureplacer triggered hang detection, the frame rate went down during triggering, and stayed down at a near unplayable frame every 4-6 seconds, and stayed down indefinitely despite featureplacer having stopped.
0 x

Post Reply

Return to “Meeting Minutes”