00:00:00 --- log: started forth/06.08.30 00:21:09 it is one way to remove the need for state-smart words 00:21:35 As I understand it, it adds additional complications as regards FIND, at least. 00:22:15 of course, just having a MACRO wordlist is much much MUCH simpler, does the job at least as good, and removes the need for an IMMEDIATE bit in your headers, too 00:23:10 I have no complaint with immediate words. I have inlining words in Quartus Forth as well, but it's a native-code system, so that's expected for optimization reasons. How do your macro words behave? 00:24:37 in compilation mode, the macro wordlist is searched first 00:24:51 if anything is found, it's executed 00:25:19 if not, the FORTH wordlist is searched, and the found xt is added to the current definition 00:25:36 in interpretation mode, only the FORTH wordlist is searched 00:25:50 in short -- the standard old-fashioned way :-) 00:25:53 Oh. So immediate words are invisible in interpretation mode. And the macro wordlist floats on top of the search-order during compilation. 00:26:07 yeah 00:26:18 To my way of thinking, the old-fashioned way is single-wordlist. It's still the simplest implementation. 00:26:21 a single MACRO wordlist is interesting and fun until you start wanting to have vocabularies in your program. 00:26:40 Yes, it occurs to me that multiple wordlists and the macro wordlist would cause all sorts of annoying subtleties. 00:26:49 the only complication is if you want to define new immediate words 00:27:05 Indeed. Which are handy. 00:27:09 sure 00:27:35 I can afford the flag bit in each header. :) 00:28:07 well right now i actually have both the macro-wordlist _and_ immediate-bits 00:28:24 avoids the issue nicely ;-) 00:28:45 Kind of makes the macro wordlist unnecessary, doesn't it? 00:29:10 nah, it helps for many other things 00:29:14 Like? 00:29:16 state-smart words 00:29:23 S" and TO 00:29:45 and, in OF, most compile-only words are _not_ compile-only, so all those too 00:29:50 What problems are introduced by S" and TO being state-smart that your macro-wordlist solves? 00:30:14 : S" state @ IF ... ELSE ... THEN ; 00:30:29 Right, the obvious implementation for the FILE S" 00:30:35 i just have a different S" in the macro voc than in the forth voc 00:30:50 Ok, but what problem arises from the first that is solved by your macro voc? 00:31:25 can't postpone it with correct (and logical) semantics 00:31:42 read ertl's papers about it 00:32:20 Does that ever come up as an issue? I mean, ever? I can live with S" and TO giving different results when postponed, if the alternative is a hairy tangle of multiple wordlists and xts. 00:32:45 it's really not hairy 00:33:08 Neither is the status quo, if the biggest issue even Ertl can raise is that I might have trouble postpoining S" and TO. 00:33:24 and all other state-smart words 00:33:43 like, in a native compiler, all your primitives 00:33:47 You've already said your solution gives you grief when you want to add new immediate words; there's no solution that doesn't cause issues. 00:34:04 GAH! No, my native compiler does most certainly NOT have all state-smart words, hardly any. 00:34:12 no, no grief -- only if i remove the immediate bits from the header 00:34:22 native forth cpu, heh 00:34:34 or a token-threaded engine 00:34:48 No reason for a preponderance of state-smart words in either kind of Forth. 00:35:24 well how do you define "dup" for example? 00:35:36 It's a primitive. 00:35:47 no, it's a token 00:36:07 Somewhere, there's a little bit of machine-specific code that does the operation of DUP. That's a primitive. Not a token. 00:36:28 so the compilation version would be like : dup 6 emit-token ; or something 00:36:40 and the interpretation version is just : dup dup ; 00:36:50 Good lord, no. The interpreter loop does the compilation of DUP into a definition when it's compiling. 00:36:57 If it's not compiling, it executes DUP. 00:37:14 There's one definition of DUP, and it's not state-smart, not in native-code, not in a Forth CPU, and not in a token-threaded engine. 00:37:21 it cannot execute it. it needs a definition that contains that token. 00:37:38 So you're suggesting a token-threaded Forth doesn't have EXECUTE ? 00:37:48 : execute >r ; 00:38:00 heh 00:38:31 EXECUTE takes an xt 00:38:35 You can most certainly execute a token in a token-threaded system. If it's built so it has to stuff the token into a temporary definition to do it, so be it. 00:38:46 but what you call "primitives", are not xt's, but tokens 00:39:02 heh sure, you could do that 00:39:46 In a token-threaded system, the tokens are a next-level abstraction of the instructions the machine itself provides. They are not any more complex to manage in a token system than they are in any other kind of implementation. There's nothing 00:39:56 so EXECUTE has to know that when running in interpretation mode, it has to find out if the xt it got is something that just compiles a token, and then do the temp definition thing 00:39:57 about a token-threaded system that would cause you to make all your words state-smart. 00:40:14 no, the tokens _are_ the insns the machine provides 00:40:36 In any kind of a Standard Forth, words with default compilation semantics are not state-smart. They do not compile themselves. The interpreter loop does it, and that doesn't vary by architecture. 00:41:18 my : dup dup ; gives you just that, heh 00:41:49 Implementing your whole system so that any word has to be state-smart to compile its own self is criminally insane. 00:42:41 hehe 00:49:58 --- quit: JasonWoof ("off to bed") 00:50:05 --- join: JasonWoof (n=jason@c-71-192-33-206.hsd1.ma.comcast.net) joined #forth 00:50:05 --- mode: ChanServ set +o JasonWoof 00:50:13 --- quit: JasonWoof (Client Quit) 01:01:33 Updated FACILITY wordset for windows: http://quartus.net/retro/facility.fs 01:03:21 Now with word-wrap. 01:34:26 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 01:58:49 virl gm 01:59:00 hiya 01:59:18 how are thins? 02:00:29 things are ok, except that I don't know how I should go further in my forths vm design. 02:01:51 good. and keep it simple with lots of possibilities 02:01:53 :> 02:13:10 when is something simple to you? 02:15:02 when it can be explained and taught to somewhere else in a few minutes. 02:15:07 someone else 02:15:15 or less 02:18:22 when it's a bytecode vm? 02:18:42 can i ignore the "vm" part and focus on "bytecode"? 02:19:50 a bytecoded vm would be that vm in which the opcodes are each an index into a table of function and/or data pointers; 02:20:23 in c, it would be the syntax. (*funcDataPtr)[opcode] i think 02:20:31 with a () after the [] 02:20:41 (*funcDataPtr)[opcode]() 02:21:13 void *funcDataPtr[] = { func1, data2, ... }; 02:37:01 virl have you implemented a save feature in your forth? 03:19:57 a save feature? you mean saving the image? 03:20:09 yes 03:21:55 no, with such details I don't bother myself yet. 03:22:25 so how do you save your incremental changes made to your forth? 03:27:07 in sourcecode, hell I don't develope it in itself yet. 03:27:24 ah 03:27:25 ok 03:27:36 which source language? 03:28:22 C at the moment 03:28:29 ok 04:30:13 woohoo i have a ancient c-code FIG-FORTH running!!! 04:33:46 it's so old it has VLIST defined 04:38:06 VLIST? what was that? 04:38:15 vocabulary list 04:38:26 you just dated yourself ;) 04:40:00 dated myself? 04:40:25 I used newer versions of forth 04:43:11 --- join: PoppaVic (n=pete@0-1pool74-186.nas24.chicago4.il.us.da.qwest.net) joined #forth 04:44:14 PoppaVic i have a working c-coded FIG-FORTH running 04:44:25 coolness ;-) 04:44:26 it's so old it has VLIST 04:44:31 yep 04:44:43 oy, I recall that/then 04:45:04 yea 04:45:27 still, in that Long Ago FIG was fun 04:45:41 seriously 04:45:48 4 decades 04:46:04 I always felt FPC was sorta' nice. 04:46:15 F83 was ok, though 04:46:16 fpc was excellent for a free project 04:46:50 Quiznos: iirc, there was no "linux" at the time, so DOS woked well for it 04:46:55 worked 04:47:01 lol wok'd 04:47:04 yep 04:47:12 we should port fpc to linux 04:47:14 Wok with Yan ;-) 04:47:33 I think it had too many close-ties to DOS. 04:47:50 partition them 04:47:52 :) 04:48:34 well, by the time to discovered and ported all the screen & key and shit - prolly using ncurses - you'd still end up with an archaic system 04:49:05 i dun care; it's dos and it must be ported 04:49:07 lol 04:49:12 oo dosemu 04:49:19 i wonder if it would boot 04:49:24 that would be a good test 04:49:26 ugh... double-ugh 04:49:31 lol 04:49:43 fine stay with icrofost 04:49:47 lol 04:49:55 eruh? 04:50:09 s/eruj/era/ 04:50:10 heh 04:51:19 and the FIGFORTH has an ALIAS word too 04:51:25 what's faster? crying when a word isn't defined or making it work? 04:51:41 written by Alan Pratt 1985 04:51:46 crying 04:51:47 lol 04:51:48 virl: heh - faster? Depends on the crier ;-) 04:51:59 lol 04:52:24 virl: also depends on your friends. 04:52:27 ah yeah.. 04:53:05 I meant with 'crying' exceptions 04:53:17 Some of the guys in C, yeah - I'd toss them a solution.. Because they spend so much time helping others. 04:53:51 are throwing exceptions faster than fixing something at runtime? 04:53:56 I don't understand "crying exception" - you mean like "scream at the user code"? 04:53:59 ahhh 04:54:02 lol 04:54:10 "crying excepentions" :LOL 04:54:29 I don't much like things that fix the world in silence 04:54:37 ugh.. you stupid folks. 04:54:59 I meant with crying simply exceptions, when you can't read then I'm really sorry. 04:55:38 lol 04:55:45 virl we're just havin fun 04:55:48 * PoppaVic shrugs 04:55:50 lighten up :)~ 04:56:51 but I do... because the other way is the java way of crying about everything even the stupid ones. 04:56:59 heh 04:59:41 I'm not really hip to "exceptions", I test returns and deal. 04:59:54 me too 05:00:11 although, I'm thinking I may use either libevent or liboop 05:00:22 brb - nature screams 05:00:23 exceptions are disgusting... somehow.. 05:04:56 --- quit: k4jcw (Remote closed the connection) 05:04:57 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 05:05:24 yeah 05:05:43 they seem to do a lot of code-leaps I don't much care for 05:05:44 but it's the way how today is handled 05:06:32 I've heard arguments that they are also cheaper to code and faster, too 05:07:10 --- join: k4jcw (n=jcw@adsl-065-006-151-062.sip.asm.bellsouth.net) joined #forth 05:07:14 ..seems unlikely to be cheaper, but perhaps faster 05:08:26 that "today" gig is why I've been thinking about such as libevent, though 05:08:58 and, of course, there is the chance you can view exceptions as "events" as well. 06:08:38 --- quit: mark4 ("Leaving") 06:24:50 --- join: Ray_work (n=Raystm2@199.227.227.26) joined #forth 06:41:13 --- quit: PoppaVic ("Pulls the pin...") 06:44:15 --- join: mwh8 (i=sibbig@210.185.188.47) joined #forth 06:47:32 . 07:08:39 --- join: nighty (n=nighty@66-163-28-100.ip.tor.radiant.net) joined #forth 07:09:15 --- quit: nighty_ (Read error: 113 (No route to host)) 07:14:25 --- join: segher_ (n=segher@dslb-084-056-164-202.pools.arcor-ip.net) joined #forth 07:24:27 --- quit: segher (Read error: 110 (Connection timed out)) 07:30:37 . 07:32:57 --- quit: mwh8 () 08:09:44 --- join: rabbitwhite (n=roger@136.160.196.114) joined #forth 08:11:00 hey 08:13:17 hey. 08:29:29 hay 09:06:24 --- join: PoppaVic (n=pete@0-1pool66-85.nas22.chicago4.il.us.da.qwest.net) joined #forth 09:08:06 --- join: JasonWoof (n=jason@c-71-192-33-206.hsd1.ma.comcast.net) joined #forth 09:08:06 --- mode: ChanServ set +o JasonWoof 09:09:12 Hey. 09:09:23 rabbitwhite, so what are you forthing on these days? 09:10:11 hi 09:10:22 gamecube project 09:10:32 hi jasonwoof 09:14:24 you just missed a long design story i told on #forth 09:15:20 no rabbitwhite that was #c4th-ot :) 09:16:16 could be 09:17:23 Ahh, heh. 09:18:58 well in that case i guess you could probably read it in the online log 09:19:04 does #forth have one too? 09:19:18 wait is it just #c4th? 09:22:02 #forth has one, dunno about #c4th-ot. 09:22:20 Got bored of Glypher, or evolved it into something else? 09:23:59 no, i thought Glypher was a failure, so what i'm currently doing is a re-attempt 09:26:23 How was it a failure? 09:27:54 i would say, but i'd risk starting controversy and i'm not really in the mood to argue 09:28:30 I understand. 09:28:51 you sometimes feel like everyone is wrong too? :) 09:29:03 Heh, sure. ;) 09:29:12 I've an interactive forthy fun thing planned as well. 09:29:38 what platform? 09:30:06 I'll probably build it on top of GLFW and PortAudio, so should be portable to a few platforms at least. 09:30:26 hmm 09:30:48 But currently, I only really care about Win, Mac, and Linus. 09:32:19 oh 09:34:13 by the way, i only meant when i said "controversy" that it could evolve into a flamewar of the whole channel, not necessarily that bad between the two of us, i don't know you well enough to know 09:34:23 *yet 09:37:23 ;) 09:37:50 I'm pretty easy going, and rather impervious to dogmatic issues, if that's the problem. 09:37:57 Forth must be this, Forth must be that, etc. 09:38:04 ugh 09:38:05 I like to forge my own path. 09:38:07 oh, well that's not what i would argue about at all 09:38:09 same here 09:38:24 I prefer to say "Forthish" or "Forths" or "variants" 09:38:34 Yea. Well, that's why my stuff is called "Forthy". 09:38:35 there _really_ is no one "Forth" 09:38:41 madwork: I know 09:38:42 i prefer just to say Forth 09:38:44 Forth is a concept, not a language. 09:39:03 that's pretty valid 09:39:20 forth veterans are always saying that forth is a tool for designing languages 09:39:21 welllll 09:39:35 it's a stack-based engine, anyway 09:39:37 Well, that's one thing it's good at (and an aspect that I appreciate). 09:40:16 i feel like maybe it would be safe to say why i thought glypher was a failure 09:40:51 I won't jump all over you, so no worries. ;) 09:40:52 its pretty simple: i didn't know what i was doing, and i didn't know where i was going. another way of putting it is, nothing came of it. 09:41:44 Forth is good at doing that too. ;) It's so wide-open, with so many possibilities, it can amplify one's ambivalence greatly. 09:42:47 my current project is wildly different in the way i feel about it in terms of what it is producing for me 09:43:37 interesting point - boy do i know what you're talking about 09:43:55 :) 09:44:09 i've since learned to focus on strengthening my knowledge of proven techniques and constructs 09:44:36 Well, the approach I am taking is to keep my VM as flexible as possible, and let the user worry about what they want to implement by way of language and technology. 09:44:41 as my foundation inmproves i don't feel as lost 09:45:30 okay. 09:45:32 As well, for my interactive forthy fun thing, I want it to be both accessible and fun for the beginner. I have a 7-year-old who's ready to do some hacking, after all. 09:45:51 hack what? 09:45:53 So, I will support some common data types and structures natively. 09:46:11 hack the interactive forthy fun thing to make whatever it is he wants to. :) 09:46:15 madwork: sounds sensible in some ways. Someday, I'll get a copy to tinker ;-) 09:46:18 I want it to be fun like the C64 days were for me. 09:46:32 PoppaVic, have you seen/used Lua? 09:46:58 read of it, seen the url - have a copy archives (somewhere) - didn't like the semantics 09:47:32 OK, that aside... it's a neat little scripting system. 09:47:55 mm. 09:47:56 And, it's easy to do stuff in. It's overarching use of tables for everything simplifies life quite a bit. 09:48:06 sure, there are several interesting lang.. 09:48:11 okay., 09:48:16 Anyway, I want something similarly accessible. Easy like BASIC, fun like Forthy, and accessible like Lua. 09:48:39 does it have error checking 09:48:42 at runtime 09:48:45 ie. being able to redefine or delete existing words interactively (without FORGETting a whole dictionary). 09:48:46 madwork: well, someday, (when I can see yer package), maybe we can yak it over ;-) 09:48:59 rabbitwhite, the VM does, yes. 09:49:04 okay 09:49:13 You can implement whatever extra you want with your language. 09:49:20 ie. it won't crash on you. :) 09:49:36 It will just throw a forthy exception and bail with an error. 09:49:48 I'll be adding more to the exception handling as well. 09:50:09 Right now you can't catch them... all errors are VM-level exceptions. 09:53:39 i was able to install a trampoline in my system with an access violation interrupt. resets the system, use it all the time :) 09:53:43 But anyway, Lua does some cool prototyped OO-type stuff with tables, without needing an OO-specific language to support it. 09:53:51 Ahh, heh. 09:54:19 well, if it was that great, you'dalready have an enginefor Forthy ;-) 09:54:21 Yea, I was thinking of going that route as well. But, Forthy is designed to not let you tramp on memory directly. 09:54:46 PoppaVic, I might incorporate Lua into my interactive thing as well, so that you have a choice of languages. ;) 09:55:33 madwork: I can understand "tools" and filters/etc, So.. this is no huge issue with me. 09:55:40 ..remember, I use C as my "assembler" 09:58:03 Forthy is written in C. 09:58:17 OH TEH NOES!!1! FROTH IN TEH C!!1!1 09:58:18 ;) 09:58:24 i don't care 09:58:45 hmm? 09:59:36 I just get tired of umpty-variant CPU, then OS, then "assembler"s and it goes on and on and on 09:59:36 rabbitwhite, I figured you don't. 09:59:42 PoppaVic, yep. 09:59:54 i'm actually taking a c++ class this semester.. 09:59:59 never dreamed i would be 10:00:08 Heh. 10:00:08 my advisor actually told me she would help me sidestep it 10:00:12 Ugh, not a fan of C++. 10:00:45 the funny part is, she told me on the first day of class (she also happened to be the instructor) that i could just do my gamecube stuff for that class, no need to do all the normal assignments 10:01:09 so i get to hear about how insane c++ is and be entertained, and get more time to do what i care about 10:01:16 madwork: I'm also unfond of inline-code and inline-asm.. Drives me nuts. 10:01:44 rabbitwhite, sounds like a good deal. :) 10:01:58 and, while I already know there is no decent ABI interface, you can fake a LOT in c - and folks can port it. 10:02:11 brb, must release a product. ;) 10:02:17 i know - but i still feel an obligation to at least know the OOP keywords 10:02:28 ?? 10:03:13 rabbitwhite, I'm at work. I have to release some builds. 10:03:18 ohhhhhh. 10:06:32 brb - get food 10:28:48 back 10:29:16 I'm eating chowmain, what did you get? 10:29:50 a breakfast burrito 10:30:06 cool. 10:30:59 forth oop? 10:31:16 no thanks 10:31:47 why are you asking then for OOP keywords? 10:32:00 i wasn't. 10:32:09 i was talking about a C++ class i'm taking. 10:34:31 ah ok.. 10:35:00 * TreyB has written lots of C++ code. 10:35:38 no! kill him! 10:35:44 get him! 10:35:50 Eeek. 10:35:53 so you get an injection of good old C++ 10:36:11 heh.. /me has also writen C++ code.. 10:36:57 how much of C++ would you say is useful, virl? 10:36:58 C++ doesn't really get interesting until you reach the parts of the language that cause you problems. 10:37:27 then perhaps there are parts that one should stay away from 10:38:10 rabbitwhite, well.. use the C part of c++ and sometimes in some situations where the oop stuff is useful.. then use the ++ stuff.. 10:38:33 TreyB, that's the reason I don't use the problematic parts.. 10:38:39 +why 10:39:16 We probably have different definitions of "problematic parts". 10:39:51 I've worked on two OSes with C++ foundations: BeOS and PalmOS 6. The run-time intiialization can get funky. 10:40:07 back 10:40:18 But application writers don't usually have to deal with those sorts of things. 10:40:26 * madwork does his OO in C. 10:40:39 well I call the oop stuff of C++ problematic... 10:40:46 Indeed. 10:42:48 My day-job has involved C++ for the last 10+ years. You get used to it eventually. 10:43:18 folks also need to differentiate OO and OOP 10:43:42 Not a fan of OOP. OBP is fine though. 10:43:53 OOP rhymes with POOP, for a reason! 10:44:04 "OBP"? 10:44:06 OOP is almost a joke on itself. 10:44:19 i always think it sounds like "oops" 10:44:38 Yeah: OBP? 10:44:51 madwork: object-based? 10:44:55 Yep. 10:44:56 well, when they talk all about "exceptions" and "handling", "oopshit!" sounds apropos. 10:45:18 Object-Based is a lot more lax in its definition than OOP. 10:45:28 ohh... OO 10:45:33 Don't have to encapsulate, can encompass things like prototyped OO, etc. 10:45:47 OOP is just so anal, heh. 10:46:14 rabbitwhite, that's why I like forth. it's not this 'oops' feeling 10:46:15 I don't know how many times I've seen someone shout "Uh, but that's not proper OOP!" 10:46:15 well, you can use external-funcs, or vtables, or dispatchers - but OO just doesn't _force_ you into the whackiness 10:46:18 PoppaVic: C gives you enough rope to hang yourself. C++ ties the noose, puts it around your neck, and then puts you up on a creaky chair. 10:46:31 TreyB: I agree 10:46:40 Yes, I can do all the OO I need just fine in C. 10:46:53 otoh, forths are similar to C _and_ can advance to C++ levels of rope-use ;-) 10:47:07 Still, if you have good balance, you can use C++ to your advantage. Just don't get over-leveraged :-) 10:47:55 Generally speaking, sharp tools work better, but you don't give them to youngsters. 10:48:03 I'd be a lot more happy with C++ is the fuckin' commies would generate .c to generate..... or they would at LEAST link both directions w/o all the whacky-voodoo 10:48:21 is the/if the 10:48:32 Ah, the great name-mangling issue. 10:48:53 ..and more - hidden args 10:49:04 careful treyb, some of us might think otherwise ;) 10:49:19 For that reason alone Bjarne needs to face the firing squad. He should have spec'd it as part of the language, IMNSHO. 10:49:25 I tend to believe in C (gcc, usually) generating something lower to eventually feed "an assembler" 10:49:52 it should have been a db/segment-of-file anyway: mapping 10:50:05 what is name-mangling? are you talking about DLL's? 10:50:08 PoppaVic: cfront used to do that, but the current spec got compilicated enough warrant a "real" frontend. 10:50:14 like @12xyz? 10:50:24 and, of course, I'd love a real C "shell" or "interpreter" 10:50:52 TreyB: I believe it, I never used cfront, but I swear I recall TC/C++ going back and forth nicely. 10:50:53 At least one exists, PoppaVic, but they charge money for it the last I heard. 10:51:29 well, I've seen CINT and such - it's a laughable and poor replacement for stuff like Forth or Perl. 10:52:27 rabbitwhite: something like myclass::myfunc(int x, char *y) gets mangled into a C-compatible identifier with many extra letters. 10:52:56 ..so, we come back to "we need a really decent *nix forthish 'engine'" - in C ;-) 10:53:10 oh, nevermind. 10:53:18 PoppaVic: you don't like ficl? 10:53:19 all in order, btw - with case/context meanings 10:53:41 TreyB: it seemed a trifle busted, even after tathi wrote some code for me. 10:53:51 when I could finish xell, eh pix. 10:54:31 Seems like FICL was never, EVER intended to be an "interpreter" - too much is buried too deep and w/o backtracking. Plus, they really abuse unions. 10:55:14 Unions exist for the sole purpose of abuse. 10:55:16 and switch threading.. brr... 10:55:21 TreyB: I've issues all around the clock, and I always peer around for ideas that offer solutions. 10:55:57 TreyB: no, they are conveniences. - I'd never (nowadays) allocate the union to the heap over and over. 10:56:27 virl: switch threading gives you speed and portability at a reasonable trade-off. Other methods require carnal knowledge of the target. 10:56:29 Plus, what you _really_ want is a "tagged-node" or "object" ;-) 10:57:05 "switch threading"?? 10:57:24 Using a switch statement to dispatch primatives. 10:57:30 ewwwwwwwwwwwww 10:57:45 I was afraid I knew what you meant ;-/ 10:58:12 Again, it comes down to a portability/performance trade-off. 10:58:27 I'm starting to think tathi's idea of a few vtables is viable, and I'm now planning to explore libevent. 10:58:36 whats the performance cost 10:59:21 well, I coded it in ansi C 10:59:50 Anton Etrl has a web-site full of details, rabbitwhite. 11:01:29 virl: well, ansi-C is nice _basic_ - after that, you need a pile of assorted POSIX, if not C99 11:02:25 I don't need anything else than POSIX and ANSI C 11:02:34 good deal 11:03:37 virl: frankly, I've issues with "posix" anyway, so - you can't do much better, really. W/o tying to a compiler or assembler and linkers/loaders 11:05:26 TreyB: unless I am really lost, an awful lot of any interpreter/shell (and forth qualifies) is heavily "event-oriented". Assemblers and compilers would be a touch less so. 11:06:41 ..and, near as I can tell anymore - in this new age of "meaning" - our "events" sound a lot like statewise/callbacks-with-data 11:06:50 "contextual" is implied 11:08:31 in fact, even "exceptions" sound like "events" with a context. 11:09:32 To me, "event oriented" means that the code waits for the environemnt to tell it something interesting happened. After that, details vary. 11:09:40 --- quit: rabbitwhite () 11:10:01 TreyB: near as I can tell, signals are just too limited and absolute, but "events" are more generic and allow for context, users and extension. 11:10:18 TreyB: yeah, I was thinking much the same. 11:10:39 Yeah, the guy that thought up signals can join Bjarne on the firing line. 11:10:48 sub "environment" with "process" 11:11:34 TreyB: well, I can understand their BAREBONES use, but the fact we NEED something like libevent/liboop or glib, just _bugs me_. 11:12:06