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


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

New Gforth "qixi" Snapshot

Started byBernd Paysan <bernd.paysan@gmx.de>
First post2015-08-20 01:58 +0200
Last post2015-08-23 05:34 -0700
Articles 20 on this page of 46 — 15 participants

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


Contents

  New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 01:58 +0200
    Re: New Gforth "qixi" Snapshot "Alex McDonald" <blog@rivadpm.com> - 2015-08-20 09:41 +0100
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 14:21 +0200
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 18:54 +0200
        Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 20:12 +0200
    Re: New Gforth "qixi" Snapshot Marc Christiansen <usenetmail@solar-empire.de> - 2015-08-20 20:42 +0200
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 22:45 +0200
    Re: New Gforth "qixi" Snapshot peter.m.falth@gmail.com - 2015-08-21 11:47 -0700
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-21 23:23 +0200
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-22 00:28 +0200
        Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 10:38 -0700
          Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-23 23:53 +0200
            Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 15:25 -0700
              Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 18:42 -0400
                Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 16:43 -0700
                  Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 19:53 -0400
                    Re: New Gforth "qixi" Snapshot Coos Haak <chforth@hccnet.nl> - 2015-08-24 01:58 +0200
              Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-24 02:05 +0200
                Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 18:16 -0700
                  Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 18:34 -0700
                    Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 22:10 -0400
                      Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 19:30 -0700
                        Re: New Gforth "qixi" Snapshot Julian Fondren <julian.fondren@gmail.com> - 2015-08-23 20:27 -0700
                          Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 21:05 -0700
                            Re: New Gforth "qixi" Snapshot Julian Fondren <julian.fondren@gmail.com> - 2015-08-23 21:20 -0700
                        Re: New Gforth "qixi" Snapshot anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-24 07:10 +0000
                          Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-24 15:17 +0200
                            Re: New Gforth "qixi" Snapshot anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-24 15:21 +0000
                              Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-24 17:36 +0200
                    Re: New Gforth "qixi" Snapshot Julian Fondren <ayrnieu@gmail.com> - 2015-08-23 19:12 -0700
                  Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 22:10 -0400
                    Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-23 22:11 -1000
                      Re: New Gforth "qixi" Snapshot Mark Wills <markwills1970@gmail.com> - 2015-08-24 01:37 -0700
                        Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-24 08:57 -0400
                        Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-24 11:13 -1000
                          Re: New Gforth "qixi" Snapshot Mark Wills <markwills1970@gmail.com> - 2015-08-25 03:09 -0700
                          Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-25 19:34 -0700
                            Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-25 21:38 -1000
                            Re: New Gforth "qixi" Snapshot "HAA" <someone@microsoft.com> - 2015-09-01 21:57 +1000
                              Re: New Gforth "qixi" Snapshot Coos Haak <chforth@hccnet.nl> - 2015-09-01 16:15 +0200
                                Re: New Gforth "qixi" Snapshot "HAA" <someone@microsoft.com> - 2015-09-03 16:05 +1000
                                  Re: New Gforth "qixi" Snapshot dunno <dunno@dunno.dunno> - 2015-09-05 03:25 +0000
                                    Re: New Gforth "qixi" Snapshot "HAA" <someone@microsoft.com> - 2015-09-05 21:33 +1000
                                      Re: New Gforth "qixi" Snapshot dunno <dunno@dunno.dunno> - 2015-09-05 18:07 +0000
              Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-23 22:01 -1000
      Re: New Gforth "qixi" Snapshot jkn_gg@nicorp.f9.co.uk - 2015-08-23 05:34 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →


#41480

Fromrickman <gnuarm@gmail.com>
Date2015-08-23 22:10 -0400
Message-ID<mrduc0$i0d$3@dont-email.me>
In reply to#41478
On 8/23/2015 9:34 PM, borota@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

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


#41482

Fromborota@gmail.com
Date2015-08-23 19:30 -0700
Message-ID<08ae1444-8191-43af-ac0d-318e52d7ead4@googlegroups.com>
In reply to#41480
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?

On Sunday, August 23, 2015 at 9:10:49 PM UTC-5, rickman 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

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


#41483

FromJulian Fondren <julian.fondren@gmail.com>
Date2015-08-23 20:27 -0700
Message-ID<194425fe-404b-4220-9162-ef84ba8991bf@googlegroups.com>
In reply to#41482
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 ;

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


#41484

Fromborota@gmail.com
Date2015-08-23 21:05 -0700
Message-ID<e8493c94-5676-4a13-a7f1-2d7e7418f1d5@googlegroups.com>
In reply to#41483
On Sunday, August 23, 2015 at 10:27:29 PM UTC-5, Julian Fondren wrote:
> 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 ;

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.

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


#41485

FromJulian Fondren <julian.fondren@gmail.com>
Date2015-08-23 21:20 -0700
Message-ID<4297cf38-3a8c-4229-8064-a823aa61c1fa@googlegroups.com>
In reply to#41484
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.

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


#41487

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2015-08-24 07:10 +0000
Message-ID<2015Aug24.091059@mips.complang.tuwien.ac.at>
In reply to#41482
borota@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/

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


#41497

FromBernd Paysan <bernd.paysan@gmx.de>
Date2015-08-24 15:17 +0200
Message-ID<mrf5dj$q06$1@dont-email.me>
In reply to#41487
Anton Ertl wrote:

> borota@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.

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.

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


#41500

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2015-08-24 15:21 +0000
Message-ID<2015Aug24.172140@mips.complang.tuwien.ac.at>
In reply to#41497
Bernd Paysan <bernd.paysan@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.

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

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


#41501

FromBernd Paysan <bernd.paysan@gmx.de>
Date2015-08-24 17:36 +0200
Message-ID<mrfdj2$2db$1@dont-email.me>
In reply to#41500
Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@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.

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


#41481

FromJulian Fondren <ayrnieu@gmail.com>
Date2015-08-23 19:12 -0700
Message-ID<b9fbdb73-a908-4b64-ae9b-23ba56d3fc4d@googlegroups.com>
In reply to#41478
On Sunday, August 23, 2015 at 8:34:26 PM UTC-5, bor...@gmail.com wrote:
> 
> On Sunday, August 23, 2015 at 8:16:55 PM UTC-5, 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
>
> 4 dup * . 10  ok
> it looks like the system is indeed using 16 base to do computations, even though base variable reports 10.

This outputs "10" for any valid base:

  BASE @ .

As suggested a simple way to get an idea of the base is

  BASE @ 1- .

Which would output 1 for binary, 7 for octal, 9 for decimal, etc.

You might also like

  BASE CELL DUMP   \ or BASE 1 CELLS DUMP

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


#41479

Fromrickman <gnuarm@gmail.com>
Date2015-08-23 22:10 -0400
Message-ID<mrduat$i0d$2@dont-email.me>
In reply to#41477
On 8/23/2015 9:16 PM, borota@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

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


#41491

From"Elizabeth D. Rather" <erather@forth.com>
Date2015-08-23 22:11 -1000
Message-ID<w8KdnQ1abt03TEfInZ2dnUU7-b2dnZ2d@supernews.com>
In reply to#41479
On 8/23/15 4:10 PM, rickman wrote:
> On 8/23/2015 9:16 PM, borota@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.

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

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


#41492

FromMark Wills <markwills1970@gmail.com>
Date2015-08-24 01:37 -0700
Message-ID<e120410a-c268-46b0-882c-0cfde36342b9@googlegroups.com>
In reply to#41491
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, borota@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.
> 
> 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."
> ==================================================

^^^ what Elizabeth said!

decimal base @ .

FIFY :-)

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


#41496

Fromrickman <gnuarm@gmail.com>
Date2015-08-24 08:57 -0400
Message-ID<mrf47p$kuq$1@dont-email.me>
In reply to#41492
On 8/24/2015 4:37 AM, 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, borota@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.
>>
>> 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."
>> ==================================================
>
> ^^^ what Elizabeth said!
>
> decimal base @ .

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

-- 

Rick

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


#41504

From"Elizabeth D. Rather" <erather@forth.com>
Date2015-08-24 11:13 -1000
Message-ID<ZLudnWZi-apmFUbInZ2dnUU7-R2dnZ2d@supernews.com>
In reply to#41492
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, borota@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. :-)

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

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


#41512

FromMark Wills <markwills1970@gmail.com>
Date2015-08-25 03:09 -0700
Message-ID<1fe1d803-0110-416a-bd7d-40ee60898f6e@googlegroups.com>
In reply to#41504
On Monday, 24 August 2015 22:13:33 UTC+1, Elizabeth D. Rather  wrote:
> 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, borota@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. :-)
> 
> 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."
> ==================================================

HA HA!

DOH! <faceplant!>

Thank you!!

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


#41533

Fromborota@gmail.com
Date2015-08-25 19:34 -0700
Message-ID<9b526861-2a2d-4186-9536-ace21328c59a@googlegroups.com>
In reply to#41504
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.

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


#41542

From"Elizabeth D. Rather" <erather@forth.com>
Date2015-08-25 21:38 -1000
Message-ID<55DD6CFE.3010005@forth.com>
In reply to#41533
On 8/25/15 4:34 PM, borota@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.

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

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


#41636

From"HAA" <someone@microsoft.com>
Date2015-09-01 21:57 +1000
Message-ID<ms43nt$i04$1@speranza.aioe.org>
In reply to#41533
borota@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.


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


#41640

FromCoos Haak <chforth@hccnet.nl>
Date2015-09-01 16:15 +0200
Message-ID<19ffsoxna1bin.n8dfv0rntsl6$.dlg@40tude.net>
In reply to#41636
Op Tue, 1 Sep 2015 21:57:18 +1000 schreef HAA:

> borota@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.

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

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


Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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


csiph-web