00:00:00 --- log: started forth/03.07.06 00:24:59 --- quit: a7r_ (Read error: 110 (Connection timed out)) 00:25:38 --- quit: a7r (Read error: 110 (Connection timed out)) 00:37:20 --- quit: ianni (leguin.freenode.net irc.freenode.net) 00:44:42 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 01:01:00 --- join: Fractal (bron@i.either.got.mad.cow.from.alberta.beef.or.strongLSD.com) joined #forth 01:55:53 --- nick: w1k1|afk -> w1k1 01:56:53 does anybody know what happened to www.thelma-louise.net ?? 02:39:26 --- join: ianni (ian@inpuj.net) joined #forth 03:23:02 --- quit: w1k1 ("maintenance") 03:29:38 --- join: mur (murr@baana-62-165-190-158.phnet.fi) joined #forth 06:09:15 --- quit: ChanServ (leguin.freenode.net irc.freenode.net) 06:11:06 --- quit: Herkamire (leguin.freenode.net irc.freenode.net) 06:11:06 --- quit: paxl (leguin.freenode.net irc.freenode.net) 06:11:06 --- quit: Fractal (leguin.freenode.net irc.freenode.net) 06:11:06 --- quit: mur (leguin.freenode.net irc.freenode.net) 06:11:06 --- quit: ianni (leguin.freenode.net irc.freenode.net) 06:11:06 --- quit: Klaw (leguin.freenode.net irc.freenode.net) 06:11:06 --- quit: skylan (leguin.freenode.net irc.freenode.net) 06:11:06 --- join: ChanServ (ChanServ@services.) joined #forth 06:11:06 --- join: mur (murr@baana-62-165-190-158.phnet.fi) joined #forth 06:11:06 --- join: ianni (ian@inpuj.net) joined #forth 06:11:06 --- join: Fractal (bron@i.either.got.mad.cow.from.alberta.beef.or.strongLSD.com) joined #forth 06:11:06 --- join: Herkamire (~jason@h0030657bb518.ne.client2.attbi.com) joined #forth 06:11:06 --- join: Klaw (chuck@ip68-99-187-95.oc.oc.cox.net) joined #forth 06:11:06 --- join: paxl (paxl@modemcable110.168-130-66.que.mc.videotron.ca) joined #forth 06:11:06 --- join: skylan (sjh@nwc57-182.nwconx.net) joined #forth 06:11:06 --- mode: leguin.freenode.net set +o ChanServ 06:24:00 --- join: Robert (~snofs@h126n2fls31o965.telia.com) joined #forth 09:29:32 --- join: gNoam (xru52729fj@1Cust139.tnt4.vancouver.bc.da.uu.net) joined #forth 09:31:53 --- part: gNoam left #forth 09:57:03 --- join: w1k1 (~w1k1@pD954511C.dip.t-dialin.net) joined #forth 10:01:57 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth 10:01:57 --- mode: ChanServ set +o kc5tja 11:01:09 --- join: crc (~crc@AC82F99E.ipt.aol.com) joined #forth 11:28:16 wb crc 11:28:59 hello 11:30:49 have you by chance looked at http://retro.tunes.org/wiki/index.php?title=Visualization recently? 11:31:14 How recently? 11:31:27 The last time I looked at it was about two weeks ago 11:31:51 about introspector 11:33:00 which i posted there, because you left #forth b4 i could mention it 11:34:36 not so special anyway, but probably worth to mention 11:35:05 I've been looking at it a little. Time has been tight lately. 11:53:37 --- join: a7r_ (~a7r@206.72.82.135) joined #forth 12:41:22 yoh 13:05:31 I need food, but I don't know what I want to eat. 13:08:22 bbiab 13:22:17 what package runs the #forth site? 13:22:21 i like it 13:26:38 The #forth runs on Zope (IIRC) 13:27:10 zope + plone 13:32:50 --- quit: crc ("I was using TinyIRC! Visit http://www.tinyirc.net/ for more information.") 13:35:17 --- join: a7r (~a7r@206.72.82.135) joined #forth 13:39:37 --- quit: a7r_ (Read error: 113 (No route to host)) 13:52:23 --- join: skylan_ (sjh@vickesh01-4866.tbaytel.net) joined #forth 14:18:18 --- quit: skylan (Connection timed out) 14:18:35 --- nick: skylan_ -> skylan 14:34:24 Back 14:34:32 sup kc5tja 14:35:03 Just got the '7 washed after its repeated road-trips to Buena Park during the Aikido seminar. It actually looks like a '7 again, and not some dust ball on wheels. 14:35:17 Dropped the unemployment work-search form in the mail. 14:35:31 And I have to figure out how to refactor one last page on my company's website before it goes live. 14:35:45 I also need to procure a web site account, but I should have that sometime tomorrow. 14:36:19 And I should probably start working on FS/Forth for Linux later tonight. 14:36:30 I expect that will be fun, being a grass-roots rewrite and all. 14:36:31 :) 14:36:56 I do need to re-write my block editor though. >:( I lost the sources to VIBE somehow, and it's no longer on any of my existing systems. I literally have NO idea where it is. 14:38:00 burn. 14:54:59 Well, it is pretty easy to reconstruct; I can do it in a few minutes actually. 15:20:37 --- quit: skylan (Read error: 113 (No route to host)) 15:25:09 --- quit: a7r (Read error: 60 (Operation timed out)) 15:29:51 --- join: skylan (sjh@vickesh01-4967.tbaytel.net) joined #forth 15:59:29 w00t! The VIBE user interface code is in place! Now to start populating it with basic commands! 15:59:40 Hi kc5tja 16:03:16 re Robert 16:05:14 http://www.bbspot.com/News/2003/06/virus_sponsors.html :) 16:10:30 I don't think this is very funny -- I distinctly remember that option being seriously considered by companies in the past. 16:16:18 dotfuscator 16:27:08 --- quit: mur ("MURR! save the http://rainforest.care2.com/ (click url there)") 17:23:01 VIBE is coming together pretty quickly. Still not where I'd like it to be, but it's taking less time than I thought. 17:23:17 I have it inserting characters, deleting and backspacing, cursor movement, etc. 17:23:51 I need to add support for inserting carriage returns, which of course doesn't actually add the $0D character, but splits the current line, and pads the two new lines with spaces. 17:24:13 I also need to find some method of adding cut-n-paste capability too; I've had times when I needed that. 17:46:46 --- join: TheBlueWizard (TheBlueWiz@207.111.96.103) joined #forth 17:46:46 --- mode: ChanServ set +o TheBlueWizard 17:46:55 hiya all 17:47:21 re TheBlueWizard 17:47:44 * kc5tja is working on VIBE -- the VI-like Block Editor -- for FS/Forth development. 17:48:45 um...IIRC you already cooked up a vi/emacs hybrid editor yourself a while ago 17:49:31 and it seems you decide to use block based storage scheme rather than file based storage scheme, right? 17:52:39 Yes and yes. 17:52:48 This is a new version of the same editor concept. 17:53:24 hm...ok. I personally don't like vi way of editing stuff 17:55:01 1) VIBE isn't restricted to doing things the VI-way. 17:55:36 2) It's the *ONLY* truely portable technique for controlling an editor. Everything else has environmental dependencies up the wazoo. 17:56:16 If you wanted to reconfigure VIBE to behave similar to Emacs, feel free. It's trivially easy to do. 17:56:23 only truly portable way? 17:56:36 what do you mean by that? 17:56:55 there are numerous ways to cook up a portable editor... 18:00:19 Function keys do not have a standard encoding. 18:00:24 Cursor keys do not have a standard encoding. 18:00:32 Page control keys do not have a standard encoding. 18:00:52 The only truely portable character encoding is ASCII. 18:01:37 So, I have restricted my input model to pure ASCII. 18:02:57 and ESC/TAB key too? I thought x86 PC keyboards are pretty much standardized 18:03:09 ESC and TAB are part of ASCII. 18:03:19 That's why VI uses them. :) 18:03:44 As far as x86 PC keyboards being standardized, what does that have to do with anything? 18:04:08 Operating systems do not pass raw hardware key encodings from the keyboard to the application. 18:04:24 um, you said you intend to have it run on the x86 platform 18:04:39 It cooks it first into a host-environment-specific character encoding, and then to ASCII. 18:04:44 Yes, I did. 18:04:56 I really don't see what is so confusing. 18:06:14 Also, 'it' refers to FS/Forth, not to VIBE in particular. 18:07:34 well, I do see a certain contradiction of sorts...it seems that you decided that since function keys, etc. has no standard code mapping, you would not use them, and presumably would not offer such decoding at OS level...perhaps ignore them altogether 18:09:50 No, I didn't say that at all. 18:10:08 I'm writing VIBE currently under GForth. 18:10:12 GForth runs under console Linux. 18:10:19 I'll be using it to write FS/Forth. 18:10:25 ok 18:10:28 FS/Forth will (initially) run under console *AND* X11 Linux. 18:10:43 Both console and X11 have widely varying character encodings before being cooked to pure ASCII. 18:10:59 But it doesn't stop there. I am also going to write FS/Forth to run on the raw hardware. 18:11:13 :) 18:11:26 I'm quite likely going to port FS/Forth to run on my Amiga 500 as well. 18:11:29 metalbanging rawx! ;) 18:12:04 Amy too??? gee...you must want to have fun :) 18:12:23 Hey, my parents bought the machine, and the machine is still in perfect working condition, so why not? 18:12:43 It has the benefit of not having any cooling fans in it, and is MUCH more friendly to bit-banging than the PC is. 18:12:52 It, unlike my PC, actually has hardware documentation available for it. 18:13:53 Oh, and then there's the FS/Forth that will doubtlessly be ported by my 65816-based computer that I'm still desiring to build. 18:14:02 And then my 16-bit and 24/32-bit future stack architecture CPUs. 18:14:06 * TheBlueWizard has a complete set of Amiga doc books (ROM Kernel series, etc.) 18:14:06 So . . . 18:14:16 1.3 or 2.04 or later? 18:14:19 :) 18:15:14 * kc5tja only has 1.3 18:15:20 Even though I have the 2.04 ROMs. 18:15:45 I have 1.1 or 1.2 (no 1.3), and 2.04 ....there is no published manuals for later versions of AmigaOS...AFAIK these are available only on developer's kit CDs, which one has to register for 18:16:04 * kc5tja nods 18:16:22 hmm...which version of OS does your A500 run? 18:17:56 2.04 18:19:38 ah...hmm...if you need certain tech info, I can supply you that from my manual...won't be easy, seeing it is so far away from your reach :) 18:20:45 I don't think it will be necessary. I have yet to really develop any serious software that even came close to taxing the abilities of 2.04. Most of my software still is built for 1.3. :) 18:22:02 * TheBlueWizard nods 18:22:24 Thanks anyway. :) 18:22:39 I'm sure there's plenty of docs available on the 'net for specific things I might be looking for anyway. 18:23:33 I have dabbled in the assembly stuff on my A1000 and A3000, a bit hardcore in very narrow areas, but nothing extreme. The keyboard decoding logic is certainly somewhat more involved than is the case for PC...at least at OS level anyway 18:24:00 * TheBlueWizard nods and points to AmiNet as the fount of all Amigan knowledge 18:24:27 that is tongue in cheek comment :) 18:25:22 But it's also largely true too. :) 18:25:53 Wow. VIBE *almost* handles the carriage return correctly. :) 18:26:53 sounds like you're 1/3 done now :) 18:27:03 please repeat last line -- I /cleared *right* after it appeared. 18:27:44 * kc5tja sighs -- I wish there was a simpler way to handle carriage return. >:( There is just *SO* much block copying around, and *TONS* of conditionals . . . there HAS to be a simpler way to handle this. 18:30:35 hmm...maybe it is a sign of wrong approach? then again, I only wrote one semi-serious editor cuz I really had to, way back in PDP-11/70 days :) It was a special kind of interactive editor designed to work with line terminal (the kind where papers are used instead of monitor) 18:32:34 * kc5tja is familiar with line terminals. 18:34:26 that editor I wrote saved me a lot of reediting (and a good amount of paper)...it was written in BASIC-PLUS. I believe I still have a hardcopy source code of it somewhere in my archive :))) 18:37:01 Heh 18:37:17 Well, I'd be using my original VIBE if my source code for it didn't disappear on me, both hard AND soft copy. :( :( :( 18:37:22 So I have to start from scratch. 18:37:40 I like this design MUCH better, actually -- while patently influenced by its predecessor, it's architecturally simpler. 18:37:59 Carriage return handling is the only sticky spot in it, because there is a *LOT* of memory moves that need to be performed for each carriage return. 18:38:38 And it's all due to the need to split the current line into two pieces when inserting. 18:38:41 sometimes it pays to just redo things... 18:39:26 I'd expect at most two memory moves for a carriage return 18:39:54 then again, I'd have to see things to see what's the problem.... 18:40:29 Move #1: Make room for the next line in the block -- moves lines n+2 to 14 to lines n+3 to 15. 18:40:52 Move #1: Make room for the next line in the block -- moves lines n+1 to 14 to lines n+2 to 15. 18:41:02 Move #2: Blank line n+1 (fill with blanks) 18:41:14 Move #3: Copy current text to end of line to line n+1. 18:41:23 Move #4: Blank rest of current line 18:41:49 Note that move 1 isn't applicable if the cursor is already on lines 14 or 15, because the memory move will trash memory in this case. 18:42:00 Note that move #2 isn't applicable if the cursor is already on line 15 for the same reason. 18:42:11 Move #3 isn't applicable if the cursor is on line 15. 18:42:18 Only move 4 is guaranteed for all cases. 18:43:25 sounds straightforward...I was thinking this way: 18:45:10 (assuming the block is linearized) move #1: move stuff after cursor to where line n+1 would begin (pushing forward by x characters, essentially) 18:46:14 move #2: calculate where the part of the next point in the pushed area should be pushed again, thus to line n+2 onward 18:47:01 step #3: blank out the appropriate part in line n+1 18:47:28 step 4: blank out the appropriate part of line n 18:47:46 Hmmm..... 18:48:03 I guess blanking == move in your interpretation 18:48:18 That's what I tried doing originally, but it didn't seem to work. I must have gotten my pointer arithmetic really screwed up. 18:48:20 of course the calculating logic would be tricky though 18:48:27 GForth kept complaining about illegal addresses and whatnot. 18:48:45 Well, with some additional thought, I'm sure it can be made pretty simple. 18:49:10 The nice side effect of my method is that I implemented the "open line" function pretty easily. :) 18:49:15 Here is the entire carriage return code: 18:49:30 : nextln eol 1+ ; 18:49:31 : #chrs scr @ BLOCK 1024 + nextln - 64 - ; 18:49:31 : copydown y @ 14 < IF nextln DUP 64 + #chrs MOVE THEN ; 18:49:31 : blankdown nextln 64 32 FILL UPDATE ; 18:49:31 : splitdown wh nextln 2DUP SWAP - MOVE ; 18:49:31 : blankrest wh nextln OVER - 32 FILL ; 18:49:32 : opendown copydown blankdown ; 18:49:34 I'm sure you'll hit upon a nice-and-sweet way to do it, especially after going outside and sniff some flowers and clear your mind.... 18:49:34 : splitline opendown splitdown blankrest ; 18:49:37 : retrn inserting? IF splitline THEN flushleft nextline ; 18:49:38 : return y @ 15 < IF retrn THEN ; 18:50:04 Well, this method works as I expect it to, and I managed to reduce the number of conditionals to just two. 18:50:38 wh is the memory address of the character referenced by the cursor. 18:50:43 is wh the current cursor position? 18:50:48 ah 18:50:48 eol is the memory address of the 63rd character in the current row. 18:52:43 in retrn, I suppose nextline should be nextln? 18:53:01 No. nextline is a command that advances the cursor to the next line. 18:53:11 ah...ok 18:53:28 : nextline 0 x ! 1 y +! bounds ; , where bounds is a word that ensure the cursor stays within the block boundary. :) 18:56:28 hmm...looks ok, if a bit different from what I'd expect 18:56:53 * kc5tja nods -- I'm a huge advocate of the "one-word-one-line" school of Forth. :) 18:57:12 I think it really does make understanding the program code substantially easier. 18:57:51 Of course, Chuck would have none of this at all. :) 18:57:59 He'd find a way to do everything I'm doing entirely off the Forth command-line. 18:58:15 I've seen a sample of his older-style Forth editor on a webpage somewhere, and it's *very* cool and very usable. 18:58:27 Though a line editor, it's very close to being a screen editor in its utility. 18:58:33 I agree with that one-word-one-line philosophy, but on a few occasions it is better to break that rule :) It is an art, really 18:58:52 kc5tja - soudns interesting 18:59:02 I don't think here would benefit from one-word-N-lines. 18:59:36 Although incomplete, the whole editor, as it currently stands, compiles to 4720 bytes of program code in GForth. 18:59:45 That's not bad considering GForth is a 32-bit environment. :D 18:59:55 Expect around 3500 or so bytes for 16-bit environment. 18:59:57 and if I break it, I would restrict that to two lines....perhaps the most extreme case would be the INTERPRETER word...even there, I'd like to factor that gunk out :) 19:00:13 TheBlueWizard: Oh, well, yeah, I agree. 19:00:22 I'm talking about the people who write 56-line long word definitions. 19:00:23 :) 19:03:14 ah...yeah...I hate those ones....obviously a C programming habit...a very bad one in Forth world 19:03:36 * kc5tja nods 19:03:46 ianni: Which one? Sorry, missed your comment. :) 19:05:32 OK, I can edit blocks now! w00t!! 19:05:50 The environment is still a bit primitive, but it works, and is now immediately usable. 19:06:49 cool re: your success 19:07:09 Thanks. :) 19:23:35 gotta go...bye 19:23:48 --- part: TheBlueWizard left #forth 19:23:49 ok 19:39:20 http://www.channel1.com/users/graham/MyToyotaPrius/Understanding/Contents.htm -- for anyone who wants to know how the Toyota Prius' transmission works -- it's damn elegant. It's right up there with the Wankel Rotary Engine as far as finesse and ingeniousness is concerned. 19:47:49 --- join: a7r_ (~a7r@206.72.82.135) joined #forth 19:58:24 re a7r_ 20:00:33 a7r_: Got the core VIBE done. 20:00:37 bye 20:00:38 err 20:00:39 oops 20:00:42 :) 20:00:57 Compiles to just a hair under 5KB of code under 32-bit GForth environment. 20:08:58 sup kc5tja 20:09:03 elite. 20:09:13 Hey, I got a website you might be interested in. 20:09:18 http://www.channel1.com/users/graham/MyToyotaPrius/Understanding/Contents.htm -- for anyone who wants to know how the Toyota Prius' transmission works -- it's damn elegant. It's right up there with the Wankel Rotary Engine as far as finesse and ingeniousness is concerned. 20:09:35 Now if only we can couple one of those things to a rotary . . . ;) 20:10:17 Yeah, VIBE is a pretty nice block editor. Still *way* over complicated by Chuck's standards, but hey, I'm going to be spending the overwhelming majority of my time in it, so I would like to have a few creature-comforts in it. 20:10:49 Plus I'm still hacking away on it. 20:10:57 I should put what I have up on the #Forth portal site though. 20:14:03 yeah 20:17:07 ZZZZZzzzzzzz......... 20:17:20 * kc5tja really has to wonder what is going through the mind of Bespin when I go to the site... :( 20:44:24 OK, the file's uploaded. 20:46:11 It should be pretty easy to port to other platforms. 20:46:29 Though the documentation may be it a bit sparse for people. I'm here to answer any questions fo course. :) 20:51:49 * a7r_ checks it out. 21:37:59 I got it sort-of working with pforth 21:38:15 Cool. 21:39:29 I had to implement blocks, and it looks like pforth's KEY sucks rocks. 21:40:45 they're using getchar 21:41:03 :( 21:41:08 Dude, that DOES suck!!! :( :( :( 21:41:20 So you have to keep hitting ENTER after every key press?? 21:41:24 yeah dude 21:41:31 burn. 21:42:57 * a7r_ changes pforth. 21:43:06 Wow. So much for ANS compliance. Although, I *do* believe that behavior is NOT ANS-conformant. 22:44:37 --- join: Serg_Penguin (Serg_Pengu@212.34.52.140) joined #forth 22:44:43 hi ! 22:44:58 does anyone know a good FORTH for ZX-Spectrum ? 23:02:08 --- quit: Serg_Penguin () 23:14:18 bbiab -- going to get some food at the store. 23:15:19 --- nick: kc5tja -> kc-food 23:35:06 --- join: Serg_Penguin (Serg_Pengu@212.34.52.140) joined #forth 23:35:37 re ! 23:36:04 i need a FORTH for ZX-Spectrum ;) 23:36:24 i got few, but they are for tape loading 23:36:54 one emulator snapshot, but all the way brain damaged 23:46:04 --- quit: Serg_Penguin () 23:49:20 kc5tja: thanks for the prius link. very cool. I've been reading it for a while 23:50:29 damn it 23:50:50 I'm not understanding something abouth flux. 23:51:04 sup Herkamire? 23:59:59 --- log: ended forth/03.07.06