#pentagram@irc.freenode.net logs for 14 Dec 2002 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:02:11] <Dark-Star> ?logs
[00:02:11] <exultbot> Logs are available at http://www.math.leidenuniv.nl/~wpalenst/exultlog.php3
[00:02:51] <wjp> um, maybe I should fix that
[00:03:06] <wjp> http://www.math.leidenuniv.nl/~wpalenst/pentagramlog.php
[00:08:46] <Dark-Star> wjp: yes I know, I just need tha base URL and then I can replace the rest :-)
[00:08:56] * Dark-Star uses this practice for quite some time now . . .
[00:09:06] <Dark-Star> s/tha/the
[00:10:27] --> Kirben has joined #pentagram
[00:10:28] --- ChanServ gives channel operator status to Kirben
[00:10:37] <wjp> hi Kirben
[00:10:42] <Kirben> Hi
[00:11:30] --> exultbot has joined #pentagram
[00:11:30] --- Topic for #pentagram is: Pentagram... more than just a game engine, it's an Action RPG operating system
[00:11:30] --- Topic for #pentagram set by Colourless at Mon Oct 7 14:31:52 2002
[00:11:34] <wjp> ?logs
[00:11:34] <exultbot> Logs are available at http://www.math.leidenuniv.nl/~wpalenst/pentagramlog.php
[00:11:39] <wjp> good bot :-)
[00:36:29] <-- Dark-Star has left #pentagram ()
[01:43:02] <-- wjp has left IRC ("Zzzz...")
[02:03:28] --> Darke has joined #pentagram
[02:03:28] --- ChanServ gives channel operator status to Darke
[04:18:03] --- Darke is now known as DarkeAFK
[04:57:48] --- DarkeAFK is now known as Darke
[06:25:25] --> SharpTooth has joined #pentagram
[06:36:16] <-- Darke has left IRC (Remote closed the connection)
[06:37:06] <-- SharpTooth has left IRC (Remote closed the connection)
[07:15:50] --> Darke has joined #pentagram
[07:15:50] --- ChanServ gives channel operator status to Darke
[07:37:43] --> Cash has joined #pentagram
[07:41:31] <-- Cash has left IRC (Client Quit)
[07:53:45] --> Cash has joined #pentagram
[07:53:47] <Cash> ?logs
[07:53:47] <exultbot> Logs are available at http://www.math.leidenuniv.nl/~wpalenst/pentagramlog.php
[07:53:55] <Cash> nice!!
[07:54:55] * Darke snickers. Looks like wjp ended up updating exultbot.
[07:55:16] <Cash> yip - I was just checking to see if he had done so
[07:55:45] <Cash> does he know much currently? besides this and faq
[07:55:59] <Cash> exult ver?
[07:56:05] <Cash> ?ver
[07:56:08] <Cash> ?exult
[07:56:12] <Cash> ?exult ver
[07:56:22] <Cash> ?ver
[07:56:24] <Cash> ver?
[07:56:50] <Darke> hello/name/job/bye I think he does.
[07:57:56] <Cash> I think there is an exult current ver - in the logs,
[07:58:08] <Cash> ?version
[07:58:19] <Cash> ?version
[07:58:36] <Cash> only works for the exult channel
[07:58:44] <Cash> true true
[07:59:10] <Darke> _And_ it's out of date. *grin*
[07:59:43] <Cash> haha yeah! oh well its a bot - somthing to play around with every nown and then
[08:00:23] <Cash> bot?
[08:03:42] <Cash> hmmm time to leave for meantime
[08:03:44] <-- Cash has left IRC ()
[09:29:50] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[09:32:20] --> Kirben has joined #pentagram
[09:32:20] --- ChanServ gives channel operator status to Kirben
[09:45:23] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[09:50:51] --> Kirben has joined #pentagram
[09:50:51] --- ChanServ gives channel operator status to Kirben
[12:53:41] <-- Darke has left IRC ("Inficio-Infeci-Infectum")
[13:04:44] --> Darke has joined #pentagram
[13:04:44] --- ChanServ gives channel operator status to Darke
[13:21:12] --> wjp has joined #pentagram
[13:21:12] --- ChanServ gives channel operator status to wjp
[13:25:20] <wjp> the current incarnation in pentagram can semi-run U8's usecode, whee :-)
[13:26:34] <Darke> Yay 'n stuff. However the cvs doesn't compile on the linux side without 'fixing' the makefiles. *grin*
[13:26:58] <wjp> um, it doesn't?
[13:28:34] <Darke> Nope. It appears to be lacking a few files. I had to remove kernel and usecode from the directories to build. I haven't grabbed the latest cvs in about 12 hours though. *grin*
[13:29:25] * Darke was intending upon spending quite some time today working on the compiler, but he got distracted 'cause things are broken. And xterm sucks.
[13:31:55] <wjp> 'about 12 hours' might or might not work :-)
[13:32:14] <wjp> I committed the necessary Usecode/UsecodeFlex classes about 12 hours ago :-)
[13:33:26] <Darke> Yeah, I just noticed. *grin*
[13:33:48] <wjp> UsecodeFlex actually uses multiple inheritance :-)
[13:34:00] <wjp> class UsecodeFlex : public Usecode, protected Flex :-)
[13:35:37] * Darke snickers.
[13:35:58] * Darke disappears for a couple of minutes to powerdown and speakerremove. *grin*
[13:36:05] <-- Darke has left IRC ("BRB")
[13:48:19] --> Darke has joined #pentagram
[13:48:19] --- ChanServ gives channel operator status to Darke
[13:48:49] * Darke hears the sound, of silence!
[13:48:58] <wjp> lol
[13:48:58] <wjp> wb :-)
[13:49:31] <Darke> Now, if I can turn the background colour of the xterm to something vaguely normal, like black, it might actually start becoming vaguely useful.
[13:49:34] <Darke> Thanks. *grin*
[13:51:37] <wjp> you could of course just switch to gnome ;-)
[13:51:49] <wjp> gnome-terminals work fine (as long as you're not using RH8 ;-) )
[13:52:58] <Darke> I'm just amazed at the fac, that nothing broke in this odd upgrade (I intend to recompile all of kde tonight), except something so amazingly simple like a terminal emulator. *grin*
[13:53:02] <Darke> s/fac/fact/
[13:54:44] <Darke> The fundamental problem with gnome is the widgets make CDE's look pretty.
[13:55:56] <wjp> there's plenty of gtk themes around
[13:58:26] <Darke> True. But way back when I started with linux, I struggled with gnome for a month and never managed to get them to work without crashing, even after spending day after day trying to get them to work. Then I found out this kde thing and never looked back. *grin*
[13:58:35] <wjp> :-)
[14:00:42] <Darke> Sorry, I'm a unix geek, who loves the command line, enjoys programming, etc. But if your program transports you to a little corner of hell when I try to get it to do what I want it to do, then I choose another program that sucks less in the areas that count. *grin* I'm sure gnome is technically superior in some areas, but they've lost at least one person (and probably many more) because they don't seem to care about how easy it is to get it t
[14:00:44] <Darke> o do what you want it too. *grin*
[14:03:21] <Darke> Incidentally, I don't suppose there's anyway to install them without having gnome itself installed? The only gnome widget app I use with any regularity is xchat, and it would be nice to make it look less of an eyesore. *grin*
[14:07:21] <wjp> hm, good question
[14:07:37] <wjp> I think gtk is at least somewhat separate from gnome, so it might be worth a try
[14:10:46] <wjp> hm, I need a simple usecode class that has some calls in it
[14:11:18] <Darke> Most simple ones I know have spawns. Just a sec.
[14:11:41] <wjp> hm, maybe some of the time-of-day ones
[14:12:21] <wjp> yes... there's a simple call there
[14:12:24] <Darke> The 'obvious' one is the only known function that decompiles properly. *grin* Remorse1.21 class 3.
[14:12:28] <Darke> Cool.
[14:12:39] <wjp> U8's 0581:28F9
[14:12:57] <wjp> it calls 0581:28E5 and divides the result by 4 :-)
[14:13:35] <Darke> Sounds simple enough. *grin*
[14:14:54] * wjp watches it crash and burn
[14:15:50] <wjp> ...but that's because I keep forgetting I still need to adjust for headers in the offset
[14:15:54] <Darke> Hmm... looks like I've got all of the relevant gtk+ libraries installed.
[14:16:23] * Darke decides not to be bothered and will search another time. *grin*
[14:18:51] <wjp> yay! function calls and returns seem to work
[14:19:28] * Darke yays too!
[14:23:28] <wjp> kind of annoying that CVS stats seem to be broken right when we actually start to commit stuff
[14:23:52] * Darke snickers. Agreed.
[14:24:28] <wjp> speaking of stats, did you see what happened Exult's pageview count after that /. story? :-)
[14:25:45] <wjp> s/happened/happened to/
[14:25:59] <Darke> Umm... no. I guess it kinda skyrocketed though, even though the story wasn't really about exult, it seems to have gotten hijacked. *grin*
[14:26:43] <wjp> it went from ~3K to ~15K
[14:28:19] <Darke> Nice! *grin*
[14:28:21] * wjp hmmms... did any of us ever figure out the exact way functions return values?
[14:28:58] <wjp> if I look at these functions it would seem what we named the 'temp' register holds the retval of a 'call'
[14:29:41] <Darke> temp register is correct.
[14:30:26] <wjp> what about calli's?
[14:30:39] <wjp> the same opcode is used to get the retval, so I guess intrinsics would store the retval there too
[14:30:52] <wjp> and that would make 'temp' 32-bit
[14:31:06] <wjp> (since I seem to remember 32-bit retvals from intrinsics?)
[14:31:45] <Darke> Yes, it should be 32bit.
[14:32:06] * wjp hmms.. it's probably a 'global' register, right?
[14:32:15] <wjp> no need for there to be a separate one per process?
[14:34:26] <Darke> The answer is 'depends'. *grin* I suspect the original had one global temp register, and it started executing it's calling function immediately when the called function returned, so it could push the temp value back on the stack.
[14:34:52] <wjp> it would make sense for calli's I guess
[14:35:04] <wjp> otherwise an intrinsic would have to know which process' temp to set
[14:37:01] <Darke> Yup. And also for return values from spawn opcodes, which I *think* can happen, but I'm too asleep at the moment. *grin*
[14:37:24] <wjp> spawns are something for later... (later today, probably, but still later :-))
[14:37:59] * Darke snickers.
[14:59:22] <wjp> k, return values are in too
[15:01:36] <wjp> oh, I was wondering about 0x65 (free string)
[15:01:59] <wjp> it would seem that it usually gets a 16bit stringref
[15:02:19] <wjp> but it sometimes seem to get a 32bit strptr too
[15:03:59] <Darke> Eh? *blink* How could it tell the difference then?
[15:04:10] <wjp> yes, that's what I was wondering
[15:05:16] <wjp> 3045: 0D push string "In Sanct An Jux"
[15:05:17] <wjp> 3058: 6B str to ptr
[15:05:17] <wjp> 3059: 0A push int 64
[15:05:17] <wjp> 305B: 40 push long var06
[15:05:17] <wjp> 305D: 57 spawn 06 02 057C:087D
[15:05:18] <wjp> 3064: 65 free str rel 02
[15:05:24] <wjp> what would that do exactly?
[15:05:41] <wjp> push string: create string and push 16bit strref
[15:05:49] <wjp> str to ptr: pop 16bit strref, push 32bit strptr?
[15:06:01] <wjp> push int 64: push 16bit 64
[15:06:09] <wjp> push long var06: push 32bit this pointer
[15:07:02] <wjp> spawn: pops a total of 10 bytes I think?
[15:07:40] * wjp is confused
[15:07:40] <Darke> Isn't it 8? Total of the first two bytes?
[15:07:52] <wjp> hm
[15:08:10] <wjp> wasn't the 2nd byte the size of the struct pointed to by this?
[15:08:17] <wjp> the this pointer itself would still be 4
[15:08:48] <Darke> Ah yes, that's what the second one is. So it 'should' be 10 bytes then.
[15:08:59] * Darke remembers going through this with Colourless before. *grin*
[15:09:23] <wjp> so that means it pops off var06, 64, and the 32bit strptr pushed by 0x6B
[15:10:26] <wjp> which way does the '02' operand to 0x65 go? up or down the stack?
[15:11:05] <Darke> What is 'rel'? SP or BP? *grin*
[15:11:07] <wjp> SP
[15:11:17] <wjp> oh, wait, spawn doesn't actually pop the bytes
[15:11:21] * Darke just found it anyway. *grin*
[15:11:32] * wjp notices a movesp afterwards
[15:11:36] <Darke> Nope.
[15:11:55] <wjp> hm, a movesp -6
[15:11:59] <wjp> maybe it does push the this pointer?
[15:12:02] <wjp> s/push/pop/
[15:12:34] <wjp> yes, that seems to be the case
[15:12:59] <wjp> that would mean SP+02 points past the 'push int 64'
[15:13:06] <wjp> right at the result of 'str to ptr'
[15:15:57] * wjp starts to wonder if he didn't imagine that there was 0x65 that got a 16bit strref
[15:16:43] <wjp> ah, there we go
[15:16:58] <wjp> 0451: 59 push pid
[15:16:58] <wjp> 0452: 0D push string "For what pathetic reason have you summoned me, mortal? "
[15:16:58] <wjp> 048D: 40 push long var06
[15:16:58] <wjp> 048F: 57 spawn 02 02 006D:00B8
[15:16:58] <wjp> 0496: 65 free str rel 00
[15:18:13] <wjp> now, that _could_ mean that 32bit string pointers are just of the form 'pid:strref'
[15:18:23] <wjp> bbl, lunch
[15:23:26] <Darke> *nod* That would make sense.
[15:39:18] <wjp> hm, OTOH, didn't spawn push the pid of the spawned process?
[15:39:59] <wjp> or did it put that in retval?
[15:55:38] <Darke> Wasn't it in retval?
[15:55:52] * Darke really can't remember.
[15:57:49] <wjp> I'm pretty sure it was retval from looking at some usecode
[15:58:12] <wjp> something doesn't quite 'feel' right about that above code snippet
[15:58:37] <wjp> that 'push pid' is later used for a 0x54 implies
[15:58:54] <wjp> which would mean it's used both for a strptr as an implies opcode
[15:59:11] <wjp> somehow that doesn't sound like something a non-optimizing compiler would produce
[16:00:24] <Darke> The pushpid isn't used in the above code.
[16:00:50] <wjp> there's a 0x54 slightly down
[16:01:02] <Darke> var06 is the this pointer, and the string above it is the only data passed to the spawn.
[16:01:18] <Darke> Which accounts for the two 'data' bytes and the two 'this' bytes.
[16:01:25] <wjp> 0451: 59 push pid
[16:01:25] <wjp> 0452: 0D push string "For what pathetic reason have you summoned me, mortal? "
[16:01:25] <wjp> 048D: 40 push long var06
[16:01:25] <wjp> 048F: 57 spawn 02 02 006D:00B8
[16:01:25] <wjp> 0496: 65 free str rel 00
[16:01:26] <wjp> 0498: 6E movesp FE
[16:01:28] <wjp> 049A: 5E push int retval
[16:01:31] <wjp> 049B: 54 implies 01 01
[16:01:35] <wjp> 049E: 12 pop temp
[16:03:58] <Darke> 452 to 48f looks something like: spawn_006d_00b8(var06, "For..."); Or rather more like: var06->spawn00B8("For..."); since by passing a 'this', it's obviously referring to a member of a base class of the current one.
[16:05:35] <wjp> 451-49D: implies(pid, var06->spawn00B8("For..."))
[16:05:41] <Darke> Actually, it's just referring to itself.
[16:06:40] <Darke> *nod* Remember the implies 'ties' two pids together? Which means it 'ties' the current pid with the pid of the spawned function.
[16:06:47] <wjp> yes
[16:07:03] <wjp> that's why it would be weird if that 'push pid' is also used for the free str rel
[16:09:49] <Darke> Why would that be? the free-str-rel frees the "For what..." string from the stack, since it's going to be the last item on it (spawn pops the this pointer if it's provided with one, remember? That's why it's got a seperate 'size' for it.). Then the movesp removes the 'freed' string left on the stack, and then the retval (the spawned pid) is pushed.
[16:10:32] <Darke> Feel free to tell me if I'm not answering the question you're asking, I'm operating on probably three brain cells at the moment. *grin*
[16:10:58] <wjp> well, it would seem here like free-str-rel is operating on a 16bit strref
[16:11:10] --> Colourless has joined #Pentagram
[16:11:10] --- ChanServ gives channel operator status to Colourless
[16:11:18] <wjp> (i.e., the direct result of 'push string "For...")
[16:12:12] * Darke ahhs. Ok. *grin*
[16:12:38] <wjp> and in the earlier code-snippet it would seem free-str-rel operates on a 32bit strptr
[16:12:47] <wjp> which is confusing me quite a bit :-)
[16:13:49] <Darke> Yeah it does, doesn't it? *eartwitch* Smells like a hack to me.
[16:16:04] <Darke> Of course if we allocate the Yamm::buffer on the edge of a 64k boundary, both the string 'offset' and the 'string address' can be inferred from each other.
[16:16:53] <Darke> *ponder* Heh, don't even have to allocate it on a boundary. Since We'll be calling Yamm to free it, and Yamm knows the starting offset of Yamm::buffer, it can work itself out.
[16:16:58] <Colourless> i honestly, don't want a yamm
[16:17:10] * Darke honestly doesn't want a Yamm. *grin*
[16:17:24] <Colourless> then why bother attempting to replicate that functionality
[16:17:37] <Colourless> as i said yesterday, we can ignore everthing they did as long as things work correctly
[16:17:55] <wjp> well, but it would be rather interesting to get both snippets I pasted to work correctly
[16:18:01] <Colourless> i would much prefer to have a list where we store pointers, and the so called 'usecode pointer' for reference.
[16:18:25] <Colourless> when ever we want to access the strings/lists/slists we just look up the entry in the pointer 'list'
[16:18:30] <Darke> We're not. We're trying to work out what the heck one opcode does, and why it seems to be able to accept both a 32bit string pointer and a 16bit string 'offset' as it's data.
[16:18:48] <Darke> Agreed.
[16:18:50] <Colourless> yes it is 'confusing'
[16:19:08] <Colourless> my usecode pointer stuff sort of goes into it
[16:20:21] <Colourless> btw the spawn opcode does pop the this pointer
[16:21:08] <Colourless> anyway my solution was each string was referenced by a value for 0 to 65535
[16:21:14] <wjp> I think it would sort itself out if the last (of first) 16 bits of a 32bit ptr are the ref
[16:21:26] <wjp> s/of first/or first?/
[16:21:34] <Darke> Yeah. I was surprised that I didn't document it anywhere, it was one of the more annoying things I had to 'learn' making fold. *grin*
[16:21:39] <Colourless> when converting this to a 32 bit pointer, the low word (the 'offset') would be the same number that references the string
[16:21:55] * Darke nods.
[16:22:06] <Colourless> the high word (the 'segement') would then indicate the offset is in the 'string' segment\
[16:22:29] <Colourless> the 65 opcode only wants to use 2 bytes
[16:22:48] <wjp> yeah
[16:22:59] <Colourless> and it will end up reading the low word, which is the 'offset' of the pointer
[16:23:06] * wjp nods
[16:23:08] * Darke nods. And it doesn't matter what it accepts, since it doesn't pop anything from the stack.
[16:23:13] <Colourless> yep
[16:23:16] <Colourless> exactly
[16:23:19] <wjp> ugly
[16:23:23] <wjp> but ah well :-)
[16:23:55] <Colourless> sounds like a good time to discuss usecode pointers to me :-)
[16:24:13] <wjp> :-)
[16:24:25] <wjp> it seems we're definitely locked into using the 16 bit ref as the low word
[16:24:37] <wjp> (it does sound like a good idea anyway, though)
[16:26:04] <Colourless> they are a simple idea. you have the segment and offset. the offset is of course what you'd expect. it's an offset into a buffer. the segment chooses what the offset is reading in to. this can be the global string table, the stack from every process, and perhaps anything else we need.
[16:26:46] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[16:27:27] <wjp> currently it would be either an object, an element from the 'stringHeap', an element from the 'listHeap', or a pointer to the stack of a process
[16:27:59] <Colourless> yeah, forgot about an object
[16:28:36] <Darke> And a pointer to a global.
[16:28:48] <wjp> the stringHeap and listHeap are global atm. (process-independent)
[16:28:52] <wjp> ah, yes, that one too
[16:28:53] <Colourless> my idea for objects was to reserve a specific segment for addressing objects, you'd then use the offest to choose the specific object
[16:29:28] <Colourless> as far as I know, usecode doesn't do any pointer arithmetic
[16:29:56] <wjp> 0001:xxxx : object, 0002:xxxx : list, 0003:xxxx : string, 0004:xxxx : global, yyyy:xxxx : pointer to stack of pid yyyy?
[16:30:16] <wjp> (we'd have to let process pid's start at something higher than 4 then, obviously)
[16:30:21] <Colourless> accessing anything global (such as things, or 'globals', list heaps) can use a single offset to access any of the members of that type
[16:31:22] <Colourless> wjp: yes something like that, but i was going to use offsets > 32768 for objects, lists, strings, etc
[16:31:29] <Colourless> s/offsets/segments/
[16:31:42] <wjp> k, and keep pid's low?
[16:31:49] <Colourless> yeah
[16:31:58] <wjp> we may have to reserve segment 0 too
[16:32:15] <wjp> (if it does anything with null-pointers)
[16:32:15] <Colourless> yeah 0 is reserved (to catch any null pointers)
[16:32:23] <Colourless> it does play with nulls
[16:32:44] <Colourless> it would theoretically restrict us to 'only' 32767 processes
[16:33:09] <wjp> I think we'd be suffering from other problems if we actually have that many concurrent processes :-)
[16:33:34] <Colourless> yes :-)
[16:36:14] * Darke pencils in a "more then 64k processes" entry in the pentagram 2.0 checklist. By the time that gets around, we'll have no problems getting that many processes (procii? *grin*) running on a $5 cpu. *grin*
[16:36:51] <Colourless> hehe
[16:36:58] <Colourless> 64 bit usecode :-)
[16:37:08] <wjp> yup :-)
[16:37:19] <wjp> we could get the original to work by simply duplicating all byte sizes, I guess
[16:37:34] * Colourless sees bug report: Why does Pentagram 2 run slow in my Itanium 3
[16:38:05] <wjp> that'll probably be way below our min.sys.reqs :-)
[16:44:36] * wjp grumbles a bit about stringlists
[16:45:51] <Colourless> string lists are virtually identical to lists, they are list<string> rather than list<sint16>
[16:46:14] <wjp> actually they seem to be list<sint16>
[16:46:22] <wjp> with strrefs in it
[16:46:35] <Colourless> that's possible and would make sense
[16:46:35] <Darke> For all intents and purposes they are list<sint16>s. *grin*
[16:46:54] <wjp> and I'm pretty sure they have to be, since the 'create list' opcode has no way (to my knowledge) of knowing which one it's creating
[16:47:35] <wjp> however, the stringlist operations are really different from the normal list operations
[16:47:58] <Colourless> probably because the string list operations need to resolve the strings
[16:48:25] <wjp> yes
[16:48:52] <wjp> that would mean putting separate stringlist functions in the UCList class
[16:48:53] <wjp> bah
[16:49:08] <wjp> but I guess it's pretty much unavoidable
[17:06:16] * Darke wonders off to prostrate himself at the feet of The Great Z. Goodluck and goodnight!
[17:06:25] <Colourless> cya
[17:06:48] <wjp> g'night
[17:06:56] --- Darke is now known as Darke|zzZ
[17:07:29] * Darke|zzZ figures on dialup he's not likely to survive the night without disappearing, but who knows. *grin*
[17:08:06] <wjp> :-)
[17:32:49] * wjp hmmms...
[17:32:59] <Colourless> yes?
[17:33:10] <wjp> it would be reasonable to assume that a stringlist 'owns' the strings in it, right?
[17:33:18] <wjp> (in the sense that it has to delete them)
[17:34:08] <Colourless> yes i think it is
[17:34:18] <wjp> I'm going with that for now; we'll see how it turns out :-)
[17:34:30] <Colourless> you know, i just thought of something
[17:35:49] <Colourless> since we know the original game had it's yamm buffer, the integer components in the lists might be places in the Yamm::Buffer, and the contents of the YammList might be pointers into the Yamm::buffer
[17:36:01] <Colourless> s/places/placed/
[17:37:18] <wjp> so a list would be an array inside the Yamm::buffer?
[17:37:31] <Colourless> no, that is not what i mean
[17:37:59] <Colourless> The list is a list of pointers
[17:38:34] <Colourless> either sint16 * or sint8 *
[17:40:16] <wjp> hm, what would be the point of that?
[17:40:41] <Colourless> because then it doesn't need to care what the data type of the list contents is when freeing the list. It will then know that it needs to free every item in the list
[17:41:29] <wjp> in the cast of sint8/sint16 there is no problem anyway, since a list knows the size of its elements
[17:41:46] <wjp> the problem is when the sint16 (uint16?) in it is actually a stringref
[17:42:55] <Colourless> for us, it doesn't matter really. we could just set the type of the list the first time something is added to it
[17:44:04] <Colourless> we could probably have a UsecodeList class or something, that can then contain either a StringList or an IntegerList
[17:44:19] <Colourless> when first created, it contains neither
[17:44:32] <wjp> hm, but what would the 'create list' opcode do then?
[17:44:49] <wjp> it is identical for popping stringrefs as for popping ints
[17:45:04] * Colourless checks
[17:45:49] <Colourless> what is the opcode?
[17:46:18] <wjp> 0x0E
[17:46:41] <wjp> 0E xx yy: xx = number of elements, yy = elementsize
[17:47:18] <wjp> I had in fact originally implemented what you suggested
[17:47:22] <wjp> but then I noticed this :/
[17:47:37] <Colourless> what is the elementsize given for a string? is it 2?
[17:47:44] <wjp> yes
[17:48:08] <Colourless> how... annoying
[17:48:20] <wjp> my thought exactly :/
[17:49:09] <Colourless> i guess then we have no way of knowing
[17:49:41] --> Dark-Star has joined #pentagram
[17:49:53] <wjp> hi
[17:49:55] <Dark-Star> hi
[17:50:07] <Colourless> which then make me wonder, does the list own the strings
[17:50:13] <Colourless> hi
[17:50:48] <Colourless> yes it does
[17:50:51] <wjp> hm, come to think of it, constructs like 'push string "blah"; push string "foo"; create list 02 02' are rather common
[17:51:03] <wjp> so it would have to own them, yes
[17:56:21] * wjp looks at opcode 0x09
[17:56:28] <wjp> it sets an element of a list/slits
[17:56:31] --- Dark-Star is now known as Dark-Star|away
[17:56:33] <wjp> s/slits/slist/
[17:56:53] <wjp> the weird thing is that it has an operand for differentiating between list/slist
[17:57:00] <wjp> I don't see why it would need that
[17:57:04] <wjp> oh wait
[17:57:17] <wjp> it needs to free the element it's overwriting in case of an slist
[17:57:54] <Colourless> the size is the same as the create function
[17:58:17] <wjp> 0x09 has 3 8bit operands
[17:58:26] <Colourless> yeah i know
[17:58:51] <wjp> oh, I guess you mean the 'size' operand, not the operands-size
[17:59:31] <wjp> hm, dinner, bbl
[17:59:38] <Colourless> cya
[18:01:23] <Colourless> i guess this is getting a similar probably as the param pid instruction and the way lists and strings are passed to another function
[18:01:31] <Colourless> s/probably/problem/
[18:02:40] <Colourless> it looks like the strings inside of the lists aren't being freed
[18:03:15] <Colourless> similar to the way passed string and list arguements to processes don't get freed by the spawn process either
[18:07:59] <Colourless> i am guessing it is doing garbage collection when the processes are terminating since it's obviously 'leaking' Yamm memory
[18:21:48] <wjp> b
[18:21:49] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))