amforth-devel

[Amforth] Maintainer(s) for AmForth

[tristan <ho...@tj...>]

Fellow AmForth-ers,

Perhaps it is time again to consider having a formal maintainer for
AmForth. Back in May 2022 Erich stepped down [1] and put in place
various resources that could be potentially be used to maintain
AmForth (in addition to those that already exist at sourceforge)

To my knowledge, nobody from the mailing list has volunteered
individually. Additionally, having a single maintainer does have its
own issues. So perhaps a way forward would be to have a small group of
maintainers for AmForth. The revelation from Mark R [2] that the latest
AmForth can be made using avra does make a difference to me, such that I
would volunteer for such a group. So are there others on the mailing
list who would be willing to join such a maintainers group?

Kind regards and best wishes,
Tristan

[1] https://sourceforge.net/p/amforth/mailman/message/37656453/
[2] https://sourceforge.net/p/amforth/mailman/message/37887282/

Re: [Amforth] Maintainer(s) for AmForth

[Mark R. <cab...@gm...>]

Hello, Tristan (and all the rest of the community).
I am guessing you mean the SourceForge repo and the mailing list? I wish I
could offer more help with this but I am at a loss with the assembly stuff.
It would be nice to have the website info protected (amforth.sourceforge.net)
since there is so much good information there. And what to do about the
mailing list? I still search them for help now and again. Can it be
archived in some way? I know the website information is in the svn repo and
could be pulled out easily enough.

My bigger issue with making any changes to the assembler files is that I
have no way to test the MSP430 stuff. I can't seem to locate one of the
chips or boards to at least make sure it would work. It's also a pity that
the risc-v stuff wasn't further along since that does seem to be something
that would be useful.

So I would support in what minimal way I can. I know there are those of you
that have been here for a long time. The fact is that this project is still
useful. It just seems to work. So long as I have access to 8 bit avr chips
I'm sure I'll be playing around with AmForth. There is something about
thinking in forth that seems to be good for my aging brain. And there is no
denying that having register level access is great.

Mark

On Sun, Sep 10, 2023 at 6:05 PM tristan <ho...@tj...> wrote:

> Fellow AmForth-ers,
>
> Perhaps it is time again to consider having a formal maintainer for
> AmForth. Back in May 2022 Erich stepped down [1] and put in place
> various resources that could be potentially be used to maintain
> AmForth (in addition to those that already exist at sourceforge)
>
> To my knowledge, nobody from the mailing list has volunteered
> individually. Additionally, having a single maintainer does have its
> own issues. So perhaps a way forward would be to have a small group of
> maintainers for AmForth. The revelation from Mark R [2] that the latest
> AmForth can be made using avra does make a difference to me, such that I
> would volunteer for such a group. So are there others on the mailing
> list who would be willing to join such a maintainers group?
>
> Kind regards and best wishes,
> Tristan
>
> [1] https://sourceforge.net/p/amforth/mailman/message/37656453/
> [2] https://sourceforge.net/p/amforth/mailman/message/37887282/
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Maintainer(s) for AmForth

[tristan <ho...@tj...>]

Hello Mark and fellow AmForth'ers,

> I am guessing you mean the SourceForge repo and the mailing list?

Yes, my primary focus is the SF AmForth repo, website, community and
mailing list.

> The fact is that this project is still useful.

I completely agree. AmForth is quite special as an embedded Forth in
that it has wordlists, recognizers and comprehensive documentation.

In suggesting a maintainer group the idea was that the effort required
to preserve and update AmForth could be divided up, and perhaps if
some of the more mundane aspects of avoiding bit rot are done, then
people with more specialised skills, but less time, might feel more
able to help.

What would I suggest for the near term?

1. A decision as to whether the SF AmForth repo, website and mailing
list should remain at SF or move elsewhere. Moving it will take some
effort, but some arguments and provisions for moving it have been
put forward and made.

2. A release adding avra as a build option.

3. Prebuilt hex files for UNO and MEGA added to release by default.

4. Update the docs where the passage of time has not been kind.

Whilst I'm new to sphinx and reStructuredText, the AmForth distribution
documentation does build easily and only minor changes would be needed
to host it pretty much anywhere. To verify this I have put it up
temporarily at https://www.mostlymostly.uk/amforthdocs and done some
tests with github pages [3]

I'm reasonably sure that a good chunk of the above (excepting point 1)
has already been done by individuals on the list, so it is more
coordination and administration than anything else. Elements of
the above that have not been done, I am happy to do.

What would I like to see longer term?

1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It
would be great to see AmForth running on, say, an ATmega4809 [1]. It
is one of the megaAVR 0-series with newer peripherals, including a
CCL. I've used similar on newer PIC mcus and they are very nice to
have. Why the ATmega4809 in particular? (a) There is some support for
it in avra (b) it is on the Arduino Nano Every [2] (c) it is available
in 40 Pin DIP (48 pin die, minus some pads). I would be interested to
know if anyone has done it/similar or how hard it might be ;)

2. For RISC-V. Of AmForth's non-avr8 branches it is the one that
interests me most. The hardware used to be relatively expensive and
hard to come by. Now it is not, which presents the problem of
choice. It would be nice to have an approachable build for AmForth
RISC-V on an inexpensive but obtainable board - but which one? Again,
I would be interested in what people have done and opinions as to what
might work. Additionally, has anyone got AmForth RISC-V running in a
simulator?

> There is something about thinking in forth that seems to be good for
> my aging brain.

I feel the same way.

Best wishes,
Tristan

[1] https://www.microchip.com/en-us/product/atmega4809
[2] https://docs.arduino.cc/hardware/nano-every
[3] https://docs.github.com/pages


On 2023-09-14 11:11, Mark Roth wrote:
> Hello, Tristan (and all the rest of the community).
> I am guessing you mean the SourceForge repo and the mailing list? I 
> wish I
> could offer more help with this but I am at a loss with the assembly 
> stuff.
> It would be nice to have the website info protected 
> (amforth.sourceforge.net)
> since there is so much good information there. And what to do about the
> mailing list? I still search them for help now and again. Can it be
> archived in some way? I know the website information is in the svn repo 
> and
> could be pulled out easily enough.
> 
> My bigger issue with making any changes to the assembler files is that 
> I
> have no way to test the MSP430 stuff. I can't seem to locate one of the
> chips or boards to at least make sure it would work. It's also a pity 
> that
> the risc-v stuff wasn't further along since that does seem to be 
> something
> that would be useful.
> 
> So I would support in what minimal way I can. I know there are those of 
> you
> that have been here for a long time. The fact is that this project is 
> still
> useful. It just seems to work. So long as I have access to 8 bit avr 
> chips
> I'm sure I'll be playing around with AmForth. There is something about
> thinking in forth that seems to be good for my aging brain. And there 
> is no
> denying that having register level access is great.
> 
> Mark
> 
> On Sun, Sep 10, 2023 at 6:05 PM tristan <ho...@tj...> wrote:
> 
>> Fellow AmForth-ers,
>> 
>> Perhaps it is time again to consider having a formal maintainer for
>> AmForth. Back in May 2022 Erich stepped down [1] and put in place
>> various resources that could be potentially be used to maintain
>> AmForth (in addition to those that already exist at sourceforge)
>> 
>> To my knowledge, nobody from the mailing list has volunteered
>> individually. Additionally, having a single maintainer does have its
>> own issues. So perhaps a way forward would be to have a small group of
>> maintainers for AmForth. The revelation from Mark R [2] that the 
>> latest
>> AmForth can be made using avra does make a difference to me, such that 
>> I
>> would volunteer for such a group. So are there others on the mailing
>> list who would be willing to join such a maintainers group?
>> 
>> Kind regards and best wishes,
>> Tristan
>> 
>> [1] https://sourceforge.net/p/amforth/mailman/message/37656453/
>> [2] https://sourceforge.net/p/amforth/mailman/message/37887282/
>> 
>> 
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Maintainer(s) for AmForth

[Mark R. <cab...@gm...>]

Good morning AmForth'ers (feel free to adjust the greeting with your RTC).

disclaimer: I am going to cherry pick the commentary by Tristan for this
post. You can safely assume that the single quotes are their's and any
quoted quotes are mine unless noted. This thread is getting a little wound
up and I think it is important to be clear for anyone wanting to toss in
their vote about what to do. But we need to do something or I fear the
group will just finish dissolving.

> I am guessing you mean the SourceForge repo and the mailing list?
>
> Yes, my primary focus is the SF AmForth repo, website, community and
> mailing list.
>

This is I think the core of it all. When I first talked about getting a
working version of avra working with linux I was pleasantly surprised to
find a number of people pop in to talk about it. I fully expected to hear
from Tristan and Erich (hoped so anyway) since you both were the most
active at the end of the recent activity. That others are still subscribed
to this list and have an interest is great. This makes me think that we
very well could (should) form a quorum, which, in our depleted state could
be as little as 3. ;)

> The fact is that this project is still useful.
>
> I completely agree. AmForth is quite special as an embedded Forth in
> that it has wordlists, recognizers and comprehensive documentation.
>
> In suggesting a maintainer group the idea was that the effort required
> to preserve and update AmForth could be divided up, and perhaps if
> some of the more mundane aspects of avoiding bit rot are done, then
> people with more specialised skills, but less time, might feel more
> able to help.
>
> What would I suggest for the near term?
>

This seems to me to pretty much sum up a good mission statement of what
AmForth is and why it can continue to be viable. Even with ONLY the focus
on the AVR8 side of the repo, which is the core of it, adding more up to
date chips as Tristan mentions later is a great way to interest new people
and keep things from going to seed. So I'll sum up the points made and
expand where needed.

0. Where should the official repo be?
1. At least two people with write access to the repo for redundancy.
2. Make a 7.0 release at that time including
> a. the avra build
> b. an up to date version of the project makefile
> c. at least the first layers of documentation brought up to date
> d. the prebuilt hex files (really just a cleaning of the project
directory in general)
3. Deciding on a better way to communicate be it built in like github has
or something that goes hand in hand.
4. Discussing what it would take to continue on with something like the
RISC-V side of the repo.

So, that is the way I see it. I'd like to add right up front that while I
am not very skilled with forth I have spent a good deal of time learning
how to get better with it. It is pretty much the only language I have
studied these last couple of years. I am time rich so I will volunteer a
portion of that time if there is a viable way to make AmForth feel more
modern. To me right now it feels like an old dusty attic. There are still
great things to be discovered, but they are up a creaky flight of stairs,
in a poorly lit room and covered in a bit of dusty age. A big part of that
for me is the Source Forge side. I use git locally and github publicly
(although I have used a couple other flavors of public git when needed). I
am painfully aware that there are issues in using github. I get that, but I
like the overall tool and the fact there is no cost outlay to have
something anyone can get at. A bugtracker, discussions, wiki etc are things
I put a lot of value in when it comes to the choice if moving happens.

At the very least though, some sort of better way to communicate is
required. I love email but am finding more and more that less and less
people use it as a primary means of communication. So coupling that with
the somewhat more difficult method of the mailing list could perhaps, or
I'd say probably, be a deterrent for people, in particular new people, to
participate. I would like to have read and search access to all of the past
mailing list text though since there are a lot of really good conversations
and problem solving that have been done. If only to use that when bringing
the documentation up to date.

And that brings up a really big part of things, the documentation.
The entire thing needs to be edited and overhauled. I honestly don't care
what flavor of markup it uses. Most that I have used are similar enough
that a small cheat sheet is all that is needed to be good at it. I will
happily take a big part of that project once a decision has been reached on
where it will live. While doing this the source tree should be cleaned up
as well. There are some inconsistencies with the comments and stack effect
diagrams, some things like should it be .dw $ff03 or .dw $0003. I'm pretty
sure the former is the desired way since the newer files are like that, as
well as the way that the AVR blanks to $ffff (I think). Perhaps then the
refcard could once again be brought up to date from scratch giving yet
another good thing for new people to access. I did have a look at the test
host that Tristan put up temporarily at
https://www.mostlymostly.uk/amforthdocs and it does seem to work perfectly.
So keeping the RST stuff (of which there is a lot in the repo) is a very
viable option no matter where things end up. I also was reading a gist
about converting from that to markdown that I have been meaning to try to
see how well it works.

Okay, that went on way too long. But I did want to address the group since
I have found so much value here in the last couple of years. I'll leave the
quoted bit below from the original message since Tristan was very concise
about things. I hope there are no hard feelings for dicing up this message
to make it as legible as possible.  I would like to see a more lively
official AmForth home wherever and however it will end up.

All the best,
Mark

What would I like to see longer term?
>
> 1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It
> would be great to see AmForth running on, say, an ATmega4809 [1]. It
> is one of the megaAVR 0-series with newer peripherals, including a
> CCL. I've used similar on newer PIC mcus and they are very nice to
> have. Why the ATmega4809 in particular? (a) There is some support for
> it in avra (b) it is on the Arduino Nano Every [2] (c) it is available
> in 40 Pin DIP (48 pin die, minus some pads). I would be interested to
> know if anyone has done it/similar or how hard it might be ;)
>
> 2. For RISC-V. Of AmForth's non-avr8 branches it is the one that
> interests me most. The hardware used to be relatively expensive and
> hard to come by. Now it is not, which presents the problem of
> choice. It would be nice to have an approachable build for AmForth
> RISC-V on an inexpensive but obtainable board - but which one? Again,
> I would be interested in what people have done and opinions as to what
> might work. Additionally, has anyone got AmForth RISC-V running in a
> simulator?
>
> > There is something about thinking in forth that seems to be good for
> > my aging brain.
>
> I feel the same way.
>
> Best wishes,
> Tristan
>
> [1] https://www.microchip.com/en-us/product/atmega4809
> [2] https://docs.arduino.cc/hardware/nano-every
> [3] https://docs.github.com/pages
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Maintainer(s) for AmForth

[Martin N. <amf...@mg...>]

On Sun, 10 Sep 2023 17:04:01 +0200
tristan <ho...@tj...> wrote:

> Fellow AmForth-ers,
> 
> Perhaps it is time again to consider having a formal maintainer for
> AmForth. Back in May 2022 Erich stepped down [1] and put in place
> various resources that could be potentially be used to maintain
> AmForth (in addition to those that already exist at sourceforge)
> 
> To my knowledge, nobody from the mailing list has volunteered
> individually. Additionally, having a single maintainer does have its
> own issues. So perhaps a way forward would be to have a small group of
> maintainers for AmForth. The revelation from Mark R [2] that the
> latest AmForth can be made using avra does make a difference to me,
> such that I would volunteer for such a group. So are there others on
> the mailing list who would be willing to join such a maintainers
> group?

I would be happy to make some sort of contribution, but being
essentially a hobbyist programmer, I'm not sure how useful I could be.
I've never worked in any type of devlopment team.

Documentation is something I could contribute to, but not until next
year due to on-going commitments in 2023.

Certainly an "advert" for maintiners on AmForth's new home would be a
good thing; together messages on the socials.

Talking of maintenance, I note that avra (on Sourceforge) hasn't been
updated since 2019. Maybe it's completed?

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2023).

Re: [Amforth] Maintainer(s) for AmForth

[Malte F. G. <mal...@gm...>]

Martin Nicholas via Amforth-devel <amf...@li...> writes:

> On Sun, 10 Sep 2023 17:04:01 +0200
> tristan <ho...@tj...> wrote:
>
>> Fellow AmForth-ers,
>> 
>> Perhaps it is time again to consider having a formal maintainer for
>> AmForth. Back in May 2022 Erich stepped down [1] and put in place
>> various resources that could be potentially be used to maintain
>> AmForth (in addition to those that already exist at sourceforge)
>> 
>> To my knowledge, nobody from the mailing list has volunteered
>> individually. Additionally, having a single maintainer does have its
>> own issues. So perhaps a way forward would be to have a small group of
>> maintainers for AmForth. The revelation from Mark R [2] that the
>> latest AmForth can be made using avra does make a difference to me,
>> such that I would volunteer for such a group. So are there others on
>> the mailing list who would be willing to join such a maintainers
>> group?
>
> I would be happy to make some sort of contribution, but being
> essentially a hobbyist programmer, I'm not sure how useful I could be.
> I've never worked in any type of devlopment team.
>
> Documentation is something I could contribute to, but not until next
> year due to on-going commitments in 2023.
>
> Certainly an "advert" for maintiners on AmForth's new home would be a
> good thing; together messages on the socials.
>
> Talking of maintenance, I note that avra (on Sourceforge) hasn't been
> updated since 2019. Maybe it's completed?

At least the home page points to https://github.com/Ro5bert/avra which
has seen some commits since 2019.


mfg²

Re: [Amforth] Maintainer(s) for AmForth

[Mark R. <cab...@gm...>]

> Talking of maintenance, I note that avra (on Sourceforge) hasn't been

> > updated since 2019. Maybe it's completed?
>
> At least the home page points to https://github.com/Ro5bert/avra which
> has seen some commits since 2019.
>

 There were some PRs for that one that led to a development branch for
another fork. I took that one and pushed them into main. You can find it
here here at my github fork <https://github.com/CableGuy67/avra>.

It builds with just a simple 'make' easily enough for me on Debian. I've
even built it for Raspian successfully. There are a few little things that
could be fixed but it does work and build AmForth in its current state
(both avra and AmForth).

Cheers,
Mark

Re: [Amforth] Maintainer(s) for AmForth

[Mark R. <cab...@gm...>]

Here is the clean link.

https://github.com/CableGuy67/avra

On Mon, Sep 25, 2023 at 8:30 AM Mark Roth <cab...@gm...> wrote:

>
>
> > Talking of maintenance, I note that avra (on Sourceforge) hasn't been
>
>> > updated since 2019. Maybe it's completed?
>>
>> At least the home page points to https://github.com/Ro5bert/avra which
>> has seen some commits since 2019.
>>
>
>  There were some PRs for that one that led to a development branch for
> another fork. I took that one and pushed them into main. You can find it
> here here at my github fork <https://github.com/CableGuy67/avra>.
>
> It builds with just a simple 'make' easily enough for me on Debian. I've
> even built it for Raspian successfully. There are a few little things that
> could be fixed but it does work and build AmForth in its current state
> (both avra and AmForth).
>
> Cheers,
> Mark
>

Re: [Amforth] Maintainer(s) for AmForth

[Erich W. <ew....@na...>]

Hi Mark,

Mark Roth <cab...@gm...> writes:

> Here is the clean link.
>
> https://github.com/CableGuy67/avra

Thanks for pulling this together.

I can successfully build the executable on debian 12, gcc 13.2
on a riscv64 machine. :)

I would kindly suggest to increase the version number, or add
some local suffix.

Thanks,
Erich

> On Mon, Sep 25, 2023 at 8:30 AM Mark Roth <cab...@gm...> wrote:
>
>>
>>
>> > Talking of maintenance, I note that avra (on Sourceforge) hasn't been
>>
>>> > updated since 2019. Maybe it's completed?

PS: to me it seems, that Robert Russel has ceased all activity
on github. Whatever that means.

Re: [Amforth] Maintainer(s) for AmForth

[Erich W. <ew....@na...>]

Hello all,

good to see some interest in this project again.



Mark Roth <cab...@gm...> writes:

> Good morning AmForth'ers (feel free to adjust the greeting with your RTC).

>snip<<<<<<

>> Tristan wrote, if I'm not mistaken
>>
>> The fact is that this project is still useful.
>>
>> I completely agree. AmForth is quite special as an embedded Forth in
>> that it has wordlists, recognizers and comprehensive documentation.
>>
>> In suggesting a maintainer group the idea was that the effort required
>> to preserve and update AmForth could be divided up, and perhaps if
>> some of the more mundane aspects of avoiding bit rot are done, then
>> people with more specialised skills, but less time, might feel more
>> able to help.
>>
>> What would I suggest for the near term?
>>
>
> This seems to me to pretty much sum up a good mission statement of what
> AmForth is and why it can continue to be viable. Even with ONLY the focus
> on the AVR8 side of the repo, which is the core of it, adding more up to
> date chips as Tristan mentions later is a great way to interest new people
> and keep things from going to seed. So I'll sum up the points made and
> expand where needed.


So, jumping right into the TODO section
>
> 0. Where should the official repo be?
in December 2020 I have created a git based version of the
repository at
  https://git.sr.ht/~amforth/

it comes in two flavours:
- code-tree :: the releases tree is preserved as is, since it is
a lot simpler for me to find changes across versions with find,
grep et al.
- code :: the releases tree is converted to git branches, which
just proves, that it can be done.

The repository at sourcehut is currently paid by me. Sourcehut
has integration with email workflows, it is possible to have
tickets and commits be handled by email to some extent, maybe
completely. The web frontend works without javascript, which is
why I am there with my private stuff as well.

That being said: I am still somewhat hesitant to move everything
over, since I fear that the small community (think mailing list)
might not resubscribe at the new place. I could be wrong though.
And if a quorum of '3' is sufficient, go for it :)

I still offer to send authentication stuff regarding
sourceforge.net to folks on this list. However, at the time
nobody expressed interest.


> 1. At least two people with write access to the repo for
> redundancy.
Tristan? Mark? Else?

> 2. Make a 7.0 release at that time including
>> a. the avra build
>> b. an up to date version of the project makefile
>> c. at least the first layers of documentation brought up to date
>> d. the prebuilt hex files (really just a cleaning of the project
>> directory in general)

I personally think, the avra build is important. This was the
remaining head ache for me, relying on a piece of proprietary
software, which might break at the least convenient time. Now I
do accept, that not everyone is on Linux/*BSD.

I still have a file which documents the steps to build a release
and the associated web site. (I'll stuff this into a separate
email)

I am not a friend of prebuilt hex files, but again, other people
have different preferences. I'd rather push someone through
creating their .hex files, because it opens the world for them.

> 3. Deciding on a better way to communicate be it built in like
> github has or something that goes hand in hand.


> 4. Discussing what it would take to continue on with something
> like the RISC-V side of the repo.

I have created a personal fork of amForth starting at version
5.0, because it did build with avra, and it is before the other
target platforms were included
- MSP430 at version 5.6
- RV32 at version 6.7
- ARM at version 6.8

I have yet to find a stability problem in my use/setup on avr
amForth, which has not surfaced. I decided to go back to a
version with simpler overall structure (and some known bugs :)

I agree that risc-v is the most appealing future target, I would
not hesitate to remove msp430 and arm and point users to
mecrisp.



>
> So, that is the way I see it. I'd like to add right up front that while I
> am not very skilled with forth I have spent a good deal of time learning
> how to get better with it. It is pretty much the only language I have
> studied these last couple of years. I am time rich so I will volunteer a
> portion of that time if there is a viable way to make AmForth feel more
> modern. To me right now it feels like an old dusty attic. There are still
> great things to be discovered, but they are up a creaky flight of stairs,
> in a poorly lit room and covered in a bit of dusty age. A big part of that
> for me is the Source Forge side. I use git locally and github publicly
> (although I have used a couple other flavors of public git when needed). I
> am painfully aware that there are issues in using github. I get that, but I
> like the overall tool and the fact there is no cost outlay to have
> something anyone can get at. A bugtracker, discussions, wiki etc are things
> I put a lot of value in when it comes to the choice if moving happens.
>
> At the very least though, some sort of better way to communicate is
> required. I love email but am finding more and more that less and less
> people use it as a primary means of communication. So coupling that with
> the somewhat more difficult method of the mailing list could perhaps, or
> I'd say probably, be a deterrent for people, in particular new people, to
> participate. I would like to have read and search access to all of the past
> mailing list text though since there are a lot of really good conversations
> and problem solving that have been done. If only to use that when bringing
> the documentation up to date.
>
> And that brings up a really big part of things, the documentation.
> The entire thing needs to be edited and overhauled. I honestly don't care
> what flavor of markup it uses. Most that I have used are similar enough
> that a small cheat sheet is all that is needed to be good at it. I will
> happily take a big part of that project once a decision has been reached on
> where it will live. While doing this the source tree should be cleaned up
> as well. There are some inconsistencies with the comments and stack effect
> diagrams, some things like should it be .dw $ff03 or .dw $0003. I'm pretty
> sure the former is the desired way since the newer files are like that, as
> well as the way that the AVR blanks to $ffff (I think). Perhaps then the
> refcard could once again be brought up to date from scratch giving yet
> another good thing for new people to access. I did have a look at the test
> host that Tristan put up temporarily at
> https://www.mostlymostly.uk/amforthdocs and it does seem to work perfectly.
> So keeping the RST stuff (of which there is a lot in the repo) is a very
> viable option no matter where things end up. I also was reading a gist
> about converting from that to markdown that I have been meaning to try to
> see how well it works.
>
> Okay, that went on way too long. But I did want to address the group since
> I have found so much value here in the last couple of years. I'll leave the
> quoted bit below from the original message since Tristan was very concise
> about things. I hope there are no hard feelings for dicing up this message
> to make it as legible as possible.  I would like to see a more lively
> official AmForth home wherever and however it will end up.
>
> All the best,
> Mark
>
> What would I like to see longer term?
>>
>> 1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It
>> would be great to see AmForth running on, say, an ATmega4809 [1]. It
>> is one of the megaAVR 0-series with newer peripherals, including a
>> CCL. I've used similar on newer PIC mcus and they are very nice to
>> have. Why the ATmega4809 in particular? (a) There is some support for
>> it in avra (b) it is on the Arduino Nano Every [2] (c) it is available
>> in 40 Pin DIP (48 pin die, minus some pads). I would be interested to
>> know if anyone has done it/similar or how hard it might be ;)
>>
>> 2. For RISC-V. Of AmForth's non-avr8 branches it is the one that
>> interests me most. The hardware used to be relatively expensive and
>> hard to come by. Now it is not, which presents the problem of
>> choice. It would be nice to have an approachable build for AmForth
>> RISC-V on an inexpensive but obtainable board - but which one? Again,
>> I would be interested in what people have done and opinions as to what
>> might work. Additionally, has anyone got AmForth RISC-V running in a
>> simulator?
>>
>> > There is something about thinking in forth that seems to be good for
>> > my aging brain.
>>
>> I feel the same way.
>>
>> Best wishes,
>> Tristan
>>
>> [1] https://www.microchip.com/en-us/product/atmega4809
>> [2] https://docs.arduino.cc/hardware/nano-every
>> [3] https://docs.github.com/pages
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


So. Epilogue of sorts. I still like to work with amForth, I am
still in no position to really understand, how the core works. I
could get there if absolutely needed. Matthias mentioned, that
he was developing it in the AVR Simulator that comes with the
Atmel tools. I accept that I have to write ISR callback
functions entirely in assembly, because of that bug that got
fixed in 6.9 iirc. I still do simple stuff, and a atmega644pa is
"big".

Cheers,
Erich

-- 
May the Forth be with you ...

Re: [Amforth] Maintainer(s) for AmForth

[Mark R. <cab...@gm...>]

Hello AmForth'ers. I like to see this little blip of activity and hope more
of the less than usual suspects join in with their thoughts!

On Tue, Sep 26, 2023 at 7:06 PM Erich Wälde <ew....@na...> wrote:

> Hello all,
>
> good to see some interest in this project again.
>
>
>
> Mark Roth <cab...@gm...> writes:
>
> > Good morning AmForth'ers (feel free to adjust the greeting with your
> RTC).
>
> >snip<<<<<<
>
> >> Tristan wrote, if I'm not mistaken
> >>
> >> The fact is that this project is still useful.
> >>
> >> I completely agree. AmForth is quite special as an embedded Forth in
> >> that it has wordlists, recognizers and comprehensive documentation.
> >>
> >> In suggesting a maintainer group the idea was that the effort required
> >> to preserve and update AmForth could be divided up, and perhaps if
> >> some of the more mundane aspects of avoiding bit rot are done, then
> >> people with more specialised skills, but less time, might feel more
> >> able to help.
> >>
> >> What would I suggest for the near term?
> >>
> >
> > This seems to me to pretty much sum up a good mission statement of what
> > AmForth is and why it can continue to be viable. Even with ONLY the focus
> > on the AVR8 side of the repo, which is the core of it, adding more up to
> > date chips as Tristan mentions later is a great way to interest new
> people
> > and keep things from going to seed. So I'll sum up the points made and
> > expand where needed.
>
>
> So, jumping right into the TODO section
> >
> > 0. Where should the official repo be?
> in December 2020 I have created a git based version of the
> repository at
>   https://git.sr.ht/~amforth/
>
> it comes in two flavours:
> - code-tree :: the releases tree is preserved as is, since it is
> a lot simpler for me to find changes across versions with find,
> grep et al.
> - code :: the releases tree is converted to git branches, which
> just proves, that it can be done.
>
> The repository at sourcehut is currently paid by me. Sourcehut
> has integration with email workflows, it is possible to have
> tickets and commits be handled by email to some extent, maybe
> completely. The web frontend works without javascript, which is
> why I am there with my private stuff as well.
>

I have played around with your git repos quite a lot this summer. I really
wanted the branches one to work so that each branch could have been tagged
and merged upward to the current state. That just won't work. There are far
too many breaking changes, or things that just didn't get captured as
commits or something. While it is nice to have all the releases easy to
swap to by changing branches, it's not really what branches are for. I have
to agree that the way things are with the releases off to the side is the
best solution.

I have not spent as much time poking around sourcehut but from what I did
see it is pretty much as listed on the tin, a git repo. If the cost is
relatively low I guess that isn't much of an issue but it would still need
to be integrated with the rest of the tools for bug reporting, discussions
etc. It seems like it could end up making more work and be even more
difficult to maintain long term or when more or less dormant.

That being said: I am still somewhat hesitant to move everything
> over, since I fear that the small community (think mailing list)
> might not resubscribe at the new place. I could be wrong though.
> And if a quorum of '3' is sufficient, go for it :)
>

lol, by definition '3' is probably too many to merely constitute a majority
;)
The point I was, as I'm sure you sussed out, is that I'd really like to
find out what people want to do, but also that something needs to be done
sooner rather than later. If it is only one person it is nothing more than
another splinter fork.


> I still offer to send authentication stuff regarding
> sourceforge.net to folks on this list. However, at the time
> nobody expressed interest.
>
>
> > 1. At least two people with write access to the repo for
> > redundancy.
> Tristan? Mark? Else?
>

If push comes to shove I 'can' probably manage to keep the lights on at SF.
I wouldn't like that to be the option we go with, but if there is no other
option than I will step up. But I do find SF to be dated and sort of
clunky. Also, as stated before, I detest this mailing list as the only way
to maintain a flow of communication with users and development. I do find
it a very handy resource to search though when having a problem but most of
that information could be integrated into the wiki pages that exist in
either an extension to the recipe section or similar. Not having a bug
tracker to me is a deal breaker. Even that can serve as a forum of sorts.

To me, the AmForth SF website is the biggest thing to really be concerned
with. It is full of pretty much everything but the code base that can get
anyone going. It just needs some maintenance as there are parts that are
glaringly out of date. The other side of that coin is that the SVN repo
seems like a whole separate thing. If you jump over to the download section
there is no obvious way back.

SVN
I'm not a fan anymore of this. Many years ago I was but once you get git
you're got in my opinion. I use it locally for most anything. Is there
anything else for interaction at SF with users and/or developers? I thought
they used to have a rudimentary form sort of thing. Not really a forum but
a set of lists that could be used like that. That could be used as a
discussion, request and/or bug tracking thing right on SF.

GIT
Erich has put a great effort in transferring the svn repo into git. Having
done so myself a couple years ago I can say his looks like a pretty clean
piece of work. Preserving the history of commits is really what it came
down to and it appears to be a nearly flawless job. My vote is that the
releases version be used moving forward. Personally, I would like to see
everything continue on as an organization. Having to work all the
documentation into MD might be tedious, but only once. This is something I
was getting ready to play with to see if it actually works as expected.
https://nimblehq.co/blog/create-github-wiki-pull-request


> 2. Make a 7.0 release at that time including
> >> a. the avra build
> >> b. an up to date version of the project makefile
> >> c. at least the first layers of documentation brought up to date
> >> d. the prebuilt hex files (really just a cleaning of the project
> >> directory in general)
>
> I personally think, the avra build is important. This was the
> remaining head ache for me, relying on a piece of proprietary
> software, which might break at the least convenient time. Now I
> do accept, that not everyone is on Linux/*BSD.
>

I totally agree and Tristan has also voiced the same. The avra stuff is a
little bit of a head-scratcher for me since I wanted to enclose it in the
AmForth repo in a stable state. There is virtually no activity for years on
either the Rob3rt repo or the other fix fork by srtlg. The thing is, just
as with the conversion from AmForth CVS to git, I want all the histories
maintained but not so much the hassle of an unknown repo. The best solution
I came up with my brother (who is a developer) is to fork it to a personal
repo then use that. That is sort of but not exactly what I tried. I forked
it, updated it then yanked out just enough of the code and put it in a new
location in my AmForth git repo with the windows version and allowed for
building it from the appl makefile if needed. That still needs work but as
a process it works pretty well. The real way to do it would be to create
the repo as a submodule within the AmForth tree. If people are going to
want to use avra they are going to have to build it locally anyhow. Plus,
then they have the source which is what it is really about.


> I still have a file which documents the steps to build a release
> and the associated web site. (I'll stuff this into a separate
> email)
>
> I am not a friend of prebuilt hex files, but again, other people
> have different preferences. I'd rather push someone through
> creating their .hex files, because it opens the world for them.
>
> > 3. Deciding on a better way to communicate be it built in like
> > github has or something that goes hand in hand.
>
>
> > 4. Discussing what it would take to continue on with something
> > like the RISC-V side of the repo.
>
> I have created a personal fork of amForth starting at version
> 5.0, because it did build with avra, and it is before the other
> target platforms were included
> - MSP430 at version 5.6
> - RV32 at version 6.7
> - ARM at version 6.8
>
> I have yet to find a stability problem in my use/setup on avr
> amForth, which has not surfaced. I decided to go back to a
> version with simpler overall structure (and some known bugs :)
>
> I agree that risc-v is the most appealing future target, I would
> not hesitate to remove msp430 and arm and point users to
> mecrisp.
>
>
The build document from the other message really needs to be put into the
repo somewhere. Well, the TS stuff for the website side I mean. But then
things are diverging from your git so we seem to have a race condition.
Your points about the hex files are valid, but I do think there are people
that will just want to load it up with as little fuss as possible and start
working with forth. I could be wrong but I don't see the harm in including
them. Once someone starts working from the template project they will be
building anyhow. Having prebuilt hex files for known popular platforms
isn't going to hurt, it just creates more access.

That's all I have for this morning. Anyone reading this, particularly
someone not usually heard here please let it be known what you would like
or not like. Or what you do or don't like about the current state of
things. I'd like to see AmForth around for a long time even in it's more or
less current state. And adding some new chips like Tristan mentioned would
be a good way to start once we can all come to some agreement on how to
move into the near future.

All the best,
Mark


> >
> > So, that is the way I see it. I'd like to add right up front that while I
> > am not very skilled with forth I have spent a good deal of time learning
> > how to get better with it. It is pretty much the only language I have
> > studied these last couple of years. I am time rich so I will volunteer a
> > portion of that time if there is a viable way to make AmForth feel more
> > modern. To me right now it feels like an old dusty attic. There are still
> > great things to be discovered, but they are up a creaky flight of stairs,
> > in a poorly lit room and covered in a bit of dusty age. A big part of
> that
> > for me is the Source Forge side. I use git locally and github publicly
> > (although I have used a couple other flavors of public git when needed).
> I
> > am painfully aware that there are issues in using github. I get that,
> but I
> > like the overall tool and the fact there is no cost outlay to have
> > something anyone can get at. A bugtracker, discussions, wiki etc are
> things
> > I put a lot of value in when it comes to the choice if moving happens.
> >
> > At the very least though, some sort of better way to communicate is
> > required. I love email but am finding more and more that less and less
> > people use it as a primary means of communication. So coupling that with
> > the somewhat more difficult method of the mailing list could perhaps, or
> > I'd say probably, be a deterrent for people, in particular new people, to
> > participate. I would like to have read and search access to all of the
> past
> > mailing list text though since there are a lot of really good
> conversations
> > and problem solving that have been done. If only to use that when
> bringing
> > the documentation up to date.
> >
> > And that brings up a really big part of things, the documentation.
> > The entire thing needs to be edited and overhauled. I honestly don't care
> > what flavor of markup it uses. Most that I have used are similar enough
> > that a small cheat sheet is all that is needed to be good at it. I will
> > happily take a big part of that project once a decision has been reached
> on
> > where it will live. While doing this the source tree should be cleaned up
> > as well. There are some inconsistencies with the comments and stack
> effect
> > diagrams, some things like should it be .dw $ff03 or .dw $0003. I'm
> pretty
> > sure the former is the desired way since the newer files are like that,
> as
> > well as the way that the AVR blanks to $ffff (I think). Perhaps then the
> > refcard could once again be brought up to date from scratch giving yet
> > another good thing for new people to access. I did have a look at the
> test
> > host that Tristan put up temporarily at
> > https://www.mostlymostly.uk/amforthdocs and it does seem to work
> perfectly.
> > So keeping the RST stuff (of which there is a lot in the repo) is a very
> > viable option no matter where things end up. I also was reading a gist
> > about converting from that to markdown that I have been meaning to try to
> > see how well it works.
> >
> > Okay, that went on way too long. But I did want to address the group
> since
> > I have found so much value here in the last couple of years. I'll leave
> the
> > quoted bit below from the original message since Tristan was very concise
> > about things. I hope there are no hard feelings for dicing up this
> message
> > to make it as legible as possible.  I would like to see a more lively
> > official AmForth home wherever and however it will end up.
> >
> > All the best,
> > Mark
> >
> > What would I like to see longer term?
> >>
> >> 1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It
> >> would be great to see AmForth running on, say, an ATmega4809 [1]. It
> >> is one of the megaAVR 0-series with newer peripherals, including a
> >> CCL. I've used similar on newer PIC mcus and they are very nice to
> >> have. Why the ATmega4809 in particular? (a) There is some support for
> >> it in avra (b) it is on the Arduino Nano Every [2] (c) it is available
> >> in 40 Pin DIP (48 pin die, minus some pads). I would be interested to
> >> know if anyone has done it/similar or how hard it might be ;)
> >>
> >> 2. For RISC-V. Of AmForth's non-avr8 branches it is the one that
> >> interests me most. The hardware used to be relatively expensive and
> >> hard to come by. Now it is not, which presents the problem of
> >> choice. It would be nice to have an approachable build for AmForth
> >> RISC-V on an inexpensive but obtainable board - but which one? Again,
> >> I would be interested in what people have done and opinions as to what
> >> might work. Additionally, has anyone got AmForth RISC-V running in a
> >> simulator?
> >>
> >> > There is something about thinking in forth that seems to be good for
> >> > my aging brain.
> >>
> >> I feel the same way.
> >>
> >> Best wishes,
> >> Tristan
> >>
> >> [1] https://www.microchip.com/en-us/product/atmega4809
> >> [2] https://docs.arduino.cc/hardware/nano-every
> >> [3] https://docs.github.com/pages
> >> _______________________________________________
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> So. Epilogue of sorts. I still like to work with amForth, I am
> still in no position to really understand, how the core works. I
> could get there if absolutely needed. Matthias mentioned, that
> he was developing it in the AVR Simulator that comes with the
> Atmel tools. I accept that I have to write ISR callback
> functions entirely in assembly, because of that bug that got
> fixed in 6.9 iirc. I still do simple stuff, and a atmega644pa is
> "big".
>
> Cheers,
> Erich
>
> --
> May the Forth be with you ...
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Maintainer(s) for AmForth

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

On 9/26/23 23:33, Mark Roth wrote:
> Hello AmForth'ers. I like to see this little blip of activity and hope more
> of the less than usual suspects join in with their thoughts!

I'm one of those "less usual" suspects, so l'll jump in. For those with 
long memories my one claim to fame in the amforth community is that I 
wrote the original version of amforth-shell.py. The project I originally 
wrote that for wrapped up many years ago now and I have not had time to 
do much of anything with my list of microcontroller project ideas where 
amforth is most applicable since. I hope to get back to it though, which 
is why I continue to follow the mailing list.

> I have played around with your git repos quite a lot this summer. I really
> wanted the branches one to work so that each branch could have been tagged
> and merged upward to the current state. That just won't work. There are far
> too many breaking changes, or things that just didn't get captured as
> commits or something. While it is nice to have all the releases easy to
> swap to by changing branches, it's not really what branches are for. I have
> to agree that the way things are with the releases off to the side is the
> best solution.
>
> I have not spent as much time poking around sourcehut but from what I did
> see it is pretty much as listed on the tin, a git repo. If the cost is
> relatively low I guess that isn't much of an issue but it would still need
> to be integrated with the rest of the tools for bug reporting, discussions
> etc. It seems like it could end up making more work and be even more
> difficult to maintain long term or when more or less dormant.
On this topic, I would say that I am very much for moving to some 
git-based source control system. I'm not particular about which "forge" 
hosts it.
> That being said: I am still somewhat hesitant to move everything
It definitely looks like a fair amount of work!
> lol, by definition '3' is probably too many to merely constitute a majority
> ;)
> The point I was, as I'm sure you sussed out, is that I'd really like to
> find out what people want to do, but also that something needs to be done
> sooner rather than later. If it is only one person it is nothing more than
> another splinter fork.
It would be great to see a group of maintainers form who collectively 
could contribute enough time to build more momentum in the project 
again. I personally can't commit to doing much in the near-term 
unfortunately.
>> 2. Make a 7.0 release at that time including
>>>> a. the avra build
>>>> b. an up to date version of the project makefile
>>>> c. at least the first layers of documentation brought up to date
>>>> d. the prebuilt hex files (really just a cleaning of the project
>>>> directory in general)
>> I personally think, the avra build is important. This was the
>> remaining head ache for me, relying on a piece of proprietary
>> software, which might break at the least convenient time. Now I
>> do accept, that not everyone is on Linux/*BSD.
>>
> I totally agree and Tristan has also voiced the same. The avra stuff is a
> little bit of a head-scratcher for me since I wanted to enclose it in the
> AmForth repo in a stable state. There is virtually no activity for years on
> either the Rob3rt repo or the other fix fork by srtlg. The thing is, just
> as with the conversion from AmForth CVS to git, I want all the histories
> maintained but not so much the hassle of an unknown repo. The best solution
> I came up with my brother (who is a developer) is to fork it to a personal
> repo then use that. That is sort of but not exactly what I tried. I forked
> it, updated it then yanked out just enough of the code and put it in a new
> location in my AmForth git repo with the windows version and allowed for
> building it from the appl makefile if needed. That still needs work but as
> a process it works pretty well. The real way to do it would be to create
> the repo as a submodule within the AmForth tree. If people are going to
> want to use avra they are going to have to build it locally anyhow. Plus,
> then they have the source which is what it is really about.

I also think that the avra build is important. The complexity of getting 
a working build environment on Linux was the biggest stumbling block I 
had in getting going for the project where I did use amforth.

One thing I would be interested in finding time to do (for myself even 
if no-one else is interested) is create a nix-shell 
<https://nixos.wiki/wiki/Development_environment_with_nix-shell> 
environment that would make all of the build tooling conveniently 
available to anyone using Nix. I have found this to be an incredibly 
powerful method for creating reproducible build environments that are 
easy to use. Note that Nix has good support for OS-X and I believe these 
days can even be used in the Windows Subsystem for Linux, so it could 
help more than just Linux users.

>> I still have a file which documents the steps to build a release
>> and the associated web site. (I'll stuff this into a separate
>> email)
>>
>> I am not a friend of prebuilt hex files, but again, other people
>> have different preferences. I'd rather push someone through
>> creating their .hex files, because it opens the world for them.
FWIW, it was the availability of pre-built hex files that caused me to 
start my project with amforth to begin with, because it gave me 
something I could get running quickly to experiment with before figuring 
out all of the complexities of the build environment. I think everyone 
has to graduate to building their own .hex files relatively quickly but 
having pre-built files is a great onboarding first-step. Following that 
up with an easy-to-obtain build environment I think would really help 
with adoption.
>> 4. Discussing what it would take to continue on with something
>>> like the RISC-V side of the repo.
>> I have created a personal fork of amForth starting at version
>> 5.0, because it did build with avra, and it is before the other
>> target platforms were included
>> - MSP430 at version 5.6
>> - RV32 at version 6.7
>> - ARM at version 6.8
>>
>> I have yet to find a stability problem in my use/setup on avr
>> amForth, which has not surfaced. I decided to go back to a
>> version with simpler overall structure (and some known bugs :)
>>
>> I agree that risc-v is the most appealing future target, I would
>> not hesitate to remove msp430 and arm and point users to
>> mecrisp.
I also think RISC-V is the most interesting future target.
> That's all I have for this morning. Anyone reading this, particularly
> someone not usually heard here please let it be known what you would like
> or not like. Or what you do or don't like about the current state of
> things. I'd like to see AmForth around for a long time even in it's more or
> less current state. And adding some new chips like Tristan mentioned would
> be a good way to start once we can all come to some agreement on how to
> move into the near future.

Whatever happens from this discussion, I'd like to say a big thank you 
to everyone that is interested in keeping amforth alive into the future. 
I'm very fond of it and would really like to see it continue to be a 
tool for those curious about how to work efficiently with their hardware.

Thanks!    Keith

Re: [Amforth] Maintainer(s) for AmForth

[Mark R. <cab...@gm...>]

On Fri, Sep 29, 2023 at 5:26 PM Keith Amidon wrote:

> On 9/26/23 23:33, Mark Roth wrote:
> > Hello AmForth'ers. I like to see this little blip of activity and hope
> more
> > of the less than usual suspects join in with their thoughts!
>
> I'm one of those "less usual" suspects, so l'll jump in. For those with
> long memories my one claim to fame in the amforth community is that I
> wrote the original version of amforth-shell.py. The project I originally
> wrote that for wrapped up many years ago now and I have not had time to
> do much of anything with my list of microcontroller project ideas where
> amforth is most applicable since. I hope to get back to it though, which
> is why I continue to follow the mailing list.
>

Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
way back when) because it had slipped my mind to get back to trying it.
I've gotten so used to using e4thcom that the tool in the repo is just
collecting figurative dust for me. Tristan W brought it up into the python3
realm some time back and I think sorted some bug or another after that.
I get the feeling there are a number of the back in the old days folks
doing the same and glancing at the mailing list. One would hope anyway.
Seeing the dates on the really old commits this past week really drove it
home just how long this project has been around. :)


> > I have played around with your git repos quite a lot this summer. I
> really
> > wanted the branches one to work so that each branch could have been
> tagged
> > and merged upward to the current state. That just won't work. There are
> far
> > too many breaking changes, or things that just didn't get captured as
> > commits or something. While it is nice to have all the releases easy to
> > swap to by changing branches, it's not really what branches are for. I
> have
> > to agree that the way things are with the releases off to the side is the
> > best solution.
> >
> > I have not spent as much time poking around sourcehut but from what I did
> > see it is pretty much as listed on the tin, a git repo. If the cost is
> > relatively low I guess that isn't much of an issue but it would still
> need
> > to be integrated with the rest of the tools for bug reporting,
> discussions
> > etc. It seems like it could end up making more work and be even more
> > difficult to maintain long term or when more or less dormant.
> On this topic, I would say that I am very much for moving to some
> git-based source control system. I'm not particular about which "forge"
> hosts it.
> > That being said: I am still somewhat hesitant to move everything
> It definitely looks like a fair amount of work!
>

The problem is that is only the half of it. One thing I didn't consider
when suggesting to move to a git based repo is the tools that do things
like generate the docs. That has always been one of the things I really
liked. The pdf version in particular is really well done. The epub is,
well, it is usable but the format isn't the best for things with codeblocks
etc. It works but even when reading on my phone I've found myself reading
pdfs more and more. Reflowable works great for novels but less great on a
small screen for manuals. So that is a thing that would have to be
addressed. Or it would have to be done locally and then just added to the
repo as part of the workflow.


> > lol, by definition '3' is probably too many to merely constitute a
> majority
> > ;)
> > The point I was, as I'm sure you sussed out, is that I'd really like to
> > find out what people want to do, but also that something needs to be done
> > sooner rather than later. If it is only one person it is nothing more
> than
> > another splinter fork.
> It would be great to see a group of maintainers form who collectively
> could contribute enough time to build more momentum in the project
> again. I personally can't commit to doing much in the near-term
> unfortunately.
> >> 2. Make a 7.0 release at that time including
> >>>> a. the avra build
> >>>> b. an up to date version of the project makefile
> >>>> c. at least the first layers of documentation brought up to date
> >>>> d. the prebuilt hex files (really just a cleaning of the project
> >>>> directory in general)
> >> I personally think, the avra build is important. This was the
> >> remaining head ache for me, relying on a piece of proprietary
> >> software, which might break at the least convenient time. Now I
> >> do accept, that not everyone is on Linux/*BSD.
> >>
> > I totally agree and Tristan has also voiced the same. The avra stuff is a
> > little bit of a head-scratcher for me since I wanted to enclose it in the
> > AmForth repo in a stable state. There is virtually no activity for years
> on
> > either the Rob3rt repo or the other fix fork by srtlg. The thing is, just
> > as with the conversion from AmForth CVS to git, I want all the histories
> > maintained but not so much the hassle of an unknown repo. The best
> solution
> > I came up with my brother (who is a developer) is to fork it to a
> personal
> > repo then use that. That is sort of but not exactly what I tried. I
> forked
> > it, updated it then yanked out just enough of the code and put it in a
> new
> > location in my AmForth git repo with the windows version and allowed for
> > building it from the appl makefile if needed. That still needs work but
> as
> > a process it works pretty well. The real way to do it would be to create
> > the repo as a submodule within the AmForth tree. If people are going to
> > want to use avra they are going to have to build it locally anyhow. Plus,
> > then they have the source which is what it is really about.
>
> I also think that the avra build is important. The complexity of getting
> a working build environment on Linux was the biggest stumbling block I
> had in getting going for the project where I did use amforth.
>

One thing I really enjoyed while testing my new makefiles (now with avra!)
was just how fast avra is compared to avrasm2 under wine. I get that part
of it is that avrasm spits out the .lst file stuff into bash while working
(and haven't bothered to see about shutting that down) but I love the idea
that I can whip up everything in seconds even on a Raspberry pi zero
original flavor board. Running wine on a zero is a non-starter which is one
of the reasons I've been keeping an eye on avra over the last few years.


> One thing I would be interested in finding time to do (for myself even
> if no-one else is interested) is create a nix-shell
> <https://nixos.wiki/wiki/Development_environment_with_nix-shell>
> environment that would make all of the build tooling conveniently
> available to anyone using Nix. I have found this to be an incredibly
> powerful method for creating reproducible build environments that are
> easy to use. Note that Nix has good support for OS-X and I believe these
> days can even be used in the Windows Subsystem for Linux, so it could
> help more than just Linux users.
>
> >> I still have a file which documents the steps to build a release
> >> and the associated web site. (I'll stuff this into a separate
> >> email)
> >>
> >> I am not a friend of prebuilt hex files, but again, other people
> >> have different preferences. I'd rather push someone through
> >> creating their .hex files, because it opens the world for them.
> FWIW, it was the availability of pre-built hex files that caused me to
> start my project with amforth to begin with, because it gave me
> something I could get running quickly to experiment with before figuring
> out all of the complexities of the build environment. I think everyone
> has to graduate to building their own .hex files relatively quickly but
> having pre-built files is a great onboarding first-step. Following that
> up with an easy-to-obtain build environment I think would really help
> with adoption.
>

I agree with this as well. Sometimes you don't want the recipe for a
cookie, you just want to try it out and see if you like it before making
your own batch.


> >> 4. Discussing what it would take to continue on with something
> >>> like the RISC-V side of the repo.
> >> I have created a personal fork of amForth starting at version
> >> 5.0, because it did build with avra, and it is before the other
> >> target platforms were included
> >> - MSP430 at version 5.6
> >> - RV32 at version 6.7
> >> - ARM at version 6.8
> >>
> >> I have yet to find a stability problem in my use/setup on avr
> >> amForth, which has not surfaced. I decided to go back to a
> >> version with simpler overall structure (and some known bugs :)
> >>
> >> I agree that risc-v is the most appealing future target, I would
> >> not hesitate to remove msp430 and arm and point users to
> >> mecrisp.
> I also think RISC-V is the most interesting future target.
> > That's all I have for this morning. Anyone reading this, particularly
> > someone not usually heard here please let it be known what you would like
> > or not like. Or what you do or don't like about the current state of
> > things. I'd like to see AmForth around for a long time even in it's more
> or
> > less current state. And adding some new chips like Tristan mentioned
> would
> > be a good way to start once we can all come to some agreement on how to
> > move into the near future.
>
> Whatever happens from this discussion, I'd like to say a big thank you
> to everyone that is interested in keeping amforth alive into the future.
> I'm very fond of it and would really like to see it continue to be a
> tool for those curious about how to work efficiently with their hardware.
>
> Thanks!    Keith
>

And a thanks to you for your past (and perhaps future) contributions!

All the best,
Mark


>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Maintainer(s) for AmForth

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

On 9/30/23 05:25, Mark Roth wrote:
> Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
> way back when) because it had slipped my mind to get back to trying it.
> I've gotten so used to using e4thcom that the tool in the repo is just
> collecting figurative dust for me. Tristan W brought it up into the python3
> realm some time back and I think sorted some bug or another after that.
> I get the feeling there are a number of the back in the old days folks
> doing the same and glancing at the mailing list. One would hope anyway.
> Seeing the dates on the really old commits this past week really drove it
> home just how long this project has been around. :)

Thanks! I'm not familiar with e4thcom. It looks interesting.

I'm curious if it also solves the primary reason I had for writing 
amforth-shell.py in the first place, which had to do with making higher 
baud rates work reliably without overrunning the very small serial input 
buffer amforth uses. When using a terminal emulator file transfer that 
just sent at maximum baud rate I frequently had problems with this on 
ATMega 328 based arduinos if the baud rate was greater than 19200 
because amforth would fall behind as it was storing new words. 
amforth-shell.py solves this problem by waiting for a positive echo of 
the character it sent before sending the next which let me run at 115k 
and greatly sped up larger file transfers while ensuring they were 
reliable. For my project I had 12+ microcontrollers I had to regularly 
reprogram with a fairly large forth program and this was necessary to 
keep myself going crazy while waiting during updates.  :-)

--- Keith

Re: [Amforth] Maintainer(s) for AmForth

[Tristan W. <ho...@tj...>]

On 30Sep23 11:35, Keith Amidon wrote:
> On 9/30/23 05:25, Mark Roth wrote:
> > Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
> > way back when) because it had slipped my mind to get back to trying it.
> > I've gotten so used to using e4thcom that the tool in the repo is just
> > collecting figurative dust for me. Tristan W brought it up into the python3
> > realm some time back and I think sorted some bug or another after that.
> > I get the feeling there are a number of the back in the old days folks
> > doing the same and glancing at the mailing list. One would hope anyway.
> > Seeing the dates on the really old commits this past week really drove it
> > home just how long this project has been around. :)
> 
> Thanks! I'm not familiar with e4thcom. It looks interesting.
> 
> I'm curious if it also solves the primary reason I had for writing
> amforth-shell.py in the first place, which had to do with making higher baud
> rates work reliably without overrunning the very small serial input buffer
> amforth uses. When using a terminal emulator file transfer that just sent at
> maximum baud rate I frequently had problems with this on ATMega 328 based
> arduinos if the baud rate was greater than 19200 because amforth would fall
> behind as it was storing new words. amforth-shell.py solves this problem by
> waiting for a positive echo of the character it sent before sending the next
> which let me run at 115k and greatly sped up larger file transfers while
> ensuring they were reliable. For my project I had 12+ microcontrollers I had
> to regularly reprogram with a fairly large forth program and this was
> necessary to keep myself going crazy while waiting during updates.  :-)
> 
> --- Keith
> 

Hello Keith,

Thank you for writing amforth-shell. For me it has been a core part of
AmForth and a key part of many of my projects. The combination of its
reliability and AmForth recognizers meant I could automate sending
both commands and data as Forth words over to an mcu running
AmForth. Human readable and with no additional effort on my part
to deal with pc-mcu communications :)

Kind regards and thanks,
Tristan

Re: [Amforth] Maintainer(s) for AmForth

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

> Thank you for writing amforth-shell. For me it has been a core part of
> AmForth and a key part of many of my projects. The combination of its
> reliability and AmForth recognizers meant I could automate sending
> both commands and data as Forth words over to an mcu running
> AmForth. Human readable and with no additional effort on my part
> to deal with pc-mcu communications :)

Thanks Tristan for this update that amforth-shell remains a reliable and 
useful tool for your applications. I always aim to build things that 
have lasting value and it makes me very happy to hear that has been your 
experience with this little tool. Hopefully all of us can work together 
to ensure that is the case for the overall amforth ecosystem well into 
the future.  :-)

-- Keith