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.fo...@nassur.net> wrote: > Hello all, > > good to see some interest in this project again. > > > > Mark Roth <cablegu...@gmail.com> 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/ > >> 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 > > > 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/ > 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
