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
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
