Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Gforth snapshot for Windows

575 views
Skip to first unread message

Bernd Paysan

unread,
Sep 29, 2016, 9:33:58 PM9/29/16
to
I've polished up the snapshots for Windows, the latest one is available
here:

http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/0.7.9_20160923/

(or https; it's a SHA-1 certificate if you wonder why Chrome shows a red
warning sign and a strike-through https; Edge is not that picky).

Apart from being the latest snapshot of Gforth, the setup.exes now are
signed with a Certum "Open Source Developer" certificate, to get rid of
the "unsigned binary from teh internetz! Danger!!!111!eleven!" terror
warning Windows 10 and its "SmartScreen protection".

Of course, since my certificate is new, it will show a terror warning
even though, but then green "unknown app" and "might damage your
computer" and you still need to click through the "more details" to be
able to install it nonetheless.

So download the setup.exes to increase my reputation ;-). I don't have a
botnet at hand to let it do this automatically, as all the bad guys do
(with a stolen identity to get the certificate... it is not like the
check would actually rule out criminals).

If someone wants to try net2o's Windows binary distribution, you can do
that as well, download here:

https://net2o.de/windows/

It needs to be installed after installing the corresponding Gforth.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

Gerry Jackson

unread,
Sep 30, 2016, 10:16:30 AM9/30/16
to
On 30/09/2016 02:33, Bernd Paysan wrote:
> I've polished up the snapshots for Windows, the latest one is available
> here:
>
> http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/0.7.9_20160923/
>
> (or https; it's a SHA-1 certificate if you wonder why Chrome shows a red
> warning sign and a strike-through https; Edge is not that picky).
>
> Apart from being the latest snapshot of Gforth, the setup.exes now are
> signed with a Certum "Open Source Developer" certificate, to get rid of
> the "unsigned binary from teh internetz! Danger!!!111!eleven!" terror
> warning Windows 10 and its "SmartScreen protection".
>
> Of course, since my certificate is new, it will show a terror warning
> even though, but then green "unknown app" and "might damage your
> computer" and you still need to click through the "more details" to be
> able to install it nonetheless.
>
> So download the setup.exes to increase my reputation ;-). I don't have a
> botnet at hand to let it do this automatically, as all the bad guys do
> (with a stolen identity to get the certificate... it is not like the
> check would actually rule out criminals).

Nor do all the anti-money laundering regulations that make life tedious
when dealing with banks in the UK.

>
> If someone wants to try net2o's Windows binary distribution, you can do
> that as well, download here:
>
> https://net2o.de/windows/
>
> It needs to be installed after installing the corresponding Gforth.
>

Thanks for an update but ...

I just tried running it through the suite of test programs

1) SUBSTITUTE doesn't seem to return the number of substitutions any
more. It used to I believe. e.g

Gforth 0.7.9_20160923, Copyright (C) 1995-2016 Free Software Foundation,
Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: mac1 s" mac1" ; ok
create buf 48 chars allot ok
s" wxyz" mac1 replaces ok
s" %mac1%" buf 20 substitute ok
.s <2> -5458752 4 ok
type wxyz ok

2) There are now a huge number of irritating warning messages. Why
should GForth warn me that:

'0.' is a double-cell integer; type `help' for more info

when I already know that

3) Ditto with (in hex mode)

defined literal BEAD as word

That's what the program is testing

4) A locals test fails, it used to work:

DECIMAL
T{ : LT31 {: A B C D E F G H I J K L M N O P :}
P O N M L K J I H G F E D C B A ; -> }T
16 BASE !
T{ 0 1 2 3 4 5 6 7 8 9 A B C D E F LT31
-> F E D C B A 9 8 7 6 5 4 3 2 1 0 }T

5) Now that GForth NAME>INTERPRET seems to return an xt for a word
without interpretation semantics we can't test that NAME>INTERPRET
returns a 0 for such words. I always recognised that might be a problem
and I suppose I'll now have to change the test. But I have to say that
some words don't do anything sensible when their interpret xt is executed
e.g.
$" RECURSE" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET
.s <1> -5418952 ok
execute .s <2> -5419160 19 ok
type %%abc%%def%%%%ghi%% ok

The string returned is from a previous test on UNESCAPE in a different
file. I'd rather a system reported an error.

6) May not be your problem but when the console window is resized any
text displayed disappears, but GForth is still working. Also the colours
for the error messages are unreadable, I had to change to white
background and black text to see what had happened. These problems
weren't in the last version I was using.

Wouldn't it be a good idea to run the suite of test programs through a
new version before you actually release it?

--
Gerry

Anton Ertl

unread,
Sep 30, 2016, 12:46:49 PM9/30/16
to
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>Nor do all the anti-money laundering regulations that make life tedious
>when dealing with banks in the UK.

Or maybe the banks just put up these regulations as justifications for
tedium that they impose for completely different (but
harder-to-swallow for the customers) reasons.

BTT: Thank you for your feedback.

>2) There are now a huge number of irritating warning messages. Why
>should GForth warn me that:
>
> '0.' is a double-cell integer; type `help' for more info
>
>when I already know that

Because Gforth does not know that you already know that. If you
actually type HELP, you get advice on how to tell Gforth that you
already know that.

>4) A locals test fails, it used to work:
>
> DECIMAL
> T{ : LT31 {: A B C D E F G H I J K L M N O P :}
> P O N M L K J I H G F E D C B A ; -> }T
> 16 BASE !
> T{ 0 1 2 3 4 5 6 7 8 9 A B C D E F LT31
> -> F E D C B A 9 8 7 6 5 4 3 2 1 0 }T

Gforth now contains a word B. Maybe we should warn about using
numbers that don't start with 0-9 or a prefix, too.

So the fix for your test is:

T{ 0 1 2 3 4 5 6 7 8 9 $A $B $C $D $E $F LT31
-> $F $E $D $C $B $A 9 8 7 6 5 4 3 2 1 0 }T

or (Forth-94):

T{ 0 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F LT31
-> 0F 0E 0D 0C 0B 0A 9 8 7 6 5 4 3 2 1 0 }T

>5) Now that GForth NAME>INTERPRET seems to return an xt for a word
>without interpretation semantics we can't test that NAME>INTERPRET
>returns a 0 for such words. I always recognised that might be a problem
>and I suppose I'll now have to change the test. But I have to say that
>some words don't do anything sensible when their interpret xt is executed
>e.g.
> $" RECURSE" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET
> .s <1> -5418952 ok
> execute .s <2> -5419160 19 ok
> type %%abc%%def%%%%ghi%% ok
>
>The string returned is from a previous test on UNESCAPE in a different
>file. I'd rather a system reported an error.

RECURSE is currently defined using a clever trick; as many clever
tricks, it has some surprising consequences. Does it have any
benefits? If not, maybe we should go back to something like

: recurse latestxt compile, ; immediate compile-only

Then you get a warning if you use RECURSE in the text interpreter in
interpretation state.

>6) May not be your problem but when the console window is resized any
>text displayed disappears, but GForth is still working. Also the colours
>for the error messages are unreadable, I had to change to white
>background and black text to see what had happened.

What colours do you normally use?

>Wouldn't it be a good idea to run the suite of test programs through a
>new version before you actually release it?

We probably should be using your test suite more, yes.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/

Jason Damisch

unread,
Sep 30, 2016, 1:17:05 PM9/30/16
to
On Thursday, September 29, 2016 at 6:33:58 PM UTC-7, Bernd Paysan wrote:

> I've polished up the snapshots for Windows, the latest one is available
> here:

Thanks for all of the effort.

Philip Smith

unread,
Sep 30, 2016, 2:46:01 PM9/30/16
to
Yes ... Very nice job... Thanks !

Gerry Jackson

unread,
Sep 30, 2016, 2:50:15 PM9/30/16
to
On 30/09/2016 17:26, Anton Ertl wrote:
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>> Nor do all the anti-money laundering regulations that make life tedious
>> when dealing with banks in the UK.
>
> Or maybe the banks just put up these regulations as justifications for
> tedium that they impose for completely different (but
> harder-to-swallow for the customers) reasons.

No I don't think so. The banks have been forced to do more detailed
checks on customers - more trouble for them as well as the customer.

>> 4) A locals test fails, it used to work:
>>
>> DECIMAL
>> T{ : LT31 {: A B C D E F G H I J K L M N O P :}
>> P O N M L K J I H G F E D C B A ; -> }T
>> 16 BASE !
>> T{ 0 1 2 3 4 5 6 7 8 9 A B C D E F LT31
>> -> F E D C B A 9 8 7 6 5 4 3 2 1 0 }T
>
> Gforth now contains a word B. Maybe we should warn about using
> numbers that don't start with 0-9 or a prefix, too.
>
> So the fix for your test is:
>
> T{ 0 1 2 3 4 5 6 7 8 9 $A $B $C $D $E $F LT31
> -> $F $E $D $C $B $A 9 8 7 6 5 4 3 2 1 0 }T
>
> or (Forth-94):
>
> T{ 0 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F LT31
> -> 0F 0E 0D 0C 0B 0A 9 8 7 6 5 4 3 2 1 0 }T

Thanks I'll make that change, but it might irritate people that haven't
implemented prefixes but, on the other hand, that might encourage them
to do so. :) I'll probably just not use hex numbers.

>
>> 5) Now that GForth NAME>INTERPRET seems to return an xt for a word
>> without interpretation semantics we can't test that NAME>INTERPRET
>> returns a 0 for such words. I always recognised that might be a problem
>> and I suppose I'll now have to change the test. But I have to say that
>> some words don't do anything sensible when their interpret xt is executed
>> e.g.
>> $" RECURSE" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET
>> .s <1> -5418952 ok
>> execute .s <2> -5419160 19 ok
>> type %%abc%%def%%%%ghi%% ok
>>
>> The string returned is from a previous test on UNESCAPE in a different
>> file. I'd rather a system reported an error.
>
> RECURSE is currently defined using a clever trick; as many clever
> tricks, it has some surprising consequences. Does it have any
> benefits?

Does executing an xt of a word with undefined interpretation semantics
have any benefit anyway. I suppose some control words could be made
useful but others like ['] just seem to compile something which is unusable.

> If not, maybe we should go back to something like
>
> : recurse latestxt compile, ; immediate compile-only
>
> Then you get a warning if you use RECURSE in the text interpreter in
> interpretation state.

That was just an aside not an error report. I was looking for a word
with undefined interpretation semantics where GForth returns 0. I
couldn't find one, which makes that part of the specification hard if
not impossible to test.

>
>> 6) May not be your problem but when the console window is resized any
>> text displayed disappears, but GForth is still working. Also the colours
>> for the error messages are unreadable, I had to change to white
>> background and black text to see what had happened.
>
> What colours do you normally use?

The default console colours were and are white text on a black
background (Windows 7 and 10 at least). While this is OK occasionally,
with prolonged use I change it do a dark colour background e.g. dark
blue or red which I find easier on the eye. I don't know if there is a
way of permanently changing the default colours of all console windows,
I've never looked. I do it by right clicking on the title bar and
selecting Properties but that only works for a console window with that
name.

Windows GForth now displays errors as red text on a black background
which is very difficult to read on my monitor. Warnings appear as dark
blue text on a black background which is even worse. Playing around with
it the only satisfactory combination seems to be a white background with
black text. At least then the red error messages and blue warnings can
be read easily. But personally I'd rather GForth didn't display errors
and warnings like that but just used the same as the main text as
selected by the user. GForth almost forces the user to use white
background with black text - unless I'm missing something, perhaps other
Windows users can comment.

--
Gerry

Bernd Paysan

unread,
Sep 30, 2016, 4:34:20 PM9/30/16
to
Am Fri, 30 Sep 2016 19:50:16 +0100 schrieb Gerry Jackson:

> Windows GForth now displays errors as red text on a black background
> which is very difficult to read on my monitor. Warnings appear as dark
> blue text on a black background which is even worse. Playing around with
> it the only satisfactory combination seems to be a white background with
> black text. At least then the red error messages and blue warnings can
> be read easily.
> But personally I'd rather GForth didn't display errors and warnings like
> that but just used the same as the main text as selected by the user.
> GForth almost forces the user to use white background with black text -
> unless I'm missing something, perhaps other Windows users can comment.

You can set the three values err-color, info-color, and warn-color to
suit your needs (best put into .gforthrc0 in your home directory).

This seems to look better on black background colors:

yellow >fg defaultcolor >bg or bold or to err-color
cyan >fg defaultcolor >bg or bold or to warn-color
green >fg defaultcolor >bg or bold or to info-color

Unfortunately, there's no way to detect if you have a black or white
background. But I can put those sane defaults into two words like white-
colors and black-colors so that you can select the appropriate colors in
a one-liner in ~/.gforthrc0.

Rod Pemberton

unread,
Sep 30, 2016, 5:27:41 PM9/30/16
to
On Fri, 30 Sep 2016 19:50:16 +0100
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote:

> >> 4) A locals test fails, it used to work:
> >>
> >> DECIMAL
> >> T{ : LT31 {: A B C D E F G H I J K L M N O P :}
> >> P O N M L K J I H G F E D C B A ; -> }T
> >> 16 BASE !
> >> T{ 0 1 2 3 4 5 6 7 8 9 A B C D E F LT31
> >> -> F E D C B A 9 8 7 6 5 4 3 2 1 0 }T
> >
> > Gforth now contains a word B. Maybe we should warn about using
> > numbers that don't start with 0-9 or a prefix, too.
> >
> > So the fix for your test is:
> >
> > T{ 0 1 2 3 4 5 6 7 8 9 $A $B $C $D $E $F LT31
> > -> $F $E $D $C $B $A 9 8 7 6 5 4 3 2 1 0 }T
> >
> > or (Forth-94):
> >
> > T{ 0 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F LT31
> > -> 0F 0E 0D 0C 0B 0A 9 8 7 6 5 4 3 2 1 0 }T
>
> Thanks I'll make that change, but it might irritate people that
> haven't implemented prefixes but, on the other hand, that might
> encourage them to do so. :) I'll probably just not use hex numbers.

So, you're going to change your code for just one word used by Gforth?
(I'm surprised Hugh hasn't made a snide comment on that yet.)

Clearly, B is non-standard and not needed for your tests. Why not just
redefine B to be B etc? Can't it be argued that Gforth shouldn't have
used B for a word? ...


Rod Pemberton

Paul Rubin

unread,
Sep 30, 2016, 5:36:33 PM9/30/16
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Gforth now contains a word B.

Is that really necessary?

Bernd Paysan

unread,
Sep 30, 2016, 6:09:18 PM9/30/16
to
Am Fri, 30 Sep 2016 16:26:45 +0000 schrieb Anton Ertl:

> Gforth now contains a word B. Maybe we should warn about using numbers
> that don't start with 0-9 or a prefix, too.

Hm, or maybe B is a bad word ;-). But we also have L and N now, too, and
those would make that test fail, as well. SwiftForth has L N B as well,
and that's the inspiration for these words.

Bernd Paysan

unread,
Sep 30, 2016, 6:15:03 PM9/30/16
to
Am Fri, 30 Sep 2016 17:28:04 -0400 schrieb Rod Pemberton:

> Clearly, B is non-standard and not needed for your tests. Why not just
> redefine B to be B etc? Can't it be argued that Gforth shouldn't have
> used B for a word? ...

Yes, it can be argued that way, but it's from SwiftForth, which inherited
it from PolyForth.

Elizabeth D. Rather

unread,
Sep 30, 2016, 7:25:51 PM9/30/16
to
On 9/30/16 12:09 PM, Bernd Paysan wrote:
> Am Fri, 30 Sep 2016 16:26:45 +0000 schrieb Anton Ertl:
>
>> Gforth now contains a word B. Maybe we should warn about using numbers
>> that don't start with 0-9 or a prefix, too.
>
> Hm, or maybe B is a bad word ;-). But we also have L and N now, too, and
> those would make that test fail, as well. SwiftForth has L N B as well,
> and that's the inspiration for these words.
>
L N and B were in Chuck's earliest Forths, and have been in FORTH, Inc.
products forever. They are part of the IDE, moving forward ( N ), back (
B ) and re-displaying ( L ) in source: blocks back in the day, and
source segments displayed by LOCATE in SwiftForth. I have never heard
that they were a problem.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Anton Ertl

unread,
Oct 1, 2016, 3:46:38 AM10/1/16
to
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>On 30/09/2016 17:26, Anton Ertl wrote:
>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>> 4) A locals test fails, it used to work:
>>>
>>> DECIMAL
>>> T{ : LT31 {: A B C D E F G H I J K L M N O P :}
>>> P O N M L K J I H G F E D C B A ; -> }T
>>> 16 BASE !
>>> T{ 0 1 2 3 4 5 6 7 8 9 A B C D E F LT31
>>> -> F E D C B A 9 8 7 6 5 4 3 2 1 0 }T
>>
>> Gforth now contains a word B. Maybe we should warn about using
>> numbers that don't start with 0-9 or a prefix, too.
>>
>> So the fix for your test is:
>>
>> T{ 0 1 2 3 4 5 6 7 8 9 $A $B $C $D $E $F LT31
>> -> $F $E $D $C $B $A 9 8 7 6 5 4 3 2 1 0 }T
>>
>> or (Forth-94):
>>
>> T{ 0 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F LT31
>> -> 0F 0E 0D 0C 0B 0A 9 8 7 6 5 4 3 2 1 0 }T
>
>Thanks I'll make that change, but it might irritate people that haven't
>implemented prefixes

The second variant won't.

>Does executing an xt of a word with undefined interpretation semantics
>have any benefit anyway. I suppose some control words could be made
>useful but others like ['] just seem to compile something which is unusable.

Yes, people have ticked compile-only words, and expected to get an xt
that performs the compilation semantics of the word when EXECUTEd.
And that also works that way in most other Forth systems.

Also, the undefined interpretation semantics did not buy any benefits
and introduced complications in various places, so we decided to get
rid of that part, and define the interpretation semantics of
compile-only words to be the same as the compilation semantics, and we
could simplify the implementation a bit.

Also, as I wrote <2015Dec...@mips.complang.tuwien.ac.at>:

|More importantly, the deviation from the conventional
|single-xt-with-immediate-flag model in the standard is spawning
|abominations like VFX's "COMPILE," (which is not (but it should be)
|equivalent to ": compile, postpone literal postpone execute ;") and
|after two decades we are diverging rather than converging in that
|area, so my thinking is that maybe we should converge on that old
|model and replace everything that does not fit it (i.e., what people
|try to do with STATE-smart words in that model) with better
|alternatives.

>That was just an aside not an error report. I was looking for a word
>with undefined interpretation semantics where GForth returns 0.

Gforth now returns an xt from NAME>INTERPRET for every word. That's
one of the simplifications we got from defining the interpretation
semantics.

> But personally I'd rather GForth didn't display errors
>and warnings like that but just used the same as the main text as
>selected by the user.

In addition to the colour choices suggested by Bernd Paysan, you can
also do

default-color is err-color
default-color is warn-color
default-color is info-color

Anton Ertl

unread,
Oct 1, 2016, 3:52:14 AM10/1/16
to
Depends on who you ask. But any words consisting only of hex digits
have the same problem. In particular, there is a standard word
FE. that has this problem.

The classical solution is not to avoid these word names, but to prefix
all numbers with a 0 that would otherwise start with a letter. These
days, we can do better, and prefix the numbers with "$".

Gerry Jackson

unread,
Oct 1, 2016, 2:42:06 PM10/1/16
to
On 30/09/2016 22:28, Rod Pemberton wrote:
> On Fri, 30 Sep 2016 19:50:16 +0100
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote:
>
>>>> 4) A locals test fails, it used to work:
>>>>
>>>> DECIMAL
>>>> T{ : LT31 {: A B C D E F G H I J K L M N O P :}
>>>> P O N M L K J I H G F E D C B A ; -> }T
>>>> 16 BASE !
>>>> T{ 0 1 2 3 4 5 6 7 8 9 A B C D E F LT31
>>>> -> F E D C B A 9 8 7 6 5 4 3 2 1 0 }T
>>>
>>> Gforth now contains a word B. Maybe we should warn about using
>>> numbers that don't start with 0-9 or a prefix, too.
>>>
>>> So the fix for your test is:
>>>
>>> T{ 0 1 2 3 4 5 6 7 8 9 $A $B $C $D $E $F LT31
>>> -> $F $E $D $C $B $A 9 8 7 6 5 4 3 2 1 0 }T
>>>
>>> or (Forth-94):
>>>
>>> T{ 0 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F LT31
>>> -> 0F 0E 0D 0C 0B 0A 9 8 7 6 5 4 3 2 1 0 }T
>>
>> Thanks I'll make that change, but it might irritate people that
>> haven't implemented prefixes but, on the other hand, that might
>> encourage them to do so. :) I'll probably just not use hex numbers.
>
> So, you're going to change your code for just one word used by Gforth?
> (I'm surprised Hugh hasn't made a snide comment on that yet.)

You're right, why should I pander to the evil developers of GForth and
members of the Forth 200X committee. In fact I should go further and use
the hex constant CD to further inconvenience the other members of the
axis of evil. Even that's not enough, I'll use base 36 constants like
DUP, SWAP and DROP to influence the Forth 200X committee into making it
mandatory for all Forth 200X words to have at least one non-alphanumeric
character. That'll teach them.

Seriously though, the test programs are meant to be standard ANS/Forth
2012 programs that contain no system specific stuff. I see no point in
leaving things in that give any known system a problem as long as the
problem is not due to that system being non-compliant with the standard.
Hex constants come into that category, so I'll avoid using them or write
0B as Anton suggests.

>
> Clearly, B is non-standard and not needed for your tests. Why not just
> redefine B to be B etc? Can't it be argued that Gforth shouldn't have
> used B for a word? ...

But they have and it seems to go back to the beloved Charles and so
'cannot be changed' :)

--
Gerry

Paul Rubin

unread,
Oct 1, 2016, 3:12:29 PM10/1/16
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> Gforth now contains a word B.
>>Is that really necessary?
> Depends on who you ask. But any words consisting only of hex digits
> have the same problem.

I wasn't even thinking about hex digits. While trying things out or
testing with Forth it's pretty convenient to use one-letter names for
symbols. There are already a few in use but adding more seems a bit
annoying.

OTOH, I didn't know that B was used by Forth systems historically, so I
guess that helps.

Bernd Paysan

unread,
Oct 1, 2016, 8:10:26 PM10/1/16
to
Am Fri, 30 Sep 2016 13:25:46 -1000 schrieb Elizabeth D. Rather:
> L N and B were in Chuck's earliest Forths, and have been in FORTH, Inc.
> products forever. They are part of the IDE, moving forward ( N ), back (
> B ) and re-displaying ( L ) in source: blocks back in the day, and
> source segments displayed by LOCATE in SwiftForth. I have never heard
> that they were a problem.

Well, Gerry Jackson's test had a little problem ;-). While Gforth didn't
have a LOCATE until recently, we choose to follow Chuck's early Forth in
syntax and semantics, when we finally implemented LOCATE.

However, IIRC, the editor commands lived in a special editor vocabulary,
and only L was visible by default, switching to the editor vocabulary
when used. That way, all those one-letter editor words like I (insert)
did not collide with normal Forth words.

In SwiftForth, B and N are globally visible, though.

Elizabeth D. Rather

unread,
Oct 1, 2016, 9:31:10 PM10/1/16
to
On 10/1/16 2:10 PM, Bernd Paysan wrote:
> Am Fri, 30 Sep 2016 13:25:46 -1000 schrieb Elizabeth D. Rather:
>> L N and B were in Chuck's earliest Forths, and have been in FORTH, Inc.
>> products forever. They are part of the IDE, moving forward ( N ), back (
>> B ) and re-displaying ( L ) in source: blocks back in the day, and
>> source segments displayed by LOCATE in SwiftForth. I have never heard
>> that they were a problem.
>
> Well, Gerry Jackson's test had a little problem ;-). While Gforth didn't
> have a LOCATE until recently, we choose to follow Chuck's early Forth in
> syntax and semantics, when we finally implemented LOCATE.
>
> However, IIRC, the editor commands lived in a special editor vocabulary,
> and only L was visible by default, switching to the editor vocabulary
> when used. That way, all those one-letter editor words like I (insert)
> did not collide with normal Forth words.
>
> In SwiftForth, B and N are globally visible, though.

True. SwiftForth doesn't have an internal editor, because it can
interface well to external editors. Incidentally, there were 3 versions
of I in earlier FORTH, Inc. products: the loop version, the editor
version (Insert), and the assembler version (the register or location
used for the Interpreter pointer), each in the appropriate wordlist, of
course.

Gerry Jackson

unread,
Oct 2, 2016, 6:14:03 AM10/2/16
to
On 30/09/2016 21:34, Bernd Paysan wrote:
> Am Fri, 30 Sep 2016 19:50:16 +0100 schrieb Gerry Jackson:
>
>> But personally I'd rather GForth didn't display errors and warnings like
>> that but just used the same as the main text as selected by the user.
>> GForth almost forces the user to use white background with black text -
>> unless I'm missing something, perhaps other Windows users can comment.
>
> You can set the three values err-color, info-color, and warn-color to
> suit your needs (best put into .gforthrc0 in your home directory).

What is .gforthrc0? I can't find it anywhere in GForth or documented in
the HTML manual, the PDF version gforth.pdf seems to have disappeared
from the download. Is it something to do with configuration of GForth
when it starts up? I see there is a file gforthrc.fs, is that anything
to do with it?

>
> This seems to look better on black background colors:
>
> yellow >fg defaultcolor >bg or bold or to err-color
> cyan >fg defaultcolor >bg or bold or to warn-color
> green >fg defaultcolor >bg or bold or to info-color
>

Those colours look fine. What text is displayed in info-color? Help
still displays white text.

> Unfortunately, there's no way to detect if you have a black or white
> background. But I can put those sane defaults into two words like white-
> colors and black-colors so that you can select the appropriate colors in
> a one-liner in ~/.gforthrc0.
>

Pardon my ignorance but what does the notation at the start of
~/.gforthrc0 mean?

--
Gerry

Gerry Jackson

unread,
Oct 2, 2016, 6:23:34 AM10/2/16
to
On 01/10/2016 08:08, Anton Ertl wrote:
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>> On 30/09/2016 17:26, Anton Ertl wrote:
>>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>>> 4) A locals test fails, it used to work:
>>>>
>>>> DECIMAL
>>>> T{ : LT31 {: A B C D E F G H I J K L M N O P :}
>>>> P O N M L K J I H G F E D C B A ; -> }T
>>>> 16 BASE !
>>>> T{ 0 1 2 3 4 5 6 7 8 9 A B C D E F LT31
>>>> -> F E D C B A 9 8 7 6 5 4 3 2 1 0 }T
>>>
>>> Gforth now contains a word B. Maybe we should warn about using
>>> numbers that don't start with 0-9 or a prefix, too.
>>>
>>> So the fix for your test is:
>>>
>>> T{ 0 1 2 3 4 5 6 7 8 9 $A $B $C $D $E $F LT31
>>> -> $F $E $D $C $B $A 9 8 7 6 5 4 3 2 1 0 }T
>>>
>>> or (Forth-94):
>>>
>>> T{ 0 1 2 3 4 5 6 7 8 9 0A 0B 0C 0D 0E 0F LT31
>>> -> 0F 0E 0D 0C 0B 0A 9 8 7 6 5 4 3 2 1 0 }T
>>
>> Thanks I'll make that change, but it might irritate people that haven't
>> implemented prefixes
>
> The second variant won't.

Sorry I meant to refer to the first variant.

>
>> Does executing an xt of a word with undefined interpretation semantics
>> have any benefit anyway. I suppose some control words could be made
>> useful but others like ['] just seem to compile something which is unusable.
>
> Yes, people have ticked compile-only words, and expected to get an xt
> that performs the compilation semantics of the word when EXECUTEd.
> And that also works that way in most other Forth systems.
>
> Also, the undefined interpretation semantics did not buy any benefits
> and introduced complications in various places, so we decided to get
> rid of that part, and define the interpretation semantics of
> compile-only words to be the same as the compilation semantics, and we
> could simplify the implementation a bit.

But if it doesn't do anything sensible what is the point. My system
returns an xt for 'undefined interpretation' words but if they are
executed it throws an exception code -14 'interpreting a compile-only word'.

>
> Also, as I wrote <2015Dec...@mips.complang.tuwien.ac.at>:
>
> |More importantly, the deviation from the conventional
> |single-xt-with-immediate-flag model in the standard is spawning
> |abominations like VFX's "COMPILE," (which is not (but it should be)
> |equivalent to ": compile, postpone literal postpone execute ;") and
> |after two decades we are diverging rather than converging in that
> |area, so my thinking is that maybe we should converge on that old
> |model and replace everything that does not fit it (i.e., what people
> |try to do with STATE-smart words in that model) with better
> |alternatives.
>
>> That was just an aside not an error report. I was looking for a word
>> with undefined interpretation semantics where GForth returns 0.
>
> Gforth now returns an xt from NAME>INTERPRET for every word. That's
> one of the simplifications we got from defining the interpretation
> semantics.

OK. So a test like that is irrelevant for GForth

>
> In addition to the colour choices suggested by Bernd Paysan, you can
> also do
>
> default-color is err-color
> default-color is warn-color
> default-color is info-color
>

Thanks.

--
Gerry

Gerry Jackson

unread,
Oct 2, 2016, 7:07:38 AM10/2/16
to
On 30/09/2016 19:50, Gerry Jackson wrote:
>> 6) May not be your problem but when the console window is resized any
>> text displayed disappears, but GForth is still working.

I just noticed it happens with my system as well. It looks like
Microsoft introduced this feature with Windows 10. Aren't they wonderful.

--
Gerry

Anton Ertl

unread,
Oct 2, 2016, 12:28:58 PM10/2/16
to
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>On 01/10/2016 08:08, Anton Ertl wrote:
>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>> Does executing an xt of a word with undefined interpretation semantics
>>> have any benefit anyway. I suppose some control words could be made
>>> useful but others like ['] just seem to compile something which is unusable.
>>
>> Yes, people have ticked compile-only words, and expected to get an xt
>> that performs the compilation semantics of the word when EXECUTEd.
>> And that also works that way in most other Forth systems.
...
>But if it doesn't do anything sensible what is the point.

My guess is that these people are using these xts in places where
performing the compilation semantics of the word makes sense.

If all of the Forth world had moved the way that Gforth had moved and
embraced Forth-94 interpretation and compilation semantics as concepts
to implement rather than as rough approximations of the speicific
implementation approach of specific systems, they could have used
COMP' for this purpose.

However, this has not happened in the last 20 years (and in
particular, cmForth, which inspired the Forth-94 approach, is no
longer relevant), and there is no reason to believe that it will
happen in the next 20 years. So, time to accept reality and go back
to systems where every word has interpretation semantics.

Anton Ertl

unread,
Oct 2, 2016, 12:38:09 PM10/2/16
to
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>On 30/09/2016 21:34, Bernd Paysan wrote:
>What is .gforthrc0? I can't find it anywhere in GForth

Type HELP, like the double warning told you.

> or documented in
>the HTML manual, the PDF version gforth.pdf seems to have disappeared
>from the download.

It is mentioned in "Invoking Gforth", although it is probably better
to separate the command-line options from the startup processing.

>Is it something to do with configuration of GForth
>when it starts up? I see there is a file gforthrc.fs, is that anything
>to do with it?

Yes and yes. gforthrc.fs contains the code that loads ~/.gforthrc0
and ~/.gforthrc.

>Pardon my ignorance but what does the notation at the start of
>~/.gforthrc0 mean?

If you mean the "~", it means your home directory. Not sure how that
concept translates to Windows.

Cecil Bayona

unread,
Oct 2, 2016, 1:14:35 PM10/2/16
to
I used Pygmy Forth for many years, it is a related to cmForth and it
served me well in creating tools for managing applications and a Network
in a Windows environment for my users. It came with a meta-compiler so I
could use it to create tiny standalone applications.


--
Cecil - k5nwa

Albert van der Horst

unread,
Oct 2, 2016, 1:36:49 PM10/2/16
to
In article <2016Oct...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>On 01/10/2016 08:08, Anton Ertl wrote:
>>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>>> Does executing an xt of a word with undefined interpretation semantics
>>>> have any benefit anyway. I suppose some control words could be made
>>>> useful but others like ['] just seem to compile something which is unusable.
>>>
>>> Yes, people have ticked compile-only words, and expected to get an xt
>>> that performs the compilation semantics of the word when EXECUTEd.
>>> And that also works that way in most other Forth systems.
>...
>>But if it doesn't do anything sensible what is the point.
>
>My guess is that these people are using these xts in places where
>performing the compilation semantics of the word makes sense.

Those people are probably clever enough to defeat the exception:

: fex STATE @ >R 1 STATE ! EXECUTE R> STATE ! ;

'IF fex

probably performs the compilation semantics on most systems.

And yes cmForth is no longer relevant.

>
>- anton

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Bernd Paysan

unread,
Oct 2, 2016, 6:40:09 PM10/2/16
to
Yes, but that's why the Gforth distribution comes with mintty. Mintty
doesn't have this problem.

The problem of the Windows console affects all programs using it,
including the Linux mode.

Bernd Paysan

unread,
Oct 2, 2016, 6:48:04 PM10/2/16
to
Am Sun, 02 Oct 2016 16:29:18 +0000 schrieb Anton Ertl:

>>Pardon my ignorance but what does the notation at the start of
>>~/.gforthrc0 mean?
>
> If you mean the "~", it means your home directory. Not sure how that
> concept translates to Windows.

Pretty well these days, there's a C:\Users\<username> directory for every
user; that's what ~ is expanded to on the Windows version.

Bernd Paysan

unread,
Oct 2, 2016, 7:00:43 PM10/2/16
to
Am Sat, 01 Oct 2016 15:31:03 -1000 schrieb Elizabeth D. Rather:

> On 10/1/16 2:10 PM, Bernd Paysan wrote:
>> However, IIRC, the editor commands lived in a special editor
>> vocabulary, and only L was visible by default, switching to the editor
>> vocabulary when used. That way, all those one-letter editor words like
>> I (insert) did not collide with normal Forth words.
>>
>> In SwiftForth, B and N are globally visible, though.
>
> True. SwiftForth doesn't have an internal editor, because it can
> interface well to external editors. Incidentally, there were 3 versions
> of I in earlier FORTH, Inc. products: the loop version, the editor
> version (Insert), and the assembler version (the register or location
> used for the Interpreter pointer), each in the appropriate wordlist, of
> course.

Still begs the question if resurrecting the EDITOR vocabulary for these
few words might be useful. Actually, the Gforth LOCATE browser does read
in the file in a way that is usable for a PolyForth-style editor, and
adding such a simple editor would be just a few dozen lines. Or adding a
full-screen editor maybe would be a line or two more (don't know how
many ;-). I would use the command line editor to edit the individual
lines, which then would give features like tab completion "for free".

lawren...@gmail.com

unread,
Oct 2, 2016, 10:51:51 PM10/2/16
to
On Saturday, October 1, 2016 at 8:52:14 PM UTC+13, Anton Ertl wrote:
> These days, we can do better, and prefix the numbers with "$".

I like the more general convention of «base»#«digits», where «base» can be any integer from 2 to 36 inclusive. For example

36#1i = 13#42 = 54

Elizabeth D. Rather

unread,
Oct 3, 2016, 3:32:48 AM10/3/16
to
On 10/2/16 1:00 PM, Bernd Paysan wrote:
> Am Sat, 01 Oct 2016 15:31:03 -1000 schrieb Elizabeth D. Rather:
>
>> On 10/1/16 2:10 PM, Bernd Paysan wrote:
>>> However, IIRC, the editor commands lived in a special editor
>>> vocabulary, and only L was visible by default, switching to the editor
>>> vocabulary when used. That way, all those one-letter editor words like
>>> I (insert) did not collide with normal Forth words.
>>>
>>> In SwiftForth, B and N are globally visible, though.
>>
>> True. SwiftForth doesn't have an internal editor, because it can
>> interface well to external editors. Incidentally, there were 3 versions
>> of I in earlier FORTH, Inc. products: the loop version, the editor
>> version (Insert), and the assembler version (the register or location
>> used for the Interpreter pointer), each in the appropriate wordlist, of
>> course.
>
> Still begs the question if resurrecting the EDITOR vocabulary for these
> few words might be useful.

It could be done in a heartbeat if anyone complained of problems with
these words. AFAIK no one has.

> Actually, the Gforth LOCATE browser does read
> in the file in a way that is usable for a PolyForth-style editor, and
> adding such a simple editor would be just a few dozen lines. Or adding a
> full-screen editor maybe would be a line or two more (don't know how
> many ;-). I would use the command line editor to edit the individual
> lines, which then would give features like tab completion "for free".

The basic polyFORTH editor was 16 lines, with a second block added to
provide a "screen editor". It was discarded because most of our users
preferred programmers' editors that they used in other projects, so it
hardly seemed worthwhile to modify it to work in files rather than blocks.

Anton Ertl

unread,
Oct 3, 2016, 3:48:04 AM10/3/16
to
alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>My guess is that these people are using these xts in places where
>>performing the compilation semantics of the word makes sense.
>
>Those people are probably clever enough to defeat the exception:
>
>: fex STATE @ >R 1 STATE ! EXECUTE R> STATE ! ;
>
>'IF fex
>
>probably performs the compilation semantics on most systems.

Gforth 0.7.2, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: fex STATE @ >R 1 STATE ! EXECUTE R> STATE ! ; ok
' if fex
:2: Cannot tick compile-only word (try COMP' ... DROP)
' >>>if<<< fex

Cecil Bayona

unread,
Oct 3, 2016, 4:46:55 AM10/3/16
to
I could see where a block editor might be handy even as a general
purpose editor, specially in embedded systems where the CPUs keep having
more and more memory, some up to 2 Megabytes, plenty for programs and
locally edit some files with a simple editor which might be faster than
downloading the whole source from a PC.
--
Cecil - k5nwa

Elizabeth D. Rather

unread,
Oct 3, 2016, 5:25:06 AM10/3/16
to
Well, that's why we prefer working with an interactive cross-compiler.
We can use full-function programmer's editors, have a much more powerful
compiler, and download the compiled code in less than a second.

Albert van der Horst

unread,
Oct 3, 2016, 6:48:56 AM10/3/16
to
In article <nst5tg$fnc$1...@dont-email.me>,
I implemented a screen editor for MSDOS. This provides easy experimenting
with new facilities in the screens. It works directly on the video buffer.
Apart from the Wordstar move by char, move by word, it stacks deleted
lines and words, and they are visible on the bottom of the screen,
where they can be undeleted. With slightly over a dozen single character
control commands, it is by far the most practical screen editor I've
ever seen. E.g. to duplicate a line
^Y delete a line appears at the bottom
^U insert it
^U insert it again

This is also useful for a booting Forth, switching back to real mode
to access the video buffer, and accessing the large memory of the
machine in 32 bits protected mode.

In a situation where you use a pc as a terminal to connect to a sbc,
it doesn't make sense to try have a screen editor on the sbc.
It is easier to transport a screen to the pc, use a screen editor there,
and transport it back. Almost everybody will save it to a small file,
edit that, and check whether it fits while uploading.
Or do it the Commodore 64/ BASIC way. Fool around on the PC screen,
insert and delete chars here and there. Then mark an area with the
mouse and press a special key to transfer it back to the sbc.

As there is just one block-file for all ciforth versions
the MSDOS editor can be found in forth.lab for lina32/lina64.
It can be made to work on Linux by using TERMCAP or infocmp,
with the same front end of the editor, any takers?

>--
>Cecil - k5nwa

lawren...@gmail.com

unread,
Oct 3, 2016, 7:31:34 AM10/3/16
to
On Monday, October 3, 2016 at 11:48:56 PM UTC+13, Albert van der Horst wrote:
> As there is just one block-file for all ciforth versions
> the MSDOS editor can be found in forth.lab for lina32/lina64.
> It can be made to work on Linux by using TERMCAP or infocmp,
> with the same front end of the editor, any takers?

Probably more fruitful to reimplement it as extension macros for Emacs.

alex

unread,
Oct 3, 2016, 7:51:54 AM10/3/16
to
On 02/10/16 18:45, Albert van der Horst wrote:
> In article <2016Oct...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>> On 01/10/2016 08:08, Anton Ertl wrote:
>>>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>>>> Does executing an xt of a word with undefined interpretation semantics
>>>>> have any benefit anyway. I suppose some control words could be made
>>>>> useful but others like ['] just seem to compile something which is unusable.
>>>>
>>>> Yes, people have ticked compile-only words, and expected to get an xt
>>>> that performs the compilation semantics of the word when EXECUTEd.
>>>> And that also works that way in most other Forth systems.
>> ...
>>> But if it doesn't do anything sensible what is the point.
>>
>> My guess is that these people are using these xts in places where
>> performing the compilation semantics of the word makes sense.
>
> Those people are probably clever enough to defeat the exception:
>
> : fex STATE @ >R 1 STATE ! EXECUTE R> STATE ! ;
>
> 'IF fex
>
> probably performs the compilation semantics on most systems.
>
> And yes cmForth is no longer relevant.
>
>>
>> - anton
>
> Groetjes Albert
>

What you propose is non standard, and on my Forth doesn't work, since
STATE is not a variable.

6.1.2250 STATE
CORE

( -- a-addr )

a-addr is the address of a cell containing the compilation-state flag.
STATE is true when in compilation state, false otherwise. The true value
in STATE is non-zero, but is otherwise implementation-defined. Only the
following standard words alter the value in STATE: : (colon), ;
(semicolon), ABORT, QUIT, :NONAME, [ (left-bracket), and ] (right-bracket).

Note: A program shall not directly alter the contents of STATE.


Anton Ertl

unread,
Oct 4, 2016, 5:28:40 AM10/4/16
to
Bernd Paysan <be...@net2o.de> writes:
>Am Sat, 01 Oct 2016 15:31:03 -1000 schrieb Elizabeth D. Rather:
>
>> On 10/1/16 2:10 PM, Bernd Paysan wrote:
>>> However, IIRC, the editor commands lived in a special editor
>>> vocabulary, and only L was visible by default, switching to the editor
>>> vocabulary when used. That way, all those one-letter editor words like
>>> I (insert) did not collide with normal Forth words.
>>>
>>> In SwiftForth, B and N are globally visible, though.
>>
>> True. SwiftForth doesn't have an internal editor, because it can
>> interface well to external editors. Incidentally, there were 3 versions
>> of I in earlier FORTH, Inc. products: the loop version, the editor
>> version (Insert), and the assembler version (the register or location
>> used for the Interpreter pointer), each in the appropriate wordlist, of
>> course.
>
>Still begs the question if resurrecting the EDITOR vocabulary for these
>few words might be useful.

B and N don't collide with other words, and for numbers the way to go
is to write $B or 0B, so I don't see a point in putting them into the
EDITOR vocabulary. I would just burden the users with either always
having the EDITOR vocabulary in the search order, or with typing
PREVIOUS once for every L.

>Actually, the Gforth LOCATE browser does read
>in the file in a way that is usable for a PolyForth-style editor, and
>adding such a simple editor would be just a few dozen lines. Or adding a
>full-screen editor maybe would be a line or two more (don't know how
>many ;-). I would use the command line editor to edit the individual
>lines, which then would give features like tab completion "for free".

What would be the point of such an editor, other than to prove that
you can do it? Nobody would use it. Even Forth, Inc., has not
supplied such an editor for files, because everybody prefers their
favourite file editor.

Bernd Paysan

unread,
Oct 4, 2016, 5:57:56 PM10/4/16
to
Am Tue, 04 Oct 2016 09:18:15 +0000 schrieb Anton Ertl:
>>Actually, the Gforth LOCATE browser does read in the file in a way that
>>is usable for a PolyForth-style editor, and adding such a simple editor
>>would be just a few dozen lines. Or adding a full-screen editor maybe
>>would be a line or two more (don't know how many ;-). I would use the
>>command line editor to edit the individual lines, which then would give
>>features like tab completion "for free".
>
> What would be the point of such an editor, other than to prove that you
> can do it? Nobody would use it. Even Forth, Inc., has not supplied
> such an editor for files, because everybody prefers their favourite file
> editor.

The Android users have already asked for a built-in editor... because
they don't have a "favorite file editor" on their OS. The available
editors as part of file managers are very limited.

Elizabeth D. Rather

unread,
Oct 4, 2016, 6:40:08 PM10/4/16
to
On 10/3/16 11:18 PM, Anton Ertl wrote:
> Bernd Paysan <be...@net2o.de> writes:
>> Am Sat, 01 Oct 2016 15:31:03 -1000 schrieb Elizabeth D. Rather:
>>
>>> On 10/1/16 2:10 PM, Bernd Paysan wrote:
>>>> However, IIRC, the editor commands lived in a special editor
>>>> vocabulary, and only L was visible by default, switching to the editor
>>>> vocabulary when used. That way, all those one-letter editor words like
>>>> I (insert) did not collide with normal Forth words.
>>>>
>>>> In SwiftForth, B and N are globally visible, though.
>>>
>>> True. SwiftForth doesn't have an internal editor, because it can
>>> interface well to external editors. Incidentally, there were 3 versions
>>> of I in earlier FORTH, Inc. products: the loop version, the editor
>>> version (Insert), and the assembler version (the register or location
>>> used for the Interpreter pointer), each in the appropriate wordlist, of
>>> course.
>>
>> Still begs the question if resurrecting the EDITOR vocabulary for these
>> few words might be useful.
>
> B and N don't collide with other words, and for numbers the way to go
> is to write $B or 0B, so I don't see a point in putting them into the
> EDITOR vocabulary. I would just burden the users with either always
> having the EDITOR vocabulary in the search order, or with typing
> PREVIOUS once for every L.

If EDITOR is always in the search order, what's the point in having it?
It was necessary in polyFORTH and its predecessors because of the "three
I's" described above.

beeflo

unread,
Oct 11, 2016, 1:51:51 PM10/11/16
to
On Thursday, September 29, 2016 at 7:33:58 PM UTC-6, Bernd Paysan wrote:
> I've polished up the snapshots for Windows, the latest one is available
> here:
>
> http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/0.7.9_20160923/
>
> (or https; it's a SHA-1 certificate if you wonder why Chrome shows a red
> warning sign and a strike-through https; Edge is not that picky).
>
> Apart from being the latest snapshot of Gforth, the setup.exes now are
> signed with a Certum "Open Source Developer" certificate, to get rid of
> the "unsigned binary from teh internetz! Danger!!!111!eleven!" terror
> warning Windows 10 and its "SmartScreen protection".
>
> Of course, since my certificate is new, it will show a terror warning
> even though, but then green "unknown app" and "might damage your
> computer" and you still need to click through the "more details" to be
> able to install it nonetheless.
>
> So download the setup.exes to increase my reputation ;-). I don't have a
> botnet at hand to let it do this automatically, as all the bad guys do
> (with a stolen identity to get the certificate... it is not like the
> check would actually rule out criminals).
>
> If someone wants to try net2o's Windows binary distribution, you can do
> that as well, download here:
>
> https://net2o.de/windows/
>
> It needs to be installed after installing the corresponding Gforth.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/

I ran the 64 bit installer, and it seemed to install great. The 32 bit installer didn't run the post-install script, and the installation thus has problems.

The installer gave an error message saying, "The program can't start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem."

I don't have cygwin installed on my computer, and I don't know why it couldn't find the cygwin stuff that came in the installation.

Thanks for the software update.

Bernd Paysan

unread,
Oct 11, 2016, 4:44:56 PM10/11/16
to
Am Tue, 11 Oct 2016 10:51:48 -0700 schrieb beeflo:
> I ran the 64 bit installer, and it seemed to install great. The 32 bit
> installer didn't run the post-install script, and the installation thus
> has problems.
>
> The installer gave an error message saying, "The program can't start
> because cygwin1.dll is missing from your computer. Try reinstalling the
> program to fix this problem."
>
> I don't have cygwin installed on my computer, and I don't know why it
> couldn't find the cygwin stuff that came in the installation.

The cygwin1.dll comes with the installation, indeed, and should be found
there... weird. Anyone else having problems with the 32 bit install?

Jan Coombs

unread,
Oct 11, 2016, 8:02:35 PM10/11/16
to
On Tue, 11 Oct 2016 20:44:38 -0000 (UTC)
Bernd Paysan <be...@net2o.de> wrote:

> The cygwin1.dll comes with the installation, indeed, and
> should be found there... weird. Anyone else having problems
> with the 32 bit install?


Just tried it on Win7pro in virtualbox and get same message. The
install progress bar shows done, the console window is labelled
"C:\Program Files\bin\sh.exe" the error window is labelled
"sh.exe - System Error"

A windows search cannot find cygwin1.dff on the 32b machine, but
on Win7pro64b install does.


WinXPpro didn't complete installation either, but error looked
different:

Installing
Please wait while Setup installs Gforth on your computer
[progress bar complete]

Setup [inset window]
Unable to execute file:
C:\Program Files\gforth\sh.exe

CreateProcess failed; code 193
%1 is not a valid Win32 application
[OK]


I couldn't find older 32b windows Gforth installers on the
Snapshots page, but tried gforth-0.7.9_20150221.exe becauuse it
was in shared folders on virtual machine. On WinXP, and got same
error as for later version.


On Win7pro this older version almost completes install, then the
"Setup Gforth" window spawns "Setup" window which says:

Unable to execute file:
C:\Program Files\gforth\sh.exe
Create process failed; code 216.
This version of %1 is not compatible with the version of Windows
you're running. Check your computer's system information to see
whether you need a x86 (21-bit) or x64 (64-bit) version of the
program,
and then contact the software publisher.


One of these virtual machines had Gforth installed, most likely
the the older one I have the installer for.


tried gforth-0.7.9_20160306, and this installed on Win7, but not
XP.

Jan Coombs

Spiros Lakkos

unread,
Oct 11, 2016, 11:50:41 PM10/11/16
to
Had the same problem on WinXP SP3

On 11/10/2016 23:44, Bernd Paysan wrote:
> Am Tue, 11 Oct 2016 10:51:48 -0700 schrieb beeflo:
>> I ran the 64 bit installer, and it seemed to install great. The 32 bit
>> installer didn't run the post-install script, and the installation thus
>> has problems.
>>
>> The installer gave an error message saying, "The program can't start
>> because cygwin1.dll is missing from your computer. Try reinstalling the
>> program to fix this problem."
>>
>> I don't have cygwin installed on my computer, and I don't know why it
>> couldn't find the cygwin stuff that came in the installation.
>
> The cygwin1.dll comes with the installation, indeed, and should be found
> there... weird. Anyone else having problems with the 32 bit install?
>


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

lawren...@gmail.com

unread,
Oct 12, 2016, 1:42:28 AM10/12/16
to
On Wednesday, October 12, 2016 at 6:51:51 AM UTC+13, beeflo wrote:
> The installer gave an error message saying, "The program can't start because
> cygwin1.dll is missing from your computer. Try reinstalling the program to
> fix this problem."

Did you try doing what it says?

That’s Windows for you: what works one time will fail another time...

beeflo

unread,
Oct 12, 2016, 12:41:37 PM10/12/16
to
I didn't try installing a general cygwin.

But, for reference, I tried to install the 32b version on Windows 7.

Bernd Paysan

unread,
Oct 12, 2016, 7:46:36 PM10/12/16
to
Am Wed, 12 Oct 2016 09:41:33 -0700 schrieb beeflo:

> On Tuesday, October 11, 2016 at 11:42:28 PM UTC-6, lawren...@gmail.com
> wrote:
>> On Wednesday, October 12, 2016 at 6:51:51 AM UTC+13, beeflo wrote:
>> > The installer gave an error message saying, "The program can't start
>> > because cygwin1.dll is missing from your computer. Try reinstalling
>> > the program to fix this problem."
>>
>> Did you try doing what it says?
>>
>> That’s Windows for you: what works one time will fail another time...
>
> I didn't try installing a general cygwin.

You don't need to, the cygwin1.dll is part of the setup.exe.

> But, for reference, I tried to install the 32b version on Windows 7.

That shouldn't be a problem, but I only tried Windows 10.

Bernd Paysan

unread,
Oct 12, 2016, 8:26:28 PM10/12/16
to
Am Wed, 12 Oct 2016 01:02:34 +0100 schrieb Jan Coombs:

>> The cygwin1.dll comes with the installation, indeed, and should be
>> found there... weird. Anyone else having problems with the 32 bit
>> install?
>
>
> Just tried it on Win7pro in virtualbox and get same message. The install
> progress bar shows done, the console window is labelled "C:\Program
> Files\bin\sh.exe" the error window is labelled "sh.exe - System Error"
>
> A windows search cannot find cygwin1.dff on the 32b machine, but on
> Win7pro64b install does.

Ok, found it. The 64 bit install has the 32 bit cygwin1.dll and stuff in
C:\Program Files\bin, the 32 bit install hasn't. If you, like I, try
both, it works. If you only install the 32 bit version, it doesn't work.

I've uploaded a new gforth-0.7.9_20161006.exe (under the same name), try
that.

Jan Coombs

unread,
Oct 13, 2016, 3:48:32 AM10/13/16
to
On Thu, 13 Oct 2016 00:26:10 -0000 (UTC)
Bernd Paysan <be...@net2o.de> wrote:
[...]
> Ok, found it. The 64 bit install has the 32 bit cygwin1.dll
> and stuff in C:\Program Files\bin, the 32 bit install hasn't.
> If you, like I, try both, it works. If you only install the
> 32 bit version, it doesn't work.
>
> I've uploaded a new gforth-0.7.9_20161006.exe (under the same
> name), try that.

Win7 now good, but XP still has problem, even when installed as
supervisor:

gforth_WinXPinstall.txt

Installer
"Setup - Gforth"
Install progress bar looks complete

Terminal window
"C:\Program Files\bin\sh.exe"
looks empty

Error window
"sh.exe - Entry Point Not Found"
The procedure entry point CancelSynchronousIo \
could not be located in the dynamic link library \
KERNEL32.dll [ OK ]

Jan Coombs.

lawren...@gmail.com

unread,
Oct 13, 2016, 4:09:07 AM10/13/16
to
On Thursday, October 13, 2016 at 8:48:32 PM UTC+13, Jan Coombs wrote:
> ... XP still has problem ...

We know XP still has problems, but it’s too late to expect them to be fixed now...

Gerry Jackson

unread,
Oct 14, 2016, 1:05:33 PM10/14/16
to
On 13/10/2016 01:26, Bernd Paysan wrote:
> Am Wed, 12 Oct 2016 01:02:34 +0100 schrieb Jan Coombs:
>
>>> The cygwin1.dll comes with the installation, indeed, and should be
>>> found there... weird. Anyone else having problems with the 32 bit
>>> install?
>>
>>
>> Just tried it on Win7pro in virtualbox and get same message. The install
>> progress bar shows done, the console window is labelled "C:\Program
>> Files\bin\sh.exe" the error window is labelled "sh.exe - System Error"
>>
>> A windows search cannot find cygwin1.dff on the 32b machine, but on
>> Win7pro64b install does.
>
> Ok, found it. The 64 bit install has the 32 bit cygwin1.dll and stuff in
> C:\Program Files\bin, the 32 bit install hasn't. If you, like I, try
> both, it works. If you only install the 32 bit version, it doesn't work.
>
> I've uploaded a new gforth-0.7.9_20161006.exe (under the same name), try
> that.
>

gforth-0.7.9_20161006.exe fails 8 tests in SUBSTITUTE tests in file
stringtests.fth under Windows 10. IIRC they used to run on a previous
version Gforth 0.7.9_20160113

Use the latest version of the tests:
https://github.com/gerryjackson/forth2012-test-suite

--
Gerry

Bernd Paysan

unread,
Oct 14, 2016, 7:30:10 PM10/14/16
to
Yes, I really need to get around embedding all your new tests into the
test suite Gforth runs automatically after build.

At the moment, the FP tests also fail with gforth --dynamic due to a
compilation problem (gforth-fast works, the threaded versions, too, so
it's likely a code block size problem), in line 1249 of paranoia.4th;
maybe Anton should investigate into this problem? This is really a long
word ;-). I also can't change code-block-size without triggering an
assertion...

Bernd Paysan

unread,
Oct 14, 2016, 7:39:40 PM10/14/16
to
Haha ;-).

It seems to be that Cygwin is using a CancelSynchronousIo syscall, which
was introduced in Vista. As long as the Windows port of Gforth uses
Cygwin, I won't do anything on this one. It's good to know that it
doesn't work on XP anymore for that reason.

Anton Ertl

unread,
Oct 15, 2016, 12:42:56 PM10/15/16
to
Bernd Paysan <be...@net2o.de> writes:
>At the moment, the FP tests also fail with gforth --dynamic due to a
>compilation problem (gforth-fast works, the threaded versions, too, so
>it's likely a code block size problem), in line 1249 of paranoia.4th;
>maybe Anton should investigate into this problem? This is really a long
>word ;-).

Fixed. This is an interesting bug: It accesses "origs[-1]", and that
has been done a lot of times when running Gforth (probably would have
shown up if we used the "sanitizers" more).

It was hidden by the the result being 0 in the usual instances, and
that does not lead to an error later on. It returned 0, because gcc
always arranged the array before to be just before origs in memory,
that was initialized to 0, and we usually don't make use of all the
elements in the array. But an earlier long basic block in
paranoia.4th resulted in the last element of the pervious array being
set to some large value, and that led to the bug revealing itself.

>I also can't change code-block-size without triggering an
>assertion...

A certain minimum code block size is required. This is not handled in
a very user-friendly way, but then, --code-block-size is more of a
testing/debugging option.

Bernd Paysan

unread,
Oct 16, 2016, 8:53:01 PM10/16/16
to
Am Fri, 14 Oct 2016 23:29:50 +0000 schrieb Bernd Paysan:

> Am Fri, 14 Oct 2016 18:05:30 +0100 schrieb Gerry Jackson:
>
>> On 13/10/2016 01:26, Bernd Paysan wrote:
>> gforth-0.7.9_20161006.exe fails 8 tests in SUBSTITUTE tests in file
>> stringtests.fth under Windows 10. IIRC they used to run on a previous
>> version Gforth 0.7.9_20160113
>>
>> Use the latest version of the tests:
>> https://github.com/gerryjackson/forth2012-test-suite
>
> Yes, I really need to get around embedding all your new tests into the
> test suite Gforth runs automatically after build.

I started with your FP test, and I ran into problems pretty soon. First
of all, older glibcs fail on a few of the precise number conversions.
Second, the x87 coprocessor fails on the rounding tests, it is slightly
off.

I've identified these problems:

old glibc:

INCORRECT RESULT hex_t{ r8 2L@ -> 42c00000 00000002 }t
Actual result[0]=1
INCORRECT RESULT hex_t{ r8 2L@ -> 3fe00000 00000002 }t
Actual result[0]=1
INCORRECT RESULT hex_t{ r8 2L@ -> 404f44ab d5aa7ca4 }t
Actual result[0]=D5AA7CA3
INCORRECT RESULT hex_t{ r8 2L@ -> 3ff00000 00000001 }t
Actual result[0]=0

The "Actual result[i]=value" is a modification of ttester.fs I made to
make sure I can see what's going on right in the output, without having
to check interactively; sometimes that's impossible, e.g. on the Travis
setup.

And this is x86 (the "spoil financial calculation" defect only with old
glibc, so that is a number conversion problem):

Page: 6

Checking rounding on multiply, divide and add/subtract.
! F* is neither chopped nor correctly rounded.
! F/ is neither chopped nor correctly rounded.
! Addition/Subtraction neither rounds nor chops.
! Sticky bit used incorrectly or not at all.
! FLAW lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.
...
Test for sqrt monotonicity.
sqrt has passed a test for Monotonicity.
Testing whether sqrt is rounded or chopped.
! Square root is neither chopped nor correctly rounded.
! Observed errors run from -5.0000E-1 to 5.0000E-1 ulps.
Diagnosis resumes after milestone Number 90
...
This computed value is O.K.

Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.3891E0 as X -> 1.
! DEFECT Calculated 7.3891E0 for
! (1 + (-1.1102E-16 ) ^ (-1.8014E16 );
! differs from correct value by -3.4413E-9
! This much error may spoil financial
! calculations involving tiny interest rates.
Testing powers Z^Q at four nearly extreme values.
... no discrepancies found.
...
! DEFECTs discovered = 1
! FLAWs discovered = 1

! The arithmetic diagnosed may be Acceptable
! despite inconvenient Defects.



I modified the code so that flaws merely emit warnings, and won't cause a
fail, but the defects still flag it as failed, and I don't feel like
turning defects into a warning ;-).

On the other hand, running those tests already revealed two bugs in Gforth
(one in the dynamic code generator, and one in our ecvt_r replacement,
which couldn't handle denormals with sufficient accuracy).

Gerry Jackson

unread,
Oct 19, 2016, 5:50:06 AM10/19/16
to
On 17/10/2016 01:52, Bernd Paysan wrote:
> Am Fri, 14 Oct 2016 23:29:50 +0000 schrieb Bernd Paysan:
>
>> Am Fri, 14 Oct 2016 18:05:30 +0100 schrieb Gerry Jackson:
>>
>>> On 13/10/2016 01:26, Bernd Paysan wrote:
>>> gforth-0.7.9_20161006.exe fails 8 tests in SUBSTITUTE tests in file
>>> stringtests.fth under Windows 10. IIRC they used to run on a previous
>>> version Gforth 0.7.9_20160113
>>>
>>> Use the latest version of the tests:
>>> https://github.com/gerryjackson/forth2012-test-suite
>>
>> Yes, I really need to get around embedding all your new tests into the
>> test suite Gforth runs automatically after build.
>
> I started with your FP test, and I ran into problems pretty soon. First
> of all, older glibcs fail on a few of the precise number conversions.
> Second, the x87 coprocessor fails on the rounding tests, it is slightly
> off.
>

Thank you for the feedback on the FP tests I appreciate it, that is only
the second (IIRC) feedback since I packaged the tests from various
sources in May 2012 with the following comment on c.l.f:

<quote>I propose to package the programs, more or less, as is, into a
download on the FLAG site and invite implementers to run them on their
Forth system. If they encounter errors, non-compliances or other
problems in the test programs to raise it with me or on comp.lang.forth,
get it resolved and update the download. In this way we could converge
on a set of satisfactory tests.</quote>

Clearly that was an over-optimistic hope. As I remember at the time
GForth did much better than other major systems which either failed
abysmally or simply crashed - perhaps when I get time I'll try again and
'name and shame' the other systems :)

> I've identified these problems:
>
> old glibc:
>
> INCORRECT RESULT hex_t{ r8 2L@ -> 42c00000 00000002 }t
> Actual result[0]=1
> INCORRECT RESULT hex_t{ r8 2L@ -> 3fe00000 00000002 }t
> Actual result[0]=1
> INCORRECT RESULT hex_t{ r8 2L@ -> 404f44ab d5aa7ca4 }t
> Actual result[0]=D5AA7CA3
> INCORRECT RESULT hex_t{ r8 2L@ -> 3ff00000 00000001 }t
> Actual result[0]=0
>

If I was correct in my post on 4 May 2012 (sorry you'll have to scan
down the messages):

https://groups.google.com/forum/?hl=en#!searchin/comp.lang.forth/floating$20point$20tests%7Csort:relevance/comp.lang.forth/lJ1hdgZCpuo/Zp9H5xhKV0MJ

GForth 0.7.0 used to pass these tests in fpio-test.4th in 2012. Are you
suggesting that the tests are wrong or that old glibc has problems?

> The "Actual result[i]=value" is a modification of ttester.fs I made to
> make sure I can see what's going on right in the output, without having
> to check interactively; sometimes that's impossible, e.g. on the Travis
> setup.

That seems useful, I'll think about adding it to the ttester.fs in the
test suite.
The test code in paranoia.4th presumably

so that flaws merely emit warnings, and won't cause a
> fail, but the defects still flag it as failed, and I don't feel like
> turning defects into a warning ;-).
>

Of course you're free to modify your copy of tests for your own
convenience but I'd rather see what other systems do with those tests
before changing the master files.

> On the other hand, running those tests already revealed two bugs in Gforth
> (one in the dynamic code generator, and one in our ecvt_r replacement,
> which couldn't handle denormals with sufficient accuracy).
>

That's good to know. Once again thanks for the feedback.


--
Gerry

jjm...@gmail.com

unread,
Oct 19, 2016, 7:45:20 AM10/19/16
to
I'm sorry if this posting is a little late.
Mr. Paysan mentions that there is no way to determine the background color of a user's terminal, which, of course, is as true now as it has been throughout the history of computer monitors and printers. The problem is one of lack of feedback.
The traditional solution in such cases has been procedural. Force the output into a known state, then set the output to the desired state and keep records. The record becomes one's source for feedback. This works so long as no outside agent changes the output without noting the change, eg. the user twiddles a knob on the console or the operating system resets the output device without reseting, say, the column or line numbers.
So long as the gforth user sets the console colors using the attribute variable through gforth words using such, one can determine the background
with " attr @ bg> " on systems relying on the ansi facilities. If, on the other hand, you use Gforth for Android, the code would be, " color-index @ bg> ". Other platforms may need slightly different solutions.

jjm...@gmail.com

unread,
Oct 19, 2016, 8:57:55 AM10/19/16
to
Mr. Ertl writes:
> B and N don't collide with other words, and for numbers the way to go
> is to write $B or 0B, so I don't see a point in putting them into the
> EDITOR vocabulary. I would just burden the users with either always
> having the EDITOR vocabulary in the search order, or with typing
> PREVIOUS once for every L.

Older systems either loaded the editor block automatically on error and switched vocabularys, or kept the editor in an overlay. One can avoid the problem with PREVIOUS by having the editor QUIT word clean up.

jjm...@gmail.com

unread,
Oct 19, 2016, 9:47:05 AM10/19/16
to
It's not true that Gforth Android users don't have a favorite editor. We just can't interface with them without using the Android "Intent" system:)
Also, writing a Gforth "internal" editor--I won't say "native"--is a rather trivial project. Most of the code is already
written into Gforth "version#" files, especially history.fs.

jjm...@gmail.com

unread,
Oct 19, 2016, 11:37:16 AM10/19/16
to
OK. EDITOR and/or EDIT or LIST invoke the editor vocabulary so the editor words don't always interfere with other searches. That's the point of vocabularies. Today's philosophy seems to be that every word should be seen all the time, globally, and should be unique. But, unfortunately, this renders the use of said words difficult as commands, and harder to associate functionally.
I'm a native speaker of English. That carrys certain biases as to language. We reuse words to death. We swim in ambiguity and grasp at new and related words like straws in the sea, attempting to reach islands of specificity. Other languages, especially the heavily inflected ones, weave the straws into mats until there's something that floats. Niether approach seems particularly well suited to computing. Forth, on the other (uh, third) hand, recognizes the functional dynamics of word use and naming. Vocabularies can do work. Words can talk about and talk to other words. But really, I don't think forth was ever meant to handle huge numbers of concepts, like how to manage all forms of editing or threading on every possible machine. That's more of a data problem.
So the short answer to the question of why would one want any vocabulary continuously present, is, forth doesn't usually do that, with the possible exception of ROOT.

Cecil Bayona

unread,
Oct 19, 2016, 12:29:09 PM10/19/16
to
By using vocabularies one also helps the system to be more responsive
since only a subset of the available words are searched for. I'm
speaking of embedded system, on a PC the CPU is so fast that it doesn't
make much difference.

I used to use Pygmy and it it emphasized the use of vocabularies and it
was quite handy, the assembler had it's own vocabulary so conditionals
used the same words one was used to but since the assembler vocabulary
was searched first the assembler version of "IF" was found first.

Nowadays oForth, and 8th use vocabularies extensively and it makes
things a little easier.

--
Cecil - k5nwa

jjm...@gmail.com

unread,
Oct 19, 2016, 3:03:44 PM10/19/16
to
Hello Cecil,
you wrote:

> By using vocabularies one also helps the system to be more responsive
> since only a subset of the available words are searched for. I'm
> speaking of embedded system, on a PC the CPU is so fast that it doesn't
> make much difference.
>
> I used to use Pygmy and it it emphasized the use of vocabularies and it
> was quite handy, the assembler had it's own vocabulary so conditionals
> used the same words one was used to but since the assembler vocabulary
> was searched first the assembler version of "IF" was found first.
>
> Nowadays oForth, and 8th use vocabularies extensively and it makes
> things a little easier.
>
> --
> Cecil - k5nwa

I think you're right about the convienience of vocabularies. Syntacticly,
vocabularies are essentially identical to structures, objects, etc. in other
languages, but forth lends vocabularies special powers if needed. And besides,
vocabularies are a pretty good match to how most people think.
Hashing also improves dictionary response. Hashing may have caused
the problem you noted with 'IF', by "hashing away" the list structure.
Some metadata, mainly the vocabulary id, really belong in a prefix with
a hashed word. List recovery metadata ( ordering ) belong post-hash, ie.
in the dictionary entry or bucket. So maybe the best way to implement a
vocabulary list is with no list at all.
As for the speed and size on ( physically ) small machines, the first
"microprocessor chips" were 4 bit half-adders about the size of a thumbprint
and ran at a few kilohertz. I don't think any computer ever made of those
chips could support even something as squeeze-hardy as forth. Today,
even some of the biggest and fastest machines struggle to accommodate
more modern languages and OSes. Who can program them in 400 bytes?


Anton Ertl

unread,
Oct 20, 2016, 9:22:06 AM10/20/16
to
jjm...@gmail.com writes:
> OK. EDITOR and/or EDIT or LIST invoke the editor vocabulary so the ed=
>itor words don't always interfere with other searches. That's the point of =
>vocabularies. Today's philosophy seems to be that every word should be see=
>n all the time, globally, and should be unique. But, unfortunately, this r=
>enders the use of said words difficult as commands, and harder to associate=
> functionally.=20

Which said words? The issue at hand was that B collided with the use
of B as number. Two solutions were presented:

1) to write the number B as 0B or $B.

2) to put B in the EDITOR vocabulary, so that it would collide with
the number B only if EDITOR is in the search order. In that case, how
does EDITOR come into the search order?

a) The user has to do it explicitly, i.e., EDITOR B PREVIOUS; if so,
the user will likely just add EDITOR to the search order at the
start of the session, and we have the same collision problem.

b) LOCATE (and whatever else sets up the context for B, e.g., an
error) puts EDITOR in the search order. In that case, after the
first LOCATE or error, we have EDITOR in the search order, and have
the same collision problem, until the user removes EDITOR from the
search order.

I think that Forth, Inc. did the right thing when they chose to put B
in the FORTH vocabulary (requiring solution 1), and we did the right
thing in following them in this respect.

As for general use of vocabularies, sure you can have two words with
the same name in different vocabularies and switch vocabularies. But
the support of that feature in other parts of Forth is rather limited.
E.g., SEE does not tell you which of the same-named words it refers
to. It's also annoying in debugging.

Therefore, I prefer to use unique names for words for general use, and
use vocabularies/wordlists only for internal words of some library or
application. And of course, because we don't bury our tools, I am not
that keen on the latter use, either.

Elizabeth D. Rather

unread,
Oct 20, 2016, 1:36:22 PM10/20/16
to
Surely SEE reports on the word it finds in the current search order?

Anton Ertl

unread,
Oct 21, 2016, 3:25:19 AM10/21/16
to
"Elizabeth D. Rather" <era...@forth.com> writes:
>On 10/20/16 2:15 AM, Anton Ertl wrote:
>> As for general use of vocabularies, sure you can have two words with
>> the same name in different vocabularies and switch vocabularies. But
>> the support of that feature in other parts of Forth is rather limited.
>> E.g., SEE does not tell you which of the same-named words it refers
>> to. It's also annoying in debugging.
...
>Surely SEE reports on the word it finds in the current search order?

: foo ." foo1" ;
vocabulary v also v definitions
: foo ." foo2" ;
also forth definitions previous
: bar foo ;
previous
see foo
see bar

see bar
8082BEF 8082BCF ( foo ) JMP E9DBFFFFFF ok

SEE BAR tells me that it jumps to FOO, but it does not tell me in
which vocabulary that FOO is, and it does not tell me that it's not
the FOO that is currently found in the search order when typing FOO
(or SEE FOO).

Bernd Paysan

unread,
Oct 21, 2016, 4:22:58 PM10/21/16
to
Am Wed, 19 Oct 2016 06:47:03 -0700 schrieb jjmail9:

> It's not true that Gforth Android users don't have a favorite editor.

I don't. None of the editors I have installed on my Android is anything
close to "favorite". I may have a "least hated editor" on Android. Maybe
I didn't look long enough ;-).

> We just can't interface with them without using the Android "Intent"
> system:)

But we for sure can use the Android "Intent" system using JNI, can't we?
Just nobody so far has done it... The code in Java is pretty simple:

Intent intent = new Intent(Intent.ACTION_EDIT);
Uri uri = Uri.parse("file:///sdcard/folder/file.txt");
intent.setDataAndType(uri, "text/plain");
startActivity(intent);

One essential problem here for good integration is that you can't tell
the intent, where in the file it should start editing...

Elizabeth D. Rather

unread,
Oct 22, 2016, 4:12:18 AM10/22/16
to
On 10/20/16 9:15 PM, Anton Ertl wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> On 10/20/16 2:15 AM, Anton Ertl wrote:
>>> As for general use of vocabularies, sure you can have two words with
>>> the same name in different vocabularies and switch vocabularies. But
>>> the support of that feature in other parts of Forth is rather limited.
>>> E.g., SEE does not tell you which of the same-named words it refers
>>> to. It's also annoying in debugging.
> ...
>> Surely SEE reports on the word it finds in the current search order?
>
> : foo ." foo1" ;
> vocabulary v also v definitions
> : foo ." foo2" ;
> also forth definitions previous
> : bar foo ;
> previous
> see foo
> see bar
>
> see bar
> 8082BEF 8082BCF ( foo ) JMP E9DBFFFFFF ok
>
> SEE BAR tells me that it jumps to FOO, but it does not tell me in
> which vocabulary that FOO is, and it does not tell me that it's not
> the FOO that is currently found in the search order when typing FOO
> (or SEE FOO).

SEE is only expected to show you what was compiled for the version
that's in the search order when you execute the SEE, not its vocabulary
linkage, antecedents, etc. You can, of course, make SEE as complicated
as you want to. As it is, basically it tells you where the FOO it jumps
to is. Should you need clarification, you can always type ' FOO with the
relevant vocabulary options to see which one is at 8082BCF. I've never
heard someone complain of this problem, so I can't comment further.

Albert van der Horst

unread,
Oct 22, 2016, 6:03:43 AM10/22/16
to
In article <Bt2dnYGC657AgpbF...@supernews.com>,
In ciforth there is a non parsing version of see:

SEE SEE
: SEE ' CRACKED ;

So in the above example
$8082BCF CRACKED

(Of course you will not type in that number. Double click with the
left, then middle click.)

I never considered SEEN , it is unsightly.

>
>Cheers,
>Elizabeth
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Anton Ertl

unread,
Oct 22, 2016, 10:02:32 AM10/22/16
to
Yes, but that's not the issue at hand.

>As it is, basically it tells you where the FOO it jumps
>to is. Should you need clarification, you can always type ' FOO with the
>relevant vocabulary options to see which one is at 8082BCF.

Not in SwiftForth.

see bar
8082BEF 8082BCF ( foo ) JMP E9DBFFFFFF ok
' foo . 231599 ok
' foo hex . 388AF ok
also v ' foo . 3899F ok

However, SEE works. But still, with a dozen FOOs, and several dozen
wordlists that they might reside in (and you can get there easily if
you embrace overloading-by-search order), that's not really a
practical approach.

And the situation is worse in Gforth:

see bar
: bar
foo ; ok

>I've never
>heard someone complain of this problem, so I can't comment further.

Those of us smart enough to avoid it have no reason to complain, and
the others may be too embarrassed:-).
0 new messages