Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.

For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
1. Open interpreter, write some code, test it until it works
2. Hope that SwiftForth doesn't crash and you don't loose all your progress
3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file

SwiftForth doesn't seem to have a command line arguments help in the documentation PDF, nor there seem to be a way to reset the state of a interpreter.. At least I couldn't find any. I had similar issues with other interpreters some time back, but I can't remember anymore what they were.

I'm probably missing something obvious, or there's something I don't get.

On Tuesday, 14 March 2023 at 16:25:50 UTC, Yaroslav Veremenko wrote:
> Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.
>
> For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
> 1. Open interpreter, write some code, test it until it works
> 2. Hope that SwiftForth doesn't crash and you don't loose all your progress
> 3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
> 4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file
>
> SwiftForth doesn't seem to have a command line arguments help in the documentation PDF, nor there seem to be a way to reset the state of a interpreter. At least I couldn't find any. I had similar issues with other interpreters some time back, but I can't remember anymore what they were.
>
> I'm probably missing something obvious, or there's something I don't get.

There are actually two answers to what I think is the question you are asking.

Here's my first answer :

I use UBUNTU + GFORTH + TERMINAL
(1) open the terminal in the folder where you want to save the file or have a file
(2) open file using GEDIT
(3) When you have looked or made changes close file
(4) open file using GFORTH
(5) If there are mistakes you can either :
(a) investigate at the GFORTH command line
(b) type BYE to exit GFORTH and return to the UBUNTU TERMINAL
(6) use up-arrow key to scroll back throw last few commands until you come to GEDIT filename
(7) press enter and you are back at (3) above

You can use the arrow keys to move backwards and forwards between the
editor and forth on the UBUNTU TERMINAL
** but remember you have to close the editor to go back to the TERMINAL
and you have to quit GFORTH to get back to the TERMINAL

Every forth system is different. This is just something you have to get used to.

Because you are updating the file or correcting errors, there should never been a
need to scroll through the history and copy and paste into an editor.

Hope that helps

On Tuesday, March 14, 2023 at 10:52:27 AM UTC-6, NN wrote:

> Hope that helps
Well that makes way more sense. I'll just get it on WSL in windows. That's how I imagine any modern ish language work (within a context of modern OS and disks).

To those who knows, is SwiftForth somewhat weird or is it just evaluation version?
Is there a common word/process used to reset forth environment?

Reason why I want to learn forth, is I'm in the process of designing esoteric homebrew computer for fun, and I think forth would be the best fit to run as a monitor+built-in language. But I want to actually learn it properly-ish first.

On Tuesday, March 14, 2023 at 5:25:50 PM UTC+1, Yaroslav Veremenko wrote:
> For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
> 1. Open interpreter, write some code, test it until it works
> 2. Hope that SwiftForth doesn't crash and you don't loose all your progress
> 3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
> 4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file

This method is only ok for small test and tiny applications.
I would recommend the following steps:

1. Open a text editor, e.g. Notepad
2. Type your definitions in the text editor
3. Save the text file as <name>.f

4. Copy and paste words from the text editor into the SwiftForth window
5. Test the words in SwiftForth

6. If the words do not work properly, revise the words in the text editor
7. Save the revised source file
8. Copy/paste and test the revised words again in Swiftforth

NOTE:
You will get warnings that words are redefined because your new words
override the old ones. If you don't want these warnings, type EMPTY
before pasting. This will delete all your previous definitions in SwiftForth.

9. If everything works as expected, you may also include the entire source
file into SwiftForth. For this, click the [Include a file] button in the toolbar.
This is the third button from the left with the yellow folder symbol.

I always write code in the text editor, include the file in SwiftForth, and test
everything. If something goes wrong, I revise the file, type EMPTY, and include
the revised file.

Larger applications use a load file that in turn includes libraries and other
source files.

Henry

On Tuesday, March 14, 2023 at 5:25:50 PM UTC+1, Yaroslav Veremenko wrote:
> Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.
> For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
> 1. Open interpreter, write some code, test it until it works
> 2. Hope that SwiftForth doesn't crash and you don't loose all your progress
> 3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
> 4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file

Well, obviously - you haven't tried 4tH.
(a) You can use either a gcc or Turbo Pascal like frontend - it's the same compiler.
But you won't have an interpreter, since it's a "compile only" language;
(b) You don't have a splash screen;
(c) You can't crash it. The worst that can happen is an error message;
(d) You can configure the Turbo Pascal like version to use any editor you like;
(e) It supports just about any platform you can think of - with the exception of Android and IOS;
(f) It's about 95% compatible with ANS Forth.

https://sourceforge.net/projects/forth-4th/

Hans Bezemer

On Tuesday, March 14, 2023 at 11:38:09 AM UTC-6, Heinrich Hohl wrote:

> 4. Copy and paste words from the text editor into the SwiftForth window
> 5. Test the words in SwiftForth

Still, this doesn't feel like the correct way of doing things though. I'd rather use gforth, it can be automated very easily.

> You will get warnings that words are redefined because your new words
> override the old ones. If you don't want these warnings, type EMPTY
> before pasting. This will delete all your previous definitions in SwiftForth.

That explains it. The word is not mentioned in the word index of documentation, and only briefly mentioned in the text.

On Tuesday, March 14, 2023 at 6:38:09 PM UTC+1, Heinrich Hohl wrote:
[..]
> I always write code in the text editor, include the file in SwiftForth, and test
> everything. If something goes wrong, I revise the file, type EMPTY, and include
> the revised file.

I always use ANEW -marker . You can do

[DEFINED] -foo [IF] -foo [THEN] MARKER -foo

at the start of the file (or define ANEW).

Bigger applications will use NEEDS -file etc.. ( or NEED or ... )

I also have "WHAT" . Type WHAT when a load error happens, and it will
jump into the file being included, at the correct line and cursor position.

LOCATE was mentioned already, HELP <name> may also work.
WORDS is normally extended to take a regular expression operand:

FORTH> WORDS: FILE
LIST-OPEN-FILES ?FILE$ ?FILE CURRENT-FILE:
SLURP-FILE(3) SLURP-FILE(2) SLURP-FILE(1) SLURP-FILE
FILE-BIRTH FILE-TIME FILE-EXISTS? FILE-HERE
ONLY-BASEFILENAME ONLY-FILENAME CURRENT-FILE= FILE-I//O
INCLUDE-FILE FILE-SIZE FILE-POSITION REPOSITION-FILE
RESIZE-FILE FLUSH-FILE WRITE-FILE
READ-FILE SEEK-FILE CLOSE-FILE OPEN-FILE
FILE-STATUS RENAME-FILE DELETE-FILE CREATE-FILE
MAP-FILE SOURCEFILENAME ?FILE logfile

There should be many more helper words like the above (in SwiftForth).

-marcel

On Tuesday, March 14, 2023 at 10:36:33 AM UTC-7, Yaroslav Veremenko wrote:
....
> Well that makes way more sense. I'll just get it on WSL in windows. That's how I imagine any modern ish language work (within a context of modern OS and disks).
....
Since you use Windows and WSL: I use VS Code to edit source. There are a couple colorizers for Forth in the Code extensions. Open a terminal window and run bash to start WSL. Then you can edit, save, and in bash just type 'gforth myfilename.f' to run.
There is a word called 'marker' you can use to define a point in the dictionary to forget back to and kind of restore your environment, but saying 'bye' and pressing the up arrow to reenter your bash command line to reload you file is fast and easy. Just remember to save your source file manually before running. I'm sure there's a way to configure Code to do this for you, but it hasn't been a painful enough problem for me to deal with yet.

On Tuesday, March 14, 2023 at 10:36:33 AM UTC-7, Yaroslav Veremenko wrote:
> On Tuesday, March 14, 2023 at 10:52:27 AM UTC-6, NN wrote:
>
> > Hope that helps
> Well that makes way more sense. I'll just get it on WSL in windows. That's how I imagine any modern ish language work (within a context of modern OS and disks).
>
> To those who knows, is SwiftForth somewhat weird or is it just evaluation version?
> Is there a common word/process used to reset forth environment?
>
> Reason why I want to learn forth, is I'm in the process of designing esoteric homebrew computer for fun, and I think forth would be the best fit to run as a monitor+built-in language. But I want to actually learn it properly-ish first.

SwiftForth is a professional development system. A license is a bit expensive, but I understand the evaluation version never expires. (It does post dialogs on open and close.)
> I'm in the process of designing esoteric homebrew computer for fun
Me too! I think you're exactly right, Forth is perfect for this. Using block files, a microcontroller with eeprom would be a complete system using block files (the way Forth interacted with disk long ago.) gForth supports block files, but the editor is absolutely minimal. Learn Forth first, then look into block files. I have gone about it the other way and I don't recommend it.

On Tuesday, March 14, 2023 at 11:53:51 AM UTC-6, Hans Bezemer wrote:
> Well, obviously - you haven't tried 4tH.

Thanks, I'll look into it. For now gforth works fell for me, but I saved the installer and the source. Is it possible to release win version without an installer?

On Tuesday, March 14, 2023 at 5:54:49 PM UTC-6, Van Kichline wrote:
> I'm sure there's a way to configure Code to do this for you, but it hasn't been a painful enough problem for me to deal with yet.

It's actually quite simple. .vscode/tasks.json
{ // See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "bash",
"args": [
"-c",
"\"gforth main.f\""
]
}
]
}

> Me too! I think you're exactly right, Forth is perfect for this. Using block files, a microcontroller with eeprom would be a complete system using block files (the way Forth interacted with disk long ago.) gForth supports block files, but the editor is absolutely minimal. Learn Forth first, then look into block files. I have gone about it the other way and I don't recommend it.

I've looked at the CollapseOS today, it has a tiny editor called VE that works on a block system.

On Tuesday, March 14, 2023 at 10:25:18 PM UTC-7, Yaroslav Veremenko wrote:
> On Tuesday, March 14, 2023 at 5:54:49 PM UTC-6, Van Kichline wrote:
> > I'm sure there's a way to configure Code to do this for you, but it hasn't been a painful enough problem for me to deal with yet.
> It's actually quite simple. .vscode/tasks.json
> {
> // See https://go.microsoft.com/fwlink/?LinkId=733558
> // for the documentation about the tasks.json format
> "version": "2.0.0",
> "tasks": [
> {
> "label": "build",
> "type": "shell",
> "command": "bash",
> "args": [
> "-c",
> "\"gforth main.f\""
> ]
> }
> ]
> }

Thanks for this!

Le mardi 14 mars 2023 à 17:25:50 UTC+1, Yaroslav Veremenko a écrit :
> Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.
>
> I'm probably missing something obvious, or there's something I don't get.

Try eFORTH for WINDOWS or LINUX:
https://eforth.arduino-forth.com/article/elements_introduction

Edit and INCLUDE files for eFORTH:
https://eforth.arduino-forth.com/article/installation_windows_instalWindows

Yaroslav Veremenko <werewolfprankster@gmail.com> writes:
>For example yesterday I installed SwiftForth, I read the documentation and =
>it has few pages on source management. The only word that seem to matter to=
> me in this case is INCLUDE. But it doesn't seem to go deep into how to act=
>ually use it. This is the process that I can imagine working, but it is cru=
>de, and prone to numerous mistakes:
>1. Open interpreter, write some code, test it until it works
>2. Hope that SwiftForth doesn't crash and you don't loose all your progress
>3. Scroll up through the history or list the words, and hope I copy paste s=
>tuff that's important to a separate text editor
>4. Close SwiftForth, start it again, wait for evaluation warning to expire,=
> manually type INCLUDE my-updated-file

The usual way I develop code is to write it in an editor (Emacs in my
case) that runs in parallel with a terminal window. When I want to
test and debug the code, I save it in the editor without closing the
editor, and start the Forth system in the terminal window such that it
loads the code and typically also runs it; e.g., with Gforth

gforth program.4th -e "<code> bye"

where <code> exercises the words we are currently interested in. Then
I can just continue editing the code without having to restart the
editor. Sometimes I just load the program and do interactive testing
and examining, but for debugging, I usually do the setup above. It
allows me to just run the test again by typing cursor up and enter
after inserting tracers or other debugging aids in the source code, or
after an attempt to fix the bug.

In SwiftForth you could do the equivalent with

sf "include program.4th <code> bye"

but SwiftForth is less convenient when the code produces an exception,
as it requires the user to answer a prompt.

>SwiftForth doesn't seem to have a command line arguments help in the docume=
>ntation PDF

Many Forth systems, incluing SwiftForth, but not Gforth,
text-interpret the first command-line argument (or all of them).

>nor there seem to be a way to reset the state of a interpreter=
>.

Maybe COLD. Or you could set a marker at the start of the program and
then run it when you want to reset it:

marker reset include program.4th
....
reset
marker reset include program.4th

But note that the marker does not reset any corruption you may have
left in the Forth system, it just forgets the program.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

In article <2023Mar16.095129@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Yaroslav Veremenko <werewolfprankster@gmail.com> writes:
<SNIP>
>>nor there seem to be a way to reset the state of a interpreter=
>>.
>
>Maybe COLD. Or you could set a marker at the start of the program and
>then run it when you want to reset it:
>
>marker reset include program.4th
>...
>reset
>marker reset include program.4th
>
>But note that the marker does not reset any corruption you may have
>left in the Forth system, it just forgets the program.

I don't bother with MARKER's. There is enough space to load a program
a second and third time.

Also I find no need to save a program's source all the time.
I can easily select a single definition in my editor and paste it in
Forth.

For a complicated system like the optimiser I'm working on,
I rely on REGRESS statements in the source, as a tiny difference
can trigger a failed test unexpectedly.

Different approaches suit different situation.

>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Thursday, March 16, 2023 at 3:10:04 AM UTC-6, Anton Ertl wrote:
> gforth program.4th -e "<code> bye"

Agreed. Now that I feel myself a bit more comfortable, I find using gforth much more convenient. Especially with a trial splash screen of SwiftForth. Reason I was asking about the reset is to avoid waiting on that splash screen.

On Thursday, March 16, 2023 at 6:35:06 AM UTC-6, none albert wrote:

> For a complicated system like the optimiser I'm working on,
> I rely on REGRESS statements in the source, as a tiny difference
> can trigger a failed test unexpectedly.
What are those? Quick google in the docs or forth standard website doesn't give me any hits.

In article <6735cd5c-db1b-4a8d-9c07-77e8778168bfn@googlegroups.com>,
Yaroslav Veremenko <werewolfprankster@gmail.com> wrote:
>On Thursday, March 16, 2023 at 6:35:06 AM UTC-6, none albert wrote:
>
>> For a complicated system like the optimiser I'm working on,
>> I rely on REGRESS statements in the source, as a tiny difference
>> can trigger a failed test unexpectedly.
>What are those? Quick google in the docs or forth standard website
>doesn't give me any hits.

I have discussed this at this panel. They are like C's assert().
They perform a test and failing that, they kill the program's
compilation, giving additional information.
In production REGRESS is redefined as a comment.
An example is
: add ... ;
REGRESS 1 2 add S: 3

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tuesday, March 21, 2023 at 10:14:58 AM UTC+1, none albert wrote:
[..]
> I have discussed this at this panel. They are like C's assert().
> They perform a test and failing that, they kill the program's
> compilation, giving additional information.
> In production REGRESS is redefined as a comment.
> An example is
> : add ... ;
> REGRESS 1 2 add S: 3
> Groetjes Albert

Just curious: do you some statistics on REGRESS ? (How many triggers
do you have once debugging is over?)

-marcel

In article <6d17d83f-d98e-4a21-84a0-b8e7915e00c1n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:
>On Tuesday, March 21, 2023 at 10:14:58 AM UTC+1, none albert wrote:
>[..]
>> I have discussed this at this panel. They are like C's assert().
>> They perform a test and failing that, they kill the program's
>> compilation, giving additional information.
>> In production REGRESS is redefined as a comment.
>> An example is
>> : add ... ;
>> REGRESS 1 2 add S: 3
>> Groetjes Albert
>
>Just curious: do you some statistics on REGRESS ? (How many triggers
>do you have once debugging is over?)

Essentially none. A typical situation is an Euler problem.
I keep all those asserts. At a certain point the test/toy cases
are over, and I have to alter e.g. the underlying data structures for
speed. This is the point where Chuck Moore starts over.
Then I rely on the asserts, to keep the program running.
That is stage two of the development, what you would call
debugging. It is less nerve wrecking to do clean ups.

assert's trigger occasionally, depending on the
problem at hand.

>
>-marcel

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tuesday, March 14, 2023 at 12:25:50 PM UTC-4, Yaroslav Veremenko wrote:
> Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.
>
> For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
> 1. Open interpreter, write some code, test it until it works
> 2. Hope that SwiftForth doesn't crash and you don't loose all your progress
> 3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
> 4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file
>
> SwiftForth doesn't seem to have a command line arguments help in the documentation PDF, nor there seem to be a way to reset the state of a interpreter. At least I couldn't find any. I had similar issues with other interpreters some time back, but I can't remember anymore what they were.
>
> I'm probably missing something obvious, or there's something I don't get.
I learned this trick watching someone else ( I would give credit if i could remember who) I have planned on expanding the code to make it more universal but haven't got around to it yet here is the ex. i use for gforth in ecr..fs
**************************** ecr.fs **********************************
: empty s" ---marker--- marker ---marker---" evaluate ;
: edit s" vim file.fs" system ;
: run s" file.fs" included ;
: ecr edit run ;

marker ---marker---
********************************************************************
basically replace file.fs in the code with the file you are working on....... then gforth ecr.fs ..... while in gforth type ecr <ret>
it will restore the dictionary to initial point run vim file.fs when you exit vim saving or not it will include file.fs and return you to gforth. it keeps you from compiling on top of yourself hence redefining. this should work on most forth's. otherwise setup a ~/.SwiftForth-editor script chmod +x and just call EDIT in swiftforth. i am no swiftforth expert the reason for my vagueness.

On Tuesday, March 14, 2023 at 12:25:50 PM UTC-4, Yaroslav Veremenko wrote:
> Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.
>
> For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
> 1. Open interpreter, write some code, test it until it works
> 2. Hope that SwiftForth doesn't crash and you don't loose all your progress
> 3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
> 4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file
>
> SwiftForth doesn't seem to have a command line arguments help in the documentation PDF, nor there seem to be a way to reset the state of a interpreter. At least I couldn't find any. I had similar issues with other interpreters some time back, but I can't remember anymore what they were.
>
> I'm probably missing something obvious, or there's something I don't get.
Sorry all i forgot to add the the new forth word empty needs to be the first call in file.fs
see my previous post on the file ecr.fs

Em segunda-feira, 24 de julho de 2023 às 12:34:56 UTC-3, David Gipson escreveu:
> On Tuesday, March 14, 2023 at 12:25:50 PM UTC-4, Yaroslav Veremenko wrote:
> > Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.
> >
> > For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
> > 1. Open interpreter, write some code, test it until it works
> > 2. Hope that SwiftForth doesn't crash and you don't loose all your progress
> > 3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
> > 4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file
> >
> > SwiftForth doesn't seem to have a command line arguments help in the documentation PDF, nor there seem to be a way to reset the state of a interpreter. At least I couldn't find any. I had similar issues with other interpreters some time back, but I can't remember anymore what they were.
> >
> > I'm probably missing something obvious, or there's something I don't get.
> I learned this trick watching someone else ( I would give credit if i could remember who) I have planned on expanding the code to make it more universal but haven't got around to it yet here is the ex. i use for gforth in ecr.fs
> **************************** ecr.fs **********************************
> : empty s" ---marker--- marker ---marker---" evaluate ;
> : edit s" vim file.fs" system ;
> : run s" file.fs" included ;
> : ecr edit run ;
>
> marker ---marker---
> ********************************************************************
> basically replace file.fs in the code with the file you are working on....... then gforth ecr.fs ..... while in gforth type ecr <ret>
> it will restore the dictionary to initial point run vim file.fs when you exit vim saving or not it will include file.fs and return you to gforth. it keeps you from compiling on top of yourself hence redefining. this should work on most forth's. otherwise setup a ~/.SwiftForth-editor script chmod +x and just call EDIT in swiftforth. i am no swiftforth expert the reason for my vagueness.
https://youtu.be/mvrE2ZGe-rs?t=1305

Le mardi 25 juillet 2023 à 02:33:24 UTC+2, fabianor...@gmail.com a écrit :
> Em segunda-feira, 24 de julho de 2023 às 12:34:56 UTC-3, David Gipson escreveu:
> > On Tuesday, March 14, 2023 at 12:25:50 PM UTC-4, Yaroslav Veremenko wrote:
> > > Every time I try forth, I start some interpreter, type some words, then it works and I feel like I want to learn more and want to write some code to actually try it out. But every time I hit a wall.
> > >
> > > For example yesterday I installed SwiftForth, I read the documentation and it has few pages on source management. The only word that seem to matter to me in this case is INCLUDE. But it doesn't seem to go deep into how to actually use it. This is the process that I can imagine working, but it is crude, and prone to numerous mistakes:
> > > 1. Open interpreter, write some code, test it until it works
> > > 2. Hope that SwiftForth doesn't crash and you don't loose all your progress
> > > 3. Scroll up through the history or list the words, and hope I copy paste stuff that's important to a separate text editor
> > > 4. Close SwiftForth, start it again, wait for evaluation warning to expire, manually type INCLUDE my-updated-file
> > >
> > > SwiftForth doesn't seem to have a command line arguments help in the documentation PDF, nor there seem to be a way to reset the state of a interpreter. At least I couldn't find any. I had similar issues with other interpreters some time back, but I can't remember anymore what they were.
> > >
> > > I'm probably missing something obvious, or there's something I don't get.
> > I learned this trick watching someone else ( I would give credit if i could remember who) I have planned on expanding the code to make it more universal but haven't got around to it yet here is the ex. i use for gforth in ecr.fs
> > **************************** ecr.fs **********************************
> > : empty s" ---marker--- marker ---marker---" evaluate ;
> > : edit s" vim file.fs" system ;
> > : run s" file.fs" included ;
> > : ecr edit run ;
> >
> > marker ---marker---
> > ********************************************************************
> > basically replace file.fs in the code with the file you are working on....... then gforth ecr.fs ..... while in gforth type ecr <ret>
> > it will restore the dictionary to initial point run vim file.fs when you exit vim saving or not it will include file.fs and return you to gforth. it keeps you from compiling on top of yourself hence redefining. this should work on most forth's. otherwise setup a ~/.SwiftForth-editor script chmod +x and just call EDIT in swiftforth. i am no swiftforth expert the reason for my vagueness.
> https://youtu.be/mvrE2ZGe-rs?t=1305

From Veltas repo of Christopher Leonard I use this scriptin function to add words to external file

\ github.com/Veltas/demo/blob/main/script.4th
\ Copyright 2023 Christopher Leonard - MIT Licence

: CREATE-FILE! CREATE-FILE ABORT" failed to open file" ;

: FILE-SIZE! FILE-SIZE ABORT" failed to get file size" ;

: SET-POSITION! REPOSITION-FILE ABORT" failed to reposition file" ;

: WRITE-LINE! WRITE-LINE ABORT" failed to write line to file" ;

: CLOSE-FILE! CLOSE-FILE ABORT" failed to write file" ;

: FAST-FORWARD! ( file) DUP FILE-SIZE! ROT SET-POSITION! ;

: OPEN-OR-CREATE! ( a u - file)
2DUP W/O OPEN-FILE IF
DROP W/O CREATE-FILE!
ELSE
NIP NIP
THEN ;

: APPEND-FILE! ( a u - file) OPEN-OR-CREATE! DUP FAST-FORWARD! ;

: REST-OF-LINE SOURCE >IN @ /STRING ;

: SCRIPT
PARSE-NAME APPEND-FILE!
DUP REST-OF-LINE ROT WRITE-LINE!
CLOSE-FILE! ; IMMEDIATE

0 VALUE SCRIPT-FILE

: SCRIPT((
PARSE-NAME APPEND-FILE! TO SCRIPT-FILE
BEGIN CR REFILL WHILE SOURCE S" ))" COMPARE WHILE

\ usecase
\ script a.fs 1 2 3 + + .
\ will create file named "a" containing "1 2 3 + + ." code
\ script a.fs : toto 10 0 do ." ." loop ;

this is a good way to test words in interpretor & copy the final versions to a file , like here a.fs.
this is a good helper to me :)

too

In article <eefa62f9-eab0-4c2b-af76-c062056f9937n@googlegroups.com>,
gobli...@gmail.com <goblinrieur@gmail.com> wrote:
>From Veltas repo of Christopher Leonard I use this scriptin function to
>add words to external file
>
>\ github.com/Veltas/demo/blob/main/script.4th
>\ Copyright 2023 Christopher Leonard - MIT Licence
>
>: CREATE-FILE! CREATE-FILE ABORT" failed to open file" ;

Normally these kind of stuff doesn't go wrong.
Routinely I do
CREATE-FILE THROW
Only in the debugging face it fails. Other wise you are advised
to generate more specific messages if

'complicate-stuff-that-creates-init-file CATCH DUP 31 =
ABORT" You probably tried to create an init file where you have not \
write access on the directory"

This also show why I prefer numeric identification for error situation
and I abhor the reuse of same error numbers for vastly different errors.

It is a myth that a one line abort" message does cut it.

This is the documentation of error 121 for my bsl package.

"
121 : line is not stable before character
A character is expected, so we wait for a start bit.
If the line is already in a start bit / break state, that
means that it is stuck in that state, or that we were too slow
and the sbc has already started sending.

If you get this error consistently then we are stuck in that
state.
This is indicative of
1) A wrong cable connection.
Use the -t option to diagnose your cable. Check the connections.
2) your parallel port doesn't use the standard address.
Use ` -a #### ' to specify the proper address.
(Mostly you get 134 with that problem.)

If the fault is intermittent, at least the msp430 can control
the line, but it does so erratically.
3) Your pc is too slow. Terminate time consuming processes, like
a gui.
4) A defective MSP430 or faulty bsl in MSP430. This has been
seen in combination with a wrong patch of the bsl.
"

If bsl fails you see "error 121", but you know where to look.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -