#pentagram@irc.freenode.net logs for 31 Jan 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:13:03] --> Fingolfin has joined #pentagram
[00:13:03] --- ChanServ gives channel operator status to Fingolfin
[01:43:21] --> Kirben has joined #pentagram
[01:43:21] --- ChanServ gives channel operator status to Kirben
[01:52:00] <-- wjp has left IRC (Read error: 104 (Connection reset by peer))
[01:52:31] --> wjp has joined #pentagram
[02:05:54] <-- Fingolfin has left IRC ("42")
[09:12:13] --> Thaqui has joined #pentagram
[10:36:56] --> Colourless has joined #Pentagram
[10:36:56] --- ChanServ gives channel operator status to Colourless
[10:37:23] <Colourless> hi
[10:47:38] <-- servus has left IRC ("Client exiting")
[10:56:57] <-- Thaqui has left IRC (Read error: 110 (Connection timed out))
[11:12:23] --> Thaqui has joined #pentagram
[12:36:39] --- ChanServ gives channel operator status to wjp
[12:55:31] <-- Thaqui has left IRC (Read error: 110 (Connection timed out))
[13:12:33] --> Thaqui has joined #pentagram
[15:04:06] --> Dark-Star has joined #pentagram
[15:12:38] <-- Thaqui has left IRC (Read error: 60 (Operation timed out))
[15:13:13] --> Thaqui has joined #pentagram
[16:04:32] <-- Kirben has left IRC ("System Meltdown")
[16:25:01] <-- Thaqui has left IRC (Read error: 110 (Connection timed out))
[16:48:23] --> Fingolfin has joined #pentagram
[16:48:23] --- ChanServ gives channel operator status to Fingolfin
[16:49:19] <Fingolfin> holla
[16:49:26] <Colourless> gu!
[16:49:35] <Darke> Gnu!
[16:50:00] <Fingolfin> Hurd?
[16:51:12] <Darke> I must say I prefer bison, really.
[16:52:24] <Fingolfin> well you know, these days you gotta be flex'ible
[16:52:41] <Fingolfin> (wow, that was low :-)
[16:53:22] * Colourless trys to avoid looking at the horror
[16:53:38] * Darke will have to let Colourless take his place in the bad-pun competition tonight. He's too sleepy to create something lower then that at the moment. *grin*
[16:57:26] <Fingolfin> yeah, hard to beat me at crap humor!
[16:57:37] <Fingolfin> not a surprise that Darke chickens out, really
[16:58:29] <Darke> Yup! I know better then to lower myself to that level. *grin*
[16:58:50] <Fingolfin> I am not sure if I mentioned this before, but for me, pentagram locks up when I press "ESC"
[17:00:26] <Colourless> well, it's supposed to quit when you press ESC
[17:00:35] <Fingolfin> yeah
[17:00:39] <Fingolfin> and it dies in the cleanup (or rather, hangs)
[17:00:45] <Fingolfin> #0 0x90017048 in semaphore_wait_signal_trap ()
[17:00:45] <Fingolfin> #1 0x90002300 in pthread_mutex_lock ()
[17:00:45] <Fingolfin> #2 0x0124fda8 in SDL_mutexP (mutex=0x57c7440) at SDL_sysmutex.c:124
[17:00:45] <Fingolfin> #3 0x00059e90 in LowLevelMidiDriver::peekComMessageType() (this=0x57c7440) at audio/midi/LowLevelMidiDriver.cpp:256
[17:00:46] <Fingolfin> #4 0x0005a138 in LowLevelMidiDriver::destroyThreadedSynth() (this=0x57c7710) at audio/midi/LowLevelMidiDriver.cpp:329
[17:00:48] <Fingolfin> #5 0x00059a68 in LowLevelMidiDriver::destroyMidiDriver() (this=0x1) at audio/midi/LowLevelMidiDriver.cpp:115
[17:00:51] <Fingolfin> #6 0x00069ae0 in GUIApp::deinit_midi() (this=0x2148ed0) at kernel/GUIApp.cpp:367
[17:01:49] <Colourless> interesting
[17:02:15] <Fingolfin> indeed
[17:02:18] <Fingolfin> hm
[17:02:27] <Fingolfin> let me check if it really hangs there, or if it's in an endless loop
[17:03:51] <Colourless> might be a bug
[17:04:57] * Darke thinks it's just that Fingolfin's hitting the ESC key the wrong way, that's all. *nodnod*
[17:05:10] <Fingolfin> /kick Darke
[17:05:15] <Fingolfin> oops, space in the wrong spot
[17:05:26] <wjp> or maybe ESC just works differently on macs :-)
[17:05:27] <Fingolfin> anyway, I verified, it's stuck in the lock, not in an endless loop
[17:05:50] <Colourless> yeah wouldn't make sense if it was an endless loop
[17:05:59] <wjp> hm, add some code to see what's holding the lock?
[17:06:17] <Colourless> Fingolfin, try defining DO_SMP_TEST
[17:06:40] <Colourless> actually, it wont be that useful
[17:06:56] <Colourless> since many of the giveinfo() calls are gone
[17:07:16] <Colourless> ah fouund the problem :-)
[17:07:44] <Colourless> line 545 of LowLevelMidiDriver()
[17:07:55] <wjp> heh -)
[17:07:57] <Colourless> it 'returns' without calling unlockComMessage
[17:07:59] <wjp> s/-/:-/
[17:09:27] <Colourless> so either a call to that needs adding or replace the return with a break and add code to set the return value
[17:10:33] <wjp> I'd go with the latter
[17:11:01] <Fingolfin> or, do it like in ScummVM, and do locking using StackLocks =)
[17:11:11] <Fingolfin> much easier to write code which doesn't forget to unlock a lock this way =)
[17:11:17] <Colourless> :-)
[17:11:27] <wjp> object with a destructor that unlocks?
[17:11:39] <Fingolfin> indeed.
[17:11:44] <Fingolfin> see common/util.h in scummvm source
[17:11:57] <Fingolfin> (class StackLock)
[17:12:26] <Fingolfin> the "use auxillary object on stack to free a resource" thing is one of the classical neat C++ "tricks" :-)
[17:12:41] <Fingolfin> also works fine for pointers (Std C++ lib has autoptr for this) and other things :-)
[17:12:57] <Fingolfin> and of course, it also works fine if you use exceptions...
[17:13:11] <Fingolfin> anyway, I can now exit pentagram just fine. thanks
[17:13:23] --> Thaqui has joined #pentagram
[17:13:29] <Colourless> yeah well i'm amazed it worked on any system :-)
[17:15:00] <Colourless> now, StackLock is kind of interesting
[17:15:37] <Colourless> though it may cause problems with 'odd' compilers
[17:16:05] <Colourless> depends on when the constructor is called
[17:16:51] <Colourless> of course if it works with ScummVM i don't think there is a problem
[17:17:11] <Fingolfin> actually
[17:17:17] <Fingolfin> it should work fine in any C++ compiler
[17:17:27] <Fingolfin> the C++ spec is *very* strict about the order in which constructors are called
[17:17:41] <Fingolfin> it works fine even in MSVC6! :-)
[17:18:08] <Fingolfin> the constructor for a stack object will be called once the definition line of the object is reached, and not before.
[17:18:18] <Colourless> yeah, older compilers though (say MSVC5) don't always works as expected
[17:18:34] <Fingolfin> which is why using stack objects inside a switch/case construct generates at least a warning in GCC (because it's not well defined)
[17:19:07] <Fingolfin> I would expect it to be correct even in 10 year old C++ compilers...
[17:19:32] <Colourless> i'm pretty sure it is MSVC 5 (or maybe another version) that constructs everything when the function is entered
[17:19:52] <Colourless> but i'm not entirely sure
[17:19:52] <Fingolfin> well, I would expect it to work correct exactly as much as I expect subclassing to work. Of course both could be broken, but both are fairly central features of C++ right from the start :-)
[17:20:04] <Fingolfin> anyway
[17:20:06] <Colourless> this is something i read some 7 or 8 years ago
[17:20:09] <Fingolfin> I would not bother about MSVC5 :-)
[17:20:14] <Colourless> :-)
[17:20:22] <Fingolfin> in fact I wouldn't even bother about MSVC6 support, to be honest. It's just too broken
[17:20:27] <Colourless> we aren't :-)
[17:21:18] <Fingolfin> anyway. One of these days I need to convince Endy to let us use the Std c++ lib in Scummvm <sigh>
[17:21:41] <Colourless> we use it everywhere in pentagram :-)
[17:21:46] <Fingolfin> I know
[17:21:53] <Fingolfin> I use it everywhere in every other C++ app, too :-)
[17:21:54] <Colourless> of course to such a level that it wont compile with gcc versions pre 3
[17:22:34] <Fingolfin> what I would do with it would work in GCC 2.95, too. Or probably MSVC6... like, make very basic use of std::string, map, list, vector, set... <sigh>
[17:22:46] <Darke> Which, like MSVC6, we don't particularly care about. Though this does cause a problem with Zaraus, apparently.
[17:23:06] <Darke> I've been using those since gcc2.81, so I'd guess you'd have no problems. *grin*
[17:24:16] <Colourless> our problems because of things like char_traits that the stl support in gcc 2.x don't have
[17:25:20] <Colourless> means that the console streams wont work and the new 'istring' also wouldn't work either
[17:28:50] <Fingolfin> nothing I'd care about =)
[17:29:11] <Colourless> oh, but istring is oh so useful :-)
[17:30:46] <Fingolfin> I don't debate that... but IMO it's the wrong approach :-). If you want case insensitivt compares, then the container class or whatever it is that access the strings should have a compare trait =)
[17:30:52] <Fingolfin> at least that's how I did it for my Map class
[17:31:06] <Fingolfin> which can have arbitarary keys (like std::map), and a compare trait (again like std::map)
[17:31:14] <Fingolfin> matter of taste/view/religion I guess :-)
[17:31:49] <Colourless> well, the map having the case insenstive compare would probably end up being more useful
[17:32:19] <Colourless> the problem with istring is, as things currently are, there is no conversion to and from a std::string
[17:32:30] <Fingolfin> I first wanted to do a "IString" class, too. but then I run into problems with making stuff except both normal strings, and IStrings....
[17:32:34] <Fingolfin> exactly
[17:32:39] <Fingolfin> :-)
[17:33:01] <Fingolfin> the string is actually the same in each case. It's the client and how it uses the string, which is different
[17:33:13] <Fingolfin> which is why I opted to make the "client" (i.e. Map template) more flexible, not the string
[17:33:34] <Fingolfin> (I don't claim it's the best solution, it depends on your problem, of course :-)
[17:34:08] <Colourless> hey, i don't know the best solution either :-)
[17:36:39] <Colourless> another alternative could be to subclass basic_string with case insensitive operators
[17:37:00] <Colourless> how well that would work though i don't know
[17:47:49] <-- Darke has left IRC (Read error: 110 (Connection timed out))
[17:55:28] --> Darke has joined #pentagram
[17:57:36] <Fingolfin> hm
[17:58:03] <Fingolfin> this is a bit strange, the OS X exult 1.1b3 build is listed under "Older releases". Well of course it's older than 1.1.9rc1. But it's newer than 1.00... :-)
[18:00:05] <wjp> different branch :-)
[18:00:30] <wjp> the 'older than' operation isn't well-defined between branches ;-)
[18:06:53] <-- Thaqui has left IRC (Read error: 110 (Connection timed out))
[19:37:10] --> Thaqui has joined #pentagram
[20:42:17] <wjp> hm, the line breaking algorithm the original uses seems to be different from ours
[20:42:41] <Fingolfin> line breaking?
[20:42:49] <wjp> there's no text rectangle width that produces the same output as the original
[20:43:05] <wjp> yes, line breaking :-)
[20:43:25] <Colourless> probably got to do with justifying
[20:43:42] <Colourless> whether it would move a word to a new line or not
[20:46:36] <Colourless> the basic algorithm that i originally implemented was that it would let a string go over the length of the line
[20:46:49] <wjp> yeah, currently it won't
[20:46:57] <Colourless> and at the next space it would go to the next line
[20:50:49] <-- Thaqui has left IRC (Read error: 60 (Operation timed out))
[20:57:39] <wjp> maybe I'll have it minimize the deviation from the specified width
[21:15:09] <wjp> although I think it might be better to have it always stop before the width
[21:15:13] <wjp> makes fitting text
[21:15:20] <wjp> in a dialog box easier
[21:15:31] <wjp> (or in a savegame decription rectangle, or...)
[21:21:05] --> Dominus has joined #pentagram
[21:21:07] --- ChanServ gives channel operator status to Dominus
[21:31:43] <-- Colourless has left IRC ("casts invisibility")
[21:37:19] --> Thaqui has joined #pentagram
[22:26:51] <-- Dominus has left IRC ("a pooka invited me to Charlie's")
[22:45:25] <-- Thaqui has left IRC (Read error: 110 (Connection timed out))
[23:42:02] --> Thaqui has joined #pentagram