#pentagram@irc.freenode.net logs for 3 Nov 2002 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:18:10] <-- Dark-Star has left IRC ()
[00:21:55] --- Darke|zzZ is now known as Darke
[00:26:22] --- ChanServ gives channel operator status to Darke
[00:29:21] <-- wjp has left IRC ("Zzzz...")
[05:22:51] --> Colourless has joined #Pentagram
[05:22:51] --- ChanServ gives channel operator status to Colourless
[05:23:18] <Darke> Hi!
[05:23:23] <Colourless> hi
[06:39:00] <-- Darke has left IRC (adams.freenode.net irc.freenode.net)
[06:40:09] --> Darke has joined #pentagram
[07:48:53] <-- Colourless has left IRC (Read error: 110 (Connection timed out))
[11:11:50] <Darke> Rambling thoughts: How do we handle 'errors' inside the pentagram engine? This may run from the potentially terminal (critical datafile corruption) to just annoying (the thread that's disassembling the usecode into a gump 'breaks' for some reason and wants to be restarted).
[11:13:28] <Darke> One thought I had was some sort of 'MessageThread'. It just collects warnings/errors/messages sent by all the threads and processes them within it's alloted timeslice. (For example restarting the disassembler thread, or popping up a message box saying "Engine terminated due to error in $file.").
[11:14:14] <Darke> It's somewhat more cleaner then my original thought of having a queue<ErrorMessages> that the main loop processes if it's ever non-empty. *grin*
[11:20:07] <Darke> Oh, also, I don't suppose the world is going to end if disasm spits out a '7A end' instead of a '79 end' for u8's disassembled output? *grin* I don't forcee any problems, unless someone's got some L33t Sup3r Cr1t1c41 code that relys on it. *grin*
[11:33:46] --> wjp has joined #pentagram
[11:33:46] --- ChanServ gives channel operator status to wjp
[12:03:06] <wjp> I don't think I have any l33t sup3r cr1t1c4l code relying on the disassembly being entirely correct, btw :-)
[12:17:14] <Darke> No problem. You can't be too careful around l33t sup3r cr1t1c41 code, y'know. *grin*
[12:41:15] --> Colourless has joined #Pentagram
[12:41:15] --- ChanServ gives channel operator status to Colourless
[12:41:41] <Colourless> hi
[12:57:47] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[13:01:05] --> Kirben has joined #pentagram
[13:01:05] --- ChanServ gives channel operator status to Kirben
[13:39:52] * Darke glares distanefully at his code, wondering if he should ramble at length in here as to how he abstractly 'envisages' the basic setup of things to work in the Process loop, rather then do actual work getting somewhere close to being able to do it. *grin*
[13:40:21] <Colourless> :-)
[13:40:30] <Colourless> talking is always interesting
[13:40:39] <wjp> coding too, for that matter :-)
[13:40:58] <Colourless> no, coding is not always interesting :-)
[13:41:03] <Darke> It's been one of those "urgh, I really don't want to touch this code" weeks for me unfortunately. *grin* Of course it happens exactly when I've got _plenty_ of time to code!
[13:41:10] <wjp> neither is talking, if you're nitpicky ;-)
[13:41:32] <Colourless> wjp, the perfect example
[13:41:42] <wjp> yes, I was just thinking the same thing :-)
[13:43:51] <Darke> Ok, here's my thoughts as to how Things Work(tm) (at least in my mind anyway *grin*). We have multiple UsecodeMachines to allow us to disallow some of the higher level functions happening during the game (such as shape conversion, mounting random directories onto our filesystem, etc).
[13:44:41] <Darke> UsecodeMachineAlpha (for lack of a better name) is our 'key' machine it's the one that runs the Main Menu, handles converstion of data, and eventually spawns the 'WorldManager' and the other UsecodeMachines to handle each specific game when you start it.
[13:45:00] <Colourless> You know Darke, you could just use protection levels :-)
[13:45:10] <Colourless> Ring0, Ring1, Ring2... etc :-)
[13:45:41] <wjp> aieeeee
[13:45:42] * Darke points to 'abstract'. *grin* He's thought of that, but there may be reasons not to use that setup.
[13:45:44] * wjp runs away in disgust
[13:45:56] <Colourless> :-)
[13:46:20] <Darke> (UCMAlpha) We can allow it full control to do 'anything', but we can set it up so that it'll only run 'our' scripts, which we make sure work reliably. Because if this UCM dies, it takes the entire engine with it. *grin*
[13:46:58] <wjp> so we want to implement the entire interface in usecode?
[13:47:17] * Darke wants to try. *grin* It should work and would certainly be a Good Thing IMO.
[13:47:54] <Colourless> the time critical stuff though will not be though
[13:48:25] <wjp> how exactly would event handling work? every gui object is a usecode class with 'usecode events' corresponding to click/mouseover/mouseout/double-click, etc...?
[13:48:30] * Darke nods. He expects we'll find bits and pieces that 'need' to be in raw code.
[13:48:39] <Colourless> wjp: yes pretty much
[13:49:08] <Darke> *nod* You can just derive it from a base class that handles the basic functionality. Look at the BARREL series of classes.
[13:49:30] <wjp> we just need to find a clear separation between usecode and C++ code. It would be very bad/confusing if things were randomly divided between usecode and C++
[13:50:31] <Darke> Pretty much.
[13:50:53] <Darke> Of course, no matter what we have that problem. *grin*
[13:51:04] <Darke> Even if we don't use the 'menu in usecode' system.
[13:51:21] <wjp> true :-)
[13:52:21] * Darke has worked out in his head how buttons, etc would work in the menus, you can pretty much steal the code straight from the crusader in game button toggle code. *grin*
[13:55:03] --> Dark-Star has joined #pentagram
[13:55:36] <wjp> stealing code from crusader would not be a good thing :-)
[13:55:59] <wjp> btw, is anyone working on a usecode8 compiler?
[13:56:11] <wjp> or an unk compiler, or whatever
[13:58:12] <Darke> When I think about it, if you had all the frames of a button in the same order (frame0=unpressed, 1=pressed, 2=highlighted,...) you could just have a generic Button class and the only thing you'd have to handle would be the actual 'click' event.
[13:58:51] * Darke 'is', kinda. *grin* He's using the same core as his decompiler, and just needs to write the front end to it, it just keeps getting perpetually delayed. *grin*
[14:35:17] <-- Dark-Star has left #pentagram ()
[14:39:11] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[15:45:49] <Darke> Colourless: With Console, I don't suppose there's any way of getting it to redirect stdout to say an OTextDataSource or OFileDataSource? I know you can Console::Dump() but that only dumps the last 'x' lines.
[15:46:18] <Colourless> Darke: not yet, but it would be trivial to change
[15:48:49] <Darke> No problem. I was just wondering if there was an 'easy' way of doing it, since I was just about to juggle cout through my fold output functions when I remembered that using cout was the Wrong Thing. *grin*
[15:50:01] <wjp> oh, right, I was going to look at that endl problem
[15:50:13] <wjp> Darke: when you run shapeconv without arguments, do you get a trailing endline?
[15:50:18] <Darke> I should be ok juggling references to pout through my functions? It just 'works' like cout doesn't it?
[15:50:36] <Darke> wjp: IIRC yes. I noticed that yesterday. Just a sec and I'll double check
[15:50:37] <Colourless> yes it works just like cout :-)
[15:50:45] <Colourless> explain problem
[15:50:56] <wjp> [wjp@aldur ~/pentagram/pentagram/tools/shapeconv]$ ./shapeconv
[15:50:56] <wjp> Usage: ShapeConv <inflx> <outflx> [-u8tocru|-crutou8][wjp@aldur ~/pentagram/pentagram/tools/shapeconv]$
[15:51:09] <Colourless> that might be a problem :-)
[15:51:17] <Darke> Same here: Usage: ShapeConv <inflx> <outflx> [-u8tocru|-crutou8]darke@darkepaw:~/code/pentagram/tools/shapeconv
[15:51:19] <Colourless> Directory C:\UC\pentagram>ShapeConv.exe
[15:51:20] <Colourless> Usage: ShapeConv <inflx> <outflx> [-u8tocru|-crutou8]
[15:51:20] <Colourless> Directory C:\UC\pentagram>
[15:51:21] <wjp> there's also an empty line between the first prompt and the 'usage', string, btw
[15:51:39] <wjp> so the endl may have switched places with the rest of the text somehow :-)
[15:51:53] <Colourless> ah, i think i know what the problem might be....
[15:52:18] <wjp> hm, case mismatch
[15:52:30] <wjp> "usage" says "ShapeConv", while binary is named shapeconf
[15:52:35] <wjp> s/f/v/
[15:53:13] <Colourless> well, if you named it shapeconv, but when i named it ShapeConve.... :-)
[15:53:23] <wjp> I guess that would be my mistake when creating the module.mk
[15:53:31] <Colourless> s/ShapeConve/ShapeConv/
[15:53:50] <Darke> But then it would be inconsistant with the naming of the other utilities. *grin*
[15:54:00] <Colourless> the endline problem would be my fault... call it trying to be 'too' clever
[15:54:12] <Darke> Everything else would need to be in StudlyCaps too. *grin*
[15:55:08] <wjp> I'd prefer binaries to be entirely lowercase
[15:55:18] <Colourless> well, it put it into caps since Disasm.cpp was in caps, and then i decided that the program executable should have the same case as the source file
[15:55:28] <Colourless> s/well, it/well, I/
[15:57:29] <Colourless> do you want to try commenting out lines 148 through 152, and lines 200 through 204 in Console.h
[15:58:03] * Darke points out that the only reason that Disasm is in caps, is that he intends upon turning it into a class called Disasm with a stub main() to call it. Like what he's doing with fold at the moment. *grin*
[15:58:16] <Colourless> :-)
[15:58:36] * Darke mumbles something about deriving them from a Process class in the future and having them play nicely with time slices.
[15:58:40] <wjp> Colourless: still broken
[15:59:04] <wjp> hm, or maybe it didn't rebuild everything
[15:59:13] <wjp> no, it's working now
[16:00:28] <Colourless> Darke: hows it for you?
[16:00:59] <wjp> this is weird
[16:01:10] <Darke> Haven't tried it yet. *grin* Just a sec.
[16:01:14] <wjp> it doesn't rebuild the right files when Console.h is touched
[16:01:57] <wjp> or rather, it doesn't rebuild the right files when building from the tools/shapeconv dir
[16:05:01] <Darke> Works for me.
[16:05:20] <Darke> (the console modifications that is, not building from the shapeconv dir. *grin*)
[16:05:31] * wjp was just about to ask :-)
[16:05:37] <Colourless> if someone is going to commit something soon, can they just remove those lines
[16:06:20] <wjp> I'm probably going to commit a change to the build system sometime soon :-)
[16:06:24] <wjp> (at least, I hope I'm going to)
[16:06:33] <Darke> Gimmie another week and I might get around to committing this tree. *grin* AKA, I'll let someone else do it. *grin*
[16:06:47] <Colourless> Darke: i suggest it be you. I just know how much like conflicts :-)
[16:07:28] <Darke> If it's only touching Console.* it doesn't worry me in the slightest. *grin*
[16:10:50] * Darke hunts under the couch for the opcode he just lost. Damn init, always slipping through my claws.
[16:12:55] <wjp> very peculiar... make thinks that Q_strcasecmp.o only depends on Q_strcasecmp.cpp
[16:13:09] <wjp> while the dependency file properly lists all dependencies
[16:14:37] <wjp> I wonder if make is confused by paths like tools/disasm/../../misc/Console.h
[16:16:54] <Darke> Wouldn't surprise me. *pounder* I don't suppose it's possible for the 'make' in the root directory to get the path to the root dir and pass it up the chain? That way you could have something like `$(ROOT)/misc/Console.h` rather then `../../misc/Console.h`. It might confuse make less. *grin*
[16:17:09] <wjp> yes, that's what I was thinking too
[16:17:53] * Darke actually suggests something like $(R) rather then the full 'ROOT', less 'intuitive', but it'll make some of the more complex includes clearer to read. *grin*
[16:19:11] * Darke hugs his init. Yay! Found it again!
[16:19:57] * Darke ummms... and goes to hide in the corner. He suspects he's in one of those 'keep him away from the keyboard!' frame of minds at the moment. *grin*
[16:20:14] * Colourless drags Darke back
[16:20:22] <Colourless> you are doing work, and you should keep doing it
[16:20:54] * Darke yelps! And strangely enough, he is. *grin* 'tis the only real reason he's still here, his mind is coherent enough to code.
[16:23:33] * wjp hmms... I think I see why this doesn't work
[16:24:03] <wjp> all those ..'s must really be confusing make
[16:27:39] <wjp> it doesn't realize that tools/shapeconv/../../misc/Args.o and tools/disasm/../../misc/Args.o are in fact the same file
[16:59:21] * Darke yawns loudly. This bunny thinks it's time for sleep. *grin* Night!
[16:59:40] --- Darke is now known as Darke|zzZ
[17:00:42] --> Dark-Star has joined #pentagram
[17:02:01] <Colourless> i think i should go too
[17:02:03] <Colourless> cya
[17:02:04] <wjp> g'night
[17:02:07] <-- Colourless has left IRC ("casts invisibility")
[18:19:52] <-- Dark-Star has left IRC (Read error: 110 (Connection timed out))
[18:20:11] --> Dark-Star has joined #pentagram
[18:53:01] <-- Dark-Star has left #pentagram ("Client Exiting")
[19:22:32] --> Dark-Star has joined #pentagram
[20:14:04] <-- wjp has left IRC (Remote closed the connection)
[20:17:52] --> Dominus has joined #pentagram
[20:19:44] --> wjp has joined #pentagram
[20:21:30] --- Dominus is now known as gigdr
[20:21:37] --- gigdr is now known as Dominus
[20:22:01] --- ChanServ gives channel operator status to wjp
[21:31:33] <-- Dark-Star has left IRC ("Client Exiting")
[23:17:44] --> SpamBuck has joined #pentagram
[23:19:31] <wjp> hi
[23:19:53] <SpamBuck> hi
[23:23:08] <-- SpamBuck has left IRC ("ChatZilla 0.8.7 [Mozilla rv:1.0.1/20020826]")