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

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

Ann: A new version of Win32Forth has been released.

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

Contents

  Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-01-13 04:55 -0800
    Re: Ann: A new version of Win32Forth has been released. Coos Haak <chforth@hccnet.nl> - 2016-01-13 14:26 +0100
      Re: Ann: A new version of Win32Forth has been released. lehs <skydda.barnen@gmail.com> - 2016-01-13 15:02 -0800
        Re: Ann: A new version of Win32Forth has been released. rickman <gnuarm@gmail.com> - 2016-01-13 18:18 -0500
          Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-01-13 15:47 -0800
            Re: Ann: A new version of Win32Forth has been released. hughaguilar96@gmail.com - 2016-01-13 18:48 -0800
              Re: Ann: A new version of Win32Forth has been released. "WJ" <w_a_x_man@yahoo.com> - 2016-01-14 03:07 +0000
            Re: Ann: A new version of Win32Forth has been released. Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-14 04:28 +0100
              Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-01-26 08:57 -0800
                Re: Ann: A new version of Win32Forth has been released. november.nihal@gmail.com - 2016-01-27 10:13 -0800
                  Re: Ann: A new version of Win32Forth has been released. Mark Wills <markwills1970@gmail.com> - 2016-01-28 00:28 -0800
                    Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-01-28 03:50 -0800
          Re: Ann: A new version of Win32Forth has been released. Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-14 04:17 +0100
    Re: A new version of Win32Forth has been released. "HAA" <someone@microsoft.com> - 2016-01-14 09:29 +1100
    Re: Ann: A new version of Win32Forth has been released. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-02-01 06:05 +0000
      Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-02-01 04:03 -0800
        Re: Ann: A new version of Win32Forth has been released. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-02-01 13:41 +0000
          Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-02-01 07:10 -0800
        Re: Ann: A new version of Win32Forth has been released. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-01 15:01 +0000
          Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-02-01 07:18 -0800
            Re: Ann: A new version of Win32Forth has been released. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-02-01 19:59 +0000
              Re: Ann: A new version of Win32Forth has been released. Coos Haak <chforth@hccnet.nl> - 2016-02-01 23:13 +0100
                Re: Ann: A new version of Win32Forth has been released. Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-02 02:09 -0500
                  Re: Ann: A new version of Win32Forth has been released. Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-02-02 03:55 -0800
                    Re: Ann: A new version of Win32Forth has been released. Coos Haak <chforth@hccnet.nl> - 2016-02-02 14:13 +0100
                      Re: Ann: A new version of Win32Forth has been released. Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-02-02 06:13 -0800
                        Re: Ann: A new version of Win32Forth has been released. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-03 12:00 +0000
                          Re: Ann: A new version of Win32Forth has been released. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-03 12:11 +0000
                          Re: Ann: A new version of Win32Forth has been released. Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-02-03 07:27 -0800
                            Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-02-04 01:00 -0800
                    Re: Ann: A new version of Win32Forth has been released. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-02 14:37 +0000
                      Re: Ann: A new version of Win32Forth has been released. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-02 15:56 +0000
                        Re: Ann: A new version of Win32Forth has been released. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-03 12:02 +0000
                      Re: Ann: A new version of Win32Forth has been released. Julian Fondren <julian.fondren@gmail.com> - 2016-02-02 08:28 -0800
                  Re: Ann: A new version of Win32Forth has been released. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-02 12:39 +0000
                Re: Ann: A new version of Win32Forth has been released. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-02 16:52 +0000
                  Re: Ann: A new version of Win32Forth has been released. Chris Curl <ccurl609@gmail.com> - 2016-02-02 14:11 -0800
                    Re: Ann: A new version of Win32Forth has been released. Coos Haak <chforth@hccnet.nl> - 2016-02-03 01:50 +0100
                      Re: Ann: A new version of Win32Forth has been released. Chris Curl <ccurl609@gmail.com> - 2016-02-03 05:56 -0800
    Re: Ann: A new version of Win32Forth has been released. pandoraefretum@googlemail.com - 2016-02-10 13:38 -0800
      Re: Ann: A new version of Win32Forth has been released. josv@planet.nl - 2016-02-11 06:53 -0800

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

#45238

On 01/02/2016 15:18, josv@planet.nl wrote:
> Indeed, When i loaded core.fr into the IDE and saved it, it ran without problems.
>

>> Input source handling can be tricky. If you copied the test from a
>> unix system without converting it to a MS-DOS text file, tests
>> may fail.
>> --
>> 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
>

Yes ensuring end of line is CRLF makes it run OK. Sorry I didn't spot 
that. I use Windows line endings and don't know how just LF's crept in. 
Still other systems don't seem to worry about it.

Thanks Albert for pointing that out.

-- 
Gerry

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

#45239

Op Mon, 1 Feb 2016 19:59:16 +0000 schreef Gerry Jackson:

> On 01/02/2016 15:18, josv@planet.nl wrote:
>> Indeed, When i loaded core.fr into the IDE and saved it, it ran without problems.
>>
> 
>>> Input source handling can be tricky. If you copied the test from a
>>> unix system without converting it to a MS-DOS text file, tests
>>> may fail.
>>> --
>>> 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
>>
> 
> Yes ensuring end of line is CRLF makes it run OK. Sorry I didn't spot 
> that. I use Windows line endings and don't know how just LF's crept in. 
> Still other systems don't seem to worry about it.
> 
> Thanks Albert for pointing that out.

Scan each character in the buffer
  No more characters -> done.
  If LF -> Unix
  If CR
    Followed by LF -> DOS
    Else -> old Mac
Repeat.

This way I read all three sorts of files for a lot of years now.

groet Coos

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

#45241

On Mon, 1 Feb 2016 23:13:49 +0100
Coos Haak <chforth@hccnet.nl> wrote:

> Op Mon, 1 Feb 2016 19:59:16 +0000 schreef Gerry Jackson:
> > On 01/02/2016 15:18, josv@planet.nl wrote:

> >> Indeed, When i loaded core.fr into the IDE and saved it, it ran
> >> without problems. 
> >   
> >>> Input source handling can be tricky. If you copied the test from a
> >>> unix system without converting it to a MS-DOS text file, tests
> >>> may fail.
> >>  
> > 
> > Yes ensuring end of line is CRLF makes it run OK. Sorry I didn't
> > spot that. I use Windows line endings and don't know how just LF's
> > crept in. Still other systems don't seem to worry about it.
> > 
> > Thanks Albert for pointing that out.  
> 
> Scan each character in the buffer
>   No more characters -> done.
>   If LF -> Unix
>   If CR
>     Followed by LF -> DOS
>     Else -> old Mac
> Repeat.
> 
> This way I read all three sorts of files for a lot of years now.
> 

Do you guys really need to handle source code from the old Mac's?

If not, discard any CR's and only watch for LF's.  That will handle
any Linux and Windows text or Forth code.


Rod Pemberton

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

#45245

> > Scan each character in the buffer
> >   No more characters -> done.
> >   If LF -> Unix
> >   If CR
> >     Followed by LF -> DOS
> >     Else -> old Mac
> > Repeat.
> > 
> > This way I read all three sorts of files for a lot of years now.
> > 
> 
> Do you guys really need to handle source code from the old Mac's?
> 
> If not, discard any CR's and only watch for LF's.  That will handle
> any Linux and Windows text or Forth code.
> 
> 
> Rod Pemberton

I usually use another solution:
Consider any of CR or LF to be the line end marker, and process the line.
Empty lines are trivial to deal with (when a sequence of CR/LF appear).
This way you can deal with really any combination of CR and LF , even the
reverse pair of LF,CR... :)

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

#45247

Op Tue, 2 Feb 2016 03:55:52 -0800 (PST) schreef Raimond Dragomir:

>>> Scan each character in the buffer
>>>   No more characters -> done.
>>>   If LF -> Unix
>>>   If CR
>>>     Followed by LF -> DOS
>>>     Else -> old Mac
>>> Repeat.
>>> 
>>> This way I read all three sorts of files for a lot of years now.
>>> 
>> 
>> Do you guys really need to handle source code from the old Mac's?
>> 
>> If not, discard any CR's and only watch for LF's.  That will handle
>> any Linux and Windows text or Forth code.
>> 
>> 
>> Rod Pemberton
> 
> I usually use another solution:
> Consider any of CR or LF to be the line end marker, and process the line.
> Empty lines are trivial to deal with (when a sequence of CR/LF appear).
> This way you can deal with really any combination of CR and LF , even the
> reverse pair of LF,CR... :)

You still have to scan for a CR or LF
optionally followed or not by a CR or LF.
I see no real difference.

groet Coos

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

#45248

> >>> Scan each character in the buffer
> >>>   No more characters -> done.
> >>>   If LF -> Unix
> >>>   If CR
> >>>     Followed by LF -> DOS
> >>>     Else -> old Mac
> >>> Repeat.
> >>> 
> >>> This way I read all three sorts of files for a lot of years now.
> >>> 
> >> 
> >> Do you guys really need to handle source code from the old Mac's?
> >> 
> >> If not, discard any CR's and only watch for LF's.  That will handle
> >> any Linux and Windows text or Forth code.
> >> 
> >> 
> >> Rod Pemberton
> > 
> > I usually use another solution:
> > Consider any of CR or LF to be the line end marker, and process the line.
> > Empty lines are trivial to deal with (when a sequence of CR/LF appear).
> > This way you can deal with really any combination of CR and LF , even the
> > reverse pair of LF,CR... :)
> 
> You still have to scan for a CR or LF
> optionally followed or not by a CR or LF.
> I see no real difference.
> 
> groet Coos

Probably it's the same complexity although it looks simpler to me:
Here's a pseudo-forth :)
begin
  Get next char
  If CR or LF
    if not empty buffer
      Process the buffer
    then
  else
    put it in the buffer
  then
again

put_it_in_the_buffer usually ignores other control chars and transforms
a TAB in a space.

Anyway, the idea is that dealing with diffrent line termination is a simple
thing, and it's a pitty that win32forth cannot do that (even if it's a
windows only program).

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

#45266

Raimond Dragomir <raimond.dragomir@gmail.com> writes:

>> >>> Scan each character in the buffer
>> >>>   No more characters -> done.
>> >>>   If LF -> Unix
>> >>>   If CR
>> >>>     Followed by LF -> DOS
>> >>>     Else -> old Mac
>> >>> Repeat.
>> >>>
>> >>> This way I read all three sorts of files for a lot of years now.
>> >>>
>> >>
>> >> Do you guys really need to handle source code from the old Mac's?
>> >>
>> >> If not, discard any CR's and only watch for LF's.  That will handle
>> >> any Linux and Windows text or Forth code.
>> >>
>> >>
>> >> Rod Pemberton
>> >
>> > I usually use another solution:
>> > Consider any of CR or LF to be the line end marker, and process the line.
>> > Empty lines are trivial to deal with (when a sequence of CR/LF appear).
>> > This way you can deal with really any combination of CR and LF , even the
>> > reverse pair of LF,CR... :)
>>
>> You still have to scan for a CR or LF
>> optionally followed or not by a CR or LF.
>> I see no real difference.
>>
>> groet Coos

>Probably it's the same complexity although it looks simpler to me:
>Here's a pseudo-forth :)
>begin
>  Get next char
>  If CR or LF
>    if not empty buffer
>      Process the buffer
>    then
>  else
>    put it in the buffer
>  then
>again

>put_it_in_the_buffer usually ignores other control chars and transforms
>a TAB in a space.

>Anyway, the idea is that dealing with diffrent line termination is a simple
>thing, and it's a pitty that win32forth cannot do that (even if it's a
>windows only program).

Really, if you do PARSE NAME and WORD you're dealing in text files.
Any relation with non-printing characters is not defined.
Only BL WORD relates parsing with a non-printing character. It
is an exception and the iso94 standard prescribes in detail
what should happen.
I may have `` : \ ^J PARSE 2DROP ; '' in ciforth but that is only the
entitlement to carnal of the implementor.

So no. Win32Forth must be able to deal with MS text files.
Any expectations you may have for imported non-converted text files,
may or may not be met. The same for linux gforth w.r.t.
non-converted text files imported  in linux.
You do something strange, you take responsability.
If Win32Forth tries to meet "reasonable expectation", "graceful degradation"
that doesn't change that fact.

The feeling that "if only they ..., unpleasant surprise could've been
prevented", is wrong.
Really, maybe the best thing for Win32Forth would be to bluntly refuse to
INCLUDED any files that have improper line endings.
Any other change in policy could break existing programs, mysteriously
and without a clue.

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]

#45269

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>So no. Win32Forth must be able to deal with MS text files.
>Any expectations you may have for imported non-converted text files,
>may or may not be met.

Sure, that's a minimal requirement, but, in the current world of
exchange of files between systems, not relly enough.

>The same for linux gforth w.r.t.
>non-converted text files imported  in linux.

Gforth accepts LF, CR, and CRLF as line endings (even different ones
in the same file); we use to rely on the text-file conversion of the C
library, but found that this caused problems, so we changed to the
all-accepting approach, and that change was successful.  It also
corresponds to Postel's law (and we satisfy the other half of Postel's
law by outputting newlines as LF in Unix, and as CRLF in Windows).

>Really, maybe the best thing for Win32Forth would be to bluntly refuse to
>INCLUDED any files that have improper line endings.

Which would be more work and less helpful than the approach we have
taken in Gforth.

>Any other change in policy could break existing programs, mysteriously
>and without a clue.

Evidence for this claim?

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

#45276

...
> 
> The feeling that "if only they ..., unpleasant surprise could've been
> prevented", is wrong.
> Really, maybe the best thing for Win32Forth would be to bluntly refuse to
> INCLUDED any files that have improper line endings.
> Any other change in policy could break existing programs, mysteriously
> and without a clue.
> 
> 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

You spoke like a lawyer...
These days accepting any CR/LF combination (well, at least Unix/Linux LF
and windows CR/LF) should be a norm. That's the world we live in.
I'm not sure about single CRs, but I do know some simple ascii protocols
that use the single CR termination... so it may be usefull too.

Take a simple example: Windows supports forward slash for directory
separator along with their backslash for quite some time... I know that
because I'm using it all the time :)

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

#45293

It sounds very atractive to me to change Win32Forth.
Jos

On 3 februari 2016 16:27:21 UTC+1 schreef Raimond Dragomir:
> ...
> > 
> > The feeling that "if only they ..., unpleasant surprise could've been
> > prevented", is wrong.
> > Really, maybe the best thing for Win32Forth would be to bluntly refuse to
> > INCLUDED any files that have improper line endings.
> > Any other change in policy could break existing programs, mysteriously
> > and without a clue.
> > 
> > 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
> 
> You spoke like a lawyer...
> These days accepting any CR/LF combination (well, at least Unix/Linux LF
> and windows CR/LF) should be a norm. That's the world we live in.
> I'm not sure about single CRs, but I do know some simple ascii protocols
> that use the single CR termination... so it may be usefull too.
> 
> Take a simple example: Windows supports forward slash for directory
> separator along with their backslash for quite some time... I know that
> because I'm using it all the time :)

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

#45249

Raimond Dragomir <raimond.dragomir@gmail.com> writes:

>> > Scan each character in the buffer
>> >   No more characters -> done.
>> >   If LF -> Unix
>> >   If CR
>> >     Followed by LF -> DOS
>> >     Else -> old Mac
>> > Repeat.
>> >
>> > This way I read all three sorts of files for a lot of years now.
>> >
>>
>> Do you guys really need to handle source code from the old Mac's?
>>
>> If not, discard any CR's and only watch for LF's.  That will handle
>> any Linux and Windows text or Forth code.
>>
>>
>> Rod Pemberton

>I usually use another solution:
>Consider any of CR or LF to be the line end marker, and process the line.
>Empty lines are trivial to deal with (when a sequence of CR/LF appear).
>This way you can deal with really any combination of CR and LF , even the
>reverse pair of LF,CR... :)

The assumption that empty lines (between CR and LF) don't matter
doesn't work for metacompiling noforth.
There is a part in noforth where the expectation is that there are two
words on a line, and no empty lines.

Not that I think that is a good idea. I have given the advice to use
REFILL, in the hope to enforce line by line compilation.

The expectation is that each REFILL fetches a new line, and it is best
if that expectation works even if one uses INCLUDED on files that are
not text files on the system the Forth works on.
The noforth metacompilation has convinced me to add a REFILL to ciforth
that honours the line by line expectation.
Not that I think it is a good idea to have non-proper text files as
source.

There is nothing easy or trivial about this matter, especially not
where it tends to stay under the radar and results in time consuming
bug-hunts.
gforth did not fulfill expectations valid for a Winforth program,
which resulted in changes in the noforth metacompilation source.
In its turn those changes were detrimental to ciforth.
Then there is the Heisenbug effect. The problem may mysteriously
disappear after inspecting source files by an endemic editor.

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]

#45250

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>gforth did not fulfill expectations valid for a Winforth program,
>which resulted in changes in the noforth metacompilation source.

Which expectations did it not fulfill?

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

#45267

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>gforth did not fulfill expectations valid for a Winforth program,
>>which resulted in changes in the noforth metacompilation source.

>Which expectations did it not fulfill?

The expectation that the metacompilation would run the same.
It is a waste of time to go deeper in this, because the non-portability
is on the side of the programmer not in gforth.


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

#45251

On Tuesday, February 2, 2016 at 1:09:13 AM UTC-6, Rod Pemberton wrote:
> Do you guys really need to handle source code from the old Mac's?
> 
> If not, discard any CR's and only watch for LF's.  That will handle
> any Linux and Windows text or Forth code.

Rod has the right idea.

Text files are are human-readable, so they tend to be
human-editable.  Humans make mistakes.  Especially when they
can't even see the mistakes.

I use vim though so I very frequently see WordPress
configurations that are all unix-format except for three added
lines with trailing ^M bytes.



On Tuesday, February 2, 2016 at 8:37:48 AM UTC-6, Albert van der Horst wrote:
> The noforth metacompilation has convinced me to add a REFILL to ciforth
> that honours the line by line expectation.

With ISN'T UNIQUE warnings stripped:

  $ cat line.fs 
  : |  -1 parse + 1- c@ . cr bye ;
  
  $ sf include line.fs '| hi'
  105 
  
  $ gforth line.fs -e '| hi'
  105 
  
  $ lina -f include line.fs '| hi'
  32 
  
  $ lina -f include line.fs '"| hi" evaluate'
  105
  
  $ lina -t line.fs  # interactively:
  | hi
  10


-- Julian

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

#45246

Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes:
[Treat LF, CR, and CRLF as newlines on input]
>Do you guys really need to handle source code from the old Mac's?

Who knows?  The code for that has been working forever in Gforth, and
is not particularly complicated, so we are not going to change it.

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

#45252

Coos Haak <chforth@hccnet.nl> writes:
>Scan each character in the buffer
>  No more characters -> done.
>  If LF -> Unix
>  If CR
>    Followed by LF -> DOS
>    Else -> old Mac
>Repeat.

Almost, but not quite like Gforth.  E.g., READ-LINE is more along the
lines of

check other boundary conditions
Get a character
if LF -> end-of-line reached
if CR ->
  get next character
  if LF -> end-of-line reached
  else -> unget the character, end of line reached
otherwise -> ordinary character, store in buffer

I.e., Unix/DOS/old Mac does not matter, it's all the same to
READ-LINE.

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

#45257

Forth ANSI standard ... 3.4.1.1 Delimiters

"If the delimiter is the space character, hex 20 (BL), control characters may be treated as delimiters."

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

#45258

Op Tue, 2 Feb 2016 14:11:04 -0800 (PST) schreef Chris Curl:

> Forth ANSI standard ... 3.4.1.1 Delimiters
> 
> "If the delimiter is the space character, hex 20 (BL), control characters may be treated as delimiters."

Of course, but this discussion is about line-termination characters.
11.6.1.2090 READ-LINE.

groet Coos

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

#45272

On Tuesday, February 2, 2016 at 7:50:20 PM UTC-5, Coos Haak wrote:
> Op Tue, 2 Feb 2016 14:11:04 -0800 (PST) schreef Chris Curl:
> 
> > Forth ANSI standard ... 3.4.1.1 Delimiters
> > 
> > "If the delimiter is the space character, hex 20 (BL), control characters may be treated as delimiters."
> 
> Of course, but this discussion is about line-termination characters.
> 11.6.1.2090 READ-LINE.
> 
> groet Coos
heh, yeah ... i was looking at an older forth ansi standard ...

i guess i should at least get to the 20th century ... :)

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

#45428

On Wednesday, 13 January 2016 12:55:52 UTC, jo...@planet.nl  wrote:
> Win32Forth version 6.15.04 has been released.
> On my PC the added Forth-installer took less then 2 minutes to decompress and install it.
> You can download the new version from:  http://sourceforge.net/projects/win32forth/files
> 
> Jos

Hi Jos,

Win32For 6.15.04 fails to install on my win 8.1

Current directory is: D:\Forth\Win32Forth\Install
Program path is:      C:\Win32For\Win32Forth\WIN32FOR.EXE
Forth path is:        C:\Win32For\Win32Forth\
Application path is:  not set

System Editor is:     Win32Forth IDE 


Current directory: C:\Win32For\Win32Forth\apps\Setup
Loading Extended C like structures... 
Loading simple C like structures..
 Members of a structure are not in a separate vocabulary.

2 Error: COUNINITIALIZE FAILED.  empty  

[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