[00:05:30] <tomprince_loki> s/core->FreeInterface(x)/x->release()/ ??
[00:44:27] --> tomprince has joined #GemRb
[00:44:31] <-- tomprince has left #GemRb
[00:44:34] --> tomprince has joined #GemRb
[00:54:29] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[01:12:51] --> ratpor has joined #GemRb
[01:34:54] --> Gekz has joined #GemRb
[01:48:14] <Gekz> I would like a kettle of fish
[02:00:33] * tomprince takes a kettle of fish from Gekz.
[02:00:50] <Gekz> :o
[02:01:00] <tomprince> ;)
[02:01:09] <Gekz> I'm on a train
[02:01:10] <Gekz> :<
[02:01:28] * tomprince wishes C++0x where a viable option.
[02:02:35] <Gekz> were*!
[02:02:40] <Gekz> and why is it not a viable option?
[02:03:15] <Gekz> if this is about VC++6 again, just make a legacy branch for it
[02:03:16] <Gekz> lol
[02:03:20] <Gekz> then deprecate it
[02:03:24] <Gekz> D:
[02:03:50] <tomprince> Well, next time avenger shows up, I'll ask him about doing exactly that.
[02:04:13] <Gekz> yay!
[02:04:20] * Gekz plots against MS
[02:04:54] <Gekz> tomprince: BGT seems to load fine in GemRB
[02:04:57] <Gekz> I didnt load a game though
[02:05:01] <tomprince> But no, the final comittee draft of C++0x was released last month or so, and even gcc 4.4 only has partial support for it.
[02:05:03] <Gekz> the menu simply amused me
[02:06:00] <tomprince> I sometimes run a BGT version here. At some point I am going to get around to doing another BWP install here. And maybe actually play it this time. :)
[02:06:34] <Gekz> I'm uploading my BGT install to my site too
[02:06:59] <Gekz> what is BWP?
[02:09:23] <tomprince> BWP = Big World Project, which aims to combine BGT, as well as all the mods to BGT/BGTutu, and mods to BG2.
[02:10:21] <tomprince> http://www.shsforums.net/topic/44661-big-world-project-bwp-v90/
[02:10:32] <Gekz> that sounds horrible
[02:10:40] <Gekz> because quite a few mods for BG and BG2 are shit
[02:10:51] <Gekz> like one where he keeps spelling minsc wrong as minsk
[02:11:03] <tomprince> It gives you the option of what to install.
[02:11:27] <Gekz> ah.
[02:30:23] <-- Gekz has left IRC (Ping timeout: 260 seconds)
[02:50:40] <CIA-74> GemRB: 03tom.prince * rf2b4f78cfa07 10gemrb/gemrb/ (27 files in 15 dirs):
[02:50:40] <CIA-74> GemRB: Plugin: Call Plugin::release directly, rather than through Interface and PluginMgr.
[02:50:40] <CIA-74> GemRB: This shouldn't introduce any calls to release through a NULL pointer, since (almost)
[02:50:40] <CIA-74> GemRB: every call is preceded by a check, or another virtual call.
[03:34:07] <CIA-74> GemRB: 03tom.prince * r4a0219672c58 10gemrb/gemrb/core/ImageWriter.h:
[03:34:07] <CIA-74> GemRB: ImageWriter: Document that PutImage frees the sprite.
[03:34:07] <CIA-74> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[03:36:56] --> Gekz has joined #GemRb
[04:10:45] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[04:23:45] <-- Nomad010 has left IRC (Ping timeout: 276 seconds)
[04:40:43] <CIA-74> GemRB: 03tom.prince * r34dc27876180 10gemrb/gemrb/ (core/Map.cpp core/Map.h plugins/AREImporter/AREImporter.cpp):
[04:40:43] <CIA-74> GemRB: Map: Pass in Image/Sprite2D/Bitmap, rather than ImageMgr.
[04:40:43] <CIA-74> GemRB: Signed-off-by: Tom Prince <email@example.com>
[04:42:42] <Gekz> in other news
[04:42:51] <Gekz> hi
[04:43:02] <Gekz> I hate the media game
[04:43:02] <Gekz> >_>
[05:45:56] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[05:50:08] --> Gekz has joined #GemRb
[05:51:06] <CIA-74> GemRB: 03tom.prince * re790a6b1468d 10gemrb/gemrb/ (3 files in 2 dirs):
[05:51:06] <CIA-74> GemRB: SaveGame: Return Sprite2D instead of ImageMgr.
[05:51:06] <CIA-74> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[05:52:54] <-- Gekz has left IRC (Client Quit)
[07:05:12] --> lynxlynxlynx has joined #GemRb
[07:05:12] --- ChanServ gives channel operator status to lynxlynxlynx
[07:56:58] --> Nomad010 has joined #GemRb
[08:27:05] <fuzzie> The Plugin::release thing seems another of those "annoying Avenger for no gain" things.
[08:27:52] <fuzzie> Not that it is difficult to do the same thing in reverse if necessary.
[08:35:13] <-- |Cable| has left IRC (Remote host closed the connection)
[08:41:06] <fuzzie> The ResourceHolder thing seems clever, assuming the actual implementation is trivial.
[08:57:59] --> Gekz has joined #GemRb
[08:58:34] <edheldil> fuzzie: which one is ResourceHolder commit?
[08:59:07] <fuzzie> http://repo.or.cz/w/gemrb.git/commitdiff/7de33f7c47e97983bd2ce08ae6447cd83aff3664 (unfinished)
[09:11:01] <fuzzie> I am concerned about increased compile times if we start putting it everywhere, but that is easy enough to check.
[09:12:54] <wjp> the actual header is missing?
[09:13:14] <fuzzie> yes.
[09:13:33] <wjp> I guess I can imagine what it does
[09:14:05] <wjp> I like the idea
[09:14:25] <fuzzie> Much nicer than trying to remember to free temporary resources everywhere.
[09:14:52] <wjp> aye
[09:15:46] <edheldil> yep
[09:15:58] <edheldil> so it DOES free them, right? ;-)
[09:16:08] <wjp> :-)
[09:16:18] <fuzzie> I think -Werror and -Wcast-align are perhaps an impossible combination to keep.
[09:16:27] <fuzzie> eg, SDLVideo.cpp:2395: warning: cast from 'SDL_MouseButtonEvent*' to 'SDL_Event*' increases required alignment of target type
[09:16:39] <fuzzie> It is nice for catching ridiculous unportable casts, though.
[09:17:32] <edheldil> because in reality, they should be allocated and freed by some cache manager
[09:17:55] <wjp> edheldil: this is a layer above that, I think
[09:18:16] <fuzzie> Well, tomprince's change to call release() directly has rather restricted exactly where we can put the cache.
[09:20:29] <edheldil> do you mean Plugin::release? that should noty be a problem, no?
[09:21:09] <edheldil> (at least I thought it was releasing the plugin, not necessarily its data)
[09:21:40] <fuzzie> Since everything now calls plugin->release() to free a plugin-provided class, rather than core->FreeInterface() as it was last night, as far as I can tell you're now required to have any cache logic in the plugins.
[09:22:03] <fuzzie> We don't really release plugins at all; there's not much point, and we don't want to lose the symbols for valgrind etc.
[09:23:14] <wjp> I'd prefer a ResourceHolder-like trick instead of this plugin->release() patch I think
[09:23:33] <edheldil> yes, exactly my thought ... if it can be done
[09:23:53] <fuzzie> Yes.
[09:25:09] <edheldil> pardon my ignorance, but what does Plugin::release() releases then? The factory class?
[09:25:34] <fuzzie> No, the individual reosources/files classes
[09:25:43] <wjp> a specific instance of an importer object typically
[09:26:09] <wjp> the naming is rather sub-optimal
[09:26:20] <fuzzie> im = ( ImageMgr * ) gamedata->GetResource( Palette32, &ImageMgr::ID );
[09:26:23] <fuzzie> pal32 = im->GetImage();
[09:26:26] <fuzzie> - FreeInterface(im);
[09:26:28] <fuzzie> + im->release();
[09:26:31] <fuzzie> ^- this is an example change which gives the idea :)
[09:28:17] <edheldil> im is the factory class instance, no? ;). Let's hope TP changes it to autofree as well
[09:28:43] <fuzzie> This kind of thing is exactly what he's changing with the ResourceHolder thing.
[09:30:00] <edheldil> It get's much less complicated, let's hope it won't break on special cases
[09:30:02] <fuzzie> Hence my original 'seems clever'. :)
[09:30:16] <fuzzie> But the release() thing seems rather less clever.
[09:30:29] <edheldil> but I have little hope for deprecating msvc6 ;)
[09:30:34] <fuzzie> So, dum de dum.
[09:30:50] <fuzzie> Well, deprecating msvc6 doesn't really help so much for magical shiny modern C++ features.
[09:31:14] <fuzzie> Would be nice to have 'for' loops actually have their own scope, though. :)
[09:31:27] <edheldil> if by magical you don't mean C++0x ...
[09:31:36] <edheldil> hehe
[09:31:57] <edheldil> I can't remember how many times I have stumbled over that
[09:33:06] <fuzzie> But I think any complicated template features will fail on more modern compilers too, and I don't like the idea of stopping supporting platforms; if you don't care about portability, why not just use wine? :)
[09:33:39] <fuzzie> But then, gemrb on weird platforms is the only reason I work on gemrb.
[09:36:44] <edheldil> well, that's an argument. Unfortunately, there's no way to see in advance what will be too complicated :(
[09:38:53] <fuzzie> Things like the ResourceHolder are so simple that I can't imagine there would be a problem, even with msvc6.
[09:59:36] <-- Gekz has left IRC (Ping timeout: 268 seconds)
[10:00:37] <edheldil> what about exceptions?
[10:01:03] <edheldil> I have never used them, just asking
[10:01:21] <fuzzie> They're in general a bad idea, I think.
[10:02:17] <fuzzie> I don't know how true that is nowadays, even Symbian seems to have been gaining basic support..
[10:02:20] <wjp> they're a large source of (binary) incompatibility between linux distros too
[10:03:43] <fuzzie> I was going to say, wjp might know more, thanks to scummvm.
[10:04:04] <wjp> not so much in this case, because scummvm just doesn't use them :-)
[10:04:28] <fuzzie> They have a portability guide on the wiki, but it doesn't say much more than "don't use exceptions, don't use RTTI, don't use the standard C++ library, think about endianism".
[10:05:45] <wjp> but mainly it helps that it's just regularly built on many platforms, exposing any issues relatively quickly
[10:05:53] <fuzzie> *nod*
[10:06:14] <fuzzie> I have been looking at trying to at least cross-compile gemrb ourselves.
[10:06:42] <fuzzie> Of course, some of scummvm's crazier platforms are out of our reach!
[10:08:15] <fuzzie> I am a bit disappointed to find that I still haven't fixed some of the weirder endian issues..
[10:56:07] <edheldil> fuzzie: from the portability guide you quoted it looks like "don't use anything except of simple single inheritance". Which is what I was using back then when writing my master thesis ;-)
[10:57:57] <fuzzie> It makes it easy to know that compilers are going to do the right thing..
[10:58:06] <fuzzie> But scummvm has simple templating throughout the core, I think.
[10:58:28] <fuzzie> At least, it stopped building with old embedded toolchains at some point, and I believe that is why.
[10:59:09] <fuzzie> Yes, there's simple templates all over.
[10:59:41] <fuzzie> and (non-virtual) multiple inheritance too. :)
[11:01:22] <fuzzie> But those can be compiled without needing to worry about overhead or runtime support.
[11:57:01] <-- Lightkey has left IRC (*.net *.split)
[12:03:48] --> Lightkey has joined #GemRb
[13:10:06] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[13:23:37] <tomprince> Morning.
[13:35:29] <edheldil> hi
[13:52:54] --> Nomad010 has joined #GemRb
[14:24:10] --> Maighstir_laptop has joined #GemRb
[15:02:41] --> ratpor has joined #GemRb
[15:28:01] <tomprince> Found a SEGV in the Deirex save from eowyn.cz. If you go in the door, kill the lich. Then grab the gem from the cabinet, you are immedietly teleported away *with the container still open*. Go through the dialogue until you are teleported back, then immedietely click on the door. It SEGVs on Interface.cpp:4651.
[15:29:00] <fuzzie> I have a proper fix for that lurking.
[15:29:54] <tomprince> So it is a known bug. :)
[15:30:01] <fuzzie> Although the immediate problem is that the GUI scripts need to be notified when area changes happen.
[15:34:45] <fuzzie> You can break gemrb in many places by being in another screen when a teleport happens.
[15:42:14] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[15:49:45] <tomprince> or.cz/pathjoin: Cleanup that path handling code somewhat. The last three commits are untested/broken.
[15:57:03] <fuzzie> I don't understand what you're doing.
[15:57:22] <fuzzie> You're removing the .bif extension when it's .bif, and then always appending .bif?
[15:59:15] <tomprince> The idea is to be able to run in through PathAppend, so that when that handles case, the call to ResolveFilePath can be removed. That particular patch isn't well thought out. Especially since the entry->name is a relative path. :)
[16:00:59] <tomprince> The idea of that patch was to use the same code for both the .bif and .cbf case, rather than just overwriting the last 4 characters directly in the .cbf case.
[16:03:44] <fuzzie> It looks like you're thinking about minimising I/O, so it looks fine other than that.
[16:06:00] <tomprince> Yes, the idea is that every path component will be checked for case only once.
[16:12:13] <tomprince> I do think it makes sense to chop off the extension in KEYImporter. It gets rid of the strcpy(path+strlen(path)-4, ".cbf")
[16:17:03] <fuzzie> I'm not sure I understand.
[16:17:12] <fuzzie> Don't you actually break the KEYImporter?
[16:22:53] <tomprince> Probably right now. It needs to be cleaned up still. Especially the last two patches.
[16:23:29] <fuzzie> I mean, if you remove the extension, you have to store it somewhere.
[16:24:30] <tomprince> Are there any other extentions than bif and cbf?
[16:25:16] <fuzzie> the last time i tried, our keyimporter worked fine with otherwise-extensioned bif files
[16:25:19] <fuzzie> is that no longer the case?
[16:26:40] <tomprince> It probably does. I didn't realise that such things existed or mattered.
[16:26:43] <fuzzie> they're one of those things some mods used to organised their biffing.
[16:26:55] <fuzzie> i'm just not sure why you're just ignoring that case..
[16:28:50] <tomprince> I didn't know that there was a case to ignore.
[16:29:00] <tomprince> I am quite willing to handle it though.
[16:31:19] <tomprince> It occurs to me that using a DirectoryImporter here might make sense, maybe, although ... would that mean holding open the bif files?
[16:32:28] <fuzzie> well, as long as you don't hold them open on the unfinished GameOnCD path..
[16:34:30] <tomprince> That would mean holding ~180 files open potentially.
[16:34:37] <fuzzie> i thought one of the ports also didn't do the .bif thing, but i don't have them all here.
[16:34:47] <fuzzie> why ~180?
[16:35:05] <tomprince> I don't know if that would be an issue.
[16:35:14] <tomprince> That seems to be the number of bifs in BG2.
[16:35:20] <fuzzie> I mean: holding open the .bif files is something I've discussed before, because opening/closing them seems sensible.
[16:36:40] <tomprince> Mostly I didn't know if we would run into FD limits.
[16:37:34] <fuzzie> Quite possibly.
[16:37:51] <fuzzie> Not just due to this, but I think with everything else on top, perhaps.
[16:38:54] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[16:42:43] <fuzzie> I mean, I'm not sure what you're intending, but not re-opening the BIF files every single time we want a file sounds like an attractive idea, independently.
[16:58:12] <edheldil> you could always cache open FD, but on a modern Linux 180 is not a big number, I believe. At least I have 10624 open files in the system on my WS atm
[16:58:52] <edheldil> later ...
[16:59:11] <edheldil> phones will be different, though
[18:01:16] --> tomprince_loki has joined #GemRb
[18:01:46] --> |Cable| has joined #GemRb
[18:01:56] <-- tomprince_loki has left IRC (Client Quit)
[18:15:16] <fuzzie> I'm not sure.
[18:16:40] --> tomprince_loki has joined #GemRb
[18:39:47] --> ratpor has joined #GemRb
[19:11:36] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[19:20:30] <tomprince_loki> or.cz/pathjoin: Updated and slightly tested.
[19:25:07] <-- tomprince_loki has left IRC (Ping timeout: 268 seconds)
[19:31:09] <fuzzie> I still don't see why you're deliberately trying to break the deallocation thing.
[19:31:54] <fuzzie> I *also* don't see why you're trying to add templates everywhere.
[19:32:12] <fuzzie> I just feel like I'm going to end up maintaining a "not breaking things for the sake of breaking them" fork.
[20:27:20] --> barraAway has joined #GemRb
[20:30:10] --- barraAway is now known as barra_home
[20:40:16] <-- Nomad010 has left IRC (Ping timeout: 240 seconds)
[20:49:40] --> tomprince_loki has joined #GemRb
[20:50:45] <tomprince_loki> fuzzie: I don't want to force you to maintain a fork.
[20:55:27] <-- tomprince_loki has left IRC (Ping timeout: 260 seconds)
[20:59:07] <fuzzie> It just seems that we have competing goals.
[21:20:32] <tomprince> Well, my goal is a code base that is easier to understand and maintain.
[21:25:39] <tomprince> And I don't want to break compatability to do it (except MSV6 :)). And it isn't that I want to break compatability with MSVC6 in particular.
[21:25:40] <lynxlynxlynx> but that conflicts with portability
[21:26:31] <lynxlynxlynx> i'm sure the mobile hardware will overtake us, but who knows what kind of toolchains they'll have
[21:26:53] <lynxlynxlynx> or already do - we don't have enough testers
[21:27:53] --> cfchris6 has joined #GemRb
[21:28:20] <-- cfchris6_ has left IRC (Read error: Operation timed out)
[21:36:59] <tomprince> I'll admit that I don't have any experience dealing with portability.
[21:37:38] <fuzzie> I just want a code base which I enjoy working on.
[21:38:01] <tomprince> I share that motivation.
[21:39:26] <fuzzie> I mean, I just feel you're breaking/complicating things for the sake of doing so.
[21:39:43] <fuzzie> The changes which do that are mostly just making it less clear, to me.
[21:40:18] <tomprince> That is the opposite of my intention. I don't want to do that.
[21:40:23] <fuzzie> I forked something on github without the release() change, but I don't think I'm working on anything which would be difficult to merge back.
[21:43:27] <tomprince> I don't want to show up, be given commit rights, and immedietely (or ever) force a long time contributer to fork.
[21:43:43] <fuzzie> Well, that's not really what happened; it's not like you just showed up.
[21:44:22] <tomprince> Well, I showed up ~6 months ago. Mostly just.
[21:44:38] <fuzzie> I showed up not a long time prior to that. :)
[21:46:22] <tomprince> Regardless :), I don't want to be the cause of you forking.
[21:46:26] <fuzzie> I am just concerned that the codebase is moving towards something which is difficult for me to work on. I have worked on other projects with templates/C++0x/boost/etc everywhere and I ended up spending too long waiting for slow template compiles and fixing portability issues. If it turns out your changes still work everywhere then I can just push everything back on trunk
[21:47:07] <fuzzie> But I think a lot of rearchitectural changes have a tendency to just worry me, regardless of their merit.
[21:47:36] <tomprince> And I'm not going to push for C++0x, as much as I'd like too. :) That was just me gripping that it will be another 10 years before people start accepting the use of things from it.
[21:48:21] <tomprince> I can understand your worries about rearchitectural changes.
[21:48:57] <tomprince> Do stop me if I am going to far.
[21:49:21] <fuzzie> Well, I don't think I'm in a good position to work that out.
[21:50:36] <tomprince> A lot of the code right now is highly interdependent in complex ways, and it is hard to get a handle on. I am trying to tease out which parts are inherent in what we are trying to do, and which are just artifacts of many years of adding things piecemeal.
[21:51:04] * tomprince goes for supper.
[21:51:14] * tomprince will be back shortly. :)
[21:56:26] <fuzzie> But the patches like removing the central point for release() and then adding it *back* with a template are perhaps predictably not patches I really want to have to worry about.
[22:05:12] <tomprince> Yes.
[22:06:18] <tomprince> That probably could have been better thought out.
[22:12:01] <-- barra_home has left IRC (Quit: Verlassend)
[22:12:38] <fuzzie> Well, it makes sense that things don't always work out the first way, but it seems like it's going to end up being a worse solution.
[22:13:59] <lynxlynxlynx> it's not too late to revert the changes
[22:14:36] <fuzzie> Well, it's *never* too late to revert the changes.
[22:15:06] <fuzzie> I mean, this is why I don't see it being so terrible to go off and fork for a bit.
[22:15:40] <lynxlynxlynx> you both seem to agree it was not the best of moves, so I don't see a problem
[22:16:20] <lynxlynxlynx> it's never too late to revert, but if there are new changes on top of the old ones, it can get messy
[22:17:26] <tomprince> Although, in this case it is almost mechanical to reapply the changes in reverse.
[22:18:02] <lynxlynxlynx> yes, this case is simple
[22:18:57] <tomprince> And I am not happy with what is in my dealloc branch right now. I realised that we only had one use (almost) of Resource, images. So I decided to drop that for now, and work on getting the sound branch in.
[22:19:20] <tomprince> I do think that moving things out of Interface is a good thing.
[22:19:29] <fuzzie> Yes.
[22:25:20] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:27:18] <tomprince> fuzzie: Do you have a link to your github, or do you want to add it to the main apge?
[22:27:28] <tomprince> s/apge/page/
[22:27:46] <fuzzie> It's just edheldil's with s/edheldil/fuzzie/.
[22:33:14] <tomprince> The or.cz/pathjoin branch is ready. The last two commits want to be squashed, and it wants some testing, but otherwise, I think it is good.
[22:38:03] <fuzzie> the -#ifndef WIN32 makes sense?
[22:39:33] <fuzzie> Looks fine to me, if it works.
[22:40:20] <tomprince> I think so.
[23:25:56] <tomprince> or.cz/pathjoin, or.cz/sound: Ready for testing.
[23:28:48] <fuzzie> 'sound' has lost the sound bit?
[23:29:03] <fuzzie> And the last commit there has a typo in the summary. :)