00:00:00 --- log: started forth/06.04.09
01:32:09 --- quit: neceve (Connection timed out)
02:43:33 --- join: Alterego (n=Alterego@88.202.136.178) joined #forth
03:17:31 --- join: Cheery (n=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth
04:07:30 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
04:16:13 --- join: segher_ (n=segher@dslb-084-056-133-235.pools.arcor-ip.net) joined #forth
04:24:30 --- quit: segher (Read error: 110 (Connection timed out))
04:53:30 --- quit: tathi ("leaving")
05:00:32 --- join: PoppaVic (n=pete@0-3pool196-200.nas30.chicago4.il.us.da.qwest.net) joined #forth
05:08:35 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
05:26:34 --- quit: snowrichard ("Leaving")
05:49:56 --- quit: crc (Read error: 101 (Network is unreachable))
06:24:00 --- join: amca (n=plump@as-bri-3-182.ozonline.com.au) joined #forth
06:24:28 --- quit: amca (Read error: 104 (Connection reset by peer))
06:40:44 --- join: crc (i=crc@pool-70-110-130-229.phil.east.verizon.net) joined #forth
06:41:49 --- quit: virl (Remote closed the connection)
08:02:17 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
08:02:29 <PoppaVic> hi tathi 
08:02:43 <tathi> hi
08:02:56 <PoppaVic> got a lot of code written the other day
08:03:10 <tathi> cool
08:03:33 <PoppaVic> About ready to group and define vtable-members.
08:03:57 <PoppaVic> I'm betting pcode is not much worse than bytecode.
08:04:29 <PoppaVic> I am trying to cogitate and reconcile "direct threaded" versus bytecode, I guess.
08:04:58 <tathi> I don't think there's much difference
08:05:36 <tathi> well, there's probably some size difference.
08:05:40 <PoppaVic> well, you might consider image-copy versus decompile or using-these inputs.
08:05:54 <tathi> huh?
08:06:45 <PoppaVic> tathi: some folks want portable objects... I don't see it being likely.
08:07:16 <PoppaVic> shit, we can't rely on a lib to create .o let alone .dynamiclibs
08:07:45 <PoppaVic> So, I'm thinking only engine+sources
08:08:13 <PoppaVic> ..and maybe 'modules' that dlopen and such can bring into the environment.
08:09:21 <PoppaVic> abstracting is pretty much the whore of the lot
08:10:46 <tathi> yeah, that's why I generally write something concrete and only abstract as necessary
08:13:52 <PoppaVic> tathi: that /msg and url sorta' show where I am heading.. I'm not too upset yet.
08:26:56 <PoppaVic> tathi: you see any major issues I need to address at this point? I already know I need a VM structure and the internal stacks.
08:30:37 <PoppaVic> hmm... lemme recycle
08:30:40 --- quit: PoppaVic ("Pulls the pin...")
08:32:14 --- join: PoppaVic (n=pete@0-1pool73-210.nas24.chicago4.il.us.da.qwest.net) joined #forth
08:34:53 <PoppaVic> Nothing?
08:39:35 <tathi> I didn't really look at it
08:41:22 <tathi> hmm, looks ok AFAICT
08:41:35 <PoppaVic> cool... Any ideas/comments?
08:44:32 <tathi> why do you have "uint8_t pfa[1]" instead of just "uint8_t pfa[]" ?
08:45:08 <PoppaVic> I don't use C99 and we need at least a 1 for otherwise, 0 is tolerable in C99
08:45:29 <tathi> oh, ok.
08:45:36 <PoppaVic> afaik, gcc screams and dies at [] in a struct
08:45:40 <tathi> I thought an empty array at the end of a struct had always been ok
08:45:49 <PoppaVic> yeah, sorta'
08:46:02 <PoppaVic> a byte won't kill me, though
08:46:10 <tathi> yeah, just curious
08:48:32 <PoppaVic> Note, a union or a struct is almost identical - added an enum, a tagfield, deleted and compacted.
08:51:15 <PoppaVic> Trying to cover all the bases, tathi 
08:51:57 <tathi> I also tend to use some other error handling mechanism, rather than checking a return value from every primitive.
08:52:02 <PoppaVic> I have this really bad feeling that the fseek shit can screw around because of whence and signs
08:52:05 <tathi> But again that's not a big deal
08:52:20 <PoppaVic> tathi: what would you propose?
08:53:24 <tathi> ah, I guess for your uses that's best.
08:53:55 <PoppaVic> I'm really anti-"exceptions", and we can't much dick with errno, so we'd need a VM.errno, and VM.errstring - and that's fine. BUT, I've been cogitating folks adding "exceptions" as they roll along or within a "context"
08:54:42 <tathi> though I kind of like how it works out with setjmp/longjmp (jmpbuf in the VM struct)
08:54:52 <PoppaVic> ewwwwwww
08:55:00 <PoppaVic> you LIKE that?
08:55:35 <PoppaVic> non-local GOTO is an invitation to spaghetti-dinners
08:55:59 <tathi> er...not how I'm thinking of it.
08:56:03 <PoppaVic> tathi: would it help to consider VM "error-handling"?
08:56:18 <tathi> it's fine how you're doing it.
08:56:55 <PoppaVic> ok... Not sure as far as "I can't work, die ugly" - but it should STILL be within the realm of C and the VM
08:57:01 <PoppaVic> ..context
08:57:53 <PoppaVic> it MIGHT be the issue of "exception _might_ resolve the issue and continue"
08:58:34 <PoppaVic> ..personally, I get really confused.. I think of states/context and calls or handlers.
08:58:43 <Alterego> Exceptions handling mechanisms always get me thinking. "Surely there's a better way!".
08:58:51 <PoppaVic> right
08:58:54 <PoppaVic> callbacks?
08:58:59 <Alterego> Maybe.
08:59:16 <PoppaVic> Alterego: I can post the latest... lemme over there
09:00:18 <PoppaVic> ok, you can see the rafb now
09:01:24 <Alterego> I'm not sure I like your compounds_ enum.
09:01:26 <PoppaVic> So far, I've avoided the VM, stacks and vtables/handlers.
09:01:50 <PoppaVic> Alterego: hey, suggest an alternative that is as compact and flexible.
09:02:12 <Alterego> It's not the use, it's the fact they're lower case constants ^_^
09:02:21 <PoppaVic> as a struct, it's tight. As far as HANDLING, we add as we go.
09:03:04 <PoppaVic> Of course they are - they are elements in the C space - what's the issue?
09:04:38 <PoppaVic> Remember, not one of these structs is supposed to "exposed" to the VM - they are internals. All we care about is sizes, offsets, types and such
09:05:07 <PoppaVic> to/to BE
09:05:51 <PoppaVic> only the VM and helpers - written in pcode or C - are supposed to know diddly. And, C is "the assembler"
09:09:32 <PoppaVic> C is the ONLY place they should know of "guts"
09:09:46 <Alterego> So how can C handle proc calling conventions and access the stack?
09:10:21 <PoppaVic> "the stack" is a struct/array the procs/handlers handle via the VM*
09:10:42 <Alterego> Interesting.
09:10:51 <Alterego> You just gave me a little idea.
09:10:56 <PoppaVic> We don't worry about the "machine stack" any more than a C programmer ever should.
09:10:58 <Alterego> For my VM design.
09:11:10 <PoppaVic> Of course.
09:11:19 <Alterego> That's my problem though. I have to worry about that.
09:11:43 <PoppaVic> how do you mean? Internally? Of course.
09:12:29 <Alterego> Deja Vu
09:12:34 <Alterego> Or is that later on ..
09:12:55 <PoppaVic> hehe
09:13:15 <PoppaVic> I tell people - over and over - forthish is _interesting_
09:13:47 <PoppaVic> So is C - but folks want to brainshit when they hear about it.
09:14:16 <PoppaVic> Too damned many concepts in both "spaces" to discard offhand
09:24:21 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth
09:24:21 --- mode: ChanServ set +o JasonWoof
09:31:36 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth
09:49:49 <PoppaVic> hmm
09:50:16 <PoppaVic> tathi: I think I see THE issue, Alterego has been raising it for the wrong reasons.
09:50:34 --- join: TheBlueWizard (i=TheBlueW@ts001d0869.wdc-dc.xod.concentric.net) joined #forth
09:51:26 <Alterego> I don't see why data types should pose a problem.
09:51:45 <PoppaVic> as soon as you deal with "host byte order", everyone wants to play dick-around.
09:52:19 <PoppaVic> data TYPES are an issue, and endian is only half of it.
09:52:47 <Alterego> From a programers perspective, it shouldn't be ..
09:52:51 <PoppaVic> there is endian and size
09:54:03 <PoppaVic> It is for everything except purist C or forth - and the lack of an ABI header/class excentuates it.
09:54:20 <PoppaVic> Interesting
09:54:28 <Alterego> Hmmm, yeah.
09:55:11 <PoppaVic> OK. Let's make a presumption....
09:55:34 <PoppaVic> We already know forthish interpreters are going to be FASt
09:56:59 <PoppaVic> We can also PRESUME that that we have the states of forth, and <foo> intermediate files.
09:57:22 <PoppaVic> we can finally ACCEPT interpret versus compiled.
09:58:02 <PoppaVic> What we cannot accept?
09:58:25 <PoppaVic> 1) every processor is the same;
09:58:35 <PoppaVic> 2) Every OS is the same;
09:58:53 <PoppaVic> 3) Every system has all the same devices;
09:59:35 <PoppaVic> 4) Every system accesses the same devices on the same CPU and the same OS
10:00:12 <PoppaVic> sooo... methods.. interpreters.. tags/flags...
10:00:57 <PoppaVic> pre methods, we want also "common interface"
10:01:07 <PoppaVic> interfaces over interfaces
10:02:23 <Alterego> Yeah, shame it isn't the OS' job to build our abstracted interface ..
10:04:46 <PoppaVic> Well, it ain't - we work with text.. in/out. and textfiles and ascii or some weird variant
10:05:25 <Alterego> Hrm, what would be your prefered interface for calling a function. This is my go so far: vm_object* dli_call_func( dli_func *func, unsigned int argc, vm_object *argv);
10:05:53 <PoppaVic> every bit means something, and then we can all squabble about nybbles or bytes, and goddamned "octets" - and then they STILL want to argue about ascii.
10:06:15 <PoppaVic> hmm...
10:06:33 <PoppaVic> 1) ASCII foremost and for code/symbols.
10:06:46 <Alterego> Actually, argc can be removed.
10:07:15 <Alterego> My vm_object can be an array, which stores its' dimensions.
10:07:16 <PoppaVic> 2) bytes are 2 4-bit nybbles - 8 bits or a struct.
10:07:41 <PoppaVic> can they be ported?
10:07:42 <Alterego> nibbles can not be addressed.
10:08:03 <PoppaVic> I know that, and it's "nybble"
10:08:10 <Alterego> yeah, my vm_object is portable.
10:08:24 <Alterego> It's the code that uses it that may have portability issues ^_^
10:08:39 <PoppaVic> I;ve seen the recent docs, and they tend to make me wonder what the high-priesthood is trying to do
10:09:32 <PoppaVic> Mind you, I did not mention word/dword, etc
10:10:08 <PoppaVic> Alterego: you want to go nuts? See forthish docs using the term "cell"
10:10:40 * PoppaVic watches "The Mummy II"
10:11:30 --- quit: virl (Read error: 110 (Connection timed out))
10:13:14 <PoppaVic> Alterego: in my file, I used the same terms as C did. I did that deliberately. To be honest, everything should be a char[]
10:13:25 <PoppaVic> ..and named simlarly
10:15:14 <PoppaVic> since sizeof is returned in TERMS-OF char - maybe THOSE should be changed.. I'd be happy to do so...
10:23:34 --- quit: PoppaVic ("Pulls the pin...")
10:26:27 --- quit: Alterego (Read error: 110 (Connection timed out))
10:58:16 --- join: Alterego (n=Alterego@88.202.136.178) joined #forth
11:06:02 --- quit: Cheery ("Leaving")
11:22:31 --- part: TheBlueWizard left #forth
15:21:09 --- join: Stepan (n=Stepan@khepri.openbios.org) joined #forth
15:21:11 <Stepan> hi guys
15:21:34 <Stepan> gee.. what happened to this channel?
15:21:40 <Stepan> its almost empty?
15:31:51 <Robert> Hi, Stepan.
15:59:13 <Stepan> Hey Robert!
15:59:18 <Stepan> How's life?
16:05:25 <Robert> Hmm....
16:05:53 * Robert yawns. Pretty tired by now :)
16:13:20 <Stepan> http://www.rhoenblog.de/textpt/images/3.jpg <-- this is on a graveyard in cologne
16:29:27 --- join: Snoopy42 (i=snoopy_1@84.58.185.223) joined #forth
17:11:24 --- quit: Alterego (Remote closed the connection)
18:34:03 --- quit: uiuiuiu (Remote closed the connection)
18:34:07 --- join: uiuiuiu (i=ian@dslb-084-056-233-226.pools.arcor-ip.net) joined #forth
20:54:16 --- quit: tathi ("leaving")
23:12:04 --- join: Amanita_Virosa (n=jenni@adsl-69-154-178-250.dsl.hstntx.swbell.net) joined #forth
23:46:03 <arke> teh hies
23:47:37 --- join: segher (n=segher@dslb-084-056-163-087.pools.arcor-ip.net) joined #forth
23:53:44 --- quit: segher_ (Read error: 110 (Connection timed out))
23:55:24 --- quit: JasonWoof ("off to bed")
23:59:16 --- quit: Quartus (Read error: 104 (Connection reset by peer))
23:59:59 --- log: ended forth/06.04.09