#pentagram@irc.freenode.net logs for 25 May 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:46:24] <-- Dark-Star has left IRC (Read error: 110 (Connection timed out))
[01:06:18] <-- wjp has left IRC ("Zzzz...")
[07:52:12] <-- sbx has left IRC ("X-Chat [1.6.4]")
[10:40:59] <-- Darke has left IRC (sterling.freenode.net irc.freenode.net)
[10:41:27] --> Darke has joined #pentagram
[11:26:37] --> wjp has joined #pentagram
[11:26:37] --- ChanServ gives channel operator status to wjp
[11:50:10] <Darke> ACTION happybounces and yays! He's finally got the compiler to be a nicely behaving pentagram Process! Admittedly it's not much of a compiler (it understands precicely 3 tokens and the basics of what a 'class' is), and it's really not doing things particularly optimally (parsing one token a cycle, will probably take quite a while to recompile an entire project if it does *that* for the rest of it's life...) but it's nice and well behaved and it..
[12:59:02] --> Colourless has joined #Pentagram
[12:59:02] --- ChanServ gives channel operator status to Colourless
[12:59:19] <wjp> hi
[12:59:39] <wjp> I reached level 25 :-)
[12:59:46] <wjp> which means I now have the 'slayer' perk :-)
[12:59:46] <Colourless> heh, cool
[13:00:01] <wjp> (i.e., every hth-hit is a critical)
[13:00:14] <Darke> Hi.
[13:00:17] <Colourless> impressive
[13:00:24] <Darke> Oooooh.
[13:00:35] <wjp> there's a 'sniper' perk too (every ranged hit is a critical)
[13:06:04] * Darke considers the primary problem, should anyone want to create a derived Application class to compile and run as a seperate executable, is going to be making sure they link it with all the relevant files. So far it's 65 and counting for Application... *grin*
[13:09:42] <Darke> Incidentally, did we decide for, or against avoiding multiple inheritence? Or did we end up making no decisions on it?
[13:10:00] <wjp> multiple inheritance is already being used
[13:10:10] <wjp> use with caution, though :-)
[13:10:47] <Darke> Cool. Don't mind me, I'll just be over here screwing around with Application and trying to split it up a little. If anything breaks horribly after I commit, blame exultbot. *grin*
[13:11:48] <Colourless> basically it works like this, is there any real reason to use it?>
[13:13:38] <Darke> Basicly it's for splitting Application into MinimalApp and GraphicalApp, then deriving Application from both. Just so I can try and see if I can try and *not* drag the entire pentagram tree into a regression tester for my compiler, and probably extending that to the stand-alone tools once they become Processes. *grin*
[13:14:11] <wjp> minimalapp should probably be the base class
[13:14:28] <wjp> (by definition of minimal :-) )
[13:14:59] * Darke slips a 'ConsoleApp' into there too, he missed it.
[13:16:04] <Darke> Hmm... though I suppose it's possible to do ConsoleApp : MinimalApp, then GraphicalApp : MinimalApp, Application : GraphicalApp. Since I *think* the basic graphics stuff needs most of the stuff that'd be in a ConsoleApp anyway...
[13:16:33] <wjp> Application should be the base class, IMHO, not the 'top' class
[13:17:02] <Darke> *nod* I'm just trying to describe it from the perspective of how it works now. *grin*
[13:17:15] <Darke> AKA, Application is the be-all-and-end-all class. *grin*
[13:18:05] <Darke> Logically, if course we should have Pentagram : GraphicalApp then. *grin*
[13:18:08] <Darke> s/if/of/
[13:28:04] <Darke> I guess I should commit the .cpp file generated by flex from my lexer file to cvs, for those lacking easy access to flex, right? *grin*
[13:28:28] <wjp> no
[13:29:00] <Colourless> even i have flex :-)
[13:29:36] <Darke> No problem. I was just unsure as to whether the various $(other) windows users had it, I expected Colourless+Kirben would. *grin*
[13:29:45] <wjp> people that use the cvs version of something may easily be required to install something like flex
[13:30:19] <wjp> we can consider putting the flex-generated file in any source dists, if necessary, though
[13:30:51] <Darke> Certainly would be a good idea for any source snapshots 'n such.
[13:33:09] <wjp> more for 'real' releases, IMHO
[13:33:27] <wjp> but that's not really relevant yet :-)
[13:35:19] <Darke> Not for a while anyway. *grin*
[13:47:37] <Darke> Hmm... nothing we use depends on us having `awk` does it? For some reason a configure script is checking for it, maybe a holdover from exult...
[13:48:16] <wjp> config.guess uses it apparently
[13:49:54] <Darke> Fair enough. Probably a good idea to leave it in there then. *grin*
[13:50:21] <wjp> but config.guess may be called before the check
[13:50:47] <wjp> I guess we can remove it from configure.ac
[13:50:48] * Darke does have problems imagining a unix system *without* some version of awk installed though. *grin*
[14:00:22] <wjp> hm, you can even increase skills over 200% in Fallout2
[14:00:32] <wjp> costs 6 skill points per point, though
[14:00:45] <wjp> (or 6 sp for 2% for a tag skill, of course)
[14:01:09] <Colourless> yes you can
[14:01:23] <Colourless> max is 250 iirc
[14:02:03] <wjp> it'll cost an insane amount of sp to get there, though :-)
[14:11:28] <Darke> Heh.
[14:15:35] <Colourless> i broke something somewhere :-)
[14:15:52] <Darke> Eh?
[14:16:52] <Colourless> i'm getting a crash while executing usecode. why i don't know :-)
[14:17:07] <Darke> Umm... oops. *grin*
[14:30:59] <wjp> reproducable?
[14:34:55] --> Dark-Star has joined #pentagram
[14:40:05] <Colourless> yes happens every time
[14:40:11] <Colourless> it's something that i've done
[14:55:02] <Colourless> hmm
[14:55:04] <Colourless> this is strange
[14:56:04] <Colourless> have a look at 0581:1C6D
[14:56:29] <Colourless> when being spawned NULL is pushed as the this pointer
[14:56:46] <Colourless> now, look carefully at the call to Camera::scrollTo
[14:56:59] <Colourless> you'll see that it's pushing the args as if there wasn't a this pointer at all
[14:57:23] <wjp> hm, yes
[14:57:25] <wjp> 8 arg bytes
[14:58:16] <wjp> so Camera::scrollTo should get a this pointer from the arguments?
[14:58:23] <Colourless> no, not at all
[14:58:31] <wjp> um, shouldn't
[14:58:33] <wjp> sorry :-)
[14:58:58] <Colourless> what i'm pointing out is a process with NULL pushed as the this pointer, shouldn't even have a this pointer pushed onto it's stack
[14:59:29] <wjp> hm, yes, the first argument is indeed in the place of the this pointer
[14:59:43] <wjp> ok, easily changed
[15:01:20] <Colourless> you know, i'm thinking that camera scrolling was originally a usecode process. Camera::scrollTo() is only called by 0581:1C6D, and anytime the usecode wants to scroll the camera it spawns a 0581:1C6D process which just passing the args without doing anything else
[15:01:53] <wjp> hm, yes, could be
[15:03:23] <Darke> Makes sense.
[15:03:53] * Darke decides that since he needs to be up again in under 6 hours, it'd be a good idea if he went to sleep now. *grin* Night!
[15:03:56] <Colourless> can you commit changes asap
[15:04:08] --- Darke is now known as DarkeZzz
[15:04:20] <wjp> for the this pointer stuff?
[15:04:35] <Colourless> yes, or do you want me to change it
[15:06:38] <wjp> I'm guessing the case this_ptr != 0 && thissize > 0 won't occur?
[15:06:51] <wjp> um, this_ptr == 0
[15:07:16] <Colourless> it might occur, but i've never seen it
[15:07:16] <Colourless> perhaps assert it
[15:08:43] <wjp> anyway, committed
[15:21:22] * wjp toasts the Hubologists and reaches level 26 :-)
[15:21:50] <Colourless> Hubologists map is called SFElronb
[15:22:28] <wjp> elronb?
[15:22:51] <Colourless> elron hubbard was mr scientologist :-)
[15:23:01] <wjp> ah, ok :-)
[15:23:18] <wjp> I was pretty sure this was meant to be a scientology parody :-)
[15:23:19] <Colourless> as if the name isn't obvious once you know that
[15:23:32] <Colourless> hubologists ? ;-)
[15:23:52] <wjp> I didn't know that 'hubbard' name :-)
[15:27:40] <Colourless> hmm, now that we fixed 'that' we are getting an infinite loop :-)
[15:27:49] <wjp> where?
[15:27:57] <Colourless> just try running first :-)
[15:28:18] <wjp> right :-)
[15:28:45] <Colourless> looks like it's waiting for a call to getCurrentTimerTick() to expire :-)
[15:28:57] <wjp> hm :-)
[15:29:02] <Colourless> s/expire/reach the correct value/
[15:29:18] <wjp> you think I should implement that? :-)
[15:29:30] <Colourless> what? no never :-)
[15:29:48] <Colourless> on second thoughts, yes it would be a very good idea
[15:29:58] <Colourless> question is, what is a TimerTick
[15:30:07] <Colourless> is it the framenum or some ms value
[15:30:12] <Colourless> my guess is framenum
[15:30:16] <wjp> or possibly the 19.2ms something
[15:30:31] <wjp> (or whatever that value was that the internal clock uses)
[15:30:51] <Colourless> i would think it's framenum
[15:30:57] <wjp> probably
[15:31:13] <Colourless> if it's not, we could just do some hacky multiplier
[15:31:34] <wjp> ok, so we'll need to move framenum to its proper place
[15:31:47] <Colourless> uh oh.
[15:31:54] * Colourless expects conflicts soon
[15:31:55] <wjp> uh oh?
[15:32:14] <wjp> want to commit anything first?
[15:32:24] <Colourless> no, no no :-)
[15:32:59] <wjp> hm, should it be in Kernel or in Application?
[15:33:06] <Colourless> Application is my opinion
[15:33:21] <Colourless> that is where i've been putting all the timing stuff
[15:33:21] <wjp> bool weAreWeAreWeAreTheMany ?!
[15:33:28] <Colourless> it's unused :-)
[15:33:32] <wjp> I would hope so :-)
[15:33:35] <wjp> SS ref?
[15:34:10] <Colourless> what?
[15:34:17] <wjp> that variable name?
[15:34:26] <wjp> or where is it from?
[15:34:30] <Colourless> where?
[15:34:38] <Colourless> yes systemshock 2 :-)
[15:43:29] <wjp> ok, that should do it
[15:43:45] <wjp> I hope the amount of conflicts stays limited :-)
[15:44:49] <Colourless> i wonder what effect this will have on execution
[15:45:30] * wjp takes a look
[15:46:44] <wjp> hm, timing does look different
[15:46:48] <Colourless> cvs server: conflicts found in kernel/Application.cpp
[15:46:54] <Colourless> cvs server: conflicts found in kernel/Application.h
[15:47:03] <Colourless> cvs server: conflicts found in usecode/u8intrinsics.h
[15:47:05] <wjp> specifically Salkind is now walking through Mordea instead of through Vardion
[15:47:35] <wjp> those last two can't be big :-)
[15:48:09] <Colourless> there was 2 in Application.h
[15:48:23] <wjp> both from me?
[15:49:09] <wjp> typical... I change two lines and both cause conflicts :-)
[15:49:11] <Colourless> yes, one of them because it looked like you, shock horror, removed a blank line
[15:49:21] <wjp> I did?
[15:49:39] <wjp> I guess I sometimes do that unconsciously :-)
[15:50:26] <Colourless> the u8intrinsics.h one was due to you adding #include "Application.h" where i added #include "CameraProcess.h"
[15:50:43] <wjp> :-)
[15:53:03] <Colourless> by changing
[15:53:03] <Colourless> case SDLK_g: { // trigger
[15:53:08] <Colourless> to
[15:53:09] <Colourless> case SDLK_g: { // trigger 'execution' egg
[15:53:15] <Colourless> you caused big conflict :-)
[15:53:29] <wjp> lol
[16:06:59] <Colourless> the timing of the func is way too slow
[16:07:30] <Colourless> like way way way too slow
[16:13:21] <wjp> yeah
[16:13:29] <wjp> and this is already faster than it will be
[16:15:52] <Colourless> ok, camera coords are actually for the top right of the screen
[16:15:59] <Colourless> top left i mean
[16:16:09] <Colourless> which is icky :-)
[16:16:13] <wjp> yes, weird
[16:16:39] <Colourless> i think
[16:16:42] <Colourless> i don't really know
[16:16:54] <Colourless> whatever is going on. the coords are 'way' off
[16:18:12] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[16:42:35] * wjp hmms
[16:42:35] <wjp> FREE::1C6D is called with return values from getX/Y/Z
[16:42:35] <wjp> (20 is added to the Z coordinate, but that isn't much)
[16:43:41] <Colourless> yeah that is enough
[17:01:28] <wjp> bbl, dinner
[17:02:33] <Colourless> k
[17:19:08] <Colourless> things are breaking badly here when you add a new process
[17:19:28] <Colourless> adding a new process invalidates the iterators
[17:20:04] <Colourless> so the oldest processes don't run
[17:22:09] <Colourless> of course afaik, it shouldn't have that problem
[17:22:21] * Colourless does more tests
[17:26:45] <Colourless> hmm, shouldn't be adding
[17:26:57] <Colourless> could be removal
[17:31:05] <Colourless> i think i know the problem
[17:31:18] <Colourless> we are doing ++it
[17:31:30] <Colourless> however, after erasing, it is not long valid
[17:31:54] <Colourless> s/not long/no longer/
[17:35:43] <Colourless> yes, stopping that from occuring seems to have fixed my problem
[17:36:08] <Colourless> ah, silly
[17:36:15] <Colourless> the bug was just stupid
[17:36:35] <Colourless> ++it was just being called when it wasn't meant to be
[17:47:44] --> Cless has joined #Pentagram
[17:47:46] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))
[17:48:02] --- Cless is now known as Colourless
[17:48:04] --- ChanServ gives channel operator status to Colourless
[17:48:24] <wjp> back
[17:48:41] <Colourless> wb
[17:48:42] <wjp> hm, problem with the process list?
[17:48:45] <Colourless> i found a bug :-)
[17:48:51] <Colourless> yes
[17:49:42] <Colourless> it = processes.erase(it);
[17:49:58] <Colourless> after that it is next
[17:49:58] <wjp> hm, we do an ++it after that?
[17:50:04] <Colourless> however, we were still doing ++it :-)
[17:50:13] <wjp> yes, that would be a bug :-)
[17:51:07] <Colourless> it became really noticable when the camera started to jump around all over the place
[17:51:38] <Colourless> uh oh, i though and noticed it's run() func wasn't being called when it should be
[17:51:44] <Colourless> s/though/thought/
[17:52:23] <Colourless> this should now be about ready to be committed
[17:59:31] --> Cless has joined #Pentagram
[17:59:33] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))
[17:59:50] --- Cless is now known as Colourless
[17:59:52] --- ChanServ gives channel operator status to Colourless
[18:05:48] <wjp> I guess that caused the occasional jumpy fish movement too
[18:10:37] <wjp> hm, effects like text will need some special handling/hooks
[18:11:01] <Colourless> what do you mean?
[18:11:21] <wjp> text being displayed would both be a process and something that needs to be painted
[18:11:25] <Colourless> notification from the gump to the process?
[18:12:15] <wjp> gamemapgump calling some kind of paint() method you mean?
[18:12:26] <Colourless> no
[18:12:40] <Colourless> text 'is' a gump, a BarkGump
[18:12:53] <wjp> heh, ok :-)
[18:12:56] <wjp> didn't know that
[18:13:35] <wjp> so I guess we'll just create a gump, and then after a few ticks remove it again
[18:14:20] <Colourless> yes, but also, when the gump is clicked, it closes
[18:14:30] <wjp> really?
[18:14:36] <wjp> hm, can't remember that from the original
[18:14:39] <Colourless> yep :-)
[18:14:39] <wjp> but I'll take your word for it
[18:15:16] <wjp> that'll just be a special function of the BarkProcess then, I guess
[18:15:27] <wjp> and something similar for whatever we use to ask questions
[18:15:27] <Colourless> so there will be feed back from the gump to the process to say, hey, i'm finished
[18:16:03] <wjp> container gumps don't have attached processes right?
[18:16:06] <Colourless> i'm thinking you could pass the BarkProcess to the gump as an arg
[18:16:13] * wjp nods
[18:16:16] <Colourless> no containers aren't processes :-)
[18:16:46] <wjp> wow, is that the first thing in U8 we found that isn't a process? ;-)
[18:17:27] <Colourless> of course if the process is terminated, you will also need to notify the gump to close. Perhaps just have the BarkProcess::terminate() call BarkGump()::kill() or something
[18:17:44] * wjp nods
[18:19:40] <Colourless> question, why did i find code written by you that looks like this
[18:19:42] <Colourless> Actor* avatar = p_dynamic_cast<Actor*>(World::get_instance()->getObject(1))
[18:19:45] <Colourless> when you could have just written
[18:19:50] <Colourless> Actor* avatar = World::get_instance()->getActor(1);
[18:20:01] <Colourless> oops that should be getNPC(1)
[18:20:36] <Colourless> it's in the 'g' key handler btw
[18:21:58] <wjp> forgetfulness, I guess :-)
[18:22:43] <wjp> it's most likely copy-pasted from the item=p_dynamic_cast< just above it
[18:23:18] <Colourless> we really do have to have a better way of getting an Item
[18:24:55] <wjp> yes
[18:25:25] <wjp> the whole way we store objects need some rearranging
[18:25:50] <wjp> s/need/needs/
[18:25:56] <wjp> the separate vector of npcs should probably be removed
[18:26:26] <wjp> and I think we should move the main objects array to Kernel
[18:26:53] <wjp> and then add a getItem() function to World
[18:27:52] <Colourless> should i enable the calling of enterFastArea() and leaveFastArea() ?
[18:28:15] <wjp> when doing what?
[18:28:15] <Colourless> i've got everything in place for it
[18:28:29] <Colourless> when entering and leaving the fast area of course :-)
[18:28:40] <wjp> when the avatar moves, you mean?
[18:28:53] <wjp> sure, why not :-)
[18:29:10] <Colourless> what about usecode event 2 anim?
[18:29:36] <Colourless> i'm sure it will cause problems due to process exclude but i'll enable that too :-)
[18:29:55] <wjp> you have object animations working?
[18:30:21] <wjp> or just the usecode-animated variety?
[18:30:42] <Colourless> normal object animations
[18:30:45] <Colourless> not the usecode type
[18:30:47] <wjp> cool :-)
[18:31:07] <wjp> what exactly should process exclude do, btw?
[18:31:15] <wjp> it should do something like ensure only one process with (objid,type) is running, I guess
[18:31:18] <wjp> but how?
[18:31:33] <wjp> terminate when others are already running?
[18:31:40] <Colourless> i don't really know how to implement it
[18:32:01] <Colourless> my guess would be yes that would be the only way to do it
[18:32:05] <wjp> (if so, implementing it will be trivial; just do a kernel::getNumProcesses())
[18:32:28] <Colourless> or each item could have a processes list
[18:32:55] <wjp> if necessary, speed-wise
[18:35:05] <wjp> main question is probably if it the process type should match as well as the objid
[18:35:20] <wjp> s/it//
[18:35:28] <wjp> have to look at some disassembly for that, I guess
[18:35:34] <Colourless> what?
[18:36:05] <Colourless> both must match
[18:36:13] <wjp> oh, ok :-)
[18:36:23] <wjp> already figured that out sometime? :-)
[18:36:48] <Colourless> well, it doesn't make sense other wise if you think about it
[18:37:20] <wjp> yeah, I guess not
[18:37:32] <wjp> too many possible side-effects
[18:38:48] <wjp> I'll assume that we only need to check for it when process-exclude is executed
[18:38:58] <wjp> (instead of checking for every new process)
[18:39:27] <Colourless> it's a bit hard to know the process type before the set info opcode :-)
[18:39:33] <wjp> after setting objid/type the process probably executes process-exclude anyway
[18:40:32] <wjp> I'll go running for ~30 minutes I think (while it's still light here)
[18:40:32] <wjp> bbl
[18:40:40] <Colourless> k
[19:23:03] <wjp> back, but gone again
[19:23:04] <wjp> (shower & stuff :-) )
[19:38:05] <Colourless> uh oh. this aint good
[19:38:11] <Colourless> sp = 32; 036B: 45 push huge [BP-05h] 305
[19:38:11] <Colourless> sp = 337; 036F: F6 unhandled opcode F6
[19:38:11] <Colourless> sp = 337; 0370: 05 unhandled opcode 05
[19:38:35] <wjp> uh, no :-)
[19:38:37] <wjp> a huge of 305 bytes?
[19:39:14] <wjp> sounds like we're outside the actual class?
[19:40:05] <Colourless> i'm screwing around seeing how the other maps work.
[19:40:27] <Colourless> most crash due to a problem somewhere in the loopscript stuff
[19:41:11] <Colourless> the huge problem is in
[19:41:17] <Colourless> running process 1f, class 44, offset 340
[19:41:47] <Colourless> doors don't quite work properly yet :-)
[19:41:58] <Colourless> the just disappear, rather than opening
[19:42:06] <Colourless> chests though work great
[19:43:15] <Colourless> hmm, there is no class 44 offset 340
[19:45:46] <Colourless> hang on, hex vs dex
[19:45:52] <Colourless> s/dex/dec/
[19:46:43] <Colourless> yes 44:340 does exist
[19:47:40] <Colourless> somone is reading a word for the huge instead of a byte
[19:48:49] <Colourless> yay, doors work now :-)
[19:49:29] <Colourless> of course, not entirely correctly yet
[19:49:38] <Colourless> a door changed colour
[19:54:10] <wjp> cute :-)
[19:54:42] <wjp> you'd think that was just simple logic
[19:55:11] <Colourless> closing the door changed it back
[20:23:05] <wjp> hm, door usecode is quite complex
[20:23:39] <wjp> some missing intrinsics there too (like canExistAt)
[20:23:47] <wjp> maybe we should have that default to true instead of false
[20:23:54] <Colourless> yes probably
[20:24:09] <wjp> (until we have real collision detection)
[20:24:54] <Colourless> simplest collision detection for us would be to just search through each chunk to see if something is intersecting or touching
[20:25:02] * wjp nods
[20:25:10] <Colourless> that is each chunk the object occupies
[20:25:31] <wjp> and one bordering chunk
[20:25:32] <Colourless> yes one bording is safest
[20:26:08] <wjp> there's a lot of room for optimizations there of course
[20:36:18] <wjp> any ETA of committing? :-)
[20:36:29] <Colourless> 'soon'
[20:36:32] <Colourless> probably 10 minutes
[20:36:38] <wjp> k, guess I'll stay up a while longer then :-)
[20:46:09] <Colourless> ok that should be it
[20:49:21] <Colourless> ah well, i should be going now
[20:49:22] <Colourless> cya
[20:49:24] <-- Colourless has left IRC ("casts invisibility")
[20:53:33] <wjp> hehe, "fixed huge bug" :-)
[20:53:41] <wjp> it wasn't _that_ big ;-)
[21:27:02] <wjp> ok, that should be 'process exclude'
[21:27:14] <wjp> only remaining unimplemented opcode is 0x6C
[21:27:21] <wjp> (which is used for some kind of parameter passing)
[21:45:04] <Dark-Star> hmmm.... tools/compile/compile.cpp, despite it's name, fails to do exactly this
[21:47:35] <Dark-Star> it fails on the constant array definition (line 116): CTestS ctests[] = { { "...", TEST_XPASS }, ... }
[21:49:40] <Dark-Star> after #undef'ing WANT_COMPILE_TEST it works...
[21:50:21] <Dark-Star> hehe... I like that "const char * const random_generic_errors[] = ..."
[21:51:17] <DarkeZzz> Which isn't, at all, surprising, since by undeffing that you're removing all the test code, which that happens to be. *grin* Of course now you've gone from making the compiler to something pointless, to doing nothing at all (or rather asserting *grin*).
[21:52:11] <Dark-Star> well, I guess I can live with that ... I wonder, though, if that error is another MSVC specific bug in initializing constant arrays of structs...
[21:53:07] <DarkeZzz> Might be. I really can't see any particular problem with the code...
[21:53:44] * DarkeZzz isn't running gcc with -ansi -pedantic though, so it could be slipping through as a gcc extension without him even knowing it...
[21:54:12] <Dark-Star> it said something like "cannot convert char[38] to CTestS" IIRC
[21:54:23] <Dark-Star> funny, I tried to catch a fish, and then suddenly a conversation pops up in the console...
[21:54:54] <Dark-Star> something like "0: 5", "1: 4", ... up to "5: 0"... is that supposed to happen?
[21:55:31] <DarkeZzz> That sounds like you accidentally double-clicked on the bedroll. That looks like the 'hours to sleep' dialogue.
[21:56:02] <Dark-Star> ah yes, that might be
[21:56:39] <DarkeZzz> Fishing seems to work for me, as does the bedroll. *grin*
[21:57:45] <wjp> DarkeZzz: you're really overdoing the consts :-)
[21:58:00] <Dark-Star> yep, just tried again, I wasn't expecting that dialog to pop up that late... I had already double clicked on the fishing rod when it popped up
[21:58:22] <Dark-Star> ok, I checked the compile error again: "cannot convert char[?] to CTestS", 5 times in a row
[21:58:35] <wjp> Dark-Star: does it compile if you remove the second const from "const char * const filename;" in struct CTestS?
[21:58:40] <DarkeZzz> It really looks to me like a bug.
[22:00:24] <Dark-Star> there are other errors that, I think, are a result of these: "initializing ctests: this type of non-aggregate initialization requires an unary constructor"
[22:00:33] <Dark-Star> I have no clue what that means, though...
[22:00:41] <DarkeZzz> wjp: I'm just being y'know, paranoid 'n such. *grin*
[22:00:59] <wjp> I really don't see the point of the extra consts
[22:01:19] <wjp> Dark-Star: did you try removing that second const?
[22:01:29] * DarkeZzz blinks. That's one weird warning.
[22:02:05] <Dark-Star> yep, removing the 2nd const works
[22:02:15] <wjp> DarkeZzz: see ;-)
[22:03:37] <wjp> it does sound like a compiler bug, though
[22:04:12] <Dark-Star> what does that 2nd const mean, anyway?
[22:04:37] <wjp> that the pointer itself is a constant
[22:04:40] <wjp> (the first const means that what the pointer points to is a constant)
[22:04:50] <DarkeZzz> The first const makes the data constant, the second const makes the pointer constant. Which is what it should be. *grin*
[22:05:22] <wjp> google turns up at least some discussion threads about compilers having trouble with initializing consts class members with { }
[22:05:27] <DarkeZzz> Like I said, I'm just being paranoid. I can't help it if buggy compilers don't like me? *grin*
[22:06:13] * DarkeZzz removes it anyway, it's not like it's not *only* bits of his testing suite. *grin*
[22:06:46] <wjp> DarkeZzz: how much do you remember about opcode 0x6C?
[22:06:52] <wjp> (the parameter pid change one)
[22:07:22] <DarkeZzz> Umm... eww... it depends what we've decided it does this month. *grin*
[22:08:27] <DarkeZzz> IIRC, the last hypothesis was it changed the ownership of the pointer of the data passed to the function, or something similar.
[22:08:49] <wjp> yeah
[22:09:09] <DarkeZzz> I can't remember if we decided if it copied the data or not.
[22:09:22] <wjp> I'm thinking the easiest way to implement it is by copying the string/list
[22:09:47] <DarkeZzz> IIRC, there was only one deletion of the data pointers though, so I can't be sure. I could be remembering wrongly though.
[22:11:03] <wjp> hm, yes, they aren't being freed
[22:12:20] <wjp> the only frees are from the 'parent' process
[22:13:06] <wjp> and since the child process can (and does) suspend, you either have to prevent it from being freed, or copy it
[22:13:16] <wjp> in both cases you have a memory leak
[22:14:24] <DarkeZzz> Or assume that the child process always terminates before the parent does? Or that part of the parameter pid function causes the parent process to suspend should it get to the return opcode and the child function hasn't terminated?
[22:14:42] <DarkeZzz> s/return/free/
[22:15:00] <wjp> the parent frees the pushed strings immediately after the spawn
[22:15:07] <wjp> (or lists)
[22:16:27] <DarkeZzz> Weird.
[22:17:16] <DarkeZzz> Maybe the 'simplest' solution is to copy and mark the appropriate variables as being needed to be implicitly freed when the child function terminates?
[22:17:49] <wjp> we could of course store the pid a given variable belongs to
[22:17:59] <wjp> and free them all when the process terminates
[22:18:07] <wjp> or do some GC occasionally
[22:19:07] <DarkeZzz> Yup.
[22:20:08] <DarkeZzz> If it were just me, I'd be avoiding 'free' opcodes alltogether and doing the implicit process termination 'free'. But since we're they have them, I 'suppose' we need to support them. *grin*
[22:25:44] <DarkeZzz> I suppose we could always do that anyway, and make 'free' a non-op. *grin*
[22:30:11] <DarkeZzz> At least they mostly had only small datablocks being alloced from the store, so at least we don't have to worry about data relocation and generating "could not allocate X continuous bytes" errors if we couldn't. *grin*
[22:33:47] * DarkeZzz lobbies to upgrade usecode to support 64-bit 'pointers' into our store space. We can be ahead of the times, proactive 'n such, having an GameOS that can technically support more memory then the host operating system! *grin*
[22:35:42] <wjp> ugh :-)
[22:40:36] * DarkeZzz grins and would prefer to migrate most of the usecode to 32bits at some point in time though, since he wants to use it for more stuff (like gumps 'n things) that the original didn't, which is likely to push the minimum store memory requirements a little higher. Not like most people will notice, since everything currently fits easily into 65kb. *grin*
[22:41:03] <DarkeZzz> Annnyway... I should have left for work 20 minutes ago. *grin* Bye!
[22:44:42] <wjp> bye :-)
[23:37:10] <-- wjp has left IRC ("Zzzz...")