#pentagram@irc.freenode.net logs for 20 Jul 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[01:45:19] --> Kirben has joined #pentagram
[01:45:19] --- ChanServ gives channel operator status to Kirben
[02:39:18] <-- SB-X has left IRC (Read error: 104 (Connection reset by peer))
[03:07:18] --> SB-X has joined #pentagram
[03:08:24] <-- SB-X has left IRC (Client Quit)
[04:15:21] --> Cashman has joined #pentagram
[04:15:30] * Cashman jacks in
[04:24:27] <Cashman> hey Darke
[04:30:44] <-- Cashman has left IRC ()
[09:51:00] --> Fingolfin has joined #pentagram
[09:51:00] --- ChanServ gives channel operator status to Fingolfin
[11:03:37] --> wjp has joined #pentagram
[11:03:37] --- ChanServ gives channel operator status to wjp
[11:04:50] <wjp> hi
[11:05:44] <Fingolfin> yo
[11:09:10] --> CashZzz has joined #pentagram
[11:09:17] --- CashZzz is now known as Cashman
[11:23:36] <-- Cashman has left IRC ()
[11:49:49] <wjp> Colourless: it looks like 'spawn' isn't supposed to cede after all
[11:50:26] <wjp> it's about the only thing I can think of that makes crumbling floors work properly
[11:50:52] <wjp> (class 525 (COLLAPSE), gotHit())
[11:53:49] <wjp> I still rather dislike the thought of running a process from outside the main kernel run loop, but I don't really see an alternative
[11:56:59] --> Colourless has joined #Pentagram
[11:56:59] --- ChanServ gives channel operator status to Colourless
[11:57:26] <Colourless> hi
[11:57:32] <Colourless> wjp: the spawn stuff
[11:57:32] <Fingolfin> hi
[11:57:40] * wjp notices his Colourless-summonning ritual worked :-)
[11:57:44] <wjp> hi :-)
[11:58:41] <Colourless> the more i look at some of the things that i 'think' the original did, i fell that spawning processes, even by code, should cause the processes to execute right away
[11:59:42] <Colourless> things like the fastArea, and animation processes. To me, it would make more sense if they executed right away
[12:00:10] <Colourless> but, for those i don't think it matters much
[12:02:26] <Colourless> anyway, what exactly did you do with 'spawn'
[12:02:37] <Colourless> there may be another method
[12:03:31] <wjp> well, nothing permanent yet
[12:03:55] <wjp> just testing a bit to see if it would indeed make crumbling floors work
[12:05:08] <Colourless> i'm thinking this might work:
[12:05:37] <Colourless> new processes placed to front of the process 'stack'
[12:05:56] <Colourless> the spawning process placed behind it
[12:06:41] <Colourless> so if the new process suspends or finishes or something, the caller will be able to continue executing
[12:07:00] <wjp> slightly hard to do, though
[12:07:29] <wjp> since the caller is the current process in the main run loop
[12:07:45] <Colourless> change the way the loop works perhaps
[12:08:09] <Colourless> how exactly i don't entirely know
[12:08:17] <wjp> me neither
[12:08:27] <wjp> can't get the next process in advance, since that might change too
[12:10:01] <wjp> the original didn't really have a process run loop, did it? Just wired things into a timer
[12:10:03] <Colourless> could change what the process return code does
[12:10:20] <Colourless> no the original used interrupts to run it's processes
[12:10:59] <wjp> so we should be able to run processes outside of our loop
[12:11:14] <wjp> maybe have addProcess automatically run a process
[12:11:28] <Colourless> yeah, maybe
[12:11:50] <wjp> (won't work in the UCProcess case, btw)
[12:11:53] <wjp> but then UCProcess::load() could run itself)
[12:12:34] <Colourless> why not change the UCProcess load stuff
[12:12:47] <Colourless> bah, now i remember, obj id needs to be assigned
[12:12:52] <Colourless> ok, like this
[12:13:06] <wjp> pid, actually
[12:13:07] <Colourless> addProcess() calls an init or load function
[12:13:24] <Colourless> really, we don't need the framenum arg to the run() function
[12:13:40] <wjp> no
[12:13:49] <Colourless> CoreApp::getFrameNum() can just be used
[12:14:09] <Colourless> i'll need to make a 'minor' change to GUIApp but that shouldn't matter
[12:14:32] <Colourless> thinking about it framenum should be incremented before running the gumps and processes, not after
[12:15:07] * wjp nods
[12:15:08] <Colourless> of course i could argue it either way
[12:15:28] <Colourless> perhaps we should have 2 addProcess functions
[12:15:36] <Colourless> an addProcess and an addProcessExec
[12:16:10] <Colourless> i would much prefer that immediate execution was only done when called by usecode
[12:16:38] <Colourless> or if otherwise required
[12:16:39] <wjp> yes, since then we'd still be inside the main run loop
[12:19:00] <wjp> brb, getting some lunch
[12:25:04] <wjp> back
[12:32:46] <Colourless> wb
[12:33:16] <Colourless> something we could also do, is assign a pid in the Process constructor
[12:39:48] <wjp> yes
[12:40:07] <wjp> no real reason to wait with assigning a pid
[12:41:18] --> Cless has joined #Pentagram
[12:41:46] <-- Colourless has left IRC (Killed (NickServ (ghosted: Cless!Cless@ppp625.adelaide.on.net.au)))
[12:41:48] --- Cless is now known as Colourless
[12:41:50] --- ChanServ gives channel operator status to Colourless
[12:44:35] <Colourless> why does it seem that we are never making 'small' updates to pentagram... no when we need to fix bugs, big changes are needed :-)
[12:47:16] <Darke> Good design/code/planning? *grin*
[12:47:46] <Darke> That and we're at least trying not to 'hack' a solution into the codebase. *grin*
[12:50:49] <wjp> well, the good part is that the "big" changes are usually very localized :-)
[12:51:21] <Colourless> localized to a single dir :-)
[12:53:53] <Darke> Always useful. *grin*
[13:13:28] <wjp> *phew*... finally finished compiling gcc 3.2.3
[13:13:53] * wjp proceeds with glibc 2.3.2
[13:14:09] * Darke is already onto gcc3.3. Slowcoach. *grin*
[13:14:16] <Colourless> do you then have to recompile gcc with the new version of glibc too?
[13:14:25] <Colourless> :-)
[13:14:46] <wjp> heh :-)
[13:14:49] <Colourless> then recompile glibc with the version of gcc compiled with the new glibc
[13:14:57] <Colourless> then repeat :-)
[13:15:21] <wjp> well, gcc's functionality won't change when you compile it with a newer glibc
[13:15:40] <Colourless> it might become faster... or smaller... or use less memory
[13:15:54] <Colourless> then again, it might do the exact opposite :-)
[13:15:57] <wjp> sure, but you won't need to recompile anything compiled with the 'old' gcc
[13:16:06] <wjp> since gcc's output will be exactly the same
[13:16:22] <wjp> ('old' = new gcc compiled with old glibc)
[13:16:39] <Colourless> no, probably not
[13:16:44] <Colourless> really you just need to relink
[13:17:04] <wjp> building gcc is a multi-stage process, though
[13:17:15] <wjp> first build it with the old gcc, then build it again with the newly built one
[13:17:53] <Colourless> ah ha, so it does rebuild itself using itself
[13:26:42] <Darke> From memory it's three stages, stage0 builds a minimally compliant ansi-c compiler from whatever the system has, stage1 builds a 'full' gcc/c, then stage2 rebuilds gcc/c along with whatever else you want built. Pity there isn't a FAQ or something around detailing exactly how it bootstraps itself, I think it'd be insteresting reading (but then again, I'm a geek *grin*).
[13:28:46] * Darke Is Not A Geek though. When he was a kit he was kitnapped by a family of squirrels who taught him the way of OoooooShinnnnyThingie! and he's never been the same again! *nodnodnod*
[13:29:00] <Colourless> DING?
[13:29:12] <Colourless> Darke Is Not a Geek?
[13:29:52] <Darke> DarkING?
[13:31:10] <Darke> DarkING: A proceess where one becomes *completely* insane. This usually consists of programming, furryness, and being surrouded by lunatics. (Present company excluded of course. *cough*)
[13:31:55] <Colourless> :-)
[13:32:15] <Colourless> of course we are not lunatics. Lunatic implies related to the moon
[13:34:48] <Darke> Well... strangely enough... that's where it comes from. *grin* 'They' believed that insanity fluctated with the phases of the moon, thus the name.
[13:34:55] <Fingolfin> ho ho ho - not so fast, Colourless! speak for yourself
[13:42:35] <-- Colourless has left IRC ("brb")
[13:47:09] --> Colourless has joined #Pentagram
[13:47:09] --- ChanServ gives channel operator status to Colourless
[13:47:41] * Darke gasps! Fingolfin is Tuxedo Mask?!?
[13:47:57] * Darke quickly hides before he gets kicked for that comment. *grin*
[13:48:26] * Fingolfin sneaks behind Darke, taps him on the shoulder, and when Darke turns around, shouts "BOOO"
[13:48:59] * Darke yelps and scurries under the nearest couch! Hey! That's not nice!
[13:50:05] <Fingolfin> what! and uncovering my secret identiy is nice, eh??
[13:50:07] <Fingolfin> tsk
[13:50:50] * Fingolfin wanders off to tell Sailor Moon about Darke's misbehaviour
[13:51:20] <Colourless> hehe
[13:51:56] * Darke pouts!
[13:52:56] * Colourless attempts to not make the pout/perr joke
[13:53:30] * Darke can't make any comments either, else they'll be gratuously taken out of context and dropped into the quotes file too!
[13:57:24] * Darke yawns and thinks sleep is probably a good option at the moment, since he needs to be up in 6 hours or so. Night!
[13:57:31] --- Darke is now known as DarkeZzz
[13:57:47] <Colourless> night
[14:01:07] <wjp> night
[14:11:00] <wjp> ok, I'll go rewrite some of the process stuff I guess
[14:11:10] <wjp> step 1: assign pid in process constructor
[14:20:53] * wjp yawns while pentagram is trying to get compiled
[14:21:36] <wjp> (compiling glibc in the background isn't helping much)
[14:24:58] <wjp> step 2: do the load() part of a UCProcess in the UCProcess constructor
[14:58:08] <wjp> step 3: addProcessExec...
[15:01:10] <wjp> step 4: _using_ addProcessExec ;-)
[15:01:24] <Colourless> :-)
[15:03:35] <-- Fingolfin has left IRC ("42")
[15:09:27] * wjp hmms
[15:09:30] <wjp> I broke something :-)
[15:15:11] <Colourless> :-)
[15:15:17] <Colourless> you really surprised?
[15:15:32] <wjp> <indignant look>yes!</look> ;-)
[15:15:57] <Colourless> error parsing tags
[15:16:14] <wjp> you must not have the fuzzy tags module ;-)
[15:16:32] <Colourless> :-)
[15:17:12] <Colourless> i guess that should be converted to <look type="indignant">yes!</look> by the 'fuzzy tags' module
[15:19:19] <wjp> impressive... a process is failing to access its own stack
[15:19:36] <wjp> (through a usecode pointer)
[15:19:43] <Colourless> hmm
[15:20:26] <wjp> ah... forgot to uncomment something
[15:20:54] <wjp> much better
[15:20:56] <wjp> now to fix loading
[15:49:00] <-- Colourless has left IRC ("bbl")
[17:40:27] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[21:25:54] --> Colourless has joined #Pentagram
[21:25:56] --- ChanServ gives channel operator status to Colourless
[21:26:16] <Colourless> b :-)
[21:26:18] <Colourless> but not for a 'huge' amount of time
[21:54:52] <wjp> wb :-)
[22:07:45] <wjp> crumbling floors are working fine now, btw
[22:07:54] <Colourless> cool
[22:08:00] <wjp> had to put in a bit of a hack to prevent processes from getting 2 pids when loading, though :/
[22:08:16] <wjp> (since the default Process() constructor is also used to construct processes when loading)
[22:34:23] <wjp> speaking of paths.... Vividos does some interesting things :-)
[22:34:51] <wjp> I'm hoping it's just caused by the canGetThere instrinsic (or whatever it's called)
[22:35:08] <Colourless> lets FLY around the map :-)
[22:35:14] <Colourless> wall? what wall!
[22:35:19] <wjp> floor? what floor!
[22:35:28] <wjp> tombstone? :-)
[22:36:23] <wjp> the biggest "issue" is when he moves up and down between the first and second floor
[22:37:42] --> Fingolfin has joined #pentagram
[22:37:42] --- ChanServ gives channel operator status to Fingolfin
[23:06:03] <-- Colourless has left IRC ("casts invisibility")
[23:17:26] <-- wjp has left IRC ("Zzzz...")