#gemrb@irc.freenode.net logs for 7 Sep 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:42:02] <-- yyz has left IRC (Read error: Connection reset by peer)
[00:48:34] --> yyz has joined #gemrb
[01:18:20] <brad_a> illl probably have to come repost this tomorrow but http://dl.dropbox.com/u/13866402/fix-pack.patch
[01:18:37] <brad_a> should fix those few minor problems with my last set
[01:56:12] <-- xrogaan has left IRC (*.net *.split)
[01:58:11] --> xrogaan has joined #gemrb
[02:19:33] <brad_a> so the reason that mac hang never occurred before is because the music thread never got spawned (hence music not playing till my patch)
[02:20:08] <brad_a> the call to SDL_KillThread is what is hung
[02:21:08] <brad_a> from what i gather that means the thread has already terminated… not sure tho. but i have read that SDL_KillThread isnt a good thing to use to terminate a thread so maybe ill look into what the recomended alternative is.
[02:33:57] <brad_a> that was an easy one http://dl.dropbox.com/u/13866402/openalhang.patch
[03:41:34] <-- yyz has left IRC (Read error: Connection reset by peer)
[03:42:31] --> yyz has joined #gemrb
[04:22:01] <-- brad_a has left IRC (Quit: brad_a)
[04:26:03] --> brad_a has joined #gemrb
[05:58:42] <-- brad_a has left IRC (Quit: brad_a)
[06:12:51] --> brad_a has joined #gemrb
[06:13:30] <-- brad_a has left IRC (Client Quit)
[06:35:03] <fuzzie> re above: but now it doesn't wait for the thread to die
[06:41:05] <-- yyz has left IRC (Read error: Connection reset by peer)
[06:41:47] --> yyz has joined #gemrb
[07:32:46] --> Tching has joined #gemrb
[08:20:29] <Tching> Brad, I can confirm that http://dl.dropbox.com/u/13866402/openalhang.patch fixes the hang. Thanks!
[08:21:50] <Tching> It would seem to me that if you don't call SDL_KillThread you can get rid of the SDL_mutex stuff as well, don't you think?
[08:22:26] <fuzzie> the problem is, it's not a good fix
[08:23:57] <fuzzie> because you set stayAlive to false, you return, and then the thread crashes because you didn't kill it and it tried checking stayAlive..
[08:24:48] <fuzzie> in reality, the thread probably doesn't wake up quickly enough, and the KillThread is done by the OS when main() returns?
[08:26:05] <fuzzie> but it should be doing SDL_WaitThread before the SDL_DestroyMutex, I guess.
[08:26:41] <fuzzie> and in that case it is indeed a bit pointless to grab the mutex
[08:30:07] --> lynxlynxlynx has joined #gemrb
[08:30:07] <-- lynxlynxlynx has left IRC (Changing host)
[08:30:07] --> lynxlynxlynx has joined #gemrb
[08:30:07] --- ChanServ gives channel operator status to lynxlynxlynx
[08:33:34] <lynxlynxlynx> gmornin
[08:41:10] <Tching> I just added this line before the "return 0;" in OpenALAudioDriver::MusicManager:
[08:41:21] <Tching> printMessage( "OpenAL", "About to leave MusicManager\n", WHITE );
[08:41:40] <Tching> And I see that message on the console when I quit GemRB.
[08:42:02] <fuzzie> run it under valgrind?
[08:42:11] <Tching> So it would seem that the SDL_Thread just finishes on its own.
[08:42:27] <fuzzie> i mean, the stayAlive is set in the *destructor* of OpenALAudioDriver
[08:42:49] <fuzzie> so it can't possibly be valid at that point, and you're presumably just using a deleted object and it's working for you by coincidence
[08:43:14] <fuzzie> but valgrind should pick it up if that is the case.
[08:45:38] <fuzzie> or else just ask wjp to look at it and confirm if i'm mad or not.
[08:45:44] <fuzzie> in the meantime, i am off to uni.
[08:46:03] <Tching> What I'm saying is that you probably don't need to bother with the SDL_Thread in the destructor at all, but I'll look more closely at that.
[08:46:25] <fuzzie> the 'driver' must stay valid for the whole runtime of MusicManager
[08:46:43] <fuzzie> and so you must not return from the destructor until the MusicManager has returned, right?
[08:47:15] <fuzzie> otherwise you're just hoping very hard that it won't crash when it accesses the deleted driver object.
[08:47:24] <Tching> Right, but I'm guessing that MusicManager has already returned. But I can't be sure. I'll take a look at it.
[08:47:30] <fuzzie> ok. bbl!
[08:48:32] <Tching> I was wrong :)
[09:00:41] <-- Drakkar has left IRC (Ping timeout: 264 seconds)
[09:02:00] --> Drakkar has joined #gemrb
[09:35:46] <CIA-26> GemRB: 03lynxlupodian * r56083f18df7e 10gemrb/gemrb/core/GUI/GameControl.cpp: do not rotate single-actor formations
[09:35:47] <CIA-26> GemRB: 03brada * re9f73367525a 10gemrb/gemrb/core/GUI/GameControl.cpp:
[09:35:47] <CIA-26> GemRB: prevent mouse up from interacting with actors when rotating formation.
[09:35:47] <CIA-26> GemRB: Signed-off-by: Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[12:40:13] <-- yyz has left IRC (Read error: Connection reset by peer)
[12:40:58] --> yyz has joined #gemrb
[13:12:57] <-- yyz has left IRC (Quit: leaving)
[14:23:16] --- DrMcCoy is now known as DocMcCoy
[14:23:28] --- DocMcCoy is now known as DrMcCoy
[15:13:24] --> brad_a has joined #gemrb
[15:18:06] <CIA-26> GemRB: 03lynxlupodian * reef542373eff 10gemrb/gemrb/GUIScripts/pst/GUIREC.py: pst: added OnRecordsHelpStat to share some of the common code
[15:20:05] <brad_a> well i clearly dont have a deep knowledge of c++ so i didnt realize any of that invalid object destructor jargon before, but i did check the thread return and it did work but as you said i suppose just by coincidence. the documentation for sdl_killThread says this, however: "SDL_KillThread gracelessly terminates the thread associated with thread. If possible, you should use some other form of IPC to signal the thread to quit."
[15:22:16] <edheldil> 'gracelessly' as in 'disgracefully'? ;-)
[15:22:45] <brad_a> well clearly yes disgracefully on mac!
[15:23:53] <brad_a> im used to coding in objective c so the intricacies of constructors and destructors are foreign to me...
[15:26:04] <brad_a> also all this brought to my attention that gemrb handles quit via gui and quit from SDL_quit event diffrently
[15:26:12] <brad_a> but i dont know why
[15:27:22] <lynxlynxlynx> btw, now that rotation is fixed, you deserve commit access
[15:27:33] <lynxlynxlynx> it will also force you to sync more often :P
[15:27:45] <lynxlynxlynx> send your sf username to edheldil
[15:28:26] <brad_a> are you sure cuz i apparently dont understand c++ enough. obj-c has spoiled my with idiot proof threading etc
[15:28:30] <brad_a> but i will anyway
[15:29:04] <lynxlynxlynx> re above: sdl is no ninja, so i doubt it could do a graceful kill
[15:29:39] <lynxlynxlynx> yes, i asked avenger and he said you can get it if you do the formation rotation
[15:29:54] <brad_a> oh good cuz that really wasnt very hard
[15:30:06] <brad_a> compared to the stuff you guys do anyway
[15:32:09] <tomprince> Although commit access doesn't mean you need to not get review before committing.
[15:32:20] <brad_a> well i wouldnt dream of that
[15:32:33] <tomprince> I think you misread my comment.
[15:32:36] <lynxlynxlynx> when in doubt, ask
[15:32:43] <brad_a> always
[15:33:00] <lynxlynxlynx> usually me or fuzzie lurk here any given day
[15:33:56] <tomprince> And I tend to be here except in the summer. Although I haven't done much work on gemrb recently
[15:34:07] <lynxlynxlynx> tomprince: btw, i added a simple entergame test that could be used with the demo
[15:35:10] <lynxlynxlynx> heh, talking of ninjas: ninja: new spell, privilege escalation detection and prevention system
[15:35:18] <lynxlynxlynx> just got it in mail
[15:49:08] --> gembot has joined #gemrb
[15:52:40] <lynxlynxlynx> brad_a: another glitch, if you pause, the reticles are drawn under all actors (or on their target point if they're moving)
[15:53:14] <lynxlynxlynx> they should only be drawn for controllable characters when they have a goal
[15:53:26] <brad_a> speaking of did i somehow just export 1 patch to you? because there should have been 3
[15:54:36] <brad_a> 3 commits i mean not 3 patch set
[15:54:45] <tomprince> brad_a: Why don't you push to github or something? (fork fuzzie's repo)
[15:54:48] <lynxlynxlynx> you can check the controlable bit by comparing the actors IE_EA (needs to be lower than EA_GOODBUTRED )
[15:54:58] <lynxlynxlynx> brad_a: one commit was useless
[15:55:03] <brad_a> which one?
[15:55:15] <lynxlynxlynx> the one that was supposed to fix ordering
[15:55:49] <lynxlynxlynx> one patch i changed
[15:56:00] <lynxlynxlynx> one just so it would apply
[15:56:14] <brad_a> oh? did you fix that yourself? because if you have a party of say 6 and you select 4 then during rotation the reticles will be wrong even though on mouse up they go to the corect point
[15:56:20] <brad_a> oh
[15:57:38] <brad_a> I should push to github but why fork fuzzies?
[15:57:56] --> Maighstir has joined #gemrb
[15:58:41] <lynxlynxlynx> there's no official repo up there
[15:59:09] <brad_a> ah
[15:59:16] <lynxlynxlynx> re useless patch: no, didn't touch it
[15:59:28] <brad_a> then it should need to be applied
[15:59:53] <lynxlynxlynx> it does nothing
[15:59:54] <tomprince> fuzzies, since that is the root of the largest connected set of gemrb repos on github. :)
[16:00:54] <lynxlynxlynx> maybe you forgot to add something to that commit, but like it was, it is just a cosmetic index change
[16:01:52] <brad_a> no look closer :)
[16:02:34] <brad_a> idx gets incremented for each party member but the other gets incremented only for selected party members
[16:05:07] <brad_a> also about the one for disallowing single actor rotation the way mouse up is writted now allowing a single actor will send that actor to where mouse up happened and not the original point
[16:05:26] <brad_a> so either that needs to be applied or mouse up needs to be tweaked to allow single actors
[16:05:52] <lynxlynxlynx> i think that's fine
[16:06:01] <brad_a> oh then its fine :)
[16:07:14] <lynxlynxlynx> you're right about the former though
[16:07:53] <lynxlynxlynx> didn't see a difference, but it is better if things not work by accident
[16:08:23] <brad_a> i will fix the drawing for non controllable pcs tonight
[16:08:49] <lynxlynxlynx> you'll have a small nightmare once you wish to push, but that will just clean up your base
[16:09:03] <brad_a> yes i already have been though some of that
[16:09:53] <-- lubos has left IRC (Quit: Leaving.)
[16:09:54] <brad_a> since i was using spaces before i got a bunch of conflicts. my own fault tho. its the best way to make sure i stop doing that.
[16:12:45] <lynxlynxlynx> be careful if you have any unfinished stuff, since it likely won't apply anymore after the rebase
[16:13:28] <brad_a> not even if i stash it?
[16:13:54] <brad_a> i have a very good backup system at least
[16:14:13] <brad_a> it wouldnt be the first time ive had to recover the entire repo ;-)
[16:16:19] <edheldil> gtg. PM me, brad, if you want the access
[16:16:53] <brad_a> yeah im actually just havving a hell of a time getting a user name that isnt taken
[16:17:08] <edheldil> brad_a?
[16:17:25] <brad_a> taken :(
[16:17:37] <brad_a> oh wait
[16:17:44] <brad_a> no its just that it doesnt allow _
[16:17:47] <brad_a> so brad-a works
[16:18:02] <CIA-26> GemRB: 03lynxlupodian * r86181fe154ff 10gemrb/gemrb/GUIScripts/ (GUICommon.py GUIREC.py iwd2/GUIREC.py pst/GUIREC.py): GUICommon: added SetCurrentDateTokens and made use of it
[16:18:17] <edheldil> try 592d7965cbee71d02ffc094ff95ed62c, that's easily recognizable ;-)
[16:18:52] <lynxlynxlynx> 350c266bd9759f3928b674495abeed82e3d49bd0 is better
[16:19:22] <brad_a> ha ha no brad-a worked
[16:19:40] <brad_a> is that all you need?
[16:19:54] <lynxlynxlynx> blood sample
[16:20:25] <brad_a> how about a stoll sample instead ;-)
[16:20:30] <brad_a> stool
[16:20:32] <brad_a> whatever
[16:20:35] <brad_a> joke ruined
[16:24:03] <edheldil> just sign NDA and forfeit your human rights ;-)
[16:24:38] <lynxlynxlynx> haha, awesome idea
[16:24:47] <lynxlynxlynx> too bad april is so far away
[16:25:06] <lynxlynxlynx> "you need to sign this nda to work on our opensource project" xD
[16:25:49] <brad_a> if i sign in blood does thhat negate the need for a blood sample?
[16:28:03] <brad_a> not to derail the conversation about ownership of my eternal soul, but can somebody answer why gemrb handles quit via gui and quit from SDL_quit event differently.
[16:28:44] --> Yoshimo has joined #gemrb
[16:28:45] <lynxlynxlynx> via gui there are actually two quits
[16:28:54] * edheldil watches brad-a climbing the steep path to dark and forbidding gates of Commitkeep. Finally he stand in the shadow of the ancient portal and with a foreboding lifts the slime encrusted door handle and strikes the door. In a deafening silence which follows the deafening echo, a whispery voice hisses: "Access granted, my precioussss"
[16:28:58] <lynxlynxlynx> quit and quitgame in the bindings
[16:29:38] <lynxlynxlynx> i think quitgame is only needed if a game was already started/loaded though
[16:30:07] <lynxlynxlynx> no idea why quit and whatever calls sdl_quit differ though
[16:31:45] <gembot> build #179 of mingw32 is complete: Exception [exception clean build/build] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/179 blamelist: lynxlupodian@users.sourceforge.net
[16:32:02] <edheldil> later
[16:32:21] <Yoshimo> since when do we have a buildbot?
[16:33:28] <brad_a> yay im a made man 8)
[16:34:01] <brad_a> well i ask about the diffrence in quit because that sdl thread hang on quit is only happening when you quit from the gui
[16:34:40] <brad_a> when i quit the application via the menubar my wrapper catches that event cancels it and sends an sdl quit event instead but that does not hang
[16:39:04] <lynxlynxlynx> tomprince: http://buildbot.gemrb.org/builders/mingw32/builds/179/steps/clean%20build/build/logs/err.html is dead
[16:39:24] <lynxlynxlynx> Yoshimo: for a while, but it wasn't up all the time
[16:40:38] --> Avenger has joined #gemrb
[16:40:52] <Avenger> you can use sdl quit only if you have sdlvideo
[16:41:00] <brad_a> lynx i think you meant to commit the other patch and not the single actor rotate one
[16:41:12] <Avenger> i wonder if we"ll ever have other than sdl, though
[16:41:31] --- ChanServ gives channel operator status to Avenger
[16:41:36] <brad_a> yes thats true but doesnt that quit event just get passed to the core?
[16:41:45] <lynxlynxlynx> brad_a: i committed 2/3 of the patches
[16:42:08] <Avenger> what quit event?
[16:42:09] <tomprince> lynxlynxlynx: that seems to be a buildbot bug, the link from the waterfall works.
[16:42:40] <brad_a> yeah but i dont see the one that fixes the reticle offset during actuall rotation. i know mouse up is fine. but try selecting 4 of 6 party members and rotating and you will see what i mean
[16:44:04] <tomprince> I seem to be very good at triggering buildbot bugs. :)
[16:44:16] <brad_a> wait i guess i misunderstood sdl quit i thought it was an event you could get in poll events
[16:44:43] <brad_a> oh it is but it just doesnt do anything
[16:45:02] <brad_a> ah so i can implement that to do what the gui quit is doing i guess
[16:46:20] <Avenger> can you also display a popup :)
[16:46:37] <brad_a> indeed i can
[16:47:05] <brad_a> thats kinda where im going because i hate accidently quitting in the middle of a game
[16:47:12] <Avenger> with a game specific string !
[16:47:23] <brad_a> ?
[16:47:28] <brad_a> i dont follow
[16:47:46] <Avenger> the popup displays a string 'like boo will miss you'
[16:47:53] <Avenger> it is game specific
[16:48:16] <brad_a> oh i see
[16:48:18] <Avenger> add the string to strrefs.h
[16:48:23] <Avenger> it is good practice :)
[16:49:26] <brad_a> so should an sdl quit event jsut call core->QuitGame?
[16:49:57] <brad_a> that doesnt appear to do any popups or anything and just quits so probably not
[16:50:16] <Avenger> well, if Interface->QuitFlag|=QF_QUIT is not enough
[16:52:48] <lynxlynxlynx> brad_a: yes, so just commit the third
[16:52:54] <Avenger> or rather core->QuitFlag=QF_QUITGAME|QF_EXITGAME
[16:53:48] <brad_a> to push just a single commit do you do git push origin/master shaofcommit?
[16:54:13] <lynxlynxlynx> i don't think you can limit it
[16:54:30] <lynxlynxlynx> ok, maybe if it is at the bottom end
[16:55:04] <tomprince> You need to make sure that the commit has the right parent
[16:58:18] <brad_a> im not sure i know git well enough ATM.
[16:58:57] <tomprince> Try running gitk
[16:59:17] <lynxlynxlynx> if you branch off at the current origin tip (what i committed), cherry-pick the commit there and push from there, it will be dine
[16:59:22] <lynxlynxlynx> fine
[16:59:51] <brad_a> hang on i just pull another conflict i need to resolve
[17:02:20] <tomprince> brad_a: http://progit.org/book/
[17:02:49] <brad_a> thank you :)
[17:03:27] <brad_a> i hope that makes more sense then the man pages as they expect you to know certain things i dont
[17:05:11] <brad_a> lynx that conflict is because im checking taget_mode in rigth button down but that isnt in the origin
[17:05:19] <brad_a> is that not nessicary for some reason?
[17:05:33] <brad_a> because if you are targeting right click should cancel that
[17:05:41] <brad_a> and do only that and not do both
[17:07:20] <lynxlynxlynx> it needs to cancel for a single actor too
[17:08:14] <lynxlynxlynx> ammend as you see fit
[17:08:20] <brad_a> yes sir
[17:09:40] <brad_a> im late for a meeting. ill be back on later
[17:09:49] <-- brad_a has left IRC (Quit: brad_a)
[17:15:40] --> Demitar has joined #gemrb
[17:22:23] <-- Drakkar has left IRC (Ping timeout: 260 seconds)
[17:22:40] <tomprince> brad_a: http://lostechies.com/jasonmeridth/2010/04/05/quot-pro-git-quot-cliff-notes/
[17:23:46] --> Drakkar has joined #gemrb
[17:52:45] <CIA-26> GemRB: 03lynxlupodian * r0ee8c7525d48 10gemrb/gemrb/GUIScripts/ (GUIREC.py pst/GUIREC.py): a few guirec improvements common<->pst
[18:05:55] <-- Avenger has left IRC (Quit: ChatZilla 0.9.87 [Firefox 6.0.1/20110830092941])
[18:08:29] <-- Demitar has left IRC (Ping timeout: 245 seconds)
[18:22:15] --> brad_a has joined #gemrb
[18:39:53] <brad_a> im guessing the reason we are using sdl threads in the openal driver is because there isnt a good cross platform alternative?
[18:40:40] <brad_a> i see its on the list to remove SDL dependancy from openal...
[18:44:44] <brad_a> fuzzie: would replacing the mutex + sdl_killthread with stayalive = false + sdl_waitThread work?
[18:45:19] <brad_a> or is it just another coinciince that it always works flawlessly on my system?
[18:45:19] --> edheldil_ has joined #gemrb
[18:50:34] <fuzzie> brad_a: well, that is what i suggested in backscroll :)
[18:50:49] <fuzzie> and yes, there's no good cross-platform alternative that doesn't drag another dependency in, i think
[18:51:13] <brad_a> ah so you did! well then i will do that :)
[18:51:19] <brad_a> as for alternative
[18:51:51] <brad_a> couldnt we use macros to use pthreads unless pthreads arent available then drag in the sdl dependancy?
[18:53:09] <brad_a> i realize im largely ignorant of cross platform development but dont most platforms support pthreads? including windows?
[18:53:21] <fuzzie> they are *posix* threads, no win32 support.
[18:53:46] <brad_a> i thought windows had posix support. or is that only recently?
[18:53:48] <fuzzie> (specifically an extension of the original posix standard, so not even in the windows posix layer)
[18:54:00] <fuzzie> but the windows posix layer runs posix apps not win32 apps anyway
[18:54:14] <brad_a> yup thats me not knowing jack about windows
[18:55:01] <Yoshimo> i use it for ages but how can you ever understand that os? ;)
[18:55:29] <fuzzie> well this stuff is basically a historical mess which you don't want to know :)
[18:55:45] <fuzzie> but i think it just isn't worth the effort of #ifdeffing stuff until someone actually goes and implements a nice opengl backend
[18:56:16] <brad_a> yeah but the alternative to historical mess is apples approach of derpricating things and breaking legacy apps every major OS release
[18:56:31] <fuzzie> well, historical mess as in "80s government contracts"
[18:56:38] <fuzzie> as opposed to backwards compatibility :)
[18:56:45] <brad_a> ;-)
[18:59:15] <Yoshimo> the best thing is linux having to emulate bugs^^
[19:00:10] <Yoshimo> just because the mainboard and other hardware manufacturers only test with windows :P
[19:01:07] <fuzzie> the best thing about linux is not having to run it on hardware designed for windows :p
[19:01:44] <brad_a> ie on anything ;-)
[19:03:07] <Maighstir> Soon enough even ARM machines will be designed for Windows
[19:04:30] <brad_a> why do you say that? if you mean mobile anything then that is already true
[19:04:54] <Maighstir> No, Windows 8 will be available for ARM
[19:05:42] <brad_a> really? why? are netbooks moving to ARM or somethig?
[19:08:01] <Maighstir> Perhaps, also tablets. It'll also have a Windows Phone 7 like interface (as well as the normal desktop), so they'll likely discontinue Windows Phone, instead having Windows for ARM replace it.
[19:10:24] <brad_a> does Microsoft just choose not to support posix to maintain dominance or something stupid like that?
[19:11:10] <tomprince> backwards compatability and upgrade paths, for one thing.
[19:11:28] <tomprince> I have also heard that a number of their apis are saner than the posix equivalents.
[19:25:31] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[19:28:03] --> edheldil_ has joined #gemrb
[20:43:50] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:13:27] --> joneirik has joined #gemrb
[21:36:08] <CIA-26> GemRB: 03lynxlupodian * r340742e52d00 10gemrb/gemrb/ (2 files in 2 dirs): added a HasFeat guiscript function
[21:36:08] <CIA-26> GemRB: 03lynxlupodian * rbdebabd7866e 10gemrb/gemrb/GUIScripts/iwd2/GUIREC.py: iwd2: small improvements to the attack stat display
[21:36:08] <CIA-26> GemRB: 03lynxlupodian * r56571cd2bc5d 10gemrb/gemrb/GUIScripts/ie_feats.py: added ie_feats.py, a copy of ie_feats.h for guiscripts
[21:58:26] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:17:01] --> Maighstir_ has joined #gemrb
[23:17:35] <-- Maighstir_ has left IRC (Client Quit)
[23:20:11] <-- Maighstir has left IRC (Ping timeout: 252 seconds)