I have been exploring the Forth programming language and specifically the Gforth implementation. I am pondering about its utilization in a "bare metal" context and I'd like to gather some insights from you all.
By "bare metal," I am referring to two distinct yet related definitions:
* Bare metal as running directly on the hardware, without the intervention of an operating system. In other words, Gforth would not operate as a guest application on top of an OS, but rather have direct access to the hardware resources.
* The ability to create an application (a set of words in Forth's context) and
cross-compile this application to run natively on the target hardware. This could potentially bypass the need for an intermediary OS, or at least minimize
its role, and ideally enhance performance. " Turn Key bare metal"
I am aware that Gforth is typically used as an interpreter running on an operating system, but I am curious if it's possible or practical to use it in a bare metal environment. Moreover, does Gforth offer any cross-compilation capabilities that could be used to create a standalone, native application for
a specific hardware platform?
Hello everyone,ideally enhance performance. " Turn Key bare metal"
I have been exploring the Forth programming language and specifically the Gforth implementation. I am pondering about its utilization in a "bare metal" context and I'd like to gather some insights from you all.
By "bare metal," I am referring to two distinct yet related definitions:
* Bare metal as running directly on the hardware, without the intervention of an operating system. In other words, Gforth would not operate as a guest application on top of an OS, but rather have direct access to the hardware resources.
* The ability to create an application (a set of words in Forth's context) and cross-compile this application to run natively on the target hardware. This could potentially bypass the need for an intermediary OS, or at least minimize its role, and
I am aware that Gforth is typically used as an interpreter running on an operating system, but I am curious if it's possible or practical to use it in a bare metal environment. Moreover, does Gforth offer any cross-compilation capabilities that couldbe used to create a standalone, native application for a specific hardware platform?
Any insights or experiences shared would be greatly appreciated. Thanks in advance for your time and knowledge.
Best,
Hello everyone,
I have been exploring the Forth programming language and specifically the G= >forth implementation. I am pondering about its utilization in a "bare metal= >" context and I'd like to gather some insights from you all.
By "bare metal," I am referring to two distinct yet related definitions:
* Bare metal as running directly on the hardware, without the intervention = >of an operating system. In other words, Gforth would not operate as a guest=
application on top of an OS, but rather have direct access to the hardware= resources.
* The ability to create an application (a set of words in Forth's context) = >and cross-compile this application to run natively on the target hardware. = >This could potentially bypass the need for an intermediary OS, or at least = >minimize its role, and ideally enhance performance. " Turn Key bare metal"= >=20
I am aware that Gforth is typically used as an interpreter running on an op= >erating system, but I am curious if it's possible or practical to use it in=
a bare metal environment.
Moreover, does Gforth offer any cross-compilatio=
n capabilities that could be used to create a standalone, native applicatio= >n for a specific hardware platform?
I appreciate your responses and insights. I should have been more specific = >initially; the intended CPU for this project is based on the ArmV8 architec= >ture, specifically in the range of 6 to 8 cores.
https://gist.github.com/jemo07/969f89c4dc20483074c4833200964821
Anton, I stumbled upon FForth, but I was unable to compile it. I haven't ye= >t dedicated much attention to the code, but I'm wondering if it's still an = >ongoing project or if it's been discontinued?
SpainHackForth
I appreciate your responses and insights. I should have been more specific =Unfortunately, "ARMv8" is ambiguous. There is ARMv8-A (with the A64 instruction set), ARMv8-M (with not A64, but A32 and T32), and ARMv8-R
initially; the intended CPU for this project is based on the ArmV8 architec= >ture, specifically in the range of 6 to 8 cores.
(I think it has A64).
https://gist.github.com/jemo07/969f89c4dc20483074c4833200964821
The mnemonics in the code look more like 6502 to me, not ARM A32/T32
or A64.
On Thursday, June 15, 2023 at 8:13:17 AM UTC-4, SpainHackForth wrote:
Hello everyone,the Gforth implementation. I am pondering about its utilization in a
I have been exploring the Forth programming language and specifically
"bare metal" context and I'd like to gather some insights from you all.
intervention of an operating system. In other words, Gforth would not
By "bare metal," I am referring to two distinct yet related definitions:
* Bare metal as running directly on the hardware, without the
operate as a guest application on top of an OS, but rather have direct
access to the hardware resources.
context) and cross-compile this application to run natively on the
* The ability to create an application (a set of words in Forth's
target hardware. This could potentially bypass the need for an
intermediary OS, or at least minimize its role, and ideally enhance >performance. " Turn Key bare metal"
an operating system, but I am curious if it's possible or practical to
I am aware that Gforth is typically used as an interpreter running on
use it in a bare metal environment. Moreover, does Gforth offer any >cross-compilation capabilities that could be used to create a
standalone, native application for a specific hardware platform?
Thanks in advance for your time and knowledge.
Any insights or experiences shared would be greatly appreciated.
Best,
Any decent Forth system can be used to write a cross-compiler for a
target system. I made one for my own self-interest (I am a hobbyist)
This was my process:
-Write a Forth Cross-assembler for the target
-Write the Cross-compiler to handle the target memory space and dictionary >-Write the primitives for the target system with Cross-compiler and Assembler >-Write the high level words using the primitives
- Compile the whole thing with the Cross-compiler
-Save the target memory image in a format you can load into memory.
As Chuck Moore put it: (Paraphrased)
"I now had an interpreter than could write an Assembler, that could write
a compiler that could compile an interpreter"
:-)
However if you really want to get some work done in the near future,
I would advise using a commercial system with all that stuff and more,
built in.
Forth Cross-compilers are kind of hard IMHO.
Hello everyone,
I have been exploring the Forth programming language and specifically
the Gforth implementation. I am pondering about its utilization in a
"bare metal" context and I'd like to gather some insights from you all.
By "bare metal," I am referring to two distinct yet related definitions:
* Bare metal as running directly on the hardware, without the
intervention of an operating system. In other words, Gforth would not
operate as a guest application on top of an OS, but rather have direct
access to the hardware resources.
* The ability to create an application (a set of words in Forth's
context) and cross-compile this application to run natively on the
target hardware. This could potentially bypass the need for an
intermediary OS, or at least minimize its role, and ideally enhance >performance. " Turn Key bare metal"
I am aware that Gforth is typically used as an interpreter running on an >operating system, but I am curious if it's possible or practical to use
it in a bare metal environment. Moreover, does Gforth offer any >cross-compilation capabilities that could be used to create a
standalone, native application for a specific hardware platform?
Any insights or experiences shared would be greatly appreciated. Thanks--
in advance for your time and knowledge.
Best,
gForth is primarily a desktop application. Serious cross compilers come from Forth Inc. and MPE.
On Thursday, June 15, 2023 at 6:34:52 AM UTC-7, Stephen Pelc wrote:
gForth is primarily a desktop application. Serious cross compilers come from
Forth Inc. and MPE.
Stephen Pelc is a super salesman! Likely learned the art from Zig Ziglar!
Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
Stephen Pelc is on the Forth-200x committee, implying that he is an expert
in Forth standards, but yet VFX fails to compile valid ANS-Forth code.
I wrote MFX for the MiniForth processor. This was an assembler, simulator and Forth cross-compiler. Was it a serious cross-compiler though???
On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
VFX is probably as ANS compliant as necesary.
MPE customers will push, if more is needed.
Juergen, give it up. Hugh is clueless.
The bug he's talking about was fixed months and months ago. However, Hugh still brags about bugs he found (and that were fixed) eight or ten years ago. Hugh has published several versions of his novice package - there are three on this box, all claiming 2009 copyright and a BSD licence.
768 lines
2379 lines
4679 lines (BUGGY)
He had a hissy fit a few weeks back, demanding that we stop looking at or using it. I'll be happy to oblige him from now on.
Stephen
--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612,
+34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads
Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
VFX is probably as ANS compliant as necesary.
MPE customers will push, if more is needed.
On Thursday, June 15, 2023 at 6:34:52 AM UTC-7, Stephen Pelc wrote:
gForth is primarily a desktop application. Serious cross compilers come from >> Forth Inc. and MPE.
Stephen Pelc is a super salesman! Likely learned the art from Zig Ziglar! Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant. Stephen Pelc is on the Forth-200x committee, implying that he is an expert
in Forth standards, but yet VFX fails to compile valid ANS-Forth code.
I wrote MFX for the MiniForth processor. This was an assembler, simulator
and Forth cross-compiler. Was it a serious cross-compiler though???
On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
VFX is probably as ANS compliant as necesary.Juergen, give it up. Hugh is clueless.
MPE customers will push, if more is needed.
On 19 Jan 2023 at 04:34:11 CET, "Hugh Aguilar" <hughag...@gmail.com>
wrote:
The bug is that this ANS-Forth compliant code causes VFX to crash: ------------------------------------------
: lit, ( val -- ) \ runtime: -- val
postpone literal ;
------------------------------------------
For the moment define LIT, as
: lit, ( val -- ) \ runtime: -- val
postpone literal ; doNotSin
An upcoming version of VFX may/will use a different fix and will not require DONOTSIN.
Stephen
On Thursday, June 22, 2023 at 2:19:34 AM UTC-7, Stephen Pelc wrote:
On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
Stephen Pelc and Juergen Pintaske are inextricably linked forever!VFX is probably as ANS compliant as necesary.Juergen, give it up. Hugh is clueless.
MPE customers will push, if more is needed.
I'm not "clueless" --- I am telling the truth that Stephen Pelc sabotaged VFX
to prevent my novice-package from working under VFX. He admitted this here: https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/wMen0WkWAQAJ Stephen Pelc is using a gross euphemism when he describes his sabotage
as a "bug" --- Stephen Pelc is a liar!
On Thursday, February 23, 2023 at 5:53:49 AM UTC-7, Stephen Pelc wrote:
On 19 Jan 2023 at 04:34:11 CET, "Hugh Aguilar" <hughag...@gmail.com> wrote:
The bug is that this ANS-Forth compliant code causes VFX to crash: ------------------------------------------
: lit, ( val -- ) \ runtime: -- val
postpone literal ;
------------------------------------------
For the moment define LIT, as
: lit, ( val -- ) \ runtime: -- val
postpone literal ; doNotSin
An upcoming version of VFX may/will use a different fix and will not require
DONOTSIN.
Stephen
Stephen Pelc's sabotage also hit my IF disambiguifier, and this sabotage is also undone with the DONOTSIN word. I'm the primary person who uses
the IF disambiguifier, so Stephen Pelc was obviously aiming his sabotage
at me (Bernd Paysan also uses disambiguifiers in his MiniOOF package,
but most likely Stephen Pelc was unaware of this and didn't realize that
his sabotage would hit anybody other than me).
If Stephen Pelc is going to be a super-salesman for MPE on comp.lang.forth, as he was doing in this thread, he should always explain to his potential customers what the word "sin" means, so this potential customers can determine whether or not they are sinners in the eyes of Stephen Pelc. Nobody will buy MPE products without first being assured that they aren't
a sinner, and he won't considered them to be sinners in the future.
What a bummer it would be for a customer to pay big money for VFX and then have Stephen Pelc sabotage VFX to prevent the customer's ANS-Forth code
from working because Stephen Pelc has determined the customer to be a sinner.
On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
VFX is probably as ANS compliant as necesary.Juergen, give it up. Hugh is clueless.
MPE customers will push, if more is needed.
The bug he's talking about was fixed months and months ago. However, Hugh still brags about bugs he found (and that were fixed) eight or ten years ago.
Hugh has published several versions of his novice package - there are three on this box, all claiming 2009 copyright and a BSD licence.
768 lines
2379 lines
4679 lines (BUGGY)
He had a hissy fit a few weeks back, demanding that we stop looking at or using it. I'll be happy to oblige him from now on.
Stephen
I'm not an altruist --- I will never provide open-source software for the good of society.
...Forth2020 has a contact page where you can make your request:
https://www.forth2020.org/beginners-to-forth/a-novice-package
...
On this Forth-200x page attacking me, they say: "grateful to Hugh Aguilar and SVFIG."
...
I insist that the Forth-200x committee stop posting
this old copy of the novice package.
On 22/07/2023 12:08 pm, Hugh Aguilar wrote:
...Forth2020 has a contact page where you can make your request:
https://www.forth2020.org/beginners-to-forth/a-novice-package
...
On this Forth-200x page attacking me, they say: "grateful to Hugh Aguilar and SVFIG."
...
I insist that the Forth-200x committee stop posting
this old copy of the novice package.
https://www.forth2020.org/home/contact
On Friday, July 21, 2023 at 9:06:34 PM UTC-7, dxforth wrote:
On 22/07/2023 12:08 pm, Hugh Aguilar wrote:
...Forth2020 has a contact page where you can make your request:
https://www.forth2020.org/beginners-to-forth/a-novice-package
...
On this Forth-200x page attacking me, they say: "grateful to Hugh Aguilar and SVFIG."
...
I insist that the Forth-200x committee stop posting
this old copy of the novice package.
https://www.forth2020.org/home/contact
Well, I sent a message to that contact page.
I have already told Stephen Pelc multiple times to stop distributing
my software against my will and he has not complied. I doubt that
there is anybody at Forth-200x who can overrule him.
I downloaded the zip file to find out what they have, and it is a new version.
I never gave them that software and I never gave them permission to distribute it, so they are lying when they say that they are grateful to me for giving it to them. Also, they are lying when they say that they got it from SVFIG. I never gave SVFIG the new copy that contains STRING-STACK.
Forth2020 is a Forth appreciation group run by Peter Forth. From what
you say you have now contacted the latter about removal of the Novice
pack from their webpage.
On Friday, July 21, 2023 at 9:06:34 PM UTC-7, dxforth wrote:
On 22/07/2023 12:08 pm, Hugh Aguilar wrote:Aguilar and SVFIG."
...
https://www.forth2020.org/beginners-to-forth/a-novice-package
...
On this Forth-200x page attacking me, they say: "grateful to Hugh
...Forth2020 has a contact page where you can make your request:
I insist that the Forth-200x committee stop posting
this old copy of the novice package.
https://www.forth2020.org/home/contact
Well, I sent a message to that contact page.
I have already told Stephen Pelc multiple times to stop distributing
my software against my will and he has not complied. I doubt that
there is anybody at Forth-200x who can overrule him.
All of the Forth-200x committee disgust me. They are so desperate to
appear to be leaders that they continue year after year to pretend that
I'm their loyal little follower. I'm not their follower! They disgust me!
All of the Forth-200x committee disgust me. They are so desperate to >appear to be leaders that they continue year after year to pretend that >I'm their loyal little follower. I'm not their follower! They disgust me! The Forth commitee and the conference organizer contribute greatly,contrary to you-know-who.
On Tuesday, June 25, 2019 at 3:35:43 PM UTC-7, Stephen Pelc wrote:
On Tue, 25 Jun 2019 06:39:51 -0700 (PDT), hughag...@gmail.com
wrote:
I don't know what they have in Africa, but I doubt that it is
any better than America, Europe, Russia, etc..
I stand by what I said.
There is nothing comparable in quality on any continent.
You are just demonstrating your ignorance and your failure to
accept that anyone else can do better than you.
Stephen
Stephen Pelc doesn't have any working code, and I don't think he is
capable of implementing a string-stack because he doesn't know
what COW (copy-on-write) is.
He has done nothing himself, but he says that anyone can do better than me.
On Monday, July 24, 2023 at 1:17:46 AM UTC-7, none albert wrote:
The Forth committee and the conference organizer have contributedAll of the Forth-200x committee disgust me. They are so desperate to >appear to be leaders that they continue year after year to pretend that >I'm their loyal little follower. I'm not their follower! They disgust me! The Forth commitee and the conference organizer contribute greatly, contrary to you-know-who.
exactly nothing in regard to a string-stack. All of the self-proclaimed Forth experts have failed miserably at implementing a string-stack
in the the entire history of the Forth language, which is about 50 years.
On Sunday, March 29, 2020 at 5:27:53 PM UTC-7, hughag...@gmail.com wrote:
On Tuesday, June 25, 2019 at 3:35:43 PM UTC-7, Stephen Pelc wrote:
On Tue, 25 Jun 2019 06:39:51 -0700 (PDT), hughag...@gmail.com
wrote:
I don't know what they have in Africa, but I doubt that it is
any better than America, Europe, Russia, etc..
I stand by what I said.
There is nothing comparable in quality on any continent.
You are just demonstrating your ignorance and your failure to
accept that anyone else can do better than you.
Stephen
Stephen Pelc doesn't have any working code, and I don't think he is capable of implementing a string-stack because he doesn't know
what COW (copy-on-write) is.
He has done nothing himself, but he says that anyone can do better than me.
I wrote STRING-STACK.4TH in 2017. It was somewhat difficult, but I finished the job in a couple of weeks working evenings and weekends.
When I started, I didn't know what COW (copy-on-write) was either. I figured this out
on my own. It seemed obvious. It was only later on that I learned the term COW
and learned that this technique was already well known --- I wasn't surprised that
I wasn't the first to invent this because it was obvious.
What is pathetic about the Forth-200x committee is that none of them
know about this obvious technique and none of them have succeeded
in writing a string-stack that used COW in half a century. Stephen Pelc doesn't
have any source-code, and there is no evidence to indicate that he knows what
COW is. All he has is a claim that an anonymous African implemented a string-stack 30 years ago that is far superior to mine. This is just typical Stephen Pelc bullshit. Most likely the anonymous African's string-stack was just a rework of Wil Baden's crap code that doesn't use COW. The Forth-200x committee are failures! They don't understand basic computer science ideas that any high-school student would know about. They contribute nothing!
Most likely the anonymous African's string-stack was
just a rework of Wil Baden's crap code that doesn't use COW.
On Monday, July 24, 2023 at 1:17:46 AM UTC-7, none albert wrote:
All of the Forth-200x committee disgust me. They are so desperate tocontrary to you-know-who.
appear to be leaders that they continue year after year to pretend that
I'm their loyal little follower. I'm not their follower! They disgust me! >> The Forth commitee and the conference organizer contribute greatly,
The Forth committee and the conference organizer have contributed
exactly nothing in regard to a string-stack. All of the self-proclaimed
Forth experts have failed miserably at implementing a string-stack
in the the entire history of the Forth language, which is about 50 years.
Most likely the anonymous African's string-stack was
just a rework of Wil Baden's crap code that doesn't use COW.
Which Wil Baden code was that? I'm not aware string stacks ever figured >highly in Forth if the literature is any indicator. Low use and lack of >development often go hand in hand. Even if someone advances the technology, >there's no guarantee it will be picked up due to lack of demand. What >definitely doesn't help is burying it.
In article <u9o13b$12f5p$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
On 25/07/2023 12:51 pm, Hugh Aguilar wrote:I get by with statically organized storage and
Most likely the anonymous African's string-stack was
just a rework of Wil Baden's crap code that doesn't use COW.
Which Wil Baden code was that? I'm not aware string stacks ever figured
highly in Forth if the literature is any indicator. Low use and lack of
development often go hand in hand. Even if someone advances the technology, >> there's no guarantee it will be picked up due to lack of demand. What
definitely doesn't help is burying it.
$@ $! $+! $C+ and $^ $/ $\
Now I'm busy with Clojure mal. There is a lot of string handling
going on, but it probably would be a term project to adapt Aguilar strings-stack. COW is worthless as future versions of Clojure needs
garbage collecting strings anyhow and Clojure shuns modification
of data structures. "Copy On Write but the Write never happens."
I seen dozen of "string stacks" by the way and no applications.
It is a favorite pass time of the likes of Aguilar to create these
package and then boast about them.
A tool can make into my library if it has been (!) used more
than 3 times, and occupies at most 3 screens.
$@ $! $+! $C+ fits in one screen and it doesn't burden the
memory. With $^ find-char-position $/ slash-from-the-front
and $\ slash-from-the back I happily analyse the comma separated
transaction lists from my bank for my taxes.
In article <u9o13b$12f5p$1...@dont-email.me>, dxforth <dxf...@gmail.com> wrote:
On 25/07/2023 12:51 pm, Hugh Aguilar wrote:
Most likely the anonymous African's string-stack was
just a rework of Wil Baden's crap code that doesn't use COW.
Which Wil Baden code was that? I'm not aware string stacks ever figured >highly in Forth if the literature is any indicator. Low use and lack of >development often go hand in hand. Even if someone advances the technology, >there's no guarantee it will be picked up due to lack of demand. What >definitely doesn't help is burying it.
I get by with statically organized storage and
$@ $! $+! $C+ and $^ $/ $\
Now I'm busy with Clojure mal. There is a lot of string handling
going on, but it probably would be a term project to adapt Aguilar strings-stack. COW is worthless as future versions of Clojure needs
garbage collecting strings anyhow and Clojure shuns modification
of data structures. "Copy On Write but the Write never happens."
I seen dozen of "string stacks" by the way and no applications.
It is a favorite pass time of the likes of Aguilar to create these
package and then boast about them.
A tool can make into my library if it has been (!) used more
than 3 times, and occupies at most 3 screens.
A tool can make into my library if it has been (!) used more
than 3 times, and occupies at most 3 screens.
$@ $! $+! $C+ fits in one screen and it doesn't burden the
memory. With $^ find-char-position $/ slash-from-the-front
and $\ slash-from-the back I happily analyse the comma separated
transaction lists from my bank for my taxes.
It would be trivial to use this for character arrays or strings. But I
never exhausted my small circular string buffer. Given that most strings
are anyhow small compared to available memory, a separate string stack
seems a rather superfluous tool.
On Tuesday, July 25, 2023 at 11:17:18 AM UTC+2, none albert wrote:
[..]
A tool can make into my library if it has been (!) used more
than 3 times, and occupies at most 3 screens.
$@ $! $+! $C+ fits in one screen and it doesn't burden the
memory. With $^ find-char-position $/ slash-from-the-front
and $\ slash-from-the back I happily analyse the comma separated
transaction lists from my bank for my taxes.
I've noticed that there are words one doesn't miss unless one sees
other use it. Here's a small selection from iForth's miscutil.frt .
In the process of writing iSPICE I needed many other string/parsing
words, but these are still in purgatory.
:ABOUT
??CR ." -- low-precision timing --"
CR ." TIMER-RESET \ ( -- )"
CR ." TIMER-PRESET \ ( u -- ) offset for .elapsed"
CR ." ?MS \ ( -- u ) ms since machine turned on"
CR ." * search the complete dfwforth directory tree."
CR ." directory any dfwforth subdirectory."
CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt par
-- ), see DOC in miscutil" ;
-marcel--
CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt parAll useful words but at any given time 90% are not needed.
-- ), see DOC in miscutil" ;
I prefer to tuck these stuff in a block file and then say
WANT TICKS
if I need the word TICKS.
(I have pontificated about additional advantages about WANT before.)
In article <7d943c24-0236-47ff...@googlegroups.com>,
Hugh Aguilar <hughag...@gmail.com> wrote:
Well, I sent a message to that contact page.Given that it was original distributed under a free license
I have already told Stephen Pelc multiple times to stop distributing
my software against my will and he has not complied. I doubt that
there is anybody at Forth-200x who can overrule him.
you cannot "tell" people anything. You can politely ask to
not distribute, but that's all.
On Sunday, February 26, 2023 at 12:26:27 AM UTC+1, Hugh Aguilar wrote:
I can't associate with soulless maintenance programmers such as DXforth, Albert van der Horst, Hans Bezemer, etc.. This just gives Tom Hart the opportunity to say: "Birds of a feather stick together." Guilt by association!Let me begin this by publicly stating that I don't want, need, require or ask
for any association with you in any way, shape or form. So relax.
...
But I'm not a maintenance programmer.
...
But maybe now you understand why I don't care about you, Hugh. Or anything you say about me. Or make me stop what I'm doing. To me, you're just a nobody
with a crazy opinion I don't care for.
Hans Bezemer
BTW, I can rip your NOVICE package till the last byte. You clearly released it under
the BSD license - and you can't revoke that. You can change the license on the next
version, but not the previous one.
...
I got an email from Peter Forth and he politely asked that he continue
to be allowed to distribute my novice package, and he insisted that
he is not associated with the Forth-200x committee in any way,
so I agreed that he can continue doing distributing it.
On Wednesday, July 26, 2023 at 1:25:19 PM UTC+2, none albert wrote:
[..]
CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt parAll useful words but at any given time 90% are not needed.
-- ), see DOC in miscutil" ;
I prefer to tuck these stuff in a block file and then say
WANT TICKS
if I need the word TICKS.
(I have pontificated about additional advantages about WANT before.)
What I've also noted (and suffer from myself) is that even a tiny obstacle >(having to load a screen or typing 'WANT sumthin') causes some people
to choose a more lengthy and clumsy solution (e.g. most teenagers
nowadays access several levels of menus to 'Copy' and 'Paste' instead
of using control keys). Consequently, I preload everything that doesn't
need a manual, and all useful words display help texts when they load
last in the queue.
-marcel--
The granular structure of a block library make it possible
to have one library for 32/64 bit linux/mswindows/mac.
On Thursday, July 27, 2023 at 5:06:28 PM UTC+2, none albert wrote:
[..]
The granular structure of a block library make it possible
to have one library for 32/64 bit linux/mswindows/mac.
I like the concept, but the implementation is based on hardware
details that are completely irrelevant by today's state of the art.
-marcel--
The granular structure of a block library make it possible
to have one library for 32/64 bit linux/mswindows/mac.
I like the concept, but the implementation is based on hardware
details that are completely irrelevant by today's state of the art. Hardware??? It is a maintenance issue.
On Friday, July 28, 2023 at 10:22:46 AM UTC+2, none albert wrote:
[..]
Hardware??? It is a maintenance issue.The granular structure of a block library make it possible
to have one library for 32/64 bit linux/mswindows/mac.
I like the concept, but the implementation is based on hardware
details that are completely irrelevant by today's state of the art.
Oh, sorry, I thought you were using blocks with 16 lines of 64
characters.
-marcel
Marcel Hendrix <mhx@iae.nl> wrote:
Oh, sorry, I thought you were using blocks with 16 lines of 64I do. That is a practical size. I bet that the size of the drawers
characters.
in your home is within 20% of the size of the drawers in mine.
My bicycles are about the same size than 1900's bicycles.
albert@cherry.(none) (albert) writes:
Marcel Hendrix <mhx@iae.nl> wrote:
Oh, sorry, I thought you were using blocks with 16 lines of 64I do. That is a practical size. I bet that the size of the drawers
characters.
in your home is within 20% of the size of the drawers in mine.
My bicycles are about the same size than 1900's bicycles.
16 lines of 64 chars always seemed a little cramped to me, even though
the 1k size fits nicely on a pair of (floppy) sectors. CRT terminals
settled upon 80x24 (or 80x25) which is probably a better indicator of the "ANSI standard drawer size" for displays. Thus ForthOS went with 80x25
with the shadow screen built in and 96 bytes at the end for filesystem metadata (i.e., 4k blocks).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 35:56:48 |
Calls: | 6,707 |
Files: | 12,239 |
Messages: | 5,353,431 |