00:00:00 --- log: started forth/05.09.02 00:11:10 --- quit: ayrnieu (Read error: 110 (Connection timed out)) 00:13:16 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 03:26:57 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:02:47 --- join: PoppaVic (n=pete@0-1pool46-185.nas30.chicago4.il.us.da.qwest.net) joined #forth 05:03:42 Mornin' 05:12:40 hmm 05:13:09 Hi 05:13:15 mornin' 05:13:22 How you doin'? 05:13:45 Good. 05:14:03 Think I finally managed to wrap my head around Verilog. 05:14:09 Well, I spent another hour or so on that header last night ;-) 05:14:27 Verilog... System for chip-layout/design/emul is it not? 05:14:47 yeah. 05:14:59 ok.. Had looked at it a few years ago 05:16:22 --- quit: tgunr (Read error: 110 (Connection timed out)) 05:16:25 I've been looking over the opcodes-stuff, and I have to wonder if it can be further decomposed well, or what might be missing. 05:17:02 http://rafb.net/paste/results/QB73LF51.html 05:17:27 I think it becomes particularly interesting with <=8-bit opcodes 05:20:50 I'm actually thinking that there is something like a 'lit' we need that suggests a new opcode-array, size and opcodes. Sort of "windowing" as Z80's used to. This would let us define extra "tables" for such as mathlib or whatever. 05:23:19 thus: "fetch a code; uh-oh, next CELL is a opcode-struct-ptr; load the ptr; fetch a code, use the new opcode-array; (continue) 05:25:14 Now, another thought that occurs to me is... Well, if we write in C, a C-interface is a given; But, as-is, I'm trying to envision object-linking extensions or dlopen/dlsym interfacing as well. 05:25:50 --- join: tgunr (n=davec@66.160.179.125) joined #forth 05:26:30 as you can see, opcode #108 would prefix funcs from math.h, but it seems like a really awkward solution. 05:31:09 short of having some kind of compiler, I don't think there are other options. 05:31:26 for which of my dilemma? ;-) 05:33:33 dlopen/dlsym stuff 05:33:38 ahh 05:34:56 yeah, seems like every found symbol would need "attributes" for the fovm.. ISA, size, returns, args-fmt, etc. 05:36:16 But, ignoring that for a moment. Consider the extensible opcodes-idea. It does seem almost mandatory that extended codes would be written in C and fovm-aware, of course. Although, I could be getting turned-around. 05:36:20 and AFAIK there's no way of finding some of those -- they're just assumed. 05:36:27 ok 05:36:40 oh, you can use 'nm' and friends, but it isn't pleasant. 05:37:51 I think this opcode-thing is more important than dlopen for now. But, looking for a clean arrangement and - of course - we'd need to make sure we had 'glue' 05:38:11 yeah, I agree that you'd have to have glue 05:38:57 for example, as I look at the header... The double and FP stuff almost seems a good "extended-opcode" area. 05:40:51 There are about 60 opcodes for those as-is, and I would suspect the extended-code ideas for them would prolly allow for a lot better. In there place, of course, we'd need one or more codes to enable the extended-codes. (that would belong in the 'essentials') 05:43:59 tathi: also.. (and this is going to sound weird) I've considered the idea of a 'stack-struct' which would mesh ?P with width, RANGE, and opcodes. 05:45:45 I don't follow 05:45:52 hmm.. 05:45:56 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 05:46:49 like this: we know the engine must have a few regs: but we presume RP, DP - and we tend to think of them as a conglomerate. 05:47:07 add a FP and it makes it even more entertaining 05:48:30 I'm thinking that perhaps viewing opcodes from the view of a engine+RP+opcodes, and other-stack+opcodes might offer new ideas. 05:49:26 ..not that any solution we have is WRONG, but looking at the header and enums and engine,, you start to think there are patterns being suggested. 05:50:28 oh 05:51:24 am I making some sense? I'm never sure, it seems dependent upon a lot of glaring at the source and shuffling. 05:52:27 some 05:52:46 not a lot, yet. :) But I assume you'll work it out eventually. 05:53:31 As long as it's not sounding insane, and just confused - hell, I AM confused. I start seeing patterns and wondering how to improve shit clean. 05:55:08 yah, it sounds somewhat confused, but like there might be something underneath the confusion. 05:55:27 I think.. What I need is to mark those opcodes that are strictly IP related, RP related, and then IP/RP related. 05:56:02 ..that should clarify the patterns for FLOW - not data-ops, of course 05:57:51 the FS is about 50% RP/IP branching, it seems; the other 50% seems to be DS/FS(engine) related. 05:58:48 or, maybe I should think of an 80:20 split 05:59:02 boy, there IS something here... goddamn 06:21:41 --- quit: madwork (Read error: 104 (Connection reset by peer)) 06:22:37 brb.... 06:22:40 --- join: madwork (n=foo@derby.metrics.com) joined #forth 06:22:40 --- quit: PoppaVic ("Pulls the pin...") 07:00:40 --- join: PoppaVic (n=pete@0-2pool238-242.nas24.chicago4.il.us.da.qwest.net) joined #forth 07:00:57 hokay, back again ;-) 07:05:38 --- nick: Raystm2 -> nanstm 07:06:33 PoppaVic! 07:06:42 tathi: umm.. Where the idea gets odd is "between-stack" ops. 07:06:45 hiya, mad ;-) 07:08:24 madwork: been beating the fovm.h file, and sorta' brainfarting/gassing right now... Ideas perk, but looking for relationships/patterns. 07:09:33 madwork: right now, I'm trying to ascertain if "stacks" are a good struct that can be self-contained. 07:09:35 Have you looked here? http://www.russianbrides.com/ 07:09:39 ;P 07:10:05 bah, most of those sorta' images are dogs you can buy for a pint of vodka at a local bar ;-) 07:10:11 Haha. 07:10:51 Forthy uses a stack structure. It also uses typed values, though, and stacks are one of those types. 07:11:45 source-urls? I'm pretty sure tathi is unto something, and this header could make the engines a better tool. 07:13:08 http://cvs.sourceforge.net/viewcvs.py/forthy/forthy/ 07:13:18 loading 07:13:24 Still much of a WIP, so expect some mess. 07:13:35 However, it's fully functional as it stands. 07:14:16 Jeez, haven't updated it in 8 months... :| 07:14:45 hmm, all I get are changes/update-comments 07:15:04 ahh, hit the ver# 07:15:09 Yep. :) 07:15:09 heh. viewCVS is kind of annoying like that :) 07:15:29 Forthy is ITC, by the way. 07:15:39 Cool, bookmarked (ITC?) 07:16:04 After all your discussions, though, I'm considering doing a Forthy2 that is bytecoded. 07:16:08 hmm, I sorta' like the idea of 'opcodes' and a simple-minded 'engine. 07:16:08 Indirect Threaded Code. 07:16:17 ahh, thought so. 07:16:36 PoppaVic, my "opcodes" are all registered by the user. 07:16:40 direct-threaded, to my mind, is more what an extractor/compiler should consider 07:17:00 right. see this: 07:17:13 Direct threaded in C doesn't make much sense, AFAIK. 07:17:26 http://rafb.net/paste/results/sXyi2v44.html 07:17:34 It's either ITC, TTC, or STC. 07:17:37 I've just started to add "struct stack_" ... 07:18:20 Given so much semi-interest by folks, I really think we can do better. 07:18:35 What the fffk is a fffp? 07:20:13 ahh, it's a func-ptr typedef 07:21:03 I'm partial to structs, unions, and typedefs. I believe they are unsung Giants 07:21:28 Sure! 07:21:51 At least you can somewhat adjust the language using them. 07:22:27 but, trying to codify the absolutely most basic forth-type engine is STILL suggesting to me that we need an underlying engine for pseudo-asm. I just can't get around it, but I AM ignoring it in this file. 07:24:36 Now, if we decide to use the "struct stack_" idea, we still need several things... 1) The VM* itself is still an argument/accessible element; 2) interstack operators. The latter is bugging me a bit. 07:25:06 Interstack swap? 07:25:23 interstack movement/gymnastics/drop, etc. 07:25:51 I'd even be willing to accept any engine needs RS and a DS 07:26:27 Well if you have the stacks freely creatable and addressable, then you don't need RS and DS built in. 07:26:59 maybe, but the engine opcode-interp/vectors need to be supported. 07:27:21 You could have one built-in stack, and it would be a stack of stacks. Then, address the stacks within... 0 is RS, 1 is DS, etc. 07:27:34 the ENGINE - or vm - is where you would have the very few regs and such 07:27:46 yeah, same as a LL 07:28:12 seems like we'd need a special vm opcode of "lit_stack" 07:28:57 I'd then consider MANDATING opcodes/funcs to get to and from datastack (retstack?) 07:29:55 THe byte/sub-byte opcodes (tokens) can open the universe, if we can guesstimate properly. 07:31:01 Well, you could use the same opcodes for interstack operations for intrastack as well. 07:31:29 sure, but you'd need to assume or ref the stacks. 07:31:34 Yep. 07:31:38 You'd ref them by number. 07:31:43 ..and their sizes are not an assumption 07:31:44 Index into the main stack. 07:31:48 er "widths" 07:31:59 The sizes are contained in the stack structures. 07:32:12 But yea, I guess if dissimilar stacks were swapped to/from... 07:32:15 yup, ala' "struct stack_" 07:32:18 ie. different widths... 07:32:24 right. It complicates life 07:32:34 You'd need to convert the different sizes. 07:32:39 all you can know from zero is CELL/DCELL 07:32:56 and, lord knows how either are treated 07:33:39 perhaps we need a SSTACK and DSTACK ? 07:33:41 Well I'm thinking that any specific static implementation using the VM will have to make informed assumptions about the data sizes involved. 07:33:50 --- join: sproingie (i=foobar@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 07:34:07 ie. you create a DS and an RS in your internal stack, and all Forth code on top of this engine assumes the correct sizes. 07:34:25 which means, "assume I am one/two CELL"? I dunno it's starting to bleed, weep and generally get confuzzling 07:34:26 Dissimilar-interstack swapping could either result in an error, or a conversion. 07:35:04 ok.. Yer assuming a basic ptr/int stack-engine then? Where RS and DS are integrated, right? 07:36:09 some forths do use the DS for the RS 07:36:57 you can't do most of the funky tricks that rf does with the RS with that approach 07:37:02 Not for the VM, no, I'm not assuming that. 07:37:23 I'm saying the stacks could be contained/configured in one internal VM stack of stacks. 07:37:34 Then the code you generate makes assumptions based on this. 07:38:09 sproingie: I'd assumed that for my latest, yeah. But, I'm trying to work within tathi's C and clean it up as I improve. basically, I'm seeing patterns and behaviors that suggest we are missing ideas/bets 07:39:00 madwork: stacks-of-data - meaning they need to allow for intra and infra stack ops. 07:39:39 A stack of stacks-of-data. 07:39:59 And yes, the opcodes would address the stacks in the "system stack"... source and destination. 07:40:33 perhaps all we need to do is declare that RS and DS are integral to the engine, single-width. And that all new stacks supply a DS/RS interface? OR a DS-only interface? 07:41:14 hmm... 07:41:25 In C, I can see this as a ctor 07:42:08 but, I refuse to leap - you guys also need to cogitate, intuit and suggest 07:43:30 I'm also trying to decide if the tathi/herk FlagStack-of-bits deserves consideration.. It's interesting, but is it efficient? 07:44:01 more importantly: can we meld it with this new paradigm? 07:45:17 The boolean 32-bit/flag limit really bothers me, intestinally. In reality, I don't see it as a nasty-limit. 07:46:16 myself, I tend to 64-80, 128 and other powers-of-two as limits/buffers 07:47:28 madwork: but, yeah: The opcodes-ideas are vastly interesting. Just a matter of what and who has which opcodes/context. 07:47:52 PoppaVic, this configurable stack mechanism could come in handy if you want seperate control-flow, locals, vocabulary, etc. stacks that are internal and potentially untouchable by the user. 07:48:21 damn right it could, but HOW and based on what struct and such gets interesting 07:48:45 Yep. Thanks for triggering the idea, anyway, I just might use it. ;) 07:48:59 damnbetcha'/np 07:49:12 I do expecgt feedback on it ;-) 07:51:48 I'm just about convinced the engine/vm needs a RS/DS that are integrated, and opcodes that work with them and the engine. DCELLS, Strings, FP are all additional structs that need to base upon the engine+RS/DS ONLY 07:52:36 that "base upon" suggests mandatory ops early. And then things can't generally get between stacks otherwise 07:54:20 --- part: PoppaVic left #forth 07:54:30 --- join: PoppaVic (n=pete@0-2pool238-242.nas24.chicago4.il.us.da.qwest.net) joined #forth 07:54:42 damn, xchat went ape 07:56:47 So, the basics are between DS and RS, but intrastack is obviated because we'd add %I[><]DS%I ops (mandatory), but there would be no way to mandate >string string> and such 07:58:15 anyway, yeah - the idea(s) have merit. And, I think C should be the major compiler, asm as platform-included, and we let linkers and compilers do their job. 08:01:55 note opcodes at 'lit' (the 129/125 point) 08:02:49 THis sounds like we need a 'stack' lit for some or all non-DS 08:05:21 not sure HOW that would work out. [infrastack c, op, [data,] ] and [intrastack c, DST, op,] ? 08:13:58 hmm, or [intrastack c, DST , SRC, op c,] - yeah.. ok. hmm 08:14:40 ok, that needs cogitation. It might even be a recompiler/optimizer issue. 08:16:44 Hmm.. OK, lemme' suggest this - you guys should comment/flame - We want the forthish-engine to compile 'code' that we can run rapidly, and also with enough info for debugging/decompiling or RECOMPILING as native, don't we? 08:19:17 Anyone? 08:21:02 Near as I can tell, we are trying to run 100% colon-defs ([ip]code) or C-funcs, right? 08:21:25 (note: the latter suggests other glue for other engines) 08:21:51 The latter suggests and extension opcode for calling c functions. 08:22:09 --- quit: tathi ("leaving") 08:22:10 ITC makes the debugging/decompiling easy. 08:22:21 That's not a VM issue though, really. 08:24:06 no. The entire cross-related mess and getting betweem shit would 08:24:40 Define "shit". 08:24:47 the ITC would imply a magnititude of "slowdown", though 08:25:19 madwork: stacks-of-engine; glue-between-whatever-C/forthish 08:25:32 "glue" 08:26:00 The glue is simple if you only allow calls to a predefined function type. 08:26:07 To me, the fact "glue" costs a bit more is a non-issue 08:27:05 madwork: ok, how does that work with fovm/C/perl/python/etc? You see, the best we can hope for is a forthish/C interface. 08:27:56 AND, (mind you), I am a major advocate of headers and defs/decls that make interfacing easy - I HATE guessing. 08:28:03 I don't use them, so I don't know. What I did in Forthy was pretty simple though, and it works well. But it requires a wrapper function for whatever you want to call in the C-world. And it uses the data stack to pass values in and out of the VM. It can also call the vm primitives directly. 08:28:10 My advice: don't handwave. Document your requirements in detail, look for solutions that fit those requirements. 08:28:38 Quartus: yeah, the req and "handwaving" are my current mission. 08:29:00 Docs are NAI. Tech writing is almost fun. 08:29:07 Leave the field open for implementation methods to innovate as much as possible, as per the Forth Standard. 08:29:08 I hate writing docs. :P 08:29:43 --- quit: lscd (Read error: 104 (Connection reset by peer)) 08:29:45 Interfacing is more trouble, because a LOT of shit doesn't doc/list those req - particularly in codified manners. 08:30:43 Quartus: yes. If I can get it to work between forthish and C, and cross-platform/cpu - everyone else can suffer or offer answers we can codify. 08:31:23 asm-programmers are worst-case, followed by 08:32:29 asm programmers will roll their own no matter what you provide. you dont need to cater to them 08:32:40 It's full-circle, at this point... Forthish is more a cross between shell and compiler than gcc/cpp behave. 08:32:58 sproingie: ok, that was my feeling - gut-wise 08:33:11 C api is probably all you need. C++ API doesn't make a lot of sense, and C++ can use extern "C" anyway 08:33:21 er s/api/abi/ 08:33:51 java will happily use the C abi as well 08:34:09 well, dealing with C++ completely adds a whole new universe of issues. It ain't C, and C is (mostly) just a sloppy assembler. 08:34:10 as will .net etc. it's the lingua franca of interfaces really 08:34:51 right. WOrst cases are still a few clocks getting a copy of data to ds/rs or whatever. 08:35:03 C is not just a sloppy assembler. it has well-defined calling conventions, at least per OS platform 08:35:46 within a single object, the calling conventions in fact don't vary, and that's all C addresses anyway 08:35:48 you can't cleanly access the asm() of C, let alone per-compiler. So, you can do best by ignoring it. 08:36:06 that's what calling conventions are for, so you don't have to access the asm 08:36:07 yeppers 08:36:26 you just need to know the address and args 08:36:44 You don't even need the args if you use the data VM struct's data stack. 08:36:51 context structure, right PoppaVic? 08:37:06 true. most language's glue layers use a single arg passing convention of their own 08:37:12 sproingie: right, and those "calling conventions" are never really cleanly documented. To me, yer best off with C, ptrs, values, structs and func-ptr 08:37:22 I do this: 08:37:22 void word_foobar(FSYSTEM *sys); 08:37:33 gratuitously incompatible ones i might add. it's actually kind of annoying, keeps you from mixing them easily 08:37:33 Then I manipulate the *sys stack to get what I want. 08:37:50 let them write a C interface - so WHAT if their C-interface has to run OUR C-interface 08:38:09 Generally the mountain does not come to Mohammed. 08:38:28 Q: and mohammed was a lamer ;-) 08:38:29 does if you're mohammed. your mountain mileage may vary 08:39:00 mountains and oceans are still mountains and oceans: build your bridges/tunnels 08:39:20 All marvellous greeting-card stuff, but you're not missing my point I hope. 08:39:52 this sounds like a lot of angst over something as simple as "what should the embedding API look like" 08:40:19 Q: which point? That we can't save the whales? I knew that. Frankly, I've just about concluded that a C-interface of code/headers is the best universal that is possible. 08:40:26 No angst here. I think building your VM and waiting for the C folks to bridge over to it will be a long lonely wait. 08:40:41 personally i recommend a high-level and a low-level one. change the low-level one as often as you please while you're in "beta" and keep the high-level one as stable as you can 08:41:08 I already live in C I can't save the whales (or the lurking perl, python, lispers) 08:41:16 FICL's got an extremely nice embedding api. in fact, the design in general. i suggest liberally ripping off FICL 08:41:29 i think it's bsd licensed too 08:41:31 sproingie: I'm tempted 08:41:47 shoulders of giants and all that 08:41:55 anyway, gotta get going. later 08:42:00 ficl is around here somewhere, but I want to avoid it as possible as we discuss the other shit 08:42:08 laters, sproingie 08:44:15 You know.. I've been advocating a synthASM for months, if not years. *sigh* I begin to suspect it's almost suggestive of a GOOD forthish CPP over forthish C. 08:44:52 Not sure precisely what that means or implies, but it IS suggestive. 08:45:40 Mostly, it seems to mean source+macros+pcode+stepping at two levels at the least. 08:47:28 oh... Plus, "affect interpreter/interpretation" versus "affect compiler/compiling". Which almost fits the .[ch] universe. 08:48:03 I think there is a 3rd level, is all. 08:48:24 "affect the decomposer/recompiler" 08:48:31 maybe.. Not sure 08:52:06 source->interpret[change interp]->compile[change compile].... 08:52:59 pcode->decompile[change decompile]->source 08:53:08 maybe.. not sure. 08:55:13 Thing that I see - in ##C, #forth and #asm is.. Folks tend to confuse preprocessing with language, and language with pcode, and pcode with binary. 08:56:03 I'm not sure how to kick them in the head, and not sure how to resolve this other than by a forthism engine anyway. 08:56:32 the line is supposed to be blurry. and it's getting even more so 08:56:50 yes, and the programmers get flakier. 08:57:08 you want VM in native code, do JIT compiling. forth doesn't lend itself to whole-program compiling anyway 08:57:46 even JIT is just another mess 08:57:49 not having bindings makes dataflow a real bitch. even factor only inferences stack arity 08:58:41 you're looking for the platonically perfect stack of program transformations from source to bits 08:58:50 good luck in your search. it doesn't and probably can't exist 08:58:53 "bindings" are another term we can misuse. Qhat do YOU mean? I'm trying to KISS and allow for expansion. 08:58:56 our brains themselves are too messy for that 08:59:13 Qhat/WHAT 08:59:15 bindings are something forth generally doesn't have. variables 08:59:21 there's globals, but that's pretty simplified 08:59:24 I know. 08:59:49 are you suggesting structures/slots/entities that typify themselves? 09:00:19 size, vtables, etc 09:00:56 no, i'm actually suggesting that you probably can't get a perfect system of transformations (preprocessing, compiling, running) except on paper 09:01:20 Because, I can see the usefulness. BUT, it seems like a source/host|target/goal issue 09:01:40 you can be mired in analysis paralysis forever, or just hack something, knowing you'll get it wrong some of the time 09:01:40 sproingie: ahh, ok - perfection is a lost cause, I agree 09:01:44 you can always fix it later 09:01:49 yeppers 09:02:12 sproingie: what is your normal platform/environment? 09:02:42 abut the only platonic forms i can think of for program transformations are monads. and haskell even turns those into an unholy mess because pure theory is so hard to work with 09:03:15 my normal platform is perl, it pays my bills. i prefer lisp and scheme currently, but i'm sort of a gadfly of languages 09:03:25 speaking of paying the bills, i'm late. gotta go 09:03:26 "monads" always make me homophobic; haskell is as much noise as any other shit. 09:03:27 toodles 09:03:36 lisp/scheme? 09:03:43 ok, latters 09:03:50 laters, two 09:03:54 hmm 09:04:09 * sproingie gonna be gone for a couple weeks, might log in next weekend. vacation, then business trip 09:04:18 damn, ok - stay well 09:04:19 lattes all ;) 09:05:52 I think we STILL have a lever. 09:06:25 ..but it ain't remotely "cute" or "fun". 09:06:41 One end or the other is liable to scream 09:14:06 OK.. I guess that's it today. No other comments seem to suggest a sensible alternative. 09:15:39 tootles 09:15:42 --- quit: PoppaVic ("Pulls the pin...") 09:47:02 --- quit: virl (Remote closed the connection) 12:22:19 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 12:38:35 --- join: virl (n=hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth 13:11:43 --- join: madgarden (n=madgarde@Kitchener-HSE-ppp3577151.sympatico.ca) joined #forth 13:33:57 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-158-049.arcor-ip.net) joined #forth 13:50:39 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 13:50:41 --- nick: snoopy_16 -> Snoopy42 13:50:46 --- join: Ray_work (n=vircuser@adsl-66-139-199-228.dsl.rcsntx.swbell.net) joined #forth 14:35:59 --- join: crc (i=crc@pool-70-110-143-162.phil.east.verizon.net) joined #forth 14:37:45 --- mode: ChanServ set +o crc 14:39:46 --- join: saon_ (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 14:49:15 --- quit: saon___ (Read error: 110 (Connection timed out)) 14:49:16 --- quit: saon (Read error: 110 (Connection timed out)) 14:55:45 --- quit: ayrnieu (Nick collision from services.) 15:01:14 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 15:52:44 --- join: lynx` (i=lynx@07-036.147.popsite.net) joined #forth 15:53:19 --- part: lynx` left #forth 16:22:32 --- nick: nanstm -> Raystm2 16:48:29 --- quit: saon_ (Read error: 110 (Connection timed out)) 17:28:33 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 17:28:49 --- quit: ayrnieu (Nick collision from services.) 17:29:35 --- nick: ayrnieu_ -> ayrnieu 18:20:05 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 18:50:05 --- join: Downix (n=nate@adsl-156-158-110.mia.bellsouth.net) joined #forth 18:50:33 Sam Falvo still hang out here? 19:00:03 I don't see him here 19:00:19 he's on in a different channel though 19:28:00 --- join: MacVince (n=vince@modemcable006.81-37-24.mc.videotron.ca) joined #forth 19:28:05 --- join: tkb (n=tkb@dhcp-69-43-0-163.pitbpama-max5.dialup.citynet.net) joined #forth 19:29:04 --- quit: tkb (Client Quit) 19:56:34 --- part: MacVince left #forth 20:13:54 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 20:14:07 --- quit: ayrnieu (Nick collision from services.) 20:14:13 --- nick: ayrnieu_ -> ayrnieu 20:15:55 --- quit: ayrnieu (Read error: 104 (Connection reset by peer)) 20:16:38 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 21:42:11 --- quit: Downix (Remote closed the connection) 21:42:11 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 22:36:27 --- join: ayrnieu_ (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 22:36:41 --- quit: ayrnieu (Nick collision from services.) 22:36:48 --- nick: ayrnieu_ -> ayrnieu 23:18:21 --- quit: sproingie (Remote closed the connection) 23:59:59 --- log: ended forth/05.09.02