What forth systems you use? #2
Comments
|
I use my pForth on Mac, Windows, Linux and embedded systems. |
|
I'm mostly toying with my own lbForth. Sometimes I test things in Gforth. |
|
I've been using amforth, flashforth, and asforth on the Atmel atmega328. |
|
I'm migrating to colorForth but I mostly use gforth and pforth. |
|
I mostly use my own dialects (Retro and Parable) on iOS, OS X, and Linux. I occasionally work with SwiftForth and gForth (on Windows and Linux, respectively). |
|
I use GForth on Linux. |
|
GForth on Linux as well, and as comparison while writing my own Forth for the 6502. |
|
Likewise, Gforth on Linux has been my primary for many years. I also occasionally use VFX Forth for Linux, which is amazingly fast. These days I am using my own Forth on an embedded CPU, SwapForth. On Thu, Mar 12, 2015 at 6:39 AM, Scot W. Stevenson <notifications@github.com
James Bowman |
|
A long time ago I used retroforth, then what I wrote myself together and now, No particular favorite at the moment. |
|
Over the years, I've used MMSForth on a TRS-80 Model 4; Blazin' Forth on a C=64; Quartus Forth on a Palm Pilot; Gforth on Linux; FigForth is the first Forth I ever got running on my PET, and I'm currently working on PETTIL, an artisanal Forth for the PET hosted here on github. Of these, my favorite would have to be Blazin' Forth, which did a really nice job of teaching me the language, exposing the C=64 hardware, bringing me into the open source world, etc... |
|
Blazin' Forth is great :) I used it for inspiration for my own C64 Forth, DurexForth. |
|
I hacked on my own not-quite-standard handwritten ARM assembly Forth, which was fun, but it's much too slow for my current project (a Gameboy emulator). For the Gameboy I need something fast that can speak to SDL2; GForth does nicely. For another project, however, I can't use GForth. That project is bare metal but not embedded (plenty of RAM and CPU power), so I need fast binaries I can ship to the bare metal opaquely, without GForth's forcing of the GPL. To make a long, confidential story short and publishable: there might be open source fallout from this project, but even if so it'll have to be Apache licenseable, and in either case to publish binaries without needing to expose 100% of the source code under GPL. I'm too new to the modern Forth world to know: are there any fast, standard(ish) Forths around that fit that bill? |
|
SP-Forth compiles to optimised x86 machine code. Documentation may be hard to read. |
|
ARM support is a not-quite-essential extra. But that's still a useful data point, thanks! |
|
I'm using Windows and SP-Forth. My favorite toy was Fig-Forth. I'm also looking at SwiftForth. |
|
I have a ARM Cortex M fig/f83ish Forth (FISH) here: |
|
@cwpjr Maybe put that on GitHub? |
|
@larsbrinkhoff FISH is a Reference Model, meaning that it is closed source. Does anyone know or have an opinion about using github to distribute "binaries" (really .hex and ..sym files and pdf documentation). With FLASH_SAVE the system can be extended... |
|
There are binary cassette tape images (*.tap files) in On Wed, Apr 8, 2015 at 3:32 PM, Clyde Willis Phillips Jr. <
|
|
@chitselb Maybe it pleases you to hear that I gave PETTIL a test ride earlier today? But I wasn't able to find any binaries even though I looked for it. "Releases" is the usual way to distribute binaries using Github. |
|
@jkotlinski I just saw this. Maybe I should be more social here. I'll see about including the binary (tmp/pettil.obj) , which can now only be built from source from the github.com/chitselb/pettil repo on a system that has Ruby, xa65 and bash. |
|
I'm running on Mac, Windows (2 platforms), Ubuntuish Linux, and Raspberry Pi. After experimenting I've settled on gforth for my relearning experience even though it doesn't run well on Android. My current plans are go through a stack of old Forth books, write some stuff for fun, and then build one of those bare metal Forths for the ARM. As I work through various books I'll probably post reviews in a respository. I know most of the written words are severely outdated but I'm old school and like to work with a text as I explore. |
|
Am Donnerstag, 27. August 2015, 13:06:59 schrieb Troy Brumley:
What kind of issues do you have with Gforth on Android? "Doesn't run well" is Bernd Paysan |
|
I use jeforth on Windows. It tops on javascrip so can do whatever javascript can with benefits of forth. This is its kernel that has only 'code' and 'end-code' at first. You build your own things then. |
|
@forthy42 I haven't been able to get past the problems with the console IO, which is a known issue with gforth on Android. Half the time your input is not echoed in a timely manner. I read about this elsewhere but decided to try it to see how bad it was. I wasn't willing to put up with it. |
|
Am Montag, 31. August 2015, 08:44:54 schrieb Troy Brumley:
It's a known issue with some keybords, which only have word-mode, no character
Ah, that issue. Some keyboards do not pass each keystroke to Gforth when it That's why I have a list of recommended keyboards. Those all work as The problem with word mode is that I'm not supposed to pass those characters I will see what I can do to work around the word-mode problem; for now, please Bernd Paysan |
|
I'll give it a whirl. I have hacker's keyboard already, but I didn't think to try it. Otherwise I enjoy gforth and am having a blast on my mac getting into the language. |
|
Am Montag, 31. August 2015, 14:39:12 schrieb Troy Brumley:
What keyboard do you use otherwise? I gave a few popular a try, and the worst Bernd Paysan |
|
I like swype for social media, but it's completely useless for precise typing. I do 95% of my social media stuff on my Galaxy Note 3. I'm not sure I could even use swype on a smaller screen :) I was able to experiment quickly with the hacker keyboard and gforth felt like gforth again. |
|
The easy way to resolve this "issue" is as follows:
* To be ANS Forth, it has to conform to the list of requirements in the
ANS Forth standard
* If the name of the system includes "forth", it is very likely to be
recognizable as Forth
* There are many interesting languages with similarities to Forth, such
as visible stacks and RPN flavor. By and large, those languages have
different names, but often, in their descriptions, mention similarities
to or influence by Forth.
In my experience, language authors have always gotten the naming right.
When it strays too far from Forth, they have changed the name.
|
|
@DRuffer no, why? |
|
@RogerLevy, I wrote "for the purposes of this group", by which I mean that it's probably not a problem to leave the interpretation of "Forth" open to each individual. As pertaining to interacting with this group. |
|
Are you going to discard coloForth from these discussions?
➢ @DRuffer no, why?
Because it fits some of your objections to compatibility (e.g. blocks and portability).
DaR
From: RogerLevy
Sent: Wednesday, June 28, 2017 10:38 AM
To: ForthHub/discussion
Cc: Dennis Ruffer; Mention
Subject: Re: [ForthHub/discussion] What forth systems you use? (#2)
@DRuffer no, why?
@AndreasKlimas that sounds totally reasonable
@ChristerNilsson it's not Forth ... I tried it out for a number of weeks, expecting an easy transition. in the concatenative family of course. but Postscript isn't Forth either
@ MitchBradley that's my attitude as well and i also think devs have done a good job of responsible naming. it definitely makes categorizing easier.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@DRuffer Well, blocks in colorforth don't even work the same way as classic blocks, so I don't see how it even holds up as an example of compatibility. True direct portability is a pipe dream, the conventional concept of it is irrelevant to Forth, when everything is so easy to add yourself. If you're going to have to potentially modify your app to port it to colorforth (and who is doing that anyway? but for arguments sake) and blocks are so easy to implement the way you want it i don't see a need for there to be blocks in every Forth for it to be called a Forth - which is a separate issue from compatibility, which I'm definitely not qualified to or interested in figuring out. (and anyway I think it's largely a lost cause in the pure sense of the word and we'll only ever have something "good enough" for Forth) |
|
@DRuffer and btw, I feel that issues of compatibility in Forth are largely a function of its lack of a namespacing system. Once it has an agreed-upon one, what flavor of block system you use won't matter anymore and it won't matter if a system has it out-of-the-box or not. |
|
RogerLevy wrote,
I would add: RPN, consistent stack cell size, stacks are visible to the programmer, has "the pearl of Forth," ie, CREATE, DOES>, and related words, which enable the programmer to make new kinds of defining words and to specify their compile-time behavior and run-time behavior separately, although not every program needs to use these. About storage, blocks, etc.: My workbench computer does not have a file or block system. I edit the source code on the PC in MultiEdit in order to have the big keyboard and full screen and file storage, and "print" (or so the PC thinks) marked blocks of text over RS-232 to the workbench computer which interprets, assembles, or compiles, as appropriate, on the fly, as little as a word at a time or as much as many pages or an entire file at a time, sometimes while doing something else at the same time. This is done without any special software on the host PC, and without leaving or suspending the editor (since it just thinks it's printing a block to an old-fashioned RS-232 printer). Any computer that can print blocks of plain text from a text editor to RS-232 could act as the host in this way. It doesn't have to be a PC or use any particular OS. The workbench computer just thinks you're typing at an RS-232 keyboard (one that sends out ASCII, not keycodes), and that you're a lightning-fast typist who never makes any mistakes; but actually the source code is coming from the PC. I set this system up when doing some automated test equipment at work in 1990. (See http://6502.org/users/garth/projects.php?project=6) The final programs were in ROM; but I worked on new portions interactively, letting the SBC do its own compilation in RAM this way. Every so often, after accumulating a fair amount of new working code, I ran the metacompiler again to transfer the new code to EPROM. A couple of years later I designed a product that ran Forth but code was again in ROM; so neither of these had a file or block system. I had to use blocks for a short time in about 1999 but I hated it. They have a few good points but these are generally greatly outweighed by their disadvantages. |
|
Blocks aren't necessarily about persistence, Chuck switched to the equivalent of |
Since Forth pre-dates that denominative by decades, I prefer to think of Factor as part of the family of Forth-like languages. |
|
Garth, thank you very much for the insight you gave.
I had to use blocks for a short time in about 1999 but I hated it. They have a few good points but these are generally greatly outweighed by their disadvantages.
do you want to share some of those disadvantages, I am relative
new to Forth and missing some experience.
thank you
|
|
@AndreasKlimas, that experience was close to 30 years ago. As I remember, an advantage of the blocks was that one or another could tell the Forth system to load a particular block, or range of blocks, based on a condition for example. But if you had to insert a block, the numbers of the blocks after it would get bumped up, so they no longer had their original block numbers. For example what had been block 61 would become 62; so if you say 61 LOAD, now you'd get the one before the one you intended. I can imagine ways to remedy that only to a limited extent. In a text file, I envision a way to get the capability of loading various sections by using labels that would be searched for, so you could say for example, "Is true? If so, load from <label_X> to <label_Y>." What you can do with text files is have several different ones and optionally INCLude or or another, meaning pull them in at that point, like calling them for compilation. I did not like that the lines were only 64 characters long. Even with shadow screens, that only made for 128 characters, and with an immovable barrier in the middle. I got more than that (132) on my monitor with the1990's MultiEdit text editor running under DOS. Yes, DOS could do more than 80 columns. I usually kept it set to 132x43, and occasionally 132x60, as much as approximately a triad of screens plus their shadow screens, viewable simultaneously; but I could tile and window it any way I wanted. Sometimes I had as many as 35 files open at once, and the editor was point-and-click, drag-and-drop, etc.. I also didn't like the blocks being only 16 lines each. If I'd change my mind and needed to add more material in the middle than would fit without losing lines off the bottom, it was a mess to fix. The professional programmers' text editor was just far more flexible. But I can see why, back in the day of very limited resources, it made sense to keep to the simple block disc interface. I sometimes wondered how it would be if blocks were 4K each, 128 columns by 32 lines. |
|
Garth, thank you for sharing your experience with source blocks.
Maybe this is the wrong place for this discussion, so I apologize.
I’m using blocks for persistence data storage. What is needed
is any kind of (simple) block management.
I think using blocks is in the spirit of simplicity.
Andreas Klimas
… Am 29.06.2017 um 09:43 schrieb Garth Wilson ***@***.***>:
@AndreasKlimas <https://github.com/andreasklimas>, that experience was close to 30 years ago. As I remember, an advantage of the blocks was that one or another could tell the Forth system to load a particular block, or range of blocks, based on a condition for example. But if you had to insert a block, the numbers of the blocks after it would get bumped up, so they no longer had their original block numbers. For example what had been block 61 would become 62; so if you say 61 LOAD, now you'd get the one before the one you intended. I can imagine ways to remedy that only to a limited extent. In a text file, I envision a way to get the capability of loading various sections by using labels that would be searched for, so you could say for example, "Is true? If so, load from <label_X> to <label_Y>."
I did not like that the lines were only 64 characters long. Even with shadow screens, that only made for 128 characters, and with an immovable barrier in the middle. I got more than that (132) on my monitor with the1990's MultiEdit text editor running under DOS. Yes, DOS could do more than 80 columns. I usually kept it set to 132x43, and occasionally 132x60, as much as approximately a triad of screens plus their shadow screens, viewable simultaneously; but I could tile and window it any way I wanted. Sometimes I had as many as 35 files open at once, and the editor was point-and-click, drag-and-drop, etc..
I also didn't like the blocks being only 16 lines each. If I'd change my mind and needed to add more material in the middle than would fit without losing lines off the bottom, it was a mess to fix.
The professional programmers' text editor was just far more flexible. But I can see why, back in the day of very limited resources, it made sense to keep to the simple block disc interface. I sometimes wondered how it would be if blocks were 4K each, 128 columns by 32 lines.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARuwI6W77zrk6_Xh8NgoxMVEfOQtXXU7ks5sI1WKgaJpZM4DnBNs>.
|
|
@AndreasKlimas True, but simplicity is an idea, and blocks are just a manifestation. They have their limitations. There was a time when they were considered all you'd need, but it's been a long time since then and computers are a lot bigger and faster. For reasons of speed and utility my old Gamecube Forth fetched blocks on demand from disk in 64kb aligned chunks. If you read from block 0 after initial load you could assume blocks 1-63 were in memory, ColorForth style. |
|
One should distinguish between blocks and screens. Blocks are a form of
software-managed virtual memory, while screens are a way of storing
source code in blocks.
I personally disliked screens intensely, for all of the reasons below
and more. They were sort of barely justifiable in the very early days
of Forth when you only had a few K of memory and maybe an 80Kbyte 8-inch
floppy disk, but it did not take long before being forced into a
sequential numerical "name space" for source objects seemed pretty
silly. And the 16x64 lines thing was famous for causing comments,
indentation, and phrasing to disappear as you ran out of space.
I found very few uses for blocks as virtual storage over my career. The
only use of block in any of my "keeper" code is inside a file system
driver, where I use it to manage a write-back cache of disk blocks
containing index information.
I know some good programmers who really like blocks, but they never
really did that much for me.
…On 6/29/2017 11:11 AM, Andreas Klimas wrote:
Garth, thank you for sharing your experience with source blocks.
Maybe this is the wrong place for this discussion, so I apologize.
I’m using blocks for persistence data storage. What is needed
is any kind of (simple) block management.
I think using blocks is in the spirit of simplicity.
Andreas Klimas
> Am 29.06.2017 um 09:43 schrieb Garth Wilson ***@***.***>:
>
> @AndreasKlimas <https://github.com/andreasklimas>, that experience
was close to 30 years ago. As I remember, an advantage of the blocks
was that one or another could tell the Forth system to load a
particular block, or range of blocks, based on a condition for
example. But if you had to insert a block, the numbers of the blocks
after it would get bumped up, so they no longer had their original
block numbers. For example what had been block 61 would become 62; so
if you say 61 LOAD, now you'd get the one before the one you intended.
I can imagine ways to remedy that only to a limited extent. In a text
file, I envision a way to get the capability of loading various
sections by using labels that would be searched for, so you could say
for example, "Is true? If so, load from <label_X> to <label_Y>."
>
> I did not like that the lines were only 64 characters long. Even
with shadow screens, that only made for 128 characters, and with an
immovable barrier in the middle. I got more than that (132) on my
monitor with the1990's MultiEdit text editor running under DOS. Yes,
DOS could do more than 80 columns. I usually kept it set to 132x43,
and occasionally 132x60, as much as approximately a triad of screens
plus their shadow screens, viewable simultaneously; but I could tile
and window it any way I wanted. Sometimes I had as many as 35 files
open at once, and the editor was point-and-click, drag-and-drop, etc..
>
> I also didn't like the blocks being only 16 lines each. If I'd
change my mind and needed to add more material in the middle than
would fit without losing lines off the bottom, it was a mess to fix.
>
> The professional programmers' text editor was just far more
flexible. But I can see why, back in the day of very limited
resources, it made sense to keep to the simple block disc interface. I
sometimes wondered how it would be if blocks were 4K each, 128 columns
by 32 lines.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARuwI6W77zrk6_Xh8NgoxMVEfOQtXXU7ks5sI1WKgaJpZM4DnBNs>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEoszYkxGbrOsfF99YCfpCMV6drJm5HDks5sJBMOgaJpZM4DnBNs>.
|
|
What about macFORTH ? Nobody :) http://bitsavers.informatik.uni-stuttgart.de/pdf/creativeSolutions/MacFORTH_1.2_Oct84.pdf |
|
MacFORTH was very influential in the '80s, and its author, Don Colburn,
was a highly respected member of the Forth community. Those of us who
knew him miss him very much. He spoke, showing his multi-tasking 68000
Forth, at the very first FIG meeting that I ever attended. Here is a
thread of reminiscences from his passing:
https://groups.google.com/forum/#!topic/comp.lang.forth/Y1db1tdl68Q
…On 6/29/2017 1:57 PM, Lecrapouille wrote:
What about macFORTH ? Nobody :)
http://bitsavers.informatik.uni-stuttgart.de/pdf/creativeSolutions/MacFORTH_1.2_Oct84.pdf
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEoszVvX-1vIbO6iNuEl6fWYqIDLYi_Kks5sJDnYgaJpZM4DnBNs>.
|
|
Don was very witty. Here is a story he told me (and Mike Perry)
firsthand, over hot wings and beer at a Rochester Forth conference: A
MacForth customer called with a problem. Don's solution was as
follows: Don instructed the customer to remove the battery from the
Mac, hold it in his right hand, and follow Don in reciting a particular
verse from the Bhagavad Gita. Upon subsequently replacing the battery,
the system worked again.
The solution, of course, depended on leaving the battery out long enough
for the "PRAM" parameter storage RAM to discharge, thus restoring
factory default configuration settings. The recitation was just to kill
time with a magical flavor.
…On 6/29/2017 8:31 PM, Mitch Bradley wrote:
MacFORTH was very influential in the '80s, and its author, Don Colburn,
was a highly respected member of the Forth community. Those of us who
knew him miss him very much. He spoke, showing his multi-tasking 68000
Forth, at the very first FIG meeting that I ever attended. Here is a
thread of reminiscences from his passing:
https://groups.google.com/forum/#!topic/comp.lang.forth/Y1db1tdl68Q
On 6/29/2017 1:57 PM, Lecrapouille wrote:
> What about macFORTH ? Nobody :)
> http://bitsavers.informatik.uni-stuttgart.de/pdf/creativeSolutions/MacFORTH_1.2_Oct84.pdf
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#2 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEoszVvX-1vIbO6iNuEl6fWYqIDLYi_Kks5sJDnYgaJpZM4DnBNs>.
>
|
|
My first Forth was on a VIM-1 board (got renamed to SYM-1); a Rockwell 6502. I hand keyed 8K of Intel hex code twice (once to key in, second one to verify). But it needed disk and I could not afford one, so I buffered 8 blocks in another 8K and wrote a driver to read/write 1K blocks to a cassette tape. Manually controlled tape movement!! Fun, fun, fun!! The blocks were just a simple unit of storage. Of course, they were numbered and called screens for source code. Oh yes, my display was a modified TV and anything more than 64 characters across was too fast for the video bandwidth. So many of the 'standards' were just practical limitations and/or convenient choices based upon the technology available at the time. They worked at the time, but that doesn't mean they ought to be kept. That said, sometimes revisiting the quaint old ways is still fun. |
|
@RigTig I used a 65c02 (CMOS, more instructions and addressing modes than NMOS) in some automated test equipment in about 1990 at work. It worked out very well. See it at http://6502.org/users/garth/projects.php?project=6 . I mentioned it further up but did not give the link. If you wander around that section of the site, I should comment that the page on my 65c02 workbench computer on which I use Forth there is quite outdated. I have github access to that site, but those oldest pages are not on it. Making additions and edits took too long there, so I started my own 6502-oriented site, http://wilsonminesco.com/, with loads of articles and information. One of the major features is the stacks treatise, at http://wilsonminesco.com/stacks/, which has 19 chapters plus appendices. While Forth is mentioned quite a few times, several chapters are about doing things in assembly in a very Forth-like way. BTW, the 65xx family has come a long way since the SYM-1, although not as far as the x86. All the off-the-shelf ones being made today are guaranteed for at least 14MHz and usually top out at about twice that (if the supporting parts can keep up, since it's only a slight exaggeration to say a read happens in basically half a cycle which is 20ns @ 25MHz, including time for glue logic), and the fastest ones are running over 200MHz (but in ASICs). The '02 is still selling in volumes over a hundred million (100,000,000) per year, but you don't see them because they're hidden as the processor at the heart of ASICs embedded in automotive, industrial, appliance, toy, and even life-support equipment. The 65816 is the 16-bit upgrade, with more instructions and addressing modes than the 65c02, and is more suitable for multitasking, multithreading, relocatable code, and compilation of higher-level languages. My 65816 Forth runs approximately 2.5 times as fast as my 65c02 Forth at a given clock speed. |
|
My current projects include working with a Forth on STM8 (by Thomas, https://github.com/TG9541/stm8ef). STM8eForth is derived from Dr. Ting's eForth. It is fun to squeeze out of a 8-bit CPU such magical things as a GCODE interpreter for a 3D printer, and multilateration (see https://en.wikipedia.org/wiki/Multilateration#Solution_with_limited_computational_resources). Someone said I needed a bigger CPU, but they haven't any idea of how much punch you can get with a well-crafted Forth solution. I've temporarily digressed into the internal implementation of the Forth and the debug module of the STM8, but that is because it is interesting and fun. |
|
@RigTig I should have commented earlier— If you still have any interest in the '02, join us on the 6502.org forum at http://forum.6502.org/ . There's a section of the forum dedicated to discussions of various Forth models on the 6502, 65816, and related microprocessors and microcontrollers. The distinguished Dr. Brad Rodriguez, author of CamelForth and somewhat of a giant in the field of Forth, is on there. |
|
I use jeforth for all small things like to remind me something at a time,
to try Microsoft AI services, or simply as a calculator to do some maths.
It works on HTA, Node.js, NW.js on Windows 10 or web browsers :
http://cdn.rawgit.com/hcchengithub/jeforth.3we/r2/index.html?cr%20.%22%20Show%20%27Hello%20ForthHub!%27%20through%20HTML%22%20cr%20%3Co%3E%20%3Ch1%3EHello%20ForthHub!!%3C/h1%3E%3C/o%3E
…On Mon, Jul 3, 2017 at 5:04 PM, Garth Wilson ***@***.***> wrote:
@RigTig <https://github.com/rigtig> I should have commented earlier— If
you still have any interest in the '02, join us on the 6502.org forum at
http://forum.6502.org/ . There's a section of the forum dedicated to
discussions of various Forth models on the 6502, 65816, and related
microprocessors and microcontrollers. The distinguished Dr. Brad Rodriguez,
author of CamelForth and somewhat of a giant in the field of Forth, is on
there.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABPKd3h_Km67UQEBozSTNQs4vvlzE7GMks5sKK6qgaJpZM4DnBNs>
.
--
Just undo it!
陳厚成 H.C. Chen
Nothing real can be threatened. Nothing unreal exists. Herein lies the
peace of God.
JavaScript Forth http://github.com/hcchengithub/jeforth.3we
|
|
Am 03.07.2017 um 13:43 schrieb H.C. Chen ***@***.***>:
I use jeforth for all small things like to remind me something at a time,
to try Microsoft AI services, or simply as a calculator to do some maths.
It works on HTA, Node.js, NW.js on Windows 10 or web browsers :
http://cdn.rawgit.com/hcchengithub/jeforth.3we/r2/index.html?cr%20.%22%20Show%20%27Hello%20ForthHub!%27%20through%20HTML%22%20cr%20%3Co%3E%20%3Ch1%3EHello%20ForthHub!!%3C/h1%3E%3C/o%3E <http://cdn.rawgit.com/hcchengithub/jeforth.3we/r2/index.html?cr%20.%22%20Show%20%27Hello%20ForthHub!%27%20through%20HTML%22%20cr%20%3Co%3E%20%3Ch1%3EHello%20ForthHub!!%3C/h1%3E%3C/o%3E>
this looks very promising.
I’m a big fan of Forth.
Unlike most Forth-developers I’m absolutely not in the business of
embedded systems.
Because of simplicity of Forth I would like to make a smooth switch from
C to Forth but don’t know which Forth I should use. HTML5 and ajax is my
daily work and I’m running many servers on Linux.
I have played with SwiftForth (and I like it :-) but unfortunately SF is 32 Bits
only and for some applications my memory mapped database already has
reached 2.5G.
Are there other Forthers around here which are not working in the area of
embedded computing (and using Forth for their work :-)
Best Wisches
Andreas Klimas
…
On Mon, Jul 3, 2017 at 5:04 PM, Garth Wilson ***@***.***>
wrote:
> @RigTig <https://github.com/rigtig> I should have commented earlier— If
> you still have any interest in the '02, join us on the 6502.org forum at
> http://forum.6502.org/ . There's a section of the forum dedicated to
> discussions of various Forth models on the 6502, 65816, and related
> microprocessors and microcontrollers. The distinguished Dr. Brad Rodriguez,
> author of CamelForth and somewhat of a giant in the field of Forth, is on
> there.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#2 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABPKd3h_Km67UQEBozSTNQs4vvlzE7GMks5sKK6qgaJpZM4DnBNs>
> .
>
--
Just undo it!
陳厚成 H.C. Chen
Nothing real can be threatened. Nothing unreal exists. Herein lies the
peace of God.
JavaScript Forth http://github.com/hcchengithub/jeforth.3we
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARuwI6LJtrfr4kC2SSFuSBzh6S1j-midks5sKNPogaJpZM4DnBNs>.
|
|
@AndreasKlimas welcome to join us with jeforth where j is JavaScript so it should work anywhere JS is available. Its kernel is 'project-k' @ https://github.com/hcchengithub/project-k , a tiny forth VM with only two words, code and end-code, so 'code Hi console.log("hello world!!") end-code' generates your 3'nd word based on project-k kernel. |
|
@GarthWilson: thanks for links. Not using 6502s right now, but good to know where to touch base. |
|
I've been using Forth on a 6809-based system for a while now, having adapted Dave Dunfield's Forth for his homebrew machine to the Ensoniq Mirage, a 1980s sampler. This has allowed me to poke at the hardware and build some diagnostic tools to help repair them, as well as making some very peculiar noises. |
|
@MitchBradley Thanks for making "blocks versus screens" clear. Thirty years ago I learned to like blocks and screens with a simple constraint: One word definition per screen. IOW, dedicate a whole block to each word in the dictionary. - Suddenly you have ample space for both definition and a good comment. And there is more. You can easily implement hypertext links in the screen editor, and add "structure headers" to the dictionary (with blocks for text) to present the words in a Smalltalk-like browser. You get new options for handling cross-development, e.g. selective loading (only words that are actually used), or single stepping the target code through the source text in the screen. Ex. www.holonforth.com/using.html. |
|
@wejgaard Kudos for taking the block/screen concept so far. |
|
@rdrop-exit Thanks - Usually, the units contain word definitions, and the name of the unit is also (made) the name of the word. But a unit can have any source chunk to interpret immediately and then gets a describing name. The chunk is loaded between the adjacent units. - For the full story (initial version 1989) see www.holonforth.com/ef89.html. Experience it in Holon86 or -11. Note: In Holonforth the editor creates the dictionary, the structure is permanent, the compiler merely inserts code addresses. |
|
@wejgaard Thanks for the explanation, very interesting approach. |
and others
My answers:
Linux: gForth, SP-Forth linux
OSX: nop
Embedded: one time was Swift Forth
The text was updated successfully, but these errors were encountered: