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

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

Importing from wordlists.

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

Contents

  Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-29 12:43 +0000
    Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-29 06:15 -0700
      Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-29 15:11 +0000
      Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-29 09:14 -0700
        Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-29 19:52 +0000
          Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-30 12:39 +0000
            Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-30 09:09 -0700
              Re: Importing from wordlists. stephen@mpeforth.com (Stephen Pelc) - 2015-03-30 16:42 +0000
              Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-30 17:55 -0700
                Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-04-02 05:41 -0700
            Re: Importing from wordlists. "HAA" <someone@microsoft.com> - 2015-03-31 13:26 +1000
              Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-30 19:54 -0700
                Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-31 02:23 -0700
                  Re: Importing from wordlists. Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-31 12:02 +0200
                    Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-31 07:41 -0700
                      Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-03-31 16:36 +0100
                  Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-31 16:52 +0000
                    Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-03-31 18:33 +0100
                      Re: Importing from wordlists. JennyB <jennybrien@googlemail.com> - 2015-03-31 15:25 -0700
                        Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 00:59 +0000
                          Re: Importing from wordlists. JennyB <jennybrien@googlemail.com> - 2015-04-01 08:05 -0700
                            Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 15:25 +0000
                            Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 15:58 +0000
                        Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 15:57 +0100
                      Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-03-31 23:58 +0100
                        Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 02:00 +0200
                          Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-31 18:48 -0700
                          Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-01 08:03 +0100
                            Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 16:38 +0200
                              Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 15:54 +0100
                                Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 17:41 +0200
                                  Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 18:24 +0200
                                    Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-02 05:27 +0200
                                      Re: Importing from wordlists. Coos Haak <chforth@hccnet.nl> - 2015-04-02 12:38 +0200
                                        Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-02 15:45 +0100
                                          Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-02 17:25 +0100
                                            Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-03 02:00 +0200
                                              Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-03 20:49 +0100
                                                Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 11:08 -1000
                                                  Re: Importing from wordlists. Paul Rubin <no.email@nospam.invalid> - 2015-04-03 14:14 -0700
                                                    Re: Importing from wordlists. franck.bensusan@gmail.com - 2015-04-04 02:47 -0700
                                                  Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-03 21:37 +0000
                                                    Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 14:05 -1000
                                                      Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-04 05:14 +0200
                                                      Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-04 14:07 +0000
                                                      Re: Importing from wordlists. Paul Rubin <no.email@nospam.invalid> - 2015-04-04 14:02 -0700
                                                        Re: Importing from wordlists. Melzzzzz <mel@zzzzz.com> - 2015-04-05 00:36 +0200
                                                    Re: Importing from wordlists. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 04:35 +0200
                                                      Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-04 13:30 +0000
                                                        Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-04 16:38 +0000
                                                        Re: Importing from wordlists. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 16:48 +0200
                                                  Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 23:49 +0100
                                                    Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 14:09 -1000
                                                      Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-04 20:30 +0100
                                                      Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-04-04 13:29 -0700
                                                  Re: Importing from wordlists. Johan Kotlinski <kotlinski@gmail.com> - 2015-04-03 23:57 -0700
                                                    Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 21:35 -1000
                                                    Re: Importing from wordlists. krishna.myneni@ccreweb.org - 2015-04-04 10:00 -0700
                                                    Re: Importing from wordlists. Melzzzzz <mel@zzzzz.com> - 2015-04-04 19:08 +0200
                                        Re: Importing from wordlists. Coos Haak <chforth@hccnet.nl> - 2015-04-02 22:45 +0200
                                          Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-03 02:08 +0200
                                      Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-02 20:59 +0100
                                        Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-03 02:03 +0200
                                          Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-03 20:52 +0100
                                          Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-09 12:39 +0100
                              Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 15:03 +0000
                        Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 01:10 +0000
                          Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-01 07:32 +0100
                            Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 07:52 +0000
                            Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 10:39 +0000
                              SYNONYM (wase: Importing from wordlists.) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 11:29 +0000
                                Re: SYNONYM (wase: Importing from wordlists.) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 15:08 +0000
                        Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 15:49 +0100
                        Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 17:12 +0000
                          Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 18:45 +0100
                          Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-01 20:43 +0100
    Re: Importing from wordlists. mhx@iae.nl (Marcel Hendrix) - 2015-04-04 09:53 +0200
      Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-04 14:20 +0000
        Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-04 17:10 +0000
          Re: Importing from wordlists. mhx@iae.nl - 2015-04-04 11:25 -0700

Page 4 of 4 — ← Prev page 1 2 3 [4]

#37858

Coos Haak wrote:

>> I tried, but failed to download. Norton Internet Security deleted it and
>> thinks that WS.Reputation.1 is the origin of the thread.
> 
> Swiching to MacAfee may solve my problem, as Alex McDonald confirms.

WS.Reputation.1 is a threat-model by popularity.  If you see an executable 
nobody else saw before, it will take actions.

You (me, somebody) could submit this file to Symantec here 
https://submit.symantec.com/false_positive/ then it probably will be white-
listed.

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

#37849

On 02/04/2015 04:27, Bernd Paysan wrote:
> Bernd Paysan wrote:
>
>> Bernd Paysan wrote:
>>
>>> Alex McDonald wrote:
>>>> I've tried in the distant past, but unsuccesfully. Let me know what the
>>>> steps are and I'll install the tools and attempt it again.
>
> I finally managed to compile it with the 64 bit Cygwin version (some old
> mmap bug of Cygwin apparently made it into Cygwin64, and the old fix
> fortunately works there ;-).  If you want to try, an "inofficial" snapshot
> is now here:
>
> http://bernd-paysan.de/gforth-0.7.9_20150221.exe
>
> If someone confirms that it works, I'll make it an official snapshot
> (probably after updating the snapshot date).
>

Installing it on 64 bit Windows 7 it gave exactly the same messages that 
Alex reported in his email. After the last message I pressed enter and 
it finished installing. It seemed to work when I started it.

I then ran the LexGen test program and it ran to completion perfectly.

I'm in the middle of updating ANS Forth test programs to test some of 
the Forth 2012 additions and I tried those. It ran through them with a 
few errors that I don't have time to investigate for a couple of days. I 
did spot that don't seem to have implemented UNESCAPE

So it looks good if those messages Alex reported are irrelevant.

-- 
Gerry

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

#37856

Gerry Jackson wrote:
> I'm in the middle of updating ANS Forth test programs to test some of
> the Forth 2012 additions and I tried those. It ran through them with a
> few errors that I don't have time to investigate for a couple of days. I
> did spot that don't seem to have implemented UNESCAPE

Apparently a typo, it's called UNESCAPES.  Fortunately, that's easy to fix.

I'd certainly like to integrate your extended Forth2012 testing framework.

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

#37897

On 03/04/2015 01:03, Bernd Paysan wrote:
> Gerry Jackson wrote:
>> I'm in the middle of updating ANS Forth test programs to test some of
>> the Forth 2012 additions and I tried those. It ran through them with a
>> few errors that I don't have time to investigate for a couple of days. I
>> did spot that don't seem to have implemented UNESCAPE
>
> Apparently a typo, it's called UNESCAPES.  Fortunately, that's easy to fix.
>
> I'd certainly like to integrate your extended Forth2012 testing framework.
>

It still needs a bit more work and doesn't cover everything new in 
Forth2012. I can't do anything to it until at least Sunday. When a bit 
tidier I'll email a copy to you.

-- 
Gerry

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

#38066

On 03/04/2015 01:03, Bernd Paysan wrote:
> Gerry Jackson wrote:
>> I'm in the middle of updating ANS Forth test programs to test some of
>> the Forth 2012 additions and I tried those. It ran through them with a
>> few errors that I don't have time to investigate for a couple of days. I
>> did spot that don't seem to have implemented UNESCAPE
>
> Apparently a typo, it's called UNESCAPES.  Fortunately, that's easy to fix.
>
> I'd certainly like to integrate your extended Forth2012 testing framework.
>

I've emailed you the updated Forth 2012 tests. Please let me know if 
they don't arrrive.

-- 
Gerry

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

#37810

In article <mfgvqo$vu4$1@dont-email.me>,
Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Gerry Jackson wrote:
>> Incidentally I'm still using what is now a very old version of GForth,
>> 0.7.0, which I believe was the last one for which a Windows executable
>> was made available. Not everybody wants to compile from the latest
>> source code in your repository - after all I primarily develop and use
>> my own system. It would be better for GForth's image if a more recent
>> version of GForth was made available as a Windows executable.
>
>Unfortunately, the Windows users are the ones who need the most care and
>give back the least ;-).  I could try to build a recent snapshot, but
>really, we need a volunteer for that.  Somebody who uses Windows for more
>than just the annual tax report...

Dutch taxes have supported wine for years now...

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

#37793

In article <mff8p3$q11$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 31/03/2015 18:33, Alex McDonald wrote:
>> on 31/03/2015 17:52:22, Albert wrote:
>>> In article <0165a96b-3372-4a43-8e77-045994fb5934@googlegroups.com>,
>>> Mark Wills  <markwills1970@gmail.com> wrote:
>>
>>>>
>>>>
>>>> --BLOCK-00046---------
>>>> : SYNONYM
>>>>   CREATE  BL WORD FIND DUP IF
>>>>     SWAP , IMMEDIATE 1+ IF
>>>>       DOES> @ EXECUTE
>>>>     ELSE
>>>>       DOES> STATE @ IF
>>>>         @ ,
>>>>       ELSE
>>>>         @ EXECUTE
>>>>       THEN
>>>>     THEN
>>>>   ELSE
>>>>     TRUE ABORT" Word not found"
>>>>   THEN ;
>>>
>>> Oh boy.
>>> I don't think it is worthwhile to define SYNONYM
>>> pseudo portably. My comrade-in-arms Coos Haak
>>> tried this one and it didn't work on his Forth
>>> of r the test that has been snipped.
>>> (The SYNONYM he implemented himself passed.)
>>
>> : synonym
>>    : bl word find
>>      >r compile, postpone ;
>>    r> 1+ if immediate then ;
>>
>> I think that should be pretty portable across ANS Forths. (I know, it
>> uses the deprectated FIND.)
>>
>
>That doesn't meet the specification of SYNONYM.
>
>15.6.2.2264 SYNONYM TOOLS EXT
>( “<spaces>newname” “<spaces>oldname” – – )
>For both strings skip leading space delimiters. Parse newname and
>oldname delimited by a space. Create a definition for newname with
>the semantics defined below. Newname may be the same as oldname;
>when looking up oldname, newname shall not be found.
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^

IMO this just means that if the names are the same, the new definition
is a synonym of the old definition, not of itself, which doesn't
make sense.

>e.g. on GForth
>' DUP SYNONYM DUP DUP ' DUP . .' DUP SYNONYM DUP DUP ' DUP . .
>redefined dup with DUP  2143110184 4268604  ok
>
>although I must confess I don't know why that condition is there.
>
>Also it doesn't allow a synonym of a deferred word to be reassigned, but
>it could be argued that IS and DEFER! cannot be applied to a synonym of
>a deferred word - but IMHO that ought to be possible (it is on VFX Forth
>and my system).

A synonym has a regular xt. So why do you expect problems or care to
mention IS and DEFER! ? You might as well wonder whether after
    SYNONYM APE JAN
the use of
    ' JAN EXECUTE
will work or not.

>
>--
>Gerry

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]

#37798

On 01/04/2015 02:10, Albert van der Horst wrote:
>> Also it doesn't allow a synonym of a deferred word to be reassigned, but
>> >it could be argued that IS and DEFER! cannot be applied to a synonym of
>> >a deferred word - but IMHO that ought to be possible (it is on VFX Forth
>> >and my system).
> A synonym has a regular xt. So why do you expect problems or care to
> mention IS and DEFER! ? You might as well wonder whether after
>      SYNONYM APE JAN
> the use of
>      ' JAN EXECUTE
> will work or not.
>

I only raised the point because of the specifications of IS has the 
statement "An ambiguous condition exists if name was not defined by 
DEFER". Similarly ACTION-OF DEFER@ and DEFER!.

If we have

defer jan
synonym ape jan

Is APE defined by DEFER or by SYNONYM and so is this valid?

:noname ... ; is ape

A language lawyer would surely conclude that APE is defined by SYNONYM 
and so that is invalid - that may not be what was intended. So Alex can 
claim that his definition of SYNONYM is valid.

-- 
Gerry

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

#37800

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>If we have
>
>defer jan
>synonym ape jan
>
>Is APE defined by DEFER or by SYNONYM and so is this valid?
>
>:noname ... ; is ape
>
>A language lawyer would surely conclude that APE is defined by SYNONYM 
>and so that is invalid - that may not be what was intended.

The language lawyer would be right.  SYNONYM explicitly copies the
interpretation and compilation semantics, and does not specify, e.g.,
"TO name" semantics.  IIRC we (or at least I) did consider "TO name"
semantics etc., but did not require it because that would require
changes in the header structure of many systems.

Of course, a system that implements a SYNONYM that also copies the "TO
name" semantics and "IS name" semantics, and has the same xt as the
original (so DEFER@ and DEFER! work) is standard, but a program that
uses these features isn't.

- 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 2014: http://www.euroforth.org/ef14/

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

#37803

In article <mfg3b7$tcd$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 01/04/2015 02:10, Albert van der Horst wrote:
>>> Also it doesn't allow a synonym of a deferred word to be reassigned, but
>>> >it could be argued that IS and DEFER! cannot be applied to a synonym of
>>> >a deferred word - but IMHO that ought to be possible (it is on VFX Forth
>>> >and my system).
>> A synonym has a regular xt. So why do you expect problems or care to
>> mention IS and DEFER! ? You might as well wonder whether after
>>      SYNONYM APE JAN
>> the use of
>>      ' JAN EXECUTE
>> will work or not.
>>
>
>I only raised the point because of the specifications of IS has the
>statement "An ambiguous condition exists if name was not defined by
>DEFER". Similarly ACTION-OF DEFER@ and DEFER!.
>
>If we have
>
>defer jan
>synonym ape jan
>
>Is APE defined by DEFER or by SYNONYM and so is this valid?
>
>:noname ... ; is ape
>
>A language lawyer would surely conclude that APE is defined by SYNONYM
>and so that is invalid - that may not be what was intended. So Alex can
>claim that his definition of SYNONYM is valid.

I see your point now. Somehow in the design of ciforth I circumvented
(prevented) issues like this. I shun forward parsing words like TO and IS
like the plague.

Then I define DEFER as a loadable extension with a straightforward
slow implementation and zero surprises.

The problem is in fact more wide spread and applies to ALIAS as well.

: VARIABLE CREATE _ , DOES> ;

VARIABLE JAN
SYNONYM APE JAN

Is
' APE >BODY valid ?
After all APE is not defined by CREATE.

>
>--
>Gerry

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]

#37805 — SYNONYM (wase: Importing from wordlists.)

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>I see your point now. Somehow in the design of ciforth I circumvented
>(prevented) issues like this. I shun forward parsing words like TO and IS
>like the plague.

But the problem here is not the parsing words, but the "was defined
with <word>".  So even the non-parsing DEFER@ DEFER! (that were
designed to avoid the problems of parsing words) are affected, as well
as >BODY and DOES> (which both are only guaranteed to work on words
that are defined by CREATE).

- 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 2014: http://www.euroforth.org/ef14/

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

#37812 — Re: SYNONYM (wase: Importing from wordlists.)

In article <2015Apr1.132929@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>I see your point now. Somehow in the design of ciforth I circumvented
>>(prevented) issues like this. I shun forward parsing words like TO and IS
>>like the plague.
>
>But the problem here is not the parsing words, but the "was defined
>with <word>".  So even the non-parsing DEFER@ DEFER! (that were
>designed to avoid the problems of parsing words) are affected, as well
>as >BODY and DOES> (which both are only guaranteed to work on words
>that are defined by CREATE).

True, I acknowledge that in the part you snipped.

Avoiding IS and TO solves some problems, but not that one.

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

#37807

on 31/03/2015 23:58:42, Gerry Jackson wrote:
> On 31/03/2015 18:33, Alex McDonald wrote:

>>
>> : synonym
>>    : bl word find
>>      >r compile, postpone ;
>>    r> 1+ if immediate then ;
>>
>> I think that should be pretty portable across ANS Forths. (I know, it
>> uses the deprectated FIND.)
>>
> 
> That doesn't meet the specification of SYNONYM.
> 
> 15.6.2.2264 SYNONYM TOOLS EXT
> ( “<spaces>newname” “<spaces>oldname” – – )
> For both strings skip leading space delimiters. Parse newname and
> oldname delimited by a space. Create a definition for newname with
> the semantics defined below. Newname may be the same as oldname;
> when looking up oldname, newname shall not be found.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> e.g. on GForth
> ' DUP SYNONYM DUP DUP ' DUP . .' DUP SYNONYM DUP DUP ' DUP . .
> redefined dup with DUP  2143110184 4268604  ok
> 
> although I must confess I don't know why that condition is there.

6.1.0450 : “colon” ... The current definition shall not be findable in
the dictionary until it is ended (or until the execution of DOES> in some
systems).

So if the sequence is : ... FIND ... POSTPONE ; the definition at : isn't
findable until after ; is compiled. In which case (if I understand the
example you've given) Gforth is finding the newly coined newname in
error.

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

#37818

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> : synonym
>>    : bl word find
>>      >r compile, postpone ;
>>    r> 1+ if immediate then ;
>>
>> I think that should be pretty portable across ANS Forths. (I know, it
>> uses the deprectated FIND.)
>>
>
>That doesn't meet the specification of SYNONYM.
>
>15.6.2.2264 SYNONYM TOOLS EXT
>( “<spaces>newname” “<spaces>oldname” – – )
>For both strings skip leading space delimiters. Parse newname and
>oldname delimited by a space. Create a definition for newname with
>the semantics defined below. Newname may be the same as oldname;
>when looking up oldname, newname shall not be found.
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
>e.g. on GForth
>' DUP SYNONYM DUP DUP ' DUP . .' DUP SYNONYM DUP DUP ' DUP . .
>redefined dup with DUP  2143110184 4268604  ok

There is no guarantee from SYNONYM that the xt of newname is the same
as that of oldname.

The requirement you underline is satisfied by the definition above.
However, the requirement to have both the same interpretation
semantics and the same compilation semantics as oldname is not (in
general), as you will see when you try to produce a SYNONYM of S" in
Gforth with this definition of SYNONYM.  That's because FIND does not
produce both (at least not in a single invocation of FIND).

- 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 2014: http://www.euroforth.org/ef14/

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

#37820

on 01/04/2015 18:12:57,  wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>> : synonym
>>>    : bl word find
>>>      >r compile, postpone ;
>>>    r> 1+ if immediate then ;
>>>
>>> I think that should be pretty portable across ANS Forths. (I know, it
>>> uses the deprectated FIND.)
>>>
>>
>>That doesn't meet the specification of SYNONYM.
>>
>>15.6.2.2264 SYNONYM TOOLS EXT
>>( “<spaces>newname” “<spaces>oldname” – – )
>>For both strings skip leading space delimiters. Parse newname and
>>oldname delimited by a space. Create a definition for newname with
>>the semantics defined below. Newname may be the same as oldname;
>>when looking up oldname, newname shall not be found.
>>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>e.g. on GForth
>>' DUP SYNONYM DUP DUP ' DUP . .' DUP SYNONYM DUP DUP ' DUP . .
>>redefined dup with DUP  2143110184 4268604  ok
> 
> There is no guarantee from SYNONYM that the xt of newname is the same
> as that of oldname.
> 
> The requirement you underline is satisfied by the definition above.
> However, the requirement to have both the same interpretation
> semantics and the same compilation semantics as oldname is not (in
> general), as you will see when you try to produce a SYNONYM of S" in
> Gforth with this definition of SYNONYM.  That's because FIND does not
> produce both (at least not in a single invocation of FIND).

Ah, well played. I'd forgotten about that.

> 
> - anton

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

#37822

On 01/04/2015 18:12, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>> : synonym
>>>     : bl word find
>>>       >r compile, postpone ;
>>>     r> 1+ if immediate then ;
>>>
>>> I think that should be pretty portable across ANS Forths. (I know, it
>>> uses the deprectated FIND.)
>>>
>>
>> That doesn't meet the specification of SYNONYM.
>>
>> 15.6.2.2264 SYNONYM TOOLS EXT
>> ( “<spaces>newname” “<spaces>oldname” – – )
>> For both strings skip leading space delimiters. Parse newname and
>> oldname delimited by a space. Create a definition for newname with
>> the semantics defined below. Newname may be the same as oldname;
>> when looking up oldname, newname shall not be found.
>>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> e.g. on GForth
>> ' DUP SYNONYM DUP DUP ' DUP . .' DUP SYNONYM DUP DUP ' DUP . .
>> redefined dup with DUP  2143110184 4268604  ok
>
> There is no guarantee from SYNONYM that the xt of newname is the same
> as that of oldname.

Sorry (to Alex also), I misunderstood what the underlined part referred 
to. I thought it meant in any code following completion of SYNONYM. I 
must have unconsciously thought it was blindingly obvious that 'newname 
shall not be found' during the execution of SYNONYM so that it need not 
be mentioned.

>
> The requirement you underline is satisfied by the definition above.
> However, the requirement to have both the same interpretation
> semantics and the same compilation semantics as oldname is not (in
> general), as you will see when you try to produce a SYNONYM of S" in
> Gforth with this definition of SYNONYM.  That's because FIND does not
> produce both (at least not in a single invocation of FIND).



-- 
Gerry

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

#37919

Paul Rubin <no.email@nospam.invalid> Re: Importing from wordlists.

> "Elizabeth D. Rather" <erather@forth.com> writes:
>> I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived
>> advantage of going 64-bit beyond generally "keeping up with fashion"?

> 64-bit programs usually run a lot faster.

This is not true for any of the (iForth64) tests that we do. 
Recompiling a program for 64bits generally makes it somewhat 
slower, at least in Forth (in C int is 32bit always).

>                                            Wider data transfers, more
> cpu registers (depending), etc.  

Unfortunately, a 64bit CPU does not have twice the memoryspeed of a
32bit one, That's perfectly logical given the hardware abstraction 
levels before you get at the raw bits. In fact one could hypothesize that
a 64bit CPU in 32bit mode accesses memory much faster than in 64bit
mode (at least with the same Forth program).

More CPU registers is only true at the programmer level because of register
renaming. It just makes it easier to write a program, it will not be faster
(again, unless it really needs 64bit data).

There is a problem with new floating-point hardware though: in 32bit mode
it is not possible to load wide registers fast enough (some C compilers 
load fp registers from the GP set), and I doubt that much hardware 
development effort is going in the direction of fixing this.

>                                  Plus the much larger address space,
> which some memory hungry programs actually use.

Ah, here we have it. One thing is for sure: programs will NOT become less
memory hungry. Standard PC's and even phones already now have far more 
memory, let alone diskspace, than can be addressed by 32 bits. 

Therefore it is not dificult to predict that any new exciting programs 
(we want to write these in Forth, surely) will be 64bit. Once that 
happens, it will become more difficult to find 32 bit-compatible DLLs, 
and users will complain about their compiler only witing 32bit DLLs. 

I predict that Apple will soon come out with a 64bit-only platform, 
and o boy, how old everybody else will look :-)

Seriously, the longer the Forth vendors wait with a 64-bit release the 
more difficult the inevitable port will be. It takes a few years to get
all the bugs and gotcha's out. iForth is 64bit for many years already
and we are now at the near 0 bugs level. We dropped 32bits support 
officially for the next release (too much support and test headaches).

-marcel

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

#37930

mhx@iae.nl (Marcel Hendrix) writes:
>Seriously, the longer the Forth vendors wait with a 64-bit release the 
>more difficult the inevitable port will be. It takes a few years to get
>all the bugs and gotcha's out.

I found the transition pretty easy for Gforth.  Just to check that the
long time since the port did not fog my memory, I checked the commit
messages (around
<http://git.savannah.gnu.org/cgit/gforth.git/log/?ofs=3250>) and found
very few that relate to the 64-bit or Alpha port.  So yes, few changes
were needed.

- 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 2014: http://www.euroforth.org/ef14/

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

#37934

In article <2015Apr4.162016@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>mhx@iae.nl (Marcel Hendrix) writes:
>>Seriously, the longer the Forth vendors wait with a 64-bit release the
>>more difficult the inevitable port will be. It takes a few years to get
>>all the bugs and gotcha's out.
>
>I found the transition pretty easy for Gforth.  Just to check that the
>long time since the port did not fog my memory, I checked the commit
>messages (around
><http://git.savannah.gnu.org/cgit/gforth.git/log/?ofs=3250>) and found
>very few that relate to the 64-bit or Alpha port.  So yes, few changes
>were needed.

Same here with ciforth. I started 2008 feb 23. The version marked
BITS64 is 2008 mar 20. 64 bit related updates are few and far (years)
between. Then in 2013 someone made me aware of the existance of 64 bit
system calls. This got rid of some annoyances such as the inability
to print strings that reside in memory above 0x1,000,0000 (4G).
That was the only major change.

I'd say that if I'd start implementing a 64-bit version right now,
with the benefit of wanting to use 64 bit system calls, I'd spend
rather less than more effort. I guess that iForth with its
reliance on a c-server has more trouble than gforth, that at least
benefits from the (in)famous c-portability.

(The Alpha port I've bragged about before. It took less than a
forth night wall-clock-time, documentation and all.)

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

#37938

On Saturday, April 4, 2015 at 7:10:42 PM UTC+2, Albert van der Horst wrote:
> In article <2015Apr4.162016@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> >mhx@iae.nl (Marcel Hendrix) writes:
> >>Seriously, the longer the Forth vendors wait with a 64-bit release the
> >>more difficult the inevitable port will be. It takes a few years to get
> >>all the bugs and gotcha's out.
> >
> >I found the transition pretty easy for Gforth.  Just to check that the
> >long time since the port did not fog my memory, I checked the commit
> >messages (around
> ><http://git.savannah.gnu.org/cgit/gforth.git/log/?ofs=3250>) and found
> >very few that relate to the 64-bit or Alpha port.  So yes, few changes
> >were needed.
> 
> Same here with ciforth. I started 2008 feb 23. The version marked
> BITS64 is 2008 mar 20. 64 bit related updates are few and far (years)
> between. Then in 2013 someone made me aware of the existance of 64 bit
> system calls. This got rid of some annoyances such as the inability
> to print strings that reside in memory above 0x1,000,0000 (4G).
> That was the only major change.
> 
> I'd say that if I'd start implementing a 64-bit version right now,
> with the benefit of wanting to use 64 bit system calls, I'd spend
> rather less than more effort. I guess that iForth with its
> reliance on a c-server has more trouble than gforth, that at least
> benefits from the (in)famous c-portability.
> 
> (The Alpha port I've bragged about before. It took less than a
> forth night wall-clock-time, documentation and all.)
> 
> >- anton

That's great! Let's see... Did you compile Timothy Trussell's 
lessons with it? 
ftp://ftp.taygeta.com/pub/forth/Archive/tutorials/...

On Windows, Linux and OSX please (of course that doesn't
matter, just curious).

-marcel

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web