#pentagram@irc.freenode.net logs for 24 Jun 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[02:07:46] --> DraX has joined #pentagram
[02:14:32] <-- DraX has left IRC ("bye? ..(sph)")
[08:14:27] <-- DarkeZzz has left IRC (kornbluth.freenode.net irc.freenode.net)
[08:18:01] --> DarkeZzz has joined #pentagram
[08:18:40] <-- DarkeZzz has left IRC (kornbluth.freenode.net irc.freenode.net)
[08:20:38] --> DarkeZzz has joined #pentagram
[08:20:38] <-- DarkeZzz has left IRC (kornbluth.freenode.net irc.freenode.net)
[08:20:38] --> DarkeZzz has joined #pentagram
[08:21:42] --- ChanServ removes channel operator status from DarkeZzz
[09:00:19] <-- DarkeZzz has left IRC (kornbluth.freenode.net irc.freenode.net)
[09:04:16] --> DarkeZzz has joined #pentagram
[09:35:37] --> Kirben has joined #pentagram
[09:35:37] --- ChanServ gives channel operator status to Kirben
[12:03:37] --> Cashman has joined #pentagram
[12:22:46] <Cashman> hi
[12:44:19] --> Colourless has joined #Pentagram
[12:44:22] --- ChanServ gives channel operator status to Colourless
[12:45:51] <Colourless> hi
[12:49:36] --> wjp has joined #pentagram
[12:49:36] --- ChanServ gives channel operator status to wjp
[12:49:40] --- wjp is now known as wjp|busy
[12:49:43] <wjp|busy> hi
[12:52:03] <Colourless> hi
[12:54:17] <wjp|busy> you fixed the foreach loop in your local copy, right?
[13:03:10] <Colourless> ah yes
[13:03:18] <Colourless> i haven't committed
[13:03:47] * Cashman is happy with his new cooling - dropped the fsb 15 degrees and the cpu 11 degrees
[13:04:05] <Colourless> i was 'going to' execpt i need to remove some stuff
[13:07:45] * Cashman apologizes for the sudden ramdomness
[13:07:58] <Cashman> typo's hehe randomness
[13:08:12] <Cashman> ram-dom
[13:15:52] <-- Cashman has left IRC ()
[15:09:03] <-- Kirben has left IRC ("System Meltdown")
[15:09:07] <-- wjp|busy has left IRC ("bbl")
[15:09:58] <-- Colourless has left IRC ("casts invisibility")
[15:44:27] --> wjp has joined #pentagram
[15:44:27] --- ChanServ gives channel operator status to wjp
[16:27:17] --> Fingolfin has joined #pentagram
[16:27:17] --- ChanServ gives channel operator status to Fingolfin
[16:27:34] <Fingolfin> hey, I saw the max int/dex/str is hardcoded to be 35. wouldn't it make more sense to encode that (and the 650) into constants... if so... is there a naming convention for (global) constants?
[16:27:59] <wjp> no :-)
[16:28:15] <wjp> that's what all those //!! constant comments are for...
[16:28:17] <wjp> ;-)
[16:28:20] <wjp> we've been a bit lazy with that, I guess
[16:28:45] <wjp> not sure if they should really be constants, though, or just game-related variables
[16:28:51] <Fingolfin> hm. ok. how about something like kSomeConstant or cSomeConstant ?
[16:29:02] <Fingolfin> hm, in those specific case, they might be variables, indeed
[16:29:21] <Fingolfin> still, if one makes them constants now, it'll be later easier to find all places where they are used and change them to vars
[16:29:25] <wjp> we need to determine which constants are really constants, basically
[16:29:27] <wjp> yes
[16:29:32] <Fingolfin> true
[16:30:24] <Fingolfin> regarding the music, I wonder if the backend abstraction model will be more like the on in ScummVM, or the on in Exult
[16:30:39] <Fingolfin> it's by far easier to write MIDI backends in ScummVM than in Exult =)
[16:31:05] <wjp> Colourless was planning to use the exult ones, but change the interface
[16:31:07] <wjp> I haven't asked him about the details
[16:34:11] <Fingolfin> well
[16:34:35] <Fingolfin> the midi backend for MacOS isn't that great, because it only maps a subset of the midi controllers
[16:34:44] <Fingolfin> only those used by exult songs, to be precise
[16:35:02] <Fingolfin> would be interesting to discuss the merits of each approach
[16:35:14] <Fingolfin> Jamieson630 from the scummvm team might also be able to give some valuable insights...
[16:35:19] <wjp> pity Colourless left already
[16:35:23] <Fingolfin> his midi parser & output code looks very good to me
[16:36:12] <Fingolfin> not that I claim they are better than the ones in Exult
[16:36:26] <wjp> what exactly is required for midi output?
[16:36:30] <wjp> I have no idea really :-)
[16:41:04] <Fingolfin> well in the ScummVM backends, essentially there are just two functions that have to be defined for each backend (beside sthe usual init/deinit stuff of course)
[16:41:18] <Fingolfin> send, which takes a uint32, a single MIDI command
[16:41:31] <Fingolfin> and sysEx, which takes a pointer and a lenght: a variable length sysex
[16:41:54] <wjp> midi is some kind of bytecode-ish format I guess?
[16:41:56] <Fingolfin> the whole rest of the work, like parsing the MIDI data, is done by a single module which is portable
[16:42:03] <Fingolfin> a little...
[16:42:07] <Fingolfin> there are various "commands"
[16:42:27] <Fingolfin> note on, note off, form the core: start playing a note in a given channel, or stop it
[16:42:32] <wjp> parsing the MIDI data is before it gets sent to the backend?
[16:42:47] <Fingolfin> there are commands to change the instrument assigned to a channel, and modify various parameters (like the pitche bend, and lots of effects, etc.)
[16:43:09] <Fingolfin> in the case of ScummVM, yes. the parser also handles vairous formats
[16:43:16] <Fingolfin> in the exult case, it works more like this
[16:43:46] <Fingolfin> the midi data is parsed (because there are at least two different types of midi formats we have to support, IIRC). then new midi data is generated
[16:43:53] <Fingolfin> which is then passed to the backend, in a fire forget manner
[16:44:10] <Fingolfin> essentially that means teh backend has to parse the data *again* and then also come up with a way to play it async
[16:44:24] <Fingolfin> and make it possible for the front end to stop the playing music, and query its status
[16:44:35] <wjp> probably because the original lib exult used to play midi expected data in this format
[16:44:38] <Fingolfin> for some OSes this might be trivial, because the OS provides such a "fire&forget" MIDI playback API
[16:44:43] <Fingolfin> ineed, exactly
[16:45:03] <Fingolfin> problem is: with e.g. CoreAudio, there is no such API. For QuickTime, tehre is one, but it needs another format. etc
[16:45:03] <wjp> beos, and one of the windows midi apis has one of those too
[16:45:19] <Fingolfin> yeah but IIRC BeOS wants a midi file - so now you have to create a temporary file
[16:45:25] <Fingolfin> and we have two win drivers in Exult, IIRC
[16:45:29] <Fingolfin> one of them also parses the midi data
[16:45:45] * wjp nods; that's why I said "one of the windows apis" :-)
[16:46:00] <wjp> we have several midi backends writing a temp file, yes
[16:46:41] <wjp> would that still be possible with the scummvm way?
[16:47:09] <wjp> I guess not, right?
[16:47:35] <Fingolfin> ScummVM already has MIDI backends for: adlib (midi emulation with fmopl), coreaudio (MacOS), morphos, alsa, seq, quicktime, win, ypa1 (PalmOS). Exult has KMIDI (from KDE? don't know it), BeOS, Timidity, amiga -> all not in ScummVM. But I
[16:47:40] <wjp> (of course, another question is if you _want_ this to be possible :-) )
[16:47:50] <Fingolfin> it wouldn't be possible with ScummVM way
[16:47:51] <wjp> kmidi is kicked out
[16:47:55] <Fingolfin> but it also wouldn't be necessary =)
[16:48:13] <Fingolfin> I don't know about timidity, though, how one interfaces to that best
[16:48:27] <Fingolfin> and I don't claim the ScummVM way is necessarily the best, or even suitable, for pentagram
[16:48:34] <wjp> sdl_mixer has a libtimidity included, IIRC
[16:49:03] <Fingolfin> but IMHO it would be worth considering it. maybe we can make a ScummVM driver for timidity / amiga / KMIDI / BeOS, and share those between scummvm and pentagram, to the benefit of all =)
[16:49:34] * wjp nods
[16:49:48] <Fingolfin> having written midi backends for both exult and scummvm... the scummvm midi backends for QuickTime and CoreAudio look nice. I wouldn't want to touch the one in exult again, frankly, plus it sounds worse than doing playback via the highlevel QuickTime midi code
[16:50:17] <wjp> the audio system in exult needs some work :-)
[16:50:27] <Fingolfin> again, would be intersting to discuss this with ryan. and maybe also jamieson, the scummvm midi expert, could add in some bits, he knows much much more about this than I do =)
[16:51:34] <Fingolfin> seems a BeOS backend in ScummVM style should be easy enough
[16:52:06] <wjp> it would help if I still had access to beos :-)
[16:52:06] <Fingolfin> :-)
[16:52:38] <wjp> but that simply refused to boot after I upgraded my PC once
[16:52:38] <Fingolfin> maybe we can find some other BeOS folks to help with this... at the very least somebody who can compile & test any code we write based on specs <g>
[16:53:42] <wjp> I wonder if they have a gcc 3
[16:53:42] <Fingolfin> see also http://www.acm.uiuc.edu/bug/Be%20Book/The%20Midi%20Kit/
[16:53:42] <wjp> (since pentagram really won't work with gcc < 3)
[16:53:42] <Fingolfin> aye
[16:54:46] <Fingolfin> well I just mentioned it to counter the argument "oh but exult supports BeOS midi and ScummVM doesn't" :-)
[16:54:46] <wjp> beos doesn't look too hard, no
[16:57:51] <wjp> bbl, dinner
[17:23:03] <wjp> how is midi timing determined, btw?
[17:23:18] <wjp> does the backend receive the commands at the point it has to execute them?
[17:37:43] <Fingolfin> hm, let me look
[17:37:49] <Fingolfin> btw, from our midiparse_xmidi.cpp
[17:37:53] <Fingolfin> Much of this code is adapted from the XMIDI
[17:37:53] <Fingolfin> implementation from the exult project.
[17:37:56] <Fingolfin> :-)
[17:38:09] <wjp> :-)
[17:39:07] <Fingolfin> yes the timing is done from the playback thread (so this does require threading... in ScummVM we have APIs in the backend to create threads & mutexs, something Pentagram would need, too, I guess)
[17:42:58] <wjp> we use SDL, so we can just use SDL's threads/mutexes
[17:44:01] <Fingolfin> sure
[17:44:52] <wjp> I don't think it's likely we'll ever support non-SDL backend
[17:44:55] <wjp> s
[18:04:58] --> Colourless has joined #Pentagram
[18:05:01] --- ChanServ gives channel operator status to Colourless
[18:05:18] <Colourless> someone mention midi?
[18:05:20] <Colourless> :-)
[18:06:41] <Colourless> actually, Fingolfin, i haven't truely told anyone my plans. In Pentagram i would have 2 levels of midi drivers. A high level driver, one that would pass the an XMIDIEventList object, which the driver can then do what ever it like with (write as a file, play it using some un specified method)
[18:07:25] <Colourless> the alternative method, would be to use a 'low' level interface, (which would just be an implementation of a high level driver) that pretty much will just accept midi events as they are produced
[18:10:13] <Colourless> the low level interface would pretty much be as simple as the one from scummvm. open, close and send
[18:11:26] <wjp> wb :-)
[18:11:41] <wjp> <Colourless> someone mention midi? <-- I'm innocent! really! It was Fingolfin!
[18:11:43] <wjp> ;-)
[18:22:55] <wjp> would be nice to have the interface to the low-level ones somewhat compatible with the scummvm one
[18:38:08] <Fingolfin> I think there aren't to many ways to vary it anyway :-)
[18:38:26] <Fingolfin> Colourless: hiya, and good to hear.
[18:38:45] <Colourless> somehow, i do think it would be difficult to make such a simple interface incompatible
[18:39:06] <Colourless> only changes that i can think of is header names, and probably the base class name
[18:39:34] <Fingolfin> <g>
[18:40:12] <Colourless> and probably the way error messages are output
[18:40:53] <Fingolfin> yeah, but it should be trivial to adapt the driver implementations from ScummVM
[18:41:37] <Colourless> yes
[18:47:57] * wjp ummms
[18:48:02] <wjp> did you see the exult forum?
[18:48:22] <Colourless> when?
[18:48:29] <wjp> last hour or so
[18:48:53] <Colourless> hm, no i don't think so
[18:49:34] * Colourless ummms ti
[18:49:46] <Colourless> "Ultima X w/o Lord British might not be a bad thing" ;-)
[18:49:54] <wjp> no, the other one ;-P
[18:50:11] <Colourless> uh, so there is another topic :-)
[18:50:27] <Colourless> a strange concept
[19:12:14] <wjp> now that you mentioned Ultima X anyway, I'm really curious to see how that will turn out
[19:12:31] <Colourless> so am I
[19:12:31] <wjp> (not really from a "I want to play it" perspective, though)
[19:12:52] <Colourless> if it is single player, i am curious to know what the hell the plot would be
[19:12:56] <wjp> indeed
[19:13:10] <wjp> if they're just using the name Ultima for the name, or for the thought behind it
[19:13:20] <wjp> (thought/world/characters/plot/...)
[19:14:07] <Colourless> i'm thinking 2 reasons:
[19:14:19] <Colourless> 1) Name (Ultima) because it's well known to UO players
[19:14:32] <Colourless> 2) World for the same reason
[19:14:40] <wjp> yes, that would be my guess at this point too
[19:15:03] <Colourless> wouldn't surprise me if the avatar was not the players character, but it also wouldn't surprise me if he was :-)
[19:17:03] <wjp> the Avatar was teleported out of the armageddon blast by the Time Lord, and ready for UX :-)
[19:17:07] <Colourless> even though i may be aprehensive about how UX would be as a game, i can see myself buying and playing it, IF it's a single player game... got to have them all! :-)
[19:17:29] <wjp> I'll probably get it too, yes :-)
[19:18:05] <wjp> UX takes place on a different shard than U1-9! Another good reason
[19:18:08] <Colourless> yeah, i can forsee the avatar somehow surviving the blast
[19:18:15] <wjp> *cough* :-)
[19:18:30] <wjp> because of his virtue, the armageddon blast didn't harm the avatar
[19:18:43] <wjp> some wizard cast a spell to un-ascend the avatar
[19:18:47] <Colourless> maybe it didn't harm big g either :-)
[19:18:48] <wjp> you name it :-)
[19:18:50] <Colourless> now that would be funny
[19:20:25] <wjp> this brainstorming kind of makes me wonder if EA could be monitoring the ultima communities for a good reason to keep the Avatar ;-)
[19:21:51] <Colourless> EA would be stupid not to have noticed at least some continuing interest in the series by the community, even after 2 'bad' games.
[19:27:38] <wjp> hm, weird post to that thread
[19:28:15] <wjp> rumours that it'll be a MMORPG based on Unreal-Warfare
[19:28:31] <wjp> somehow that rings a bell
[19:29:01] <Colourless> that was the previous rumour
[19:29:12] <wjp> oh right, the one just after april 1, right?
[19:29:34] <Colourless> yeah
[19:29:42] <wjp> exult logs, 5 may 2003
[19:29:43] <wjp> :-)
[19:30:08] <Colourless> as you said 'just' after april 1 :-)
[19:31:05] <wjp> well, it went through a printed magazine, so that could cause a delay
[19:31:06] <Colourless> something to think about, the translated message didn't say massively multiplayer online rpg, it just said online rpg
[19:31:16] <wjp> true
[19:31:48] <Colourless> an online rpg, COULD be a RPG for example a console, that could be played coop over the interent
[19:31:53] <wjp> but the message you mentioned 5 may was: "For over a year now, Origin has been quietly woodshedding Ultima-X its new
[19:31:53] <wjp> MMORPG. And it?s going to surprise you. I can't say anything just yet except maybe three quick words: Unreal Warfare engine."
[19:32:39] <wjp> the source is probably the same; this was from UO Stratics too
[19:32:50] <Colourless> yes it was
[19:33:04] <Colourless> who knows thought
[19:33:45] <Colourless> the current quote on our forum has been translated to german back to english
[19:34:35] <wjp> the German message said "online RPG"
[19:35:26] <Colourless> yes, which was commenting about the original UO statics post
[19:36:34] <wjp> yes
[19:38:22] <Colourless> i can't be help remember the exult aprils fools joke
[19:38:28] <Colourless> s/be/but/
[19:41:58] <Colourless> we mentioned a new multiplayer game
[19:42:16] <Colourless> we also said "Work on Ultima VIII and IV just has begun"
[19:42:37] <Colourless> Ultima V and VI are well under way
[19:42:56] <Colourless> odd thing, since then, it may not be us, but such projects do seem to have occured :-)
[19:43:18] <wjp> heh, indeed :-)
[19:45:55] <Colourless> i think all that proves though is a year is a long time
[19:46:32] <wjp> is anyone doing a faithful U5 rewrite?
[19:48:05] <Colourless> don't know
[19:48:06] <wjp> other than that there's xu4, nuvie, exult, pentagram
[19:48:21] <wjp> (and uwadv)
[19:48:58] <Colourless> additionally tsshp which while primarily system shock, is also intended to be for uw1/2
[19:49:13] <Colourless> of course that's been around for 'years'
[19:50:09] <Colourless> we won't mention that 'L' word here, cause while that is UV it's not an engine rewrite, plus... it's 'L' :-)
[19:55:06] <wjp> XU4: "...you open your eyes to:" <space> "Segmentation fault"
[19:55:13] <wjp> maybe I didn't quite configure it right :-)
[19:55:48] <Colourless> :-)
[20:01:00] <Colourless> i keep thinking, i don't think that the unreal warfare engine would be entirely suited to be a MMORPG. Pure reason is the thing was designed to be a FPS game engine with multiplayer support
[20:01:23] <Colourless> MMORPG works very different to a MP FPS game
[20:03:50] <wjp> yeah
[20:04:07] * wjp wonders what he was working on on pentagram last
[20:04:27] * wjp also wonders what he's going to be working on next :-)
[20:04:58] <wjp> that pid change opcode maybe
[20:05:09] <Colourless> the biggies that no need doing: Pathfinding, AI
[20:05:18] <Colourless> s/no/now/
[20:05:29] <Colourless> Savegames :-)
[20:08:26] <wjp> std::map<uint16, std::pair<UCList*, uint16>> listHeap :-)
[20:09:11] <Colourless> oh nice :-)
[20:09:40] <wjp> I'm wondering if we need to do garbage collection on lists/strings
[20:10:00] <wjp> if not, we wouldn't need to store the pid for _every_ list/string, but just for the 'pid-changed' ones
[20:12:26] <Colourless> i would think that the usecode would do that
[20:12:43] <wjp> I'm still seeing some weird leaks, though
[20:17:03] <wjp> there are two "Goodbye." strings left in the heap after talking to Devon (when you say Goodbye right away)
[20:17:35] <Colourless> what does the usecode say?
[20:17:49] <wjp> I need to figure out where they're allocated first
[20:18:06] <wjp> hm, Devon's usecode is a bit of a mess; maybe I should try with a guard
[20:18:47] <wjp> ok, talking to guard:
[20:19:01] <wjp> AskGump on-screen now, string heap:
[20:19:07] <wjp> 3:Who are you?
[20:19:07] <wjp> 4:What is your duty?
[20:19:07] <wjp> 5:Where am I?
[20:19:07] <wjp> 6:Bye
[20:19:07] <wjp> 13:Who are you?
[20:19:08] <wjp> 14:What is your duty?
[20:19:10] <wjp> 15:Where am I?
[20:19:12] <wjp> 16:Bye
[20:19:34] <wjp> when I say bye, they're all gone
[20:20:20] <wjp> when I first ask "Who are you?", a Who are you? stays on the stack
[20:20:23] <wjp> s/stack/heap/
[20:21:42] <wjp> hm, I don't see where that extra one is from
[20:21:57] <Colourless> ask gump duplicates the strings
[20:22:04] <Colourless> but it frees htem
[20:22:13] <wjp> yes, I made it free them
[20:22:43] <wjp> but the one that remains is not on the heap yet when AskGump is active
[20:24:00] <wjp> maybe the 'remove slist' opcode is wrong
[20:24:59] <wjp> bingo
[20:25:11] <Colourless> yes?
[20:25:12] <wjp> it doesn't free the strings it removes
[20:26:51] <wjp> uh
[20:27:01] <wjp> how peculiar
[20:27:30] <wjp> "Who are you?" "Oh sorry, I thought you were still speaking to me"
[20:27:36] <Colourless> care to explain
[20:27:46] <Colourless> who?
[20:27:55] <wjp> Devon
[20:27:59] <wjp> on 'f'
[20:28:16] <Colourless> on 'f' ?
[20:28:21] <wjp> I must be doing something wrong :-)
[20:29:23] <Colourless> ya think :-)
[20:45:33] <wjp> hm, for some strange reason it would delete the current answer
[20:46:33] <wjp> ah
[20:47:53] <wjp> fixed now, I hope :-)
[20:48:20] <wjp> I was expecting removeString to free the string in one place, and not to free it in another
[20:49:40] <wjp> ok, no more leaks when talking to Devon a bit now
[20:56:38] <wjp> oh, right, now I remember :-)
[20:56:45] <wjp> the pid-changed string/lists aren't freed
[20:57:50] <wjp> so one way to deal with it would be adding the string/list/slist to a "free me" list
[20:58:49] <wjp> (belonging to the UCProcess)
[20:59:59] <wjp> would be much more efficient than storing the pid of each string/list and GC-ing
[21:00:18] <Colourless> indeed it would
[21:05:46] <Fingolfin> when would the strings then ultimately be deleted?
[21:05:56] <wjp> when the process terminates
[21:06:00] <Fingolfin> (I am sorry I know little about the modern pentagram workings - need to read up a lot =)
[21:06:20] <wjp> on terminate it'll just free everything in it's FreeMe list
[21:06:22] <Fingolfin> hm, are you talking about unique strings then?
[21:06:23] <wjp> s/it's/its/
[21:06:32] <wjp> unique in which way?
[21:07:08] <Fingolfin> well, I mean: obviously that approach wouldn't work if you could allocate infinitely many such strings - it will never shrink. so that sounds as if you talk about "static" data
[21:07:41] <wjp> there's a fixed size string heap
[21:08:11] <Colourless> global shared by all processes
[21:08:20] * wjp nods
[21:21:14] <wjp> ok, freeOnTerminate should work now
[21:22:23] <wjp> kind of hard to test, though... I don't think I've seen any uses of 6C in pentagram so far
[21:25:22] <wjp> ok, committed
[21:25:27] <wjp> all opcodes are implemented now :-)
[21:25:36] <wjp> (I'm not saying they'll work, but at least they're implemented :-) )
[21:32:32] <-- Colourless has left IRC ("casts invisibility")
[21:56:39] <Fingolfin> errrr
[21:56:40] <Fingolfin> inline virtual void print_bin(OBufferDataSource &o) const=0;
[21:56:46] <Fingolfin> an inline virtual function? uhmmm
[21:56:47] <Fingolfin> :-)
[21:56:54] <wjp> heh :-)
[21:56:59] <wjp> interesting :-)
[21:57:05] <Fingolfin> in fact, inline *and* abstract
[21:57:11] <wjp> amazing :-)
[21:57:29] <Fingolfin> no wonder GCC 3.3 with lots-of-warning on gives a warning - just wonder how it can compile that at all (I guess normally it ignores the "inline"
[21:57:47] <wjp> where is that, btw?
[21:58:05] <Fingolfin> in tools/fold/GenericNodes.h (I'll checkin my fix if it compiles fine)
[21:58:19] <Fingolfin> am compiling pentagram with all ScummVM warnings, minus -Wshadow, right now
[21:58:34] <wjp> shadow will probably be painful :-)
[21:58:53] <wjp> lots of x,y,z probably
[21:59:04] <Fingolfin> indeed
[21:59:14] <Fingolfin> partially was the reason for my "why I like member vars prefix" :-)
[21:59:24] <wjp> I guessed :-)
[22:04:05] <wjp> you'd have to have really impressive path prediction for an inline virtual method
[22:05:10] <Fingolfin> and even that could only work if all invocations of that method were "fixed"
[22:05:17] <Fingolfin> i.e. fully known target object type
[22:05:25] <wjp> i.e., _really_ impressive ;-)
[22:05:44] <wjp> (including user prediction ;-) )
[22:08:58] <DarkeZzz> Not all. Just one. gcc is allowed by the standard to only inline some invocations and put an uninlined copy in as well, as appropriate. *grin* Though in that case it's just a case of me not removing the inline as the code evolved. Strangely, that must have been a warning I missed turning on, since I haven't seen it and I've used gcc3.3 since release. *grin*
[22:11:59] <Fingolfin> any such specialised code would have to use some form of runtime type checking, though, in order to be correct, wouldn't it? I wonder if that would grant any speed gain... replace a function invocation by inlined code (read: bigger code, less locality) and a (possibly complicated) type/vtable check with conditional jumps
[22:12:03] <Fingolfin> doesn't sound like a good strategy to me
[22:12:23] <Fingolfin> and in the case of a pure virtual method, you might not even know any partial implementation at any given time
[22:16:21] <wjp> we recently started using doxygen, btw, if you want to read up a bit :-)
[22:16:31] <wjp> http://www.math.leidenuniv.nl/~wpalenst/pentagram
[22:16:45] <wjp> not all classes are documented yet, but we're working on it :-)
[22:17:03] <DarkeZzz> Hmm... but wouldn't you be able to do that at compile time (especially if you had a simple enough class heirachy), with unit at a time compiling? *thinks*
[22:18:57] <Fingolfin> DarkeZzz: well you could for a given, *very simple* piece of code perform inlining, if you have the full type information for the given object ready at compile time. but that code really would have to be very simple. Like. "Foo object; object.pure_virtual_method();". Then of course it could inline the code even for a pure virtual method. and maybe it even does if you have auto-inlineing on... :-)
[22:19:01] <DarkeZzz> Erf. No, you'd probably have to handle it at link time somehow with a smart linker, and even then it would only be 'easy' (in a relatively speaking way *grin*) for rather simple class trees.
[22:19:49] <wjp> time for me to go
[22:19:50] <wjp> night
[22:19:55] <DarkeZzz> Night!
[22:20:04] <Fingolfin> DarkeZzz: my point
[22:20:13] <-- wjp has left IRC ("Zzzz...")
[22:21:06] * DarkeZzz thinks that one of these days someone needs to write a language that's actually easy to compile for. *grin*
[22:36:41] <Fingolfin> there are plenty. problem is, all of them are research language. and for most C/C++ programmers, it's hard to write in them :-)
[22:38:50] <DarkeZzz> Or for that matter s/write/do something useful/. *grin* I've seen too many 'research' languages that people are claiming are useful for real world applications, that just... well... aren't. *grin*
[22:59:12] * DarkeZzz waves and slips off to work. Bye!
[23:38:36] <-- Fingolfin has left IRC ("42")