[00:41:10] --> Kirben has joined #pentagram
[00:41:11] --- ChanServ gives channel operator status to Kirben
[01:23:40] <-- wjp has left IRC ("Zzzz...")
[05:33:25] <-- Kirben has left IRC (capek.freenode.net irc.freenode.net)
[05:33:25] <-- DarkeZzz has left IRC (capek.freenode.net irc.freenode.net)
[05:34:39] --> Kirben has joined #pentagram
[05:34:39] --> DarkeZzz has joined #pentagram
[08:04:37] <-- DarkeZzz has left IRC ("Inficio-Infeci-Infectum")
[08:13:13] --> Darke has joined #pentagram
[08:13:13] --- ChanServ gives channel operator status to Darke
[10:46:48] <-- Darke has left IRC ("Inficio-Infeci-Infectum")
[13:23:32] --> Colourless has joined #Pentagram
[13:23:32] --- ChanServ gives channel operator status to Colourless
[13:27:59] --> wjp has joined #pentagram
[13:27:59] --- ChanServ gives channel operator status to wjp
[13:43:43] <wjp> you wanted to make the main world renderer/map/thingie a gump, right?
[13:44:26] <wjp> makes sense in a way; all rendering (map and otherwise) would be restricted to gumps
[14:08:49] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[15:12:45] <Colourless> yes
[15:45:03] --> Darke has joined #pentagram
[15:45:04] --- ChanServ gives channel operator status to Darke
[17:24:40] * wjp oopses
[17:24:56] <wjp> every process needs a pid, it seems; not just usecode processes
[17:24:58] <Colourless> what are you on about?
[17:25:03] <Colourless> yes that is true
[17:26:33] <wjp> hm, the only reason seems to be that usecode can wait for them, right? (and get a return value)
[17:26:42] <Colourless> yes
[17:27:23] <Colourless> things like getting the player to select conversation choices is probably be main example of getting a return value from a non usecode process
[17:27:27] <wjp> yes
[17:27:41] <wjp> that's why I stumbled on it now :-)
[17:27:59] <wjp> I thought maybe that would be a nice intrinsic to implement, so we could actually interact a bit
[17:28:20] <Colourless> what do you mean?
[17:28:46] <wjp> running actual conversations would be nice
[17:28:53] <Colourless> ah
[17:29:00] <Colourless> i see
[17:29:01] <wjp> would be a good way to test some more of the interpreter too
[17:29:12] <Colourless> it would be a bit of a pain :-)
[17:29:19] <Colourless> but possible none the less
[17:29:33] <wjp> it would require doing 'implies' too
[17:29:36] <wjp> *sigh* :-)
[17:30:11] <Colourless> all i know about implies is it takes 2 processes, and does something to them
[17:30:14] <wjp> do you think it would be safe to assume that only one process can be waiting for a specific process at any given time?
[17:30:31] <wjp> my guess about implies is that it makes one wait for the other, and gets the return value of the one that finishes
[17:31:08] <Colourless> yes possible. most of the time it's always the current process, and the created process. but sometimes, it's 2 created processes
[17:31:26] <wjp> hm, in the execution scene?
[17:31:30] <Colourless> yes
[17:31:58] <Colourless> strange thing with the execution scene
[17:32:33] <Colourless> it's got a spawn inline, but i know for certain that the spawned code does not entirely halt the execution of the originally process
[17:33:10] <wjp> do you have a specific code location in mind?
[17:33:32] <Colourless> just a second
[17:34:16] <Colourless> ah ha
[17:34:37] <Colourless> i see. the spawn inline is part of the implies that takes 2 created processes
[17:34:55] <Colourless> the spawn inline is at A38
[17:35:09] <Colourless> the second spawn is at A49
[17:35:17] <Colourless> the implies is at A53
[17:35:38] <wjp> hm, yes
[17:35:56] <Colourless> there is actually 4 spawns and 2 implies statements there
[17:36:11] <Colourless> the first spawn is at A2D
[17:36:28] <Colourless> second is the spawn inline at A38
[17:36:36] <Colourless> third is at A49
[17:36:38] <wjp> hm, the pid of the first spawn is discarded
[17:36:47] <Colourless> fourth is at A5D
[17:36:57] <Colourless> first implies is at A53
[17:37:05] <Colourless> second implies is at A67
[17:37:08] * wjp hmms
[17:37:22] <wjp> which pids are passed to the second implies?
[17:37:40] <wjp> that of the last spawn, and maybe the retvalue of the first implies?
[17:38:12] <Colourless> seriously, i do not know what exactly is going on there
[17:38:51] <Colourless> the pid of the spawn inline also seems discarded
[17:39:27] <wjp> isn't that passed to the first implies?
[17:39:49] <Colourless> i don't know how, it's never pushed onto the stack
[17:39:57] <wjp> oh, right
[17:40:04] <wjp> hm, bbl, dinner :/
[17:41:36] <Colourless> as i have once said before, it's probably going to be a case of it's just not going to work properly for 'ages' and then we'll figure out whats going wrong and magically it's like all going to work properly, once something as complex as the execution scene works
[18:09:19] <wjp> that's the idea, yes :-)
[18:10:51] <wjp> hm, which parameters do these two implies get?
[18:11:30] <Colourless> i do not know at this stage
[18:11:51] <wjp> Darke: how's that decompiler coming along? ;-)
[18:12:13] <Darke> wjp: Erm... *grin*
[18:12:14] <Colourless> ah, i think i now know
[18:13:04] <Colourless> maybe not.
[18:14:04] <Colourless> anway, wjp, something interesting to look at. the spawn inlined code (from a6e to ad7) has a suspend opcode before it executes anything
[18:14:47] * wjp nods
[18:15:10] <wjp> hm, the disassembly I have here doesn't have intrinsic names
[18:15:24] <wjp> did one of the disasm tools already include those?
[18:15:39] <Colourless> all the disasms should include them
[18:16:01] <wjp> mine's obviously quite ancient :-)
[18:16:43] * wjp updates his disassembly
[18:20:03] <Colourless> the only thing i can think of is if spawn inline automatically pushes the pid to the stack
[18:25:03] <Colourless> heh, spawn inline works different, that's for sure
[18:25:09] <Colourless> just looking through the entire disassembly
[18:25:50] <Colourless> can't say i've ever seen a case where it does spawn inline, push retval, implies 01 01
[18:26:04] <Colourless> always seems to do a
[18:26:05] <Colourless> spawn 02 00 0581:1C19
[18:26:26] <Colourless> or call another processes
[18:26:33] <Colourless> s/call/spawn/
[18:27:41] <wjp> yes, every spawn inline is followed by a spawn, except for one, which is followed by a calli (item::guardianBask)
[18:28:11] <Colourless> which is also a spawn
[18:30:02] * wjp nods
[18:36:30] <wjp> it looks very plausible that a spawn inline pushes the pid
[18:55:29] <wjp> the amount of possible sync issues here is kind of scary :-)
[19:36:27] <wjp> the implies with the current pid as an argument seem to be followed by a suspend
[19:36:54] <wjp> that could mean that that implies doesn't immediately suspend a process
[19:37:53] <Colourless> yes i don't think it does. doesn't make much sense if there is a suspend opcode
[19:42:25] <wjp> which would you prefer? giving each process a list of processes that it's waiting for, or giving each a list of processes that are waiting for it?
[19:42:39] <wjp> the latter would probably be cleanest
[19:42:48] <Colourless> latter since it's easier
[19:43:45] <wjp> I guess it should really be a list (and not a single pid), right?
[19:43:55] <Colourless> i would guess so
[19:46:39] * wjp wonders what implies pushes
[19:47:19] <wjp> it looks like a pid, and I would assume one of the two it pops; but which one? :-)
[19:47:59] <wjp> problem is that it nearly always is discarded into temp, so it's kind of hard to tell :-)
[19:48:31] <Colourless> :-)
[19:48:59] <wjp> ah well, I'll just randomly pick one for now; we'll figure out if it's correct someday (I hope :-) )
[19:54:08] * wjp hmms... is there any 'proper' terminology for a process that's waiting for another process? (specifically the variable name of the list of 'waiting' pids)
[19:54:52] <Colourless> dependant is the only thing i can think of
[19:59:36] * wjp hmms..
[19:59:47] <wjp> this is kind of annoying
[20:00:19] <wjp> I guess we need a way of accessing a process by its pid
[20:00:38] <Colourless> the kernel should control all processes and pid
[20:00:43] <wjp> yes
[20:01:49] <wjp> so we probably need a map<uint16,Process*>
[20:01:59] <wjp> and a list<Process*> too for keeping the run-order?
[20:02:00] <Colourless> not at all i would think
[20:02:11] <wjp> no?
[20:02:18] <wjp> just look through the list when you need one?
[20:02:24] <Colourless> yes
[20:02:34] <wjp> hm, the number of concurrent processes will be rather low, yes
[20:02:35] <Colourless> to make it easier you could also have a 'last pid allocated'
[20:02:40] <wjp> yes, I have that
[20:03:19] <Colourless> just keep incrementing until you run out. if you run out, then search for unallocated ones. there of course would be optimizations possible too
[20:04:01] <wjp> if really necessary we could easily keep an available-pid set :-)
[20:04:31] <wjp> (stored in some kind of extent structure if memory is a problem :-) )
[20:04:38] <wjp> but no real need for that, I would say
[20:04:45] <Colourless> i would imagine in the original engine the PID was probably something really hacky like a near pointer
[20:05:04] <Colourless> they seemed to like that sort of thing
[20:05:07] <wjp> now why wouldn't that surprise me? :-)
[20:05:10] <wjp> indeed :-)
[20:13:23] * wjp wonders where the result of a process should be stored
[20:14:01] <Colourless> i really should be going now
[20:14:05] <Colourless> cya
[20:14:06] <wjp> g'night
[20:14:11] <-- Colourless has left IRC ("casts invisibility")