Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #51465 > unrolled thread

Gforth snapshot for Windows

Back to article view | Back to comp.lang.forth

Contents

  Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-09-30 01:33 +0000
    Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-30 15:16 +0100
      Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-30 16:26 +0000
        Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-30 19:50 +0100
          Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-09-30 20:34 +0000
            Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-10-02 11:14 +0100
              Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-02 16:29 +0000
                Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-02 22:47 +0000
            Re: Gforth snapshot for Windows jjmail9@gmail.com - 2016-10-19 04:45 -0700
          Re: Gforth snapshot for Windows Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-09-30 17:28 -0400
            Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-09-30 22:14 +0000
            Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-10-01 19:42 +0100
          Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-01 07:08 +0000
            Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-10-02 11:23 +0100
              Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-02 16:14 +0000
                Re: Gforth snapshot for Windows Cecil Bayona <cbayona@cbayona.com> - 2016-10-02 12:14 -0500
                Re: Gforth snapshot for Windows albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-02 19:45 +0200
                  Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-03 07:43 +0000
                  Re: Gforth snapshot for Windows alex <alex@rivadpm.com> - 2016-10-03 12:51 +0100
          Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-10-02 12:07 +0100
            Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-02 22:39 +0000
        Re: Gforth snapshot for Windows Paul Rubin <no.email@nospam.invalid> - 2016-09-30 14:36 -0700
          Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-01 07:46 +0000
            Re: Gforth snapshot for Windows Paul Rubin <no.email@nospam.invalid> - 2016-10-01 12:12 -0700
            Re: Gforth snapshot for Windows lawrencedo99@gmail.com - 2016-10-02 19:51 -0700
        Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-09-30 22:09 +0000
          Re: Gforth snapshot for Windows "Elizabeth D. Rather" <erather@forth.com> - 2016-09-30 13:25 -1000
            Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-02 00:10 +0000
              Re: Gforth snapshot for Windows "Elizabeth D. Rather" <erather@forth.com> - 2016-10-01 15:31 -1000
                Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-02 23:00 +0000
                  Re: Gforth snapshot for Windows "Elizabeth D. Rather" <erather@forth.com> - 2016-10-02 21:32 -1000
                    Re: Gforth snapshot for Windows Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 03:46 -0500
                      Re: Gforth snapshot for Windows "Elizabeth D. Rather" <erather@forth.com> - 2016-10-02 23:25 -1000
                      Re: Gforth snapshot for Windows albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-03 12:57 +0200
                        Re: Gforth snapshot for Windows lawrencedo99@gmail.com - 2016-10-03 04:31 -0700
                  Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-04 09:18 +0000
                    Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-04 21:57 +0000
                      Re: Gforth snapshot for Windows jjmail9@gmail.com - 2016-10-19 06:47 -0700
                        Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-21 20:22 +0000
                    Re: Gforth snapshot for Windows "Elizabeth D. Rather" <erather@forth.com> - 2016-10-04 12:40 -1000
                      Re: Gforth snapshot for Windows jjmail9@gmail.com - 2016-10-19 08:37 -0700
                        Re: Gforth snapshot for Windows Cecil Bayona <cbayona@cbayona.com> - 2016-10-19 11:29 -0500
                          Re: Gforth snapshot for Windows jjmail9@gmail.com - 2016-10-19 12:03 -0700
                        Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-20 12:15 +0000
                          Re: Gforth snapshot for Windows "Elizabeth D. Rather" <erather@forth.com> - 2016-10-20 07:36 -1000
                            Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-21 07:15 +0000
                              Re: Gforth snapshot for Windows "Elizabeth D. Rather" <erather@forth.com> - 2016-10-21 22:12 -1000
                                Re: Gforth snapshot for Windows albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-22 12:12 +0200
                                Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-22 13:52 +0000
                    Re: Gforth snapshot for Windows jjmail9@gmail.com - 2016-10-19 05:57 -0700
    Re: Gforth snapshot for Windows Jason Damisch <jasondamisch@yahoo.com> - 2016-09-30 10:17 -0700
    Re: Gforth snapshot for Windows Philip Smith <philipkingsmith@gmail.com> - 2016-09-30 11:45 -0700
    Re: Gforth snapshot for Windows beeflo <beeflobill@gmail.com> - 2016-10-11 10:51 -0700
      Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-11 20:44 +0000
        Re: Gforth snapshot for Windows Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-10-12 01:02 +0100
          Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-13 00:26 +0000
            Re: Gforth snapshot for Windows Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-10-13 08:48 +0100
              Re: Gforth snapshot for Windows lawrencedo99@gmail.com - 2016-10-13 01:09 -0700
                Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-14 23:39 +0000
            Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-10-14 18:05 +0100
              Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-14 23:29 +0000
                Re: Gforth snapshot for Windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-15 16:26 +0000
                Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-17 00:52 +0000
                  Re: Gforth snapshot for Windows Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-10-19 10:50 +0100
        Re: Gforth snapshot for Windows Spiros Lakkos <slakkos@hotmail.com> - 2016-10-12 06:50 +0300
      Re: Gforth snapshot for Windows lawrencedo99@gmail.com - 2016-10-11 22:42 -0700
        Re: Gforth snapshot for Windows beeflo <beeflobill@gmail.com> - 2016-10-12 09:41 -0700
          Re: Gforth snapshot for Windows Bernd Paysan <bernd@net2o.de> - 2016-10-12 23:46 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#51465 — Gforth snapshot for Windows

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/

[toc] | [next] | [standalone]

#51478

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

[toc] | [prev] | [next] | [standalone]

#51479

Gerry Jackson <gerry@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/

[toc] | [prev] | [next] | [standalone]

#51483

On 30/09/2016 17:26, Anton Ertl wrote:
> Gerry Jackson <gerry@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

[toc] | [prev] | [next] | [standalone]

#51485

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.

-- 
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/

[toc] | [prev] | [next] | [standalone]

#51535

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

[toc] | [prev] | [next] | [standalone]

#51548

Gerry Jackson <gerry@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.

- 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/

[toc] | [prev] | [next] | [standalone]

#51553

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
"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/

[toc] | [prev] | [next] | [standalone]

#52041

     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.  

[toc] | [prev] | [next] | [standalone]

#51487

On Fri, 30 Sep 2016 19:50:16 +0100
Gerry Jackson <gerry@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

[toc] | [prev] | [next] | [standalone]

#51490

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.

-- 
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/

[toc] | [prev] | [next] | [standalone]

#51509

On 30/09/2016 22:28, Rod Pemberton wrote:
> On Fri, 30 Sep 2016 19:50:16 +0100
> Gerry Jackson <gerry@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

[toc] | [prev] | [next] | [standalone]

#51502

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 30/09/2016 17:26, Anton Ertl wrote:
>> Gerry Jackson <gerry@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 <2015Dec5.165730@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
-- 
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/

[toc] | [prev] | [next] | [standalone]

#51538

On 01/10/2016 08:08, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 30/09/2016 17:26, Anton Ertl wrote:
>>> Gerry Jackson <gerry@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 <2015Dec5.165730@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

[toc] | [prev] | [next] | [standalone]

#51547

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 01/10/2016 08:08, Anton Ertl wrote:
>> Gerry Jackson <gerry@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
-- 
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/

[toc] | [prev] | [next] | [standalone]

#51549

On 10/2/2016 11:14 AM, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 01/10/2016 08:08, Anton Ertl wrote:
>>> Gerry Jackson <gerry@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
>
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

[toc] | [prev] | [next] | [standalone]

#51550

In article <2016Oct2.181418@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>On 01/10/2016 08:08, Anton Ertl wrote:
>>> Gerry Jackson <gerry@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

[toc] | [prev] | [next] | [standalone]

#51560

albert@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

- 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/

[toc] | [prev] | [next] | [standalone]

#51566

On 02/10/16 18:45, Albert van der Horst wrote:
> In article <2016Oct2.181418@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>> On 01/10/2016 08:08, Anton Ertl wrote:
>>>> Gerry Jackson <gerry@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.

[toc] | [prev] | [next] | [standalone]

#51542

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web