00:00:00 --- log: started forth/05.01.01 00:15:04 --- quit: Testament (Read error: 110 (Connection timed out)) 00:50:37 --- join: bbls (~bbls@80.97.121.133) joined #forth 00:51:42 hi 00:51:47 hi 00:51:58 * Robert waits for Sonarman to suggest a correction. 00:52:22 what kind of correction? a bugfix? 00:55:19 No, correcting my "hi" to "Hi." 00:55:37 ah :) 00:55:43 then i should correct it too :) 00:57:43 ;) 01:09:14 --- quit: Sonarman (Read error: 110 (Connection timed out)) 03:11:48 --- join: Topaz (~top@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 03:14:09 I 03:14:10 Hi 03:15:26 --- quit: bbls (Read error: 110 (Connection timed out)) 03:17:03 --- join: qFox (C00K13S@82-169-140-229-mx.xdsl.tiscali.nl) joined #forth 03:30:17 --- join: arke (f2@bespin.org) joined #forth 03:40:09 --- quit: arke ("Lost terminal") 03:56:57 --- join: Testament (CapStone@cs24160141-160.satx.rr.com) joined #forth 04:14:17 --- quit: p-Imperator (Read error: 110 (Connection timed out)) 04:17:08 --- join: aum (~aum@60.234.138.239) joined #forth 04:57:30 --- quit: Topaz ("Leaving") 05:10:31 --- join: Topaz (~top@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 05:16:14 --- join: tathi (~josh@pcp01375108pcs.milfrd01.pa.comcast.net) joined #forth 05:18:44 --- quit: Topaz ("Leaving") 05:33:43 --- join: Topaz (~top@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 05:53:39 --- quit: Topaz (Remote closed the connection) 06:09:01 --- quit: fmacs (Read error: 60 (Operation timed out)) 06:14:00 --- quit: tathi ("leaving") 06:21:25 --- join: Topaz (~top@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 06:59:16 hi all 06:59:41 Hi 06:59:48 How are you this year? 07:00:02 Not too bad 07:00:07 A little tired though 07:01:41 hey all 07:01:49 Hi saon 07:01:53 Hi saon 07:02:20 then not has changed much, crc :-) 07:02:24 dang... 07:02:25 :) 07:02:32 then not much has changed 07:02:43 I might have to work a couple of hours today... 07:02:56 rid of my second personality get I can't 07:03:01 heh 07:03:19 strong the farce is in me 07:03:22 :-) 07:03:34 heh 07:03:56 A yoda reference in #forth? How odd. ;) 07:04:24 I think that line harkens back to some MAD issue of some years ago 07:47:28 hmm google groups says that comp.lang.forth has no topics... 08:02:08 does that mean that we can't get OT? 08:02:22 OT? 08:02:28 On Topic. ;) 08:02:33 hmm 08:02:37 * crc doesn't know 08:03:58 it implies we need to take the zen approach to new heights.... not talk about forth by not talking about nothing else 08:04:14 * swsch_ gets lured to the dark side 08:04:34 the dark side of the forth? 08:04:51 s/forth/farce :-) 08:04:59 :) 08:05:20 motivate me, folks, I've got some work to do! 08:05:29 hmm 08:05:41 that's not enough 08:05:47 MORE 08:06:03 * crc prepares to upload another alpha of 8.0 08:07:22 Uploaded :) 08:07:23 yes that's more like it :-) 08:07:26 oooohhh 08:07:41 http://www.retroforth.org/rf8.tar.gz 08:09:55 (Try now; I reuploaded the old file a minute ago) 08:10:07 You can now load a named blockfile ;) 08:10:31 use examples/intro.nlk 08:10:33 load 08:10:44 (using bin/rfx) 08:11:52 -9 on TOS 08:12:20 hmm 08:12:31 use examples/intro.blk 08:12:44 bash did this already 08:12:48 * crc typed an n instead of a b 08:12:50 ? 08:12:58 tab completion 08:13:16 Hmm 08:13:23 I do: 08:13:25 ./bin/rfx 08:13:30 use examples/intro.blk 08:13:31 load 08:13:53 and see the introduction/tutorial block's contents 08:13:55 oh ... left my brain somewhere obviously :-) 08:14:06 heh, easy to do ;) 08:14:15 aha! 08:14:41 You can't create a new blockfile from within rf8 yet, but that'll come before the weekend is over 08:14:58 (as well as the ability to set the size of the block file) 08:15:12 what happens to the old one if I do this? 08:15:30 If you create a new one? 08:15:37 yes 08:15:54 am I working in the new one from now on? 08:15:56 Nothing, as long as you give a different name for the new block file 08:16:15 use examples/intro.blk 08:16:16 loadd 08:16:28 (that should be "load") 08:16:37 use mynewblockfile 08:16:38 save 08:16:49 will save the loaded blocks into mynewblockfile 08:17:07 (note that mynewblockfile isn't created automatically yet...) 08:17:55 * crc wonders about a good default number of blocks... 08:18:06 how about displaying the number of the current block to the right of one of 08:18:15 the separator lines 08:20:12 re number of blocks: start with 16, add a command to double the file size 08:20:38 I have 42 right now 08:20:43 (that's 21 blocks) 08:20:47 of course :-) 08:21:10 err, 21k file (512 bytes/block) 08:21:24 I don't remember why 42 blocks though... 08:21:49 maybe the adams effect .. 08:21:55 maybe 08:22:37 what happens to things being printed? e.g. 1 1 + . or words 08:26:57 They get scrolled offscreen currently 08:27:19 I'm planning to have things displayed in the TOB at some point 08:27:44 * crc just uploaded a new alpha @ retroforth.org/rf8.tar.gz 08:27:56 (Now it shows the current block #) 08:28:17 10 minutes! I'm very impressed :-) 08:28:24 hehe 08:28:46 * crc was also doing a test of "40 fib" and watching for the timings taken 08:30:07 much better this way 08:30:43 good 08:31:21 now I'd like some help in the vertical direction. :-) 08:31:27 bin/rf is a binary without the block editor (it will be able to load/eval/save code in a block file very soon) 08:31:34 vertical? 08:31:49 a block is 8 lines "high" 08:32:07 ok 08:32:44 how about a first column with either digits or a simple marker in line 5? 08:33:00 ? 08:33:13 you mean line numbers? 08:33:40 line digits or just a visual help to avoid having to count 08:34:24 "12345678" or " - - - -" or "- - " in the first column would be very nice 08:34:31 usability-wise 08:35:23 probably takes longer than 10 minutes to implement, though... 08:36:21 let's see what I can do :) 08:37:55 whats 8.0/drop for? 08:39:31 An old test I did 08:40:22 --- join: tathi (~josh@pcp01375108pcs.milfrd01.pa.comcast.net) joined #forth 08:40:44 I'm impressed by the results of diff source/rb* 08:42:31 Download it again 08:43:08 that'll be cleaned up quite a bit soon ;) 08:43:41 tar: 8.0/source: time stamp 2005-01-01 17:42:35 is 41 s in the future 08:43:43 :-) 08:44:01 vaporware obviously :-) 08:44:18 you da man! 08:46:37 i like it! 08:48:32 good 08:48:47 it needs a lot of cleaning up, but I'm getting happier with it 08:49:00 Now to reorganize the blocks a bit... 08:50:04 hehe ... 4 i gives a segfault 08:50:43 it gives a clear message: "Think before typing!" 08:50:44 great! 08:51:12 but it's looking really good. 08:52:14 * swsch_ is off to feed his children 09:05:07 --- join: bbls (~bbls@80.97.121.133) joined #forth 09:07:08 * crc will be leaving in a few minutes... 09:49:59 bbl 11:15:51 --- join: foxchip (~fox@adsl-68-123-46-3.dsl.pltn13.pacbell.net) joined #forth 11:34:46 Hi 11:54:31 --- quit: foxchip () 12:02:20 --- join: Sonarman (~snofs@adsl-67-113-234-213.dsl.snfc21.pacbell.net) joined #forth 12:30:04 --- join: Sonarman_ (~snofs@adsl-66-124-255-5.dsl.snfc21.pacbell.net) joined #forth 12:45:09 --- quit: Sonarman (Read error: 110 (Connection timed out)) 12:50:16 --- join: T0paz (~top@spc1-horn1-6-0-cust117.cosh.broadband.ntl.com) joined #forth 12:52:35 --- quit: SeaForth ("Leaving") 13:07:33 --- quit: Topaz (Read error: 110 (Connection timed out)) 13:19:16 --- join: SeaForth (~SeaForth@c-24-1-126-202.client.comcast.net) joined #forth 13:59:36 --- nick: saon -> saon|dead 14:19:30 --- join: paf (~paf@MTL-HSE-ppp189409.qc.sympatico.ca) joined #forth 14:34:35 --- join: TheBlueWizard (TheBlueWiz@modem-152.nyc-tc03b.FCC.NET) joined #forth 14:36:32 --- nick: saon|dead -> saon 15:21:20 --- join: Sonarman (~snofs@adsl-66-124-255-5.dsl.snfc21.pacbell.net) joined #forth 15:26:40 --- join: Sonarman1 (~snofs@adsl-63-196-0-38.dsl.snfc21.pacbell.net) joined #forth 15:28:15 --- join: segher (~segher@p0672.nas2-asd6.dial.wanadoo.nl) joined #forth 15:28:58 --- quit: Sonarman_ (Read error: 60 (Operation timed out)) 15:30:12 --- quit: Sonarman (Read error: 60 (Operation timed out)) 15:40:35 --- join: Sonarman (~snofs@adsl-64-160-166-223.dsl.snfc21.pacbell.net) joined #forth 15:51:15 --- quit: Sonarman1 (Read error: 104 (Connection reset by peer)) 16:17:20 --- quit: qFox ("this quit is sponsored by somebody!") 16:59:12 --- join: zardon (~zardon@S0106000d6151238b.gv.shawcable.net) joined #forth 16:59:19 --- quit: zardon (Client Quit) 17:05:54 --- quit: Sonarman (Read error: 60 (Operation timed out)) 17:07:34 --- join: Sonarman (~snofs@adsl-67-113-234-45.dsl.snfc21.pacbell.net) joined #forth 17:12:01 --- quit: T0paz (Remote closed the connection) 17:23:34 hi all 17:27:11 hi aum 17:27:50 new year's resolution #n: do better forth factoring 17:28:23 hehe 17:28:31 ? 17:28:38 ah :) 17:29:02 --- join: swsch (~stefan@swsch.sustaining.supporter.pdpc) joined #forth 17:30:15 okay, one-liner for today: : does r> latest-code-field ! ; : does> postpone does postpone r> ; immediate : create header does ; 17:30:38 it assumes some stuff, like, old-style threading, but it's cute :-) 17:32:06 what does it actually /do/ ? 17:32:47 that's definitely cute 17:33:14 aum: it's just an implementation of CREATE .... DOES> .... 17:33:31 tathi: :-) 17:33:49 ah, ok 17:36:54 * aum continues with his forth-on-a-card 17:42:17 * tathi doesn't see how it assumes a certain threading style though... 17:46:07 it requires the return stack to hold actual absolute return addresses, in single cells 17:47:22 won't work with all kinds of subroutine threading, won't work with most native-code generators, etc. 17:47:24 --- quit: swsch_ (Read error: 110 (Connection timed out)) 17:47:30 work with both ITC and DTC, though 17:49:34 --- quit: Sonarman (Read error: 110 (Connection timed out)) 17:52:37 do people here feel there might be a market for a credit-card-sized PCB with a serial port and n analog/digital connectors, that runs forth? 17:53:28 not a big market, for sure -- but a fun hobbyist thing 17:53:54 it's a combined 8-, 16- and 32-bit forth 17:54:17 8-bit cells, but full set of 8/16/32-bit operators 17:54:28 32-64k flash rom 17:56:36 well, there's at least some market for it... 17:56:49 8-bit cells? ouch! why not 16-bit? or is your stack wider than your cells? 17:57:00 http://www.mpeltd.demon.co.uk/ 17:57:02 for instance 17:57:12 i could have gone for 16-bit stack, but RAM is scarce 17:57:47 so default operators (eg, +, @ etc) are 8bit, but has 16-bit versions (16+, 16@ etc) 17:58:13 and syntax for 8/16/32bit literals 17:58:34 segher: why does ITC/DTC require single-cell return addresses? 17:58:38 eg 2$23 ( -- 23 00 ) 17:58:45 23 ( -- 23 ) 17:58:53 4$23 ( -- 23 00 00 00 ) 17:59:51 --- join: Sonarman (~snofs@adsl-64-160-164-8.dsl.snfc21.pacbell.net) joined #forth 18:06:54 gotta go...bye all 18:07:04 --- part: TheBlueWizard left #forth 18:24:12 tathi: it doesn't require it, but it's the "normal" way to do it 18:27:31 --- quit: SeaForth (Read error: 60 (Operation timed out)) 18:30:16 --- join: SeaForth (~SeaForth@c-24-1-126-202.client.comcast.net) joined #forth 18:41:16 back 18:41:26 wb 18:41:59 Hi bbls 18:48:16 --- quit: tathi ("leaving") 18:56:49 --- quit: bbls (Read error: 60 (Operation timed out)) 19:06:48 --- quit: SeaForth (Read error: 110 (Connection timed out)) 19:14:09 --- join: SeaForth (~SeaForth@c-24-1-126-202.client.comcast.net) joined #forth 19:15:44 is there a standard number-parsing word ( addr u -- n 0|1 ) ? 19:15:59 ? 19:16:42 given string in 'addr u', tries to parse a number, returns num and true if successful, false if failed 19:16:50 Hmm 19:17:11 or is there only that >number thing? 19:17:14 There's >number, but that returns the number on TOS 19:17:38 In RetroForth, you can use >number ?if ... then to check whether the conversion worked or not 19:18:00 what is '?if'? is there some kind of global 'success flag'? 19:18:22 It uses the carry flag (retroforth-specific) 19:18:27 Same thing with "find" 19:18:42 >NUMBER returns the unconverted part of the string, too, so you could just test for zero length 19:19:22 Not in RetroForth 19:19:38 " 1000#" >number 19:19:56 well, i'm building a forth, so i'll probably just write a 'parse-number' 19:20:04 would leave the addr/count of "1000#" on the stack and set cf 19:20:11 ok 19:22:13 the ANSI Forth >NUMBER is useful for building higher-level number parsing words 19:22:39 Should parse-number leave the string addr/count on the stack? 19:24:01 if it doesn't eat all of the string, it should leave what is left, yes 19:24:13 Hmm 19:24:20 * crc wonders how this will work... 19:24:52 In RetroForth I can do : parse-number >number ?if drop 0 ;; then 1 ; 19:24:59 " 100" parse-number . 19:24:59 0 19:25:06 " 1@@" parse-number . 19:25:06 1 19:25:12 type 19:25:13 1@@ 19:26:23 : >NUMBER ( ud1 c-addr u1 -- ud2 c-addr u2 ) BEGIN DUP WHILE >R DUP >R 19:26:29 C@ -digit WHILE 10*+ R> CHAR+ R> 1- REPEAT THEN R> R> ; 19:26:41 My >number is in assembly 19:27:35 i don't care about speed for number conversion -- never showed up high in my profiling, so... 19:27:45 hehe 19:28:02 i *do* do some speedups for number _output_, though 19:28:11 not full assembler, though 19:29:35 My compiler/interpreter words (: entry find >number forth macro last base , 1, 2, 3, ;; ; interpret) are in assembly and so are the basic I/O words (key emit type .) 19:29:55 Pretty much everything else is written in Forth (or is inlined using the , words) 19:31:08 having FIND (or one of its factors, anyway) in assembler is useful, yes 19:31:59 I found that it was simpler and cleaner overall to implement the core compiler in assembly than to metacompile :) 19:37:35 hehe. i've got a bigger problem/goal, though 19:37:49 i need to _cross_-compile 19:38:40 hmm 19:38:51 --- part: SeaForth left #forth 19:39:00 * crc wants to eventually "meta-assemble" RetroForth 19:49:52 my situation is different 19:50:08 with a tib of only 20 bytes, i'm parsing one token at a time 19:50:42 so the trip is to read a token into tib with 'word', then attempt to parse it 19:50:50 into a number 19:51:00 or into an xt of a known word 19:51:27 can't afford 80, 128 or whatever bytes for an input buffer 19:51:48 wow. *small* target! 19:52:06 yep, a PIC16F with only 190-odd bytes of RAM spare 19:52:08 i've got a few GB and a 64-bit CPU :-) 19:52:26 but my forth executes code resident in off-chip EEPROM (32-64k) 19:52:38 primitives and the vm live on the PIC itself 19:52:58 You parse when after each space? 19:53:01 yep 19:53:06 * crc used to do that... 19:53:07 nasty, eh? 19:53:12 Not really 19:53:32 I prefer a big TIB though :) 19:53:39 but in the event of failure, the interp will read to eol before barfing 19:53:42 ah, have the input reading thing stop after each space. interesting :-) 19:53:52 yes - not much choice there 19:54:33 pretty hard to do input line editing with that set up, though ;-P 19:54:56 that's the user's problem 19:55:02 * crc went to line-based input when he began writing the block editor :) 19:55:39 if i could find a decent capacity I2C RAM chip (larger than 256 bytes), I'd go for full buffers/blocks 19:55:58 it took me almost two years before i implemented backspace at all. i just learnt to type better :-) 19:56:06 i could use some eeprom space as a buffer, but it would prematurely wear out the eeprom 19:56:34 nasty idea - writable memory that 'wears out' 19:56:58 can't you add some sram chip? 19:57:00 eeprom wasn't meant to be continually written to 19:57:22 i could use SRAM, but it would eat too many of the PIC's I/O pins 19:57:41 address bus, chip enable, data bus, r/w, clock ... 19:58:14 even if the data bus is muxed onto address bus, that's still 18 or 19 pins 19:58:40 i could possibly use shift registers for address/data, but that's bloating the chip count 19:59:16 there's sram on iic, too 19:59:29 is iic like i2c? 19:59:44 it's the same thing. 20:00:00 Inter-IC-Connect 20:00:14 got any part numbers or urls? 20:00:52 lemme see... 20:39:14 prune ( xn xn-1 ... x1 x0 i j -- xn xn-1 .. xi-j xi-j-1 .. x1 x0 ) 20:39:41 deletes items i thru i+j-1 from stack 20:39:46 Hmm 20:40:13 beats a pile of roll/drop 20:41:25 So if I did: 1 2 3 4 5 6 2 5 prune what would .s show? 20:42:08 bad args 20:42:14 ? 20:42:19 example 20:42:59 1 2 3 4 5 6 7 8 4 2 prune -- 1 2 3 5 6 7 8 20:43:48 ick 20:44:01 it's kinda like 'nip' on crack 20:44:04 * crc never lets words do things like that.... 20:47:36 hmm, that is a bit ugly 20:48:12 maybe 1 2 3 4 5 6 7 8 2 3 prune returning 1 2 3 7 8 20:48:48 Why do your words need to modify the stack that heavily? 20:48:48 and in your example, there'd be stack underflow of 1 cell 20:49:34 because RAM is scarce, prefer not using variables, also i'm minimising use of >r 20:49:39 hmm 20:49:49 still, it seems like overkill to me... 20:59:07 * crc goes to bed 21:20:40 --- join: Sonarman_ (~snofs@adsl-64-169-92-177.dsl.snfc21.pacbell.net) joined #forth 21:35:18 --- quit: Sonarman (Read error: 110 (Connection timed out)) 22:00:16 --- join: SeaForth (~SeaForth@c-24-1-126-202.client.comcast.net) joined #forth 22:25:09 --- join: futhin (thin@bespin.org) joined #forth 22:25:16 Hi 22:25:18 hi 22:25:49 * Robert throws some C pointer syntax at futhin 22:26:04 * futhin dodges it matrix-style 22:26:36 so whats new 22:26:50 The year. 22:27:16 And, uhm, I guess crc is making progress on rf, and aum is working at his tiny Forth system. 22:27:57 the year is new? 22:27:59 how so? 22:28:06 :P 22:28:27 Modulo magic 22:34:18 --- quit: SeaForth (Read error: 104 (Connection reset by peer)) 22:59:58 --- nick: futhin -> cduce 23:00:09 --- part: cduce left #forth 23:08:52 --- quit: aum () 23:12:40 --- quit: segher ("Leaving") 23:26:41 --- join: NiggorHat (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth 23:26:52 Heh. 23:27:26 hi 23:27:35 sup mah niggaz 23:27:45 --- quit: NiggorHat (Client Quit) 23:34:26 --- quit: paf ("Leaving") 23:47:24 --- quit: Sonarman_ ("Reconnecting") 23:47:29 --- join: Sonarman (~snofs@adsl-64-169-92-177.dsl.snfc21.pacbell.net) joined #forth 23:59:59 --- log: ended forth/05.01.01