amforth-devel — Development discussion and user support

Re: [Amforth] amforth-shell.py bugfix

[Rafael G. <ast...@ya...>]

Other  interesting papers by the same author
http://www.holonforth.com/holon/papers/ef89.htm

http://www.holonforth.com/holon/papers/ef94.htm

http://www.holonforth.com/holon/papers/ef95.htm



________________________________
 De: Rafael Gonzalez <ast...@ya...>
Para: Everything around amforth <amf...@li...> 
Enviado: Martes 23 de abril de 2013 12:01
Asunto: Re: [Amforth] amforth-shell.py bugfix
 


I think the python script is becoming more and more complex.

Maybe it is the time to switch to an umbilical-like system.

For that, a new tool is needed and HolonU may be what your are looking for.
http://www.holonforth.com/new/holon.html


Probably you can attach a communication backend to the target system

See the tool history and use case using an old stlye Text User Inetrface in DOS
http://www.holonforth.com/using.htm


This is one of the developments that has impacted me most

Greetings
Rafael



________________________________
 De: Matthias Trute <mt...@we...>
Para: Everything around amforth <amf...@li...> 
Enviado: Sábado 20 de abril de 2013 9:30
Asunto: Re: [Amforth] amforth-shell.py bugfix
 

Hi Hannu,

> Take words and see them all. Produce dot file and make callgraph or
> wordgraph. Anyway to see what gets used where and in which order.

Crazy. I think, a real forth interpreter with a modified code generator
(like the debugger in amforth) would be easier to use than a python
based heuristic parser that does not understand forth. Maybe gforth
is a better place to start with.

Matthias


------------------------------------------------------------------------------
Precog is a next-generation
 analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] amforth-shell.py bugfix

[Rafael G. <ast...@ya...>]

I think the python script is becoming more and more complex.

Maybe it is the time to switch to an umbilical-like system.

For that, a new tool is needed and HolonU may be what your are looking for.
http://www.holonforth.com/new/holon.html


Probably you can attach a communication backend to the target system

See the tool history and use case using an old stlye Text User Inetrface in DOS
http://www.holonforth.com/using.htm


This is one of the developments that has impacted me most

Greetings
Rafael



________________________________
 De: Matthias Trute <mt...@we...>
Para: Everything around amforth <amf...@li...> 
Enviado: Sábado 20 de abril de 2013 9:30
Asunto: Re: [Amforth] amforth-shell.py bugfix
 

Hi Hannu,

> Take words and see them all. Produce dot file and make callgraph or
> wordgraph. Anyway to see what gets used where and in which order.

Crazy. I think, a real forth interpreter with a modified code generator
(like the debugger in amforth) would be easier to use than a python
based heuristic parser that does not understand forth. Maybe gforth
is a better place to start with.

Matthias


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Interrupt Handlers

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

>> After receipt of a data buffer from a certain communication euipment I
>> want to lanuch immediately a processing activity, i.e., right from the
>> ISR and not wait for a round robin task to visit.
>
> You can implement a priority task scheduler as well. PAUSE is not the
> ultimate tool for everything ;)

Hello Matthias,

The Kiss Principle <http://en.wikipedia.org/wiki/KISS_principle> is my
guiding light. I will not introduce cooperative, pre-emptive, etc.
multitasking if I can solve a problem using simpler means. I will report
to this forum how well my approach succeeds, or fails ;-)

By the way, did you have an opportunity to look at MARKER? I think it
does not preserve well wordlist order. It's non-trivial code so just if
you don't have time for this now I'll have a go at it myself.

Regards, Enoch.

Re: [Amforth] Soft Interrupt Handlers

[Matthias T. <mt...@we...>]

Hi Enoch,

> My editor (Emacs) apologizes. It does not like your asm code
> indentation. Which one do you use, BTW.

Uhm. my own one. And a different one for each file. Probably. ;)

> 
> > Second: Your patch steps behind what amforth has already
> > solved years ago: If an interrupt source has to be cleared
> > *within* the ISR, it will block the controller with your new code
> 
> In my soft interrupts handling scheme I am interested in Atmel's type I
> interrupts only. They are described by Atmel as follows:
> 
> """
> There are basically two types of interrupts. The first type is
> triggered by an event that sets the interrupt flag. For these
> interrupts, the Program Counter is vectored to the actual Interrupt
> Vector in order to execute the interrupt handling routine, and *hardware
> clears the corresponding interrupt flag*.
> """
> 
> The other type, like the USART, does need special asm code. Your serial
> driver is a case in point.

And this is the major concern I have with your patch. I dont like the idea
of having two different interrupt handlers for subtle different interrupt
classes. In your notation, all amforth interrupts a first level interrupts.
May I suggest, that you implement the second level interrupts just like
they are described in the wikipedia: as a thread for the multitasker (see 
below).

I should re-write the usart handler with forth code instead of the assembler,
nobody seem to believe me that it will work ;)

> > I once spent a lot of time to deal with the reasons. I wrote
> > a small article for the German Forth Group, unfortunatly (for you)
> > in German. It seems, I should translate it into (my version of) English
> > ASAP. There I explain the current interrupt handling in more detail.
> 
> Google Translate does magic, please forward a link.

http://www.forth-ev.de/repos/vd/2011-02/Interrupts.tex

> Note that there is an overflow mark. If the developer encounters hard
> interrupts overflow he should increase this queue size (or check up his
> code). This can be done through some asm .equ convenience.

IMHO a little too late. The interrupt was lost.

> Did you really try it, i.e., reenabling interrupts within an ISR?  You
> do it and your 'intcur' gets crushed.

Its difficult to test. The program flow indicate that it should
work: An interrupt occures. The current interrupt handler sets
the T flag and the program flow continues. Soon after the
forth VM is entered and detects the T flag. Everything with
disabled further interrupts so far. The inner interpreter immediately calls
the forth-ISR and both the T-flag and the curint information
is no longer needed for the whole forth ISR word. Thats why I
think that that re-enabling interrupts within the Forth-ISR is
safe and does not cause any trouble. The only place that IMHO
may be casue trouble is the final ISR-END which calls RETI.
That may have to be expanded to something that checks the
GIE flag to either call RETI (if set) or a simple RET (if cleared).
But my impression is, that RETI is smart enough to handle
both cases itself. I should re-read the datasheets ;)
 
> After receipt of a data buffer from a certain communication euipment I
> want to lanuch immediately a processing activity, i.e., right from the
> ISR and not wait for a round robin task to visit.

You can implement a priority task scheduler as well. PAUSE is not the
ultimate tool for everything ;)

Matthias

Re: [Amforth] amforth-shell.py bugfix

[Matthias T. <mt...@we...>]

Hi Hannu,

> Take words and see them all. Produce dot file and make callgraph or
> wordgraph. Anyway to see what gets used where and in which order.

Crazy. I think, a real forth interpreter with a modified code generator
(like the debugger in amforth) would be easier to use than a python
based heuristic parser that does not understand forth. Maybe gforth
is a better place to start with.

Matthias

Re: [Amforth] Soft Interrupt Handlers

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:
>> I hope that you would be interested in the following AmForth
>> development. I will send you the patch under a separate cover.
>
> I am interested. And regardless what you think of what
> follows, I appreciate your work.
>  
>> http://pastebin.com/sDGsKjhb

Hello Matthias,

I can assure you that I am "ego-less" as far as AmForth is concerned. I
invite criticism, in fact, being ignored would be more painful.

> A few remarks: Your patch include some pseudo changes to
> files that are not really changed (e.g. amforth-interpreter
> with some whitespace changes). I was slightly puzzeled wether
> I mis-read the patch until I was sure, that the changes are
> purely cosmetic. changing the r0 to temp0 is something very
> close.

My editor (Emacs) apologizes. It does not like your asm code
indentation. Which one do you use, BTW.

> Second: Your patch steps behind what amforth has already
> solved years ago: If an interrupt source has to be cleared
> *within* the ISR, it will block the controller with your new code

In my soft interrupts handling scheme I am interested in Atmel's type I
interrupts only. They are described by Atmel as follows:

"""
There are basically two types of interrupts. The first type is
triggered by an event that sets the interrupt flag. For these
interrupts, the Program Counter is vectored to the actual Interrupt
Vector in order to execute the interrupt handling routine, and *hardware
clears the corresponding interrupt flag*.
"""

The other type, like the USART, does need special asm code. Your serial
driver is a case in point.

> I once spent a lot of time to deal with the reasons. I wrote
> a small article for the German Forth Group, unfortunatly (for you)
> in German. It seems, I should translate it into (my version of) English 
> ASAP. There I explain the current interrupt handling in more detail.

Google Translate does magic, please forward a link.

> Basically your patch is the old interrupt handling plus queue (A solution
> I once considered too, btw.)

What I implemented is called SLIH (second level interrupt handling). It
exists in all operating systems. I don't consider myself an inventor at
all here.

> Third: What makes you sure that a queue with 8 entries
> can do the job? The code comments indicate, that you're
> not that sure yourself. The default action "Drop the interrupt"
> is IMHO the worst solution.

Note that there is an overflow mark. If the developer encounters hard
interrupts overflow he should increase this queue size (or check up his
code). This can be done through some asm .equ convenience.

> And finally: What exactly is the use case of having a reentrant
> interrupt service routine? In my understanding of interrupts, this
> is a situation, that must be avoided at any price. e.g. it does not
> make much sense to process a character from the usart if the
> previous one is not already processed. Or to stack timer events.

This is what Wikipedia says about the purpose of SLIH:

"""
A SLIH completes long interrupt processing tasks similarly to a
process. SLIHs either have a dedicated kernel thread for each handler,
or are executed by a pool of kernel worker threads. These threads sit on
a run queue in the operating system until processor time is available
for them to perform processing for the interrupt. SLIHs may have a
long-lived execution time, and thus are typically scheduled similarly to
threads and processes.
"""

FLIH (first level interrupt handlers) and SLIH (second level interrupt
handlers) were already introduced in the old IBM mainframe days.

> Re-enabling interrupts within the current ISR is no big deal. Just
> call +INT and you're done. New interrupts will arrive as they they
> are triggered.

Did you really try it, i.e., reenabling interrupts within an ISR?  You
do it and your 'intcur' gets crushed.

After receipt of a data buffer from a certain communication euipment I
want to lanuch immediately a processing activity, i.e., right from the
ISR and not wait for a round robin task to visit.

By the way, it's okay to have different opinions. We already read our
stacks (".s") in different order :-)

>> P/S It includes some unrelated (though desired) stuff such as cinvert to
>> complement a byte, etc.

> There are many word that can be implemented in assembly as well.
> A theoretical use case doesn't convince me. A cinvert could be a 
> factor for invert ;)

cinvert is indeed not important by Rafael's u2/ is!

Regards, Enoch.

Re: [Amforth] amforth-shell.py bugfix

[Hannu V. <vu...@ms...>]

> To: amf...@li...
> From: ix...@ho...
> Date: Fri, 19 Apr 2013 18:51:09 -0400
> Subject: Re: [Amforth] amforth-shell.py bugfix

> I have two more developments planned for the shell, one easy -- one
> tough... The tough one I mentioned already, which is, use a library like
> PyUSB to control the popular JTAG Mk II ICE the Forth way.

And here is one idea just for fun. I thought I'll tackle this but I don't have time to learn python.

Take words and see them all. Produce dot file and make callgraph or wordgraph.
Anyway to see what gets used where and in which order.

#dot-tree for all and #dot-word for one word. 

It might be also useful for optimizing stuff.
: bar blob urf xyz ;
: baz asd = if blob then urf ;

The diagram will show that you need refactoring.

This is hand written to get a idea.

digraph foo{
  node [shape = record];
  bar [label="bar|<f0> blob|<f1> urf|<f2> xyz"];
  baz [label="baz|<f0>asd|<f1> if|<f2> blob|<f3> then|<f4> urf"];
  blob;
  urf;
  xyz;
  asd;
  if;
  blob;
  then;
  urf;
  bar:f0 -> blob;
  bar:f1 -> urf;
  bar:f2 -> xyz;
  baz:f0 -> asd;
  baz:f1 -> if;
  baz:f2 -> blob;
  baz:f3 -> then;
  baz:f4 -> urf;
}

Yes. I like to visualize my data.

Best regards,
Hannu Vuolasaho
 		 	   		  

Re: [Amforth] amforth-shell.py bugfix

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi,
>
>> I added an #include-once directive and let it default to "no" (current
>> behavior).  Also added was a program argument to change the default
>> behavior if one so desires [me]. Testing done as well.
>> 
>> http://pastebin.com/5Mfrvzdw
>
> Applied. And Thanks to Keith for discussion. 
>
> btw: I agree with Keith that the shell is a tool to make live
> easier, but I won't make it a must-have tool. 

Let's make it an essential convenience then :-)

I have two more developments planned for the shell, one easy -- one
tough... The tough one I mentioned already, which is, use a library like
PyUSB to control the popular JTAG Mk II ICE the Forth way.

Let's mention the easy one, perhaps we shall have a volunteer coming
up. Let's say we need to send new Forth code to a client to introduce a
new feature or bug fix. The client, unfortunately, cannot be expected to
have a sophiticated uploader tool like our Python based shell. All
he/she has is something akin to minicom (Linux), tera-term (Windows),
etc.

A simple solution is to add a "distiller" mode to the shell where
alongside its normal work it would capture to a file all the characters
uploaded to the SUT (system under test), that is, past name substituion,
past all #include's, etc. The end result would be one compact file which
our client will be able to upload via his simple terminal program.

Anyone?

Regards, Enoch.

Re: [Amforth] Soft Interrupt Handlers

[Matthias T. <mt...@we...>]

Hi Enoch,

> I hope that you would be interested in the following AmForth
> development. I will send you the patch under a separate cover.

I am interested. And regardless what you think of what
follows, I appreciate your work.
 
> http://pastebin.com/sDGsKjhb

A few remarks: Your patch include some pseudo changes to
files that are not really changed (e.g. amforth-interpreter
with some whitespace changes). I was slightly puzzeled wether
I mis-read the patch until I was sure, that the changes are
purely cosmetic. changing the r0 to temp0 is something very
close.

Second: Your patch steps behind what amforth has already
solved years ago: If an interrupt source has to be cleared
*within* the ISR, it will block the controller with your new code

I once spent a lot of time to deal with the reasons. I wrote
a small article for the German Forth Group, unfortunatly (for you)
in German. It seems, I should translate it into (my version of) English 
ASAP. There I explain the current interrupt handling in more detail.

Basically your patch is the old interrupt handling plus queue (A solution
I once considered too, btw.)

Third: What makes you sure that a queue with 8 entries
can do the job? The code comments indicate, that you're
not that sure yourself. The default action "Drop the interrupt"
is IMHO the worst solution.

And finally: What exactly is the use case of having a reentrant
interrupt service routine? In my understanding of interrupts, this
is a situation, that must be avoided at any price. e.g. it does not
make much sense to process a character from the usart if the
previous one is not already processed. Or to stack timer events.

Re-enabling interrupts within the current ISR is no big deal. Just
call +INT and you're done. New interrupts will arrive as they they
are triggered.

> P/S It includes some unrelated (though desired) stuff such as cinvert to
> complement a byte, etc.

There are many word that can be implemented in assembly as well.
A theoretical use case doesn't convince me. A cinvert could be a 
factor for invert ;)

Matthias

Re: [Amforth] amforth-shell.py bugfix

[Matthias T. <mt...@we...>]

Hi,

> I added an #include-once directive and let it default to "no" (current
> behavior).  Also added was a program argument to change the default
> behavior if one so desires [me]. Testing done as well.
> 
> http://pastebin.com/5Mfrvzdw

Applied. And Thanks to Keith for discussion. 

btw: I agree with Keith that the shell is a tool to make live
easier, but I won't make it a must-have tool. 

Matthias

Re: [Amforth] Soft Interrupt Handlers

[Enoch <ix...@ho...>]

Hello Matthias,

I hope that you would be interested in the following AmForth
development. I will send you the patch under a separate cover.

Regards, Enoch.

http://pastebin.com/sDGsKjhb

P/S It includes some unrelated (though desired) stuff such as cinvert to
complement a byte, etc.

[Amforth] Soft Interrupt Handlers

[Enoch <ix...@ho...>]

Hello Matthias,

I hope that you would be interested in the following AmForth
development. I will send you the patch under a separate cover.

Regards, Enoch.

-----------------------------------------------------------------

1 Objective 
------------

One of AmForth features is the ability to write interrupt service
routines (ISRs) in Forth. However, in the existing implementation
as of SVN r1423 those ISRs should run with the hardware interrupt
system (SREG I-bit) disabled. This means that one has to keep
those ISRs very short and defer long processing to the "main"
(aka user mode). The following changes to the kernel introduce an
eight level soft interrupt queue, allowing Forth ISRs to be
interruptible and thus be as slow to execute as necessary (and
even reentrant).

2 Implementation 
-----------------

To the existing +int and -int ("hard front-end") words that
control the SREG I-bit the following ("soft rear-end") words were
added:

2.1 int+  ( -- )  "soft interrupts on" 
=======================================
Enables the soft interrupts. By default soft interrupts are
enabled.

2.2 int-  ( -- )  "soft interrupts off" 
========================================
Disables the soft interrupts.

2.3 int'  ( -- addr )  "soft interrupts apostrophe" 
====================================================

Returns the address of a system variable where the lower byte, if
non zero, indicates the occurance of a hard interrupt
overflow. The overflow mark is the interrupting-device program
address. Clear this mark by: 0 int' c!

The higher byte, if non-zero, indicates having the soft
interrupts inhibited.

3 Compatibility 
----------------

Existing code should not be affected.

[Amforth] Does marker need a bugfix concerning wordlists?

[Enoch <ix...@ho...>]

Hello all,

Please follow me:

> get-order .s                                                                                                                                  
#3 84 20 2  ok                                                                                                                                  

>  words                                                                                                                                        
lulu kuku ->ican ...

removing the marker:

> ->ican                                                                                                                                        
 ok                                                                                                                                             

> words
_initial ... (surprise, my _private wordlist???!!!)

and the reason:

> get-order .s                                                                                                                                  
#3 20 84 2  ok                                                                                                                                  

Can anyone repeat the above?

Thanks, Enoch.

P/S Using the latest SVN revision.
                                                                                                                                           

Re: [Amforth] amforth-shell.py bugfix

[Enoch <ix...@ho...>]

I added an #include-once directive and let it default to "no" (current
behavior).  Also added was a program argument to change the default
behavior if one so desires [me]. Testing done as well.

http://pastebin.com/5Mfrvzdw

Regards, Enoch.


Keith Amidon <ca...@pi...> writes:

> {-- Mon, 15 Apr 2013 12:52:45 -0400: Enoch <ix...@ho...> wrote: --}
>
>   Enoch> As this is our first direct communication, thank you for contributing
>   Enoch> the shell.
>
> Thanks for your appreciation.  I've really enjoyed working on my amforth
> projects and just wish I had more time for them. ;-)
>
>   Enoch> I did read your other thoughts. It raises intersting questions regarding
>   Enoch> the future role of the shell in AmForth development. Is it an essential
>   Enoch> tool or "just" a convenience.
>
> Personally, I think it is important that the shell is *always* just a
> convenience.  My suggested implementation was intended to maintain that
> property.  
>
> My reasoning for the "#require" suggested implementation with the
> special word to indicate something was uploaded was that the only way to
> reliably know what has been uploaded to the microcontroller is to ask
> it.  Anything else is vulnerably to shell restarts, microcontroller
> re-flashes, etc.
>
> My reasoning with the "#include" suggestions was motivated purely by my
> own workflow.  I pretty much manually do all the things I suggested the
> shell do and I find that process to be error-prone.  Trying to automate
> it using the existing support in the shell is doable (e.g. by having it
> ignore the error from the next command when calling the marker word) but
> results in output errors when the markers aren't present.  I'd like to
> avoid that error output since the primary expected users of the
> libraries I've created are very inexperienced.
>
>          --- Keith
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter

Re: [Amforth] amforth-shell.py bugfix

[Keith A. <ca...@pi...>]

{-- Mon, 15 Apr 2013 12:52:45 -0400: Enoch <ix...@ho...> wrote: --}

  Enoch> As this is our first direct communication, thank you for contributing
  Enoch> the shell.

Thanks for your appreciation.  I've really enjoyed working on my amforth
projects and just wish I had more time for them. ;-)

  Enoch> I did read your other thoughts. It raises intersting questions regarding
  Enoch> the future role of the shell in AmForth development. Is it an essential
  Enoch> tool or "just" a convenience.

Personally, I think it is important that the shell is *always* just a
convenience.  My suggested implementation was intended to maintain that
property.  

My reasoning for the "#require" suggested implementation with the
special word to indicate something was uploaded was that the only way to
reliably know what has been uploaded to the microcontroller is to ask
it.  Anything else is vulnerably to shell restarts, microcontroller
re-flashes, etc.

My reasoning with the "#include" suggestions was motivated purely by my
own workflow.  I pretty much manually do all the things I suggested the
shell do and I find that process to be error-prone.  Trying to automate
it using the existing support in the shell is doable (e.g. by having it
ignore the error from the next command when calling the marker word) but
results in output errors when the markers aren't present.  I'd like to
avoid that error output since the primary expected users of the
libraries I've created are very inexperienced.

         --- Keith

Re: [Amforth] amforth-shell.py bugfix

[Enoch <ix...@ho...>]

Hi Keith,

As this is our first direct communication, thank you for contributing
the shell.

Keith Amidon <ca...@pi...> writes:

> {-- Mon, 15 Apr 2013 03:03:55 -0400: Enoch <ix...@ho...> wrote: --}
>
>   Enoch> Hello Matthias & All:
>   Enoch> amforth-shell.py bugfix. skips already uploaded #include files.
>
>   Enoch> http://pastebin.com/ePa76LmL
>
> I can see how this would be useful in some circumstances.  However, in
> interactive development I upload the same file many times after making
> changes to it, often with the use of marker words temporarily embedded
> in the file.  For that reason I would prefer that this not be included
> in the main distribution unless there is a method to turn the checking
> on/off, preferably with a default value of off.

Good point, I'll add #include-once [<yes-or-no>] with a "no"
default. You have provided a nice config nesting infrastructure.

I did read your other thoughts. It raises intersting questions regarding
the future role of the shell in AmForth development. Is it an essential
tool or "just" a convenience.

Regards, Enoch.

Re: [Amforth] amforth-shell.py bugfix

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:
>> amforth-shell.py bugfix. skips already uploaded #include files.
>
> This would break my standard workflow: 
> start shell
> do
>   flash controller
>   upload files with #include (via cursor up-history)
>   test
> again

Hello Matthias,

I guess you better alter the above workflow a little if you wish to
prevent postpone (for example) being uploaded multiple times :-)

This #include once behavior is what Python does with import. I was
considering to remember the set of uploaded files between shell sessions
but rejected it for simplicity.

> I would prefer something like
> require <name> as specified
> in http://www.forth200x.org/required.html
> and keeping the include as it is now.

Hmm... I prefer keeping the shell's meta commands "meta"
(http://foldoc.org/meta). Once AmForth incorporates a notion of files
(anyone using AT90USB????) we can let the AVR take charge.

Regards, Enoch.

Re: [Amforth] amforth-shell.py bugfix

[Keith A. <ca...@pi...>]

{-- Mon, 15 Apr 2013 03:03:55 -0400: Enoch <ix...@ho...> wrote: --}

  Enoch> Hello Matthias & All:
  Enoch> amforth-shell.py bugfix. skips already uploaded #include files.

  Enoch> http://pastebin.com/ePa76LmL

I can see how this would be useful in some circumstances.  However, in
interactive development I upload the same file many times after making
changes to it, often with the use of marker words temporarily embedded
in the file.  For that reason I would prefer that this not be included
in the main distribution unless there is a method to turn the checking
on/off, preferably with a default value of off.

This got me wondering if what would be more useful is a

    #require <file>

directive as an alternative to

    #include <file>

The way I would implement "#require <file>" is that it would attempt to
execute the word "<file-basename>-provided", where <file-basename> is
replaced with the name of the specified file with any path to reach the
file and any ".frt" extension stripped.  So, if the directive were:

   #require lib/marker.frt

The word that would be executed would be:

   marker-provided

If this word can be executed without error it indicates the required
file has already been uploaded and thus the upload can be skipped,
otherwise the file is uploaded just as it is in the #include directive.

I would not have the "#require" implementation do anything to create the
"<file-basename>-provided" word.  Instead, I'd let the library itself do
that so that the library can determine what the definition of that word
should be.  To guard against usage of "#require" with libraries that do
not create "<file-basename>-provided" I would have the "#require"
implementation verify it *can* successfully execute the that word on the
target after the upload and print a warning if it can not.

I suspect this would address the use case that the suggested change is
intended to support while allowing the user of the shell to clearly
express the kind of behavior they want without having to be aware of
configuration settings/flags.

On a related note, I've also considered having #include automatically
establish a markers named "marker-before-<file-basename>" before a
library is loaded and call this during it is reloaded as a convenience.
Up until now I avoided doing this because I didn't want the shell to
require any non-default words.  However, I think this could be nicely
combined with some of the infrastructure the "#require" functionality
would need in the shell, in the following way:

  1. Have the marker library create marker-provided
  2. In #include:
     a. Check for marker-provided.  If it is not present skip the
        following two steps
     b. Before uploading the file, attempt to execute
        "marker-before-<file-basename>", ignoring any error
     c. Create a new "marker-before-<file-basename>"
     d. Continue with the upload

The nice thing about this is it only takes effect if you load the marker
library.  So you can do things like load marker.frt during development
but then not load it when you are ready to create a production image in
which you don't want the markers, etc.

Unfortunately, I don't have time to work on any of this right now.
Hopefully these thoughts are at least useful to the discussion.

      --- Keith

Re: [Amforth] amforth-shell.py bugfix

[Matthias T. <mt...@we...>]

Hi Enoch,

> Hello Matthias & All:
> 
> amforth-shell.py bugfix. skips already uploaded #include files.

This would break my standard workflow: 
start shell
do
  flash controller
  upload files with #include (via cursor up-history)
  test
again

I would prefer something like
require <name> as specified
in http://www.forth200x.org/required.html
and keeping the include as it is now.

Another closly related feature would be

require 2drop

that checks, whether 2drop is already defined and includes
the file 2drop[.frt] only if not found in the dictionary. 

Just dreaming ;)

Matthias

[Amforth] amforth-shell.py bugfix

[Enoch <ix...@ho...>]

Hello Matthias & All:

amforth-shell.py bugfix. skips already uploaded #include files.

http://pastebin.com/ePa76LmL

Regards, Enoch.

Re: [Amforth] imove

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
>> In your latest docs you refer to having a GIT tree, where is it based?
>
> Its on my local desktop system. Not available for external access.
>
>> I would like to track AmForth via GIT rather than SVN for some local
>> kernel changes that I maintain (*)
>
> I've heart that git-svn works well. Never really tried it myself howver.

Hello Matthias,

I took up your advice and finally I have commit rights :-)

Regards, Enoch.

Re: [Amforth] imove

[Matthias T. <mt...@we...>]

Hi Enoch,

> In your latest docs you refer to having a GIT tree, where is it based?

Its on my local desktop system. Not available for external access.

> I would like to track AmForth via GIT rather than SVN for some local
> kernel changes that I maintain (*)

I've heart that git-svn works well. Never really tried it myself howver.

Matthias

Re: [Amforth] imove

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:
> Thanks for sharing. Fix applied :=)

Hello Matthias,

I really enjoy the experience and I should be thanking you!

In your latest docs you refer to having a GIT tree, where is it based?

I would like to track AmForth via GIT rather than SVN for some local
kernel changes that I maintain (*).

Regards, Enoch.

(*) 

Those will be offered soon once fully tested in my application. These
are issues related to the way Interrupts are handled with the intention
of making AmForth Interrupt Service routines truly interruptible.

Re: [Amforth] imove

[Matthias T. <mt...@we...>]

Hi Enoch,

> I had it fixed for my own use, so here sharing:

Thanks for sharing. Fix applied :=)

Matthias

Re: [Amforth] imove

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

>> Also, it seems to me that your implementation may cause ram buffer
>> overflow.
>
> The code copies flash cells. That may overrun the
> RAM if an odd number of bytes is transferred. Thats
> bad indeed.

Hello Matthias, 

I had it fixed for my own use, so here sharing:

: imove ( i-addr len ram -- )
  rot rot dup 1 and >r			\ ( ram i-addr len ) ( r: odd )
  2/ over + dup >r			\ ( ram i-addr i-addr' ) ( r: odd i-addr' )
  swap					\ ( ram i-addr' i-addr )
  ?do  i @i over ! cell+  loop		\ ( ram' )
  r> r>					\ ( ram' i-addr' odd )
  if  @i swap c!  else  2drop  then
;

http://pastebin.com/ZqL4aWN7

Regards, Enoch.