00:00:00 --- log: started forth/07.11.16 00:00:34 I think I'll need to be able to stack a few sets of keybindings 00:01:02 in my example of typing a word into a code definition, I'd need these sets of bindings in order: 00:01:53 1) the system-wide stuff that always works, 2) the (customized for only word-name-legal chars) text editor keys, 3) some word-level navigation words, since I'm in a definition too 00:02:54 --- quit: Quartus () 00:03:07 the system-wide stuff is always the same, so doesn't need to be involved in the FSM 00:03:08 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 00:03:08 --- mode: ChanServ set +o Quartus 00:03:12 the system-wide stuff is always the same, so doesn't need to be involved in the FSM 00:04:28 There's no reason not to put it in the FSM. 00:06:23 --- join: ecraven (i=nex@eutyche.swe.uni-linz.ac.at) joined #forth 00:35:14 --- join: forther (n=forther@c-67-180-150-67.hsd1.ca.comcast.net) joined #forth 01:10:06 --- quit: forther (Read error: 110 (Connection timed out)) 01:12:53 --- quit: proteusguy ("Leaving") 01:42:16 --- quit: Al2O3 ("Eggplant & SenseTalk: Driving Success Through Automation") 02:46:39 --- quit: saon ("CGI:IRC") 03:41:42 --- join: DeFrag (n=DeFrag@ppp91-122-8-95.pppoe.avangard-dsl.ru) joined #forth 04:00:26 --- quit: Quartus (Read error: 110 (Connection timed out)) 04:00:45 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 04:00:45 --- mode: ChanServ set +o Quartus 04:22:11 --- join: KipIngram (n=KipIngra@c-98-199-207-98.hsd1.tx.comcast.net) joined #forth 04:47:54 --- quit: ecraven ("bbl") 05:51:28 --- join: timlarson_ (n=timlarso@65.116.199.19) joined #forth 06:17:56 --- nick: TreyB_ -> TreyB 06:42:29 --- join: madwork (n=foo@204.138.110.15) joined #forth 07:16:47 --- quit: KipIngram (Read error: 110 (Connection timed out)) 07:26:17 --- join: ygrek (i=user@gateway/tor/x-70dbb1033c26f1da) joined #forth 07:42:53 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 07:42:53 --- mode: ChanServ set +o tathi 07:54:13 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM000f9f776f96.cpe.net.cable.rogers.com) joined #forth 08:06:26 --- join: CyberKid (i=HydraIRC@c-68-63-244-236.hsd1.ky.comcast.net) joined #forth 08:24:07 --- quit: CyberSpace (Read error: 110 (Connection timed out)) 08:24:07 --- nick: CyberKid -> CyberSpace 08:24:44 --- join: forther (n=forther@c-67-180-150-67.hsd1.ca.comcast.net) joined #forth 08:26:48 --- join: timlarson__ (n=timlarso@65.116.199.19) joined #forth 08:44:28 --- quit: timlarson_ (Read error: 110 (Connection timed out)) 09:05:48 --- quit: Quartus (Read error: 110 (Connection timed out)) 09:06:07 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 09:06:07 --- mode: ChanServ set +o Quartus 09:07:44 --- join: arke_ (n=arke@p54A7C182.dip.t-dialin.net) joined #forth 09:23:40 --- join: Al2O3 (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth 09:25:05 --- quit: ygrek (Remote closed the connection) 09:25:28 --- quit: arke (Read error: 110 (Connection timed out)) 09:28:55 --- join: ygrek (i=user@gateway/tor/x-1ec84ef207dff5ab) joined #forth 09:45:32 --- join: timlarson___ (n=timlarso@65.116.199.19) joined #forth 10:03:20 --- quit: timlarson__ (Read error: 110 (Connection timed out)) 10:04:02 --- quit: tathi (Read error: 110 (Connection timed out)) 10:29:41 --- join: iano (n=iosgood@sub26-46.member.dsl-only.net) joined #forth 10:48:02 --- quit: timlarson___ (Read error: 104 (Connection reset by peer)) 10:48:33 --- join: timlarson___ (n=timlarso@65.116.199.19) joined #forth 10:55:01 --- join: ygrek_ (i=user@gateway/tor/x-47293ca270c31933) joined #forth 10:57:45 --- join: ecraven (i=nex@eutyche.swe.uni-linz.ac.at) joined #forth 11:12:05 --- quit: ygrek (Remote closed the connection) 11:12:07 --- join: KragenSitaker (n=kragen@panacea.canonical.org) joined #forth 11:17:04 --- quit: forther ("Leaving") 11:23:56 So does anyone have a Forth running as a real-time task under RTLinux? 13:05:29 I vaguely remember someone making a Forth that ran in kernel mode for a standard kernel 13:08:58 from c.l.f 2004: Rick Hohensee has made a Forth in the linux kernel. 13:09:31 --- quit: Al2O3 (Read error: 104 (Connection reset by peer)) 13:10:03 --- join: Al2O3 (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth 13:10:21 it was called H3sm 13:10:32 --- quit: Al2O3 (Success) 13:10:35 also search for cLIeNUX 13:13:14 look here: ftp://ftp.gwdg.de/pub/linux/install/clienux/interim/ for H3rL 13:13:27 Though it is five years old now. 13:15:20 --- join: kitsune (n=fox@166.129.173.180) joined #forth 13:26:03 --- quit: timlarson___ ("Leaving") 13:52:48 --- quit: Quartus__ ("used jmIrc") 13:53:03 --- join: Quartus__ (n=Quartus_@209.167.5.2) joined #forth 13:54:48 Hi. 13:56:30 --- join: saon (n=saon@207.138.42.211) joined #forth 14:12:03 --- quit: Quartus (Read error: 110 (Connection timed out)) 14:12:15 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 14:12:15 --- mode: ChanServ set +o Quartus 14:12:31 iano: yeah, i remember the rick hohensee thing 14:13:12 I also would be very interested in such a Forth. 14:13:25 the thing is, the linux kernel itself can't really meet real-time deadlines. that's why RTLinux exists --- by paravirtualizing Linux, you can run real-time tasks next to it 14:13:26 It would be marvelous for embedded Linux debugging. 14:13:37 oh, hey, i hadn't thought about that 14:13:40 and embedded hardware debugging 14:13:46 you're completely right 14:14:00 although for embedded hardware debugging you could probably get away with a gdb stub task or something 14:14:15 The OLPC folks have gone above and below that level: 14:14:17 but maybe forth on the embedded board would be nicer than scripting gdb :) 14:14:34 Open Firmware for hardware debugging without Linux 14:15:00 do you happen to know how to interrupt an infinite loop in OLPC Open Firmware? in June I wrote an Open Firmware program which had a bug 14:15:01 and a Forth that can run as root as a standard process for debugging with Linux 14:15:04 and as far as I know it's still running 14:15:13 :) 14:15:15 somewhere in Boston 14:15:24 Ask in #olpc 14:15:29 on old Suns it was L1-A or something 14:15:39 the OFW author Mitch Bradley is there now 14:16:06 if he doesn't know, no one does. :) 14:19:13 --- quit: DeFrag () 14:21:06 --- join: Al2O3 (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth 14:22:41 --- quit: ygrek_ (Remote closed the connection) 14:24:20 --- quit: Al2O3 (Client Quit) 14:25:27 yeah, stop-a should get you back out 14:25:38 or break on the serial terminal 14:25:47 (serial BREAK not ctrl-c) 14:32:37 lucca: you mean on the Sun, right? 14:32:57 right 14:48:20 yes, they did ;) 15:06:34 --- quit: ecraven ("gn") 15:09:20 --- join: crest__ (n=crest@p5489C64D.dip.t-dialin.net) joined #forth 15:12:27 --- quit: Quartus (Read error: 110 (Connection timed out)) 15:12:37 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 15:12:37 --- mode: ChanServ set +o Quartus 15:17:53 --- quit: crest_ (Read error: 110 (Connection timed out)) 15:19:19 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 15:19:19 --- mode: ChanServ set +o tathi 15:22:20 --- nick: arke_ -> arke 16:05:18 how goes it? 16:06:13 pretty good 16:06:28 tathi: where do i look for a colorforth i can nasm to life? 16:09:43 hmmm...qualdan.com/colorforth/ I think. 16:10:23 http://qualdan.com/colorforth/chuck05-jg5.tar.gz 16:10:26 thanks! 16:10:54 there might have been a couple of minor fixes, but I think that one should work, if any colorforth does on your box 16:11:42 heh 16:11:54 well, i assume i can get it to boot in qemu or something 16:12:44 KragenSitaker: this is a bit out of date, but may me some help: http://jasonwoof.org/colorforth_under_bochs 16:13:16 yes, quite likely 16:13:33 heh. I wouldn't be so quick to assume that. I don't recall hearing of anyone getting it to work under qemu. 16:13:37 bochs is amazingly slow, and you'll probably have to compile that old patched version yourself, but I was able to get it to work 16:13:41 (not that I pay much attention) 16:16:35 --- quit: gnomon (Read error: 110 (Connection timed out)) 16:17:15 the idea is that color16 or color32 occupy the first few sectors of a floppy disk? 16:17:21 yes 16:17:32 if you're running Linux you can use dd or something 16:17:41 yeah. even cp works. 16:17:49 oh, really? 16:17:57 heh. Well, that's colorforthers for you 16:18:02 always pushing the more difficult solution 16:19:50 heh 16:20:21 i think people used to use dd because on non-linux unixes, cp to a block device didn't usually do the right thing 16:20:36 looks like there's some remarks about getting it to boot from CD in the last few months: http://colorforth.cvs.sourceforge.net/colorforth/colorforth/jc2007/ 16:20:44 but of course i have no idea which version that is 16:21:28 hmm, jeff fox has said things like this over the years: 16:21:55 # and that he is going to compile a complete Forth system on top 16:21:55 # of the 1K before he starts an application. This is wrong. The 16:21:55 # complete Forth system is 1K, and the reason for that is 16:21:55 # maximize Chuck's productivity. What stops people from doing 16:22:29 but color32 and color16 are 72kiB each, not 1kiB 16:22:34 yeah. 16:22:52 the kernel is at least 8KiB, and he left 12KiB of space for it 16:23:00 --- quit: Quartus (Read error: 110 (Connection timed out)) 16:23:06 (IIRC) 16:23:15 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 16:23:15 --- mode: ChanServ set +o Quartus 16:23:19 most of it is colorforth source code to do various things 16:24:24 But yeah, it's not really all that small. 16:24:53 I keep saying that one of these days I'm going to write a little Standard Forth system with an editor that's no bigger than colorforth, but with more functionality :) 16:25:04 it's a normal size forth really 16:25:08 Haven't found the time or the motivation to actually do it though. 16:25:12 yup 16:25:40 well, a normal size minimalist forth 16:25:47 right 16:30:05 --- quit: kitsune (Read error: 110 (Connection timed out)) 16:35:20 apparently that version runs on qemu 16:35:34 but not on actual computers 16:35:37 oh, right. 16:35:58 that guy registered colorforth.sourceforge.net and has actually been doing some work on the thing. 16:36:34 I don't know why somebody doesn't just make a version that will run on almost anything. 16:36:34 did he start from your code, or an earlier jeff fox drop? 16:36:51 It can't be *that* hard to find code for a decent boot sector 16:37:02 earlier code, I think. 16:37:07 Pretty sure he's seen mine though. 16:37:10 you could probably use grub or something 16:37:19 There's not that much difference in the kernel. 16:37:40 i'm mostly interested to see the chuck moore programming style 16:38:03 oh god. you don't want to know 16:38:14 heh. I wasn't going to say it. 16:38:37 heh 16:38:50 i have cmForth so I have some idea :) 16:39:06 but I'm curious to see how his technique has evolved in the ensuing, uh, 18 years? 16:39:34 well, some of the Forth code probably isn't too bad, allowing for the restrictions imposed by colorforth 16:39:48 even if I wouldn't want to write code that was that hard to read, I still might learn some new ways of thinking about things 16:39:57 the asm core is pretty awful though 16:40:00 heh 16:40:14 that's what you get when you edit your program by hand-hacking a bunch of machine code 16:40:37 I'm particularly interested in Chuck's assertion that ROT implies you're using too many stack entries 16:41:48 well, chuck doesn't have to deal with reality 16:42:10 heh 16:42:25 also he says to just use variables when you get that much stuff to deal with 16:43:34 complex business rules, calls to win32 api, and other situations are hard to implement in chuck's style 16:43:41 right --- but not local variables. which implies that he's still managing to do a lot of stuff with a lot less hassle than I am 16:43:57 yeah, obviously you can't call select() without digging deeper than two elements into your stack 16:44:00 chuck writes programs for aesthetic beauty, not to solve practical problems 16:44:22 i'd like to see him try introducing colorforth in a j2ee shop :) 16:44:24 so too does sedgewick 16:44:39 but i learned a hell of a lot from reading "algorithms in c" 16:44:54 the only other C code I've seen that was that beautiful was in the Lions book 16:45:27 complex business rules a lot of times benefit from decision tables and things like that 16:45:38 yup 16:45:46 you can express hard problems with a DSL 16:45:56 that rids of you of accidental complexity but not essential complexity 16:46:03 and implementing the DSL is of course a project in itself 16:46:10 and you can probably traverse a decision table without too much stack wibbling 16:46:39 in general, avoid dogma such as "NEVER use locals" or "NEVER use rot" or "NEVER use that" 16:51:08 actually, I agree about ROT. I use it sparingly. 16:51:23 there's a difference between using something sparingly and condemning its use altogether 16:51:38 chuck thinks if you use ROT or if you use locals or if you use files then you're just a shit programmer 16:51:46 I get the impression that Chuck generally doesn't solve complex problems 16:51:52 he does 16:51:54 OKAD for instance 16:51:59 but he has full control over the entire scope of the problem 16:52:05 he doesn't have to interact with existing data, existing programs 16:52:10 or even existing operating systems 16:52:20 and he has all the time in the world to write (in his view) 100% perfect code 16:52:20 chuck works in the embedded space, don't forget. smaller problems 16:52:26 most other programmers don't operate like that 16:52:46 you have deadlines, you have existing software to talk to, you have to deal with messy stuff like XML, web services, Win32, etc 16:53:26 its the 100% perfection style that really determines his style 16:53:45 I get the impression he never stops tuning his code 16:53:57 yup 16:54:07 and he chooses problems where Forth is a good fit 16:54:18 and he's been writing forth implementations for the last 40 (?) years so he's tuned them pretty well 16:54:19 ...whereas the rest of us don't have that luxury 16:54:43 i think forth is a good fit for many problems, most of the barriers to its adoption are social not technical 16:54:54 remember, he has said he considers text manipulation problems "uninteresting" 16:54:55 the forth community does not value code reuse or having a solid base of tested, documented libraries ready to go 16:55:15 whereas that is an entire industry's livelihood! 16:55:37 and the domain of entire programming languages! 16:56:23 yeah, perl and python win big time in terms of sharing and community 16:56:59 yep 16:57:15 it's taken me a lon gtime to realise that (what slava said) 16:57:23 it's not that we can't agree on a good library 16:57:26 any individual library is easy to implement 16:57:27 it's that we don't really care to have one 16:57:34 do you want string concatenation and splitting? well that's a couple hours work at most 16:57:39 assuming your forth isn't buggy or broken to hell 16:57:50 --- join: arke_ (n=arke@p54A7E36D.dip.t-dialin.net) joined #forth 16:57:50 do you want sockets? 16:57:55 well that's easy too, if you read the docs for your OS 16:58:03 I personally far prefer to write my own library, than learn how to use an existing one 16:58:06 part of their win is working hard to establish a solid base for library development 16:58:08 want an http client once you have sockets? easy 16:58:15 but doing EVERYTHING yourself eventually adds up 16:58:15 --- quit: arke (Nick collision from services.) 16:58:18 --- nick: arke_ -> arke 16:58:28 --- mode: ChanServ set +o arke 16:58:30 JasonWoof: that's the other thing 16:58:34 its easy to write a library which solves 80% 16:58:36 which Forth with its bazillion incompatible dialects has never had 16:58:40 but then someone else needs to solve a disjoint 80% 16:58:47 and can't/won't use your library because it doesn't do what they want, or its inelegant for them 16:58:49 so they write a new one 16:59:00 writing truly universal libraries which don't devolve into a mess of sphaghetti APIs is very hard 16:59:50 sure 16:59:58 a problem with the forth community largely ignores 17:00:10 and so forth is mostly used to write smaller programs 17:00:23 and not used to deal with complex stuff like nasty file formats and protocols 17:01:14 there is currently a forth discussion on ##asm 17:01:48 iano: I try to use it sparingly but often I am not smart enough to 17:02:45 (rot) 17:13:38 So, has anyone ever used one of chuck moore's chips? 17:16:08 don't think so 17:16:39 They seem interesting, but I cannot find any info on them really. 17:17:53 If you're referring to intellasys, you have to register before their site shows any actual info... 17:18:15 Hmm. 17:18:51 oh, i think i found some info on the seaforth chip in some electronic design magazine's yearly PDF listing of microcontrollers 17:18:58 Do they sell any boxes that would be good for fooling around on? Maybe something that has some flash storage, ability for keyboard input, and some graphic output? 17:19:36 --- quit: iano (Nick collision from services.) 17:22:38 Hmm, I am wondering where they plan to go with these new designs. 17:22:45 I don't find forth optimal for multi-core stuff. 17:22:50 I don't even see how it can be done. 17:25:37 didn't we already have this discussion? 17:26:00 which one? 17:26:14 (and yeah, probably) 17:26:28 --- join: iano_ (n=iosgood@sub26-46.member.dsl-only.net) joined #forth 17:26:34 Deformative thinks that in any multi-threaded forth system, all threads share a single data stack, and when you point out that this is not the case he changes the subject, then an hour later starts talking about how forth is unsuitable for concurrency again 17:27:04 slava: I don't think I ever received an answer. 17:27:12 Sec, lemmi check my logs. 17:27:14 you received several, and you ignored them 17:27:15 threads cannot share a data stack 17:27:18 that's crazy-talk 17:27:26 I never said they would. 17:27:37 for some reason many people think forth cannot do concurrency because the data stack must be global 17:27:48 um. no 17:28:05 I wondered how to construct a new thread, I guess you can pass it a single word... 17:28:13 forth has one of the simplest cooperative taskers 17:28:21 But then I don't see how message passing would be implemented. 17:28:35 send-msg ( msg thread -- ) 17:28:42 12:30:21 Hmm, is parallel processing even possible in forth? 17:28:42 12:30:25 I do not see it. 17:28:45 november 7th, 2007 17:29:11 16:19:43 Because wouldn't they be working on the same stack? 17:29:12 How would the message be received? 17:29:12 etc.. 17:29:19 wait-for-msg ( -- msg ) ?? 17:29:25 just like in C or any other language? 17:29:28 let's see if I can find a reference for you... 17:29:34 * Deformative scratches head. 17:29:45 Alright I guess. 17:29:52 Forget I said anything. ._. 17:30:03 ugh you're that morse code guy? 17:30:25 forget *I* said anything 17:32:42 here is one overview of a common model: http://www.zetetics.com/bj/papers/8051task.pdf 17:33:04 i'm not sure which forths support native threads 17:35:29 hah. Forth usually is the operating system. It's tasks are as native as it gets. 17:35:36 usually? 17:36:04 Well, I don't know how Forth has adapted to multi-core architectures these days. 17:36:10 if at all 17:36:30 IntellaSys must have some multi-processing techniques 17:36:36 in my experience, forth is usually an interpreten language on my OS 17:36:50 (lately, linux, but previously mac os 8-9) 17:37:29 iano_: each of the seaforth chip-lets has it's own stacks built it 17:37:29 which forth did you use on classic mac os? 17:37:49 mops 17:37:52 oh ok 17:38:00 didn't do much with it 17:38:09 I got obsessed with forth later 17:41:59 first time i saw forth i was looking at the ans spec and i didn't understand why they have + d+ and f+ as separate words 17:42:22 i really only knew java at the time, which uses compile time overloading 17:43:30 :) 17:43:45 I think it's a shame that people learn java first 17:44:08 http://www.dataman.ro/?page_id=37 -- this used to be a java applet 17:44:12 now its .net for some reason 17:44:15 but it was the first "forth" i saw. 17:44:26 the java applet was pretty accurate, actually. it used a big integer array as the store for @ and !, etc. 17:44:35 not sure how far the .net version goes, perhaps its just a thin layer over c# 17:46:06 did it handle mal-aligned fetches or byte fetches? 17:46:27 i don't know, but you can do that with bit masking and shifting 17:46:33 so it would not have been hard to implement 17:46:53 even floats, java has functions to turn a float into its bitwise representation and vice versa 17:47:33 yeah, i realize it wouldn't be that hard 17:47:40 int-array is probably best 17:48:18 * JasonWoof thinks for a sec about porting fovium (stack based vm I'm writing a forth for) to javascript 17:48:32 that would be funny 17:48:42 I figured that at some point there might be a browser plugin for it 17:49:42 I am thinking about writing an image manipulation program with concepts from lisp and forth. 17:49:45 Not sure though. 17:50:13 JasonWoof: you could port it to java and run it as an applet :) 17:50:15 slava: I thought I was the morse code guy ;) 17:50:16 or even flash 17:50:33 i don't know, some guy can here a few days ago and every few lines he would type some morse code with . and_ 17:50:36 slava: applet would make more sense than javascript certainly 17:50:43 javascript is very slow 17:50:57 yep :) 17:51:03 slower than java 17:51:26 yeah, especially with graphics ;) 17:51:41 heh 17:51:43 heh, I don't think I would implement graphics if I did a javascript version 17:51:50 slava: I don't remember that Delta ever finished their Java forth 17:51:52 I don't have graphics yet in the C version 17:51:57 ncurses? 17:51:59 nor did Misty Beach 17:52:09 heh. that wasn't me 17:52:09 slava: Erm, [Wed Nov 14 2007] [21:37:56] Deformati: just out of curiosity, why do you keep typing 'R' in Morse code at the end of your sentences? 17:52:11 iano_: i don't know about finished, but i ran it at somepoint 17:52:18 [Wed Nov 14 2007] [21:38:44] You mean ._. ? 17:52:30 the C version is SDL, but the client (being emulated) only has text output atm 17:52:30 [Wed Nov 14 2007] [21:38:56] That is supposed to be a text expression smiley thing. 17:52:30 [Wed Nov 14 2007] [21:39:10] Kinda like "Uh" 17:52:52 Deformative: yeah, I remember you said that. It doesn't look remotely like a face though 17:52:59 it does in my font 17:53:02 May be with your font. 17:53:06 it's amazing how much strife there can be over smileys 17:53:27 Deformative: well, get a better font. two dots with a line between them isn't face-shaped 17:53:52 -_- 17:54:13 I recommend the 10x20 font from misc-fixed 17:54:14 I'm surprised there isn't a Unicode area for smileys yet. :) 17:54:23 humph 17:54:39 i like monaco :) 17:54:48 me too 17:55:26 Ë-Ë 17:56:04 we were talking about something relivant and interesting to me 17:56:18 how's fronds coming along 17:56:28 I'm actually working on it again :) 17:56:39 I wrote some nice code to handle branch tables and lookup tables 17:57:35 now that I've got that in place I can set up a more sophisticated keybinding system so I can make different editing modes in a sane and expandable way 17:57:51 basically I need to be able to edit a tree of typed data 17:57:59 cool 17:58:11 a word name is edited differently than an integer value, than a comment, than a definition, etc 17:58:57 iano_: there are some smileys in Unicode 17:58:59 I'm pretty psyched about my table stuff, because it handles all my word types seamlessly 17:59:23 immediates work as you'd expect (ie you don't have to know if a word is immediate or not to use it in your branch tables) 18:00:01 at some point I'll make a lot of the lower level words like 2+ inline themselves 18:00:10 : 2+ ,1+ ,1+ ; immediate 18:00:12 that sort of thing 18:03:05 what if you want to do ['] 2+ execute? 18:03:21 i've come to the conclusion that optimization should not be part of the parser 18:05:07 that'll compile the opcodes 18:05:18 that's the one bit that isn't clean 18:06:02 what's this comma business? 18:06:03 you can call 2+ at compile-time, and it'll make a runtime version, essentially doing: : runtime-2+ 2+ ; 18:06:10 my comma prefix is like postpone 18:06:13 lucca: naming convention for words which write to here 18:06:23 hrmmmm 18:06:25 JasonWoof: oh 18:06:32 so you don't actually have a : ,1+ ... ; macro? 18:06:40 also what slava said, that's why I neglected to mention the postpone bit 18:06:50 no, I built that in 18:07:18 just this: : 1+ op-1+ op, ; immediate 18:07:28 ºâ» 18:07:42 KragenSitaker: gesundheit 18:07:45 KragenSitaker: XºâX» yourself 18:08:10 JasonWoof: your client is incorrectly rendering UTF-8 bytes as inverse-video Xes :) 18:08:21 it's a ^X with the high bit set 18:08:28 but your client is ignoring the high bit 18:08:31 irssi? 18:08:34 slava: my dictionary has an extra field, for immediate words it's the compiled runtime version 18:08:41 ok 18:08:41 irssi can do utf-8 okay, if configured 18:08:47 yes, if configured 18:08:52 KragenSitaker: no, it displayed the X in reverse video... 18:08:53 and if a recent enough version 18:09:04 KragenSitaker: it's my copy-and-paste that ignored it 18:09:13 JasonWoof: yes, that's the standard way for irc clients to display control characters 18:09:20 I have no interest whatsoever in utf 18:09:38 --- quit: iano_ () 18:09:40 anyway, stop distracting me with your garbage characters 18:09:49 JasonWoof: heh, my application will need the forth to be fully utf-8 aware... normalizing and everything 18:10:01 good for you 18:10:24 I have no use for variable width characters except as a compression method 18:10:34 for which huffman encoding seems far far more appropriate 18:10:53 heh 18:11:29 the specification of UTF-8 is a bit simpler than the huffman table we'd have to all share 18:11:54 had some ideas about using token-threaded-code with tokens encoded utf-8 style, so that one could implement a peephole optimizer using regexes... 18:12:01 slava: the compiler uses the alternate CFA for immediates automatically when you call them at compile-time 18:12:13 slava: only trouble is there's no XT that refers to that alternate CFA 18:13:13 lucca: you know, if you're doing token-threading, you can have word 0xff be a "fetch next byte from instruction stream and look it up in an auxiliary table and then execute it" opcode 18:13:13 hmmm... well there are mechanisms for that 18:13:34 I don't really have a general "execute" word yet. I suppose when I write it, it'll have to handle that 18:13:45 guess that means my XT needs to include the color 18:14:39 hmmm 18:14:52 currently my "tic" mechanism just returns a reference to the dictionary entry 18:15:11 which isn't nessesarily even a word... 18:15:22 for constants and such the CFA is the value, not a code pointer 18:15:55 apon further inspection... if I write EXECUTE right, it'll handle immediates fine 18:15:55 KragenSitaker: yeah... I think I'm just going itc though, as this is mostly a c-forth (and no ;code) 18:16:10 well... maybe 18:16:12 damn 18:16:31 that makes compiling dependancies automagically tricky 18:17:13 when someone does "['] foo" (and foo is immediate) I don't know if they're going to execute it's compile-time version 18:17:36 and I can't automagically compile compile-time versions for everything, because some don't work that way 18:17:42 like control constructs 18:17:57 you could probably crash by trying to compile something like: : compile-time-then then ; 18:18:28 lucca: is itc Bill Muench's 1987 eForth-in-bForth? 18:19:07 hmmmm... perhaps definitions really need to go into dynamically allocated memory 18:19:32 It's occured to me that I might want that at some point 18:19:36 JasonWoof: you could have a separate version of ['] for getting an xt that you're going to compile into a definition than for getting an xt that you're going to execute at compile-time 18:19:43 like, spelled differently 18:20:29 it'd have to be built into my dependancy compiler 18:20:40 I don't like it 18:20:46 it imposes more complexity on the human 18:21:23 is this for a target/meta compiler? 18:21:40 because in that case the human can't avoid making that distinction 18:21:40 KragenSitaker: what do you mean by that? 18:22:06 it's possible I do need seperate syntax 18:22:20 JasonWoof: I mean, is the code you're compiling going to get executed in some context in which all or most of the compile-time environment is missing? 18:22:40 no 18:22:40 e.g. because the compile-time environment is on your mac, and it's going to get executed on an embedded AVR 18:22:43 nothing goes away 18:22:56 not even the source code 18:23:11 so the problem is only with the dependency checking then? 18:23:17 yes 18:23:30 I haven't really used XTs yet 18:23:42 my tic-like-thing returns a reference to the dictionary header 18:23:59 which I've mostly used to implement geeky forth-implementation level stuff like tables, defer, etc 18:24:20 right 18:26:47 ok, so when you do the "tic foo execute" think, you're expecting to get the same semantics from foo that you'd get if you typed it interactively (not in a definition) right? 18:27:03 trouble is, when the compiler sees "tic foo" it doesn't know if you're going to "execute" it or not 18:27:31 thus it cannot ensure that the compile-time version of foo is compiled 18:28:27 (I've been using the term "compile-time version" a lot here, probably in-correctly... I mean the non-immediate form useful for interactive use) 18:29:02 one solution is to have a form of tic which is used when you intend to EXECUTE it later 18:29:10 which would not be used on words like THEN 18:29:30 right 18:29:47 all this sounds awfully similar to the distinctions you have to make for a meta or target compiler 18:30:02 another is to make it so I have some seperate memory to compile the compile-time versions to. And have EXECUTE compile the needed definition when/if needed 18:31:21 this forth can compile itself 18:31:54 it generates a fresh image of itself without executing any of the code compiled into the new image 18:32:54 how do you handle that problem in the metacompiler? 18:33:03 what problem? 18:33:08 the '-for-execute vs. '-for-, problem 18:33:18 (sorry if i'm not contributing much --- i've only slept a couple of hours in the last 30) 18:33:45 I don't think I use EXECUTE or the like 18:34:18 that or I've not used immediates where this would be a problem 18:34:20