Hello Tristan,
Tristan Williams writes:
> A one line patch for amforth-shell.py to correct a python2/python3
> syntax error. It occurs when using the --no-error-on-output
> option. Below is a unified diff against r2450/trunk/tools/amforth-shell.py
>
> --- amforth-shell.py
> +++ new-shell.py
> @
Super. I just patched my local repo. All I had to do was to add the
python3-serial package (debian buster) and change the defaults for the
serial port and it fired right up. I'll try it next time I'm passing files
around to see how things go here.
Thank you,
Mark
On Mon, Jul 6, 2020 at 12:53 PM T
Hello,
Problem found, when loading something went wrong which amforth was not correct
anymore!
cheers,
Jan
> Op 7 dec. 2018, om 14:24 heeft Jan Kromhout het
> volgende geschreven:
>
> Hello,
>
>
> After running for several weeks amforth-shell.py, this afternoon it is
> stopped with an U
Hi all:
Matthias Trute writes:
> Hi Keith,
>
> The #terminal flag would require a source code inspection and
> an annotation. Technically a good idea, but from the users
> perspective less ideal. IMHO.
>
>> My suggestion to handle this situation would be to do too things:
>>
>> 1. Add a #termin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Keith,
The #terminal flag would require a source code inspection and
an annotation. Technically a good idea, but from the users
perspective less ideal. IMHO.
> My suggestion to handle this situation would be to do too things:
>
> 1. Add a #termin
On Tue, 2013-11-05 at 20:05 +0100, Matthias Trute wrote:
> Hi Craig,
>
> > It doesn't matter if I execute key interactively or put it into a
> > new word definition. It always hangs.
>
> Pressing Ctrl-C and restarting the shell works for me. But nothing
> else..
>
> >
> > What am I doing wrong?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Craig,
> It doesn't matter if I execute key interactively or put it into a
> new word definition. It always hangs.
Pressing Ctrl-C and restarting the shell works for me. But nothing
else..
>
> What am I doing wrong?
Nothing. The shell has a bug
Hi Enoch,
> Hello AmForth-ers,
>
> May I suggest the following humble patch to the fabulous shell.
applied. Thanks
Matthias
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new
{-- Thu, 25 Apr 2013 11:46:23 -0400: Enoch wrote: --}
Enoch> Your amforth-shell.py is designed for importing and that's a good
Enoch> starting point. I am sure that we can copy ideas from the various
python
Enoch> development approaches under emacs to modify gforth.el. All that we
need
Keith Amidon writes:
> {-- Tue, 23 Apr 2013 12:12:50 -0400: Enoch wrote: --}
>
> Enoch> Specialized IDEs are great but for me it's Emacs for
> Enoch> everything.
>
> It's emacs for everything for me as well. Take a look at the mail user
> agent this email comes from... ;-)
>
> Enoch> I
{-- Tue, 23 Apr 2013 12:12:50 -0400: Enoch wrote: --}
Enoch> Specialized IDEs are great but for me it's Emacs for
Enoch> everything.
It's emacs for everything for me as well. Take a look at the mail user
agent this email comes from... ;-)
Enoch> I am using (a customized version of) gfo
m/holon/papers/ef95.htm
>
>
>
>
> De: Rafael Gonzalez
> Para: Everything around amforth
> 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
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
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 modifie
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 heu
> To: amforth-devel@lists.sourceforge.net
> From: i...@hotmail.com
> 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
Matthias Trute 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
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
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 writes:
> {-- Mon, 15 Apr 2013 12:52:45
{-- Mon, 15 Apr 2013 12:52:45 -0400: Enoch 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 r
Hi Keith,
As this is our first direct communication, thank you for contributing
the shell.
Keith Amidon writes:
> {-- Mon, 15 Apr 2013 03:03:55 -0400: Enoch wrote: --}
>
> Enoch> Hello Matthias & All:
> Enoch> amforth-shell.py bugfix. skips already uploaded #include files.
>
> Enoch> htt
Matthias Trute 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
{-- Mon, 15 Apr 2013 03:03:55 -0400: Enoch 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 up
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 as specified
i
Hello Matthias & all:
> Matthias Trute writes:
>> That makes sense. But appl_own.py as the filenname. There should
>> be better ones. Or a more generic approach. I'm not a python expert,
>> but many python directories contain a file named __init__.py to do
>> something useful.
>
> Seems too "
Matthias Trute writes:
> Enoch,
>
>> I said, how nice it would be if amforth-shell would do it for me just
>> like it does with Atmel's register/bit defs.
>
> That makes sense. But appl_own.py as the filenname. There should
> be better ones. Or a more generic approach. I'm not a python expert
Enoch,
> I said, how nice it would be if amforth-shell would do it for me just
> like it does with Atmel's register/bit defs.
That makes sense. But appl_own.py as the filenname. There should
be better ones. Or a more generic approach. I'm not a python expert,
but many python directories conta
Matthias Trute writes:
> Hi Enoch,
>
>>
>> As I promised to generalize crc8.frt (#1) a question was raised how would
>> the user configure it to its use, namely, select the generating
>> polynomial byte and the needed bit order (#2).
>>
>> I answered the question through the following amforth-sh
Hi Enoch,
>
> As I promised to generalize crc8.frt (#1) a question was raised how would
> the user configure it to its use, namely, select the generating
> polynomial byte and the needed bit order (#2).
>
> I answered the question through the following amforth-shell.py
> improvement which introdu
Hi Enoch,
> When cleaning up my code to make it uploadable through the minicom
> plugin as well I noted that commented #include's are not recognized by
> the shell (though promised). Below is a patch that straightens things
> up.
Many thanks for it.
>
> Also, I seek confirmation that amforth w
Hi,
>> \ older mcu's may need
>> [undefined] TCCR0B [if] TCCR0 constant TCCR0B [then]
>> [undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then]
>>
>>
>> That would not even require any external tool at all
>>
>> Volunteers welcome ;) (be aware: its not that easy
>> as its seems to be). I just a
On 10/14/2012 05:01 AM, Matthias Trute wrote:
> Am 13.10.2012 22:51, schrieb Enoch:
>> On 10/13/2012 02:53 PM, Matthias Trute wrote:
>>> Hi,
>>>
We do still have a problem how to deal with hardware idiosyncrasies as
timer0.frt demonstrates. It should not be dealt with through the shell
>>
Am 13.10.2012 22:51, schrieb Enoch:
> On 10/13/2012 02:53 PM, Matthias Trute wrote:
>> Hi,
>>
>>> We do still have a problem how to deal with hardware idiosyncrasies as
>>> timer0.frt demonstrates. It should not be dealt with through the shell
>>> (re my ill thought #py idea).
>>>
>>> The generic f
On 10/13/2012 02:53 PM, Matthias Trute wrote:
> Hi,
>
>> We do still have a problem how to deal with hardware idiosyncrasies as
>> timer0.frt demonstrates. It should not be dealt with through the shell
>> (re my ill thought #py idea).
>>
>> The generic frt code should include some preprocessing in
Hi,
> We do still have a problem how to deal with hardware idiosyncrasies as
> timer0.frt demonstrates. It should not be dealt with through the shell
> (re my ill thought #py idea).
>
> The generic frt code should include some preprocessing instructions to
> produce MCU specific code, m4 perhaps?
On 10/13/2012 11:29 AM, Matthias Trute wrote:
> Hi,
>
>> What is your recommended practice?
>
> Very simple: Use what you like most. All tools
> that I include with amforth are the ones I consider
> useful for others as well. I do not enforce any of
> them.
>
> The shell has a few advantages ove
Hi,
> What is your recommended practice?
Very simple: Use what you like most. All tools
that I include with amforth are the ones I consider
useful for others as well. I do not enforce any of
them.
The shell has a few advantages over a dumb terminal
and I like to use it. YMMV.
Matthias
--
Hi Enoch,
On 10/11/2012 09:03 PM, Enoch wrote:
> This brings me to a more fundamental question which you, as Amforth's
> BDFL, I feel, need to address.
>
> Amforth-shell.py turns the use of frt "&34 constant PORTA" definitions
> in the code unnecessary as the shell script does these substitutions
Hello Matthias,
It was a short Python hacking, it turned out that I did not like it
myself too :-)
#py simply triggers the eval code in the patched amforth-shell.py.
Yes, the code sent to the device is being modified by the shell
according to the python expression that is embedded in the frt code
Enoch,
> Please find attached a patch to Keith's shell script for your
> consideration. I took the lazy approach of using Python's eval() option
> and it was quite easy:
I've difficulties to understand you approach. Do you change
the forth code, that gets sent to the controller with the
condition
Hello again Matthias,
Here's the patch at pastebin: http://pastebin.com/NbfGxU3C
Thanks, Enoch.
On 10/08/2012 01:36 PM, Matthias Trute wrote:
> Hi,
>
>> On the at90can128, for example, one has to introduce "TCCR0 constant
>> TCCR0B" before uploading lib/hardware/time0.frt
>>
>> How about exten
Hi Matthias,
Please find attached a patch to Keith's shell script for your
consideration. I took the lazy approach of using Python's eval() option
and it was quite easy:
Two variables:
avr - device name string
py - a truth value
1st method:
#py= avr=="at90can128"
#py? "% TCCR0 c!" if py
Hi,
> On the at90can128, for example, one has to introduce "TCCR0 constant
> TCCR0B" before uploading lib/hardware/time0.frt
>
> How about extending Keith's fantastic shell with conditional upload
> constructs such as:
>
> #ifdev at90can128
>% TCCR0 c! \ stop timer
> #else
>%
43 matches
Mail list logo
