00:00:00 --- log: started forth/06.03.22 00:02:53 brb 00:02:55 --- quit: Brie ("Leaving") 00:03:33 --- join: Brie (i=bre@ringbreak.dnd.utwente.nl) joined #forth 00:03:35 re 00:13:24 hello 00:17:05 hi jason 00:17:22 <-- UK 01:04:09 --- quit: Brie ("Leaving") 01:08:07 grrrr 01:08:15 my keyboard can't register three freaking keys at once 01:08:29 left-shift space and / 01:08:55 that's extremely annoying 01:11:32 so I can't type a question mark in the normal way while holding space 01:13:22 works with rshift 01:13:45 this better be a *(@#&$ed up modmap and not a problem with my actual keyboard 01:17:39 can't imagine how X could screw this up 01:17:56 I'm just not getting an event at all 01:18:01 same thing happens in rxvt 01:18:19 (well, it's not so conclusive, but in rxvt I get a question mark in vim only with the right shift) 01:27:17 --- join: segher (n=segher@dslb-084-056-148-153.pools.arcor-ip.net) joined #forth 01:29:14 --- quit: JasonWoof ("off to bed") 01:30:57 --- join: amca (n=plump@as-bri-1-86.ozonline.com.au) joined #forth 01:58:45 --- join: apgo (n=apgo@85.108.77.83.cust.bluewin.ch) joined #forth 02:14:38 --- quit: apgo_ (Read error: 110 (Connection timed out)) 02:18:24 --- join: neceve (n=Clau@unaffiliated/neceve) joined #forth 02:52:37 --- join: GoHst10 (i=WINNT@12-208-98-237.client.insightBB.com) joined #forth 03:32:10 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:25:31 --- join: Cheery (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 04:44:08 --- join: PoppaVic (n=pete@0-1pool46-189.nas30.chicago4.il.us.da.qwest.net) joined #forth 05:17:50 --- quit: tathi ("leaving") 05:18:15 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 05:18:36 hi 05:18:50 mornin' 05:47:46 humph... I think I may have a clue-like variant. 05:54:43 --- quit: amca (Read error: 113 (No route to host)) 06:05:02 wow, I'm impressed by the game 'Spore' which uses a lot of realtime procedural created content. 06:12:16 I think I may have an idea to run down, virl 06:19:04 virl? you awake? 06:22:17 damnit 06:25:20 fer cripes sakes. 06:26:54 yes, I'm awake 06:27:14 ahh... Cool... I think I've an idea I'd like some bouncing/ideas about 06:28:04 Presume we begin with the typical Data and Return Stack - and absolutely minimal support for ops, ok? 06:29:32 ops? operations? or opcodes? (!,+,-, something like that) 06:29:58 Now.. Elements on the Datastack are not "values"... They are pointers (or voodoo handles) to typed-datastacks. Where every type has a wordlist of functions and ops 06:30:07 No, I meant like dup, rot, etc 06:30:44 so stack manipulation operations 06:31:01 right, and we can consider tick and whatnot 06:31:30 It seems to me that the main "datastack" becomes a CONTEXT-stack. 06:31:40 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 06:32:36 THis is predicated on every type of data having their own (internal) stacks of proper-sized data and at least 1 wordlist. 06:33:28 so to summarize your idea, every value describes himself 06:33:44 THis rough-concept seems to allow for typing, extension, ordering and context-specific behaviors. 06:33:55 right. 06:34:21 It seems to make "the stack" just an indirect-access issue - a communications-stream. 06:35:42 I asked in ##C, but no one answered - I was curious what the percentage of overhead was for a layer of indirection... I can't imagine more than 1 or 2% 06:36:15 it allows a reduction of 'when blah happens then do this' 06:36:22 I don't think you can express it as a percentage 06:37:06 Because that would depend entirely on how much work your actual functionality consists of. 06:37:16 it simplifies this to 'jump to this where it's explained' 06:38:18 well, writing in C, I can envision how they'd generate asm.. 06:38:50 a few clockcycles of register/indirect-register loading and writing. 06:38:53 define they in this context? ##C or your concept 06:39:00 ok, your concept 06:39:13 ..Seems likely that such code is a tiny amount of total code. 06:39:32 sure 06:39:48 yeah, my brainfart.. I'm thinkin' it's a Good Thing... 06:40:21 I was just pointing out that "1 or 2%" is semantically null. 06:41:09 In fact, I'm not sure and have not tested it or planned thru, but.. It almost suggests that vocs and such become moot at the level they are currently considered. 06:41:11 Personally I like Forth's attitude of "if the programmer wants indirection, he can say so explicitly" 06:41:12 well, it's worth a look, I think 06:41:59 yeah, basically an object-oriented approach 06:42:02 right, tathi but remember: I don't want to support users generating asm HERE - let them link with it or use dlopen and "our conventions". 06:42:16 I didn't say anything about generating asm 06:42:43 tathi: understood, the "indirection" ala' forth prompted that. 06:42:49 I don't see how. 06:43:14 tathi: prolly paranoia and my head leaping all over and all angles at random, sorry 06:43:28 what kind of code you compile to should be orthogonal to how your dispatch mechanism works. 06:43:54 especially if you're talking about layers of translation to get there at all. 06:43:58 you mean the inner-interp stuff? the stepper/nesting stuff? 06:43:58 tathi, well yes it's oop but it would be better to code it in Forth or C 06:44:08 virl: yes 06:44:52 when you would write that in an OOP language it would have in coding an not nice overhead 06:44:53 Writing this in C makes things.... Interesting, because we can ignore a lot of machine-issues and leave them to modular-code. 06:44:59 right 06:45:23 virl: sorry, when I say OOP, I usually mean the concept of OOP, not "an OOP language". 06:45:28 I don't care how you implement it. 06:45:35 ahh, right. 06:46:15 Yes, and in forth - like C - we should be thinking of "objects" and "contexts" and "applicable support" 06:47:11 again, I like the directness of forth :) 06:47:15 What I think this does is simplify the potential for FFI, prototyping and assert/verify, and combine elements of vocs/order 06:47:45 tathi: sure, and I can recall many happy years with FIG and FPC 06:49:52 I agree, except that I don't see the point about FFI 06:50:48 tathi: well, I'd been worried about "typing" and size/width and such - forth doesn't want to consider it... Functions and shit will TREAT it as they wish, not as it IS 06:51:51 yes, but any FFI library is going to have to deal with those issues, and compiling native code, you should just have to pass it the values for the arguments, and the prototype for the function to call. 06:52:07 I think this makes C "primitives" easier, from the hi-level universe. 06:52:52 Yeah, and those 3rd-party libs are.. 1) external; 2) MAY compile; 3) machine-specific via their own autotooling. 06:53:23 oh, sorry 06:53:25 I can't trust we all speak the same way, until we talk hi-level and can speak generic C 06:53:34 wasn't talking about a 3rd-party lib, necessarily. 06:53:53 yeah, I can't get the latest FFI-capable Gforth to build. 06:54:06 but I think that FFI should be encapsulated into its own module, and should translate from whatever types you're using into whatever types are needed to talk to the outside world. 06:54:16 ..well, ok - I tricked it, but it goes nuts with doubles/floats 06:54:26 tathi: I agree 06:54:33 ...trying to consider that. 06:54:55 and unless I very much misunderstand what you mean by FFI, an FFI library is machine-specific by definition. 06:55:05 no 06:55:34 ok, let's get on the same page first then :) 06:55:35 generically, it means all interfaces... ALL I care about is getting between the forthish-VM and C 06:55:58 ok, but WHEN does this getting between things happen? 06:56:20 as far as I'm concerned, if it's compiled into the VM, it's not FFI 06:56:48 if you're telling the VM to dlopen() a library that it wasn't compiled to know about, and call functions from it, that's FFI. 06:57:45 and according to everything I know, that DOES require machine-specific code, because different architectures/OSes have different calling conventions. 06:58:50 sorry, I forgot I had to get garbage outside... lemme' catch up 06:59:01 well, that can be translated explicitly 06:59:50 virl: sorry, what can be translated explicitly? 07:00:15 What I am suggesting is, primitives - and the engine/interface - is written in C. Anyone wanting to write a primitive will use C-calling conventions and our FFI to get from the vm/engine space to their func/call. 07:00:46 ..and back 07:01:16 ..This would NOT screw with bytecoding scheming if we can get THAT sorta' thing shoehorned in. 07:01:18 tathi, I guess the FFI calling code, but ok I never programmed something like that 07:02:11 virl: yeah, I agree. I was just saying that doing that sort of thing involves machine-specific code at some level. 07:02:33 I certainly think it should be hidden underneath an API that you can provide everywhere. 07:03:10 I still like some of the bytecode concepts, but it seems like a slow layer atop the C core and it would likely interfere - and slow - hilevel. Now, otoh... If the bytecode was just a new class/type and written in C.... 07:03:11 PoppaVic: ok, I wouldn't consider it FFI if it's compiled into (or as a module designed for) the VM. 07:03:24 and yeah, I can see that you could do that without being machine-specific 07:03:53 tathi: likely, yes. You can also look at the FFI as the funcs needed to xlate between contexts and call/return-from 07:04:34 * PoppaVic is bopping up and down like a gerbil on uppers 07:05:01 I'm not sure I understand the bit about bytecode. 07:05:22 tathi: it's merely another type-compiler and type-interpreter 07:05:51 ok, let's leave all that for a sec - take a breath.... 07:06:08 I was going to keep going, but ok :) 07:07:46 GIVEN: the vm (the interface and steppers/eval/nesting) is written in C, and we codify at least the datastack (maybe the return-stack as well), we deal in ptrs (or handles) on both stacks - that can look elsewhere for REAL data and SUPPORTIVE calls/funcs. 07:08:47 Are we looking at something with potential? Are we possibly even subverting the idea of "order" and "context"? 07:09:02 --- join: ravenEx (i=ravenEx@87.252.239.209) joined #forth 07:11:41 I'm pretty sure we should stick to "default-stacks-are pointers", because they just can't occur/accrue until runtime - when we have or are-loading modules to handle types and their support, wordlists, etc. 07:13:24 * virl is now afk 07:16:28 Yes, you're using a different model (an OO-like model) instead of forth-like order/vocs/context. 07:16:42 No, I don't see that as being very useful. 07:17:11 But I've never been a huge fan of having a type engine built into a forth-like language. 07:17:55 I think that a more "direct" forth model is more efficient, and if it provides the primitives to easily do indirection when necessary, you don't lose much. 07:17:58 I'm not sure it affects order, I'm, just suggesting that it might obviate a lot of gymnastics and order/voc noise. 07:18:56 yeah, maybe. 07:18:56 So far, (and this is just me), I still envision pcode/high and primitives/low. 07:19:21 I don't use vocabs very much 07:20:01 pcode being a list of primitives 07:20:05 yeah, I like lexicons/vocs... problem is that it gets pretty sloppy 07:20:14 akin, yeah 07:20:45 sloppy how? 07:21:27 I sometimes think we SHOULD only "compile" lists of literals and ptrs-to-primitives... Forth prefers the more compact, and complicated nesting and nesting (repeat) 07:22:42 er...but if it's all stack based, it doesn't matter whether you do it nested or all linearly (except for space, of course) 07:22:55 ahhh 07:23:27 I mean, you can inline the whole nested structure to a linear one, can't you? 07:23:30 yeah, "stack based" becomes the rub... I'm beginning to believe it's nothing more than a commo-queue 07:23:46 tathi: you'd think. 07:24:07 "queue" implies FIFO 07:24:16 "stack" implies LIFO 07:24:37 otherwise yeah, they're both lists in which you insert/delete only at the ends...so? 07:26:00 I'm just thinking... It's a common commo-channel, and forth-purists just want to PRETEND it's a "stack - as they do gymnastics and array-ops 07:27:41 I don't see how you can claim it's NOT a stack 07:28:25 It's a list of things, you manipulate it only at the one end 07:28:35 Obviously it's also a communications channel. 07:29:05 Any programming language has some way to pass data (arguments) around. 07:29:46 Lisp has lists, Forth has a stack, most languages require you to refer to pieces of data by name to pass them around. 07:29:59 ahh 07:30:05 yes. 07:30:09 I see the prob 07:30:43 You are seeing "the stack" as really "a stack", and ignoring all the duplications and gymnastics. 07:31:33 Some routines treat it as a stack, others as an array, others as a queue - and it all gets jumbled. 07:32:39 ..and even then, everyone has to refill "the stack" with "locals" to work later, as other things consume further data or generate it. 07:34:06 so what? 07:34:14 it's being a stack is a very useful abstraction 07:34:25 I have begun to believe that forthish "datastack gymnastics" are the primary cause of slowdown. 07:34:30 hell yes! 07:34:46 I doubt it. 07:34:46 Stacks are handy... So are queues and arrays and trees, etc 07:35:13 Besides, if you want to compile to a register-based code and optimize out the gymnastics, that's not difficult. 07:35:34 I suspect, if you searched source, all those gymnastics are the highest-use words anywhere and when 07:35:41 ahhhh 07:35:52 now we are back to regs and asm. 07:36:08 because that's what practically all processors these days use. 07:36:13 ok 07:36:26 on a stack-based machine, gymnastics are fast 07:36:38 on a register-based machine, they're obviously somewhat less so 07:36:58 PoppaVic: hi 07:37:41 hi slava ;-) 07:38:18 slava: if you know the url to our log, I'd like to recommend you roll back about an hour and scan 07:38:36 I think I got a soul-eating idea by the tail 07:38:45 brb... lemme' recycle the ISP 07:38:45 --- quit: Quartus (Read error: 104 (Connection reset by peer)) 07:38:47 --- quit: PoppaVic ("Pulls the pin...") 07:39:42 --- join: Quartus (n=trailer@CPE0001023f6e4f-CM013349902843.cpe.net.cable.rogers.com) joined #forth 07:40:19 --- join: PoppaVic (n=pete@0-1pool46-77.nas30.chicago4.il.us.da.qwest.net) joined #forth 07:40:28 are you talking about your typed stack idea? 07:41:05 no, even past that... Considering stacks of indirect-refs to types-and-support. 07:41:57 i've never liked type-specific stacks 07:42:08 like having one stack for each type 07:42:18 Think of the primary datastack as just pointers to "types"; where every type has it's own stack and wordlists. 07:42:27 ahh... OK 07:42:44 how would you push/pop these indirect stacks? 07:43:10 push/pop where? why? It's contextual. 07:43:28 I have to go now, sorry 07:43:31 ok 07:43:35 later 07:44:46 Interesting. 08:01:20 --- quit: neceve (Read error: 110 (Connection timed out)) 08:01:52 --- join: neceve (n=Clau@unaffiliated/neceve) joined #forth 09:45:55 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 09:45:55 --- mode: ChanServ set +o JasonWoof 10:05:57 --- quit: PoppaVic ("Pulls the pin...") 11:24:55 --- quit: warpzero ("Lost terminal") 11:25:06 --- join: warpzero (n=warpzero@wza.us) joined #forth 11:45:07 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 11:51:59 --- quit: Cheery ("Leaving") 11:54:02 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]") 12:04:29 --- quit: ravenEx ("IGNORANCE IS STRENGTH") 12:33:30 --- join: Lars_G (n=lars@unaffiliated/lars-g/x-000001) joined #forth 13:05:30 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 13:23:16 SOSOP sex object sexual orientated programming, a scripting language for Pornsites 13:23:54 For some reason I'm reminded of Fozzy Bear. 13:37:09 Waka Waka 13:45:07 --- quit: GoHst10 (Connection timed out) 13:45:16 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]") 13:48:00 --- part: Lars_G left #forth 14:13:21 --- quit: virl (Remote closed the connection) 15:28:00 --- join: Brie (i=bre@ringbreak.dnd.utwente.nl) joined #forth 15:28:35 hiya 15:48:10 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-153-182.pools.arcor-ip.net) joined #forth 15:55:50 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 15:55:56 --- nick: snoopy_1711 -> Snoopy42 16:48:44 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 16:58:40 --- join: GoHst10 (i=WINNT@12-208-98-237.client.insightBB.com) joined #forth 17:08:38 hi 17:21:41 --- join: segher_ (n=segher@dslb-084-056-147-046.pools.arcor-ip.net) joined #forth 17:26:34 --- quit: tathi ("leaving") 17:28:04 --- quit: uiuiuiu (Remote closed the connection) 17:28:08 --- join: uiuiuiu (i=ian@dslb-084-056-229-170.pools.arcor-ip.net) joined #forth 17:31:47 uiuiuiu, where did you get your name? 17:32:04 --- quit: segher (Read error: 110 (Connection timed out)) 18:01:16 --- quit: GoHst10 (Remote closed the connection) 18:03:22 --- quit: neceve ("Bye people, I'm leaving") 18:19:48 --- join: GoHst10 (i=WINNT@12-208-98-237.client.insightBB.com) joined #forth 18:46:05 --- quit: Teratogen () 19:03:50 --- quit: madwork (Read error: 110 (Connection timed out)) 19:22:27 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]") 19:38:02 --- join: easy4 (n=ez4@c-68-34-246-125.hsd1.pa.comcast.net) joined #forth 19:42:55 --- part: apgo left #forth 20:41:46 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 20:41:50 hi 20:53:53 --- quit: easy4 (Remote closed the connection) 20:54:43 --- join: easy4 (n=ez4@c-68-34-246-125.hsd1.pa.comcast.net) joined #forth 21:20:42 --- quit: easy4 (Read error: 110 (Connection timed out)) 23:13:47 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]") 23:59:59 --- log: ended forth/06.03.22