00:00:00 --- log: started retro/06.11.05
00:19:17 --- join: forther (n=forther@c-67-180-209-27.hsd1.ca.comcast.net) joined #retro
00:43:41 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #retro
02:34:10 --- join: Cheery (n=Cheery@a81-197-19-23.elisa-laajakaista.fi) joined #retro
02:56:32 --- join: neceve (n=claudiu@unaffiliated/neceve) joined #retro
08:38:31 --- quit: Shain (Remote closed the connection)
09:09:20 --- join: Shain (i=steve@c-67-161-56-76.hsd1.ca.comcast.net) joined #retro
10:03:28 <crc> good afternoon
10:12:07 <Cheery> crc: I'd require a pattern matcher in my latest project. Do you know anything which could help me doing it in rxforth?
10:12:31 <Cheery> I have clear what it should do but no clue how it should do what it should do.
10:17:29 <Cheery> I've noticed I'm like a mammal without fur on arctic if I have no pattern matcher or unificator.
10:22:29 <forther> what is "rxforth"
10:24:06 <forther> never mind. I find it on web.
10:29:21 <crc> forther: rxforth is one of my two current experimental projects involving forth
10:30:03 <crc> Cheery: I haven't found any existing libraries for pattern matching which I like yet...
10:31:17 <Cheery> I've found, but they are in lisp.
10:33:06 --- join: Snoopy42 (i=snoopy_1@dslb-084-058-124-096.pools.arcor-ip.net) joined #retro
10:34:58 <crc> glibc has some functions, but I haven't tried them yet: http://www.aquaphoenix.com/ref/gnu_c_library/
10:36:04 --- join: snoopy_1611 (i=snoopy_1@dslb-084-058-168-002.pools.arcor-ip.net) joined #retro
10:37:09 <Cheery> crc: I don't mean string pattern matching, I mean parameter pattern matching.
10:37:49 --- quit: Snoopy42 (Nick collision from services.)
10:38:19 --- nick: snoopy_1611 -> Snoopy42
10:38:53 * crc has now tested Toka on 32bit x86, 64bit x86, and MIPS, so it does run fine on BSD and Linux under various OSes/processors. I'm working on finding good PowerPC and ARM emulators at present
10:39:36 <crc> Cheery: I don't understand
10:39:59 <Cheery> Do you know haskell functions?
10:40:12 <crc> no
10:41:05 <Cheery> well, they have this kind of things.
10:41:36 <Cheery> ( x? _ y? foobar z )
10:41:58 <Cheery> then when you apply this to some list. you'd get 1 or 0, whether the list matches this pattern.
10:42:24 <Cheery> so if three first are anythings and fourth and fifth are foobar and z, it'd match.
10:42:28 <Cheery> otherwise it wouldn't
10:45:31 <Cheery> now, you can combine this with functions and other systems.
10:45:44 <Cheery> To replace very big if and switch cases.
10:45:59 <Cheery> And therefore, you can also make the input richer.
11:33:06 <Raystm2> Hi. I just got done reading the entire 902 repository. Followed the way it builds. That was fun. :)
11:36:47 <crc> glad you like it
11:39:29 <Raystm2> I wasn't familure with grep and sed. That's a neat way to build the dictionary per port.
11:40:04 <Raystm2> Took me a bit to realize the pipe command.
11:41:26 <Raystm2> I was so used to reading it as the comment delimiter.
12:18:26 <Cheery> crc: I think I solved the thing I was looking for.
12:18:36 <Cheery> It'll be useful for other things as well.
12:19:02 <Cheery> But it requires few tricks before I can write it with forth, could you implement jump macro?
12:19:22 <Cheery> ie. that there would be a macro which makes it jump instead of returning.
12:19:56 <Cheery> Thus, I'd require some kind of allocation bag, but I think I write that myself. :)
12:20:19 <Cheery> That jump macro shouldn't be complex and I guess you could easily implement it in rxforth.
12:23:41 <crc> what would it need to do?
12:25:09 <Cheery> It just jumps from a matching sequence to another.
12:25:29 <Cheery> Therefore not using return stack much.
12:25:56 <Cheery> There may be a matching jump in a middle of routine. So this is why I ask. :)
12:26:14 <Cheery> I'd just like to turn some calls into jumps myself.
12:26:35 <crc> tricky, unless you track the offset for each call
12:26:58 <crc> you can change $e8 (call) to $e9, but you have to know where in the word the call is
12:27:45 <Cheery> well, I could the macro after I've wrote call.
12:28:07 <Cheery> oh well. wait.
12:28:39 <Cheery> I should select the jump from a memory address.
12:29:16 <Cheery> like. :right_path @ jump
12:29:36 <Cheery> so the jump could be just like execute.
12:30:37 <Cheery> So I'd need to write an instruction something like: jmp eax
12:31:37 <Cheery> Thought so that the jumping pointer doesn't leave into stack.
12:35:16 <Cheery> I think I could catch this from gas and copy&paste it into an instruction. :)
12:35:18 <crc> : jump [ $c389 2, $ad 1, $e3 1, ] ;
12:35:26 <crc> ( addr -- )
12:36:25 <Cheery> thank you!
12:36:29 <crc> np
12:47:30 <Cheery> crc: thought that doesn't seem to work. :/
12:47:39 <Cheery> in rxforth
12:48:10 <Cheery> Or then I mess up something
12:52:19 <crc> macro: jump $c389 2, $ad 1, $e3ff 2, ;
12:52:33 <crc> sorry, I messed up on the "jump ebx" encoding
12:53:42 <Cheery> We all make mistakes.
12:54:31 <Cheery> works excellent now. :)
12:55:23 <lukeparrish> kc5tja is describing test-driven development to me in ##forth. :)
12:55:39 <Quartus> I recommend test-driven development.
12:56:01 <Cheery> Quartus: explain test-driven development for me.
12:56:33 <Cheery> or lukeparrish, is kc5tja describing it now?
12:56:35 <crc> macro: call2jump here 5 - dup c@ 1+ swap c! ;   ( change the CALL prior to this to a JUMP )
12:56:36 <lukeparrish> yeah, it seems like a very good approach. of course, in forth you test your words in the interpreter a lot. 
12:56:49 <lukeparrish> he just described a bunch of stuff about it
12:56:49 <Quartus> The goal is to write code that works.  You code a test-case first, and then write code to fulfill the test condition.
12:57:05 <Cheery> hmmm.
12:57:28 <Cheery> Another friend of mine also recommended for doing something like this. :P
12:57:41 <Cheery> but he talked about unit tests.
12:58:07 <lukeparrish> right, that's what he's explaining :)
12:58:25 <Cheery> I've heard that's art to make good test cases.
12:58:29 <Quartus> Unit tests are the same thing, but with a lower-resolution.  I write a test line for each Forth word, right inline, with a  {{ word -> result }} syntax.  It's automatic regression testing on each compile.
12:58:33 <lukeparrish> he made a piece of software called CUT, C unit tester. http://www.falvotech.com/content/cut/
12:58:52 <Quartus> With Forth you don't need test scaffolding, which makes it very easy.
12:59:35 <Cheery> hmm.
12:59:48 <Cheery> Quartus, that sounds intresting.
13:00:16 <Quartus> Test cases aren't hard to write.  If you find you haven't tested sufficiently to find a bug, add a test-case and carry on.  The idea isn't to somehow write brilliant test-cases that catch every bug; it's to install in-line sanity checks, and then to confirm that bugs are removed and stay removed.
13:01:00 <Cheery> How do you use your test cases?
13:01:05 <Quartus> What do you mean?
13:01:21 <Cheery> or wait.
13:01:38 <Cheery> it's done on each compile...
13:01:59 <Raystm2> You don't have to do it on _each_ compile.
13:02:10 <Quartus> : add3 ( n1 -- n2 ) 3 + ;    {{ 5 add3 -> 8 }}  {{ -1 add3 -> 2 }}  {{ 0 add3 -> 0 }}
13:02:13 <Quartus> oops
13:02:26 <Quartus> you see the last test-case is wrong, and it throws an error.
13:02:34 <Cheery> Hm. that doesn't seem really hard to implement.
13:02:41 <Quartus> Right. It's trivial.
13:03:20 <Cheery> Quartus, but it means tested words must be using functional approach.
13:03:42 <Cheery> or does they?
13:05:02 <Quartus> No, you can test whatever you like... I tested a CRC checksum module with     create data ..., ..., ...,   {{ data 3 crc -> 12ab34cd }}
13:05:15 <lukeparrish> nice!
13:05:25 <Quartus> The {{ -> }} just confirm that whatever you've got on the left of the arrow results in whatever's on the right.
13:05:37 <Cheery> but that doesn't need {{ and }} at all?
13:05:44 <Cheery> the arrow can do all the job?
13:05:52 <lukeparrish> I imagine it makes it easier to read
13:06:16 <Quartus> No, you need a far-end word to figure out where to stop.  Plus, you can alias {{ to \ and thereby skip the tests if you wish.
13:06:50 <Quartus> Consider  {{ 23 7 /mod -> 2 3 }}
13:07:07 <lukeparrish> so this allows you to do more than one stack elements
13:07:11 <Quartus> Right.
13:08:00 <lukeparrish> so forth lets you easily comment out all the tests in one blow. nifty.
13:08:12 <Quartus> I don't, but you could, yes.
13:08:40 <Quartus> Once I've completed a module I move the tests into their own file.
13:10:28 <Cheery> Hmm.
13:10:32 <Cheery> Seems reasonable to implement.
13:10:55 <Quartus> I tested an encryption routine with    create data ..., ..., ...,  create encrypted ..., ..., ...,  {{ s" keyword" encryption-key -> }} {{ data 3 encrypt -> }} {{ data 3 encrypted 3 compare -> 0 }}
13:11:31 <Quartus> (larger block size than 3, mind you, but you get the idea)
13:11:49 <Cheery> So {{ -> }} is like a test that certain thing gives certain results?
13:11:56 <Quartus> Right.
13:13:03 <Quartus> If it fails, you get either an error that the results do not match, or that there's the wrong number of results.
13:13:15 <Cheery> in rxforth it actually does need only vectoring the .data :) between -> and }}, so it requires four words to implement.
13:13:58 <Quartus> You need about four words to do it in Standard Forth, with no vectoring required.
13:14:33 <Quartus> It's not my idea -- it's based on John Hayes' tester.fs stuff.  I've written my own variant.
13:14:50 <Quartus> tester.fs what coretest.fs is based on.
13:16:00 <Cheery> I think I'll implement my own too, thought I consider to leave the tests inside file.
13:16:04 <Quartus> Quartus Forth has over a thousand such tests that I run automatically as a key part of the regression testing, on every modification of the kernel or library code.
13:16:17 <crc> Cheery: http://retroforth.net/paste/?id=248 is a port for RxForth 1c
13:17:00 <Quartus> Yes, that's pretty much a transliteration of Hayes' code.
13:17:37 <Cheery> kewl, then I don't need to even implement one, I can just use one. :)
13:17:41 <crc> Cheery: it needs the 1c preview 4 release
13:17:59 <crc> http://groups-beta.google.com/group/rxforth/web/1c_preview4.tar.gz
13:18:11 <Quartus> I did some refactoring and added a {{ -> }} test to the test code itself. :)
13:18:14 <Cheery> I have it. ;)
13:18:20 <crc> good
13:18:25 <Cheery> I've keeped my rxforth updated the whole time.
13:19:28 <Quartus> Nothing wrong with keeping your tests in application-level code.  It's library modules that move the tests out of, as some of the tests take several seconds to run, and I don't want them running every time I include the module.
13:19:30 <crc> the preview4 was just uploaded tdoday
13:23:40 <Cheery> aah.
13:23:59 <Cheery> I think you forgot to update the namestring.
13:25:36 <Cheery> There are new iterate and other stuff and if thens are away... but namestring still says it's preview 3 ;)
13:26:08 <crc> probably I did :)
13:27:12 <crc> I replaced the uploaded version with a corrected one
13:34:43 --- join: nighty__ (n=nighty@sushi.rural-networks.com) joined #retro
13:46:33 --- quit: nighty_ (Read error: 110 (Connection timed out))
13:57:58 --- quit: Cheery ("Download Gaim: http://gaim.sourceforge.net/")
14:09:35 <lukeparrish> crc: I'm having problems with parse in rxforth
14:10:19 <crc> example?
14:10:26 <lukeparrish> anything I call it with it seems to crash
14:10:31 <lukeparrish> '_ parse
14:10:44 <lukeparrish> it doesn't crash until you try and do something on the next line
14:11:17 <lukeparrish> hmm. maybe it's not parse, but '
14:11:27 <crc> that works for me...
14:11:45 <crc> .s is broken in preview4, but everything else seems to work 
14:12:27 <lukeparrish> hmm. .s is what I'm trying to do, maybe that's it
14:12:57 <lukeparrish> ok. .s only crashes when something is on the stack, apparently
14:20:24 <crc> http://groups-beta.google.com/group/rxforth/web/1c_preview5.tar.gz
14:20:28 <crc> this has a fixed .s
14:23:09 <lukeparrish> cool
14:41:39 <crc> would you like me to send on a copy of my code for Toka?
14:44:25 --- join: Quartus_ (n=Quartus_@209.167.5.2) joined #retro
17:42:06 --- log: started retro/06.11.05
17:42:06 --- join: clog (n=nef@bespin.org) joined #retro
17:42:06 --- topic: 'RetroForth | Pastebin @ http://retroforth.net/paste | The editing key is 'despair''
17:42:06 --- topic: set by ChanServ on [Thu Nov 02 05:51:04 2006]
17:42:06 --- names: list (clog jas2o Quartus_ Snoopy42 Shain neceve @lukeparrish @Raystm2 Quartus @crc timlarson nighty @ChanServ)
17:56:02 * crc continues working on commenting the functions
19:14:59 <lukeparrish> toka is very cool :)
19:20:58 <crc> glad you like it
19:22:15 * lukeparrish is reading the sources now
19:22:20 <crc> I've compiled it on an emulated DECstation 5000 under NetBSD (MIPS processor) and it works nicely
19:22:30 <lukeparrish> very nice to see the descriptions in the code like that.
19:22:35 <crc> I like it
19:22:53 <lukeparrish> is that essentially what literate programming is?
19:22:56 <crc> makes pulling out the documentation (doc/GLOSSARY and doc/FUNCTIONS( easy
19:23:11 <crc> literate programming goes a bit further, but it's similar
19:23:22 <lukeparrish> cool
19:23:54 <Quartus> Literate programming is more than just verbose commenting -- it lets you write the program in any order that explains it best, and then there's software that untangles that into the right order for the compiler.
19:25:54 <lukeparrish> ah, so that's it
19:26:10 * crc has only had brief encounters with literate programming
19:26:34 <Quartus> And there's usually some way to pretty up the documentation.  Markup.
20:26:06 <Quartus> Cross-references, too. Hyperlinked, nowadays.
21:46:27 --- join: forther (n=forther@c-67-180-209-27.hsd1.ca.comcast.net) joined #retro
21:46:41 --- part: jas2o left #retro
22:01:27 --- join: Raystm2- (n=NanRay@adsl-68-95-251-145.dsl.rcsntx.swbell.net) joined #retro
22:05:08 --- join: Cheery (n=Cheery@a81-197-19-23.elisa-laajakaista.fi) joined #retro
22:18:33 --- quit: Raystm2 (Read error: 110 (Connection timed out))
23:03:01 <Cheery> crc, in preview 4, .s has stopped working.
23:03:07 <Cheery> try 1 2 3 .s
23:09:44 <crc> lukeparrish caught that
23:09:52 <crc> a preview5 is up with a fixed .s
23:28:12 <Cheery> good, it fixed.
23:59:59 --- log: ended retro/06.11.05