I'm not a C expert by any means, but I'll certainly give it a look, and see if it's within my capabilities. I'm more of a joat when it comes to programming languages, I know 2 dozen+ languages, but that knowledge is generally only enough to build simple programs from scratch, and to hack existing code to do what I need. On the other hand, I do know several of those pretty well, and of course prefer to work in those languages when possible, but I'm a strong believer in using the best language for the job, which sometimes gets me in trouble, since the best language may not be one I know the best, so work takes longer, but I honestly believe it turns out to be a better product when all is said and done.
It's quite a bit of fun determining what language fits best sometimes.
But, as usual, I digress. I'll grab the prop forth today, and dig into it to see how much it'll take to work on the conversions. I'd wager it won't be much effort to do the translation, since it sounds like a quick and simple job, but looks often are deceiving as folks here well know.
PB, it sounds like the GO compiler doesn't like something in your source file. I think that message is basically, "I got to line 2, column 1 and didn't find the keyword package." This sounds like a cut/paste format problem copying the source to the linux box.
It complains differently if it can't find the packages to import.
If your GOROOT points to the correct directory (where you installed it), GO should be able to find everything.
I pretty sure go is a standalone package....but I can't test that since all of my Linux boxes (even the BeagleBone) have gcc installed as part of the distribution.
Thanks for looking into this. Everything seems to check out yet it still doesn't work. Sal suspected something is different in the ways the serial driver is handled, which may indicate the serial.a needs to be recompiled.
If I install gcc will the OS detect the module need recompile? Sounds magic.
I am developing a PropForth robot control application for the Eddie robot platform. I have a question concerning the encoders. My problem is that the required serial communication with the encoders uses only one pin, i.e., the Tx & Rx pins are identical. This is not a problem if one is using any of the spin serial objects, since there are separate Tx and Rx methods. Is there a way to use the PropForth serial word to do this?
concerning the encoders. serial communication .. using only one pin, i.e., the Tx & Rx pins are identical.
Is there a way to use the PropForth serial word to do this?
Okey Doky. Just got off the call with Sal. As always, he says this is simple.
Here are two ways, depending on how fast it needs to run. We looked at the Eddie material briefly, and it did not appear to contradict the solution, but we did not check it thoroughly or test, so here goes.
In general: The Propforth serial is buffered, so if the same pin is used for Tx and Rx, all the chars you send are echoed to input.
Throw those characters away, wait a couple character times, and start listening. So the stock serial driver can be used.
Or write a separate forth word: If the speed is low enough, just write a simple serial driver in forth. Probably up to 115200 baud should work.
To send a character: given the bit rate
- put the character's first bit on the pin
- waitcnt
- put the next bit on the pin
- waitcnt
- etc
To receive a character:
- wait pin equals
-waitcnt
- get pin
- waitcnt
- etc
Only thing is, if the other end doesn't send a character, you end up waiting forever, so you might have to do something about that. A lot depends on timing.
Let us know if you have any luck with this, or if any problems come up. I imagine this will be something lots of folks run across.
PB, it sounds like the GO compiler doesn't like something in your source file. I think that message is basically, "I got to line 2, column 1 and didn't find the keyword package."
If your GOROOT points to the correct directory (where you installed it), GO should be able to find everything.
I pretty sure go is a standalone package....but I can't test that since all of my Linux boxes (even the BeagleBone) have gcc installed as part of the distribution.
We'll get thsi figured out somehow!
OK BIG progress today, but still a little short of the mark.
All I had to do was use yum to install gcc as superuser
sudo yum install gcc
...wait some time...
56m
Is this size ok? Y
...wait some time...
Complete!
cd <go directory>
su
go install goterm
go install gomuxterm
I changed the .bashrc back to the simple settings and was able to compile (install)
If I connect at 115200, it connects but of course shows garbage characters.
VERY NEARLY THERE!
So how to I tell the OS the 230400 is a valid baud? 230400 works on the windows installs, and on Rick's linux, and 230400 just works with minicom on OLPC; so I think there is something in the serial code gcc is compiling ( src/serial.a) that needs update.
I never tried 230400 with goterm/gomuxterm on my Linux system until this morning - it didn't work either.
But have no fear!! I fixed it!
You need to update the code in linux_serial.go to support 230400. (to be completely correct, you should update the .go file in src/linux_serial and then copy it to /src/serial)
The windows code is different and doesn't have the switch/case for baud rates.
old code:
if err == nil {
switch baud {
case 115200:
speed = C.B115200
case 57600:
speed = C.B57600
case 19200:
speed = C.B19200
New code:
if err == nil {
switch baud {
case 230400:
speed = C.B230400
case 115200:
speed = C.B115200
case 57600:
speed = C.B57600
case 19200:
speed = C.B19200
just add another case to the switch statement.
When done, make sure the updated linux_serial.go gets copied into src/serial and the do an install on goterm and gomuxterm. It should recognize 230400 at this point. Mine did.
Unfortunately, the data I collected shows I completely misunderstand whats going on here.
It appears the OLPC-XO at 433Mhz over wireless Ethernet running 32 channels
has better throughput that the E6750 at 3.4Ghz over wired Gigbit ethernet running 1 channel.
I don't see how a toy laptop does better than an overclocked desktop gaming rig. I thought the max could be 2000 characters per second, and the number larger than this we due to the ways the tests were run. Is the actual limit (BAUD/10) cps? Could the very high number be due to linux, or wireless?
I may have to load ubuntu on a box, and run this again.
Two boxes:
#1 - I5 @ 2.5GHz w/ 4GB RAM running Win7 Professional
#2 - I3 @ 2.4GHz w/ 8GB RAM running Linux (Fedora 16)
both connected to C3 running latest Propforth across a USB serial port at 230400 bits per second configured with 8 channels
local loop connections were used to PropForth (127.0.0.1 4000)
same test were entered at the PropForth prompt
0 5000 t 1 5000 t 2 5000 t 3 5000 t
#1 aggregate throughput for SEND test 15738 characters per second (14.63 bits per char)
#2 aggregate throughput for SEND test 22845 characters per second (10.08 bits per char!)
#2 45% more characters per second
No conclusions, just posting findings.
(Dang! Linux is faster than windows - whoda thunk! )
differences
linux vs Windows (and all associated code and drivers between the USB port and the telnet program connected to the local loop)
linux_serial.go versus windows_serial.go (the code is different but I haven't looked enough to see where they differ)
CPUs
Memory
Rick: Could you please run those both again with 32 channels? 5.3 is going to support 32 channels by default, and the automation is going to use 32 channels, so this is what we are really interested in. The only thing missing is data for 32 channels on quad core for windows and linux.
I'm starting to guess that Fedora on any box is going to be a lot faster than windows on any other box. Which would be really cool, I can set up my old pentium as the test fixture and leave my windows boxes for games, as it should be.
Is anybody running on Apple? I would like numbers for OSX in case it differs from linux. Its supposed to be the same as linux, isn't it?
I think I can. The first 4 can be sends or receives but after that, I believe they all need to be loop backs since I'll be out of COGs if I understand how this works. I'll have to see how the Propforth looks after opening up 32 channels.
I can run numbers on an i7 windows box (4 cores/8 threads), i5 windows box (2 cores/4 threads), i3 (2 cores/4 threads), i5 Mac OS X (currently without GO), AMD 4-core Windows box, linux netbook, windows netbook.....none of them are tainted by games. Oh, if I can get GO running on my Beagle Bone, I can test that too!
OS X is more a BSD Unix than a Linux UNIX - numbers should be similar.
It will probably be Wednesday, earliest, before I can do any in depth testing -- especially the Mac.
I think I can. The first 4 can be sends or receives but after that, I believe they all need to be loop backs since I'll be out of COGs if I understand how this works. I'll have to see how the Propforth looks after opening up 32 channels.
Just open it up the exact same way, you don't change anything except make the 8 into a 32. The only this that changes is the size of the buffer for each channel, this is the effect we are look at.
gomuxterm /dev/ttyUSB0 230400 32 3000 4000 0
Also, it important that you run the exact 8 tests listed, or we the numbers won' t compare well. If you skip the single tests, or do multiple tests on the same line, the numbers come out different.
Continue demonstrating your excellent aptitude at GO, and the fine folks at Google may give you a job. I hear they got money $$$.
Along those lines, if you want extra credit for go programming, here's one for you: Care to add a system call for a date/time stamp to the connect and disconnect message for gomuxterm? And drop the message into a log file? See issue 151 http://code.google.com/p/propforth/issues/detail?id=151
I plan to download the GO book for kindle, but the credit card is messed up won't be sorted until after installing ubuntu and collecting one more linux data set.
[rapost@C3PO go]$ gomuxterm /dev/ttyUSB0 230400 8 3000 4000 0 | tee test.log
20120605-10:15:52.98558 - Using 4 CPUs
Rebooting propeller, try 1
Sending constant definitions:
d_6 wconstant _MX_BSHIFT
d_64 wconstant _MX_BSIZE
d_63 wconstant _MX_BMASK
d_8 wconstant _MX_NUM_CHAN
d_32 wconstant _MX_BUF_OFFSET
Sending code...
Sending start command... Waiting for sync
Starting serial multiplexer
20120605-10:15:58.70647 - Listening on 127.0.0.1:3000
20120605-10:15:58.70658 - Listening on 144.153.98.202:3000
20120605-10:15:58.70682 - Listening on 127.0.0.1:4000
20120605-10:15:58.70692 - Listening on 144.153.98.202:4000
20120605-10:16:06.09964 - New Telnet Connection 127.0.0.1:4000 <--> 127.0.0.1:55926
20120605-10:16:08.20558 - Telnet Connection Closed 127.0.0.1:4000 <--> 127.0.0.1:55926
20120605-10:16:08.20568 - New Control Connection 127.0.0.1:4000 <--> 127.0.0.1:55926
20120605-10:16:12.44813 - Mux Channel 04 Loop Chars/sec: 12393.94
20120605-10:16:25.45962 - Mux Channel 00 Send Chars/sec 13618.08
20120605-10:16:45.11349 - Mux Channel 01 Rec Chars/sec 13167.60
Connecting to 0
20120605-10:16:58.20927 - Control Connection Closed 127.0.0.1:4000 <--> 127.0.0.1:55926
20120605-10:16:58.20937 - New Telnet Connection 127.0.0.1:4000 <--> 127.0.0.1:55926
20120605-10:17:04.52152 - Telnet Connection Closed 127.0.0.1:4000 <--> 127.0.0.1:55926
20120605-10:17:04.52158 - New Control Connection 127.0.0.1:4000 <--> 127.0.0.1:55926
20120605-10:17:08.02110 - Control Connection Closed 127.0.0.1:4000 <--> 127.0.0.1:55926
^C
[rapost@C3PO go]$
It just sends things to stdio for now (classic UNIX).
It also logs the test results to the gomuxterm console as well as the telnet session - you can capture all events at the gomuxterm console now. (yay, me!!)
You can use the unix tee command to send stdio to a file and the console:
a copy of test.log attached for your enjoyment. I'll go put the new gomuxterm.go on the wiki since the forum doesn't like *.go files and I don't feel like zipping it!
Copy gomuxterm.go to src/gomuxterm (maybe save the old one) then do 'go install gomuxterm' and you should be able to log to your heart's content.
How about some basic scripting in gomuxterm so you can automate the automator?
I still haven't figured out the deal with 1 channel test (gomuxterm channel configuration parameter =1). As we know, the cog6 buffer is divided into equal size segments depending on the number of channels we want, 32, 16, 8, 4, or 1. When we have 1 channel, the channel gets the whole 1k of cog6 cog ram as the buffer.
BUT the test on the prop side
4 5000 s 5 5000 s 6 5000 s 7 5000 s
is using 4 logical channels. And it still appears to run, although possibly slower than the gomuxterrm 4 channel test.
So whats happening? Are the channels starting off at slightly different times, so even though they are all overwriting each other they are out of the way before the next channel comes along? Or would they be garbling each others data if these were real transmission and not just loop tests?
This test is only for max RATES, next tests will have real transmission. We as developer have to make sure that we have the correct number of channels invoked in relation to channels configured, as the "minimum necessary and sufficient" rule of thumb told us not to put in error checking for this (just yet). Being forth, it allows us to configure one number of channels, and invoke a different number of channels. This may lead to interesting results , or an affect to watch out for.
This afternoon, I found a very basic Forth interpreter written in GO. I had to do some cheating but I got it to compile and run basic arithmetic and stack operations. We now have goforth!!
So, if I look at the gForth code to see how they implement some things....and combine it with goforth....and combine that with gomuxterm......and combine that with a Propeller or two running PropForth....well, this starts to make yoru head spin!!! Forth CAN RULE THE WORLD!!!!
I have a bunch of numbers from gomuxterm adn different combinations of channel counts and stuff. I'm not sure if they mean anything yet or not or point to any sweet spots as far as buffer sizing and channel counts.
This afternoon, I found a very basic Forth interpreter written in GO. I had to do some cheating but I got it to compile and run basic arithmetic and stack operations. We now have goforth!!
Frank Sargeant says all the simplest forth needs is fetch a byte, store a byte, and execute subroutine.
a bunch of numbers from gomuxterm adn different combinations of channel counts and stuff. ... sweet spots as far as buffer sizing and channel counts.
This is going to be interesting. Sal is focusing on sufficient channels for automatied regression testing, such that the entire progess is initiated from a single command and requires NO user intervention. Of course as some point the user has to at least decide it it ran successfully or not, but the goal is zero intervention.
As far as applications go, we definitely will want to determine the best speed given the PC, OS, channels, etc.
So test automation will be first baseline, and then various config will tell us how to determine the sweet spots. Please keep collecting data and recording your findings. These will be very helpful.
It's interesting you should mention this. I recently ran across a language the creater called claw. It has 8 instructions in it inc/dec pointers, inc/dec values, begin/end loop, input and store byte, and print byte.
That's it.
Your mention of what a forth environment needs prompted me to go have another look at this particular language, it looks like an extremely premative forth could very easily be made using this, then we could test that theory.
I have to admit, I'm not very good at assembly, so most of how this language works went by me, (just out of reach, leaving me with the feeling that if I stretch just a bit more, I can get it) but it still looks like a lot of fun.
You can find it at sourceforge http://sourceforge.net/projects/claw/
The interpreter (written in c) comes to a whooping 4k on my osx box, so perhaps this is something that could be ported to the propeller, to add to the list of languages available there, to increase the size of that already amazing number of language implementations.
Anyway, it's an interesting exercise if nothing else.
This afternoon, I found a very basic Forth interpreter written in GO. I had to do some cheating but I got it to compile and run basic arithmetic and stack operations. We now have goforth!!
... I may be shot for asking this ... BUT ... does this mean we should "goForth and multiply" ?????
Comments
It's quite a bit of fun determining what language fits best sometimes.
But, as usual, I digress. I'll grab the prop forth today, and dig into it to see how much it'll take to work on the conversions. I'd wager it won't be much effort to do the translation, since it sounds like a quick and simple job, but looks often are deceiving as folks here well know.
It complains differently if it can't find the packages to import.
If your GOROOT points to the correct directory (where you installed it), GO should be able to find everything.
I pretty sure go is a standalone package....but I can't test that since all of my Linux boxes (even the BeagleBone) have gcc installed as part of the distribution.
We'll get thsi figured out somehow!
If I install gcc will the OS detect the module need recompile? Sounds magic.
I am developing a PropForth robot control application for the Eddie robot platform. I have a question concerning the encoders. My problem is that the required serial communication with the encoders uses only one pin, i.e., the Tx & Rx pins are identical. This is not a problem if one is using any of the spin serial objects, since there are separate Tx and Rx methods. Is there a way to use the PropForth serial word to do this?
NickL
Sent a message to Sal, we can probably get a solution after tomorrow's call.
Okey Doky. Just got off the call with Sal. As always, he says this is simple.
Here are two ways, depending on how fast it needs to run. We looked at the Eddie material briefly, and it did not appear to contradict the solution, but we did not check it thoroughly or test, so here goes.
In general: The Propforth serial is buffered, so if the same pin is used for Tx and Rx, all the chars you send are echoed to input.
Throw those characters away, wait a couple character times, and start listening. So the stock serial driver can be used.
Or write a separate forth word: If the speed is low enough, just write a simple serial driver in forth. Probably up to 115200 baud should work.
To send a character: given the bit rate
- put the character's first bit on the pin
- waitcnt
- put the next bit on the pin
- waitcnt
- etc
To receive a character:
- wait pin equals
-waitcnt
- get pin
- waitcnt
- etc
Only thing is, if the other end doesn't send a character, you end up waiting forever, so you might have to do something about that. A lot depends on timing.
Let us know if you have any luck with this, or if any problems come up. I imagine this will be something lots of folks run across.
OK BIG progress today, but still a little short of the mark.
All I had to do was use yum to install gcc as superuser
I changed the .bashrc back to the simple settings and was able to compile (install)
go install goterm
go install gomuxtem
both completed with no error messages, and it give me the usage message when I type in these at the command line.
NOW the only problem is an INVALID BAUD RATE message.
If I connect at 115200, it connects but of course shows garbage characters.
VERY NEARLY THERE!
So how to I tell the OS the 230400 is a valid baud? 230400 works on the windows installs, and on Rick's linux, and 230400 just works with minicom on OLPC; so I think there is something in the serial code gcc is compiling ( src/serial.a) that needs update.
Any hints?
But have no fear!! I fixed it!
You need to update the code in linux_serial.go to support 230400. (to be completely correct, you should update the .go file in src/linux_serial and then copy it to /src/serial)
The windows code is different and doesn't have the switch/case for baud rates.
old code:
if err == nil { switch baud { case 115200: speed = C.B115200 case 57600: speed = C.B57600 case 19200: speed = C.B19200New code:
if err == nil { switch baud { case 230400: speed = C.B230400 case 115200: speed = C.B115200 case 57600: speed = C.B57600 case 19200: speed = C.B19200just add another case to the switch statement.
When done, make sure the updated linux_serial.go gets copied into src/serial and the do an install on goterm and gomuxterm. It should recognize 230400 at this point. Mine did.
I guess I can add GO to my resume now!!
Opened issue 154 to capture this change
http://code.google.com/p/propforth/issues/detail?id=153
I need to grab the updated goterm/gomuxterm source for my Linux box. It looks like I can do performance testing AND my meatloaf sandwich for lunch!!
Unfortunately, the data I collected shows I completely misunderstand whats going on here.
It appears the OLPC-XO at 433Mhz over wireless Ethernet running 32 channels
has better throughput that the E6750 at 3.4Ghz over wired Gigbit ethernet running 1 channel.
I don't see how a toy laptop does better than an overclocked desktop gaming rig. I thought the max could be 2000 characters per second, and the number larger than this we due to the ways the tests were run. Is the actual limit (BAUD/10) cps? Could the very high number be due to linux, or wireless?
I may have to load ubuntu on a box, and run this again.
Two boxes:
#1 - I5 @ 2.5GHz w/ 4GB RAM running Win7 Professional
#2 - I3 @ 2.4GHz w/ 8GB RAM running Linux (Fedora 16)
both connected to C3 running latest Propforth across a USB serial port at 230400 bits per second configured with 8 channels
local loop connections were used to PropForth (127.0.0.1 4000)
same test were entered at the PropForth prompt
0 5000 t 1 5000 t 2 5000 t 3 5000 t
#1 aggregate throughput for SEND test 15738 characters per second (14.63 bits per char)
#2 aggregate throughput for SEND test 22845 characters per second (10.08 bits per char!)
#2 45% more characters per second
No conclusions, just posting findings.
(Dang! Linux is faster than windows - whoda thunk!
differences
linux vs Windows (and all associated code and drivers between the USB port and the telnet program connected to the local loop)
linux_serial.go versus windows_serial.go (the code is different but I haven't looked enough to see where they differ)
CPUs
Memory
I'm starting to guess that Fedora on any box is going to be a lot faster than windows on any other box. Which would be really cool, I can set up my old pentium as the test fixture and leave my windows boxes for games, as it should be.
Is anybody running on Apple? I would like numbers for OSX in case it differs from linux. Its supposed to be the same as linux, isn't it?
I can run numbers on an i7 windows box (4 cores/8 threads), i5 windows box (2 cores/4 threads), i3 (2 cores/4 threads), i5 Mac OS X (currently without GO), AMD 4-core Windows box, linux netbook, windows netbook.....none of them are tainted by games. Oh, if I can get GO running on my Beagle Bone, I can test that too!
OS X is more a BSD Unix than a Linux UNIX - numbers should be similar.
It will probably be Wednesday, earliest, before I can do any in depth testing -- especially the Mac.
Just open it up the exact same way, you don't change anything except make the 8 into a 32. The only this that changes is the size of the buffer for each channel, this is the effect we are look at.
gomuxterm /dev/ttyUSB0 230400 32 3000 4000 0
Also, it important that you run the exact 8 tests listed, or we the numbers won' t compare well. If you skip the single tests, or do multiple tests on the same line, the numbers come out different.
Thanks!
Continue demonstrating your excellent aptitude at GO, and the fine folks at Google may give you a job. I hear they got money $$$.
Along those lines, if you want extra credit for go programming, here's one for you: Care to add a system call for a date/time stamp to the connect and disconnect message for gomuxterm? And drop the message into a log file? See issue 151 http://code.google.com/p/propforth/issues/detail?id=151
I plan to download the GO book for kindle, but the credit card is messed up won't be sorted until after installing ubuntu and collecting one more linux data set.
It just sends things to stdio for now (classic UNIX).
It also logs the test results to the gomuxterm console as well as the telnet session - you can capture all events at the gomuxterm console now. (yay, me!!)
You can use the unix tee command to send stdio to a file and the console:
[rapost@C3PO go]$ gomuxterm /dev/ttyUSB0 230400 8 3000 4000 0 | tee test.log
a copy of test.log attached for your enjoyment. I'll go put the new gomuxterm.go on the wiki since the forum doesn't like *.go files and I don't feel like zipping it!
Copy gomuxterm.go to src/gomuxterm (maybe save the old one) then do 'go install gomuxterm' and you should be able to log to your heart's content.
How about some basic scripting in gomuxterm so you can automate the automator?
**WARNING - This is MORE FUN than the day job! **
I still haven't figured out the deal with 1 channel test (gomuxterm channel configuration parameter =1). As we know, the cog6 buffer is divided into equal size segments depending on the number of channels we want, 32, 16, 8, 4, or 1. When we have 1 channel, the channel gets the whole 1k of cog6 cog ram as the buffer.
BUT the test on the prop side is using 4 logical channels. And it still appears to run, although possibly slower than the gomuxterrm 4 channel test.
So whats happening? Are the channels starting off at slightly different times, so even though they are all overwriting each other they are out of the way before the next channel comes along? Or would they be garbling each others data if these were real transmission and not just loop tests?
This test is only for max RATES, next tests will have real transmission. We as developer have to make sure that we have the correct number of channels invoked in relation to channels configured, as the "minimum necessary and sufficient" rule of thumb told us not to put in error checking for this (just yet). Being forth, it allows us to configure one number of channels, and invoke a different number of channels. This may lead to interesting results , or an affect to watch out for.
This afternoon, I found a very basic Forth interpreter written in GO. I had to do some cheating but I got it to compile and run basic arithmetic and stack operations. We now have goforth!!
So, if I look at the gForth code to see how they implement some things....and combine it with goforth....and combine that with gomuxterm......and combine that with a Propeller or two running PropForth....well, this starts to make yoru head spin!!! Forth CAN RULE THE WORLD!!!!
I have a bunch of numbers from gomuxterm adn different combinations of channel counts and stuff. I'm not sure if they mean anything yet or not or point to any sweet spots as far as buffer sizing and channel counts.
Frank Sargeant says all the simplest forth needs is fetch a byte, store a byte, and execute subroutine.
http://pygmy.utoh.org/3ins4th.html
If it can do that, then it can be used to create a new version of itself. But I always leave they to somebody smart.
This is going to be interesting. Sal is focusing on sufficient channels for automatied regression testing, such that the entire progess is initiated from a single command and requires NO user intervention. Of course as some point the user has to at least decide it it ran successfully or not, but the goal is zero intervention.
As far as applications go, we definitely will want to determine the best speed given the PC, OS, channels, etc.
So test automation will be first baseline, and then various config will tell us how to determine the sweet spots. Please keep collecting data and recording your findings. These will be very helpful.
That's it.
Your mention of what a forth environment needs prompted me to go have another look at this particular language, it looks like an extremely premative forth could very easily be made using this, then we could test that theory.
I have to admit, I'm not very good at assembly, so most of how this language works went by me, (just out of reach, leaving me with the feeling that if I stretch just a bit more, I can get it) but it still looks like a lot of fun.
You can find it at sourceforge
http://sourceforge.net/projects/claw/
The interpreter (written in c) comes to a whooping 4k on my osx box, so perhaps this is something that could be ported to the propeller, to add to the list of languages available there, to increase the size of that already amazing number of language implementations.
Anyway, it's an interesting exercise if nothing else.
... I may be shot for asking this ... BUT ... does this mean we should "goForth and multiply" ?????
(Oh no, see what happens when we start getting "quippy")
The downward spiral has begun, the natives are restless! Only a new release can save this thread now!
Groan....
I'm pretty sure this violates a forum rule somewhere, or at least it should.
OBC
Here, we'll write it in secret code and nobody will know:
: goforth* go forth * dup . ; ( -- n1 )