#exult@irc.freenode.net logs for 4 Jun 2002 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:56:02] --- Darke|afk is now known as Darke
[00:56:09] <matto> Darke|fluff !
[00:56:38] * Darke fluffs.
[03:05:10] --> Kirben has joined #exult
[03:05:10] --- ChanServ gives channel operator status to Kirben
[03:05:42] <Darke> Hi.
[03:06:31] <Kirben> Hi
[03:15:46] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[03:22:39] --> Kirben has joined #exult
[03:22:39] --- ChanServ gives channel operator status to Kirben
[04:29:23] <-- Darke has left IRC ("Inficio-Infeci-Infectum")
[05:39:30] <-- matto has left IRC ("This feeling.. inside me. Finally found my life, I'm finally free. No longer torn in two. Living my own life by learning f)
[05:44:35] --> _Kirben has joined #exult
[06:24:36] --> SharpTooth has joined #exult
[06:25:34] --- SharpTooth is now known as Darke
[06:25:55] --- ChanServ gives channel operator status to Darke
[06:28:29] <-- _Kirben has left IRC (Read error: 104 (Connection reset by peer))
[06:38:04] <-- Darke has left IRC ("Inficio-Infeci-Infectum")
[06:44:54] --> Darke has joined #exult
[06:44:54] --- ChanServ gives channel operator status to Darke
[07:12:36] --> wjp has joined #exult
[07:12:36] --- ChanServ gives channel operator status to wjp
[07:16:46] <wjp> hi
[07:17:55] <Darke> Hi.
[11:20:57] --- Darke is now known as Darke|afk
[12:03:44] --- wjp has changed the topic to: Exult: an open-source engine for Ultima 7: http://exult.sf.net/. No rabbits allowed in this channel. *evilgrinfluff*
[13:20:56] --> Colourless has joined #Exult
[13:20:56] --- ChanServ gives channel operator status to Colourless
[13:21:23] <Colourless> hi
[13:21:58] <wjp> hi
[13:25:26] <Colourless> wjp, thanks for testing that path stuff
[13:25:37] <Colourless> seems to confirm that it's a compiler issue
[13:25:58] <Colourless> question now is, what can we do?
[13:32:10] <Kirben> Colourless: btw latest exult studio update seems to use gtk function that doesn't exist under win32
[13:34:24] <Colourless> hmm
[13:34:38] <Colourless> what's the function?
[13:34:43] <Colourless> copy and paste stuff?
[13:35:41] <Kirben> not the cvs update just before that for version checking:
[13:35:43] <Kirben> g++ -O2 -fnative-struct -fvtable-thunks -Dsnprintf=_snprintf -DSIZEOF_SHORT=2 -D
[13:35:43] <Kirben> NG_H -DHAVE_FREETYPE2 -I. -I./shapes -I./mapedit -I./imagewin -I./files -I./head
[13:35:43] <Kirben> ers -I./server -I./objs -I./conf `pkg-config --cflags gtk+-1.3-win32-production`
[13:35:43] <Kirben> `pkg-config --cflags libglade-0.17` `pkg-config --cflags freetype2` -c -o stud
[13:35:44] <Kirben> io.o ./mapedit/studio.cc
[13:35:46] <Kirben> ./mapedit/studio.cc: In method `void ExultStudio::info_received(unsigned char *,
[13:35:48] <Kirben> int)':
[13:35:50] <Kirben> ./mapedit/studio.cc:2232: implicit declaration of function `int gdk_timeo
[13:35:55] <Kirben> ./mapedit/studio.cc: In method `void ExultStudio::info_received(unsigned char *,
[13:35:56] <Kirben> int)':
[13:35:58] <Kirben> ./mapedit/studio.cc:2232: implicit declaration of function `int gdk_timeout_remo
[13:36:00] <Kirben> ve(...)'
[13:36:18] <Kirben> gdk_timeout_remove doesn't seem to exist in the includes
[13:36:35] <Colourless> i'll have a look
[13:36:44] <Colourless> i'll attempt to look at what jeff was doing
[13:39:14] <Colourless> ah yep, i see what he did
[13:39:27] <Colourless> now to work out what it should be
[13:40:45] <Colourless> simple. should be gtk_timeout_remove not gdk_timeout_remove
[13:41:42] <Colourless> i think i'll commit all my changes
[13:42:26] <Kirben> ok
[13:43:31] <Colourless> they will cause things to die horribly with mingw path bug, but it strictly speaking doesn't appear to be 'our' problem
[13:44:34] <Colourless> auto converting to short filenames doesn't work when attempting to create a new file, which is where the crash when starting a new game was occuring
[13:45:03] <Colourless> if i remove the auto convert, it crashes when attempting to start a game
[13:45:15] <Colourless> (after choosing at the exult menu)
[13:45:59] <Colourless> oddly enough, the crash only occurs when attempting to read from or write to the files. it doesn't occur when opening
[13:46:09] <Colourless> when writing the file also gets created
[13:46:33] <Colourless> buffer overrun perhaps?
[13:48:14] <Colourless> wouldn't make much sense though. why only win9x, why only mingw
[13:55:24] <Kirben> no idea
[13:57:11] <Kirben> try mingw mailing list I guess
[13:59:12] <Kirben> http://sourceforge.net/mail/?group_id=2435
[14:07:15] <Colourless> ok, i'll try
[14:07:35] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:46:59] <wjp> hey, coder_infidel is in the mingw ML archives
[14:47:19] <wjp> haven't heard from him in ages
[15:05:52] <Colourless> this is.... strange
[15:07:35] <Colourless> it quite literally makes no sense
[15:08:01] <Colourless> i'm writing a little 'test' app to see if i can find where the problem is occuring
[15:08:14] <Colourless> and it appears something is going horribly wrong in U7file somewhere
[15:08:28] <Colourless> the problem is, what's going wrong isn't making sense
[15:08:55] <Colourless> an unmodified u7open is causing a crash when attempting to close the file
[15:09:24] <wjp> on what filename exactly?
[15:09:56] <Colourless> c:\\ultima vii - the black gate & serpent isle\\serpent\\gamedat\\testfile.txt
[15:10:35] <wjp> oh, btw, something that I forgot to mention in my post on the forum: it _did_ seem to work if I had U7 in "G:\ultima 7 the black gate\"
[15:11:00] <wjp> (without a second-level directory, and without an &)
[15:11:56] <wjp> hm, on what line does it crash exactly?
[15:12:29] <Colourless> it crashes when doing out.close();
[15:13:04] <Colourless> however, get this, if i put in a return statment before the line where the exception get thrown by u7open(ofstream &out,...) there is not crash
[15:13:11] <Colourless> s/not/no/
[15:13:25] <Colourless> also, the exception isn't getting thrown when the line isn't there
[15:13:35] <wjp> hm, what file is this in?
[15:14:01] <Colourless> files/utils.cc
[15:14:15] <wjp> and the out.close()?
[15:14:27] <Colourless> in my own test file
[15:14:34] <wjp> could you dcc that?
[15:16:13] <Colourless> actually, it's crashing after the close
[15:16:59] <wjp> I assume you just do something like:
[15:17:27] <Colourless> it's just this:
[15:17:27] <Colourless> int main(int argc, char *argv[])
[15:17:27] <Colourless> {
[15:17:27] <Colourless> std::ofstream out;
[15:17:27] <Colourless> std::cout << "U7open(out, ...);" << endl;
[15:17:28] <Colourless> U7open(out, "c:\\ultima vii - the black gate & serpent isle\\serpent\\gamedat\\testfile.txt");
[15:17:29] <Colourless> out << "stuff" << endl;
[15:17:31] <Colourless> std::cout << "out.close();" << endl;
[15:17:33] <Colourless> out.close();
[15:17:36] <Colourless> std::cout << "closed" << endl;
[15:17:38] <Colourless> return 0;
[15:17:39] <Colourless> }
[15:17:40] * wjp nods; that :-)
[15:19:02] <wjp> do you have gdb or something like that?
[15:19:18] <Colourless> no i don't
[15:19:52] <wjp> so when you run this with the unmodified U7open, what is the last debug output shown?
[15:20:02] <Colourless> actually i do have it
[15:20:03] <wjp> (and is the string 'stuff' actually written to the file?)
[15:20:42] <Colourless> Directory C:\uc\exult>pathtest
[15:20:42] <Colourless> U7open(out, ...);
[15:20:42] <Colourless> out.close();
[15:20:42] <Colourless> closed
[15:21:14] <Colourless> i'll put it inside a func called be main to see if the func is even returning
[15:21:41] <wjp> brb
[15:24:28] <Colourless> after putting that code in a function called do_it() and changing main to this:
[15:24:29] <Colourless> int main(int argc, char *argv[])
[15:24:29] <Colourless> {
[15:24:29] <Colourless> std::cout << "calling doit" << endl;
[15:24:29] <Colourless> do_it();
[15:24:29] <Colourless> std::cout << "returned from doit" << endl;
[15:24:30] <Colourless> return 0;
[15:24:32] <Colourless> }
[15:24:58] <Colourless> "returned from doit" isn't displayed
[15:36:00] <wjp> ok, so it's probably crashing when out goes out of scope
[15:36:07] <Colourless> yeah
[15:36:17] <wjp> what happens when you don't explicitly close it?
[15:36:50] <wjp> I guess the next thing to do is reducing U7open to a minimum
[15:37:07] <wjp> (and moving it into the same testfile, so it will form a nice small testcase for the mingw devels)
[15:37:31] <Colourless> still crashes without out.close()
[15:38:13] <Colourless> comment out 'throw' line in u7open, no crash
[15:38:29] <wjp> but is the throw line actually used?
[15:38:47] <Colourless> no
[15:39:06] <Colourless> i'll try turning off optimizations
[15:39:08] <wjp> what happens when you change the file_open_exception to a standard exception?
[15:40:30] <Colourless> still crashed with standard exception
[15:40:50] <wjp> ok, and if you throw out all the uppercasing code?
[15:41:14] <wjp> (slowly eliminating all exult-related things :-) )
[15:42:16] <Colourless> changing things to:
[15:42:17] <Colourless> // int uppercasecount = 0;
[15:42:17] <Colourless> // do {
[15:42:17] <Colourless> out.open(name.c_str(), mode); // Try to open
[15:42:17] <Colourless> if (out.good())
[15:42:17] <Colourless> return; // found it!
[15:42:19] <Colourless> // out.clear(); // Forget ye not
[15:42:21] <Colourless> // } while (base_to_uppercase(name, ++uppercasecount));
[15:42:23] <Colourless> has no effect
[15:43:14] <wjp> ok, then the get_system_path call is the last remaining bit of exult code?
[15:43:53] <Colourless> nope, also didn't help
[15:44:02] <Colourless> BUT getting rid of the string did stop the crash
[15:44:16] <wjp> hmm...
[15:44:29] <wjp> maybe it's illegal to call out.open with a name.c_str()?
[15:44:49] <Colourless> i wouldn't think so
[15:45:18] <wjp> can you create a one-file testcase from this and dcc that to me?
[15:46:01] <Colourless> adding a return after the throw also stops the crash
[15:46:46] <wjp> hm, try changing string name = ... to string* name = new string(...)
[15:47:37] <Colourless> that was also fine
[15:47:48] <wjp> I wonder if it would cause problems if the string goes out of scope before the out does
[15:47:57] <wjp> s/the out/out/
[15:48:10] <wjp> out probably still has a pointer to name.c_str
[15:48:39] <Colourless> i don't think so
[15:48:42] <wjp> although I can't imagine what it would use it for
[15:48:57] <Colourless> i think the stack is getting really screwed up somehow
[15:49:12] <wjp> it does sound an awful lot like a compiler error
[15:51:47] <Colourless> no optimizations, no crash
[15:52:28] <wjp> so... use a string* for now as a workaround?
[15:52:57] <Colourless> or add a return statement AFTER the throw statement
[15:53:03] * wjp nods
[15:54:05] <Colourless> it might be picking up a strange obsurce bug
[15:54:23] <wjp> what gcc version are you using?
[15:54:41] <Colourless> gcc version 2.95.3-6 (mingw special)
[15:55:57] * wjp wonders what the bug-reporting procedure for mingw is
[15:56:09] <Colourless> i'll see if i can put it all in a single file
[15:57:32] <wjp> I wonder what filenames exactly cause the crash
[15:57:43] <wjp> a certain length, an &, spaces?
[15:57:45] --> Dark-Star has joined #exult
[15:57:48] <wjp> hi
[15:57:54] <Colourless> i'll check
[15:58:02] <Dark-Star> hi
[15:58:41] <wjp> I wonder if string changes its behaviour when it reacher 32 or 64 or something bytes
[15:58:47] <wjp> s/reacher/reaches/
[16:04:36] <Colourless> only removing the '&' didn't do anything
[16:04:50] <Colourless> but removing '& Serpent Isle' worked
[16:05:39] <wjp> that reduces the length to below 64 bytes, btw
[16:05:55] <wjp> (63, in fact)
[16:06:30] <Colourless> c:\\ultima vii - the black gate & s\\serpent\\gamedat\\testfile.txt
[16:06:32] <Colourless> doesn't crash
[16:06:36] <Colourless> but
[16:06:45] <Colourless> c:\\ultima vii - the black gate & se\\serpent\\gamedat\\testfile.txt
[16:06:45] <Colourless> does
[16:07:13] <wjp> what if you replace the directory name by 1234567890123456890etc...?
[16:07:49] <wjp> or if you remove the subdirectory levels and just replace it by one long directory?
[16:07:55] <Colourless> 0123456789012345678901234567890123456789012345678901234567890123456789
[16:07:57] <Colourless> ???
[16:08:07] <wjp> yeah :-)
[16:08:23] <wjp> or anything without any strange characters of the same length
[16:08:24] <Colourless> crash
[16:08:56] <Colourless> 0123456789012345678901234567890123456789012345678901234567890123456789.txt - crash
[16:09:08] <wjp> ok, this should produce a nice and clean testcase
[16:09:35] <Colourless> btw there is no exult code. i'm compiling simply with:
[16:09:36] <Colourless> g++ pathtest.cpp -O
[16:10:07] <wjp> and that contains main, do_it and U7open, I guess?
[16:10:29] <Colourless> yep
[16:10:41] <Colourless> 012345678901234567890123456789012345678901234567890123456789.txt causes a crash
[16:10:44] <Colourless> 01234567890123456789012345678901234567890123456789012345678.txt doesn't
[16:11:20] <wjp> that's 64/63 chars
[16:12:06] <Colourless> want the file?
[16:12:09] * wjp nods
[16:13:44] <wjp> does it still crash if you remove the is_text, and rename the function to open_file?
[16:14:15] <wjp> and then you just need to use std::endl ;-)
[16:14:34] <Colourless> still crashes
[16:14:59] <wjp> ok, I guess you should mail it to the mingw-users mailing list then
[16:15:43] <wjp> yikes, 18:15 already
[16:15:43] <Colourless> don't even need to write anything to the file
[16:15:49] <wjp> I have to go home
[16:16:30] <Colourless> cya]
[16:16:44] <-- wjp has left IRC ("gtg")
[16:31:14] <-- Dark-Star has left IRC ()
[16:32:43] --> wjp has joined #exult
[16:32:43] --- ChanServ gives channel operator status to wjp
[17:18:09] <Colourless> yay, i can now start a new game in win98 exult using a long path
[17:18:50] <Colourless> i wonder if this 'bug' might have been problems anywhere else
[17:22:12] <wjp> that weird issue with compressed large savegames comes to mind
[17:24:06] <Colourless> yeah maybe
[17:24:21] <Colourless> i was also thinking maybe it would even cause corrupted save games
[17:24:54] <Colourless> of course we don't even know what the problem actually is
[17:25:15] <wjp> I wonder if that latest corrupted savegame thread in the forum will result in anything
[17:26:04] <wjp> my guess would be that the savegame he's starting from is already corrupted, but it just doesn't show until he saves a couple of times more
[17:53:41] <Colourless> got an email back from someone on the mingw mailing list and the problem isn't occuring gcc 3.1
[17:57:40] <wjp> that's good
[18:01:59] <wjp> heh, the includes aren't shown in the mailing list archives :-)
[18:02:08] <wjp> I guess they're interpreted as html tags or something :-)
[18:02:32] <Colourless> includes?
[18:02:38] <wjp> #include <iostream>
[18:02:49] <Colourless> heh
[18:03:01] <wjp> it's like that literally in the page source, so the <iostream> isn't displayed... oops :-)
[18:03:29] <Colourless> hmm, url for the page?
[18:03:44] <wjp> the geocrawler archives are ok, though
[18:04:04] <wjp> http://sourceforge.net/mailarchive/forum.php?thread_id=778142&forum_id=5119
[18:04:24] <Colourless> hehe
[18:05:04] <wjp> that's probably exploitable, too
[18:05:21] <Colourless> i would imagine so
[18:05:40] <wjp> #include <script language="javascript"> ;-)
[18:05:52] <Colourless> really badly too
[18:06:15] <Colourless> i'm thinking you need to send a report to sourceforge about it :-)
[18:16:22] --> Fingolfin has joined #exult
[18:16:28] <wjp> hi
[18:17:10] <Fingolfin> yo
[18:17:11] --- ChanServ gives channel operator status to Fingolfin
[18:17:18] <wjp> Colourless: yeah, I think so too :-)
[18:18:20] <Colourless> hi
[18:18:42] * wjp wonders if there's a specific place to report problems with the SF beta mail archives
[18:24:36] <Fingolfin> yeah
[18:24:40] <Fingolfin> SF bug reporter
[18:24:45] <Fingolfin> err that is
[18:24:56] <Fingolfin> I think they shut it down, you are supposed to use the support request tracker
[18:25:05] <wjp> yeah, but not for security-related issues
[18:25:23] <Fingolfin> or you can go to irc.slashnet.org #sourceforge and ask there, but moorman will tell you to file an SR first :-)
[18:25:26] <Fingolfin> oh
[18:25:33] <Fingolfin> then go to that channel and msg moorman
[18:25:49] <Fingolfin> I am there always anyway :-)
[18:26:19] <Fingolfin> you could poke precision or coax or mccombs, too, they all work for SF
[18:26:38] <wjp> hm, this doc page says I should send email to staff@sourceforge.net
[18:26:46] <wjp> s/should/could/, or something like that :-)
[18:26:54] <Fingolfin> sure you can do that too, as you prefer
[18:27:09] <Fingolfin> I just htought that you might prefer IRC :-) but as you wish
[18:27:17] <wjp> yeah, I generally do :-)
[18:39:58] <wjp> hm, #sourceforge there is quite a busy channel, isn't it? :-)
[18:40:14] <wjp> thanks for the intro, btw :-)
[18:47:20] <Fingolfin> hehe sure
[18:47:26] <Fingolfin> [20:41 Uhr] <moorman> wjp sent in his issue
[18:47:26] <Fingolfin> [20:41 Uhr] <moorman> wjp++;
[18:49:29] <wjp> :-)
[18:49:48] * wjp == anonimity + 1 :-)
[18:50:55] <Colourless> so, what are they going to do about it?
[18:53:32] <Fingolfin> can somebody tell me now what "it" is? I would like to crack SF :-)
[18:53:48] <wjp> just read the logs :-)
[18:54:01] <wjp> you won't be able to crack SF with it, though
[18:54:09] <Fingolfin> damn :-)
[18:54:23] <wjp> hm, I might have been able to do it, but too late now
[18:54:36] <Fingolfin> ohhh
[18:54:47] <Fingolfin> dinner time!
[18:55:11] <wjp> enjoy :-)
[18:55:38] * wjp should go back to attempting to study for his cryptography exam
[19:21:08] --> Dark-Star has joined #exult
[19:21:16] <Dark-Star> hi again
[19:21:51] <Colourless> hi
[19:21:56] <wjp> hi
[19:25:48] <-- Fingolfin has left IRC ("reboot, bbl")
[19:52:07] <Dark-Star> nothing goin on... I'll leave ;-)
[19:52:10] <Dark-Star> bye
[19:52:20] <-- Dark-Star has left #exult ()
[20:33:59] --> Fingolfin has joined #exult
[20:47:27] <Colourless> time for me to leave
[20:47:47] <-- Colourless has left IRC ("cya")
[20:51:49] <-- Darke|afk has left IRC (calvino.openprojects.net irc.openprojects.net)
[20:53:45] --> Darke|afk has joined #exult
[21:04:04] --- Darke|afk is now known as Darke
[21:04:29] <wjp> hi
[21:06:49] <wjp> Darke: I just applied one of Robbe's gcc3.1 patches, and it touched part of ucxt. Could you check if everything's still ok?
[21:07:01] <wjp> (in particular it removed an #include <strstream>)
[21:11:27] <Darke> *nod* It shouldn't have a problem then, the <strstream> stuff was only in there for the exeptional cases where <sstream> didn't work.
[21:12:09] * Darke tests anyway. *grin*
[21:14:04] <wjp> hm, checking the patch again, it _only_ removed an #include <strstream>, in fact
[21:14:10] <wjp> (from ucxt.cc)
[21:15:37] <wjp> Colourless also found the 'spaces in pathnames' problem, btw. It turned out to be 'pathname longer than 64 characters' problem triggering a compiler error
[21:15:49] <wjp> s/be/be a/
[21:16:44] * Darke checks ucxt. Seems to be working.
[21:17:04] <Darke> Cool.
[21:50:08] --> Dark-Star has joined #exult
[21:57:31] <-- Darke has left IRC (calvino.openprojects.net irc.openprojects.net)
[21:57:56] --> Darke has joined #exult
[21:58:02] --- wjp gives channel operator status to Fingolfin
[21:58:19] <wjp> looks like Jeff wants to release RC2 now.. yay :-)
[21:58:41] <-- Darke has left IRC (calvino.openprojects.net irc.openprojects.net)
[21:59:25] --> Darke has joined #exult
[22:05:43] * Darke makes a mental note that we need to include more 'slack' in pentagrams numbering scheme, if we ever get to the point we have a version 1.0 of it. *grin*
[22:05:56] <wjp> :-)
[22:06:19] <wjp> maybe we should just lay out the numbering scheme now, while there's still room :-)
[22:06:36] <wjp> 0.01-0.79: pre-pre-pre-alpha's
[22:06:41] <wjp> 0.80-0.89: alphas
[22:06:50] <wjp> 0.90-0.99: betas
[22:06:55] <wjp> 0.99.1-0.99.9: RCs
[22:06:55] <wjp> 1.0: 1.0
[22:07:01] <wjp> ?
[22:07:35] <Dark-Star> how about "0.99-RC2" to "0.99-RC23"...?
[22:07:39] <wjp> hm, the cvs version numbers have to fit in somewhere, too
[22:07:51] <Dark-Star> why add another ".1"?
[22:08:07] <wjp> because mozilla does it? :-)
[22:08:34] <wjp> I'd prefer to keep the main numbers sufficient to identify the release
[22:08:47] <wjp> so you don't need the 'text' part
[22:10:52] <Dark-Star> ok, sounds reasonable. so how about constantly using 3 numbers after the 1.0 release? x.0.0 for major releases, 1.x.0 for "minor" releases and "1.3.x" for RCs?
[22:11:57] <wjp> after 1.0? too far away for me :-)
[22:12:52] * Darke crosses his legs and ponders pentagram's numbering scheme.
[22:13:13] * Darke begins to levitate off the ground.
[22:13:34] * Darke thinks it's just one of those days, isn't it? *grin*
[22:14:47] <wjp> :-)
[22:15:00] * wjp ties Darke to the floor to keep him from floating away
[22:15:51] <Darke> Umm... thanks. *noddlenod*
[22:15:54] * wjp then notices the channel topic and cuts the rope ;-)
[22:18:05] * Darke eeps! and pouts. No fair!
[22:21:00] <Fingolfin> I still don't see what problems you guys have with rabbits. It's getting harder and harder to explain to mine why they have to stay outside
[22:22:03] <Dark-Star> talking about Pentagram: I just read the design docs for the "new" pentagram and I wondered if you have already thought about the interfaces for the various classes? will you stick to the "old" methods? or redesign them?
[22:22:24] <wjp> redesign
[22:23:08] <Dark-Star> cool, maybe I'll find some time to think about the interfaces... if you don't mind, that is ;-)
[22:23:39] <wjp> of course I don't mind :-)
[22:24:32] <Dark-Star> maybe that's something where I can contribute :)
[22:24:52] * Dark-Star starts printing out some docs
[22:53:57] <Dark-Star> ok I'll go get some sleep now, need to get up again in 6 hours :-(
[22:53:58] <Dark-Star> bye
[22:54:31] <-- Dark-Star has left #exult ()
[22:55:13] <wjp> I got a couple of savegames for the disappearing pikeman
[22:55:26] * wjp wonders if he can reproduce it now
[22:55:38] <Darke> Good luck!
[22:56:17] * wjp gets all depressed by the huge amount of usecode that scrolls by
[23:00:12] <wjp> hm, tried it twice. Pikeman is still there
[23:03:03] <wjp> thrice...
[23:09:03] <Darke> Weird.
[23:13:21] <wjp> ugh, 11000 lines of usecode debugging output
[23:13:41] <wjp> I should implement object access breakpoints into my debugger :-)
[23:14:54] * Darke snickers. That _could_ be a good idea...
[23:28:21] * Darke wonders if Dominus will use any of the suggestions outlined in here: http://www.wired.com/news/culture/0,1284,52901,00.html to make the exult documentation more interesting. *grin*
[23:28:46] <wjp> hm, is that that /. story?
[23:28:59] <Darke> Yep.
[23:34:24] <-- Fingolfin has left IRC ("good night")
[23:48:17] * Darke grumps. You get some really cryptic error messages when you sub-subclass from classes with pure virtual functions, if you mess up.
[23:51:01] <Darke> Saying that it can't find the 'vtable' in class 'Foo', is really not all that helpful an error message. *grin*
[23:52:31] <wjp> is Foo the subclass?
[23:56:44] <Darke> It was 'Bar : public Foo', 'Foo : public Base', 'Base'. Base had two pure virtual functions, Foo 'overrode' them, without actually declaring them pure virtual, and never actually providing a implementation of them, and added one function (implemented), then Bar actually provided it's implementation of the two originally pure virtual functions.
[23:57:28] <wjp> hm, error seems to make at least some sense, then
[23:58:39] <Darke> Kind of. It told me the two lines containing the error, were in a completely different place and file to where the error was, which had nothing to do with the error, and never actually touched any of the classes involved. *grin*
[23:59:10] <wjp> hm, I guess it would be hard to actually point to a specific line for this error :-)