Menu
▾
▴
amforth-devel
|
From: pix <pi...@te...> - 2007-03-02 05:57:18
|
hi, i've just been working on a python script to upload forth source files to amforth. it watches the character echo to do a kind of software flow control, and waits for a prompt after each line. to test it with different inputs, i've been using the files in blocks, and when i hit blocks/interrupts.frt i ran into what i think is a parser bug in amforth. when given a long sequence starting with a right bracket, after hitting enter, amforth basically goes crazy and needs to be reset. it gets triggered by the first line of blocks/interrupts.frt: ( make noop the default interrupt word ) as a test i made a file of different length leftbracket sequences: > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ok > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ok > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ok > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ok > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >^[[?1;2c^[[?1;2c the stuff at the end is amforth going squirrely and confusing my terminal. here is the same test but with closed bracket sequences: > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ) ok > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ) ok > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ) ok > ( xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ) okøø ^[[?1;2c as you can see it doesn't matter if you close the sequence or not. this is with amforth 1.3 pix. |
|
From: Matthias T. <mt...@we...> - 2007-03-02 06:39:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pix, > when given a long sequence starting with a right bracket, after hitting > enter, amforth basically goes crazy and needs to be reset. it gets > triggered by the first line of blocks/interrupts.frt: Thanks. The solution is quite simple: Increase PADSIZE in devices/atmega...asm to at least TIBSIZE. Then ( should work if the closing backet is on the same line. Multiline comments still won't work, since the interpreter does not hold the "comment state" over line breaks (like e.g. the compile state). > as you can see it doesn't matter if you close the sequence or not. your xxx are to much and to long That will overwrite internal data structures. Too bad, the atmega does not have virtual memory with page protection ;=) > this is with amforth 1.3 I will document it, so that others may decide if they want to live with short word comments in () or use \. Increasing the default has drawbacks since it needs a lot more of the very short RAM. Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF58Z/Lo3irIddFw4RAvqRAJ4sz8oKSjFj1UAqXynE8ejlT3hdDgCeLlkf Y/50CvLip+PrgEgvNqG+3nY= =5mkh -----END PGP SIGNATURE----- |
|
From: pix <pi...@te...> - 2007-03-02 08:51:16
|
On Fri, Mar 02, 2007 at 06:57:48AM +0100, pix wrote: > i've just been working on a python script to upload forth source files > to amforth. it watches the character echo to do a kind of software > flow control, and waits for a prompt after each line. to test it with > different inputs, i've been using the files in blocks, and when i hit > blocks/interrupts.frt i ran into what i think is a parser bug in > amforth. i took hans' suggestion and made it strip out comments before uploading. it uses a regular expression, so there is the possibility that it will strip out comment-shaped things inside a ." " group, but apart from that it seems to work. the script is here: http://libarynth.fo.am/cgi-bin/view/Libarynth/AmForth#better%20uploading%20with%20python you probably need linux or at least osx to run this. it might also work under windows if it is possible to specify a serial port as a filename (like COM1:). i also have a note on the page about adding backup/restore rules to the makefile, because matthias said this was tricky in an earlier post. pix. |
|
From: Matthias T. <mt...@we...> - 2007-03-08 20:21:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pix, > is there any kind of accepted standard for forth > pre-processor syntax? None I'm aware, but a few users wrote me in PM some wishes: If amforth signals an abort instead of the ok the script should stop uploading. Limit the number of characters sent per second to some adjustable value I've added a link to your site in the FAQ. Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF8HBZLo3irIddFw4RAu7VAKDApeaPBKVWL22fNKwiUPTT/0X/KgCggG+U iIHA90f9sYGN3PdiGCZmyNM= =6UCu -----END PGP SIGNATURE----- |
|
From: pix <pi...@te...> - 2007-03-08 23:20:12
|
On Thu, Mar 08, 2007 at 09:21:45PM +0100, Matthias Trute wrote: > Hi Pix, > > > is there any kind of accepted standard for forth > > pre-processor syntax? > > None I'm aware, but a few users wrote me in PM some wishes: would it be to ugly to have the script implement "INCLUDE" and "INCLUDE?" on it's side? > If amforth signals an abort instead of the ok the script should stop > uploading. do you mean, any of the error messages starting with "??" ? > Limit the number of characters sent per second to some adjustable value hmmm. doable i guess. i was wondering, would there be any value in sending a few more characters than have been echoed back? is there any kind of buffer? i was thinking the script at the moment might be too cautious. i noticed it's also possible to add the script as an upload protocol in minicom. you need to set the -f option so that it doesn't check to see who else has the tty open. > I've added a link to your site in the FAQ. oh, thanks. pix. |
|
From: Matthias T. <mt...@we...> - 2007-03-09 08:01:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pix, > would it be to ugly to have the script implement "INCLUDE" and > "INCLUDE?" on it's side? I see no other place to implement it. If amforth sees these instructions it will abort. >> If amforth signals an abort instead of the ok the script should stop >> uploading. > > do you mean, any of the error messages starting with "??" ? Yes. >> Limit the number of characters sent per second to some adjustable value > > hmmm. doable i guess. > > i was wondering, would there be any value in sending a few more > characters than have been echoed back? is there any kind of buffer? there are two buffers: usart receive buffer (16 characters long) and the forth TIB (80 characters). Only the characters in the TIB had echos back to the serial line (except some control characters). The usart buffer keeps the "unread" characters that wait for the next execution of key. I'm not fully satisfied with it but it works "good enough", at least for me.... > i was thinking the script at the moment might be too cautious. That's impossible ;=) Bye Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF8RRULo3irIddFw4RAhGlAJwMSYRYj410g+2M/zfsLqC6HI93eQCgyc9c 6Tg4X0S92vVOpRa7r2sESSg= =comk -----END PGP SIGNATURE----- |
|
From: pix <pi...@te...> - 2007-03-09 12:30:14
|
On Fri, Mar 09, 2007 at 09:01:24AM +0100, Matthias Trute wrote: > Limit the number of characters sent per second to some adjustable > value actually, why would this be necessary? has anyone encountered the buffers getting overloaded with the echo-tracking flow control scheme? if you just want to send characters slowly, there is pv, and ascii-xfr (comes with minicom, alows separate character/line delays). the idea of amforth-upload was to upload as fast as possible without overloading amforth. .. and timing is a pain to implement ;) pix. |
|
From: Matthias T. <mt...@we...> - 2007-03-09 12:22:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 pix schrieb: > On Fri, Mar 09, 2007 at 09:01:24AM +0100, Matthias Trute wrote: >> Limit the number of characters sent per second to some adjustable >> value > > actually, why would this be necessary? has anyone encountered the > buffers getting overloaded with the echo-tracking flow control scheme? As I wrote: Those are wishes other users wrote to me, maybe not related directly with your tool. personally I think that your scheme is quit good, I cannot imagine how it can overload the amforth buffers (I do hope that someday a "real" flow control will work). Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF8VGQLo3irIddFw4RAtK5AJ9x5Gm1J8D0o8OYwQSZbR3DOR3qIQCfSUHz rAdiWuJH9SbKcLS6ddNf4NA= =Tu15 -----END PGP SIGNATURE----- |
|
From: pix <pi...@te...> - 2007-03-02 16:18:13
|
On Fri, Mar 02, 2007 at 04:45:56PM +0100, Matthias Trute wrote: > > i took hans' suggestion and made it strip out comments before > > uploading. it uses a regular expression, so there is the > > possibility that it will strip out comment-shaped things inside a ." > > " group, but apart from that it seems to work. > > Cool stuff. Can you add an include statement? That could simplify > greater uploads or rebuilds. good idea. is there any kind of accepted standard for forth pre-processor syntax? actually, since the script can read from the commandline, you could do include with m4 or cpp. pix. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X