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

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

DurexForth v1.5.0

Started byJohan Kotlinski <kotlinski@gmail.com>
First post2016-01-04 15:08 -0800
Last post2016-01-07 03:14 -0500
Articles 6 on this page of 46 — 16 participants

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

Contents

  DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-04 15:08 -0800
    Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-04 20:54 -0800
      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 00:48 -0800
        Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 04:40 -0500
          Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 02:53 -0800
            Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 09:19 -0500
              Re: DurexForth v1.5.0 Chris Curl <ccurl609@gmail.com> - 2016-01-05 08:44 -0800
                Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 11:53 -0500
                  Re: DurexForth v1.5.0 Chris Curl <ccurl609@gmail.com> - 2016-01-05 10:28 -0800
                    Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 14:12 -0500
                      Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 11:16 -0800
                        Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 14:58 -0500
                          Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 12:03 -0800
                            Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 15:10 -0500
                              Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 12:36 -0800
                                Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 16:34 -0500
                      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 13:42 -0800
                        Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-05 16:40 -0800
                          Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 18:13 -0800
                            Re: DurexForth v1.5.0 "Elizabeth D. Rather" <erather@forth.com> - 2016-01-05 16:27 -1000
                            Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 18:59 -0800
                              Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-05 22:47 -0800
                                Re: DurexForth v1.5.0 "Elizabeth D. Rather" <erather@forth.com> - 2016-01-05 21:37 -1000
                                  Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-06 00:14 -0800
                                    Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 10:32 +0200
                                      Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-06 00:42 -0800
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 11:02 +0200
                                          Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 01:51 -0800
                                            Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 12:02 +0200
                                      Re: DurexForth v1.5.0 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-06 10:46 +0000
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 12:49 +0200
                                        Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 03:12 -0800
                                          Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-06 18:21 +0000
                                            Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-06 22:57 -0800
                                              Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-07 08:47 +0000
                                      Re: DurexForth v1.5.0 Coos Haak <chforth@hccnet.nl> - 2016-01-06 13:39 +0100
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 14:45 +0200
                                  Re: DurexForth v1.5.0 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-06 12:48 +0000
                                  Re: DurexForth v1.5.0 Syd Rumpo <usenet@nononono.co.uk> - 2016-01-07 11:09 +0000
                                Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-06 22:57 -0800
          Re: DurexForth v1.5.0 no.top.post@gmail.com - 2016-01-14 12:45 +0000
    Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-05 10:37 +0000
      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 03:08 -0800
    Re: DurexForth v1.5.0 Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-01-06 12:22 +0100
      Re: DurexForth v1.5.0 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-06 13:08 +0000
    Re: DurexForth v1.5.0 Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-07 03:14 -0500

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

#44867

Fromno.top.post@gmail.com
Date2016-01-14 12:45 +0000
Message-ID<n7859u$eij$1@dont-email.me>
In reply to#44576
In article <n6g2se$vlu$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: 

> On 1/5/2016 3:48 AM, Johan Kotlinski wrote:
> > On Tuesday, January 5, 2016 at 5:55:00 AM UTC+1, hughag...@gmail.com
> > wrote:
> >> This seems reasonable --- so long as a char is 8-bit, there is no
> >> reason why it has to be any particular character coding --- we have
> >> the words SPACE and CR that abstractify blanks and
> >> carriage-controls, so they don't have to be any particular code.
>   --- snip --
> If the C64 does not use ASCII it would have a hard time exchanging text 
> files with the rest of the computer world, no?  I can't imagine why it 
> would be useful to not use the 128 ASCII codes.  One time it would be an 
> issue is when converting from ASCII-hex to integers.  It is not uncommon 
> to hard code the conversion constants as numbers rather than use the 
> ASCII characters.  This would be broken on the C64 I expect.
> 
That's absurd. If you/it doesn't need to communicate with "the rest of the
computer world", what are you doing here?
Have you heard about standardisation.
Do you make you own pencils, and nuts and bolts.

Related to this: there's a new fad [probably M$ originated] where
single-quotes are replaced by multiple bytes [one is HEXc3].
When I complain on USEnet, the kiddies say I'm trolling.

When the crap goes through my TTS, it say " see aye en tea",
instead of "can't".

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

#44577

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2016-01-05 10:37 +0000
Message-ID<2016Jan5.113741@mips.complang.tuwien.ac.at>
In reply to#44560
Johan Kotlinski <kotlinski@gmail.com> writes:
>Unfortunately there is one part of the standard that seems really like a ba=
>d idea for me to follow, so I would like to pass in some criticism here. It=
> is the enforcing of ASCII that sits bad, since the C64 naturally uses PETS=
>CII.

Given that PETSCII is mostly ASCII, especially in text mode (assuming
you are doing a case insensitive Forth, like most Forth systems
around), I would just go with PETSCII, and would not expect many
problems from it.  One exception is the absence of the characters {,
|, }, so you will have to choose some other characters (maybe those
that are at the place of {,|,} (123-125) if you want to implement the
new Forth-2012 locals syntax.

>It bothers me why the Forth standard, which is so flexible in many oth=
>er areas, should be so specific about this? The C standard does well withou=
>t this requirement.

The C standard in its lack of definition is not a good standard to
follow.  Standardizing ASCII allows to write such things as DIGIT
efficiently (and that will work just as well for PETSCII).  I don't
think that there are many programs where the differences between
PETSCII and ASCII make a difference.  Given that ASCII was the Forth
standard character set at least since 1994, when the Commodore
machines were more common than today, and IIRC nobody reported that as
a problem before 2016, I expect that it is not a big issue.

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

#44579

FromJohan Kotlinski <kotlinski@gmail.com>
Date2016-01-05 03:08 -0800
Message-ID<96186514-079f-404f-b3d9-a05f49ea0675@googlegroups.com>
In reply to#44577
On Tuesday, January 5, 2016 at 11:51:11 AM UTC+1, Anton Ertl wrote:
> PETSCII and ASCII make a difference.  Given that ASCII was the Forth
> standard character set at least since 1994, when the Commodore
> machines were more common than today, and IIRC nobody reported that as
> a problem before 2016, I expect that it is not a big issue.

Yes, it is not a big issue, it is a minor annoyance. By the way, I see ASCII was already in Forth-79 and Forth-83 standards, and it was simply ignored by the C64 developers of that time. Seems like a good way to deal with it.

Cheers
Johan

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

#44622

FromMatthias Koch <matthias.koch@hot.uni-hannover.de>
Date2016-01-06 12:22 +0100
Message-ID<n6it7l$el2$1@newsserver.rrzn.uni-hannover.de>
In reply to#44560
Hi Johan,

never mind, just use what fits best. It is generally a good idea 
to follow ANS defaults as long as you are free to choose, but if
there are good technical reasons or special features you really
wish to have, just do it and write a line about that in README.

Sometimes ANS cannot implemented with given circumstances at all,
the required multiple does> is not suitable for direct compilation
into Flash for example, and the ANS standard is quite calm about
how to actually compare two UTF-8 strings, which would involve
a lot of work when done as specified by Unicode docs.

See https://en.wikipedia.org/wiki/Unicode_equivalence

I liked the Commodore 64 a lot ! Go for PETSCII, as everything
around will expect it. It will be much less overhead to just
convert files when transfering from and to other systems.

Perhaps a conversion table for both directions included could
be helpful as translator if you have serial communication with
the "outer world" available.

Have fun,
Matthias  (mecrisp.sourceforge.net)

> Hi all,
> sorry to disturb, I have been lurking here some years while developing my own toy Forth. It's a subroutine-threaded Forth for the C64.
> 
> A few months ago I started working on Forth 2012 standard compliance, and now released a version that passes 99% of the core standard tests. If you are interested, you can try it out here: https://github.com/jkotlinski/durexforth/releases/tag/v1.5.0
> 
> Overall, the Forth 2012 web site and tests have been a great resource. I learned a lot and now DurexForth is also more enjoyable to use.
> 
> Unfortunately there is one part of the standard that seems really like a bad idea for me to follow, so I would like to pass in some criticism here. It is the enforcing of ASCII that sits bad, since the C64 naturally uses PETSCII. It bothers me why the Forth standard, which is so flexible in many other areas, should be so specific about this? The C standard does well without this requirement.
> 
> Regards
> Johan

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

#44627

FromAlbert van der Horst <albert@spenarnc.xs4all.nl>
Date2016-01-06 13:08 +0000
Message-ID<568d11e5$0$23722$e4fe514c@news.xs4all.nl>
In reply to#44622
Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:


>Hi Johan,

>never mind, just use what fits best. It is generally a good idea
>to follow ANS defaults as long as you are free to choose, but if
>there are good technical reasons or special features you really
>wish to have, just do it and write a line about that in README.

>Sometimes ANS cannot implemented with given circumstances at all,
>the required multiple does> is not suitable for direct compilation
>into Flash for example, and the ANS standard is quite calm about
>how to actually compare two UTF-8 strings, which would involve
>a lot of work when done as specified by Unicode docs.

>See https://en.wikipedia.org/wiki/Unicode_equivalence

>I liked the Commodore 64 a lot ! Go for PETSCII, as everything
>around will expect it. It will be much less overhead to just
>convert files when transfering from and to other systems.

>Perhaps a conversion table for both directions included could
>be helpful as translator if you have serial communication with
>the "outer world" available.

>Have fun,
>Matthias  (mecrisp.sourceforge.net)

That makes a strict avoidance of CASE-SENSITIVE so attractive.
Don't fool around with the data that is given by the user.
(Same for filenames, if filenames are handled this way, like
Unices do, you can handle an arabic file name, even if the character
sequences looks funny and nothing like arabic.)
Names are strings of bytes that can simple be looked up.
E.g. lina has no problem with making a distinction between
a word that consists of 3 zero characters and 4. (and WORDS+ could
be made to print them as \000\000\000  \000\000\000\000 )
How the user gets them typed, or displayed, is between him and
his terminal.
I actually use this is in a communication program. I detect
function keys, and then the code of it is looked up in
the dictionary, escapes and all.

This example make a single board computer print the stack when
function key 8 is pressed on a regular linux terminal

: ~[19~ ".S" send-one-line ;   <ESC> LATEST >NFA @ CELL+ C!  \ F8

or end the session with F4

: ~OS close-connection BYE ;   <ESC> LATEST >NFA @ CELL+ C!  \ F4

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]

#44654

FromRod Pemberton <NoHaveNotOne@bcczxcfre.cmm>
Date2016-01-07 03:14 -0500
Message-ID<20160107031453.7bc31f5d@_>
In reply to#44560
On Mon, 4 Jan 2016 15:08:59 -0800 (PST)
Johan Kotlinski <kotlinski@gmail.com> wrote:

> Unfortunately there is one part of the standard that seems really
> like a bad idea for me to follow, so I would like to pass in some
> criticism here. It is the enforcing of ASCII that sits bad, since the
> C64 naturally uses PETSCII. It bothers me why the Forth standard,
> which is so flexible in many other areas, should be so specific about
> this? The C standard does well without this requirement.

Well, I think the best solution is to just use PETSCII
and translate it, if you need code portability.

However, if that's unreasonable, you could reprogram
the graphics character set on the C64.  That's how all
those old C64 "graphics" games worked, e.g., Ultima.
So, you could load a different set of character images,
i.e, images for ASCII and so display ASCII.  A simple
256 byte lookup table would translate keyboard input.


Rod Pemberton

[toc] | [prev] | [standalone]

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

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

csiph-web