00:00:00 --- log: started retro/10.01.01 06:33:26 back 06:39:30 morning 06:39:39 happy 2010 06:59:54 * crc is working on adding proper scrolling to the sdl port 07:02:16 nice 07:08:46 [crcx/ngaro] 740d7d: graphical port: console now scolls 07:15:23 and now I've added circle drawing, so it's a match to the javascript build :) 07:15:47 [crcx/ngaro] 4122ee: add circle code 07:38:29 --- join: erider (n=chatzill@pool-173-69-160-231.bltmmd.fios.verizon.net) joined #retro 08:45:06 hi erider 08:45:27 crc: hi 08:45:39 key 27 == enter right? 08:45:48 27 = ESC 08:45:51 10 = ENTER 08:46:01 ah ok 08:50:42 crc: no work today 08:50:47 nope :) 08:50:53 cool 08:51:01 relaxing alittle 08:51:30 yes, and doing some coding on retro (I finished the canvas stuff in the sdl-based vm, and added scrolling to it) 08:52:32 I am interested in forth written debugger 08:53:43 reva has a debugger IIRC 08:58:06 yeah I know I am playing around with the inline{"hex"} feature 09:01:24 there are still bugs in the mac port of reva 09:01:32 crc: I am not sure how to attach to a running process yet 09:02:07 I don't think reva's debugger can do that 09:04:56 crc: ah it only good to look at the internals of reva itself 09:05:01 yes 09:05:23 handling other processes is a much more complex task 09:05:24 we that is useful I guess 09:05:29 well* 09:05:51 retrosee is pretty powerful, especially if you know 09:05:57 *retro's see 09:06:13 especially if you know ngaro 09:06:32 which is really simple 09:18:46 http://gist.github.com/267165 09:19:49 --- join: js4 (n=Jay@64.38.131.169) joined #retro 09:19:56 hi js4 09:20:19 Hi, looks like a bug in build.c (from the retro-10.3 tar). 09:20:33 what is it doing? 09:20:45 I am building on cygwin, I have the fix too ... 09:20:53 Here's the error messages... 09:21:15 bash-3.2$ cd ../tools/; make; cd ../console/; make 09:21:15 ../tools/build retro 09:21:15 devices.o:devices.c:(.text+0x41): undefined reference to `_initscr' 09:21:15 devices.o:devices.c:(.text+0x46): undefined reference to `_cbreak' 09:21:49 The problem is the -lcurses is in the wrong place. I change line 203 of build.c to read: 09:21:52 snprintf(cmd, 256, "gcc %s %s %s -o %s", flags, objs, libs, fn); 09:22:01 and it builds now. 09:22:28 it was doing gcc ... -lcurses foo.o bar.o 09:22:50 now it's doing gcc ... foo.o bar.o -lcurses ... 09:23:30 now... I'll go play with forth instead of cygwin/windows/gcc/etc. 09:24:02 js4: thanks, I'll apply the fix 09:24:15 No probs! THanks for your work on retro! 09:24:35 you're welcome ;) 09:24:46 [crcx/ngaro] 57878d: fix build.c under cygwin [thanks js4] 09:25:04 It prolly deserves to be tested elsewhere, but ixquick found me a linux news group explaining the problem (for a user with the same error on a different program...) 09:25:54 lol, no a cygwin group... def worth testing... http://www.mail-archive.com/cygwin@cygwin.com/msg87537.html 09:26:10 I tested it on my mac, and will check on linux later today 09:26:26 ok, cool. Happy and prosperous new year! Have fun! 09:26:53 I'll try 09:27:47 * docl just had a thought about commenting 09:27:53 docl: in your gist, evalBlock{ doesn't appear to be used 09:28:51 ah yes, I guess if it is not public it is not needed 09:29:17 I was thinking, why not create | ... ; as a comment type? 09:29:38 then you could make comments with stack diagrams of words in them 09:29:46 js4: the fix works on my linux box as well 09:29:53 docl: example please 09:29:56 | find ( "-f ) ; 09:30:25 Great! /me tries retro under emacs... 09:30:29 basically put it at the beginning of the local def so people don't have to look up the word to see what it does 09:32:00 no wait, that's not the correct stack diagram 09:32:05 | find ( $-f ) ; 09:32:14 why end in ; ? 09:32:19 since it takes a string rather than parse for one 09:32:30 older retro versions had: | .... 09:32:40 which ended at a newline 09:32:54 yeah, but newlines aren't always convenient 09:33:17 v.v "Error opening terminal: emacs." I'll fix that later I guess... 09:33:18 you couldn't document words with a ; in their name using ; as a delimiter 09:33:32 hmm, that is true 09:34:56 you'd have to look for space, ;, and another space 09:35:23 that's trickier though 09:35:30 and what if you don't have a space following the ; ? 09:35:40 e.g., at the end of a file you include with --with 09:36:08 look for any non-ascii maybe? 09:37:11 | find ( $-f ) | 09:37:56 I guess that works just as well. 09:38:44 it's what you use in retroweb anyway :) 09:39:15 | find ( $-f ) return true if string is a word in the dictionary. | 09:39:24 any hints what retro is looking for in the environment other than $TERM ? 09:39:52 $ == 'string' 09:39:59 I get the same error when running under a cygwin bash shell (though it complains about "... terminal: cygwin." 09:40:23 erider: it is the stack diagram we use for strings, yes. 09:40:37 js4: no; it could be a problem with the curses library 09:41:01 js4: I only have limited access to windows systems, so don't get to test much on them :( 09:41:04 hmmm.... time for gdb, or printf's.... 09:41:10 * js4 reads the source... 09:42:23 erider: $ means the number on the stack is an address for a string of characters that has 0 at the end. 09:43:08 yeah I am trying to get my stack notion together 09:43:46 [crcx/retro10] 64bd91: updated ifDefined/ifNotDefined based on code from ... 09:46:11 erider: http://gist.github.com/267171 09:54:31 that helps 09:57:31 maybe accept could take a string as an argument... 09:58:31 or a variant form of accept 10:02:51 --- quit: js4 (Remote closed the connection) 10:03:51 is there a way to resume the accept loop without starting at the beginning of tib all over again? 10:08:52 http://gist.github.com/267165 10:09:04 now has comprehensive documentation of the words it calls 10:11:44 oh, I should be using R: and C: 10:12:21 I omitted the parentheses. does this make it less readable? 10:13:45 R: and C: add a lot of width to the stack diagram 10:15:34 --- join: js4 (n=Jay@64.38.131.169) joined #retro 10:29:35 ommision of parenthesis is ok, but have slightly more space between the word names and the stack comment (e.g., with accept, two spaces is a better visual separation) 10:29:55 accept was only designed to read a string into tib 10:31:46 [crcx/wheke] cfe466: canvas library now included in main repo 10:35:06 well... it runs if I compile without -DCURSES... but it treats space as a ... 10:35:23 that's normal 10:35:32 o 10:35:44 retro's parser deals with one token at a time, cr is a synonym for space 10:35:54 docl: try this: : accept$ ( $c- ) push repeat ekey dup r =if pop 2drop 0 swap ! ;then swap !+ again ; 10:36:31 docl: it's a varient of 'accept' that'll store input to a string address instead of the tib 10:36:44 how do I test if it has enough terminal smarts? does it work OK without curses?? 10:37:20 Hmmm.... I supose since I'm not seeing 11 when I type 1 it is OK... 10:37:42 clear clears the screen, cool 10:37:46 good 10:37:46 cool 10:38:04 js4: cygwin may be emulating the low-level stuff well enough to run without curses 10:38:29 * crc hasn't used cygwin much over the last two years 10:38:31 So, atleast for me, under cygwin, compile without -DCURSES. There is something busted about how curses is set up on my system I guess... 10:39:05 Last I messed with curses I really *had* a terminal... if I was lucky it was that cool heathkit with 25 lines! 10:39:27 we have quite a few dumb terminals where I work 10:41:47 [crcx/wheke] f04af7: add accept$ to strings library 10:42:46 [crcx/wheke] 3ace89: disable .primitive class when using [IF]/[THEN] 10:53:47 or ? neither is erasing... something related to curses? ^H seems to have the effect of reasing, it just doesn't do it on the screen... 10:54:44 * docl hadn't seen the !+ word in action before, nice 10:55:28 js4: what does it do if you try 8 emit? 10:56:07 8 is the keycode for control-h/backspace on my computer 10:57:08 hard to tell from the interpreter... let me try something : ... ; 10:57:15 hmm, it's hard for me to test as well 10:57:24 try maybe : t 10 for 8 emit next ; t 10:58:03 : foo 45 emit 45 emit ; 10:58:20 and : foo 45 emit 45 emit 8 emit ; 10:58:29 look like they produce the same output 10:58:31 -- 10:59:20 : foo 45 emit 45 emit 8 emit 8 emit 46 emit ; 10:59:25 looks like it prints .- 10:59:41 even though it's backing up over the --'s just fine... 10:59:57 it's backing up? that means it is working 11:00:06 mine nondestructively backs as well 11:00:36 you could do 8 emit 32 emit 8 emit 8 emit to backspace and erase 11:00:39 yes, backing up, non-destructively. I didn't know if that was by design, or by "js messed up the build with curses stuff" 11:00:46 :) 11:01:43 you should be able to backspace and type over a word if you have not yet pressed space. 11:01:44 hmmm.... let's go see if I can use the vector stuff I just read to patch the interpreter's read.... 11:02:21 try typing key then pressing backspace, if you want to see what key backspace is read as 11:02:26 ...bs =if 8 emit 32 emit 8 emit then... 11:02:45 8 11:03:08 good 11:03:35 and "... del =if 8 emit 8 emit 32 emit 32 emit 8 emit ( call what 8 does to the input buffer ) then ..." 11:04:02 hmmm 8 8 32 32 8 8 actually... but one step at a time... 11:04:43 *giggle* "see listen" Now I see a bash prompt. 11:05:02 yep repros just fine 11:05:13 i.e. that's a crash bug 11:05:52 RETRO 10 11:05:52 11:05:52 ok see listen 11:05:52 1638 nop 11:05:52 1639 nop 11:05:52 1640 call 1622 ( ok ) 11:05:54 1642 lit 32 11:05:56 1644 call 702 ( accept ) 11:05:58 1646 call 1319 11:06:00 1648 call 1585 11:06:02 1650 call 1601 11:06:04 1652 jump 1640 11:06:06 1654 ; 11:06:08 1655 call 1478 11:06:10 1657 call 1638 ( listen ) 11:06:12 1659 ; 11:06:14 1660 nop 11:06:16 1661 Unknown: 4192 11:06:18 1662 Unknown: 39 ''' 11:06:20 1663 Unknown: 49 '1' 11:06:22 1664 Unknown: 43 '+' 11:06:24 1665 nop 11:06:26 1666 Unknown: 1660 11:06:28 1667 Unknown: 4192 11:06:30 1668 Unknown: 43 '+' 11:06:32 1669 Unknown: 49 '1' 11:06:34 1670 Unknown: 45 '-' 11:06:36 1671 nop 11:06:38 1672 Unknown: 1666 11:06:40 1673 Unknown: 4192 11:06:42 1674 Unknown: 47 '/' 11:06:44 1675 Unknown: 115 's' 11:06:46 ..... 11:06:48 bash 3.2$ 11:06:51 the trouble is the lack of two noops after the return 11:07:46 maybe if you do 0 1661 ! it will work? 11:07:55 Hmmmm and is the compile not doing the tail-recursion -> jump optimization? Or is see lying? 11:08:10 * js4 tries 0 1661 ! 11:08:37 Nice! 11:08:58 "see" is parsing through all that code for a particular pattern to know when to stop decompiling for you... 11:09:19 that pattern is matched for words that haven't been vectored yet 11:09:41 * docl thinks a new ngaro code signifying the end of a word may be justified 11:10:19 or possibly using two returns in a row would do the trick. trouble is that uses up extra memory for every word. 11:10:42 Hmmm... how color-ish are you (planning to be)? Would it be enough to quit when see gets to the start of another dictionary entry? 11:10:59 in any case, a word normally ends with a return, and a new word normally starts with two 0's 11:11:18 You don't do " : foo 1 : bar + ; " do you? 11:11:30 that's basically what it does, except that when you vector a word it doesn't have those zeros 11:11:40 no we don't have that 11:12:09 at least I don't think we do 11:12:12 hmm 11:12:25 THen yeah, see knows where listen starts in memory, and can check the words near it in the dictionary to get a good stoping spot. 11:12:50 Why do words *start* with two nop's? 11:12:57 : foo 1 [ stub bar ] + ; would probably to the same thing. lemme try it real quick 11:13:26 it's part of vectoring 11:14:01 one of those is for overwriting with a jump instruction, the other is for overwriting with the address to jump to 11:14:19 So 1 opcode per byte? byte addressed VM? 32 bit or 16 bit cells? 32 or 16 bit addresses? 11:15:05 the latest retro is using cells instead of bytes. 32 bit I think 11:16:10 ok, I'm messing around with 10.3 right now... and reading the docs a little too ^_^ 11:17:07 : foo 1 [ create bar ] + ; works, except you'll have to do "bar execute" as it just returns the address. 11:17:35 alternate way to vector: word starts with no nops, but has space after it's end to store the bytes overwritten by the jump when it is vectored. 11:19:04 (create makes things of type .data, so if you reclass that to .word it will work) 11:20:02 I was vaguely playing aroud with "RED-IS-ALL-CAPS green is lower case" and it looks pretty OK actually. Hopelessly nonstandard though... 11:21:38 cool 11:21:44 the dictionary headers are a linked list, but only to previous entries. I could follow it, but not all words have visible headers (e.g., stuff between { } and {{ }} get unlinked), so that's not a reliable way of finding the end of a word 11:23:05 The only thing you have to be sure off is not to fall off memory. So take the closer of "nearest word" and "beginning of dictionary" (or end, dunno which whay yours grows...) 11:23:46 So what if see sometimes shows hidded words... just stop before the edge of memory. 11:25:12 Most folks know decompiling isn't easy to get 100% correct. Just avoid the crashes. 11:25:34 I like "word classes" cool idea... 11:25:42 easy enough to fix 11:26:07 http://gist.github.com/267221 11:26:23 prolly be a day or two before I have enough experience in retro to contribute to implementation... 11:26:46 [crcx/retro10] 586287: decompiler should stop at "here" 11:28:24 nice 11:28:31 awesome 11:30:46 [crcx/retro10] 5a4089: should have used >if not =if with last patch 11:33:02 or "... I am guessing ;; is return-but-dont-end-colon-definition 11:34:03 yup 11:35:41 < won't work since the address being checked should always be less than here 11:36:04 hmm, see listen still crashes for me 11:37:55 it's defined in core.retro, with the big set of aliases after it. 11:38:14 those aren't aliases, the list is the initial dictionary 11:40:36 true 11:41:00 word entries, or whatever they're called 11:48:44 docl: pull from my repo and try now 11:48:55 I found a stack leak in "see" 11:48:55 [crcx/retro10] 294aab: fix stack leak in "see" 11:50:41 is ">>" arithmetic, or logical? DOes it preserve the sign or shift in 0's? 11:51:27 cool, listen doesn't crash it 11:54:09 << -- y * 2^x 11:54:24 >> -- y / 2^x 11:54:26 IIRC 11:54:31 I don't use them much 11:55:33 * js4 tries it out, "duh, I forgot I can ask the code. -1 2 >> . prints -1" 11:56:08 and -1 2 / . prints 0 11:57:00 actually, I have no code currently that uses either one of these words :) 12:01:14 Yep, pretty much good for communications and implementing things like *, /, sqrt... 12:02:06 * and / are primitives, sqrt is defined in the library. I'm not sure how good the sqrt routine is though 12:03:04 Hmmmm I think "Holds Y coordinate for text output (framebuffer only)" either lost the word it is describing in the glossary, or ( is *very* interesting. 12:03:23 line 914 in RetroLanguage.rst 12:04:24 that was a remnant from the old framebuffer implementation 12:05:46 [crcx/retro10] 02f9f7: remove line about an older word that should have b... 12:07:48 does copy work in both directions with overlapping memory? 12:08:16 100 101 20 copy 101 100 20 copy ??? 12:08:56 or does it do fill in one direction or the other? 12:09:54 I've never tested it on overlapping memory regions 12:13:20 o.o No block disk io? 12:13:31 not at this point 12:14:56 others are experimenting with such, but I've not been sent any patches and haven't implemented a disk-type device in my vms 12:16:02 Does the javascript version have a save-image capability? 12:16:20 not in 10.3 12:16:38 That is about half the reason I am playing with retro, cause I found the webpage version a while ago... very cool that... 12:16:42 10.4 has two (one server-side, and one client-side), but the client-side saving code only works on some browsers 12:16:59 Cool. 12:18:22 "100 s " bash prompt. 12:18:43 only 64 blocks are declared by default 12:18:56 you can increase that though: 12:18:59 1024 set-blocks new 12:19:19 first block is block 0? 12:19:24 yes 12:21:58 snapshot of latest image file: http://retroforth.org/latest.gz 12:22:00 Well I like it. Good job! 12:23:27 thanks :) 12:24:37 grrr... how many times will I type 20010 before I get 2010 into my fingers? 12:25:01 lots 12:25:31 ok, afk for a while... back later. Fun new toy! 12:32:51 heh, welcome to the twenty-somethings 12:33:28 hi guys 12:33:55 and goodbye to the x-thousand-y's. see you again in another 99 decades 12:34:02 hi erider 12:34:16 I am back :) 12:34:57 cool! 12:35:30 where were we last night? did we cover strings? 12:36:29 * docl wrote much of the wheke strings library 12:37:12 there's two kinds of string you can use... delimited or counted 12:37:23 zero delimited is default in retro now 12:37:30 it used to be counted in older versions 12:38:15 am I making sense or talking too fast? 12:40:38 if I get into a monologue, feel free to interrupt with any questions 12:41:44 say you have a string 64 chars long, and you want to split it where there is a comma 12:42:52 ok 12:42:52 you start with the string address, and the count number for it... in a stack diagram we would call this 'ac' 12:43:17 $c would be better, to show that we are dealing with a string 12:44:01 is $ used for both counted and zero terminated? 12:44:28 good point 12:45:26 very few strings won't have a zero terminator though 12:45:39 zero terminated can be treated as a counted string anyway 12:47:10 blockfile lines are an example of one that doesn't have a zero terminator, as blockfiles are padded with spaces. the end of the line in the blockfile is just where it hits 64 chars and wraps to the beginning of the next line. 12:47:47 but most of the time when you are playing with strings you'll want to add the zero terminator 12:48:14 then if you need the count you can always call getLine 12:48:34 getLength 12:48:37 oops 12:48:39 that's right 12:48:55 "dup getLength" most of the time 12:49:11 true 12:49:32 otherwise you have the count but not the address 12:50:07 so let's say we have a string on the blockfile that we know is 64 chars long, and has a comma in the middle of it. 12:50:40 ok 12:50:46 what we want are two strings in compile space (on the heap) that are zero terminated. 12:51:27 you can get the address at a given line in the block editor by using the line number and (line) 12:51:43 so if it's line 0 just type 0 (line) 12:52:47 : setup ( $n- ) 0 (line) 64 ; might be a word that gets it for you 12:53:28 ( -$n ) 12:53:49 since you're returning the address and count, not consuming it 12:53:53 oops 12:54:20 next we want to keep track of the current value of "here" 12:54:26 create is a good way to do this 12:54:30 create string1 12:56:34 I am having issues with the if statement 12:56:40 hold on 12:58:17 the stack diagram for splitcomma would be like my typo above 12:58:29 : splitcomma ( $n- ) ; 12:58:47 : splitcomma ( $n- ) 13:02:39 ( $n-$n ) for dup @ char: , =if pop ;; else , then 1+ next 13:02:50 r> is push and r< if pop right 13:03:02 is* 13:03:28 >r is push, r> is pop 13:03:44 or used to be in the old retro 13:05:00 ( $n- ) here swap dup allot copy 0 , ; 13:05:26 that should take care of the second part of the word. but the first part has a problem, I forgot to use 0 , so it is not terminated 13:05:43 ( $n-$n ) for dup @ char: , =if 0 , pop ;; else , then 1+ next 13:05:56 * docl should test this code out 13:07:29 have a look at this please 13:07:44 it keeps crashing reva 13:07:54 : deduct ( n -- ) 13:08:07 >r account @ 0 - account ! ; 13:09:51 account is defined "variable account 13:10:07 100 account ! 13:10:36 110 deduct 13:10:48 should print the message 13:11:07 ah I am missing then 13:13:36 docl: do I need to use dup for the if word? 13:13:52 yes, if you want to keep the value on the stack 13:14:01 if takes 2 values off of the stack 13:14:40 docl: I don't need the values if I call the words again in the else statement 13:15:48 so you probably don't need dup. although it might strictly speaking be more efficient to keep the value on the stack instead of calling the words 13:17:14 : deduct push account @ dup 0 : deduct ( n- ) push account @ dup 0 what I want is >r takes the value passed to "deduct" and store it on the return stack for later uses the fetch account's value to compare it to see if it is less then 0 "if so do nothing and print the message but if not fetch the value from account then pop the value passed to "deduct" back on the data stack then subtract the two values on the data stack then store it back into account" 13:20:03 hmm, the way I wrote it there is a return stack imbalance (which will cause a crash) 13:20:25 push/pop isn't really needed as far as I can see 13:21:06 : deduct ( n- ) account @ dup 0 I need to store the number that is passed to the word deduct 13:21:25 in this example it just stays on the stack 13:21:48 it gets dropped if there is a negative balance, along with the copy of account's stored value 13:23:02 that works 13:23:07 :) 13:23:15 so I needed the dup 13:23:39 the dup was just because I took out the extra "account @" 13:23:53 it was better, but not 100% needed ;) 13:24:36 ok 13:24:38 : deduct ( n- ) account @ 0 you can continue :) 13:25:27 * docl seems to have picked a hard example with splitting strings 13:26:06 just thought of an easier way to do it 13:26:32 first we copy the string to "here", then we give it a 0 at the end: 13:26:56 ( $n- ) here swap copy 0 , 13:27:14 erider: you couldn't use >r in your word earlier since there was no matching r> 13:27:26 erider: the return stack isn't intended to be used for passing value 13:27:27 copy takes three arguments: starting address 1, starting address 2, and number of chars to copy 13:27:51 oops, I made a mistake 13:28:01 ( $n- ) here swap dup allot copy 0 , 13:29:21 this works better, but we lost the original "here" value. it has changed, so we can't access the string easily. 13:29:56 ( $n-$ ) here dup push swap dup allot copy 0 , pop 13:30:41 is one way to do it, from inside of a word (push and pop don't work from the interpreter) 13:31:13 : keepCountedStringHere ( $n-$ ) here dup push swap dup allot copy 0 , pop ; 13:32:01 this takes a counted string, copies it to the heap, allocates space for it, terminates it, and returns the address of it so you can use it. 13:32:35 crc: I know but it was a hack to save the value that was placed on the data stack 13:33:08 erider: you still have to use r> to move it back to the data stack, or it'll be treated as an address to return to 13:33:52 : keepCountedStringHere ( $n-$ ) here push for @+ , next drop 0 , pop ; 13:34:01 crc: yeah I used >r then later r> 13:34:54 but docl found a better way 13:35:06 erider: >r and r> have the disadvantage that they mess with the return stack, which can lead to crashes. best not to use them unless you need to. 13:35:12 so I don't need to use >r or r> 13:35:19 :) 13:36:59 crc's version of keepCountedStringHere uses a for loop and a non-consuming store-increment operator to parse through the original string's values 13:37:15 or I should say fetch-increment 13:37:20 fetch-increment 13:37:33 @+ and !+ are excellent for arrays and strings 13:37:47 yeah, I really need to start using them :) 13:39:33 * docl is not in the habit of seeing a single + as incrementing by 1 though, that will take some getting used to 13:40:36 | @+ a-an ::: gets value and increments address | 13:42:26 in this context it could be $-$c since it is a string address and a character value returned 13:43:18 docl: the names were from the machine forth dialect I borrowed from 13:43:51 docl: can we have a simple example of a sime string parser? ie " foo" parse out 'f' 'o' 'o' 13:44:01 simple* 13:44:24 sure 13:44:47 [crcx/retro10] 291657: fix stack comments for @+ and !+ 13:45:20 : parser ( $-c... ) dup getLength for @+ swap next ; 13:45:29 might do the trick 13:46:05 note that if you do emit emit emit it will come out backwards because of the stack order. 13:46:06 you need a 'drop' after the 'next' 13:46:21 : parser ( $-c... ) dup getLength for @+ swap next drop ; 13:47:04 seems to work 13:47:10 yes it does 13:47:29 hooray for @+ 13:47:36 or I wonder if this would work : parser ( $c-- ) 0 do @ + swap loop ; 13:47:51 no 13:48:05 that would add the fetched value to whatever was on the stack 13:48:59 : @+ ( a-ac ) dup 1+ swap @ ; 13:49:00 so I would need @ 1 + 13:50:00 : parser ( $c-... ) 0 do dup 1+ swap @ swap loop drop ; 13:50:02 might work 13:50:12 * crc doesn't use do/loop, so can't confirm at present 13:50:15 bbiab; dinner time 14:27:20 Does the compiler do "tail-call becomes jump" optimization? 14:37:44 I think we have an optimizer in the wheke library that does that 14:43:37 OK, yeah I found something in library/internals/optimizer.retro 14:45:21 looks like there's a bug though... 14:47:06 what bug? 14:47:18 suppose you just finished compiling "lit 7 nop" and now are about to compile ";". You will think the previous instruction is a call (opcode 7). Depends on endianess, the constant might be 0x700 instead or something... 14:47:37 or lit 7 drop, or lit 7 xor.... 14:49:11 that is a potential problem 14:50:52 Yeah, the compiler has to tell itself that the last instruction compiled was a call.... anyway... I'm gonna go try to make del/rubout/<--- key work... and ^h erase... 14:52:44 semi painfull cause it's got meta compiler stuff mixed in... 14:54:21 the key input? 14:54:35 yeah 14:55:14 are you using the git repos? 14:55:24 display of the backspace/etc should be handled at the vm level 14:55:28 makes it a lot easier to track the latest changes 14:56:25 crc: in rem we have some exceptions to that, don't we? 14:56:45 docl: yes 14:57:04 but if he wants to clear the last displayed char, etc, that can be handled at the vm level more efficiently 14:57:05 I don't know anything about git. p4, svn, cvs, rcs, source safe, sccs, floppy thumb tacked to the bulletin board, those I know. 14:58:13 there's a git for cygwin I believe 14:59:29 --- part: crc left #retro 15:00:49 http://git.or.cz/gitwiki/CygwinBinaryInstall 15:00:57 --- join: crc (n=charlesc@c-68-80-139-0.hsd1.pa.comcast.net) joined #retro 15:00:57 --- mode: ChanServ set +o crc 15:01:53 a non-destructive backspace is sometimes useful when editing 15:02:59 isn't that what the back arrow is for? 15:03:11 arrow keys are not supported 15:03:28 (not reliably or portably anyway) 15:04:25 is there a nondestructive space? 15:06:03 no 15:07:39 * docl remembers the nondestructive backspace from the C64 15:09:38 js4: you can just download the tarballs from github if you prefer 15:10:57 More fun to play with the forth code though.... but.... 15:11:42 why did you decide to not buffer a whole line, sorta the more traditional aproach, let's you backup past spaces and all... 15:33:13 cool, got backspace... dunno what I did wrong with del though... 15:34:15 I think the use of space is for ultraportability 15:36:16 ok, got it. Here's my version of (accept)... 15:36:35 t: (accept) ( -c ) 15:36:36 repeat 15:36:36 key 15:36:36 dup, 127 # =if drop, 8 # then 15:36:36 dup, emit 15:36:36 dup, 8 # =if 32 # emit dup, emit then 15:36:38 dup, break-char # @, =if drop, ; then 15:36:40 dup, 8 # =if 1 # >in # -! drop, 8 m, ' (accept) m, then 15:36:42 >tib 15:36:44 again ; 15:37:47 All that code can be cleaned up and tightened up some too... no need for break-char as far as I can see. But need to read some more code to be sure... 15:38:35 forexample, there's a bug. Hit bs a few thousand times... 15:38:47 should overflow the return stack 15:40:54 ooops, no 8 is jump, not call... OK no bug... 15:41:17 hmm. you might make use of the (remap-keys) vector to change backspace behavior 15:41:21 what is that comma doing behind the @ and drop 15:41:32 @, drop, ?? 15:42:25 I don't pretend to understand the meta-compiler. I just hacked bassed on this pattern from the original code... 15:42:28 break-char # @, =if drop, ; then 15:42:39 the words are all different in the core part of the code because the final versions of the words haven't been added to the dictionary yet. 15:42:47 I would *love* to understand the meta-compiler better though... will be reading code for a while... 15:43:30 ok 15:43:33 I looked at (remap-keys) but it looks like if is commented out? 15:43:52 dup, 0 # !if (remap-keys) ws ; then drop, 15:44:05 no, that # is a literal sign 15:44:06 ooops! !if isn't !=0if 15:44:08 I think 15:44:22 it's !=if 15:44:25 sigh... 15:44:38 bug between the operators ears ^_^ 15:45:03 Yes, remap is prolly a better place to put the remapping of 127 to 8. 15:45:26 But the space emit bs emit prolly should be in (accept) 15:45:39 I think the idea is you can revector (remap-keys) without having to change key or accept 15:46:08 * erider is sticking to the basic words for now 15:46:08 I think custom listen loops are possible... 15:46:14 I looked at that. Problem is too many of the words I need to call are not in the dictionary. 15:47:07 In particular >in isn't in the dictionary. 15:47:30 yeah, that has bugged me too 15:50:29 OK, moved the remap of del to also be bs, works fine. 15:51:24 >tib is the pointer to tib, in core.retro 15:51:51 dup, 8 # =if 1 # >in # -! drop, 8 m, ' (accept) m, then 15:52:08 That's the original source. It's messing with >in. 15:55:49 hmm. I think the names have been changed in the latest git version I'm looking at 15:56:13 accept:tib is the new name 15:56:53 http://github.com/crcx/retro10/blob/master/source/core.retro line 133 15:58:56 to make that var public, go to the bottom and insert: >in data: >in 16:00:56 coolo... oh to be clear: I hearby put my code in the public domain. Do what you will with it. 16:01:05 :) 16:02:08 if I get more active on this project I'll use git and license my code under the same license y'all are using. 16:02:45 sure. we use public domain anyway, so it's all good. 16:04:51 coolo. most of the stuff I do is either lgpl2 or gpl2, but I would have no problems contributing to a public domain project. 16:06:03 awesome 16:06:05 Now I'll try to read and understand how retro's meta compiler works... everytime I touch the subject though it makes seem so simple... 16:07:18 the metacompiler seems hard to read to me. I'm not sure I understand why the words need different temporary names. 16:08:08 I guess they do act somewhat different in some ways, like the need for # for literal numbers. not sure what the reason for that is though. 16:10:43 t is for temporary, maybe? 16:10:52 m in m, is probably meta 16:11:21 * docl is reading meta.retro to get some insight 16:11:37 oh yeah, t for target 16:13:55 ok, so target is a word meaning something like heap normally means 16:14:35 : m, target @ ! 1 target +! ; <- basically like comma, but with target instead of heap 16:16:50 : m, target @ ! target ++ ; should work fine 16:31:42 looks like a lot of playing with pointers to memory cells 16:32:09 yep, real programming :) 16:34:23 yeah but hard to follow without a debugger to show to the steps along the way 16:34:36 * js4 is reading http://www.ultratechnology.com/meta.html 16:39:15 cool 16:44:50 I think this is where the trouble starts when meta compiling, the immediate words. "IF will compile a primitive sometimes called 0BRANCH" And what if the address/xt/opcode for 0BRANCH is different in the metacompiled system than in the one running doing the metacompilation? 16:57:31 docl: when you use: create array 10 allot 16:57:56 do you scale with * or can you use + to move to cell to cell 16:58:36 ie 1 array ! 2 array 1 + ! etc.... 17:05:31 that should work 17:06:06 yeah it looks like I can scale it with + 17:06:23 in retro 10 all cells are automatically the same, so you don't have to worry about their size versus that of bytes 17:06:45 1 cell is +1 address 17:07:02 yeah in char too? 17:07:12 yep 17:07:20 what if you use c@ 17:07:31 we used to have that, and reva probably still does 17:07:59 c@ would just get 1 byte. @ would get a whole cell of 4 bytes in a row 17:08:20 it's more efficient for strings that way 17:08:36 so how would you scale strings then 17:09:00 1+ 2 + 3 + etc 17:09:01 if 1+ is going to move an entire cell 17:09:13 1+ is how retro 10 does it 17:09:35 hmm 17:09:41 in reva 1+ will not work, you'll want 1 cells + or cell+ 17:09:48 (if it is like retro used to be) 17:09:57 no sure how it can tell the difference 17:10:18 type words, is there c@, c!, cells, cell+, cell-? 17:10:18 1+ works 17:10:45 1+ should always work for strings, but not for numbers 17:10:58 ok 17:11:01 it works for numbers too in retro 10 17:12:49 * docl ponders if cell size could be made modifiable in ngaro for the sake of eventual optimization 17:13:19 I'm sure if you had a big app and were a cheapskate for space you could go in and add such a feature, so your text takes up 1/4th the amount of space 17:14:34 but these days 400k isn't so much more than 100k... and the code is way more readable this way. 17:20:11 hmm. compressed strings is actually not a bad idea. you could write a word that turns sets of chars into numbers, then stores them as number arrays 17:20:40 no need for changing anything in ngaro really 17:21:00 pad place is cool 17:21:23 so say I have a mud server with a ton of textual data, I could cut the size of my descriptions to the same as in an ascii file just by passing them through a few filters 17:22:51 that moves text to the pad right? 17:25:07 http://gist.github.com/267334 17:25:26 * docl just wrote a looping conditional, woo :) 17:35:12 * docl just added it to my wheke fork 17:36:02 I think tempString is basically a form of pad place 17:37:35 docl: regarding space used by cells; ngaro will eventually support compressed images 17:37:44 sweet 17:39:17 ` does what? freezes the compiler 17:40:17 it compiles a call to a word later (when you are calling the word you are working on) instead of right away 17:40:58 ` is like postpone, it compiles a reference to the word's xt, and a call to the class handler for the word 17:41:27 ok so it is not like ' 17:41:29 sort of tricky to explain, but really useful once you figure it out 17:41:33 it is really handy when you are making a macro that compiles words in in a certain order 17:42:01 or is it something like create do> 17:42:16 create does> is a separate construct 17:43:16 oops, should have taken that ifagain bit out, it isn't used 17:43:44 : foo ` 1 ` 2 ` + `. ; immediate 17:43:52 would be compiled as: 17:44:15 : foo 1 .data 2 .data ['] + .word ['] . .word ; immediate 17:44:30 in this case, when executed, it'd run 1 2 + . 17:44:44 but if used in a definition, the code would be inlined, rather than compiled as a call 17:44:49 so: 17:44:52 : bar foo ; 17:44:54 see bar 17:45:11 7387 nop 17:45:11 7388 nop 17:45:11 7389 lit 1 17:45:12 7391 lit 2 ( last ) 17:45:12 7393 + 17:45:12 7394 call 1252 ( . ) 17:45:14 7396 ; 17:45:37 hmm 17:50:21 http://github.com/docl/wheke/blob/master/contrib/loop.retro 17:51:16 erider: the thing to remember is it's not only important what the word does, but also when it does it. 17:52:06 char: is about the same as key, except that char: grabs the input while you are typing it into the compiler. 17:52:23 (char may be more like 32 accept though iirc) 17:53:49 char: also compiles it as a literal number, which is also what the compiler does by default with numbers you type in compile mode 17:56:21 so "char: k" is the same as typing "107" or "[ 107 literal, ]" 17:56:36 or even more arcanely, [ 7 , 107 , ] 17:57:13 the square brackets leave and enter compile mode without creating a new word or compiling a return the way : and ; do. 18:00:52 [crcx/wheke] e1ddaf: ordered lists 18:08:47 erider: whenever you have a word do something in the compiler instead of just getting compiled in, it is a macro. 18:09:36 ok 18:10:06 there are two ways to make a macro that I'm aware of. "immediate" makes the last created word capable of acting in compile mode or interpret mode. "compile-only" makes it do something when entered in at compile time only 18:11:06 for something like a looping condition or if/then, it needs to compile a jump to a particular spot, at compile time. 18:11:24 one of the simplest is repeat/again. 18:12:07 repeat puts "here" on the stack at compile time (which becomes a pointer to any code following it) and "again" compiles a jump to that address when it is called. 18:14:13 what I did in my do/until was very similar to repeat/again, but I included compiling in code for "do" to store the top value in a variable and have "until" compare against it before deciding to jump back. 18:15:03 : repeat here ; compile-only 18:15:22 : again 8 , , ; compile-only 18:15:30 docl: one problem with a variable: you can't have nested words using do/until 18:15:45 true 18:16:03 it could be made to use a list like the { } words do 18:17:10 or you could have a condition-store-retrieve macro 18:22:53 just use the return stack 18:22:55 : do ( R: n- C: -a ) ` push here ; compile-only 18:22:55 : until ( R: - C: a- ) ` dup ` r ` !if swap 8 , , ` then ` pop ` drop ; compile-only 18:43:05 here is a version without the return stack. should be nestable as it dynamically creates the variable at compile time. 18:43:09 : do ( R: n- C: -a ) 0 , here dup 1- dup literal, ` ! ; compile-only 18:43:09 : until ( R: - C: a- ) 18:43:09 ` dup literal, ` @ 18:43:09 ` = ` not ` if swap 8 , 3 + , 18:43:09 ` then ; compile-only 18:45:56 hmm, gives me an endless loop in an actual test 18:48:21 --- join: revabot (n=blah@pool-173-69-160-231.bltmmd.fios.verizon.net) joined #retro 18:48:41 I think I just had forgot to drop a value 18:48:55 --- quit: revabot (Read error: 104 (Connection reset by peer)) 18:49:05 hmm that works 18:49:27 until leaves the count number on the stack. may not be the smartest form for it to take. 18:49:57 it's messy as heck, what with the 3 + bit :| 18:51:51 docl: throw an extra drop after the then 18:51:54 --- join: revabot (n=blah@pool-173-69-160-231.bltmmd.fios.verizon.net) joined #retro 18:51:54 Hi! pad place rocks! 18:52:01 macros don't have to be pretty 18:52:46 --- quit: revabot (Read error: 104 (Connection reset by peer)) 18:53:50 the code seems to go into an infinite loop if I try to use anything other than 0 as the target condition 18:55:49 you need to have a jump over the allocated cell for the value being checked 18:56:44 : do ( R: n- C: -a ) 8 , here 2 + , 0 , here dup 1- dup literal, ` ! ; compile-only 18:59:57 here is the entry point of the dictionary right? 19:00:52 here = next available address in the heap 19:01:51 so , is tied to the heap 19:02:00 where is pad? 19:02:13 pad is implementation defined 19:02:22 retro doesn't define pad 19:02:46 ok 19:03:17 crc: for some reason I thought here was tied to the dictionary location 19:03:32 in retro the dictionary is part of the heap 19:03:46 some forths split the headers into a separate memory area 19:04:12 ah ok because it is read in as an image 19:04:59 erider: in reva, pad is a 1k buffer, but I'm not sure where it's allocated at 19:05:09 crc: the fix works, thanks 19:05:52 so it kind of like scratch 19:06:52 yes 19:07:00 docl: cool. I didn't test it myself :) 19:10:22 crc: do you have toka in github too 19:11:09 yes 19:11:28 github.com/crcx/toka 19:44:28 ok, it looks a lot nicer now 19:46:45 I don't like that it always loops at least once even if tos is greater than nos. (although, that is how until traditionally works) 19:57:00 --- quit: erider (Read error: 113 (No route to host)) 20:14:35 fixed! 20:14:50 also fixed the stack diagrams 20:33:24 that was fun 20:33:59 * docl should write up a commentary on this macro 20:37:51 http://gist.github.com/267334 updated with latest code 21:32:02 commentary would be nice 22:32:33 docl: I began work on commentary: http://gist.github.com/267405 22:34:15 docl: "target" isn't used 22:34:46 docl: and in "until", you could use "` >if" instead of "` < ` if" 22:36:59 why are you making a non re-entrant do? 22:37:23 the latest 'do' should be reentrant 22:37:48 whups, forgot to take target out from my working code before pasting to the gist 22:38:09 docl: ok, I'll pull it out of my commentary 22:38:11 Hmmmm the virtual variable is used only at compile time? 22:39:15 If it's used at run time, and if two threads run through the same word, they will write over eachother's virtual variable. 22:39:16 it's used at run time, but allocated inside the definition 22:39:43 The variable is in the word using do, right? 22:39:46 js4: only one implementation of the vm allows for multiple execution threads 22:39:49 js4: yes 22:41:07 * docl just made up the term virtual variable. may or may not be the ideal term. 22:41:11 I have an implementation using the return stack, which would be usable with multiple threads 22:41:31 why not always use that implementation? 22:42:50 which implementation has multiple threads? 22:42:59 * js4 thinks virtual variable is about as good a name as c's "static local variable" 22:43:09 :) 22:44:10 docl: the go language vm 22:44:41 docl: and the unreleased assembly version 22:59:53 js4: I can see what you mean about threads. the mechanism will need modification to be multiple thread compliant. 23:00:53 things like "here" will need modification too. each thread should have it's own here, tib, pad, etc. 23:01:16 shouldn't be too terribly difficult 23:01:37 docl: tib, scratch, etc are fixed points in the image 23:01:51 hmm 23:01:57 * crc has only dabbled with threads calling a limited set of words and I/O 23:02:06 And I don't know what multiple here's would mean. 23:02:35 those words do need attention so that multiple threads don't do something funny though... 23:02:58 two threads interleaving a word they are entering in the dictionary eeek! 23:09:25 docl: http://gist.github.com/267414 23:09:44 js4: much needs to be considered/tested before retro can be made threadsafe 23:12:07 Well I think the old solution is that a bunch of global variables were made "user variables" and there was one copy per task. Kinda like docl said. When you did a thread switch you changed the "user variable pointer" 23:12:27 yes 23:13:07 but there's plenty of places where changes would need to be made 23:14:48 well you could just have multiple images that interact, I suppose 23:15:56 or rather the vm instances interact, passing data through ports perhaps 23:22:04 crc: I have to admit your version of do/until looks better 23:29:26 docl: I updated it with some commentary 23:30:00 Multiple threads always introduces lots of issues. Most can be avoided by avoiding globals and "static locals" as much as possible. It would be a shame for a retro looking forth not to be able to do multi threading though. After all some of chuck's earliest forths were... 23:31:00 though at that time the idea was of a "task" a heavier weight idea than what we usually think of as a thread... I think... 23:39:19 hmm. that sounds like an interesting project. 23:39:41 user variables, etc are all possible, but some vm support is needed (for the stacks) 23:45:24 can't user stacks be made from lists pretty easily? 23:45:34 not the return stack 23:50:12 Hmmmm the threads in the VM don't have to be the threads in the forth. Yes threads in the VM must have their own C stack. But the question is do you project the threads inwards or not. Most CPUs are single threaded. The hardware around the CPU and the software in it create threads from interrupts, and such, and explicitly manipulate stacks and stack pointers to give each thread/task it's own stack. 23:50:41 Or 'go' stacks. I dunno nothing about 'go' though. 23:55:43 I think the go vm has one image per thread, with words to communicate between images 23:59:59 --- log: ended retro/10.01.01