#gemrb@irc.freenode.net logs for 5 May 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:37:31] --> mihairu has joined #gemrb
[00:59:53] <-- barra_home has left IRC (Quit: Verlassend)
[01:07:19] --> raevol has joined #gemrb
[01:08:39] <-- mihairu has left IRC (Ping timeout: 252 seconds)
[01:19:31] <-- raevol has left IRC (Quit: Leaving.)
[01:20:47] --> raevol has joined #gemrb
[01:31:51] <-- raevol has left IRC (Quit: Leaving.)
[01:33:18] --> raevol has joined #gemrb
[01:34:56] <-- raevol has left IRC (Client Quit)
[03:16:08] --> mihairu has joined #gemrb
[06:36:59] --> Bo_Thomsen has joined #gemrb
[06:38:11] --> lynxlynxlynx has joined #gemrb
[06:38:11] --- ChanServ gives channel operator status to lynxlynxlynx
[07:13:03] --> adominguez has joined #gemrb
[07:31:35] <dhewg> moin
[07:35:40] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[07:56:33] <wjp> hi
[07:56:46] <fuzzie> moop.
[07:58:14] <fuzzie> oh dear, gibberlings3.net expired?
[08:03:25] <wjp> hm, whois agrees
[08:03:27] <dhewg> looks dead from here
[08:03:42] <wjp> still working here, but not for long then, probably
[08:04:03] <wjp> forums.gibberlings3.net has address
[08:04:20] <fuzzie> thanks
[08:04:56] <fuzzie> hehe, i still had commented-out google ipv6 in my hosts file
[08:08:24] <wjp> I kind of wonder why there's no ~/.hosts
[08:13:48] <edheldil> because hosts is an artifact from pre-DNS days?
[08:14:24] <edheldil> and possibly it would have security implications
[08:14:30] <fuzzie> well, then the question becomes 'how come there's no ~/.resolv.conf'? ;p
[08:18:09] <edheldil> possibly because it's reopened several times during daemon lifetime - and since daemon meanwhile setuided to nobody ....
[08:18:45] <edheldil> another reason is probably POSIX
[08:19:15] <edheldil> and possibly nobody cared enough to implement it
[08:20:59] <fuzzie> maybe we could just summarise it as edheldil's fault? :)
[08:22:54] <edheldil> grr
[08:22:57] * edheldil shuts up
[08:24:50] <fuzzie> i spent enough time some years ago battling nscd to put me off name resolving for a lifetime :/
[08:27:30] * edheldil is admin for a TLD :)
[08:28:07] <fuzzie> well, i know you seemed involved in all this stuff, hence why it seemed appropriate to make it your fault :p
[08:30:20] <edheldil> anyway .. I have finally installed gemrb on Nokia n900. Looks nice, but loading is slooooooow
[08:30:42] <fuzzie> with master?
[08:31:30] <fuzzie> also make sure it's set to 16bpp in config :)
[08:31:43] <edheldil> no, only 0.6.4 ... I have not made devel env yet
[08:32:02] <fuzzie> 0.6.4 is missing dhewg's magical load time fix
[08:32:16] <fuzzie> also all of our caching work :)
[08:33:20] <edheldil> there was some issue that although the game was running and unpaused, the pcs stopped and did not want to move, but I had no time to investigate
[08:33:41] <fuzzie> also all of the timing work.. :P
[08:34:02] <edheldil> hehe
[08:36:26] <dhewg> heh, i see my fix is still popular :)
[08:43:03] <fuzzie> yes
[08:51:44] --> SiENcE has joined #gemrb
[09:02:24] <-- |Cable| has left IRC (Remote host closed the connection)
[10:05:59] <-- dhewg has left IRC (Ping timeout: 260 seconds)
[10:06:04] --> dhewg has joined #gemrb
[10:31:04] <dhewg> i dont get the whole plugin/resource handling
[10:33:23] <fuzzie> what about it?
[10:36:22] <dhewg> i mean, i didnt yet look at every importer. so far its no problem understanding it, but the design is weird
[10:36:30] <dhewg> it looks inefficient
[10:36:39] <fuzzie> which bit? :P
[10:37:53] <dhewg> every time something is requested via importers, the plugin manager map is poked at, a instance is created, that something is created by that instance, then the instance is thrown away
[10:39:20] <dhewg> why not just use something like "static Resource *create(DataStream *)" from one global plugin instance?
[10:39:30] <fuzzie> well
[10:39:35] <fuzzie> this has kinda evolved, i guess
[10:39:41] <fuzzie> the importers have been slowly becoming stupid
[10:39:55] <dhewg> thats what i figured so far
[10:40:02] <dhewg> but its all huge and stuff
[10:40:08] <dhewg> so im prolly missing something
[10:40:17] <fuzzie> well, you're probably looking at the wrong plugins
[10:40:22] <dhewg> i mean, i really dont get the plugin architecture in the first place :P
[10:40:23] <fuzzie> look at 2DAImporter, for example
[10:40:46] <fuzzie> or ACMReader
[10:42:30] <fuzzie> but for the images, in particular, tomprince rearchitected the system so that nothing uses the importers any more, they just retrieve something from the importer and then discard the importer itself
[10:44:42] <fuzzie> i'm not sure this is a spectacularly great idea, but i guess the importers can always keep themselves open in an image class they return
[10:45:34] <dhewg> yeah
[10:46:04] <fuzzie> the static thing *is* a good idea for a few things, like items and stores, i just doubt they're worth special-casing
[10:47:06] <dhewg> if - then all :P
[10:47:38] <fuzzie> and making everything static and returning new objects in most cases is possible i'm sure, but no time to think about it right now
[10:47:54] <dhewg> i didnt mean to put that work on you
[10:48:02] <dhewg> but well, i poked at the hashmap a little again
[10:48:06] <fuzzie> well, you won't, because i have no time ;p
[10:48:16] <dhewg> :)
[10:48:29] <dhewg> one argument was to get rid of tons of allocs
[10:48:40] <dhewg> and this stuff is created and thrown away left and right
[10:49:33] <fuzzie> yeah, it might be nice to deal with that, but on the other hand, the image management is wasting insane amounts of memory atm, so..
[10:51:24] <dhewg> sure, but that doesn mean other spots can not be improved too :P
[10:51:34] <fuzzie> yes
[10:52:22] <fuzzie> but you have to be careful not to bake the 'let's just read everything into memory and throw away the importer/stream, whoooo' into the design :P
[10:53:47] <dhewg> i was thinking about the caching
[10:54:28] <dhewg> i mean if you seperate importer from created objects, and those objects have a common base class, it makes alot of stuff easier
[10:54:59] <fuzzie> yeah
[10:55:31] <fuzzie> i just want the "objects have data on-disk, not in memory" case to be remembered :)
[10:55:56] <dhewg> in case it wasnt clear: i didnt plan on wasting mem :P
[10:56:21] <dhewg> just getting to to know the project and looking for stuff which can be improved
[10:56:50] <fuzzie> sure
[10:58:37] <fuzzie> and the audio importers provide a sufficiently good example i think
[11:00:31] <dhewg> for what now?
[11:00:35] <dhewg> wasting mem?
[11:01:20] <fuzzie> no
[11:01:51] <fuzzie> for the case where the importer hangs around for the lifetime of the object, atm
[11:02:08] <fuzzie> and where you'd need some custom subclass to hang around and keep the stream, in any redesign
[11:03:16] <dhewg> ah
[11:04:26] <dhewg> got a little time to look at some code?
[11:04:54] <fuzzie> not really :P
[11:07:16] --> lubos has joined #gemrb
[11:12:15] <dhewg> heh k :P
[11:28:46] <-- SiENcE has left IRC (Quit: @all: cya)
[11:40:10] <fuzzie> maybe i have some time on the weekend or tomorrow evening
[11:42:09] --- Maighstir is now known as Maighstir|away
[11:43:07] <fuzzie> but no shortage of other people to bother!
[11:57:54] <dhewg> hehe :P
[12:00:56] <lynxlynxlynx> i'm here, but i'm hardly the right person for reviewing such code
[12:01:47] <lynxlynxlynx> prove the improvement with a benchmark and then others can look at the tidiness ;)
[12:24:05] <dhewg> well that one was more about unifying code
[12:24:34] <dhewg> the direct change from old static code to new templated stuff wont affect performance
[12:24:42] <dhewg> at least in theory
[12:26:33] <fuzzie> not a spectacularly reliable theory, alas
[12:31:55] <-- lubos has left IRC (Ping timeout: 260 seconds)
[12:45:45] --> lubos has joined #gemrb
[12:51:15] --> test32894789234u has joined #gemrb
[13:32:05] <dhewg> dont be so pessimistic :P
[13:32:23] <dhewg> i'll run some test and benchmarks
[13:32:57] --> AstralStorm has joined #gemrb
[13:33:02] <AstralStorm> hello
[13:33:12] <AstralStorm> does GemRB support Baldur's Gate 2 network play?
[13:33:35] <Gekz> nope
[13:33:40] <AstralStorm> oh, pity
[13:33:48] <AstralStorm> any other network play?
[13:40:35] <-- lynxlynxlynx has left IRC (Ping timeout: 258 seconds)
[13:43:33] --> lynxlynxlynx has joined #gemrb
[13:43:33] <-- lynxlynxlynx has left IRC (Changing host)
[13:43:33] --> lynxlynxlynx has joined #gemrb
[13:43:33] --- ChanServ gives channel operator status to lynxlynxlynx
[13:43:54] <lynxlynxlynx> bleh
[13:44:01] <lynxlynxlynx> nope
[13:44:01] <lynxlynxlynx> it will probably be the last thing we'll work on, if at all
[13:44:01] <lynxlynxlynx> if singleplayer doesn't function perfectly, multiplayer will only be doubly worse
[13:51:01] <edheldil> with a great potential to screw other's game as well
[13:52:45] <edheldil> it's hard enough to find BG2 player, even worse to find more :)
[13:53:25] <lynxlynxlynx> not so horribly hard
[13:53:36] <lynxlynxlynx> and at that point we could make it so much sexier
[13:55:56] <edheldil> how?
[13:56:17] <edheldil> unless you mean importing all the harlots from Sigil to Candlekeep ;-)
[14:00:28] --> Bo_Thomsen has joined #gemrb
[14:00:58] <fuzzie> dhewg: but also bear in mind compile speeds, pls
[14:06:54] <lynxlynxlynx> level 2 & 3 modding
[14:07:38] <lynxlynxlynx> things like 8 player parties and other (silly) obstacles removed
[14:07:50] <fuzzie> maybe someone could implement the crazy deathmatch thing :)
[14:11:01] <edheldil> another crazy (singleplayer) idea - randomly generated dungeons ;-)
[14:11:40] <fuzzie> well, an isometric-tile map importer might be interesting to do, someday
[14:12:06] <fuzzie> and you could build random dungeons on top of that
[14:17:04] <tomprince> dhewg: You could probably change a number of plugins to not be allocated fresh everytime. Fairly easily too, just adding some stuff to plugindef.h and the plugin definition blocks.
[14:19:31] <fuzzie> i did notice that PluginMgr.h is mandated by almost the entire codebase
[14:20:03] <fuzzie> it would be nice if we could fix that
[14:25:05] <fuzzie> i guess simply removing the PluginHolder from Plugin.h, and putting it in PluginMgr.h, would solve that
[14:25:51] --- Maighstir|away is now known as Maighstir
[14:40:22] <tomprince> fuzzie: That would be reasonable.
[14:43:08] <tomprince> Also, I had an implementation of ImageMgr that didn't hit the backend from 364 days ago, that I pushed.
[14:45:03] <AstralStorm> edheldil, you mean like, infinity engine roguelike? that's a great idea!
[14:45:10] <AstralStorm> but someone will have to paint all these blocks
[14:45:20] <AstralStorm> better yet, port nethack to gemrb afterwards
[14:51:11] <Gekz> oh god
[14:51:14] <Gekz> nethack in gemrb
[14:51:19] <Gekz> I'd cream everywhere.
[14:53:45] <edheldil> s/cream/scream/ ; s/everywhere/forever/
[14:54:45] <edheldil> AstralStorm: we have *no* dataset yet, so I would not hold my breath
[14:54:49] --> SiENcE has joined #gemrb
[14:54:57] <fuzzie> well
[14:55:10] <fuzzie> creating a native IE dataset is hard
[14:56:02] <fuzzie> hacking up tiles, less hard
[14:58:11] <fuzzie> tomprince: deliberately avoiding reviewing code for any project atm, will look on weekend
[15:03:40] <tomprince> k.
[15:14:34] <AstralStorm> edheldil, of course, I'd go blue then die of suffocation
[15:14:53] <AstralStorm> gemrb isn't ready yet for singleplayer BG2 at all?
[15:15:30] <AstralStorm> or is it just "lots of bugs"?
[15:16:08] <tomprince> The later. And I don't know if it is still *lots*.
[15:16:31] <edheldil> of course it is :)
[15:16:42] <tomprince> I think it is completable.
[15:17:39] <tomprince> Also, If you spam this channel with your bugs as you run into them, people are generally good about fixing them in a timely fashion. (At least if you have a way to reproduce them consistently)
[15:21:02] <CIA-52> GemRB: 03tom.prince * r59bb426e2738 10gemrb/gemrb/ (23 files in 13 dirs):
[15:21:02] <CIA-52> GemRB: PluginHolder: Move this from Plugin.h to PluginMgr.h.
[15:21:02] <CIA-52> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[15:23:19] <wjp> not sure if we should promote IRC as an effective bug reporting medium...
[15:24:20] <tomprince> Well, I am simply observingg.
[15:25:01] <tomprince> And I am perhaps biased, since that is the only thing I look at.
[15:32:50] <fuzzie> i think effective bug reporting on irc requires you be somewhat technical
[15:34:12] <fuzzie> it worked well for dhewg's bugs because a 'maybe add a check for this on that line' response was sufficient
[16:03:26] <-- mihairu has left IRC (Remote host closed the connection)
[16:04:15] --> mihairu has joined #gemrb
[16:10:21] <-- SiENcE has left IRC (Quit: @all: cya)
[16:33:40] <tomprince> true ...
[16:58:54] <-- adominguez has left IRC (Quit: Saliendo)
[17:08:48] <dhewg> fuzzie: do you remember about the unaligned access on powerpc?
[17:09:22] <dhewg> the stuff that max mentioned in his mail
[17:09:25] <dhewg> also, wrong channel
[17:19:34] <-- gembot has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[17:19:59] --> gembot has joined #gemrb
[17:36:52] --> |Cable| has joined #gemrb
[18:06:44] <-- Gekz has left IRC (Read error: Connection reset by peer)
[18:07:51] --> Gekz has joined #gemrb
[18:07:51] <-- Gekz has left IRC (Changing host)
[18:07:51] --> Gekz has joined #gemrb
[18:10:38] <-- Gekz has left IRC (Read error: Connection reset by peer)
[18:11:12] --> Beh0lder has joined #gemrb
[18:11:18] <Beh0lder> hello all
[18:11:23] --> Gekz has joined #gemrb
[18:11:23] <-- Gekz has left IRC (Changing host)
[18:11:23] --> Gekz has joined #gemrb
[18:12:34] <Beh0lder> What happened with G3 site?
[18:16:25] <tomprince> I think the dns expired.
[18:16:46] <tomprince> There is an IP address in the backlog here.
[18:22:40] <dhewg> if anyone wants to poke at what i have so far: https://github.com/dhewg/gemrb/commits/hashmap
[18:23:46] <dhewg> comes with 3 usages to test it, to see whats going on under the hood, there's a debug define in HashMap.h
[18:26:41] <dhewg> tomprince: can you easily make your buildbot test compile that?
[18:27:06] <dhewg> i have no idea if it works on anything that is not gcc :)
[18:31:36] <gembot> build #129 of msvc++6 is complete: Failure [failed setproperty compile] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/129
[18:33:19] <tomprince> dhewg: msvc6 doesn't have proper scoping of variables declared in for statements.
[18:33:43] <dhewg> i can see that, but wasnt yet sure how to express myself about it :P
[18:33:57] <dhewg> but thx for throwing it at buildbot
[18:40:37] <gembot> build #96 of mingw32 is complete: Exception [exception setproperty install download_1] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/96
[18:43:17] <tomprince> You can ignore that one. That is just that the windows VM has an old buildslave (it only has the latest release :P)
[18:44:18] <dhewg> ok
[18:44:50] <tomprince> Any reason stringmap is a separate file?
[18:45:05] <dhewg> includes
[18:45:44] <dhewg> but apart from that no real reason
[18:46:02] <-- Beh0lder has left #gemrb
[18:46:43] <dhewg> if you're looking at it, i dont know how to solve the TODO in the keyimporter
[18:46:47] <tomprince> Well, I don't think you want to hard code sizeof(ieResRef). They should be null-terminated anyway, and it might silently break if somebody uses something else.
[18:47:17] <dhewg> oh d'oh
[18:47:35] <dhewg> there's a variant of that in keyimporter. c&p fail
[18:48:04] <dhewg> nice catch
[18:51:06] <tomprince> Don't know about the TODO.
[18:51:37] <dhewg> the only thing i can think of to prevent that copy is to reintroduce a hash argument to the template
[18:51:50] <dhewg> what you saw on that other patch a week or so ago
[18:52:24] <dhewg> or to seperate the keyimporter stuff into multiple hashmaps, but i think thats maybe not a good idea
[18:52:54] <tomprince> I bet you could move the code in StringMap.h to HashMap.cpp. Although you'd have to change it to not specialise the structs, just the methods.
[18:53:52] <tomprince> (Same thing for HASHMAP_DEFINE_TRIVIAL_HASHKEY, just specialize the methods)
[18:54:36] <dhewg> you mean rip the 3 things out of that struct?
[18:56:40] <tomprince> No, instead of template <> struct HashKey<T> { .... have template <> HashKey<T>::hash(T) { ...
[18:58:04] <dhewg> with the only goal to put them in a .cpp?
[18:59:28] <tomprince> Well, for the string ones. I don't know if it makes sense to move the trivial ones to the cpp.
[19:00:08] <tomprince> But, since you aren't changing the shape of the struct, just providing different implementations of the methods, just do that.
[19:00:12] <-- test32894789234u has left #gemrb
[19:00:51] <dhewg> my template voodoo is a bit rusty, but wouldn't you lose compiler optimisations if moving to a .cpp?
[19:01:55] <tomprince> That is why you wouldn't want to move the trivial ones.
[19:02:45] <tomprince> I don't know about the cost of the string ones vs the call overhead.
[19:04:51] --> Avenger has joined #gemrb
[19:05:11] <Avenger> hi
[19:06:04] <tomprince> Also, returning a std::string* feels dirty to me (in DirectoryImporter), but I don't see a way around it.
[19:06:19] <tomprince> hello.
[19:06:34] <Avenger> eep, you want to add more std stuff and templates?
[19:06:43] <Avenger> i don't really like that
[19:07:04] <tomprince> in this case, templates but not stl stuff.
[19:07:32] <fuzzie> haven't been paying attention, but i think a *simple* template HashMap will be easier to read and faster
[19:07:39] <tomprince> Right now we have something like three hashmap implementations.
[19:07:48] <dhewg> a little std is in there though
[19:08:08] <Avenger> well, i hoped we get rid of it, and not put in more ;D
[19:08:33] <fuzzie> hopefully we can replace all of them with one single HashMap
[19:08:35] <Avenger> it is a dependency, it has different implementations
[19:08:50] <Avenger> i would like a single own hashmap, maybe
[19:08:52] <fuzzie> with just three different hash functions, some lines of code
[19:09:00] <fuzzie> this is our own hashmap i am pretty sure :)
[19:09:02] <Avenger> but mind that we have our own hashing
[19:09:18] <dhewg> yeah, the idea was to replace the other implementations. this template is based on the current code
[19:09:20] <Avenger> spaces/case insensitivity
[19:09:29] <dhewg> but it doesnt have all features yet
[19:09:48] <dhewg> see if you like it, and i can work on that :)
[19:09:55] <fuzzie> we should make sure to not use tolower() in it, too :P
[19:10:11] <dhewg> but then we need make sure that tolower() stuff gets in
[19:10:23] <fuzzie> did the fast inline stuff get committed? i forget
[19:10:27] <Avenger> i waned to avoid templates because they cause extra compile time and... well, i just don't like them
[19:10:33] <tomprince> No.
[19:10:33] <fuzzie> yes
[19:10:47] <fuzzie> i complain about anyone trying to increase the compile time :-P
[19:10:56] <tomprince> :) no to the tolower stuff being committed.
[19:11:01] <fuzzie> hehe
[19:11:14] <fuzzie> right, you didn't like my idea for the function names
[19:11:52] <tomprince> they just seem needlessly verbose.
[19:11:57] <Avenger> i prefer using simple language, as little c++ as needed
[19:12:28] <fuzzie> but inline_tolower seems pretty sane to me
[19:13:58] <Avenger> tolower reminds me... do simplified chinese have capitals?
[19:14:16] <fuzzie> not sure
[19:14:22] <fuzzie> did you look at the example Japanese .tlk?
[19:14:28] <Avenger> i'm not sure if we have to bother with it though
[19:15:14] <Avenger> but we had some special letters list for polish characters
[19:15:28] <fuzzie> yes, that code is still there :)
[19:16:37] <Avenger> i didn't look at the tlk, i doubt i can figure anything out anyway :)
[19:16:46] <fuzzie> http://fuzzie.org/nfs/gemrb/japanese_soa/ is what I pulled out of the Japanese SoA patch
[19:17:08] <fuzzie> i think edheldil said it was simple enough, just double bytes
[19:17:58] <Avenger> well, if capitals are easily done by flipping a bit, it is great
[19:18:19] <Avenger> if not... then we need some native :D
[19:18:37] <fuzzie> added the BAMs too now
[19:19:19] <fuzzie> but i assume they don't have capitals :)
[19:20:15] <Avenger> hmm, yeah, maybe that's some european invention
[19:20:28] <fuzzie> i mean, drop capitals
[19:20:33] <AstralStorm> I wonder... has anyone made a separate game yet based on gemrb?
[19:20:36] <fuzzie> and the other ones i am hoping we can ignore maybe
[19:20:43] <fuzzie> AstralStorm: Maighstir is working on something.
[19:20:50] <AstralStorm> heh
[19:20:55] <fuzzie> But the pre-rendered backgrounds make it a lot of work.
[19:21:04] <Avenger> all i can see is that tokens remained single byte
[19:21:07] <AstralStorm> more like pre-painted
[19:21:44] <Avenger> AstralStorm: well, when we did glory of istar, the areas were rendered in 3d
[19:21:51] <fuzzie> Almost everything from Bioware is just rendered and then touched up a bit - I was kinda surprised to notice but it's obvious when you look.
[19:22:35] <gembot> build #113 of cmake g++-4.4.5 is complete: Failure [failed git] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/113 blamelist: dhewg <dhewg@wiibrew.org>
[19:23:03] <AstralStorm> fuzzie, hah, nice to know
[19:28:54] <Avenger> hehe, buildbot reports some damage
[19:30:59] <dhewg> uh oh, did i break it?
[19:31:34] <fuzzie> buildbot is not so smart, it will report personal builds to the whole channel
[19:31:35] <tomprince> no, i don't know what that failed git is, unless you pushed something rebased in the mean time.
[19:31:53] <dhewg> no, same branch, 2 commits on top
[19:32:07] <dhewg> but it should work even with a rebase
[19:32:25] <dhewg> we did that on scummvm once it just didnt complain :)
[19:33:05] <tomprince> The trick is, if you rebase before all the builders have fetched, those that try to fetch after will fail.
[19:33:20] <tomprince> But I think that git is just a github hiccup.
[19:34:29] <tomprince> And I don't know why the win32 builds didn't kick off. Trying to debug that now.
[19:40:05] <Avenger> as far as i see, that bot was shot down :D
[20:10:44] <-- gembot has left IRC (Quit: buildmaster reconfigured: bot disconnecting)
[20:11:16] --> gembot has joined #gemrb
[20:16:23] <tomprince> dhewg: can you push the v0.6.2 tag to your repo?
[20:17:36] <dhewg> does it depend on that?
[20:17:51] <dhewg> i have 0.6.4 there, but thats something different than your 0.6.4
[20:18:54] <gembot> build #97 of mingw32 is complete: Exception [exception setproperty install download_1] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/97 blamelist: dhewg <dhewg@wiibrew.org>
[20:19:26] <tomprince> Not the branch, the tag.
[20:20:26] <dhewg> oups, pushed them all :P
[20:21:34] <fuzzie> lynxlynxlynx: what caused the ToB completeable?
[20:21:35] <tomprince> As long as 0.6.2 (or in fact, and tag on mainline) is there. :)
[20:22:43] <gembot> build #130 of msvc++6 is complete: Exception [exception setproperty interrupted] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/130 blamelist: dhewg <dhewg@wiibrew.org>
[20:23:04] --> SiENcE has joined #gemrb
[20:24:28] <fuzzie> lynxlynxlynx: also, ar0512 rects are over http://fuzzie.org/nfs/gemrb/ar0512.png ?
[20:28:27] <gembot> build #98 of mingw32 is complete: Exception [exception setproperty install download_1] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/98 blamelist: dhewg <dhewg@wiibrew.org>
[20:34:57] <gembot> build #132 of msvc++6 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/132
[20:56:46] <gembot> build #133 of msvc++6 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/133 blamelist: dhewg <dhewg@wiibrew.org>
[21:02:02] <dhewg> huh
[21:02:17] <dhewg> i rebased already, lets try...
[21:14:31] --> barra_home has joined #gemrb
[21:27:43] <-- Avenger has left IRC (Quit: bye!)
[21:48:54] <gembot> build #116 of cmake g++-4.4.5 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4.5/builds/116
[22:07:47] <lynxlynxlynx> fuzzie: e8, it was unavoidable
[22:08:07] <fuzzie> ah
[22:08:12] <lynxlynxlynx> and yes re rects
[22:18:30] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:19:57] <AstralStorm> hey, does your buildbot run any tests?
[22:21:31] <fuzzie> the ones we have, which is almost nothing
[22:21:49] <AstralStorm> heh :) life
[22:22:30] <AstralStorm> https://www.youtube.com/watch?v=l1wKO3rID9g :)
[22:24:02] <fuzzie> i forget if it's you who we discussed the 'tests for gemrb would be 95% of the entire project' thing with
[22:24:14] <AstralStorm> definitely not
[22:24:40] <fuzzie> but almost *all* of the hard work is working out what on earth stuff is meant to do, recently
[22:25:08] <AstralStorm> in fact, you're testing the IE itself
[22:25:10] <AstralStorm> or should be
[22:26:05] <fuzzie> but you can't realistically test the IE at a low enough level
[22:26:20] <AstralStorm> indeed, but does it matter?
[22:26:31] <AstralStorm> if it looks like a duck, walks like a duck...
[22:26:37] <fuzzie> if we don't, then it doesn't help much :)
[22:26:49] <fuzzie> the problem are all about the subtle behaviours of things interacting
[22:27:12] <AstralStorm> then you should write tests of the subtle behaviours, amirite?
[22:27:14] <fuzzie> and you can't make the original engine cooperate to be deterministic
[22:27:20] <AstralStorm> once they're discovered
[22:27:26] <fuzzie> sure
[22:27:47] <AstralStorm> non-deterministic is fine, as long as non-determinism matches? everyone loves bug-for-bug compatibility
[22:27:49] <fuzzie> and replacing guesswork with discovery is the 95% of the whole project :)
[22:28:03] <fuzzie> sure, non-deterministic is great, but how to test?
[22:28:18] <fuzzie> could do an awful lot of work and hook all the relevant functions in the bg2 executable, i suppose
[22:29:00] <tomprince> We have slowly been moving to more testing.
[22:29:31] <tomprince> Now, if lynxlynxlynx would write the script to test against the bg2demo ...
[22:29:33] <AstralStorm> great, no "oops, we've written a damn fine engine, but it doesn't work like IE" for you
[22:29:48] <fuzzie> well
[22:29:55] <fuzzie> it doesn't work remotely like the IE, of course :-)
[22:32:54] <fuzzie> i am pondering about that isometric thing again, i wonder if parpg has anything suitable for testing
[22:38:26] <fuzzie> stuff like http://wiki.fifengine.net/images/b/b4/2007.2.007.jpg would be perfect
[22:41:47] <AstralStorm> weirdness, what FIFE is aiming for, Fallout-like engine? Simcity? I'm not sure what it is :)
[22:42:12] <fuzzie> it was originally intended to be a Fallout engine
[22:42:34] <AstralStorm> looks like it, but can it run Fallout itself? I bet not
[22:42:41] <fuzzie> not any more, afaik
[22:42:50] <AstralStorm> bummer
[22:43:42] <fuzzie> i suggest making puppy eyes at barra_home
[22:44:23] <AstralStorm> barra_home, 0_0
[22:44:43] <fuzzie> huh, kaelis did some bits of this fife demo stuff
[22:45:59] <AstralStorm> http://blog.parpg.net/2011/01/parpg-goes-agile/ - these guys need that hitler movie some more than you
[22:46:31] <fuzzie> i think they're still using svn for all development
[22:46:43] <fuzzie> with mandatory trac tickets
[22:46:46] <fuzzie> they are poor, lost souls
[22:47:07] <AstralStorm> svn and scrum don't mix
[22:47:49] <fuzzie> honestly i can't work out quite how FIFE works though
[22:48:00] <fuzzie> i mean, for a decent isometric engine, you want 'wall' type things, i guess
[22:48:05] <fuzzie> well i guess i will sleep and ask barra sometime :P
[23:10:11] <barra_home> lies!
[23:10:51] <-- SiENcE has left IRC (Quit: bye)
[23:13:37] <barra_home> I like how you pull mandatory trac tickets out of your ass fuzzie :-) whatever that means
[23:13:44] <barra_home> but feel free to elaborate
[23:14:28] <barra_home> I think that's the story that every changeset actually needs an associated trac ticket
[23:14:46] <barra_home> I commented on this one in here in the past and actually cleared up that this was wrong :-)
[23:23:15] <barra_home> but keep up the good work spreading that wrong story fuzzie :-)
[23:23:30] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[23:23:58] <barra_home> and to be fair: we're preparing to move to hg soon, so DVCS support will be introduced
[23:24:07] <-- barra_home has left IRC (Quit: Verlassend)
[23:32:33] <-- mihairu has left IRC (Read error: Connection reset by peer)