00:00:00 --- log: started forth/04.07.29 00:18:58 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth 00:19:09 --- mode: ChanServ set +o kc5tja 00:23:29 --- quit: kc5tja (Client Quit) 03:23:01 --- join: scope (~junk@njd.paradise.net.nz) joined #forth 03:36:17 --- join: crc (crc@0-1pool24-48.nas32.philadelphia1.pa.us.da.qwest.net) joined #forth 05:04:51 --- quit: ChanServ (ACK! SIGSEGV!) 05:11:36 --- join: ChanServ (ChanServ@services.) joined #forth 05:11:36 --- mode: irc.freenode.net set +o ChanServ 05:13:41 I hate writing documentation 05:18:17 --- quit: crc ("Time for bed... Goodnight all!") 06:01:50 --- join: I440r_ (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth 06:04:14 --- quit: Tomasu (Read error: 110 (Connection timed out)) 08:21:53 --- join: wossname (wossname@HSE-MTL-ppp73658.qc.sympatico.ca) joined #forth 08:35:39 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 09:00:13 --- quit: warpzero (Read error: 110 (Connection timed out)) 09:44:24 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 09:47:36 --- quit: wossname ("%^_~") 10:29:13 --- join: warpzero (~warpzero@mi244.dn178.umontana.edu) joined #forth 10:30:26 --- quit: Topaz ("Leaving") 10:30:52 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 11:29:53 --- join: skittle (XINU@12-222-128-22.client.insightBB.com) joined #forth 12:41:19 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 13:08:02 --- quit: tathi ("leaving") 13:59:47 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 14:43:35 --- join: cduce (thin@66.114.33.57) joined #forth 14:43:56 what's cracking? 14:44:29 Forth. 14:44:40 what about it? 14:45:04 I see cracks in the Forth egg, soon we'll see what's inside. 14:45:13 Perhaps it's a baby Chuck. 14:45:25 oooh, a baby chucken 14:54:51 hehe 14:55:17 when i had you to myself i didn't want you around 14:56:07 I bet you say that to all the ladies 14:56:26 i'd be scared of a baby chucken 15:05:21 --- join: doublec (~doublec@coretech.co.nz) joined #forth 15:08:13 hi doublec 15:08:49 --- join: tgunr (~davec@A17-205-43-45.apple.com) joined #forth 15:13:00 hi slava 15:16:30 slava, how is the game going? 15:20:52 doublec, i'm working on cfactor right now 15:24:23 I'm writing Forthy words for interfacing with firmware functions. 15:24:28 --- nick: madwork_ -> madwork 15:29:27 madwork, which firmware? 15:30:00 cluck cluck cluck 15:30:02 or is it chuck chuck chuk? 15:30:20 if a wood chuck chucked wood how many wood chucks does he chuck? 15:33:17 --- join: Tomasu (~moose@S010600045a4c73cc.ed.shawcable.net) joined #forth 15:41:01 slava, this is our "Page Counter" terminal firmware. 15:44:55 It's actually a new test firmware we're developing for testing the various hardware elements. 15:45:53 With words like setClock. and GotAllQwertyKeys? We're using that syntax I described before. 15:57:15 --- quit: warpzero ("Tried to warn you about Chino and Daddy Gee, but I can't seem to get to you through the U.S. Mail.") 16:02:02 --- join: Dorky56 (~DorkyDofu@0-1pool9-61.nas3.thornton1.co.us.da.qwest.net) joined #forth 16:03:02 HELP!! gforth has a bug, pfe doesn't like me, and bigforth's error messages are unhelpful in the extreme. 16:06:18 The bug in gforth has to do with an interaction between wordlists and include files, near as I can tell. 16:07:19 pfe gets an error in oof.fs, when defining the method 'bind' - or sometimes ' But why an 'invalid memory address' error? 16:08:00 bigforth doesn't have enough memory. And when I try to tell it to grab more with switches at the command line, it just changes the wording of it's error message. 16:08:46 I don't really want to dink around with the innards of *ANY* forth interpreter, I just want to work on my project. 16:10:31 Which project? 16:10:52 I'm using IsForth for Linux, btw. 16:10:58 oop sux 16:11:00 :P 16:11:18 I think it can be useful in moderate doses. 16:11:51 The problems are that the world is full of fanatics who either hate it more than anything else OR want to force everyone to use it. 16:13:15 what, forth, linux, or isforth specifically? 16:13:47 Dorky56: What was that refering to? 16:13:54 I'm working on getting oof.fs to work with garbage collection and persistence 16:14:26 Hm, fun... 16:14:50 Forth isn't all that portable, you might have to fiddle around a little. 16:15:10 It's turned out to be rather straighforward, actually. 16:15:11 the concept of forth 16:15:15 is pretty portable 16:15:29 just not the code =\ 16:15:43 Except for the bugs, random memory errors, and unhelpful errors messages. 16:15:45 Yeah, reality has a nasty habit of interfering with our theories. 16:16:25 They all die in different places, with wildly different error messages - is this what you mean by non-portable code? 16:16:57 Dorky56, i'm working on a forth-like langauge with OOP and transparent persistence features 16:17:49 I'd expect non-portability to be primarily an issue of 'undefined word' messages an the like. This is not the case? 16:20:28 I can see as how something like PICforth is a little different, as it a cross-compiling forth for PIC microprocessors (which don't even have a stack) 16:21:12 Sure they do. 16:21:40 They have indirect addressing, what more can you need? 16:22:36 Point. It works (though my PIC project currently crashes) 16:23:24 You're writing it in Forth? 16:23:29 Actually, the main disadvantage of PICforth is that the hardware call stack is TOTALY inaccesable - and only three words deep. 16:23:39 The PIC project, yes. 16:23:59 Neat. I've only been using assembly language for those little creatures. 16:24:23 I am new here. Been using forth for at least a little while though. 16:25:12 Doing the PIC in forth has turned out to work fairly well. I'm glad I went with it, assembly is a bit to low-level for what I was trying to do, and C is just to high. 16:25:12 But I am writing a Forth optimizer (which will probably be done somewhere around 2010...) which I'm thinking about making able to produce code for x86 as well as AVR and maybe PIC. 16:26:19 With such small projects as I have been doing, I really think assembly language is the easiest way to go. 16:27:31 I wrote a temperature controller for a solar hot water system, with a 16x2 LCD display, 5 temperature sensors, and several modes. 16:27:49 Much easier in forth than assembly, and my current PIC project is even more complex. 16:28:11 Sounds like a good use for Forth. 16:28:20 How well does PICForth optimize? 16:30:33 Fairly well, really. It helps in some cases to know how it optimizes, but usually I can't write it by hand any tighter than it does. 16:30:44 Not always the case, of course, but usually. 16:30:50 Cool. 16:31:15 I don't even want to think about how a simple Forth compiler for PIC would behave. 16:31:15 I fixed a couple of bugs in the compiler that I haven't gotten around to sending back to the maintaner. 16:31:57 Mostly in calling words between different memory segments - what state the extended part of the IP register is left in (I forget what that register is called.) 16:32:09 Dorky56, you're doing OOP in a PIC? :) 16:33:19 *shrug* Yes, that's one of the nasty parts of the PIC. 16:34:37 NO! no oop in the pic! (talk about egregriously masochistic!) 16:35:28 I wonder if that is realistic, anyway. 16:35:49 With some simplifications and an optimizer... 16:37:59 Sounds like asking for trouble to me. To many levels of indirection. 16:38:20 Like I said, the main limitation of the PIC from my point of veiw is the 8 deep call stack limit. 16:38:41 That's pretty deep I think. 16:39:03 You can't factor out EVERY instruction, but for simple programs it should be enough. 16:40:29 --- quit: Tomasu (Read error: 60 (Operation timed out)) 16:41:37 With interrupts, it's only seven. With a menu system, 16-bit arithmatic (including division and multiplication) and all the other crap I have to fit in there - it's pretty tight. 16:42:04 I've redesigned a couple of things specifically because of that limitation.- 16:42:17 Even duplicated code, in one case. 16:42:35 If your application is large enough, I guess that can happen... 16:43:01 True. But I still hate it. 16:43:22 So does anyone know how to get around the memory limitations in bigforth? 16:43:30 or around the wordlists bug it gforth? 16:44:01 or perhaps have a clue why pfe would get an 'invalid memory' error when compiling the 0= word? 16:44:14 I've reached the end of my rope on those. 16:44:20 That sounds _really_ odd. 16:44:23 Maybe I'll try isforth.. 16:44:38 IsForth is made by I440r_, who isn't exactly a friend of standards... 16:45:24 Oh. Probably pretty difficult to get oof.fs and garbage collection to work, eh? 16:45:54 dorky - Anton's OO system and GC work fine on gforth. 16:46:12 Unless you want to rewrite it from scratch (more or less), right. :) 16:46:49 oo and GC work fine - but includes more than one level deep TOTALY screw over wordlist allocation, which screws up anton's OO. 16:47:22 Which leaves me swearing at my computer (again) 16:48:00 Talk to Anton about it, then, or take a look at the wordlist allocation yourself. 16:48:28 slava, even gforth's termcap bindings are weak. Oh, waitaminit. Gforth doesn't have termcap bindings. some ansi stuff though. 16:49:21 dorky - what goal do you have, through this? 16:49:53 Dorky56, isforth has nice terminfo-like words. 16:50:44 Well, stage one was to get oo and GC working. Next in persistence. After that, maps, vision, and eventually (a LONG time later) a roguelike. 16:51:04 seems like a funny way to go about it, but OK. 16:51:55 Dorky56, heh 16:51:56 whyso? If I'm going to make a forth roguelike, I have to start somewhere. 16:52:15 i think quite a few people here are working on games, or forths for games 16:52:27 dorky - curiously, do you understand how tetris.fs and sokoban.fs in the gforth distribution work? 16:53:16 yes. I've looked at them. What do you mean? Is there a principle embodied in them that you are refering to specifically? 16:53:45 dorky - it may amuse you to understand how they, and particularly sokoban.fs, operate. 16:53:46 I've actually written a quite playable 'snake eats the ?' game in forth. 16:54:25 Dorky56, i think he means sokoban has similar display methodologies as rogue 16:54:32 slava - no, I don't mean that. 16:54:47 Do you mean the map parsing words? 16:55:25 dorky - anyway, your plan sounds like an excuse to avoid working on your roguelike so that you can enjoy yourself with fiddling with OO and GC and persistence and maps and vision, where I'd start with the roguelike and work myself back through maps and vision and the others as needed =) 16:55:37 dorky - no, of course not. 16:56:15 dorky - what you're the author =) 16:56:26 er, "but you're". 16:56:26 Maybe... But persistance is an essential part of a roguelike, and if I'm going to use objects, it's easiest to build persistence into the base class. 16:57:09 ayrnieu, HUH? you've totaly and completely lost me. 16:57:19 and I'm the author of what, exactly? 16:57:26 dorky - what you write. 16:57:35 --- join: Tomasu (~moose@68.149.209.223) joined #forth 16:57:37 dorky - meaning that you can go about how you like. 16:58:11 AAHH, yes. Indeed I can and I'll be thanking you to remember that. 16:58:26 After all, if I used only what I understood, what whould I learn? 16:58:32 dorky - anyway, I mean the part of sokoban.fs that encodes and that executes the rules that define the game of sokoban -- and you'll notice a bug in them, probably, unless someone has fixed it since I last checked. 16:59:19 dorky - generally you learn things completely by accident. 17:00:04 The sokoban style of defining rules isn't nearly as extensible as a roguelike requires. 17:00:34 And what I'd really like to do is make it easy to modify and define new objects/classes/monsters/races/etc/etc/etc. 17:00:52 dorky - sokoban.fs, please, and I know that. 17:01:20 So something a bit more complex is needed (I think) in order to keep those mounds of code well organized. 17:01:35 writing a car driving AI is hard :) 17:01:35 --- quit: slava ("Leaving") 17:02:14 I'd probably start with something like sokoban, but with an extra dimension to the map and multiple actors. 17:02:25 ... but nevermind. 17:02:56 To each their own. I'm actually more interested in defining interaction between monsters/objects 17:03:05 with the map as mostly an after thought. 17:03:22 So objects seemed a logical place to start. 17:03:53 Though I do have a few strange ideas about how to connect maps together, and how the vision code should work as well. 17:04:06 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 17:04:07 hi 17:04:12 I'll readily admit that I'm full of strange ideas. 17:04:44 slava, I agree that writing a car driving AI is hard. But I think that the really hard part about it is the liability issues. 17:04:58 Which are kinda o.t. 17:05:05 Dorky56, liability issues? 17:05:13 Dorky56, i was referrign to the AI in a game i'm working on 17:05:19 Who pays when the car hit someone. 17:05:29 Obviously doesn't apply to a game. 17:05:39 But isn't the player driving in most driving games? 17:05:55 the player drives their own car 17:06:10 but there is a random computer controlled traffic and pedestrians 17:06:41 Ah. Sounds like fun. How many points is the little old lady with the walker worth? 17:07:47 the AI cars still collide with each other too often. 17:08:09 if i tighten up the collision rules, deadlocks tend to occur, where a set of cars all stop and each one is waiting for another one to leave 17:08:10 oops. Aren't they obeying the traffic signals? 17:08:31 there's no traffic signals really, just ways to check for potential future collisions and decide on a driving direction 17:08:57 Maybe you could adjust that so that if they all stop, they wait a random amount of time, back up, and drive of the other direction. 17:09:04 slava - use the ethernet model of deadlock-handling, then, where each car waits a random time and then tries to move again, continuing to watch for movement from other cars. 17:09:37 slava - oh. traffic signals would probably simplify your life =) 17:09:57 That's not the ideal solution - but it may be the only one, depending on the density of the cars. 17:10:32 Even in real life we get gridlock sometimes - but we have traffic rules to determine who gets to resolve it and how. 17:10:51 and you've personalities of drivers, generally weighted to the aggressive, with the occasional Dave Barry with roof-mounted mini-nukes. 17:11:33 Leaving permanent obsticles in the road? or does somebody come by to remove the wreckage? 17:11:44 mini-nukes do not leave a road. 17:12:11 Ah. Simple solution to the deadlock problem then, no? 17:12:28 Dorky56, all objects like wrecks etc expire after a certain period of time in my game, so there's no permanent obstacles unless the map designer puts a building in the wrong place etc 17:12:57 Or simply have the most agressive guy pull out a handgun, and start taking pot shots at the others, who panic and throw it into reverse. 17:13:31 How big are your maps? 17:13:55 dorky - I've never know paniced drivers to go into reverse, but OK. 17:14:00 also, panicked. 17:14:01 any size is possible, at the moment they are 200x200 tiles (each tile is 32x32 pixels) 17:14:49 Oh, and thanks for putting up with me everybody! I didn't exactly come here to waste a little time, but at least I'm less frustrated than wasting time tracking down errors in gforth/bigforth/pfe. 17:14:54 How big is a car? 17:19:27 Dorky56, 24x8 or something 17:20:54 that's a huge map then. 266 car lengths across. Enough for several city blocks, I'd imagine. 17:21:27 well its not to scale really 17:21:30 the largest buildings are 3x3 tiles 17:21:43 its the largest sprite size supported by the engine 17:22:19 What engine is it? and what language are you writing this in? 17:23:44 the code is all mine, its written in java 17:25:17 I've yet to get around to learning java. Actually, o-caml or some variant of a non-side effects language is next on my list. 17:25:53 ocaml has side effects 17:26:26 i don't believe in side-effects-less languages. now a programming style that minimizes side effects can bring advantages, but if your language has no support for them at all, its hard to write dynamic code. 17:27:31 What's the name of that class of languages, anyway? I've forgoten. 17:27:37 functinal 17:28:02 Ya, that's right. 17:30:13 i like lisp and scheme the most from that category 17:30:34 i haven't coded anything substantial in either but they've been a big inspiration 17:30:39 'code as data' etc. 17:30:52 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 17:30:57 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth 17:31:45 except that CL and like people would balk at the 'functional', and I personally think it somewhat inappropriate to apply it to Scheme. 17:32:35 I would know more lisp, but when I first got into linux, I decided to go with vi, for reasons I'v forgotten now, but I'm comfortable where I am. 17:32:35 heh 17:32:49 what does vi have to do with lisp? 17:32:51 ... 17:33:34 Nothing! that's the point. Emacs, on the other hand, does. Since it was/is the other choice for programmers editor, my decision to go with vi has limited my exposer to lisp. 17:34:03 well emacs lisp is hardly a good representitive of the lisp family. its archaic 17:34:41 --- quit: tathi ("leaving") 17:34:57 There's another lisp interpreter? :) 17:35:37 --- quit: fridge ("rock out with your cock out") 17:40:26 --- join: LOOP-HOG (~jdamisch@sub22-119.member.dsl-only.net) joined #forth 17:40:30 hi 17:41:32 bye 17:41:33 --- quit: LOOP-HOG (Client Quit) 17:46:17 --- join: number42 (~ber@MTL-HSE-ppp192293.qc.sympatico.ca) joined #forth 17:46:23 ok i implemented traffic lights, of some sort :) 17:51:16 --- quit: Dorky56 ("Client Exiting") 17:58:24 --- join: LOOP-HOG (~jdamisch@sub22-119.member.dsl-only.net) joined #forth 17:58:26 hi again 18:09:22 no action 18:09:29 hi! 18:09:34 That's some action for you. 18:09:44 * number42 lobs a grenade at LOOP-HOG 18:09:47 damne! 18:09:54 a^ca 18:09:57 diable 18:10:01 fu^sita 18:10:13 kia sako de feko por kristnasko 18:11:06 I can't get my intel fax modem to instal anymore, and they don't support fax modems anymore in any way shape or form, so I can just throw it away 18:11:10 it was only like $20, but still 18:11:30 I was going to fax out some resumes, i hope the unemployment dept understands 18:12:29 i'm just going to get baked and listen to some folk music, nothing else works for me today. 18:13:11 pop e and listen to rave music instead 18:13:17 healthier for you 18:13:22 like bloody hell 18:13:25 --- join: warpzero (~warpzero@dsl.142.mt.onewest.net) joined #forth 18:13:31 LOOP-HOG, baking++ 18:13:37 e healthier than weed, lol 18:13:50 I used to goto raves, no more 18:14:24 wtf 18:14:25 E destroys your neural center for fine motor control. It's waaayy worse than weed. 18:14:27 since when did forthers do drugs 18:14:40 if e is pure its healthier, unless you vaporize weed but even then THC builds up in your frontal lobes and if you smoke a ton of weed all the time, it puts pressure on your frontal lobes 18:14:41 warpzero: since the seventies ;) 18:14:52 cduce, bullshit 18:14:54 cduce: bullshit. Anyway. 18:15:07 all e does is increase serotonin levels 18:15:16 it doesn't come with tar and carcinogens that you inhale into your lungs 18:15:25 my friend Sara Tonin 18:15:28 smoking weed gives ya 1000 different carcinogens 18:15:34 cduce, so make brownies :) 18:15:43 word 18:17:03 ok enough drug talk 18:17:09 ok fine 18:17:10 we don't want robert becoming a drug addict 18:17:17 because he's really susceptible to peer pressure 18:17:21 i can't be a bad example, i guess 18:17:22 especially forth peer pressure 18:17:29 and forth beer pressure 18:17:35 ph33r the b33r 18:19:56 --- quit: Topaz (Remote closed the connection) 18:20:14 --- part: number42 left #forth 18:26:31 --- join: tucknip (pickroll@dialup-4.152.183.12.Dial1.Atlanta1.Level3.net) joined #forth 18:38:22 --- join: number42 (~ber@MTL-HSE-ppp192293.qc.sympatico.ca) joined #forth 18:38:34 Is there a way to dump the data and the code stack? 18:38:49 ("code stack", is that how the second stack is really called?) 18:38:57 call stack, return stack, whatever :) 18:39:03 .s prints the data stack. 18:39:03 Using gforth... 18:39:16 number - 'data stack' and 'return stack', generally. 18:39:36 number - the return stack does not usually have meaningfully-printable objects on it =) 18:40:10 I was curious at the implementation and it could be dumped. 18:40:17 *if it* 18:40:31 I don't know what you mean by 'dumped'. 18:41:07 .R 18:41:40 go through the source for your Forth and find out if you can impliment it yourself 18:42:01 loop - no, ANSI Forth defines .r as something else entirely. 18:42:05 then you have to pick back through address by address but maybe you really need to do that ? 18:42:16 oh yeah, that's right 18:43:21 I don't really care much about ANSI Forth as I care about GForth in particular. 18:43:56 if you care about gforth, then you care about ANSI Forth, because gforth cares about ANSI Forth =) 18:44:19 I just mean if there are extra functionalities in GForth that aren't in the standard I don't mind using them. 18:44:36 of course. 18:44:48 I'm a Schemer after all... ;) 18:45:40 Indeed. The world of Forth should seem familiar to you in this respect -- though perhaps more extremely so.. 18:52:57 --- quit: slava (Remote closed the connection) 19:12:00 --- join: [Forth] (~Forth@216-110-82-59.gen.twtelecom.net) joined #forth 19:15:07 --- quit: [Forth] (Client Quit) 19:25:00 --- quit: tgunr ("Quit") 19:26:39 --- join: SDO (~SDO@67-23-111-213.clspco.adelphia.net) joined #forth 19:27:39 --- part: tucknip left #forth 19:41:24 --- quit: SDO ("Vision[0.9.6-0203]: i've been blurred!") 19:50:01 --- quit: number42 ("Client Exiting") 19:51:29 --- join: number42 (~ber@MTL-HSE-ppp192293.qc.sympatico.ca) joined #forth 19:54:10 When you create a new 'word', where is that word stored? 19:54:28 number - in the dictionary. 19:54:36 That's some kind of hash table? 19:54:43 Not really. 19:55:07 How is it implemented then? 19:55:20 oddly =) 19:55:39 sigh, but if you really want to know, the general archetype of Forth dictionaries goes something like this: 19:55:50 no, not like that. 19:56:08 ? 19:57:48 You've a linked list of word headers, which may or may not directly include actual code, but which should refer to actual code, which do include the name of the word in a limited counted-string form, and include some other bits of information. When you create a new word, you create a word header in HERE and link it to the last-defined word, and also SMUDGE the name of the word you create now so that referrals to that name in your definition refer to any prev 19:58:42 The inner interpreter, which sometimes has a simple implementation as the CPU of your computer, doesn't care about the dictionary. 19:59:39 the outer interpreter walks backwards (from the last-defined word) through the dictionary until it finds a match and then either executes what it finds or compiles what it finds depending on STATE and the the IMMEDIATEcy or otherwise-ness of the word. 20:00:26 and then you've innumerable subtle variations -- in Color Forth, for instance, you've a more complex STATE =) -- even if ColorForth doesn't implement it that way. 20:01:08 and you've different threading mechanisms, which tend to have an influence on the exact nature of the dictionary. 'threading' here has nothing at all to do with multiprocessing. 20:01:41 Some online resources can probably explain this better with little pictures of an ideal word on the dictionary and such. 20:02:23 And you'll probably find a description of the various common threading mechanisms interesting =) 20:02:44 I got a crash course on threading mechanism from I440r :) 20:02:49 Very interesting indeed. 20:03:06 I440r probably shared his biases on that matter with you as well =) 20:03:07 You've got truncated a few messages ago on "SMUDGE the name of the word you create now so that referrals to that name in your definition refer to any prev..." 20:03:31 refer to any previous dictionary words. 20:04:10 --- quit: LOOP-HOG () 20:04:28 If you create a new word with the same name as another in the dictionary it will be shadowed? 20:04:34 Or destroyed? 20:04:42 ( Sanitized for your protection ) : + ( n m -- n+m ) depth 2 < if error" aiee, we tried to + but we had less than 2 stack elements!" then + ; 20:04:50 number - shadowed. 20:05:10 Because the def to the old definition might still be valid somewhere? 20:05:22 s/def/ref/ 20:05:32 I dasn't speak of the reasons. 20:05:42 The design has its usefulnesses, as in that last example. 20:11:15 What is color forth? 20:12:18 ColorForth refers to a Forth written by Chuck Moore, distinguished by its multiplicity of word contexts -- which Chuck's tools display as having different colors, hence the name. This has also led to silly jokes about colorblind people. 20:12:55 I use Color Forth to refer to that multiple-context design rather than Chuck's particular (and more peculiar than just the contexts) implementation, which I've never managed to use. 20:14:12 I've enjoyed the Flux part of Enth/Flux, a native Forth ('native' here means 'on the metal', without any external OS; 'native-code' refers to the 'compiling to machine code' aspect), though, which serves as a kind of ColorForth. 20:14:48 sorry, Color Forth. HerkForth, by Herkamire on this channel, also has a colourful system, but I've never used it either. 20:15:36 number - www.ultratechnology.com has numerous Forth-related documents, which includes discussions of Jeff Fox and Chuck Moore and other people. 20:15:47 by those people, not of them. 20:16:08 hello 20:16:50 Hey I was just on that site, after following a link from wikipedia 20:16:59 You like purple, right? ;) 20:20:23 ayrnieu: I'm not sure what you mean by multiple contexts 20:21:42 Herkamire - Color Forth does not get confused by hex : 123 123 ; 20:21:57 Herkamire - or rather, confused after the fact. Numbers have their own context -- by base, even =) 20:23:11 Herkamire - you can think of an implementation as simply extending STATE to cover these extra 'decimal number' and 'hex number' and 'comment' interpretations, with the outer interpreter switching STATE by color (or 'whitespace' which also indicates color to source-displaying systems). 20:24:16 Flux implements it this way, for instance, with a jump table and the magic whitespace as ASCII [0,7] 20:24:25 IIRC. 20:26:19 --- part: cduce left #forth 20:26:38 oh 20:27:17 never thought of that as contexts 20:27:50 I always thought of the color as metadata for the word 20:30:08 but, now that you mention it, I do remember some complexity about color changes 20:35:11 I didn't do that in herkforth. herkforth just stores a few bits in each source token to indicate color 20:35:21 nothing happens on color changes 20:35:38 herkforth has no state in the compiler at all 20:38:52 Spooky, I'll have to look at that sometime. 20:39:04 cool 20:41:22 What does THROW do? It propagates an exception up the stack till something catches it? 20:41:43 number - AFAIK, yes. 20:42:05 number - gforth has a number of exception-catching constructs. 20:42:09 It there a way to unwind the stack, as with C's setjmp/longjmp ? 20:42:25 It there a way to copy the return stack (or a part of it)? 20:55:50 --- quit: I440r (Excess Flood) 20:56:02 --- quit: I440r_ (Excess Flood) 21:08:14 --- quit: Herkamire ("bed") 21:15:23 --- join: I440r (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth 21:21:57 --- part: aum left #forth 21:25:30 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 21:25:40 --- part: ayrnieu left #forth 22:34:19 --- quit: doublec ("Leaving") 22:41:26 * Tomasu is away: Just casue 23:25:33 --- join: ayrnieu (~julian@205.241.56.30) joined #forth 23:37:04 --- join: ball (~ball@dialup-4.159.208.237.Dial1.Chicago1.Level3.net) joined #forth 23:38:58 in (say) gforth, do I get access to environment variables? 23:40:39 s" PATH" getenv type 23:40:55 ayrnieu: thanks :-) 23:55:30 --- quit: ayrnieu ("Lost terminal") 23:59:59 --- log: ended forth/04.07.29