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