[01:36:27] <-- Nomad010 has left IRC (Read error: Connection reset by peer)
[01:52:06] <tomprince> gemrb segfaults in ControlAnimation::UpdateAnimation if the bam was not found in the constructor. Possible fixes:
[01:52:57] <tomprince> 1. lookup the bam before creating the ControlAnimation
[01:53:25] <tomprince> 2. Check in ControlAnimation::UpdateAnimation if we have an animation?
[02:06:55] <tomprince> Case 2 seems more sensible, but then iwd2 fails when calling SetAnimationPalette.
[02:07:07] <tomprince> That is, case 1 seems more sensible.
[02:28:29] <tomprince> case at or.cz:ctl-anim
[04:18:08] <CIA-74> GemRB: 03tom.prince * r75a79c03bab6 10gemrb/gemrb/ (23 files in 10 dirs):
[04:18:08] <CIA-74> GemRB: Resource: Get rid of unused autoFree paramater.
[04:18:08] <CIA-74> GemRB: The value passed was always true, so get rid of it.
[04:18:08] <CIA-74> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[04:35:44] <CIA-74> GemRB: 03tom.prince * ra4ea4949b205 10gemrb/gemrb/ (14 files in 10 dirs):
[04:35:44] <CIA-74> GemRB: Resource: Resource objects are not reusable, so simplify the code.
[04:35:44] <CIA-74> GemRB: Signed-off-by: Tom Prince <email@example.com>
[04:52:32] --> raevol has joined #GemRb
[04:53:26] <CIA-74> GemRB: 03tom.prince * r344a4bea710e 10gemrb/gemrb/ (7 files in 2 dirs):
[04:53:26] <CIA-74> GemRB: Cleanup includes.
[04:53:26] <CIA-74> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[05:58:52] <-- raevol has left IRC (Quit: Leaving.)
[06:39:22] --> barraAway has joined #GemRb
[07:14:45] --> lynxlynxlynx has joined #GemRb
[07:14:46] --- ChanServ gives channel operator status to lynxlynxlynx
[07:41:20] --> Gekz has joined #GemRb
[07:41:33] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[07:42:00] <-- xrogaan has left IRC (Read error: Operation timed out)
[07:43:09] <tomprince> or.cz/holder: Cleaned up and organized.
[07:43:38] --> xrogaan has joined #GemRb
[07:43:38] <-- xrogaan has left IRC (Changing host)
[07:43:38] --> xrogaan has joined #GemRb
[07:43:45] <tomprince> Tested as a whole, but not individually yet.
[07:51:34] <edheldil> tomprince: do you think that having path case resolution in PathJoin(), while still having to keep ResolveFilePath() is optimal? Jusrt asking ...
[08:06:37] --> Gekz_ has joined #GemRb
[08:06:56] <-- Gekz has left IRC (Ping timeout: 246 seconds)
[08:33:40] <lynxlynxlynx> the ResolveFilePath on PluginsPath now makes the output look uglier - there are double slashes
[08:38:04] --> Nomad010 has joined #GemRb
[08:48:13] <-- |Cable| has left IRC (Remote host closed the connection)
[09:01:53] <Gekz_> looks can be deceiivng
[09:22:59] <lynxlynxlynx> not when you're talking about ugliness
[09:38:26] <Gekz_> especially when talking about it lol
[09:38:33] <Gekz_> cant you just check if the string ends in / before joining it
[09:47:31] <lynxlynxlynx> of course it can be fixed, now we always append a slash
[10:03:39] <-- Nomad010 has left IRC (Remote host closed the connection)
[10:04:13] --> Nomad010 has joined #GemRb
[11:41:04] <edheldil> the check for trailing slash used to be done in PathAppend() :-P
[11:41:58] --> Gekz has joined #GemRb
[11:42:06] <lynxlynxlynx> PathJoin is the culprit now
[11:42:36] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[13:08:35] <tomprince> edheldil: PathJoin doesn't do case resolution on the first path component passed, or handle ~.
[13:26:16] <CIA-74> GemRB: 03tom.prince * rcfd10fd33b16 10gemrb/gemrb/core/VFS.cpp: VFS: Fix doubled slash in PathJoin.
[13:27:36] <lynxlynxlynx> there's another one a few lines before
[13:33:38] <CIA-74> GemRB: 03tom.prince * r00b588f901fa 10gemrb/gemrb/core/VFS.cpp: VFS: Fix another doubled slash bug.
[13:34:49] <lynxlynxlynx> :)
[13:36:03] <tomprince> Although I am more interested in people comments on the or.cz/holder branch. :)
[13:42:33] <-- Nomad010 has left IRC (Ping timeout: 276 seconds)
[13:45:08] <fuzzie> well, you're putting templates into header files everywhere, so i'm not going to merge it into my tree
[13:46:40] <tomprince> Nothing at all fancy with them though.
[13:47:45] <fuzzie> if you're happy with putting overcomplicated refcounting all over the tree, it still looks fine at a glance :)
[13:53:37] <tomprince> Part of the motivation was to deal with your concerns about s/FreeInterface/->release/.
[13:53:46] <fuzzie> sure, but you haven't fixed that at all
[13:53:56] <fuzzie> you're just using a templated intermediary for release()
[13:54:07] <fuzzie> there's still no way for the core to control cache policy
[13:54:53] <fuzzie> so it's still removing functionality without any real gain except for some clarity in function-local temporaries, which i think your original patch handled quite well on its own.
[13:55:05] <fuzzie> so from my point of view, it's a bad thing.
[13:57:57] <fuzzie> but as discussed previously, that's not a view you necessarily have to worry about.
[13:59:16] <tomprince> I do.
[14:00:15] <fuzzie> it maybe also comes back to the discussion the other day about how some of these changes are more complicated to understand, with the advantage that they're tidier.
[14:00:20] <wjp> I don't think passing Holders<X> around really gains us enough for the simplicity it costs
[14:00:32] <fuzzie> which is also a "half a dozen of one, 6 of the other" kind of thing.
[14:01:14] <wjp> especially given that we don't even know yet how we want to do caching, so I'd prefer keeping it simple for now
[14:02:22] <fuzzie> but obviously it's clear from existing changes that we've already had places where we've forgotten to free temporary resources in some of the paths, so as a local function tool, it seems to make sense.
[14:02:37] <wjp> yes, I quite like that usage
[14:02:52] <tomprince> One of the benifits I considered, is that we could pass Holder<>s, or the underlying pointer to python now, without worrying about dangling refs. Like tables and symbols.
[14:02:53] <wjp> I added the StackLock to the openal code for the same reason
[14:04:07] <tomprince> fuzzie: I think my patches are split up enough that you can grab the bits where it is used function-locally without grabbing the rest. I deliberately tried to split up the patches so that was possible.
[14:14:27] <tomprince> wjp: bufw is unused in SDLVideo::showYUVVFrame, when NDEBUG is defined. (which is now the default on cmake).
[14:16:04] <wjp> hm, I'll have to look at that closer when I'm back home
[14:16:26] <fuzzie> i suspect i wrote that
[14:19:35] <fuzzie> given the assert and the stride data, i imagine you could just comment out bufw as unused entirely..
[14:21:53] <tomprince> I suspect so, but that would also mean getting rid of the assert ...
[14:22:55] <tomprince> Although, given the assert there and in showFrame, would it make sense just to drop bufh/bufw in both of them?
[14:23:17] <fuzzie> no, because bufh is required :)
[14:23:34] <tomprince> But if bufh==h always?
[14:23:43] <fuzzie> oh, huh
[14:23:47] <fuzzie> i guess so, then
[14:24:14] <fuzzie> why is that?
[14:24:29] <fuzzie> it sounds like an awful idea
[14:25:03] <fuzzie> oh, Avenger trying to optimise things..
[14:25:17] <fuzzie> i think the code is wrong there
[14:25:30] <fuzzie> we should be able to stretch video, and as such we should be blitting from bufw/bufh to w/h
[14:26:05] <tomprince> Although, looking at the callers, the pass the exact same variable for both in both cases.
[14:26:15] <fuzzie> sure, but you can see it's useful functionality?
[14:26:21] <tomprince> Yes.
[14:26:53] <fuzzie> Avenger broke this to make sure the SDL YUV structure only had to be allocated once, i guess
[14:28:09] <fuzzie> but it should be easy to fix it again, at a glance..
[14:28:33] <fuzzie> will teach me to check commits more closely
[14:30:20] <fuzzie> or, i guess alternatively, you could simply handle that stretching on the SDLVideo side?
[14:30:38] <fuzzie> and then drop the w/h parameters
[14:33:03] <fuzzie> either way that bufw is still irritatingly unused
[14:35:03] <tomprince> Well, if w/h is dropped, then the assert goes away, and bufw can be commented out.
[14:36:02] <fuzzie> well, sure, it solves your problem :-)
[14:57:26] --> Nomad010 has joined #GemRb
[15:22:18] <tomprince> I love clang++ template error reporting.
[15:26:29] <wjp> g++ 4.5 apparently improved that as well. I should try how it fares tonight
[15:31:17] --> barra_away has joined #GemRb
[15:33:37] <-- barraAway has left IRC (Ping timeout: 264 seconds)
[15:44:00] <tomprince> Apparently gdb knows how to run make :)
[15:45:07] <lynxlynxlynx> anything actually
[15:45:36] <tomprince> It dumps anything it doesn't understand to sh?
[15:45:56] <lynxlynxlynx> no, there's "shell" iirc
[15:46:15] <lynxlynxlynx> make is a shortcut
[15:46:51] <tomprince> Well, I just found that shortcut by accident, and was suprised and pleased.
[15:53:37] <edheldil> on dropping the buffer, comment out that pesky call to MD_update() as well ;-)
[15:58:31] <fuzzie> ;p
[16:28:10] <tomprince> or.cz: The function local stuff is first now, and there is a rudimenary caching of Resources.
[16:28:41] <Gekz> howdy
[16:28:46] <Gekz> I lost my job today
[16:28:48] <Gekz> how goods that
[16:50:04] <tomprince> Question about caching: 2da and ids are cached *as long as someone "holds a reference"* to them, and no longer. Would it make more sense to just treat them like everything else, modulo getting python track references properly?
[16:50:56] --> Gekz_ has joined #GemRb
[17:00:13] --> Avenger has joined #GemRb
[17:00:17] --- ChanServ gives channel operator status to Avenger
[17:06:18] <tomprince> Hello.
[17:07:05] <Avenger> hello
[17:07:12] <Avenger> and bye!
[17:07:16] <-- Avenger has left IRC (Quit: bye!)
[17:07:17] <tomprince> Question about msvc6?
[17:08:11] <tomprince> :(
[17:10:15] <tomprince> I wanted to know if 'export GEM_EXPORT' worked instead of the nested ifdefs at the bottom of Interface.h.
[17:10:37] <tomprince> And the sign-compare in BIKPlayer.
[17:14:37] <fuzzie> tomprince: the "modulo getting python tracking references properly" being the tricky bit.
[17:14:48] <fuzzie> Gekz_: :(
[17:16:14] <tomprince_loki> I know how to do that, probably without to much trouble. I was just wondering if people thought it was a reasonable thing to do.
[17:16:39] <tomprince_loki> It would mean that we can drop all the GetTable and GetSymbol stuff from GameData/Interface, I think.
[17:17:26] <fuzzie> well, it depends on what you're planning to replace them with, i guess.
[17:18:03] <tomprince_loki> If Plugin is refcounted, all that needs to be done is get Python to grab a reference when it gets something, and release it when the Python object is dropped.
[17:19:11] <tomprince_loki> As far as I can tell, the only reason that they have a special interface right now, is so that Python can use integers to reference them.
[17:19:45] <fuzzie> well, Plugin *isn't* refcounted now, right?
[17:20:42] <tomprince_loki> No...
[17:21:38] <fuzzie> so, i mean, the only reason they have a special interface is because Plugin isn't refcounted and we don't want to be keeping multiple copies around and the Python interface was pretty unfriendly to this sort of thing until the recent metaclass additions..
[17:22:36] --> |Cable| has joined #GemRb
[17:23:53] <fuzzie> so it's not really quite as simple as just the Python side, which could be trivially moved into the GUIScript plugin keeping a list around
[17:24:33] <tomprince_loki> Well, the Holder branch right now will handle the first two parts.
[17:26:46] <fuzzie> but only if you apply the entire branch, right?
[17:26:57] <fuzzie> so it's not a trivial change.
[17:29:36] <fuzzie> i mean, i'm not trying to argue that again, but there are more reasons for all that code *as it is*.
[17:30:52] <tomprince_loki> Yes. I was just wondering if there was something besides that, that was more subtle or something.
[17:31:50] <tomprince_loki> It just seemed that holder branch made the only remaining issue the python one, as I was wondering if there was something I was missing.
[17:33:55] <fuzzie> well, i mean, you could just move the Python integer indexing into the GUIScript code.
[17:34:26] <fuzzie> so that isn't really the reason.
[17:35:18] <fuzzie> so it's more that: if that were the only reason, you could move that out of Interface without needing to actually change much code at all.
[17:41:21] <tomprince_loki> I think we are talking past each other somewhat. I was thinking of implementing it on top of the holder branch, and was wondering if there were issues other than the three you mentioned above. Which I know may end up not being merged.
[17:41:32] <fuzzie> Sorry.
[17:41:47] <fuzzie> What I mean is: The fact that python needs integers to reference things has nothing to do with the special interface there.
[17:42:40] <fuzzie> We could trivially move that code into plugins/GUIScript, without even needing to modify the python side.
[17:44:30] <fuzzie> It was just convenient to have both in core, given the caching is currently happening there too, and it means you can add a "!!!" debug line there and spot which stupid code is repeatedly requesting a cached table without parsing the contents out.
[17:45:17] <tomprince_loki> Well, you could even just cast the pointers to longs. I really meant the lifetime issues with python references, and avoiding dropping the reference on the C++ side before python is done with it.
[17:45:19] <fuzzie> But it would be easy enough to do such things another way.
[17:46:15] <fuzzie> Well, casting the pointers to longs means that you can induce segfaults from the python side, and the idea is that you shouldn't be able to do that.
[17:46:30] <fuzzie> But I'm not sure anyone particularly cares.
[17:46:41] <tomprince_loki> i.e. lifetime issues ...
[17:46:45] <tomprince_loki> :)
[17:48:04] <fuzzie> I don't get it.
[17:48:40] <tomprince_loki> Well, you can only induce segfaults from pointers passed to Python if the object is deleted before the pointer is used.
[17:48:57] <fuzzie> Or if you just pass nonsense values.
[17:49:49] <fuzzie> I mean, maybe I misunderstand what you're planning to do.
[17:50:02] <tomprince_loki> Ah.
[17:51:00] <fuzzie> But the idea is that the Python side should be moddable, etc, which means it should be resistant to crazy users.
[17:51:19] <fuzzie> But my point again is that *that* issue is completely seperate from the GameData thing.
[17:51:44] <tomprince_loki> Well, I hadn't decided exactly. But the plan was that the interface exposed to GUIScript would be wrapped as an object ... either using metatables, or code on the C side. So that the only way to call the functions is through a validly created object.
[17:51:57] <fuzzie> You don't have to change the python functions just to get rid of the GameData stuff.
[17:53:19] <fuzzie> So this conversation got a bit too long, anyway. :)
[17:53:26] <tomprince_loki> :)
[17:53:44] <tomprince_loki> That does make sense. On the other hand, I think both parts are sensible things to do.
[17:54:10] <fuzzie> Well, they seem again like a lot of work for no benefit, but if you're doing the work..
[17:54:39] <tomprince_loki> I was planning to do the work ... :)
[17:57:44] <tomprince_loki> Certainly no obvious immediate benifit. The benifit I see is longer term, where the code base is approachable and straightforward, where the C++/python interface is at least similiar, and ...
[18:01:59] <tomprince_loki> That is probably part of the reason I like templates and so on. Because it add complexity in one place, while leading to simplifications in a bunch of others.
[18:02:21] <tomprince_loki> And I think that is a net win.
[18:04:08] <tomprince_loki> I know the Video* -> Holder<Video> might not actually be a win, and I am less attached to that bit, than much of the rest.
[18:05:37] <tomprince_loki> I realised that as I was going through and making all those changes. I wanted to try to avoid having a Holder::get(), but that might not make sense.
[18:08:19] <fuzzie> But, again, 'simplication' seeming to mean 'less code' in some of those cases, and not 'easier to understand'. :)
[18:09:40] <fuzzie> I mean, don't get me wrong, I still work on codebases where almost everything is stored in a smart_ptr and we massively re-use code via templates and specialisation and etc, I am fully aware of how much easier to maintain it can be.
[18:09:42] <tomprince_loki> Well, I'll admit that easier to understand is a subjective thing, and that my evalutaion of it is different that a lot of people. :)
[18:11:02] <tomprince_loki> And I probably have a very high tolerance ofr abstraction.
[18:11:04] <fuzzie> But I also still know that every time I add an overloaded operator, or some templated magic, it means another piece that people have to stop and think about.
[18:12:09] <fuzzie> Although it doesn't help that I also know that when I come back to this stuff after not having thought about it for a year, *I* tend to be one of those people, and maybe your memory is somewhat better than mine.
[18:13:52] <tomprince_loki> I don't know.
[18:13:58] <fuzzie> And you've kind of taken the hat of maintaining all the resource/plugin code at this point. :)
[18:14:12] <tomprince_loki> Yes. :)
[18:14:46] <tomprince_loki> At least the glue code. Not necesarily the internal logic. I don't know enough about all the ie formats for that. :)
[18:19:04] <tomprince_loki> What I do know is that when I first approached the code base, it took me quite a while to understand, and there are still parts of it that seem mysterious. And part of the difficulty for me is that it seems like there is no clear seperation between things.
[18:21:55] <tomprince_loki> Like, the gui code is spread between C++ and python, and on the C++ side, it seems mixed in with the scripting code, and the rule code, and the file access code. And it is hard to see which bits are about GemRB memory format or gui code, and which bits are implementing logic for the original games.
[18:22:07] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[18:23:19] <fuzzie> Yes.
[18:23:21] <tomprince_loki> And the lowest hanging fruit was the plugin system ...
[18:24:11] <fuzzie> Which is much-improved.
[18:24:33] <fuzzie> I don't think anyone would argue it isn't, if only because all that absurd boilerplate is gone. :)
[18:24:41] <tomprince_loki> :)
[18:26:43] <fuzzie> and moving core out of plugins makes sense for clarification, but then the #include changes are on the other side; they're now more ambigious, but tidier.
[18:27:13] <fuzzie> even just applying the "did I have more accurate information before or after?" test.
[18:27:21] <tomprince_loki> My goal is to eventually clean up the rest of the code. Which is undoubtedly a multi-year project.
[18:27:23] <fuzzie> not that I am objecting to it.
[18:27:39] <fuzzie> because having "../../../core/blah.h" for everything would drive us all completely mad.
[18:28:05] <tomprince_loki> Well, it would be possible to just have core/blah.h.
[18:28:33] <fuzzie> That is a perfect solution which I would never have considered.
[18:28:54] <fuzzie> I mean, I doubt it's worth the hassle now. Ah well. :)
[18:37:40] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[18:37:40] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[18:45:21] --> tomprince has joined #GemRb
[18:45:36] <tomprince> Something like or.cz/core?
[18:47:16] <tomprince> Not tested \w autotools
[18:49:43] <tomprince> Feel free to apply either or both, with appropriate log messages.
[18:50:42] --> tomprince_loki has joined #GemRb
[18:50:45] <tomprince> I'm not planning to to, but either way works for me.
[18:52:49] <fuzzie> unless someone else feels strongly about it, as i say, it seems not worth the hassle
[18:52:56] <fuzzie> i wish i'd asked about it earlier :)
[18:53:07] <fuzzie> but i would like to avoid the wrath of Avenger
[18:54:16] <tomprince_loki> :)
[18:56:05] <tomprince_loki> I hope I didn't incur it with the sound changes landing last night ... :)
[18:57:06] <tomprince_loki> He did seem to appear and disappear very quickly today.
[19:02:24] <fuzzie> he's usually very busy during the week anyway
[19:28:45] <wjp> well, gemrb actually builds with g++ 4.5
[19:32:53] <tomprince_loki> You can actually run -flto on it, with the static-link branch. Although I haven't run tests to see if it is a win.
[19:34:30] <tomprince_loki> It might even help on just libgemrb_core itself.
[20:05:25] <-- Nomad010 has left IRC (Ping timeout: 264 seconds)
[20:24:21] --> Nomad010 has joined #GemRb
[20:55:09] --> Dark-Star has joined #GemRb
[20:55:09] --- ChanServ gives channel operator status to Dark-Star
[20:58:17] <Dark-Star> just curious: anyone know why avenger is still so keen on supporting MSVC6, with all those recent kludges to work around its broken template system?
[20:58:38] <wjp> because he likes it better than the newer ones
[21:00:20] <Lightkey> if that was not rhetorical, I don't know what is
[21:02:10] <Dark-Star> well, it's 12 year old software we're talking about... they didn't even ship with a correct STL library back then :)
[21:02:27] <lynxlynxlynx> he likes the debugger a lot
[21:07:48] <Dark-Star> well, it did have a good debugger back in 1998, that's for sure, but I don't think the VS2008 one is any worse (although the intermediate versions like VS2003 really were quite limited)
[21:08:01] <Dark-Star> but anyway, if it works for him why now, I was just curios
[21:09:08] <Dark-Star> btw I noticed I'm still OP in here, feel free to remove me from the OP list (I haven't really done anything else than reading the commit mails and ocassionally compiling GemRB from SVN in the last, like, 4 years or so ;-)
[21:11:55] <Dark-Star> anything else with respect to GemRB, that is. I have done other things, obviously :)
[21:13:58] <lynxlynxlynx> we're mature and don't care about ops and voices
[21:14:27] <tomprince_loki> And it isn't usually busy enough here for that either.
[21:14:32] <Dark-Star> fine with me :)
[21:14:46] <lynxlynxlynx> and it's freenode, not some teenage server
[21:28:26] <fuzzie> and the nice thing about supporting msvc6 is that we don't end up with a codebase full of unportable stuff
[21:29:21] <fuzzie> msvc6 is *so bad* that you're never going to have C++ which works in vc6 but not with some compiler an embedded platform is stuck with
[21:30:35] <Dark-Star> true, but you will also be stuck with loads of workarounds that could be solved so-much-nicer if VC6 would just support "correct" C++
[21:30:39] <fuzzie> but i think the thing about the debugger is that Avenger's other stuff (like DLTCEP) are vc6-era MFC code, so there's no legitimate way for him to get a modern msvc.
[21:31:46] <Dark-Star> I especially like this one (taken from the recent commits) for example: 74c46799744d5cd761e0544ae26091c1c9f98907 :-)
[21:32:07] <fuzzie> well, i don't see why that one was necessary
[21:32:12] <fuzzie> no-one has convinced me that it was.
[21:32:24] <fuzzie> but i haven't tried it myself yet.
[21:32:28] <Dark-Star> because VC6 doesn't support templated functions I guess (it's too long that I used it so I can't tell for sure)
[21:32:42] <fuzzie> but we use templated functions in various other places :)
[21:32:59] <Dark-Star> hm, maybe the debugger doesn't support them? ;-)
[21:33:41] <fuzzie> but we'd have had to have done something horrible there anyway to avoid the optimiser, so it's a fair example
[21:34:12] <Dark-Star> and why not overload operator() for the class so that the callers don't have to be updated? Well I guess VC6 doesn't support that either ...
[21:34:21] <fuzzie> well, because it was a quick hack.
[21:35:52] <fuzzie> but, yes, i think there will be a few places like that forever :)
[21:36:06] <fuzzie> it would be nice to be rid of them, but it really doesn't seem like much of a burden
[21:36:32] <fuzzie> the stupid 'for' scope is a much better target for my hatred. :)
[21:37:36] <Dark-Star> so true :) all people I talked to were really happy after ditching support for VC6 in their projects.
[21:37:49] <Dark-Star> but honestly, all the good stuff Tom recently did (and still does) really outweigh the VC6 cruft that has to be carried around IMHO
[21:39:39] <fuzzie> well, my viewpoint is mostly: gemrb's goal is to actually run the IE games. Avenger made a few thousand commits towards that goal. unless some VC6-incompatible fix is going to actually move us a long way towards that goal, keeping VC6 support is a tiny price to pay.
[21:40:04] <fuzzie> and all the refactoring in the world is completely useless if gemrb doesn't *work*.
[21:40:42] <Dark-Star> yeah, of course, I didn't mean to suggest ditching VC6 support even if I may have sounded like that
[21:40:55] <fuzzie> well, i think the standard line is "please convince Avenger" :)
[21:41:46] <Dark-Star> sounds like a tough job ;-)
[21:42:01] <fuzzie> also I think reading the commit emails and seeing enough of this stuff to comment on it is really enough work to make you a gemrb hero, have a gold star :)
[21:42:26] <fuzzie> i barely keep up recently myself
[21:48:37] <lynxlynxlynx> peer review ftw :)
[21:51:11] <Dark-Star> hm it seems Microsoft has retired the MSVC2008 express editions in favor of MSVC2010... at least I can't find 2008 anymore :(
[21:53:21] <-- Gekz has left IRC (Read error: Connection reset by peer)
[21:53:55] --> Gekz has joined #GemRb
[21:53:56] <-- Gekz has left IRC (Changing host)
[21:53:56] --> Gekz has joined #GemRb
[21:56:51] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:01:45] <tomprince_loki> Or, find a debugger that is better than VC6, which amounts to the same thing. I certainly that, given that Avenger chooses to use VC6, dropping VC6 support isn't worth it.
[22:02:19] <tomprince_loki> Avenger even agreed that dropping support for the VC6 compiler would be a good thing, except that he hasn't found a better debugger.
[22:03:27] <fuzzie> someone should sneak into his house and install msvc2010, i expect
[22:03:31] <fuzzie> assuming it can be installed alongside vc6
[22:04:21] <fuzzie> yes, that is specifically supported
[22:05:19] <tomprince_loki> Does vc2010 even supports c++0x doesn't it. ;)
[22:05:21] <tomprince_loki> /me hides.
[22:05:56] <fuzzie> well, as you know, c++0x is one of those things where everyone supports disjoint subsets :)
[22:06:19] <tomprince_loki> :)
[22:07:51] <tomprince_loki> Well, I haven't actually looked at recent support. I think I last played with c++0x last summer or something.
[22:08:18] <tomprince_loki> It would suprise me if there was a compiler that supported c++0x features, but didn't support auto, or rvalue references.
[22:09:29] <fuzzie> it's kind of spotty, i think
[22:09:33] <fuzzie> oho
[22:09:35] <fuzzie> http://blogs.msdn.com/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx
[22:10:04] <fuzzie> not too bad at all, it seems
[22:10:20] <-- barra_away has left IRC (Quit: Verlassend)
[22:13:16] <tomprince_loki> All the nice stuff it looks like.
[22:15:41] <Dark-Star> I read today that c++0x will be called c++11 because they couldn't finish it in time (it is in the final stages of becoming a standard, apparently)
[22:16:05] <tomprince_loki> Actually, it doesn't mention anything about initializer lists, or uniform intialization syntax.
[22:16:22] <tomprince_loki> Some people will call c++0xb
[22:16:57] <tomprince_loki> The final comittee draft was finalized about a month ago, I think. Herb Sutter's blog has the announcment I read.
[22:19:45] <Dark-Star> I really don't fully grok all that rvalue stuff in the standard. I mean every time I *seem* to understand it, another paragraph or example comes up and I'm back at the beginning ;-)
[22:20:28] <Dark-Star> it's probably just a of about the right tutorial/introduction, though
[22:20:41] <Dark-Star> s/a about/a question about/
[22:21:10] <Dark-Star> no that's wrong too... damn I should go to bed :)
[22:23:04] <tomprince_loki> I won't claim ot understand it fully either.
[22:23:06] <Dark-Star> anyways, I have a slight feeling that c++0x (or c++11 or whatever) will be too bloated to be really useful (or at least too bloated to be widely accepted). I hope I'm wrong though
[22:26:40] <tomprince_loki> I think that there is enough in the new standard that is really useful for writing simpler easier to maintain code, that it will be accepted. How widely accepted is another matter.
[22:27:13] <tomprince_loki> I think a number of people might disagree with me on simpler, but I think in part, it is just getting used to the new idioms available.
[22:27:41] <fuzzie> well, it's one of those "can i look at this line and know what it does?" things
[22:29:20] <tomprince_loki> And I think we will have to agree to disagree on the answer to that question in many cases. :)
[22:29:33] <fuzzie> and not as if any of the C++0x tools magically change that answer to 'no'
[22:30:12] <fuzzie> and, well, you can approach the question pretty objectively :)
[22:31:43] <fuzzie> just a question of how much you're happy with the answer being 'no' - we already have varied things in the tree which violate that
[22:32:00] <fuzzie> don't think c++0x seems particularly likely to make it worse.
[22:32:43] <tomprince_loki> And I think that quite a few of the features in c++0x are targeted at library writers, and people writting the low-level infrastrucure bits of projects, to enable them to write code that doesn't have weird limitations and corner cases.
[22:33:02] <tomprince_loki> I'd like to reduce the number of places where the answer is 'no'.
[22:33:40] <fuzzie> well, that's not always a good idea
[22:34:09] <tomprince_loki> No?
[22:34:12] <fuzzie> no
[22:34:19] <fuzzie> i mean, your Holder<> thing is an instant 'no'
[22:34:44] <-- Nomad010 has left IRC (Ping timeout: 240 seconds)
[22:34:44] <fuzzie> if you look at it and you're not familiar with it, there's no way to work out what it's doing
[22:35:20] <fuzzie> but the same applies to our operator-overloaded AutoTable thing, or indeed anything on-stack doing constructor/destructor magic
[22:36:23] <fuzzie> or virtual functions, even
[22:36:49] <tomprince_loki> Well, but once you know that it is a ref-counted smart-pointer you know enough about what it does that the details aren't an issue. And I think that smart pointers like that are a common enough idiom.
[22:37:02] <fuzzie> and being explicit about all of those things is easy enough, but then you have what i imagine is everyone's nightmare :)
[22:37:35] <fuzzie> although with that said, i guess that is the philosophy of most people i know who insist on coding in C.
[22:38:45] <fuzzie> and you say that, but then someone specialises the template and.. :)
[22:39:50] <tomprince_loki> I would say that is in the realm of "don't do that then", unless you maintain the abstract interface.
[22:39:52] <fuzzie> (i mean, slipperly-slope argument there, not intended to be criticism in particular.)
[22:40:31] <tomprince_loki> Certainly, there many more ways to abuse C++ to make it inpenetrable. :)
[22:40:53] <fuzzie> but everyone's "don't do that" is at a different level, obviously - easy enough to argue that assuming smart pointer specialisation makes sense becaus they should always do the 'right thing' when freeing objects, for example.
[22:41:14] <Dark-Star> my guess is that people won't use C++0x for a long time because it's so new and not properly supported for all the various build chains out there. So people will stick with boost or other libraries
[22:41:16] <fuzzie> but, sorry, abstract argument.
[22:41:30] <fuzzie> Dark-Star: you think boost is well-supported for all the various build chains out there? :)
[22:41:47] <Dark-Star> okay, point taken :)
[22:42:13] <fuzzie> they make terribly impressive attempts to be compiler-compatible with boost::config, but i guess the length of time it took for the previous C++ standard to be well-supported is probably a good warning sign
[22:43:06] <Dark-Star> but every time I see C++0x right now I see compatibility lists with lots of "no"/"partial" in there and this might really take some time to figure out. so most projects probably wouldn't accept 0x code because, for example, it won't run on VC6 (assuming that there's a hack to make boost work on that dinosaur ;-)
[22:43:24] <tomprince_loki> I get the impression that C++0x uptake will be somewhat faster than C++98 uptake.
[22:44:07] <Dark-Star> fuzzie: yes, exactly my thoughts. the STL was so different from vendor to vendor that for a long time the suggestion was "don't use it, better re-code your own lists/maps/..."
[22:44:24] <Dark-Star> maybe it won't be *that* bad with 0x but I don't think it'll be a smooth ride either
[22:44:25] <tomprince_loki> I suspect that C++0x is already in production in some places. OSS is constrained by having support many platforms.
[22:46:22] <Dark-Star> another interesting point: how many existing projects will break by switching to c++0x because of the new keywords ("auto" for example)
[22:46:36] <tomprince_loki> And I get the impression that the compiler and standard library writers are mindful of the difficulties that happened last time around, and are trying to make things smoother this time.
[22:47:23] <tomprince_loki> auto is already a keyword.
[22:49:12] <Dark-Star> it is? hmm ...
[22:49:39] <Dark-Star> aah it's the opposite of "register" or something?
[22:50:13] <tomprince_loki> And the C++0x attribute syntax was envisioned to avoid introducing lots of new keywords.
[22:50:43] <tomprince_loki> I think the opposite of static.
[22:50:52] <tomprince_loki> At block scope.
[22:51:25] <Dark-Star> never seen it used, but gcc indeed does complain...
[22:52:05] <tomprince_loki> I think it essentially dates to pre-C89.
[22:53:06] <Dark-Star> well, gotta go get some sleep, see you guys around
[22:53:48] <tomprince_loki> nullptr, static_assert, constexpr, decltype, alignof are the major new keywords I think.
[22:56:05] --- Dark-Star is now known as Dark-Star|Zzz
[23:16:37] <Lightkey> http://imagebin.org/94737 that is some seriously bad photo
[23:16:59] <Lightkey> anyway, it is from c't 7/2010 ;-)
[23:17:20] <Lightkey> published fortnightly
[23:27:55] --> Gekz_ has joined #GemRb
[23:28:37] <-- Gekz has left IRC (Read error: Connection reset by peer)
[23:56:32] --> _pickle has joined #GemRb