Open joseluis opened 8 years ago
I have added some of the most starred and most recently updated Forths in the ForthStar list.
I have classified the language as Assembly
if the Forth kernel uses some standard assembly language file in its implementation. Forth
means that it's written entirely in Forth, but possibly with some Forth assembler.
Good idea, a list of Forth systems. In fact I'm preparing my own Forth systems for GitHub.
But the page title seems unprecise to me, too generic. I suggest "Forth systems on GitHub". What do you think?
Or maybe simply "Forth systems", in order to include any Forth system, even if it's not on GitHub? But there are some lists out there, for example on http://forth.org, and it would be pointless to duplicate them. A list of links to would be enough.
I have included some cross-compilers. Maybe they aren't "systems" strictly speaking? But I thought they have a place in this list.
I could add https://github.com/jacereda/fina-forth but it doesn't build with clang. Requiring gcc is a PITA and I don't feel in the mood to update it.
@larsbrinkhoff Maybe we could divide the table and create an specific one for the cross-compilers.
So many copies and forks of AmForth!
I've divided the list in main language groups, ordered them by number of stars, and added a Forth in Python and another in Lua
@programandala-net I would prefer "Forth Systems" as the title. Even though amForth and mecrisp-stellaris don't use github I think it would be fair to link to their corresponding upstream repositories.
http://mecrisp.sourceforge.net/ http://amforth.sourceforge.net/
I personally don't like git or github, my Forth systems and projects are hosted here: http://hub.darcs.net/pointfree
Also, maybe this table would be a good thing for the Forth wiki. I'm intrigued by the Ward Cunningham's "Smallest Federated Wiki" and if others are interested, it's something I could set up (as a wiki farm). I've already starting porting over content from ForthFreak, to be turned into a living wiki again.
@joseluis I was careful to make my additions in alphabetical order. But now that I see your ordering, I actually like it. One concern though: it's a pain to maintain, and when it inevitably will lose the connection to the actual number of stars, it will look bad.
@lowfatcomputing What is "the Forth wiki"? It used to be ForthFreak, I guess, but now there's this thing on GitHub, and another thing on reddit.
I'm happy to move elsewhere, as long as there's just one.
@larsbrinkhoff I didn't notice your ordering, I'm sorry. As I saw the list getting bigger, it was getting impossible to find anything there.
Yes it can be a pain to maintain. As it is right now, the only real posibility is to update an item only when someone notices its number of stars have changed. There's no need on updating everything regularly.
But I'm actually thinking on creating a web frontend for the wiki in github pages (forthhub.github.io/wiki). In there we could show a proper dynamic table with column filtering and ordering capabilites. And we could get the list of repositories / urls from the wiki page if we want to. I'd be happy to give it a go.
@joseluis Sounds cool, go for it!
En/Je/On 2015-12-18 11:44, @lowfatcomputing escribió / skribis / wrote :
I would prefer "Forth Systems" as the title. Even though amForth and mecrisp-stellaris don't use github I think it would be fair to link to their corresponding upstream repositories. I personally don't like git or github, my Forth systems and projects are hosted here:
I agree about the title "Forth systems", and including also Forth systems not hosted on GitHub.
Not sure about the best solution for Forth compilers, though: using the same list, creating a second list on the page or creating a new page.
@larsbrinkhoff I've uploaded a simple website to forthhub.github.io/wiki/forth-systems/ that shows the first implementation of the idea.
It is functional to a point. I found 2 problems that makes my original idea not being able to work fully without significant compromise and further work. Derived mainly from the following facts:
The first problem is the impossibility of making cross-domain resources from client JavaScript without having access to the server or the resources being in served in jsonp format. So we can't use a github Wiki page as the data source.
The solution I found to the first problem is to use a file in the same repository as the data source for the dynamic table. (In this case /rawdata/Forth-Systems.md which is a MarkDown file that can be edited in the same way as the wiki.
The second problem is derived from the rate limits of the GitHub api that are a mere 60 per hour. So if the api is called once per github repository, everytime a user visits the page, it stops working. It would need a way to save the fetched data.
The way I'm thinking to be able to save automatically the data back and not overloading the API unnecessarily would be to use tools like oauth.io and js-github. For example, adding the possibility (for GitHub users with push rights to this repository) of pressing a button in the page and updating the values, automatically saving them back to the repository with a commit.
This is not trivial to implement but I'm open to work on it when I have more free time, since it looks like an interesting problem.
Of course all of this problems would not exist when hosting the page in a normal hosting server, but that would have additional costs, and/or dependency on a manager. On the other side when using GitHub pages every member of ForthHub has the same access level to the data.
------------------------------------
I started the forth wiki on reddit :: https://www.reddit.com/r/Forth/wiki/index
but I like this github page :)
------------------------------------
I think tree or table are not enough to organize our data
how about using a little database ?
a simple 'database' with the following three concepts
1. data-point
2. tag-group
3. tags
<data-point>/<data-point> -- <data>
/<tag-group> -- <tags>
/<tag-group> -- <tags>
/...
- <data-point>/ is a dir
- <data-point>/<data-point> is a file
under which stores the main data
- each <tag-group> is a file
under which stores tags
for example :
name/name
/link
/lang
/cpu
/<new-group>
for example :
| Name / Link | Lang | CPU | Description |
| ------------ | ------ | ----- | ------------ |
| [AmForth](https://github.com/search?q=amforth&type=Repositories&s=updated) | Assembly | AVR, MSP430 | _(13 repositories)_ |
| [pijFORTHos](https://github.com/organix/pijFORTHos) | Assembly | ARM | Bare-metal FORTH operating system for Raspberry Pi |
amforth/amforth -- <description>
/link -- https://github.com/search?q=amforth&type=Repositories&s=updated
/lang -- assembly
/cpu -- avr msp430
'amforth/' is a dir, under it, 'amforth' 'link' 'lang' 'cpu' are all files
( the format of <description> can be markdown, for example )
pijforthos/pijforthos -- <description>
/link -- https://github.com/organix/pijFORTHos
/lang -- assembly
/cpu -- arm
------------------------------------
then you can
1. if you are using a normal server
dynamicly generate html files from the database
2. if you are using github-page
use js functions to display the database in different ways
------------------------------------
Hey @xieyuheng using a database is another good option. But the same problem remains. Where we do we host it? I propose several options.
CC @larsbrinkhoff
1) On one side I'd prefer to work in a "normal" hosting. I even have a (very small) hosting business for my clients so it will be very easy for me to host it there (either the whole site or just the database). But I woudn't want the ForthHub website depend just on me. I'd prefer to share access with more members.
In fact, I believe the login credentials to any third-party service would need to be shared among several members of the group. And try to reduce the number of dependencies on other services to a minimum.
2) On the other side I'd like to be to continue using GitHub pages because it's very transparent, and there's the possibility of using a third party service to host the database. I found about rdbhost.
Apart from the rate limitations, the main problem with accessing any database from client's JavaScript is that the login credentials to the database would be completely public which is not secure, and it would open it to vandalism.
3) My favourite option would be a mixture of the two. Hosting it in a normal hosting and setting it up so that the website files be pulled every 5 minutes from the github repository. That way every ForthHub member could modify the source. And a dump of the SQL database would be pushed to the same github repository, achieving a full transparent backup of the website without security concerns. So that even if the hosting dissapears it can easily be recreated again elsewhere. I like the versatility of this solution.
The only weak point is that we would need to register a domain name and of course several people should have access to that account. Fortunately there are several possibilities of registering a free domain, ending in .TK
, .ML
, .CF
or .GA
, like for example forth-hub.tk.
What do you guys think?
@joseluis I am looking for a single list of forth system for some time. I'd like to put your list onto https://forth-standard.org/ which is very open: the sourcecode is on github, and although I operate it, decisions are made by the Forth200x-Committee. I have already implemented a simple API for https://theforth.net/ which speaks JSON, Plain Text and Forth. So we could also make the systems available for further processing. I was actually thinking of using the wiki page as a source and parsing it with a cron job or using a hook to update the database. I think I'll also extend the contribution function for the standard to allow comments on the Forth System.
Would you be happy with that train of thought?
Thanks @GeraldWodni It seems that for now the main need that we wanted to solve quickly with the website was to be able to show a searchable and filterable list of Forth systems, so if you could have that implemented in forth-standard.org then we would have that covered.
It makes sense for me that the data comes from the ForthHub wiki page. The idea is not to centralize too much the data and sourcecode around one person, and to facilitate collaboration.
I keep seeing value in having a website frontend for the group though, for any more needs that may arise, and to be as independent as possible.
BTW, you just gave me the idea of hosting a custom API interface, in order to allow the current ForthHub website hosted in GitHub pages to overcome the static website limitations...
@joseluis I am looking for a single list of forth system for some time. I'd like to put your list onto https://forth-standard.org/ which is very open:
@GeraldWodni, a single regulary updated list of Forth systems would be of general interest, and so it should contain any kind of Forth implementation for any platform. Would it be right for forth-standard.org? Maybe a selection of standard systems, automatically extracted from the general list, would be more appropiate for the site.
Marcos Cruz http://programandala.net
@joseluis, I think the current version of the list looks great!
@programandala-net I agree with you. I I'll add a column for that. It may even make sense to leave that cell blank if the system doesn't follow any standard, and when it does to write the name of the specific one that it is compliant with.
@larsbrinkhoff thank you. I plan to keep improving it after the holidays when I have more time available.
Hi. Would http://krue.net/avrforth/ belong under "Forths in Forth"?
I don't know. If there's a base of assembly language, it wouldn't. Unless it's prefix Forth assembly language. :-)
Just realized I should probably made a new issue, moved to #60. I'm inexperienced with Forth so I don't know under which section it should go ... hoping it can be put up there somewhere, though.
For future reference, federated wiki forth content has since been created. http://uwiki.strotmann.de/view/welcome-visitors It looks like it has content from the ForthFreak wiki.
I created the federated wiki last year. I've used material from ForthFreak Wiki, but also own data.
I like the idea of the federated wiki, but the UI interface is not optimal (for me). I would prefer something that I can edit from within emacs ;)
We were having a discussion on the Forth2020 group about lists, and this list was quoted, but it seems to have large gaps in it while still covering obsolete Forth systems. I don't host on github, but I may. There is my Tachyon Forth on the Parallax P1 8-core MCU that has been very popular for the past 9 years and that I use in commercial and industrial products. This also includes TAQOZ for the more powerful and faster P2 successor which also has a cut-down version in silicon (not Flash or top metal mask).
I've have been writing industrial grade embedded Forths since the 80's and I have always made these freely available. The previous kernel I did before the Propeller was for the LPC21xx and other ARMv7-TDMI cores that I entered into a ARM design contest in 2005 as the "noPC". This was a very extensive Forth with VGA and sound and SD FAT16 filesystem etc.
How do we get these and others perhaps onto the list?
Kudos and assumptions you are well as the world stands. I am nearly entomological about my word sets. As you know a few special Forths exist. Historically I stayed targeted to my application. I always wondered how to organize a robust Forth for pc's, etc. I appreciate the capture an api, scripting or web service approach. I'd like to see your vocabulary. What do you think about Arron's 8th? Cheers, Clyde
On Mon, Jun 7, 2021 at 9:27 PM peterjak @.***> wrote:
We were having a discussion on the Forth2020 group about lists, and this list was quoted, but it seems to have large gaps in it while still covering obsolete Forth systems. I don't host on github, but I may. There is my Tachyon Forth https://sourceforge.net/projects/tachyon-forth/on the Parallax P1 8-core MCU that has been very popular for the past 9 years and that I use in commercial and industrial products. This also includes TAQOZ for the more power P2 successor which also has a cut-down version in silicon (not Flash or top metal mask).
I've have been writing industrial grade embedded Forths since the 80's and I have always made these freely available. The previous kernel I did before the Propeller was for the LPC21xx and other ARMv7-TDMI cores that I entered into a ARM design contest in 2005 https://drive.google.com/drive/folders/1PqlSoLo7cgAKB38P9A7kRf4NbVDfVBPt?usp=sharingas the "noPC". This was a very extensive Forth with VGA and sound and SD FAT16 filesystem etc.
How do we get these and others perhaps onto the list?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/19#issuecomment-856389189, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABILVRIQKH7FB6SKOMGKF3LTRV5ZTANCNFSM4BWZ5LXA .
Hello @peterjak,
How do we get these and others perhaps onto the list?
It's a wiki page that is editable by all members. I have sent you an invitation to the group.
Thanks guys, I will have some time next week to setup my code on github. In the meantime here is a Google pubdoc with the color coded dictionary list of the basic modules loaded into TAQOZ. There are many other modules too, to do with multimedia (sound, images, videos, graphics etc), as well as networking servers etc.
Added PlanckForth and updated stars in last table.
Added ForthModelT. It is more of an educational project but it is a complete language following the standard, just the "CPU" is a bit unusual.
I added Able Forth: https://github.com/ablevm/able-forth
It's quite an impressive implementation, with a meta compiler much like the one in cmFORTH. It's not an ANS standard Forth; on the other hand it has many interesting properties. It runs on top of a bytecoded virtual machine called AbleVM. The Forth running inside the virtual machine is a fully self-contained system with a persistent block-structured memory image. Forth source screens and binary data sets are easily imported into the image from the outside.
I added WAForth. I put it under 'JavaScript', although it's actually WebAssembly, and has a stand-alone native implementation.
Added zForth
We have created a wiki page to maintain a list of Forth repositories, implemented in any language, here:
https://github.com/ForthHub/wiki/wiki/Forth-Systems