New Gforth "qixi" Snapshot

[Bernd Paysan]

I've uploaded a new snapshot of the current git HEAD of Gforth into the
usual place

https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/ (http works, too)

Apart from the ongoing development, the Windows version contains a few
changes:

* Gforth is started in a way that HOME points to the actual home directory
(which in Windows is composed of %HOMEDRIVE% and %HOMEPATH%... WTF?), and
thus all the user-specific stuff actually goes to your home directory - like
history and such.

* I've added mintty.exe as terminal, which is clearly superior compared to
the standard DOS box terminal. Unfortunately, I haven't found out how to
get rid of the DOS box Windows launches when it starts mintty (the
workaround which is in mintty.exe itself only works when mintty.exe is
inside a Cygwin install).

* I've started to generate bindings for system libraries using SWIG. The
first one that compiled on Windows was OpenGL ES. As WGL is not yet
generated, you can't open a context to work with it, but it's a start.

* Fixpath during installation now does really fix the search path, before,
it was broken. I.e. if you use Gforth outside Cygwin, from cmd.exe, you
should be able to start it from any other working directory. Make sure, you
have set HOME as mentioned above.

If you have Cygwin installed, use the cygwin bindist tarball instead.

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

[Alex McDonald]

on 20/08/2015 00:58:36, Bernd Paysan wrote:
> I've uploaded a new snapshot of the current git HEAD of Gforth into
> the usual place
>
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/ (http works,
> too)
>
> Apart from the ongoing development, the Windows version contains a few
> changes:
>
> * Gforth is started in a way that HOME points to the actual home
> directory (which in Windows is composed of %HOMEDRIVE% and
> %HOMEPATH%... WTF?), and thus all the user-specific stuff actually
> goes to your home directory - like history and such.
>
> * I've added mintty.exe as terminal, which is clearly superior
> compared to the standard DOS box terminal. Unfortunately, I haven't
> found out how to get rid of the DOS box Windows launches when it
> starts mintty (the workaround which is in mintty.exe itself only works
> when mintty.exe is inside a Cygwin install).

Link (or patch) the PE header as a GUI app. The field is 1 for a console
DOS box, 2 for a DLL and 3 for a GUI.

WORD
Subsystem
An enum value indicating what subsystem (user interface type) the
executable expects. This field is only important for EXEs. Important
values include: IMAGE_SUBSYSTEM_NATIVE // Image doesn't require a
subsystem IMAGE_SUBSYSTEM_WINDOWS_GUI // Use the Windows GUI
IMAGE_SUBSYSTEM_WINDOWS_CUI // Run as a console mode application
// When run, the OS creates a console
// window for it, and provides stdin,
// stdout, and stderr file handles

It's probably marked as CUI.


https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

[Bernd Paysan]

Alex McDonald wrote:
> Link (or patch) the PE header as a GUI app. The field is 1 for a console
> DOS box, 2 for a DLL and 3 for a GUI.
>
> WORD
> Subsystem
> An enum value indicating what subsystem (user interface type) the
> executable expects. This field is only important for EXEs. Important
> values include: IMAGE_SUBSYSTEM_NATIVE // Image doesn't require a
> subsystem IMAGE_SUBSYSTEM_WINDOWS_GUI // Use the Windows GUI
> IMAGE_SUBSYSTEM_WINDOWS_CUI // Run as a console mode application
> // When run, the OS creates a console
> // window for it, and provides stdin,
> // stdout, and stderr file handles
>
> It's probably marked as CUI.
>
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

Good idea, I'll try that. Cygwin compiles everything as CUI. Since I ship
my own copy, I can patch that as I like, getting rid of the consoles.

[Bernd Paysan]

Alex McDonald wrote:

> Link (or patch) the PE header as a GUI app. The field is 1 for a console
> DOS box, 2 for a DLL and 3 for a GUI.

mintty.exe is 2 (GUI), the Gforth exes are all 3 (console)... so maybe the
console pops up when mintty launches Gforth. Gforth however needs to be a
console app... that's not the solution.

The problem is that mintty outside the cygwin environment can't find its
helper app which hides those consoles.

[Bernd Paysan]

Bernd Paysan wrote:
> The problem is that mintty outside the cygwin environment can't find its
> helper app which hides those consoles.

I found a solution: Replace the /bin/cygwin-console-helper.exe string in my
copy of Cygwin with ./in/cygwin-console-helper.exe, and actually put that
helper into the "in" subdirectory. Or just add a few zeros for padding and
put it just into ./cygwin-console-helper.exe (looks less crazy).

The explanation for this fuckup is inside the fhandler.cc source file:

/* Ugly workaround for Windows 7 and later.

First try to just attach to any console which may have started this
app. If that works use this as our "invisible console".

This will fail if not started from the command prompt. In that case,
start
a dummy console application in a hidden state so that we can use its
console
as our invisible console. This probably works everywhere but process
creation is slow and to be avoided if possible so the window station
method
is vastly preferred.

FIXME: This is not completely thread-safe since it creates two
inheritable
handles which are known only to this function. If another thread starts
a process the new process will inherit these handles. However, since
this
function is currently only called at startup and during exec, it
shouldn't
be a big deal. */

[Marc Christiansen]

Bernd Paysan <bernd....@gmx.de> wrote:
> * I've started to generate bindings for system libraries using SWIG. The
> first one that compiled on Windows was OpenGL ES. As WGL is not yet
> generated, you can't open a context to work with it, but it's a start.

Where does one get SWIG with forth support? The documentation on
swig.org doesn't list forth as supported and ./configure for the
snapshot says
[...]
checking for swig... /usr/bin/swig
swig error : Unrecognized option -forth
Use 'swig -help' for available options.
configure: WARNING: *** Swig without -forth. The library bindings cannot be built.
[...]

Unsurprisingly swig -help does not list forth :)

This is using SWIG Version 3.0.5 on x86_64-pc-linux-gnu.

Saluton
Marc

[Bernd Paysan]

You need Gerald Wodni's fork.

git clone g...@github.com:/GeraldWodni/swig.git

[peter....@gmail.com]

On Thursday, 20 August 2015 01:58:36 UTC+2, Bernd Paysan wrote:
> I've uploaded a new snapshot of the current git HEAD of Gforth into the
> usual place
>
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/ (http works, too)
>
> Apart from the ongoing development, the Windows version contains a few
> changes:
>
> * Gforth is started in a way that HOME points to the actual home directory
> (which in Windows is composed of %HOMEDRIVE% and %HOMEPATH%... WTF?), and
> thus all the user-specific stuff actually goes to your home directory - like
> history and such.
>
> * I've added mintty.exe as terminal, which is clearly superior compared to
> the standard DOS box terminal. Unfortunately, I haven't found out how to
> get rid of the DOS box Windows launches when it starts mintty (the
> workaround which is in mintty.exe itself only works when mintty.exe is
> inside a Cygwin install).
>

I am interested to understand why you think mintty is clearly superior?

I have been testing many alternatives to the windows console but in the
end always return to it. What I am really missing is a tabbed interface
I found mintty to display faster but unable to run programs that use
the console API correctly.

> * I've started to generate bindings for system libraries using SWIG. The
> first one that compiled on Windows was OpenGL ES. As WGL is not yet
> generated, you can't open a context to work with it, but it's a start.
>
> * Fixpath during installation now does really fix the search path, before,
> it was broken. I.e. if you use Gforth outside Cygwin, from cmd.exe, you
> should be able to start it from any other working directory. Make sure, you
> have set HOME as mentioned above.
>
> If you have Cygwin installed, use the cygwin bindist tarball instead.

Could it be possible to include also the cygwin dlls in the bindist tarball?

On a company PC you are not always allowed to run installers

Thanks anyway for great work

Peter

[Bernd Paysan]

peter....@gmail.com wrote:

> On Thursday, 20 August 2015 01:58:36 UTC+2, Bernd Paysan wrote:
>> If you have Cygwin installed, use the cygwin bindist tarball instead.
>
> Could it be possible to include also the cygwin dlls in the bindist
> tarball?

The tarball is for users who have cygwin already installed, and having two
different cygwin dlls inside one cygwin install is a very bad idea.

Maybe I can pack up another tarball with the dlls and the needed programs.
However, this requires some testing to make sure it actually works.

> On a company PC you are not always allowed to run installers

[Bernd Paysan]

peter....@gmail.com wrote:

> I am interested to understand why you think mintty is clearly superior?
>
> I have been testing many alternatives to the windows console but in the
> end always return to it. What I am really missing is a tabbed interface
> I found mintty to display faster but unable to run programs that use
> the console API correctly.

mintty is for programs originally written for Linux. These programs all
don't use the console API much, and especially not "correctly", as they
actually expect an xterm. Gforth is such a program. When you use it in the
normal console, it doesn't work that well. In mintty, it works fine.

So as terminal for Gforth, mintty is clearly superior. It's faster, it
behaves correctly in corner cases (such as editing lines which are longer
than the screen width), and it does handle Unicode right. And it supports
the typical X style copy&paste, which makes it feel "right", for me at least
;-).

[jkn...@nicorp.f9.co.uk]

Hi Peter
FWIW This is the best 'standard' Console for a windows system that I have
found. It supports tabs amongst its many features; about the worst feature is
its search-unfriendly name ;-/

http://sourceforge.net/projects/console/

HTH
J^n

[bor...@gmail.com]

X style like copy&paste is available for windows console too if you enable QuickEdit mode from the left top corner icon. One of the first things I always do when getting a new windows system is enabling that for all console windows, by checking in under Defaults. You can also increase the window width, buffer width, etc.

I used to have an utility around that was hiding windows based on window class name, etc. It was a few lines of c code. It is surprising run.exe can't hide mintty for some reason.

On Friday, August 21, 2015 at 5:28:32 PM UTC-5, Bernd Paysan wrote:

[Bernd Paysan]

bor...@gmail.com wrote:
> I used to have an utility around that was hiding windows based on window
> class name, etc. It was a few lines of c code. It is surprising run.exe
> can't hide mintty for some reason.

That's because mintty isn't a console app, but runs another console app,
which needs to attach to a console, and starting with Windows 7, doing so
lets a console pop up.

To hide that, cygwin1.dll has a function, which is calling /bin/cygwin-
console-helper.exe, and that creates a hidden, attachable console
(apparently, that has to be done by a program, which seems to be running in
the background). It's not just hiding the window, it's making the console
completely invisble.

To allow this to work, this cygwin-console-helper.exe must be in /bin. Easy
within a cygwin installation (the root is the install directory), but I had
to find out that the root is in "Program Files". If I install a bin
directory here, and put the helper there, it works.

[bor...@gmail.com]

Nice you got it working.

By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?

5 dup * . 19 ok

That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.

I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...

[rickman]

On 8/23/2015 6:25 PM, bor...@gmail.com wrote:
> Nice you got it working.
>
> By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?
>
> 5 dup * . 19 ok
>
> That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.
>
> I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...

Maybe I am not following what you are saying, but you *do* realize your
system is in base 16 (hex), right?

--

Rick

[bor...@gmail.com]

I have never done everything in relation to setting the base to 16.
I have .gforth-history to prove it, at least as far as my Forth knowledge go.
I am not feeling too well due to a cold/flu so maybe I am a bit more
negative than I should be :)

[rickman]

It would be nice if you didn't top post for sure. But check the base.
I don't know what code you are using, but the base might be getting
changed inside some of the code you are using. First, check the
variable to see if it is 16.

--

Rick

[Coos Haak]

Op Sun, 23 Aug 2015 19:53:30 -0400 schreef rickman:

Good advise, but remember,
base @ .
always prints 10 ;-(
try instead
10 1- .
If you still see F then something is wrong, 9 would be normal.

I don't see any problem:

$ gforth
Gforth 0.7.9_20150820, Copyright (C) 1995-2015 Free Software Foundation,
Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
5 dup * . 25 ok

groet Coos

[Bernd Paysan]

bor...@gmail.com wrote:

> Nice you got it working.
>
> By the way, is it OK in Forth world that after some user(beginner)
> triggered errors, to have not even the most basic operations work any
> longer?
>
> 5 dup * . 19 ok

Ok, as rickman figured out quickly: You are in hex now. Unless you put
yourself there and then produced an error, you shouldn't get into hex mode
by accident. If you do, it's probably a bug.

> That's with the snapshot I just downloaded - I was consistently getting
> that until I restarted GForth.

Normally, you shouldn't. What kind of user-triggered error was there
before?

It helps to reproduce the error, when I know what you exactly did between
"work" and "doesn't work".

[bor...@gmail.com]

It looks like the issue is reproducible on my machine.
Where should I send you .gforth-history file?

5 dup * . 19 ok

base @ . 10 ok

[bor...@gmail.com]

4 dup * . 10 ok
it looks like the system is indeed using 16 base to do computations, even though base variable reports 10.

[rickman]

On 8/23/2015 9:16 PM, bor...@gmail.com wrote:
> It looks like the issue is reproducible on my machine.
> Where should I send you .gforth-history file?
>
> 5 dup * . 19 ok
> base @ . 10 ok

So what base is that?

--

Rick

[rickman]

On 8/23/2015 9:34 PM, bor...@gmail.com wrote:
> 4 dup * . 10 ok
> it looks like the system is indeed using 16 base to do computations, even though base variable reports 10.

Right, base 16...

--

Rick

[bor...@gmail.com]

Got it thanks.
It looks like the "culprit" is 'see'.

base @ 1- . 9 ok
see nip
Code nip
:2: error: No such file or directory
see >>>nip<<<
Backtrace:
$6FFFF84F038 throw
$6FFFF84F310 gdb-addr-sep-char
$A
$23C600
$6FFFF6D3A00
$6FFFF849E38 discode
$6FFFF84ACD0 seecode
$6FFFF84B618 xt-see
$6FFFF801920
$6FFFF84B898 name-see

5 dup * . 19 ok

base @ 1- . F ok

I am guessing because of the error? Or is that the expected behavior for 'see' to change the base and not restore it back?

[Julian Fondren]

On Sunday, August 23, 2015 at 9:30:22 PM UTC-5, bor...@gmail.com wrote:
> Got it thanks.
> It looks like the "culprit" is 'see'.
>
> base @ 1- . 9 ok
> see nip
> Code nip
> :2: error: No such file or directory
> see >>>nip<<<
> Backtrace:
> $6FFFF84F038 throw
> $6FFFF84F310 gdb-addr-sep-char
> $A
> $23C600
> $6FFFF6D3A00
> $6FFFF849E38 discode
> $6FFFF84ACD0 seecode
> $6FFFF84B618 xt-see
> $6FFFF801920
> $6FFFF84B898 name-see
> 5 dup * . 19 ok
> base @ 1- . F ok
>
> I am guessing because of the error? Or is that the expected behavior for 'see' to change the base and not restore it back?

It is the expected behavior of an *error* to not restore much, and you
get an error from SEE NIP

It's of course possible to restore such variables on error, but unless
you use return-stack manipulation the constructions are tedious enough
that I'd rather not restore them ever, but instead set them to definite
values and document this.

: see ( "name" -- ) hex (see) decimal ;

As opposed to:

\ wrapper to restore BASE on error
: see ( "name" -- )
BASE @ >r HEX ['] see catch r> BASE ! throw ;

Of course you can also use higher order words;

: with ( xt-action xt-environment -- )
BASE @ >R ( preserve other 'environmental' variables? )
execute catch
( restore others ) R> BASE ! throw ;

: see ( "name" -- )
['] see [: hex foggy chilly safeish ;] with ;

[bor...@gmail.com]

If you don't handle errors you usually get much better performance for sure.
Kx.com kdb+ also comes to mind. They beat everybody else there as far as
performance is concerned: MS, Oracle, MySQL, etc. One of the tricks they use
is having very minimal to none error handling. But for that I would never
recommend using kdb+ as an OLTP system. Just for OLAP data analysis, after
your data has already been safely stored by a reliable system like Oracle,
SQL Server, MySQL, etc.

I see this kind of "cheating", as far as error handling is concerned, being
promoted by Chuck too and among some Forthers, it seems to me. But then,
I think, we should not be too surprised if Forth is not taking the world
by storm.

[Julian Fondren]

On Sunday, August 23, 2015 at 11:05:04 PM UTC-5, bor...@gmail.com wrote:
> I see this kind of "cheating", as far as error handling is concerned, being
> promoted by Chuck too and among some Forthers, it seems to me. But then,
> I think, we should not be too surprised if Forth is not taking the world
> by storm.

*sigh*, yep, Forth is unpopular because people who aren't familiar with
BASE think it is broken after a base-changing word throws an error.

I wish Forth had a more interesting problem for people to latch on to
than unpopularity, that every trivial complaint could be tied to.

I see this kind of "cheating", as far as error handling is concerned,
being promoted by Chuck too and among some Forthers, it seems to me.

But then, I think, we should not be too surprised if Forthers keep
getting lined up against walls and shot by our alien masters.

[Anton Ertl]

bor...@gmail.com writes:
>Got it thanks.
>It looks like the "culprit" is 'see'.
>
>base @ 1- . 9 ok
>see nip
>Code nip
>:2: error: No such file or directory
>see >>>nip<<<
>Backtrace:
>$6FFFF84F038 throw
>$6FFFF84F310 gdb-addr-sep-char
>$A
>$23C600
>$6FFFF6D3A00
>$6FFFF849E38 discode
>$6FFFF84ACD0 seecode
>$6FFFF84B618 xt-see
>$6FFFF801920
>$6FFFF84B898 name-see
>5 dup * . 19 ok
>base @ 1- . F ok
>
>I am guessing because of the error? Or is that the expected behavior for 'see' to change the base and not restore it back?

No, these are two bugs in in Gforth: 1) HEX is used instead of
BASE-EXECUTE. 2) check-gdb-syntax does not work and causes the
exception.

Chuck Moore advocated always setting BASE to the value you expect (I
guess this means that you should have written "5 DUP * DECIMAL .").
Many people take his word as gospel, but these days we have CATCH and
can do better. And IMO we should do better.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

[Elizabeth D. Rather]

On 8/23/15 12:25 PM, bor...@gmail.com wrote:
> Nice you got it working.
>
> By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?
>
> 5 dup * . 19 ok
>
> That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.
>
> I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...

The concept is that the programmer has more freedom, coupled with more
responsibility, than with some other languages. Depending on the system
you're using, it shouldn't take more than a second or so to reboot and
start over. Your compiler is small, simple, and fast, and is not your nanny.

I taught Forth classes for many years. If the regulars here will forgive
me for repeating an old story, at one point I developed a Forth that
checked for all of the common newbie errors and issued messages. I found
that students kept getting more and more frustrated at their programs
not working. When I looked over their shoulders and pointed out all the
error messages they were getting, they said, "Oh, yes, I get those all
the time, I just ignore them." So I took the checks out. When the
students had to reboot they learned something.

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."
==================================================

[Elizabeth D. Rather]

Hello? The word . prints out TOS using the current BASE. Therefore,
whatever BASE is set to, the phrase 'base @ .' will display 10.

[Mark Wills]

^^^ what Elizabeth said!

decimal base @ .

FIFY :-)

[rickman]

I was trying to get Borat to think about it rather than just spelling it
out for him.

--

Rick

[Bernd Paysan]

Well, it has one more problem here: I don't pack gdb with Gforth for the
setup.exe, and therefore, the 64 bit version has no disassembler at all.

Maybe I should just add the necessary code to one the 386 disassemblers I
have, so that it understands amd64 code, too, and not use GDB. The few
platforms where we don't have our own disassembler are unfortunately those
where GDB may not be available, either.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Well, it has one more problem here: I don't pack gdb with Gforth for the
>setup.exe, and therefore, the 64 bit version has no disassembler at all.

Thought so, and the short-term fix is to fall back to DUMP.

>Maybe I should just add the necessary code to one the 386 disassemblers I
>have, so that it understands amd64 code, too, and not use GDB. The few
>platforms where we don't have our own disassembler are unfortunately those
>where GDB may not be available, either.

In the medium term (weeks), I want to call the routine from binutils;
that should be available on Windows, too, no? If that does not work
out, enhancing the 386 disassemblers is also an option.

[Bernd Paysan]

Anton Ertl wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>>Well, it has one more problem here: I don't pack gdb with Gforth for the
>>setup.exe, and therefore, the 64 bit version has no disassembler at all.
>
> Thought so, and the short-term fix is to fall back to DUMP.

You probably should pack the gdb attempt into a catch, and if that fails for
whatever reason, use dump.

>>Maybe I should just add the necessary code to one the 386 disassemblers I
>>have, so that it understands amd64 code, too, and not use GDB. The few
>>platforms where we don't have our own disassembler are unfortunately those
>>where GDB may not be available, either.
>
> In the medium term (weeks), I want to call the routine from binutils;
> that should be available on Windows, too, no? If that does not work
> out, enhancing the 386 disassemblers is also an option.

That should be available on Windows, too.

[Elizabeth D. Rather]

On 8/23/15 10:37 PM, Mark Wills wrote:
> On Monday, 24 August 2015 09:11:24 UTC+1, Elizabeth D. Rather wrote:
>> On 8/23/15 4:10 PM, rickman wrote:
>>> On 8/23/2015 9:16 PM, bor...@gmail.com wrote:
>>>> It looks like the issue is reproducible on my machine.
>>>> Where should I send you .gforth-history file?
>>>>
>>>> 5 dup * . 19 ok
>>>> base @ . 10 ok
>>>
>>> So what base is that?
>>>
>>
>> Hello? The word . prints out TOS using the current BASE. Therefore,
>> whatever BASE is set to, the phrase 'base @ .' will display 10.
>

> ^^^ what Elizabeth said!
>
> decimal base @ .
>
> FIFY :-)

Actually, base @ decimal . would be more revealing. :-)

[Mark Wills]

HA HA!

DOH! <faceplant!>

Thank you!!

[bor...@gmail.com]

Thanks Elizabeth.
I was confused by the fact that I was not setting base to 16 myself. 'see'
command in Gforth was failing and left the base flipped to 16 without me
realizing it. I surely learned something out of that. In latest snapshot
they fixed the issue though.

By the way, I bought your "Forth Application Techniques" book. I find it to be
the best Forth intro book out there. I think Starting Forth for a programmer is
a bit annoying, spending too much time on well known simple concepts and then
quickly skimming over deeper aspects related to Forth compiler/interpreter/etc.
I find your text to be clear and concise, how I like technical books to be.
I am almost tempted to recommend putting Forth Application Techniques up on
forth.com site instead of (or in addition to) Starting Forth.

[Elizabeth D. Rather]

On 8/25/15 4:34 PM, bor...@gmail.com wrote:
...

>
> By the way, I bought your "Forth Application Techniques" book. I find it to be
> the best Forth intro book out there. I think Starting Forth for a programmer is
> a bit annoying, spending too much time on well known simple concepts and then
> quickly skimming over deeper aspects related to Forth compiler/interpreter/etc.
> I find your text to be clear and concise, how I like technical books to be.
> I am almost tempted to recommend putting Forth Application Techniques up on
> forth.com site instead of (or in addition to) Starting Forth.
>

Thank you! At least for now, we feel Forth Application Techniques (FAT)
is best suited to being in paper, as it's easy to have it open on your
desk as you write code. But we will give your suggestion some thought.

[HAA]

bor...@gmail.com wrote:
> ...

> I was confused by the fact that I was not setting base to 16 myself. 'see'
> command in Gforth was failing and left the base flipped to 16 without me
> realizing it. I surely learned something out of that. In latest snapshot
> they fixed the issue though.

LMI Forth changes base to decimal after ABORT. You want to work in hex,
mis-type something, and bingo you're in decimal ! It threw me every time.

[Coos Haak]

Op Tue, 1 Sep 2015 21:57:18 +1000 schreef HAA:

Most implementations don't touch BASE.
Setting BASE to 1 and then printing a number mostly
gives overflow in <# .. #>
Setting BASE to 0 may give a division exception.

I have this code in my error-recovery
BASE @ 37 2 WITHIN IF DECIMAL THEN
so BASE is only changed if somehow a program tries
to set BASE to a wrong number. There is an exception
when printing a number but afterwards we are in decimal.

groet Coos

[HAA]

Assuming 0 or 1 doesn't crash the system first :) In practice
nobody sets BASE to a value they don't intend to use.

[dunno]

IIRC ANS standard specify BASE value as number in range 2..32

--
dunno

[HAA]

6.1.0750 BASE
CORE

( -- a-addr )

a-addr is the address of a cell containing the current number-conversion
radix {{2...36}}.

36 (10 digits + 26 letters) allows numbers to be printed using the characters
'0'..'9' 'A'..'Z'

[dunno]

Yes, it's 36, thanks for correction.

--
dunno