-eForth ?
Michael L Gassanenko
"eForth creator Bill Muench's site"
http://homepage.mac.com/forth/
in not there anymore.
Is there an official eForth distribution in the net?
There used to be many.
---
Particular question
For me it is important now that this Forth is written in high-level Forth.
( I found some pieces of eForth on my HDD, but....
Who knows for sure, how #BITS was defined? 15 or 16? )
: UM/MOD ( ud u -- ur uq ) ( 6.1.2370 )( 0xD5 )
2DUP U<
IF NEGATE [ #BITS ] LITERAL
\ ^^^^^^
BEGIN DUP
WHILE >R >R DUP UM+ >R >R DUP UM+ R> +
DUP R> R@ SWAP >R UM+ R> OR
IF >R DROP D# 1 + R> ELSE DROP THEN R> R> D# 1 -
REPEAT 2DROP SWAP EXIT
THEN DROP 2DROP D# -1 DUP ;
: UM/MOD ( udl udh un -- ur uq )
2DUP U<
IF NEGATE 15
\ ^^^
FOR >R DUP UM+ >R >R DUP UM+ R> + DUP
R> R@ SWAP >R UM+ R> OR
IF >R DROP 1 + R> ELSE DROP THEN R>
ENDFOR DROP SWAP EXIT
THEN DROP 2DROP -1 DUP ;
Or maybe n FOR ... ENDFOR executed n+1 times?
Michael L Gassanenko
>
> General question
>
> "eForth creator Bill Muench's site"
> http://homepage.mac.com/forth/
> in not there anymore.
>
> Is there an official eForth distribution in the net?
> There used to be many.
>
> ---
>
> Particular question
>
> For me it is important now that this Forth is written in high-level Forth.
I should have formulated this as:
if eForth is lost, is there another such Forth written in Forth?
>
> ( I found some pieces of eForth on my HDD, but....
> Who knows for sure, how #BITS was defined? 15 or 16? )
[..]
>
> Or maybe n FOR ... ENDFOR executed n+1 times?
The latter is true; RTFM worked.
hp
> Michael L Gassanenko wrote:
>>
>> General question
>>
>> "eForth creator Bill Muench's site"
>> http://homepage.mac.com/forth/
>> in not there anymore.
>>
>> Is there an official eForth distribution in the net?
>> There used to be many.
my implementation(s) are for the 'as' and 'nasm' assemblers but, the
archives include the original sources:
http://www.lxhp.in-berlin.de/e4a.src.tar.bz2
and
http://www.lxhp.in-berlin.de/eforth.tar.bz2
>>
>> ---
>>
>> Particular question
>>
>> For me it is important now that this Forth is written in high-level
>> Forth.
orig. by B.M. included in the 1st, 'e4a...'
best,
hp
--
>>> hp -at- lxhp -dot- in-berlin -dot- de <<<
linux,asm,forth http://www.lxhp.in-berlin.de
Ron Aaron
> Michael L Gassanenko wrote:
>
>
> my implementation(s) are for the 'as' and 'nasm' assemblers but, the
Where are your implementations found?
dwight elvey
I believe that eForth, by definition, is done in
assembly, not high level.
for...next has been implemented in different ways.
Most like it so that the value of the loop can be used
directly as an index. This typically means that '15 for...next'
would execute 15 times. Still, one can have a pre-decrement
such that something like '16 for... r@ MyArray ...next'
would return 15 to 0 from r@.
I don't know what eForth does.
I think Bill is still around. You might also check with
Dr Ting. He has implemented several versions of eForth.
Dwight
Michael L Gassanenko <m_l...@yahoo.com> wrote in message news:<3F58B0DD...@yahoo.com>...
Jeff Fox
> "eForth creator Bill Muench's site"
> http://homepage.mac.com/forth/
> in not there anymore.
Go to the internet archives wayback machine. That's
what I did. Several version of Bill's site is there.
One can download eForth 5.0, bForth, and his metacompiler.
16-bit and 32-bit variations with slightly more than
changing #BITS and it has the ability to redirect I/O
through DOS files.
> Is there an official eForth distribution in the net?
> There used to be many.
Dr. Ting's eForth academy has many many eForth versions
for a very wide range of targets. Some of those are real
eForth distributions, ANS and with various optional wordsets.
Of course Dr. Ting's versions tend to be one of his stripped
down subsets of Bill's eForth core, coded in MASM and missing
lots of words like VARIABLE or DOES>.
Best Wishes,
Jeff Fox
Jeff Fox
> Hi
> I believe that eForth, by definition, is done in
> assembly, not high level.
No Dwight. That is exactly backwards. I have explained
this at least dozen times in c.l.f but let me try once
again while I am on this visit.
Bill wrote eForth as a portable ANS Forth system while
the standard development was in progress. He wrote
thirty words in assembler (Forth defined assembler) and
the rest in Forth.
Dr. Ting got his permission to use it as a sort of
FIG-Forth for the 1990s. Since Dr. Ting felt that metacompilation
was what had limited the acceptance of Forth on a larger scale
he wanted to distribute a system in MASM format and promote the
idea to encourge other people to port the system and learn
Forth the way folks did when FIG had thousands of members.
So he wrote a modified version of SEE that would output in
a format that was mostly MASM compatible, edited it and
then threw out all but the MASM source for the kernel and
he even stripped that down. Dr. Ting removed words such
as VARIABLE and DOES> and left them, and the vast majority
of eForth as an exercise for the reader to recreate. This
was his philosophy on how to teach Forth and promote it.
At least he also distributed the original Forth source
for those who already knew Forth well enough to prefer it
to the MASM source.
I worked with both systems so I know. I worked with Bill
on testing various versions that he developed for ANS compliance.
Bill did not want to have to explain or support his metacompiler,
he didn't want to have to document it for other people to use
but I found it fairly self-explanatory. When I had questions
he answered them patiently.
Dr. Ting went on to create dozens of versions for new environments
and collects dozens more written by other people, some of them
as complete or even beyond what Bill had published, but the majority
were versions in MASM of only the stripped down sub-set of the
actual eForth kernel.
Despite Dr. Ting's philosophy that starting with almost nothing
was what made it fun he published a number of eForth manuals
and related documents. The eForth Porting Guide, eForth manual,
and eForth and Zen are a few examples. But in all his versions
it was left as an exercise for the reader to implement words
like VARIABLE DOES> DO LOOP etc. etc.
Dozens of people started with Dr. Ting's system and spent
a lot of time to recreate their own (usually very inferior/0
versions of a more complete Forth system to duplicate the
majority of the code that Dr. Ting had thrown out. This
was his idea.
Many people, especially in c.l.f, ranted about what a piece
of crap it was, how it gave people a terrible impression of
Forth etc. When each year some new person would suggest that
a team of programmers be organized to extend eForth into a
full ANS Forth system that included DOES> and DO LOOPs and
even optional ANS Forth wordlists I would say, "In order
to duplicate what Bill did ... years ago?" Then I would
repeat this story one more time...
I have also told this story many times when the subject of
metacompilation would come up. You know how the same
questions get asked over and over year afterv year in a
newsgroup. Most recently it was when someone asked, "Wasn't
metacompilation a quasi-cult?"
I would explain again that I started with Dr. Ting's core,
then added the rest of Bill's code back in. But since it
took MASM 90 minutes to generate a system it was painful.
I asked Bill for a copy of his bForth and metacompiler
and was very pleased that it did the job that took MASM
90 minutes in 30 seconds. Hey my PC was very slow way
back then, 1990.
When I wanted to experiment by comparing various ITC, DTC,
STC, BTC, and native code implementations I found Bill's
metacompiler to be inadequate for that. So I wrote my
own. It was not difficult. Later I made minor changes
to the Forth source so that it could be metacompiled
in an entirely trivial manner with only a few lines of
source code in the metacompiler.
I came to a very different conclusion than Dr. Ting.
If the demonstrated techniques for metacompilation were
so complex that they were what was limiting people's
understanding and acceptance of Forth then instead of
throwing it away make it simple and clear so most
anyone could easily understand it.
In Dr. Ting's approach, and in his documentation, he
calls metacompilation a black-belt level activity and
the last thing in his educational method. I said it
is an easy thing, a simple exercise, not a black-belt
level activity.
Of course in c.l.f eForth was regularly promoted by
newbies who had spent a lot of time to duplicate a
small fraction of Bill's original code (duplicate in
high level functionality, not in clarity or quality)
and many others regularly ranted that it was awful
and a good example of what is wrong with Forth,
those damn low quality PD systems!
Newsgroups being what they are it seems that that
will never change. There will always be people
finding Ting's stripped down subset of the eForth
kernel coded in MASM and who will get their first
impression of Forth from that. And there will
be newbies proposing that a group project be
organized to turn Dr. Ting's education project
back up to what he started with in 1990. And
there will be always be those who will complain
that it is an example of exactly what is wrong
with Forth, those damn PD systems. (that were not
written by the person complaining.)
I eventually realized that my articles about making
metacompilation simple, and comments about the techniques
that Chuck had used to simplify metacompilation in the
last twenty years were of little value to most people.
This was simply because the complexity of metacompilation
is related to the internal complexity of the target
system and most systems were just so complex in their
internals that a metacompiler for them had to be even
more complex. Very few people had any interest in
making it simpler, writing less code, etc. Eventually
a metacompilation standard, as an extension to the
ANS Forth standard was proposed and I concluded that
with the weight of authority behind it that it was
the direction that most people were headed.
Still, I found my experiences with eForth in Forth to
be very educational, particularly with regard to
metacompilation and multi-tasking issues. I know
that there have been other people with positive
educational experiences using or studying eForth
or learning from Dr. Ting's eForth documentation.
Thankfully Bill eventually put the last version of
eForth that he wrote, along his bForth and metacompiler
up on his website. It was there for a long time then
the website went away. Thankfully it is still accessible
using the internet archives.
So all that said, one more time, I hope people will
stop posting that eForth is by definition written
in MASM not Forth.
Best Wishes,
Jeff Fox
cLIeNUX user
>Michael L Gassanenko <m_l...@yahoo.com> wrote in message news:<3F58B0DD...@yahoo.com>...
>
>> "eForth creator Bill Muench's site"
>> http://homepage.mac.com/forth/
>> in not there anymore.
>
>Go to the internet archives wayback machine. That's
My version is based on Rideau's (Fare's) version for Linux. I added
most Linux syscalls as "core" words and a few other tweaks. There's
eforthl.tgz in
ftp://ftp.gwdg.de/linux/clienux/interim/
and eforth is also on the ViralinuxII floppy image, with H3sm, my
3-stacker. And ash, a rustic unix shell. That's a 1-floppy proto-Linux.
Rick Hohensee
Line Noise
f...@ultratechnology.com (Jeff Fox) wrote:
> Thankfully Bill eventually put the last version of
> eForth that he wrote, along his bForth and metacompiler
> up on his website. It was there for a long time then
> the website went away. Thankfully it is still accessible
> using the internet archives.
>
> So all that said, one more time, I hope people will
> stop posting that eForth is by definition written
> in MASM not Forth.
>
> Best Wishes,
> Jeff Fox
So it is -somewhere- in the archives is it?
That is good, how would we find it?
Do you hapen to know the URL for a MacOS version?
A 4th for the mac would be neat, espechaly if it was in 4th!
Anton Ertl
>No Dwight. That is exactly backwards. I have explained
>this at least dozen times in c.l.f but let me try once
>again while I am on this visit.
I have now added the following to the FAQ:
5.13. eForth: Who wrote it, and how do the versions differ?
The original eForth was written by Bill Muench, and was metacompiled.
C. H. Ting produced a version for educational purposes that was
written in MASM, and had many words removed (the user should add them
back in as an exercise). For the long story, read
<4fbeeb5a.03090...@posting.google.com>.
- 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
EuroForth 2003: http://www.micross.co.uk/euroforth2003/Call_for_papers.html
Jeff Fox
> So it is -somewhere- in the archives is it?
> That is good, how would we find it?
goto http://web.archive.org
search for http://homepage.mac.com/Forth
surf and pick the files that you want
> Do you hapen to know the URL for a MacOS version?
No. Bill's DOS version just inputs and outputs thru
a BIOS or DOS routine. It was trivial to add AT-XY
and colors in a DOS window with ANS escape sequence
support. There may be a MAC OS version somewhere but
I am not aware of it.
I believe that Dr. Ting has posted versions of his
eForth for the processors that Apple uses in MACs
so the core code words may be there. However Ting's
versions generally speaking ONLY support serial I/O.
Ting's idea was that you plug in a serial line to
a PC or terminal, hit return, you get an OK back.
This is what made it even simple than FIG-Forth. Just
a small core with nothing but serial I/O makes for a
system that is almost trivial to port. This is different
kind of definition of portability than is used throughout
the ANS Forth effort.
I expect that you want a MAC version with lots of hooks
to the MAC toolbox. I think some other Forth for the MAC
would be more satisfying except perhaps as do it yourself
bootstrap exercise. But interfacing to all the things
built into MAC OS is not a trivial task. But perhaps
one exists that I do not know of.
Best Wishes,
Jeff Fox
Bee
> "eForth creator Bill Muench's site"
> http://homepage.mac.com/forth/
> in not there anymore.
>
> Is there an official eForth distribution in the net?
I am Bill Muench.
I wander, but am not lost.
There is a copy of eForth on this server:
http://www.baymoon.com/~bimu/forth/
When mac.com was no longer free, I never got around to making
the site public again.
an...@a0.complang.tuwien.ac.at (Anton Ertl) wrote:
> I have now added the following to the FAQ:
>
> 5.13. eForth: Who wrote it, and how do the versions differ?
>
> The original eForth was written by Bill Muench, and was metacompiled.
> C. H. Ting produced a version for educational purposes that was
> written in MASM, and had many words removed (the user should add them
> back in as an exercise).
I also wrote the MASM version, to quote my web page:
The name eForth possible came from: educational Forth,
experimental Forth, easy Forth, or the fact that "e" was next
letter in the alphabet of unused Forth system names.
--
Bill Muench
Santa Cruz, California 95065
831-425-8740
jeff+dated+106...@jrpenn.demon.co.uk
> Particular question
>
> For me it is important now that this Forth is written in high-level Forth.
>
> ( I found some pieces of eForth on my HDD, but....
> Who knows for sure, how #BITS was defined? 15 or 16? )
from emata.x86:
16 CONSTANT #BITS ( bits per cell )
I have a copy of the zip distribution from Bill's site if you require it.
regards
jeff
dwight elvey
> Michael L Gassanenko <m_l...@yahoo.com> wrote:
> > "eForth creator Bill Muench's site"
> > http://homepage.mac.com/forth/
> > in not there anymore.
> >
> > Is there an official eForth distribution in the net?
>
> I am Bill Muench.
>
> I wander, but am not lost.
>
> There is a copy of eForth on this server:
>
> http://www.baymoon.com/~bimu/forth/
>
> When mac.com was no longer free, I never got around to making
> the site public again.
>
> an...@a0.complang.tuwien.ac.at (Anton Ertl) wrote:
> > I have now added the following to the FAQ:
> >
> > 5.13. eForth: Who wrote it, and how do the versions differ?
> >
> > The original eForth was written by Bill Muench, and was metacompiled.
> > C. H. Ting produced a version for educational purposes that was
> > written in MASM, and had many words removed (the user should add them
> > back in as an exercise).
>
> I also wrote the MASM version, to quote my web page:
Hi Bill
I thought it was you that had told me that you'd done a MASM version.
I figured Jeff knew better than I did.
My favorite meta compile is with my NC4000 ( 4 MHz xtal ). I used
an XT HD interface and a 5Meg hard drive with it. Using Chucks
cmforth, I can meta compile a new image in about 15 seconds.
Take Care
Dwight
Line Noise
> l...@telus.net (Line Noise) wrote in message
news:<ln-050903...@207.6.28.219>...
>
> > So it is -somewhere- in the archives is it?
> > That is good, how would we find it?
>
> goto http://web.archive.org
> search for http://homepage.mac.com/Forth
> surf and pick the files that you want
>
Thanks lots I will surf on over!
> > Do you hapen to know the URL for a MacOS version?
>
> No. Bill's DOS version just inputs and outputs thru
> a BIOS or DOS routine. It was trivial to add AT-XY
> and colors in a DOS window with ANS escape sequence
> support. There may be a MAC OS version somewhere but
> I am not aware of it.
>
Oh well, you can't have everything.
>
> I expect that you want a MAC version with lots of hooks
> to the MAC toolbox. I think some other Forth for the MAC
> would be more satisfying except perhaps as do it yourself
> bootstrap exercise. But interfacing to all the things
> built into MAC OS is not a trivial task. But perhaps
> one exists that I do not know of.
>
The mac toolbox/API took 1,000's of man-hours to design, and would take
me just as long (or longer) to figure out! They will have a new set of hoops
in place before most of us amateur hobbyists learn how to jump the present set.
If possible I would like a small 4th that was as close to the new "standard"
as possible, but with the ability to either extend it to use the new
peripherals like the microphone, colour screen, mouse, scanner, internet etc...
or to seamlessly communicate with multi-platform interpreters that are
designed for these new computer features, like REBOL, GhoastScript, TK, etc.
The state of 4th on MacOS X is not optimum. Mops, a OOP 4th that the creator
has spent man-years maintaining, will only compile under MacOS 9 and my cobbled
together computer will no-longer boot up in system 9! Weird or what? As for
unix-like 4th's ported to the mac, they require that you compile them your-self.
I am positive that by the time I stopped receiving error messages from
"Make" or GCC
I would know enough about the intricacies of unix/C to be a guru! At which
point
of-course 4th becomes redundant!
> Best Wishes,
> Jeff Fox
...and best wishes to you as-well.
Line Noise
p.s. If someone has a working version of a unix based 4th running on MacOS X
and they could make it available to the general public please let me know.
Jeff Fox
>
Nice to hear from you. And thanks for the correction
about the origin of the first MASM version.
Best Wishes,
Jeff Fox
Jeff Fox
> I have now added the following to the FAQ:
You might include the corrected information that Bill
provided and the fact that most of Dr. Ting's verions
only support serial I/O.
Best Wishes,
Jeff Fox
Michael Manti
l...@telus.net (Line Noise) wrote:
>
>
> p.s. If someone has a working version of a unix based 4th running on MacOS X
> and they could make it available to the general public please let me know.
Anton Ertl
Ok, I have now changed the section to this:
5.13. eForth: Who wrote it, and how do the versions differ?
eForth was written by Bill Muench, and was originally metacompiled.
On request from C. H. Ting he also produced a version that was written
in MASM, and had many words removed (the user should add them back in
as an educational exercise).
If you have any further corrections, it would probably be best if you
suggested the new wording.
Anton Ertl
>As for
>unix-like 4th's ported to the mac, they require that you compile them your-self.
>I am positive that by the time I stopped receiving error messages from
>"Make" or GCC
Did you try it? On the MacOS X system I use for testing Gforth builds
and installs with a simple "./configure; make; make install".
>I would know enough about the intricacies of unix/C to be a guru! At which
>point
>of-course 4th becomes redundant!
Not at all. If the only point of Forth was to serve those people who
know it and not C, there would be little point in Forth indeed. But
if that would be the only point, no one would write Forth a system for
Unix/C platforms. But Forth has additional strengths, and that's why
we see a number of such systems.
>p.s. If someone has a working version of a unix based 4th running on MacOS X
>and they could make it available to the general public please let me know.
MacOS X ports of several Forth systems (at least Gforth, PFE, pforth)
are available through Fink.
BTW, please limit your lines to about 70 characters, and don't do comb
layout (some newsreaders hide the damage they do from their users, so
take a look at
http://groups.google.com/groups?selm=ln-0609031743590001%40207.6.28.219&output=gplain
to see the problem).
Jeff Fox
> >At which point of-course 4th becomes redundant!
>
> Not at all.
I agree.
> If the only point of Forth was to serve those people who
> know it and not C, there would be little point in Forth indeed.
"Only" switches things to a straw-man argument to which even
I have to agree, absurd as it is. Yes, in some bizare
hypothetical universe that would be true.
> But if that would be the only point, no one would write Forth
> a system for Unix/C platforms. But Forth has additional
> strengths, and that's why we see a number of such systems.
If you insert the word "only", as you have, it would make sense
in some bizare hypothetical universe.
Best Wishes,
Jeff Fox
Ming-Chun Lin
"Ron Aaron" <ronaaron@mike_row_soft.com> wrote:
Hi!! Guys,
Dr. Ting put lots of implement of eFORTH on this website.
If you are interesting in, just visit it.
http://www.eforth.com.tw/academy/basic.htm
http://www.eforth.com.tw/academy/advance.htm
Regards
Frank
m-coughlin
> MacOS X ports of several Forth systems (at least Gforth, PFE,
> pforth) are available through Fink.
>
?? What is "Fink" ? Since this answer is for someone who
does not know everything about computers and is having trouble
compiling C based Forth's using GCC, I think any links to good
references should be spelled out in detail. I don't use MacOS X
myself, but I'd like to know where I can find working Forth
systems for it in case anyone asks me.
> BTW, please limit your lines to about 70 characters
As Forth programmers, we should limit our lines to 64
characters. Unfortunately none of the editors I use for email
and newsgroups makes this easy or automatic. I think 64
characters per line is the best size for text and I have to
adjust this manually.
--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA
m-coughlin
First of all there is a special newsgroup for using Forth
on the MacIntosh. comp.lang.forth.mac
I just checked it and was very pleased to see that it had
many messages about its proper topic and only one piece of spam.
Let me start out writing for people who are new to Forth.
Line Noise wrote:
> The mac toolbox/API took 1,000's of man-hours to design, and
> would take me just as long (or longer) to figure out! They will
> have a new set of hoops in place before most of us amateur
> hobbyists learn how to jump the present set.
>
> If possible I would like a small 4th that was as close to the new
> "standard" as possible, but with the ability to either extend it
> to use the new peripherals like the microphone, colour screen,
> mouse, scanner, internet etc...
> or to seamlessly communicate with multi-platform interpreters
> that are designed for these new computer features, like REBOL,
> GhoastScript, TK, etc.
You do not want a version of Forth that is close to the
"standard". You want a version of Forth that is documented for
beginning programmers and hobbyists. The "standard" versions of
Forth (using the word "standard" as meaning common, ordinary, or
not special) are only suited to hackers who are good at reverse
engineering software.
> The state of 4th on MacOS X is not optimum. Mops, a OOP 4th that
> the creator has spent man-years maintaining, will only compile
> under MacOS 9 and my cobbled together computer will no-longer
> boot up in system 9! Weird or what? As for unix-like 4th's ported
> to the mac, they require that you compile them your-self.
> I am positive that by the time I stopped receiving error messages
> from "Make" or GCC I would know enough about the intricacies
> of unix/C to be a guru! At which point of-course 4th becomes
> redundant!
I first used the Unix operating system decades ago when
its printed documentation could only be obtained thru devious
means in strange places. I knew it would never last and would be
replaced by a better system that could be understood by people
who were not computer geeks. I was shocked beyond belief when
Apple said it was going to replace its system "for the rest of
us" with one based on Unix.
Unfortunately you have not found the path to the true
Mops. Keep looking. There are many versions of Mops, old and
new, but it is not always possible to find the one you need
right away. I have Mops working on MacOS from 7.1 (with a 680x0)
to my newest Mac system, a PowerPC with MacOS 8.1. Mops for OSX
is available and constantly being improved.
People who create C/Unix based Forth systems forget what
trouble they had learning about computers and think all
computing starts with C and Unix. They are interested in helping
beginners, but they can't stop giving answers that only make
sense to C/Unix programmers. So you have to keep at it until you
can drag the right information out of them. Another example of
the difficulty of getting an answer to a simple question is
shown in the thread about -eForth. A little while ago, I
mentioned that Bill Muench's web site (with his sources to
eForth) seemed to have disappeared. This produced no response
(well, it was only a sideline to another topic). After a long
series of messages about eForth started by Michael Gassanenko,
we now know that Bill Muench's web site has moved to http://www.baymoon.com/~bimu/forth/
Mops is well supported, with good documentation, and used
by several helpful people, the most helpful being its author,
Mike Hore. I'm sure you can find what you need to have Mops
working on your computer with OSX, but you might also run into a
little difficulty that will need the same amount of effort that
was needed to find the original sources for eForth.
[snip]
> p.s. If someone has a working version of a unix based 4th
> running on MacOS X and they could make it available to the
> general public please let me know.
Let me switch to writing for people who have been programming
computers for decades. I'll recopy a paragraph from the
beginning.
> If possible I would like a small 4th that was as close to the new
> "standard" as possible, but with the ability to either extend it
> to use the new peripherals like the microphone, colour screen,
> mouse, scanner, internet etc...
> or to seamlessly communicate with multi-platform interpreters
> that are designed for these new computer features, like REBOL,
> GhoastScript, TK, etc.
This is not asking for anything easy. There is nothing
available that meets these requirements. As the philosopher said
to the king, "there is no royal road to understand mathematics".
Nowadays we can say there is no way to use a computer for the
general public. When you learn to use a computer well, you
become a special person, not a member of the general public. I
am always trying to teach my friends how to use computers. Its
hard to get very far with people who can't manage to plug in a
keyboard. Back up your data to floppy disks, I tell them. Much
too hard to understand, they tell me. After a long time they
make some progress. Then I see they can type faster than me, the
expert. But I learn a good lesson. Computers are too hard to use
and understand. Not a little bit too hard, very much too hard.
Every time something is made a little easier, then new programs
are written that do something that makes computers complicated
again. When I show somebody how to write simple text messages,
they want to use different fonts, different colors and include pictures.
So now to Forth on the Mac. Is Forth going to be a way to
make using a computer easier? Forth was the first programming
language available for the Mac. Why did C and Unix catch up and
surpass it? If we can make Forth the royal road to understanding
computers, all us Forth programmers will get rich.
Let me quote from Mr. Line Noise again.
> The state of 4th on MacOS X is not optimum. Mops, a OOP 4th that
> the creator has spent man-years maintaining, will only compile
> under MacOS 9 and my cobbled together computer will no-longer
> boot up in system 9! Weird or what? As for unix-like 4th's ported
> to the mac, they require that you compile them your-self.
> I am positive that by the time I stopped receiving error messages
> from "Make" or GCC I would know enough about the intricacies
> of unix/C to be a guru! At which point of-course 4th becomes
> redundant!
Mops runs under MacOS X. Why is finding the right
version and getting it going not easy enough? Why isn't it
easier to use Forth on the Mac and not have to know anything
about error messages from "make' and "GCC"? We need a few
amateur hobbyists to remind us that Forth might make things
simpler for using current GUI based programs, but its not there yet.
Line Noise
Michael Manti <mma...@mac.com> wrote:
it is 404
Ah good! that one works, and it has a carbon app pre-compiled.
... with 2,991 defined words! Yikes! But it seems to have
extensive dox. I guess I will be away for a wile.
Gary Chanson
"Line Noise" <l...@telus.net> wrote in message
news:ln-110903...@207.6.28.219...
>
> Ah good! that one works, and it has a carbon app pre-compiled.
> ... with 2,991 defined words! Yikes! But it seems to have
> extensive dox. I guess I will be away for a wile.
2,991? Small! Quest32 has 7,601. ];-)
--
-GJC
-Software Consultant (Embedded systems and Real Time Controls)
-gcha...@mvps.org
-Abolish public schools
Line Noise
an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> l...@telus.net (Line Noise) writes:
> >As for
> >unix-like 4th's ported to the mac, they require that you compile them
your-self.
> >I am positive that by the time I stopped receiving error messages from
> >"Make" or GCC
>
> Did you try it?
Tried and failed.
I _did_ compile the "D" version of 4th, the instruction where
very cookbook-like i.e.: put these file in these directories,
open terminal and type these words hit enter then these hit enter
ect.
> On the MacOS X system I use for testing Gforth builds
> and installs with a simple "./configure; make; make install".
>
The instructions "./configure; make; make install". must mean
something to someone, but why do you mistake me for one!?
What seems simple and obvious to you is so only because you have been
doing it for years, or decades even.
If you overheard a surgeon instruct an assistant "open; extract; close"
would you then feel ready to preform an appendectomy?
> >I would know enough about the intricacies of unit/c to be a guru! At which
> >point
> >of-course 4th becomes redundant!
>
> Not at all. If the only point of Forth was to serve those people who
> know it and not C, there would be little point in Forth indeed.
I do not know C and therefore the only point of 4th that is
of interest to me, and my kind, is it's usefulness outside of
the domain of C.
> But
> if that would be the only point, no one would write Forth a system for
> Unix/C platforms. But Forth has additional strengths, and that's why
> we see a number of such systems.
>
> >p.s. If someone has a working version of a unix based 4th running on MacOS X
> >and they could make it available to the general public please let me know.
>
> MacOS X ports of several Forth systems (at least Gforth, PFE, pforth)
> are available through Fink.
OK I will do a web search for Fink ( there will be a lot
of entries for that i bet!) and see what comes up.
>
> BTW, please limit your lines to about 70 characters, and don't do comb
> layout (some newsreaders hide the damage they do from their users, so
> take a look at
>
>
http://groups.google.com/groups?selm=ln-0609031743590001%40207.6.28.219&output=gplain
>
> to see the problem).
>
> - anton
1 2 3 4 5 6
123456789 123456789 123456789 123456789 123456789 123456789 1234
Looks OK to me.
But if it bugs you I will try to keep my line short.
Doug Hoffman
>
> > The state of 4th on MacOS X is not optimum. Mops, a OOP 4th that
> > the creator has spent man-years maintaining, will only compile
> > under MacOS 9 and my cobbled together computer will no-longer
> > boot up in system 9!
"will only compile under OS9" needs a little more explanation. As
received (downloaded) Mops will run and compile/interpret just fine
under OSX. But, if you wish to recompile the kernel, Mops currently
seems to require that that be done uunder pre-OSX. Not really show
stopper, IMHO.
Also, there is the commercial Power MacForth which also runs just fine
under OSX. You can't recompile the kernel because the source isn't
provided (it's a commercial Forth). But, like Mops, you really don't
need to. Both MacForth and Mops are fine Forths
Michael Coughlin wrote:
>We need a few
>amateur hobbyists to remind us that Forth might make things
>simpler for using current GUI based programs, but its not there yet.
Probably a true statement, but things aren't too bad. I have written
some extensions for Mops that work like this:
window w \ instantiate a window object
test: w \ fire up the window
checkbox c \ instantiate a control object
c add: w \ add the control to the window's list of GUI objects
Done! The window is now up and runnning with a functional checkbox
control. Clicking on the checkbox will check/uncheck it. The state
of the checkbox can be obtained via:
get: c \ returns 1 if checked, 0 if unchecked
Other GUI elements are created/used in a simiilar manner. I have the
pre-OSX version completed and running. I'm now working on updating it
for OSX.
Regards,
-Doug
Bernd Paysan
> As Forth programmers, we should limit our lines to 64
> characters. Unfortunately none of the editors I use for email
> and newsgroups makes this easy or automatic. I think 64
> characters per line is the best size for text and I have to
> adjust this manually.
Knode can do that, just checked. However, I think news postings
should be readable with a 80x24 or 80x25 terminal, and then,
the default "wrap after 76" is ok. Maybe not for long replies
and counter-replies ;-).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
clvrmnky
> Anton Ertl wrote:
>
>>MacOS X ports of several Forth systems (at least Gforth, PFE,
>>pforth) are available through Fink.
>>
> ?? What is "Fink" ? Since this answer is for someone who
> does not know everything about computers and is having trouble
> compiling C based Forth's using GCC, I think any links to good
> references should be spelled out in detail. I don't use MacOS X
> myself, but I'd like to know where I can find working Forth
> systems for it in case anyone asks me.
>
http://fink.sourceforge.net. It is basically an implementation of
Debian's dpkg and apt-get that allows you to get ports of common
software onto your Mac without having to enter autoconf hell.
You can choose precompiled packages, or compile everything from source.
Really excellent way to get good open-source software onto your Mac. I
use it heavily. Being able to easily run good old standard apps I'm
used to on *NIX on OS X is really fun.
>>BTW, please limit your lines to about 70 characters
>
> As Forth programmers, we should limit our lines to 64
> characters. Unfortunately none of the editors I use for email
> and newsgroups makes this easy or automatic. I think 64
> characters per line is the best size for text and I have to
> adjust this manually.
>
Heh. The recommended (by news.answers.*, anyway) limit for USENET
articles is 72 characters, which is what I've forced vi to wrap on for
years now. I have no idea what Mozilla is doing to this message, however.
Coos Haak
>In article <2003Sep...@a0.complang.tuwien.ac.at>,
>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> l...@telus.net (Line Noise) writes:
>> >As for
>> >unix-like 4th's ported to the mac, they require that you compile them
>your-self.
>> >I am positive that by the time I stopped receiving error messages from
>> >"Make" or GCC
>>
>> Did you try it?
>
>Tried and failed.
>
>I _did_ compile the "D" version of 4th, the instruction where
>very cookbook-like i.e.: put these file in these directories,
>open terminal and type these words hit enter then these hit enter
>ect.
<snipped more>
I always thought that the name of the language on topic
in c.l.f. was Forth (See the ANSI/ISO standard).
Or are you referring to some implementation by
as you mention "4th" or "4th's" ?
Coos
Coos Haak
<r...@tid.es> wrote:
><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
><html>
<snipped "unreadable" text>
Don't post HTML in newsgroups.
Read Forth literature about IF ELSE THEN and BEGIN UNTIL
>: UMIN ( u u -- u ) 2DUP U< IF BEGIN DROP ;
: UMIN 2DUP U> IF SWAP THEN DROP ;
>: UMAX ( u u -- u ) 2DUP U< UNTIL THEN SWAP DROP ;
: UMAX 2DUP U< IF SWAP THEN DROP ;
>: DU< ( ud ud -- f )
> ROT 2DUP XOR IF SWAP 2SWAP THEN THEN 2DROP U< ;
: DU<
ROT 2DUP =
IF 2DROP U< EXIT
THEN
U> NIP NIP
;
You can't span BEGIN UNTIL over a definition, at
least most implementations don't allow that.
CODE definitions is another matter.
Coos
Line Noise
<j.j....@hccnet.nl> wrote:
> I always thought that the name of the language on topic
> in c.l.f. was Forth (See the ANSI/ISO standard).
> Or are you referring to some implementation by
> as you mention "4th" or "4th's" ?
>
> Coos
1st, 2nd, 3rd & 4th... common english abbreviations for
first, second, third, ect.
By fluke 4th is a homonym for Forth.
astro...@yahoo.es
> On Thu, 11 Sep 2003 16:31:48 +0200, Rafael González Fuentetaja
> <r...@tid.es> wrote:
>
> ><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> ><html>
> <snipped "unreadable" text>
> Don't post HTML in newsgroups.
Sorry, I don't understand what has happened. It was not certainly my
intention to post HTML. Now, I'm writting this through Google and
expect to be OK.
>
> Read Forth literature about IF ELSE THEN and BEGIN UNTIL
There must be a misunderstanding here.
These definitions below are not mine, they are actually from Bill
Munch´s lib.e4 file.
From my basic knowledge of FORTH, I can understand the IF ELSE THEN
and
BEGIN UNTIL constructs, but I don't understand such things as:
1) IF without THEN in definition of D<
2) IF and BEGIN without THEN and UNTIL in definiton of UMIN
3) UNTIL and THEN , without IF and BEGIN in definition of UMAX
4) THEN without IF in definition of DU<
The fact that they were written by Bill Munch makes me think that they
are not bugs but rather some optimization tricks or non-academic
usages that I'd like to be explained.
Rafael
: UMIN ( u u -- u ) 2DUP U< IF BEGIN DROP ;
: UMAX ( u u -- u ) 2DUP U< UNTIL THEN SWAP DROP ;
: D< ( d d -- f ) ROT 2DUP XOR IF SWAP 2SWAP 2DROP < ;
: DU< ( ud ud -- f )
ROT 2DUP XOR IF SWAP 2SWAP THEN THEN 2DROP U< ;
>
Coos Haak
<snip>
> I don't understand what has happened. It was not certainly my
>intention to post HTML. Now, I'm writting this through Google and
>expect to be OK.
Yes, it is not.
<snip>
>From my basic knowledge of FORTH, I can understand the IF ELSE THEN
>and
>BEGIN UNTIL constructs, but I don't understand such things as:
>
>1) IF without THEN in definition of D<
>2) IF and BEGIN without THEN and UNTIL in definiton of UMIN
>3) UNTIL and THEN , without IF and BEGIN in definition of UMAX
>4) THEN without IF in definition of DU<
>
>The fact that they were written by Bill Munch makes me think that they
>are not bugs but rather some optimization tricks or non-academic
>usages that I'd like to be explained.
The Forth's I use check the matching of the IF/THEN and BEGIN/UNTIL
pairs, but :/; pairs too. When the checking is removed, I think
Bill Muench's code would compile.
>Rafael
>
>: UMIN ( u u -- u ) 2DUP U< IF BEGIN DROP ;
>: UMAX ( u u -- u ) 2DUP U< UNTIL THEN SWAP DROP ;
UNTIL jumps conditionally to the BEGIN
>: D< ( d d -- f ) ROT 2DUP XOR IF SWAP 2SWAP 2DROP < ;
>: DU< ( ud ud -- f )
> ROT 2DUP XOR IF SWAP 2SWAP THEN THEN 2DROP U< ;\
Here the IF from D< would conditionally jump to the
seconde THEN in DU<.
Nice code, I rest my case.
Coos
Coos Haak
A homonym for Forth in Dutch would be Force or Fors,
because there is no equivalent for the English 'th'.
As I wrote earlier, we speak of Fort or Ford (d and t
at the end of a word is not different in sound).
comp.lang.forth is not MTV !
Coos
Anton Ertl
>Anton Ertl wrote:
>
>> MacOS X ports of several Forth systems (at least Gforth, PFE,
>> pforth) are available through Fink.
>>
>
> ?? What is "Fink" ?
How do I know? I asked Google for "Fink MacOS". The first hit tells
me:
|The Fink project wants to bring the full world of Unix Open Source
|software to Darwin and Mac OS X. We modify Unix software so that it
|compiles and runs on Mac OS X ("port" it) and make it available for
|download as a coherent distribution.
>Since this answer is for someone who
>does not know everything about computers and is having trouble
>compiling C based Forth's using GCC, I think any links to good
>references should be spelled out in detail.
>> BTW, please limit your lines to about 70 characters
>
>As Forth programmers, we should limit our lines to 64
>characters.
If we used 64x16-char screens for reading Usenet, it should be more
like 55 characters (to allow for a few levels of quoting). However,
we don't, so we should stick to Usenet conventions, and they are
designed for 80-char wide terminals.
Anton Ertl
>In article <2003Sep...@a0.complang.tuwien.ac.at>,
>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> l...@telus.net (Line Noise) writes:
>> >As for
>> >unix-like 4th's ported to the mac, they require that you compile them
>your-self.
>> >I am positive that by the time I stopped receiving error messages from
>> >"Make" or GCC
>>
>> Did you try it?
>
>Tried and failed.
Well, with that wealth of feedback we will have a hard time learning
about and fixing the problem. How about reporting which Forth system
you tried, which version, on what version of MacOS X, and what error
messages you got?
>The instructions "./configure; make; make install". must mean
>something to someone, but why do you mistake me for one!?
Because you wrote that you have received error messages from make.
Bill Spight
> >: UMIN ( u u -- u ) 2DUP U< IF BEGIN DROP ;
> >: UMAX ( u u -- u ) 2DUP U< UNTIL THEN SWAP DROP ;
> UNTIL jumps conditionally to the BEGIN
>
> >: D< ( d d -- f ) ROT 2DUP XOR IF SWAP 2SWAP 2DROP < ;
> >: DU< ( ud ud -- f )
> > ROT 2DUP XOR IF SWAP 2SWAP THEN THEN 2DROP U< ;\
> Here the IF from D< would conditionally jump to the
> seconde THEN in DU<.
>
> Nice code, I rest my case.
Please explain. What is so nice about this code?
Thanks,
Bill
Gary Chanson
Bernd Paysan
> People who create C/Unix based Forth systems forget what
> trouble they had learning about computers and think all
> computing starts with C and Unix.
I can remember having learned to "read the instructions". This seems to be
the major obstacle of most people when starting to deal with computers.
However, times change. Computers are now introduced to people at an age
where they actually are willing to read instructions. Ok, that was how I
went at that problem, by starting to read about computers. From that to
actually buying a computer, it took me about 2 years. Part of that time was
waiting - I concluded that a 32 bit processor and a GUI was necessary, and
that one wasn't available for a reasonable price before.
BTW: For the Windows users, I created a self-installing distribution of
Gforth, since these people want something like that, and are worried by the
idea of compiling their system themselves (which is something Free Software
encourages - you have the right to compile your system yourself*). Mac
users probably want something similar.
*) and no, you don't see "error messages" when you compile Gforth. You see
messages, but they do not indicate an error. I'm aware that people are
scared by messages scrolling past; that's why SuSE 8.2 hides them under a
progress bar. I'm scared by people who don't want to look inside things and
understand. Ignorance is the root of all evil.
Coos Haak
<gcha...@NOSPAM.TheWorld.com> wrote:
>
>"Bill Spight" <Xbsp...@pacbell.net> wrote in message
>news:3F6330FD...@pacbell.net...
>> Please explain. What is so nice about this code?
>
> Nothing.
What was I thinking, a Saturday morning and not
so very structured...
Some code definitions in my kernel are still written
this way. I was younger than.
Coos
Marcel Hendrix
> BTW: For the Windows users, I created a self-installing distribution of
> Gforth, since these people want something like that, and are worried by the
> idea of compiling their system themselves
It is hard to imagine that such a tone of voice will attract flocks of
enthusiastic gnu-Forth-for-windows users.
-marcel
Bernd Paysan
This is free software. Our motivation is not maximum amount of users (as
it would be for commercial software), but least amount of effort. I
have too many bad memories when I started with this Windows
autoinstaller stuff (back then with bigFORTH). At the Forth-e.V.
conference 1998, a number of Windows users expressed vocally that they
absolutely need such a thing, because extracting a .tar.gz is ways too
difficult for a Windows user (for one thing, it requires a
non-Microsoft tool like WinZip). Another problem Windows users had back
then was that IE inserted CRs before every LF into tar.bz2 files, which
for sure couldn't be decompressed afterwards.
I suggested them kindly to find a free setup compiler; WinShield is not
an option. Everbody agreed, and several people promised to do some
research. Then I waited for several months, with no result (but some
activity). Finally, I got impatient, entered "www.download.com" or
something like that into my browser, searched for "setup compiler" and
downloaded Inno Setup (the only one that wasn't shareware and came with
sources) - a matter of a few minutes.
I have absolutely no need for enthusiastic GNU-Forth-for-Windows users
of that kind. The idea I have of enthusiastic users is like the Debian
and Fink maintainers of Gforth: They do all the compiling and packaging
for these distributions themselves, and report a bug when there's one
(so usually you don't hear anything, things just work).
Fortunately, the setup.exe thing takes enough most of the entry barrier
away, so complaints are ways down - and we get even people who test the
setup.exe before we can release it. I even managed to get bigFORTH to
compile most of itself during the installation, reducing the package by
half a megabyte size. The only complaint I got was "the package now is
half a megabyte smaller, is there something missing?".
Anton Ertl
>This is free software. Our motivation is not maximum amount of users (as
>it would be for commercial software), but least amount of effort.
Sounds like the motivation for commercial software (whether
proprietary or free) to me. Since Gforth is a non-commercial free
software project, I see the issue a little differently:
- Users who provide useful feedback and might become developers or
contribute in some other way are certainly users we want to have.
- Users who play dumb and are just a support load don't help us.
Here's a commercial opportunity for someone out there: provide a
commercial help line for such people (but, OTOH, if these people
wanted to pay for support, they would have bought a commercial Forth
system; ok, there are only proprietary commercial Forth systems
around, but I doubt that these people care for that difference).
- Other users may be useful by spreading the word.
These different kinds of users seem to be distributed quite
differently among the users of different OSs:
- Once upon a time Gforth had a bug that showed up only on Solaris.
We got about five useful bug reports from Solaris users and none that
was useless.
- OTOH, the feedback most Windows users give is "it does not work",
and that's if we are lucky; in some cases we see just some negative
slur on Gforth in some other context.
- Linux users seem to be in-between.
It's not clear why this is the case, but I think the way the OS vendor
deals with bug reports establishes a culture.
Michael L Gassanenko
>
> Michael L Gassanenko <m_l...@yahoo.com> wrote:
> > "eForth creator Bill Muench's site"
> > http://homepage.mac.com/forth/
> > in not there anymore.
> >
> > Is there an official eForth distribution in the net?
>
> I am Bill Muench.
>
> I wander, but am not lost.
>
> There is a copy of eForth on this server:
>
> http://www.baymoon.com/~bimu/forth/
>
> When mac.com was no longer free, I never got around to making
> the site public again.
is BFforth (unstripped e-forth) available?
Bee
bForth has no relationship to eForth other than I made both.
bForth is what I used to write commercial and field research
software. It was optimized, at the time, to be (first) small and
(second) fast for the hardware we were using. There were
versions for many processors.
A x86 bForth is included in the zip file as an executable. It is
what I call BTC = bit threaded code, there was even a TBTC =
tokenized bit threaded code version. It has one 64k segment for
machine code, one for highlevel tokens, and one for the
dictionary. The .exe file is very small and is expanded when
loaded into memory.
I have not made the source for bForth available. But it does
have a fairly good decompiler and disassembler.
Bee (Bill Muench)
Santa Cruz, California 95065
Albert van der Horst
Bernd Paysan <bernd....@gmx.de> wrote:
>Marcel Hendrix wrote:
>
>> Bernd Paysan <bernd....@gmx.de> writes Re: Forth for the Mac
>>
>non-Microsoft tool like WinZip). Another problem Windows users had back
>then was that IE inserted CRs before every LF into tar.bz2 files, which
>for sure couldn't be decompressed afterwards.
Bizarre! Thanks a lot, I now understand a mysterious problem.
I have a tool to create a block file from a text file, by
expanding lines to 63 characters, and adding a LF. If such
content is redirected in Windows, it is mangled.
This kind of trickery seems making the pipe mechanism
in Windows worthless.
<SNIP>
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://www.jwdt.com/~paysan/
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.
Gary Chanson
"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in message
news:HL8yEL.Kpy...@spenarnc.xs4all.nl...
>
> I have a tool to create a block file from a text file, by
> expanding lines to 63 characters, and adding a LF. If such
> content is redirected in Windows, it is mangled.
>
> This kind of trickery seems making the pipe mechanism
> in Windows worthless.
The pipe mechanism has nothing to do with it. A pipe simply moves
data from input to output without doing any kind of conversion. If you
send a Unix text file to a Windows console, you have no right to expect it
to be handled properly (with or without a pipe).
m-coughlin
>
> In article <6k72kb...@cohen.paysan.nom>,
> Bernd Paysan <bernd....@gmx.de> wrote:
> >Marcel Hendrix wrote:
> >
> >> Bernd Paysan <bernd....@gmx.de> writes Re: Forth for
> >> the Mac
> >>
> <SNIP>
> > non-Microsoft tool like WinZip). Another problem Windows users
> > tar.bz2 files, which for sure couldn't be decompressed
> > afterwards.
>
> Bizarre! Thanks a lot, I now understand a mysterious problem.
There's nothing mysterious or bizarre about it at all.
Microsoft was following an industry standard. This is a bit
unusual, but not bizarre. The ASCII standard used two characters
to end a line. If a text message had only one end of line
character instead of a pair, the message was non-standard and
could not be read by text display programs that did follow the
ASCII standard. Unfortunately, if this conversion is applied to
binary data, things will not work; not even a little bit. I've
seen problems with end of line characters showing up randomly
for decades, but not as much as I used to since there are many
work-arounds in place, at least for text files.
> I have a tool to create a block file from a text file, by
> expanding lines to 63 characters, and adding a LF. If such
> content is redirected in Windows, it is mangled.
>
> This kind of trickery seems making the pipe mechanism
> in Windows worthless.
Maybe you need a CR-LF pair. Or is there another line
ending standard in use?
--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA
Jeff Fox
> > > non-Microsoft tool like WinZip). Another problem Windows users
> > > had backthen was that IE inserted CRs before every LF into
> > > tar.bz2 files, which for sure couldn't be decompressed
> > > afterwards.
> >
> > Bizarre! Thanks a lot, I now understand a mysterious problem.
>
> There's nothing mysterious or bizarre about it at all.
> Microsoft was following an industry standard.
If you meant that it was unusual for mysterious that IE treated
.tar.gz2 files as if they were text files and corrupted them
then yes, business as usual.
Unix used CR, DOS used CR,LF and of course the Mac used LF only.
So lots of utilites got written over and over to fix this kind
of problem but it can never be solved once and for all. The utilities
sometimes result in programs with LF,CR,LF or other strange combinations
because it is one of those unsolvable problems with files that
will always have to be dealt with. But hopefully not all software
is as brain damaged or nasty as IE and will not apply these text file
conversions to binary files. Microsoft is just following THEIR
industry standards and mucking up the compeditor's softare that
uses other conventions like LF or CR only.
And of course this all goes back to the days when printers used
overstrike and had to be able to perform CR and LF separately.
But it is an example of the kind of problems that text files
will always have unless we have a true one and only monopoly.
Line termination, other control characters, file names and
directory structures are all examples of files not being as
univeral as is often claimed and will always result in errors
that can never be fixed once and for all. Of course if
everyone would just do it the right way... ;-)
> This is a bit
> unusual, but not bizarre. The ASCII standard used two characters
> to end a line. If a text message had only one end of line
> character instead of a pair, the message was non-standard and
> could not be read by text display programs that did follow the
> ASCII standard. Unfortunately, if this conversion is applied to
> binary data, things will not work; not even a little bit. I've
> seen problems with end of line characters showing up randomly
> for decades, but not as much as I used to since there are many
> work-arounds in place, at least for text files.
>
> > I have a tool to create a block file from a text file, by
> > expanding lines to 63 characters, and adding a LF. If such
> > content is redirected in Windows, it is mangled.
> >
> > This kind of trickery seems making the pipe mechanism
> > in Windows worthless.
>
> Maybe you need a CR-LF pair. Or is there another line
> ending standard in use?
It is a good example of why Windows users might have problems
with formats like tar or gzip, and no it is not really all
that bizare that IE may have been hostile to them.
Best Wishes,
Jeff Fox
Gary Chanson
"Jeff Fox" <f...@ultratechnology.com> wrote in message
news:4fbeeb5a.0309...@posting.google.com...
>
> Unix used CR, DOS used CR,LF and of course the Mac used LF only.
No, Unix uses LF and Mac uses (or used) CR. DOS and Windows do use
CR+LF.
Marcel Hendrix
[..]
> No, Unix uses LF and Mac uses (or used) CR. DOS and Windows do use
> CR+LF.
And most importantly, all internet standards specify CR+LF explicitly,
whether it be Windows or Unix. I don't think we can blame MS for this.
-marcel
andr...@littlepinkcloud.invalid
> Albert van der Horst wrote:
>>
>> In article <6k72kb...@cohen.paysan.nom>,
>> Bernd Paysan <bernd....@gmx.de> wrote:
>> >Marcel Hendrix wrote:
>> >
>> >> Bernd Paysan <bernd....@gmx.de> writes Re: Forth for
>> >> the Mac
>> >>
>> <SNIP>
>> > non-Microsoft tool like WinZip). Another problem Windows users
>> > had backthen was that IE inserted CRs before every LF into
>> > tar.bz2 files, which for sure couldn't be decompressed
>> > afterwards.
>>
>> Bizarre! Thanks a lot, I now understand a mysterious problem.
> There's nothing mysterious or bizarre about it at all.
> Microsoft was following an industry standard. This is a bit
> unusual, but not bizarre. The ASCII standard used two characters
> to end a line.
No it didn't. ASCII mandates no character that marks an end of line
-- that's the source of all the confusion.
> If a text message had only one end of line character instead of a
> pair, the message was non-standard and could not be read by text
> display programs that did follow the ASCII standard.
Huh? The ASCII control characters are carriage return, which moves
the carriage back to the leftmost column, and line feed, which moves
the carriage up one line.
CP/M only supported raw printer drivers, so there was no conversion of
end of line characters to whatever the particular printer wanted.
Each byte sent by the program went directly to the parallel printer
port. Because of that, CR/LF became the standard way to end a line on
CP/M. And DOS inherited that, and Windows...
Andrew.
Alex McDonald
> "Jeff Fox" <f...@ultratechnology.com> wrote in message
> news:4fbeeb5a.0309...@posting.google.com...
> >
> > Unix used CR, DOS used CR,LF and of course the Mac used LF only.
>
> No, Unix uses LF and Mac uses (or used) CR. DOS and Windows do use
> CR+LF.
On a Forth note, Win32Forth later versions are comfortable with LF,
CRLF and CR line endings on text files, and correctly handle files of
these types. Inconsistencies in files (that is, CRLF/CR/LF
interspersed) are handled OK, except pathalogical cases such as
...LFCRCRLF... when W32F does greedy matching; that example would be
seen as ...<LF>, null line<CR>, null line<CRLF>, ...
This seems to work OK. I had thought of fixing on UNIX/Windows/Mac
line endings for the whole file based on the first line terminator
seen, but that required holding a state for each file, which was
undesirable, and didn't seem to buy anything significant.
--
Regards
Alex McDonald
Albert van der Horst
Gary Chanson <gcha...@NOSPAM.TheWorld.com> wrote:
>
>"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in message
>news:HL8yEL.Kpy...@spenarnc.xs4all.nl...
>>
>> I have a tool to create a block file from a text file, by
>> expanding lines to 63 characters, and adding a LF. If such
>> content is redirected in Windows, it is mangled.
>>
>> This kind of trickery seems making the pipe mechanism
>> in Windows worthless.
>
> The pipe mechanism has nothing to do with it. A pipe simply moves
>data from input to output without doing any kind of conversion. If you
simply --> is supposed to
I'm never sure whether MS does what it is supposed to.
>send a Unix text file to a Windows console, you have no right to expect it
>to be handled properly (with or without a pipe).
Okay. It happens to be the same as a Unix text file, but it is
just a Forth block file, and I consider them as binary under windows.
Thus I send it to a file directly.
>-GJC
>-Software Consultant (Embedded systems and Real Time Controls)
>-gcha...@mvps.org
hp
and, a carriage return isn't a line feed, &vv...
--
>>> hp -at- lxhp -dot- in-berlin -dot- de <<<
Jeff Fox
> news:4fbeeb5a.0309...@posting.google.com...
> >
> > Unix used CR, DOS used CR,LF and of course the Mac used LF only.
>
> No, Unix uses LF and Mac uses (or used) CR. DOS and Windows do use
> CR+LF.
Quite right. When I wrote the sentance I wrote LF CR,LF LF and I knew
one of the LF was suppose to be a CR. It had been a while since I
got bitten by that issue. Thanks.
Best Wishes,
Jeff Fox
Jeff Fox
> And most importantly, all internet standards specify CR+LF explicitly,
> whether it be Windows or Unix. I don't think we can blame MS for this.
The issue was that MS's IE was 'fixing' .tar.gz2 format files by
treating them as text files that needed fixin. If MS wasn't responsible
where was the problem? The problem was with the people who used tar
and gzip and didn't realize that 'all internet standards specify CR+LF
explicitly'?
Best Wishes,
Jeff Fox
Jeff Fox
> simply --> is supposed to
> I'm never sure whether MS does what it is supposed to.
That seems pretty reasonable. But what definition of 'supposed to' does
one use? Supposed by whom? Does a documented bug become a feature or a
standard? Who gets to make the rules?
Is there something that you are sure always does what it is suppose to?
> >send a Unix text file to a Windows console, you have no right to expect it
> >to be handled properly (with or without a pipe).
>
> Okay. It happens to be the same as a Unix text file, but it is
> just a Forth block file, and I consider them as binary under windows.
> Thus I send it to a file directly.
Were you using an extension or format that MS is suppose to recognize
by default as binary and not text?
Best Wishes,
Jeff Fox
Jeff Fox
> On a Forth note, Win32Forth later versions are comfortable with LF,
> CRLF and CR line endings on text files, and correctly handle files of
> these types. Inconsistencies in files (that is, CRLF/CR/LF
> interspersed) are handled OK, except pathalogical cases such as
> ...LFCRCRLF... when W32F does greedy matching; that example would be
> seen as ...<LF>, null line<CR>, null line<CRLF>, ...
I assume that the compiler handles other control characters as
spaces. But what about editing? Are html tags legal and are
they treated as space delimiters or are they only allowed in
comments?
> This seems to work OK. I had thought of fixing on UNIX/Windows/Mac
> line endings for the whole file based on the first line terminator
> seen, but that required holding a state for each file, which was
> undesirable, and didn't seem to buy anything significant.
Does the latest editor make any changes to line delimiters? What
kind does it insert when one presses Enter? Does it care what
kind were already in use in the file?
Best Wishes,
Jeff Fox
Gary Chanson
"Alex McDonald" <alex...@btopenworld.com> wrote in message
news:b57b10b6.03091...@posting.google.com...
>
> On a Forth note, Win32Forth later versions are comfortable with LF,
> CRLF and CR line endings on text files, and correctly handle files of
> these types. Inconsistencies in files (that is, CRLF/CR/LF
> interspersed) are handled OK, except pathalogical cases such as
> ...LFCRCRLF... when W32F does greedy matching; that example would be
> seen as ...<LF>, null line<CR>, null line<CRLF>, ...
I did something like this in my 16 bit DOS Forth but I decided that it
added too much complexity without adding any significant functionality and
left it out of the 32 bit Windows version (Quest32).
Gary Chanson
IE doesn't handle .tar.gz files at all so how can it "fix" them? If
it tries to open one, it simply calls whatever utility has been registered
for that file type. There is no standard utility for .tar.gz files in
Windows. The most common one used is WinZip which handles them without
problems.
Gary Chanson
"Jeff Fox" <f...@ultratechnology.com> wrote in message
news:4fbeeb5a.03091...@posting.google.com...
> >
> > just a Forth block file, and I consider them as binary under windows.
> > Thus I send it to a file directly.
>
> Were you using an extension or format that MS is suppose to recognize
> by default as binary and not text?
Windows doesn't differentiate between text and binary files. All
files are binary in Win32. A few of the utilities supplied with the OS
(ie COPY, TYPE, etc.) do make a differentiation between text and binary
files, but only by treating ^Z as an end of text character (backward
compatibility with CP/M). They don't convert end of line characters.
Many (most?) Windows programs are written in languages which do
differentiate between text and binary files and may do conversions.
--
-GJC
-Software Consultant (Embedded systems and Real Time Controls)
-gcha...@mvps.org
-Abolish public schools
Alex McDonald
news:<b57b10b6.03091...@posting.google.com>...
> > On a Forth note, Win32Forth later versions are comfortable with LF,
> > CRLF and CR line endings on text files, and correctly handle files of
> > these types. Inconsistencies in files (that is, CRLF/CR/LF
> > interspersed) are handled OK, except pathalogical cases such as
> > ...LFCRCRLF... when W32F does greedy matching; that example would be
> > seen as ...<LF>, null line<CR>, null line<CRLF>, ...
I may have confused Win32Forth users here. It's important to note that I'm
referring to versions of Win32Forth after TJZ's last distribution; please
see http://groups.yahoo.com/group/win32forth/files/Distros/ file V606.EXE, a
self extracting ZIP archive with the latest tested version (well, as tested
as it gets with about 5 active users).
>
> I assume that the compiler handles other control characters as
> spaces.
Yes, but only if they are parsed by WORD, as in BL WORD . Other parsing
words such as S" (which uses PARSE) leaves them untranslated, as per the ANS
specification (excepting, of course CRLF, LF or CR).
> But what about editing? Are html tags legal and are
> they treated as space delimiters or are they only allowed in
> comments?
: <A SOURCE >IN ! DROP ; IMMEDIATE \ HTML link start marker
is the only allowed HTML marker outside comments, and comments to end of
line. There's no support for HTML or XML in Win32Forth, although the editor
tries to render HTML, but imho would be better if it let Windows do that.
Anyhow,
to support XML/HTML encoded source, I would suggest using SAX or an XSLT
capable parser as a callable front end rather than having Forth parse what
is foreign to the native parser.
>
> > This seems to work OK. I had thought of fixing on UNIX/Windows/Mac
> > line endings for the whole file based on the first line terminator
> > seen, but that required holding a state for each file, which was
> > undesirable, and didn't seem to buy anything significant.
>
> Does the latest editor make any changes to line delimiters? What
> kind does it insert when one presses Enter? Does it care what
> kind were already in use in the file?
The editor is a good Windows citizen. Although it will read files with mixed
line terminators, it will CRLF terminate all lines in a modified file (which
is modified in memory; the line terminators are not maintained as each line
is pointed to from a table, a common editor technique that avoids huge
amounts of memory shuffling as the file is editted).
READ-LINE is promiscuous; WRITE-LINE is Windows standard compliant and
writes CRLF. This is not a problem on a Windows Forth. The promiscuous
READ-LINE was added at the request of a user who was using EMACS and saving
in Unix CR format; supporting LF for Mac was trivial to add once this was
done. [I'm grateful to Bill McCarthy for debugging it for me.]
Changes to source files (including collapsing/expanding tabs, blank
padding/trimming and CR/CRLF/LF) have no effect on W32F's ability to VIEW a
definition or jump to the line causing an error. W32F records the line
number & the filename for defined words in the dictionary; it's up to the
editor that W32F calls to find the line.
>
> Best Wishes,
> Jeff Fox
--
Regards
Alex McDonald
Alex McDonald
>
> "Alex McDonald" <alex...@btopenworld.com> wrote in message
> news:b57b10b6.03091...@posting.google.com...
> >
> > On a Forth note, Win32Forth later versions are comfortable with LF,
> > CRLF and CR line endings on text files, and correctly handle files of
> > these types. Inconsistencies in files (that is, CRLF/CR/LF
> > interspersed) are handled OK, except pathalogical cases such as
> > ...LFCRCRLF... when W32F does greedy matching; that example would be
> > seen as ...<LF>, null line<CR>, null line<CRLF>, ...
>
> I did something like this in my 16 bit DOS Forth but I decided that it
> added too much complexity without adding any significant functionality and
> left it out of the 32 bit Windows version (Quest32).
I added at the request of an EMACS user; it wasn't too hard (Bill McCarty
helped greatly; the first version had a bug...)
and adds very little code to READ-LINE. It also helps when running Forth
sources from the net. Lots of them are badly formed (in the Windows sense).
--
Regards
Alex McDonald
Jeff Fox
> "Jeff Fox" <f...@ultratechnology.com> wrote in message
> news:4fbeeb5a.03091...@posting.google.com...
> >
> > by default as binary and not text?
The discussion was about IE, the browser that MS includes as part
of their Windows distribution and how it mangled .tar.gz2 files.
It was clearly established that we were talking about IE and MS
and treating binary files as text files that needed fixing.
First we heard that it wasn't MS's fault. ;-)
> Windows doesn't differentiate between text and binary files.
Now we get a complete denial of the problem. ;-)
When I double click on an icon MS software does different things
after differentiating between the different types of text and binary
files that the system recognizes.
> All files are binary in Win32.
You mean they have bits in them? ;-)
> A few of the utilities supplied with the OS
> (ie COPY, TYPE, etc.) do make a differentiation between text and binary
> files, but only by treating ^Z as an end of text character (backward
> compatibility with CP/M). They don't convert end of line characters.
I can't imagine how you can completely deny the entire thread's history.
You are claiming that IE didn't do this at all?
Maybe this is so. I didn't report the 'bug' I just said that IE is
MS software so it isn't so strange that it might mangle .tar.gz2 files
since that isn't one of their own standards.
> Many (most?) Windows programs are written in languages which do
> differentiate between text and binary files and may do conversions.
Many? Most? How about the one we have been talking about? ;-)
Best Wishes,
Jeff Fox
Jeff Fox
> > The issue was that MS's IE was 'fixing' .tar.gz2 format files by
> > treating them as text files that needed fixin. If MS wasn't responsible
> > where was the problem? The problem was with the people who used tar
> > and gzip and didn't realize that 'all internet standards specify CR+LF
> > explicitly'?
>
> IE doesn't handle .tar.gz files at all so how can it "fix" them?
You must have missed the first post in this thread. If I may quote it:
"then was that IE inserted CRs before every LF into tar.bz2 files, which
for sure couldn't be decompressed afterwards."
The way I read that was that IE in the process of downloading a file
over the internet didn't respond to the .tar.gz2 file extension
properly and treated it like a text file that needed CR added before
every LF. Obviously it was then corrupted and couldn't be decompressed
afterwards.
I understood that DOS had few distinctions twenty years ago and that
one of them was text and binary files. The text files were expected
to be terminated by a EOF character. If one wanted to COPY a binary
file the safe way was to specify \B for binary so that it would use
the file length from the directory rather than terminating copy at
the first EOF character.
Windows is much smarter about file extensions. If I type the name
of a file at the command prompt it launches the program that it
thinks is appropriate to deal with that type of file. So it is
more knowledgable about file extensions than DOS which started with
just .txt .bat .exe .com formats. Despite the way you write messages
to me as if I were completely unaware of things like DOS and Windows
I do have experience with them as well as Unix and a few other OS. ;-)
Here the issue has been that Bernd was refering to how Windows users
wanted executable binaries because they didn't want to compile the
sources. This led to a discussion of one reason why this was a problem
for Windows users, a couple of them mentioned that IE had corrupted
the tarred and gziped source files in the first place by not defaulting
to treating them as binary files and instead treating them as foreign
text files that needed fixing.
Michael C. commented that this was not strange behavior at all and
I added that indeed Windows not recognizing .tar.gz2 was not unusual
that IE was not designed to be totally friendly to foreign (non-MS)
stuff. First there was the denial that this sort of bug was MS's
fault which I thought was funny. Then came your comments about
how windows doesn't differentiate between files of different types
that it only knows binary format. So I explained it for you once
before. You went off on other MS utilities than the one under
discussion so I tried to bring it back to IE. Now you have
denied that IE handles .tar.gz2 files at all.
We were talking about using IE as a browswer, grabbing a tarred
gzipped file and how it mangled the files users. This is what
we mean when we say that IE processed the files and 'fixed'
the format making it useless.
> it tries to open one, it simply calls whatever utility has been registered
> for that file type.
Right, but even when you add a gzip utility to Windows so that you
can set it up to launch gzip and decompress the .gz file it was already
too late because it had already mangled the foreign (read non-MS) format
file.
> There is no standard utility for .tar.gz files in Windows.
Right. It doesn't default to 'proper' behavior with .gz files
which caused problems. In fact it just interpreted the unknown
extension as a text file and added CR.
> The most common one used is WinZip which handles them without
> problems.
Even if IE has modified them by adding CR before every LF character?
I doubt it. That is not what was reported in this thread.
It is kind of sad that you feel compeled to argue with anything
that I write when all you had to do was read the thread to realize
that other people reported this problem with IE. It is also kind
of sad that those people, and the other people reading the thread
haven't corrected you. I guess they just enjoy seeing you thrash
on with silly off topic comments as long as you argue with me.
Have you figured this thread out yet?
Best Wishes,
Jeff Fox
Gary Chanson
> >
> > I did something like this in my 16 bit DOS Forth but I decided
> > that it
> > added too much complexity without adding any significant functionality
> > and
> > left it out of the 32 bit Windows version (Quest32).
>
> I added at the request of an EMACS user; it wasn't too hard (Bill
> McCarty
> helped greatly; the first version had a bug...)
> and adds very little code to READ-LINE. It also helps when running Forth
> sources from the net. Lots of them are badly formed (in the Windows
> sense).
Fixing it in READ-LINE is only a partial fix. In my 16 bit Forth,
everything which might do line parsing is written to handle whatever line
terminators it encounters.
Marcel Hendrix
[..]
>> No, Unix uses LF and Mac uses (or used) CR. DOS and Windows do use
>> CR+LF.
> And most importantly, all internet standards specify CR+LF explicitly,
^^^^^^^^^^^^^^^^^^ (*)
> whether it be Windows or Unix. I don't think we can blame MS for this.
(*) e.g. telnet, rfc959 (ftp), rfc0821 (smtp), rfc0977 (nntp), rfc1036,
rfc1725 (pop3), rfc2086 (http) ... (I didn't implement others yet, but
assume they'll be the same in this respect.)
-marcel
m-coughlin
> m-coughlin <m-cou...@comcast.net> wrote:
> > Albert van der Horst wrote:
> >>
> >> In article <6k72kb...@cohen.paysan.nom>,
> >> Bernd Paysan <bernd....@gmx.de> wrote:
> >> >Marcel Hendrix wrote:
> >> >
> >> >> Bernd Paysan <bernd....@gmx.de> writes Re: Forth for
> >> >> the Mac
> >> >>
> >> <SNIP>
> >> > non-Microsoft tool like WinZip). Another problem Windows
> >> > users
> >> > had backthen was that IE inserted CRs before every LF into
> >> > tar.bz2 files, which for sure couldn't be decompressed
> >> > afterwards.
> >>
> >> Bizarre! Thanks a lot, I now understand a mysterious problem.
>
> > There's nothing mysterious or bizarre about it at all.
> > Microsoft was following an industry standard. This is a bit
> > unusual, but not bizarre. The ASCII standard used two characters
> > to end a line.
>
> No it didn't. ASCII mandates no character that marks an end of
> line -- that's the source of all the confusion.
That's a good way to look at the situation. Or another way
to say it is ASCII does not have a single character to end a
line. Since the ASCII standard was developed when mechanical
teletypes were in use, they decided to send a command to move
the carriage return to the first position and a separate one to
advance the paper roll up one line. I've seen programs that made
good use of this on CRT terminals that did not have cursor
addressing to update information on the bottom line without
clearing the screen.
> > If a text message had only one end of line character instead of a
> > pair, the message was non-standard and could not be read by
> > text display programs that did follow the ASCII standard.
>
> Huh? The ASCII control characters are carriage return, which
> moves the carriage back to the leftmost column, and line feed,
> which moves the carriage up one line.
Yes. And when you tried to read text without ACSII CR-LF,
you either got letters zinging all over the page or you got
everything printed on one line. Ripped the heck out of paper
when you wanted to print it.
> CP/M only supported raw printer drivers, so there was no
> conversion of end of line characters to whatever the particular
> printer wanted. Each byte sent by the program went directly to
> the parallel printer port. Because of that, CR/LF became the
> standard way to end a line on CP/M. And DOS inherited that, and
> Windows...
NO that wasn't it. FIRST there was the ASCII standard, with
CR-LF, then there were printers that followed the ASCII
standard. There is no trouble with printers printing B when the
file has an A because printers follow the ASCII standard saying
what number byte means B and which means A. But there is lots of
trouble because there are swarms of text files that don't follow
the ASCII standard for what bytes end a line. (Well actually I
did once have a printer that would get the letters mixed up. It
had a bad interface chip, but I soldered in a new chip and then
it worked fine.) There are also switches on old printers to use
ASCII CR-LF ends or something else. They are offen set wrong.
Its not DOS, or Windows or C/Unix problem. Its an ASCII
standard problem. There are plenty of things to blame Microsoft
for. We don't need to blame them for the line ending problem. In
fact, they actually do (or did) follow an industry standard.
Maybe when they hear from all those people who complain that
they are using the wrong characters to end lines, they are less
inclined to follow industry standards.
andr...@littlepinkcloud.invalid
Exactly. So we are not in disagreement about the basic historical
facts.
>> > If a text message had only one end of line character instead of a
>> > pair, the message was non-standard and could not be read by
>> > text display programs that did follow the ASCII standard.
>>
>> Huh? The ASCII control characters are carriage return, which
>> moves the carriage back to the leftmost column, and line feed,
>> which moves the carriage up one line.
> Yes. And when you tried to read text without ACSII CR-LF,
> you either got letters zinging all over the page or you got
> everything printed on one line. Ripped the heck out of paper
> when you wanted to print it.
>
>> CP/M only supported raw printer drivers, so there was no
>> conversion of end of line characters to whatever the particular
>> printer wanted. Each byte sent by the program went directly to
>> the parallel printer port. Because of that, CR/LF became the
>> standard way to end a line on CP/M. And DOS inherited that, and
>> Windows...
> NO that wasn't it. FIRST there was the ASCII standard, with
> CR-LF, then there were printers that followed the ASCII standard.
Right.
> There is no trouble with printers printing B when the file has an A
> because printers follow the ASCII standard saying what number byte
> means B and which means A. But there is lots of trouble because
> there are swarms of text files that don't follow the ASCII standard
> for what bytes end a line.
But there is no ASCII standard for what bytes end a line -- we've
already established that. There are only printer control characters.
ASCII says nothing about line terminators.
> Its not DOS, or Windows or C/Unix problem. Its an ASCII
> standard problem.
Exactly. If ASCII had actually specified a line terminator character
we wouldn't be in this mess.
> There are plenty of things to blame Microsoft for. We don't need to
> blame them for the line ending problem.
Indeed not. DOS was CP/M compatible, so it had to do exactly what
CP/M did.
Andrew.
m-coughlin
[snip]
> First we heard that it wasn't MS's fault. ;-)
>
> > Windows doesn't differentiate between text and binary files.
>
> Now we get a complete denial of the problem. ;-)
>
> When I double click on an icon MS software does different things
> after differentiating between the different types of text and
> binary files that the system recognizes.
>
> > All files are binary in Win32.
>
> You mean they have bits in them? ;-)
>
> > A few of the utilities supplied with the OS
> > (ie COPY, TYPE, etc.) do make a differentiation between text and
> > binary files, but only by treating ^Z as an end of text character
> > (backward compatibility with CP/M). They don't convert end of
> > line characters.
>
> I can't imagine how you can completely deny the entire thread's
> history. You are claiming that IE didn't do this at all?
I had the good luck to connect to the Internet before they
invented browser software and Microsoft was not involved. In
those old days, if you wanted to get a copy of a file, you used
a program called ftp. It had two modes, text and binary. Text
was the default, since for a brief time most people were
interested in mainly reading text files. In addition, the ASCII
standard had only defined 127 characters, so when you
transmitted bytes of text, they had their high bit set to zero.
If you received a byte bigger than 127, you knew there was a
mistake and your program might try some measure to correct it.
There were even some systems that would strip off the high bit
of each character. Why bother to transmit a bit that always had
to be off? Especially if you were using the plane old telephone
system. Then things changed. Everything got faster and had error
correction. People wanted to transmit binary data. People in
Europe wanted to use the letters of their native language that
were not part of the set used by English and Mediaeval Latin.
But this was not easy to do since it required changing a lot of
computers. The problems of mixing text and binary data lingered
around for far too long.
So when the wide area network named The Internet started
to become popular, there was still the idea that the default
should be text and not binary. Many a time I unsuccessfully
transferred a compiled program to my home Unix box over my 9600
baud modem since I forgot to set the ftp program to binary.
Fortunately I didn't do it with the really big files like X-windows.
> Maybe this is so. I didn't report the 'bug' I just said that IE is
> MS software so it isn't so strange that it might mangle .tar.gz2
> files since that isn't one of their own standards.
Maybe its not a bug; maybe its a case of having too
many things treated as text by default.
> > Many (most?) Windows programs are written in languages
> > which do differentiate between text and binary files and may
> > do conversions.
>
> Many? Most? How about the one we have been talking about? ;-)
Nowadays we always want to transfer binary data and
think messing around with 7 bit characters was a mistake. But
that was not the idea at the beginning. There are lots of old
ideas and assumptions underlying the defaults of computer
programs that can trip you up. They are not all due to Microsoft.
Anton Ertl
>m...@iae.nl (Marcel Hendrix) writes Re: Mysterious CR's Re: Forth for the Mac (was Re: -eForth ?)
> ^^^^^^^^^^^^^^^^^^ (*)
>> whether it be Windows or Unix. I don't think we can blame MS for this.
>
>(*) e.g. telnet, rfc959 (ftp), rfc0821 (smtp), rfc0977 (nntp), rfc1036,
>rfc1725 (pop3), rfc2086 (http) ... (I didn't implement others yet, but
>assume they'll be the same in this respect.)
RFC 2086 is "IMAP4 ACL extension". You probably meant
RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1
And this says:
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7.
...
3.7.1 Canonicalization and Text Defaults
Internet media types are registered with a canonical form. In
general, an entity-body transferred via HTTP messages MUST be
represented in the appropriate canonical form prior to its
transmission; the exception is "text" types, as defined in the next
paragraph.
So, unless the HTTP server reported the .tar.gz file as having a text
type, the browser (even one from MS) has to assume that the bytes
coming across the net are already in the desired form.
When in canonical form, media subtypes of the "text" type use CRLF as
the text line break. HTTP relaxes this requirement and allows the
transport of text media with plain CR or LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR, and bare LF as being
representative of a line break in text media received via HTTP.
So, in the body, HTTP 1.1 does not specify "CRLF, and nothing but
CRLF".
- 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
EuroForth: http://www.micross.co.uk/euroforth2003/Call_for_Participation.html
Marcel Hendrix
> m...@iae.nl (Marcel Hendrix) writes:
>>> And most importantly, all internet standards specify CR+LF explicitly,
>> ^^^^^^^^^^^^^^^^^^ (*)
>>> whether it be Windows or Unix. I don't think we can blame MS for this.
[..]
> So, in the body, HTTP 1.1 does not specify "CRLF, and nothing but
> CRLF".
You go in deeper, and dig nearer to the original problem, than I intended.
In "the body" you can do whatever you want with line endings, just like
you can put whatever you want in "a binary file", when you make sure it
is understood as such at "the other end."
You surely are not denying that CR+LF is all over the mentioned protocols?
-marcel
Jeff Fox
The protocols do specify CR/LF as the format of the line endings of
the protocol command message exchanges. (The user presses Enter, the
message that goes out ends in CR/LF.) But of course some of the protocols
support multiple formats for the body including bit streams and image
formats where text line termination has no place.
That was of course the history of the thread, that IE treated .tar.gz2
files as if they were ascii text files that needed to have a CR added
before every LF character which made them useless and put a bump into
getting the sources for users to compile themselves. I expect that
one can coax MS software into the proper behavior once this default
behavior has been identified as a problem for people using IE and
wanting to deal with .tar.gz format files.
> You surely are not denying that CR+LF is all over the mentioned
> protocols?
I haven't seen anyone deny that, but that was not what other
people were taking about. They were taking about binary data
in the body of transfers and how some software was treating it
as ASCII text terminated by LF which needed fixin to CR/LF
format. The command messages use CR/LF in those protocols
but that is something else alltogether.
Best Wishes,
Jeff Fox
>
> -marcel
Line Noise
an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Bernd Paysan <bernd....@gmx.de> writes:
> >This is free software. Our motivation is not maximum amount of users (as
> >it would be for commercial software), but least amount of effort.
>
> Sounds like the motivation for commercial software (whether
> proprietary or free) to me. Since Gforth is a non-commercial free
> software project, I see the issue a little differently:
>
> - Users who provide useful feedback and might become developers or
> contribute in some other way are certainly users we want to have.
>
> - Users who play dumb and are just a support load don't help us.
> Here's a commercial opportunity for someone out there: provide a
> commercial help line for such people (but, OTOH, if these people
> wanted to pay for support, they would have bought a commercial Forth
> system; ok, there are only proprietary commercial Forth systems
> around, but I doubt that these people care for that difference).
>
> - Other users may be useful by spreading the word.
>
>
> These different kinds of users seem to be distributed quite
> differently among the users of different OSs:
>
> - Once upon a time Gforth had a bug that showed up only on Solaris.
> We got about five useful bug reports from Solaris users and none that
> was useless.
>
> - OTOH, the feedback most Windows users give is "it does not work",
> and that's if we are lucky; in some cases we see just some negative
> slur on Gforth in some other context.
>
> - Linux users seem to be in-between.
>
> It's not clear why this is the case, but I think the way the OS vendor
> deals with bug reports establishes a culture.
>
> - anton
I thought that my comment "tried and failed" followed by
a paragraph saying, and here I will par-a-phase myself
'but another guys "cook-book" approach worked just fine'
would have engendered the idea that a cook-book was the
appropriate way to instruct the ignorant.
It was not my intention to be unhelpful. I just wished to
point out an impediment to forth's adoption by new users.
If person "A" compiled a working copy of a forth for unix
would it produce a separate invokable file that could be
FTP'ed to person "B"? and could person "B" then run that
file and program in forth?
Is anyone using -eForth on MacOS X? and does -eForth have
a way of getting data from the mouse, finding and/or
changing the colour value of a pixel on the screen, or
of producing sound on a speaker?
Jeff Fox
> m-coughlin wrote:
> > People who create C/Unix based Forth systems forget what
> > trouble they had learning about computers and think all
> > computing starts with C and Unix.
>
> I can remember having learned to "read the instructions".
I had to read this post a couple of times to understand it.
Then I felt embarrased. Then I laughed about getting old.
I actually thought that you were talking about 'reading
the instructions' as in reading a hex dump and making sense
of the opcodes. When I got my first micro the manual was
pretty thin and it took me quite a while to read the
instructions (that the processor read). Naturally I
thought of the old days when programmers had to read
memory dumps to use and program computers. (But I don't go
as far as saying that real programmers can read the
instructions.)
Then I remembered getting a Mac ten years later and
making a joke out of tossing the instruction manual
and saying 'we don't need no stinking manual' after
all it's a Mac. It was designed to be accessible to
an 18 month old child who can't yet talk or read. ;-)
Then I thought about how in the last fifteen years
much of the time I have been working with computers
where there is no manual unless you write one. So
again the idea of 'reading the instructions' as
in reading a user's manual just wasn't the first
thought that came to my mind. ;-)
> This seems to be
> the major obstacle of most people when starting to deal with computers.
I thought, yeah, it took me quite a while to learn to read the
processor's instructions.
> However, times change. Computers are now introduced to people at an age
> where they actually are willing to read instructions.
I wondered about that. I remember lots of 12 year olds when I was
in my twenties who learned to read the processor's instructions. It
was hard to keep up with some of them regarding that sort of hands-
on knowledge of various computers.
> Ok, that was how I
> went at that problem, by starting to read about computers.
Then I began to realize that you were talking about reading
magazine articles, how-to books, and computer instruction manuals.
It didn't make sense to me at first when I was thinking that
people learned about computers by reading their instructions.
> From that to
> actually buying a computer, it took me about 2 years.
That made me think about how I worked with them for a decade
before it was really possible to get one of your own. I had
a physics instructor who told me that with the invention of
the microprocessor that before long a computer would be about
as cheap as a mechanical switch. Of course the people in the
computer sci department insisted that microprocessors were
a fad and were not real computers at all back then, after
all they could not run their mainframe's binaries.
> Part of that time was
> waiting - I concluded that a 32 bit processor and a GUI
> was necessary, and that one wasn't available for a
> reasonable price before.
That made me think about writing GUI in Forth long before
32-bit processors were available and how my style of doing
it changed after exposure to Smalltalk and how that was
almost 24 years ago.
> BTW: For the Windows users, I created a self-installing distribution of
> Gforth, since these people want something like that, and are worried by the
> idea of compiling their system themselves (which is something Free Software
> encourages - you have the right to compile your system yourself*). Mac
> users probably want something similar.
>
> *) and no, you don't see "error messages" when you compile Gforth. You see
> messages, but they do not indicate an error. I'm aware that people are
> scared by messages scrolling past; that's why SuSE 8.2 hides them under a
> progress bar. I'm scared by people who don't want to look inside things and
> understand. Ignorance is the root of all evil.
I started over, reread your post, and realized how I had completely
missed the original point. You had been talking about users who
didn't read the instruction manauals for products that explain how
to run a program or how to compile a program. It made me think
of all the times I joked about there needing to be a 'Forth for
Dummies' book since computers had become mostly media players
and consumer items. In the old... days there was almost nothing
one could do with a personal computer unless you programmed it
and the people who played with them were all programmers. There
were no manuals just as there aren't today on the bleeding edge.
It made me think about all the stories about people programming
at a front panel and reading and writing instructions long before
there were instruction manuals for consumers. It also reminded
me of how Mike once said that source code was 'code' as in
needing to be decoded by a cryptologist. Then I thought about
the people who got started in computing long before I did and
how their experiences were different than mine. I didn't think
that Fortran and Cobol and mainframe assemblers and JCL was
particularly interesting. But there certainly were people who
got sort of locked into that era of computing.
It made me think about how different the experience has been
for each generation of programmers in an industry that moves
as fast as this one has. It not only takes all kinds, but
there is no other way. Something to think about anyway.
Best Wishes,
Jeff Fox
Jeff Fox
> Is anyone using -eForth on MacOS X?
Not that I know of.
> and does -eForth have
> a way of getting data from the mouse, finding and/or
> changing the colour value of a pixel on the screen, or
> of producing sound on a speaker?
Of course.
Best Wishes,
Jeff Fox
Roelf Toxopeus
f...@ultratechnology.com (Jeff Fox) wrote:
> Line Noise <l...@telus.net> wrote in message
> news:<ln-2413B7.17...@news.telus.net>...
>
> > Is anyone using -eForth on MacOS X?
>
> Not that I know of.
There is a Mac OS 9 PPC eForth on Mr. Ting's site. I recall it was
written to be used as a tokenizer for OpenFirmware.
The accompanying readme file is very interesting.
Apple's MPW is used to compile it. For MacOS X you have to
adapt it to Apple's ProjectBuilder (which doesn't need an
instruction manual and avoids Make and such things, hey this
is a Mac isn't it ;0)
-Roelf
Anton Ertl
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: Mysterious CR's Re: Forth for the Mac (was Re: -eForth ?)
>
>> m...@iae.nl (Marcel Hendrix) writes:
>>>> And most importantly, all internet standards specify CR+LF explicitly,
>>> ^^^^^^^^^^^^^^^^^^ (*)
>>>> whether it be Windows or Unix. I don't think we can blame MS for this.
>
>[..]
>
>> So, in the body, HTTP 1.1 does not specify "CRLF, and nothing but
>> CRLF".
>
>You go in deeper, and dig nearer to the original problem, than I intended.
>
>In "the body" you can do whatever you want with line endings, just like
>you can put whatever you want in "a binary file", when you make sure it
>is understood as such at "the other end."
If it's a text body, then no, only CRLF, LF, and CR are allowed as
newlines.
>You surely are not denying that CR+LF is all over the mentioned protocols?
There are about 30 mentionings of CRLF in RFC 2068, but what does that
have to do with the mangling of a file that was certainly transferred
as a body and not in some other part of the protocol?
Anton Ertl
>I thought that my comment "tried and failed" followed by
>a paragraph saying, and here I will par-a-phase myself
>'but another guys "cook-book" approach worked just fine'
>would have engendered the idea that a cook-book was the
>appropriate way to instruct the ignorant.
This still does not tell anyone which Forth system you have tried and
where you failed. E.g., Gforth includes cookbooks, but did you try
Gforth at all; and if so, at what step did you fail?
>If person "A" compiled a working copy of a forth for unix
>would it produce a separate invokable file that could be
>FTP'ed to person "B"? and could person "B" then run that
>file
With PFE, maybe. Gforth needs at least two files.
I just asked a Mac Guru, and according to him Mac programs nowadays
don't come as one directly executable program, but as a
self-extracting executable that runs an installer, and the installer
installs several files in various places.
> and program in forth?
I don't know if B can program in Forth. But with just the executable,
B will certainly not learn it. The docs will be missing.
m-coughlin
> m-coughlin <m-cou...@comcast.net> writes:
> >Anton Ertl wrote:
> >> MacOS X ports of several Forth systems (at least Gforth, PFE,
> >> pforth) are available through Fink.
> > ?? What is "Fink" ?
> How do I know? I asked Google for "Fink MacOS". The first hit
> tells me:
> |The Fink project wants to bring the full world of Unix Open Source
> |software to Darwin and Mac OS X. We modify Unix software so
> |that it compiles and runs on Mac OS X ("port" it) and make it
> |available for download as a coherent distribution.
> >Since this answer is for someone who
> >does not know everything about computers and is having trouble
> >compiling C based Forth's using GCC, I think any links to good
> >references should be spelled out in detail.
> Ok: http://www.google.com
The first thing that came to my mind when I saw the term
"Finc" was an abbreviation for Forth, Inc. The second thing that
came to my mind was that was not what was meant.
You can find nearly anything with Google if you know what
you are looking for to begin with.
> >> BTW, please limit your lines to about 70 characters
> >As Forth programmers, we should limit our lines to 64
> >characters.
> If we used 64x16-char screens for reading Usenet, it should be
> more like 55 characters (to allow for a few levels of quoting).
> However, we don't, so we should stick to Usenet conventions,
> and they are designed for 80-char wide terminals.
I didn't say 64x16 screens, I said 64 character lines. That
leaves room for quoting with > and still have 64 characters of
text. But that is not automatic so I have to edit line lengths.
My 80 character wide terminals don't get used much anymore.
They must use 80 characters since that is what a punch card had.
Typewriters had a maximum of 85 character lines (or some had 110
if they had smaller size letters), but you had to set margins,
and having 64 character lines looks good on a piece of paper.
Mike Hore
> Line Noise wrote:
>>
>>> The state of 4th on MacOS X is not optimum. Mops, a OOP 4th that
>>> the creator has spent man-years maintaining, will only compile
>>> under MacOS 9 and my cobbled together computer will no-longer
>>> boot up in system 9!
>
> "will only compile under OS9" needs a little more explanation. As
> received (downloaded) Mops will run and compile/interpret just fine
> under OSX. But, if you wish to recompile the kernel, Mops currently
> seems to require that that be done uunder pre-OSX. Not really show
> stopper, IMHO.
Also you really don't normally need to recompile the Mops system
at all.
To get the latest version, check www.PowerMops.org. The manual
is now online in html. Things keep happening.
.......
Well I see I need to start reading CLF again -- I'd got too
far behind, and also I thought anybody interested in Forth
for the Mac would read/post on comp.lang.forth.mac.
Thanks Doug for keeping your eye out here too -- I'd better
do it as well :-)
Cheers, Mike.
----------------------------------------------------------------
Mike Hore mikeh...@OVE.invalid.icasolution.com.au
(sorry about munged email address, but you should be able to
figure it out)
----------------------------------------------------------------
Doug Hoffman
[]
>
> Also you really don't normally need to recompile the Mops system
> at all.
Yes. If the latest release has any problems, I've not found them. It
seems very solid (and *fast*).
> To get the latest version, check www.PowerMops.org. The manual
> is now online in html. Things keep happening.
>
> .......
>
> Well I see I need to start reading CLF again -- I'd got too
> far behind, and also I thought anybody interested in Forth
> for the Mac would read/post on comp.lang.forth.mac.
>
> Thanks Doug for keeping your eye out here too -- I'd better
> do it as well :-)
No problem, Mike. I find some very interesting stuff here and so make
it a practice to visit.
-Doug
Elliott Chapin
new to Forth, but this'll be my first look at it on a Mac.
Thanks ...
On 25 Sep 2003 15:39:46 -0700, dhof...@journey.com (Doug Hoffman)
wrote:
-------------------------------------------------------------------------
http://www3.sympatico.ca/echapin
Doug Hoffman
> So - how do I rebuild the application after the second update? I'm not
> new to Forth, but this'll be my first look at it on a Mac.
You don't need to rebuild the Mops system at all. Mike packages
updates as complete builds as downloaded. The download is not large
and this makes things simple for the users. (just remember to trash
the prior Power Mops application, otherwise there will be problems).
-Doug
Elliott Chapin
after the fact. And it was just a couple of minutes later that I
should have looked at the manual (now downloaded).
On 30 Sep 2003 13:56:59 -0700, dhof...@journey.com (Doug Hoffman)
wrote:
>Elliott Chapin <ech...@sympatico.ca> wrote in message news:<69dhnvsfefriv208a...@4ax.com>...
-------------------------------------------------------------------------
http://www3.sympatico.ca/echapin
Doug Hoffman
> But his page notes a couple of modifications apparently to be done
> after the fact. And it was just a couple of minutes later that I
> should have looked at the manual (now downloaded).
OK. Those aren't Mike's updates, they are small optional tweaks
provided by me. If you have seen the website (the website isn't
actually Mike's. It is maintained by a "volunteer", who is doing a
very good job with it.) then you have also seen the answer to your
original question. It is not hard to rebuild the system if you so
choose. My tweaks are optional and may become part of a future normal
release.
Let me know if you have problems and I can probably talk you through
it.
Regards,
-Doug
Albert Lee Mitchell
> Michael L Gassanenko wrote:
>> ----------snip-------------
>>
>> For me it is important now that this Forth is written in high-level Forth.
>
> I should have formulated this as:
> if eForth is lost, is there another such Forth written in Forth?
Yes, our umbilical Forth is written in high level Forth and free for
download. http://www.amresearch.com/software/
Version 3 runs under F-PC
Version 4 runs under Win32Forth
Version 5 runs in Linux/BSD
Version 6 runs in M$ Windoze and Xwindows on Linux, *BSD, and Apple OSX
under Gforth.
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc. The Embedded Systems Experts
http://www.amresearch.com (916) 780-7623
----------------------------------------------------------------------