Ans permits what range of KEY codes?
Pat LaVarre
> Date: 2002-05-31 11:17:02 PST
...
> an issue that falls in the chasm
> between low-level keyboard drivers
> and the normal higher-level (e.g. on top of an OS)
...
> ANS Forth attempts to waffle ...
Definitely enlightening, thank you.
> confusing to use KEY (implying the ANS Forth word)
I did intend to speak of Ans Forth KEY, but I may have deeply
misunderstood that KEY in my newbie confusion.
> > http://www.forth.org/dpans/dpansf.htm
> > http://www.forth.org/dpans/dpans6.htm#6.1.1750
...
> KEY can _only_ produce a single 7-bit ASCII value.
Eh? Sez who? (Because you're Elizabeth, I know you know, but I don't
get it, not yet. I see no rationale links for KEY. I went looking
for explicit permission to delay all KEY results til Return/Enter was
pressed, but I didn't find it.)
The KEY here (MacOF) produces only x00..7E, never even x7F, but I have
(mis?)read 1994 Ans Forth 6.1.1750 as allowing KEY to produce any cell
value:
"Receive one character char, a member of the implementation-defined
character set. Keyboard events that do not correspond to such
characters are discarded until a valid character is received, and
those events are subsequently unavailable.
"All standard characters can be received. Characters received by KEY
are not displayed.
"Any standard character returned by KEY has the numeric value
specified in 3.1.2.1 Graphic characters. Programs that require the
ability to receive control characters have an environmental
dependency.
And from 1994 Ans Forth 3.1.2 Character types we have:
"Characters shall be at least one address unit wide, contain at least
eight bits, and have a size less than or equal to cell size.
I can see people stretching this English as saying that ( addr C! C@ )
shouldn't change the cell that KEY stacked, but how can we say this
English means KEY can stack nothing but x00..7F? Is that somehow
implied?
> the normal ... (e.g. on top of an OS)
I do appreciate you explaining how different the normal o.s. below a
Forth is from mine ... but may I exclaim: MacOF is an o.s. Grossly
huge compared with many embedded o.s. Comparable to PC BIOS, more
differently capable rather than less capable, if compared with PC DOS.
> > "only" 1994 Ans Core Forth, including KEY & EMIT,
> > plus more or less of the Ans CoreExt,
> > plus the Ans optional Facilities PAGE and AT-XY.
In MacOF, I have only KEY. I don't have EKEY. I could build an EKEY,
but only by getting into undocumented distinctions between legacy ADB
keyboards, USB keyboards, etc. etc.
> Open Firmware ...
> an interactive test environment,
> presumably on a separate machine.
There's the rub, eh? A second machine demands more space, carries
more weight, doubles my entry and upgrade costs, ....
No worries if I was doing this full time for pay, but back in the real
world ...
Pat LaVarre
Michael L.Gassanenko
I understand it as that ANS permits any range of KEY codes *to an implementor*.
Your system even has no environmental restriction: it just has no
internationalization support.
In other words, it looks like your system implies the use of English.
Elizabeth D. Rather
> I did intend to speak of Ans Forth KEY, but I may have deeply
> misunderstood that KEY in my newbie confusion.
>
> > > http://www.forth.org/dpans/dpansf.htm
> > > http://www.forth.org/dpans/dpans6.htm#6.1.1750
> ...
> > KEY can _only_ produce a single 7-bit ASCII value.
>
> Eh? Sez who? (Because you're Elizabeth, I know you know, but I don't
> get it, not yet. I see no rationale links for KEY. I went looking
> for explicit permission to delay all KEY results til Return/Enter was
> pressed, but I didn't find it.)
>
> The KEY here (MacOF) produces only x00..7E, never even x7F, but I have
> (mis?)read 1994 Ans Forth 6.1.1750 as allowing KEY to produce any cell
> value:
Yes, it is legal for a system to define its own "implementation-defined
character set", but a "standard program" has an environmental dependency
if it requires more than x7E, since that's the minimum guaranteed. I was
a little overly restrictive here.
> ...
> I do appreciate you explaining how different the normal o.s. below a
> Forth is from mine ... but may I exclaim: MacOF is an o.s. Grossly
> huge compared with many embedded o.s. Comparable to PC BIOS, more
> differently capable rather than less capable, if compared with PC DOS.
Open Firmware is sort of an OS, but certainly not a general-purpose OS.
Its mission is very specific and narrowly defined. It has a lot of
capabilities
that are unique (e.g. ability to build, manage and operate the device
tree),
but lacks a lot of features necessary to support a development
environment.
The user interface is intended to let technicians type in simple
definitions
for diagnostic purposes, for example, but is not intended for serious
programming.
In answer to your original question, is Open Firmware Forth, I'd have
to say, it's more of a specialized Forth application that passes along
many
of the features of Forth. Its fundamental difference is its ultimate
mission:
to boot the OS and configure the computer, while Forth's mission is to
provide an interactive development platform.
> > > "only" 1994 Ans Core Forth, including KEY & EMIT,
> > > plus more or less of the Ans CoreExt,
> > > plus the Ans optional Facilities PAGE and AT-XY.
>
> In MacOF, I have only KEY. I don't have EKEY. I could build an EKEY,
> but only by getting into undocumented distinctions between legacy ADB
> keyboards, USB keyboards, etc. etc.
That's too bad, and a little surprising, since Mitch Bradley (father of
Open Firmware) was one of the main proponents of EKEY.
> > Open Firmware ...
> > an interactive test environment,
> > presumably on a separate machine.
>
> There's the rub, eh? A second machine demands more space, carries
> more weight, doubles my entry and upgrade costs, ....
>
> No worries if I was doing this full time for pay, but back in the real
> world ...
What are your real goals? If you want to learn and work with Forth
as a language, you might be better off not bothering with MacOF but
instead get a "real" Forth like Power MacForth or one of the Unix
Forths.
Cheers,
Elizabeth
Pat LaVarre
...
> "implementation-defined character set", ...
> a "standard program" has an environmental dependency
> if it requires more than x7E
Ahhhh, I see now, thank you again. With those search keys, I found a
match at:
http://www.forth.org/dpans/dpansa3.htm#A.3.1.2
Specifically: "6) A Standard Program can depend on the ability to
receive any character in the range 32 ... 126 through KEY, and
similarly to display the same set of characters with EMIT. If a
program must be able to receive or display any particular character
outside that range, it can declare an environmental dependency on the
ability to receive or display that character."
I wish I had earlier noticed the 126 x7E, not 127 (x7F), here.
The fact that the KEY of MacOF does not provide x7F was a surprise to
me. I see now that a program that needs KEY to distinguish x 08
BackSpace from x7F Delete, for example emacs as done classically on
Ascii terminals, indeed does have a trivially observable
"environmental dependency".
Pat LaVarre
Pat LaVarre
> Date: 2002-05-31 21:45:00 PST
> ...
> ANS permits any range of KEY codes *to an implementor*.
> Your system even has no environmental restriction:
> From: Elizabeth D. Rather (era...@forth.com)
> Date: 2002-06-01 00:52:02 PST
...
> Yes, it is legal for a system
> to define its own "implementation-defined character set",
How large may this "implementation-defined character set" be?
Must x00..FF contain it?
Does Ans say that the transformation ( addr C! C@ ) may not change the
cell that KEY stacked? Does Ans say only that? For example, on a
system with 16-bit chars, may KEY fetch and may EMIT store
x0000..FFFF?
Curiously yours in truly stunning newbie ignorance,
Pat LaVarre
Pat LaVarre
...
> since Mitch Bradley (father of Open Firmware)
> was one of the main proponents of EKEY.
Thanks for questioning this, let me double-check ...
> > Apple PowerBook3, 1 2.7f2 BootROM built on 08/13/00 at 10:41:50
> > Copyright 1994-2000 Apple Computer, Inc.
> > All Rights Reserved
> >
> > Welcome to Open Firmware.
> > ...
Here ( ' EKEY ) chokes, complaining: ekey, huh??
> > http://members.aol.com/plforth/
> > http://members.aol.com/plforth/moforth/index.html
> > http://playground.sun.com/pub/1275/coredoc/1275-1994/1275.ps.gz
I have not yet studied this doc, and I imagine the .ps.gz format
precludes many from glancing it at easily, but via the TeX.dmg &
texshop.dmg downloads for MacOS X I get .pdf, and in that ...
I see the OF Annex I "Index ..." lists KEY but not EKEY. Likewise the
normative Annex A "... glossary". And the glossay says KEY fetches a
"char".
I guess Mitch lost an argument in committee?
Curiously enough, I see the OF Annex I also lists $CALL-METHOD and
MY-PARENT, so maybe in OpenFirmware we do have a public standard for
object-orientated Forth?
Pat LaVarre
Jerry Avins
a system-dependent, non-portable way. What use would OF have for it?
Jerry
--
I would not bet against the possibility of time travel. My opponent
might be from the future and know the answer. .. Stephen Hawking
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Pat LaVarre
> you might be better off not bothering with MacOF
> but instead get a "real" Forth like Power MacForth
> or one of the Unix Forths.
Is GForth "real"? I have that. For me, MacOF was more fun: there I
could more easily make the hardware do things e.g. make the Cd-rom
eject its tray.
> What are your real goals?
Umm, I don't have an agenda? I do have some idiosyncratic interests
e.g. I was pleased to see I could trace the talk between MacOF and its
Cd-rom drive.
Why am I here asking comp.lang.forth folk to clue me in re Forth?
Well, I'm interested (academically?) by free (gratis), interactive,
personal, programming environments. I don't like buying extra
software, I don't like customising software, because when I do that I
disconnect my experience from the other people who bought the same
hardware I did. These past few years, in my copious free time, I've
been looking at what it takes to make unsigned Java applet development
interactive.
> http://members.aol.com/ppaatt/nqjava/applet/archive.htm
> [ downloads 89364 bytes of .zip'ped .class'es to run ]
Once I wrote an applet that evaluated fragments of Java as you typed
them. I wrote the whole thing in a few days of inspired hacking.
It's a glorious mess. Rather than trying to fix it, I think I should
start over.
In passing I noticed that an unsigned Java applet lacks the necessary
privileges to define new words. Technically speaking, an unsigned
applet can't write a .class file into a space that ClassLoader will
see, unless the applet running on a server that gives write privileges
to the world of people that could know the p*sswords buried in the
applet. Also java.lang.reflect doesn't help build new classes, and
the comp.lang.java.machine code can't ask to add methods after a class
is "loaded".
I think the least awful workaround for these annoying limitations
would be to build a Forth.
This Forth would compile & interpret comp.lang.java.machine code that
the sandbox would natively reject (technically, "fail to verify").
For example, a Java sandbox rejects a variable stack effect like ?DUP,
but accepts ( DUP IF ... ELSE DROP THEN ).
I've seen two or three Java applet Forth's on the web - unimpressive.
None are Ans Forth, though some are as large or larger than my
nqjava.zip.
None run the Forth inside a classic terminal window (aka Win2K Dos
box) (aka a java.awt.TextArea with a java.awt.TextField for the
line-buffered input). Consequently, in using these Forth's, we lose
the scroll and the cut-copy-paste and the line-editing of the o.s.
Yuck.
> http://members.aol.com/ppaatt/java/demo/ReflectiveApplet.html
I've got the i/o (mostly?) worked out. Just not the Forth.
> instead get a "real" Forth
I'm also interested by comparative linguistics.
If we have an applet Forth, and an applet C, and an applet APL, etc.
etc. then we remove the quality-of-implementation variable. We can
make more apple-to-apple comparisons between programming languages.
In particular I'd like to see the machine adapt to the person, not the
other way round. If you can script an app in a language you know, I'd
like to be able to script the same app in a language I know.
Pat LaVarre
Elizabeth D. Rather
> ...
> > Yes, it is legal for a system
> > to define its own "implementation-defined character set",
>
> How large may this "implementation-defined character set" be?
>
> Must x00..FF contain it?
Depends on the size of a char. In theory, there's a lot of freedom
here, but there are some implied relationships between a char and
an address unit (although we tried to stamp them out!), and the
folks who were addressing "internationalization" issues (involving
multiple and extended character sets) found a lot of problems.
There are some papers on the subject, but I'm afraid I'm traveling
now and don't have the link. Doubtless someone else here
has it.
> Does Ans say that the transformation ( addr C! C@ ) may not change the
> cell that KEY stacked?
I'm not sure I follow this. A cell on the stack is fair game, you can
do anything you want to with it. C@ and C! deal in chars and wouldn't
of themselves affect a char on the stack. KEY will return a char in
the low-order part of the top stack item, assuming the stack is larger
than a char.
> Does Ans say only that? For example, on a
> system with 16-bit chars, may KEY fetch and may EMIT store
> x0000..FFFF?
>
In theory, yes. Many programs in existence have a dependency on
1 byte = 1 char = 1 address unit, however.
Cheers,
Elizabeth
Elizabeth D. Rather
>
> > > http://playground.sun.com/pub/1275/coredoc/1275-1994/1275.ps.gz
>
> I have not yet studied this doc, and I imagine the .ps.gz format
> precludes many from glancing it at easily, but via the TeX.dmg &
> texshop.dmg downloads for MacOS X I get .pdf, and in that ...
>
> I see the OF Annex I "Index ..." lists KEY but not EKEY. Likewise the
> normative Annex A "... glossary". And the glossay says KEY fetches a
> "char".
>
> I guess Mitch lost an argument in committee?
Probably too much prior art in Open Boot (which preceded the
standardized Open Firmware).
> Curiously enough, I see the OF Annex I also lists $CALL-METHOD and
> MY-PARENT, so maybe in OpenFirmware we do have a public standard for
> object-orientated Forth?
No, it really isn't about OOP, it's about relationships on the device
tree,
whose construction, maintenance, and use is the primary mission of
Open Firmware. If you've succeeded in making a readable version of
1276-1994, it contains a lot of explanatory material that I think you'll
find interesting.
Cheers,
Elizabeth
Elizabeth D. Rather
> > If you want to learn and work with Forth as a language,
> > you might be better off not bothering with MacOF
> > but instead get a "real" Forth like Power MacForth
> > or one of the Unix Forths.
>
> Is GForth "real"? I have that. For me, MacOF was more fun: there I
> could more easily make the hardware do things e.g. make the Cd-rom
> eject its tray.
I've never used GForth, but suspect it's more usable as a development
environment than MacOF. At least you shouldn't have to write your
own editor.
> > What are your real goals?
>
> Umm, I don't have an agenda? I do have some idiosyncratic interests
> e.g. I was pleased to see I could trace the talk between MacOF and its
> Cd-rom drive.
>
> Why am I here asking comp.lang.forth folk to clue me in re Forth?
>
> Well, I'm interested (academically?) by free (gratis), interactive,
> personal, programming environments. I don't like buying extra
> software, I don't like customising software, because when I do that I
> disconnect my experience from the other people who bought the same
> hardware I did. These past few years, in my copious free time, I've
> been looking at what it takes to make unsigned Java applet development
> interactive.
> ...
Although MacOF does provide more hardware access, I suspect for
most of your stated goals GForth will provide a friendlier platform.
Cheers,
Elizabeth
Pat LaVarre
> > also lists $CALL-METHOD and MY-PARENT,
> > so maybe in OpenFirmware we do have a public standard
> > for object-orientated Forth?
...
> No, it really isn't about OOP,
> it's about relationships on the device tree,
Can you easily elaborate?
This looks a lot like OOP to me. The word MYSELF is a pointer to the
current instance which acts as an implicit argument to methods. The
word MY-PARENT gets me from MYSELF to an instance of my superclass.
Via $CALL-METHOD I pass the string name of a method to the current
instance.
But you correctly point out I have not yet read the OpenFirmware
standard. (I like to work with a real system for awhile before I let
the written standard distort my perspective.)
I imagine getting to .pdf from .ps.gz was the bigger effort, but I
cheated. A friend I met in real life showed me how.
Pat LaVarre
Pat LaVarre
I'm not trying to be teasingly coy, I'm trying to be politely concise.
If you find my posted thinking confused, please do tell me.
> > what it takes
> > to make unsigned Java applet development interactive.
...
> GForth will provide a friendlier platform.
I'm thinking OpenFirmware is a better simulation of a Java applet's
sandbox precisely because it is less capable than GForth.
Mac OpenFirmware makes it easy to read source files. Ditto Java: an
unsigned applet can read the .html that launched it.
Mac OpenFirmware makes it neither easy nor impossible to save source
files. Ditto Java: an unsigned applet can save into the public ls -l
space of an ftp incoming/ folder.
> At least you shouldn't have to write your own editor.
To work in Mac OpenFirmware, I have to write my own source code
editor. Ditto Java.
> > free (gratis), interactive, personal, programming environments
> GForth will provide a friendlier platform.
By the GPL, GForth is free in the sense of libre (a la free speech),
not gratis (a la free beer), per
http://www.gnu.org/philosophy/categories.html
Pat LaVarre
William Cook
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:2695edf1.02060...@posting.google.com...
I see a real difference between free speech and free beer - the
difference between producer and consumer. Is the beer brewer obligated
to give the beer away gratis because he got his accounting software
gratis? Except in extreme situations, free speech has no cost to the
speaker nor the hearer. You can not say the same about beer, nor I
would maintain, software.
Bill Cook
Kent WA USA
> Pat LaVarre
Elizabeth D. Rather
> > > Curiously enough, I see the OF Annex I
> > > also lists $CALL-METHOD and MY-PARENT,
> > > so maybe in OpenFirmware we do have a public standard
> > > for object-orientated Forth?
> ...
> > From: Elizabeth D. Rather (era...@forth.com)
> > Date: 2002-06-01 13:56:03 PST
> ...
> > No, it really isn't about OOP,
> > it's about relationships on the device tree,
>
> Can you easily elaborate?
No. It's a complicated topic.
> This looks a lot like OOP to me. The word MYSELF is a pointer to the
> current instance which acts as an implicit argument to methods. The
> word MY-PARENT gets me from MYSELF to an instance of my superclass.
> Via $CALL-METHOD I pass the string name of a method to the current
> instance.
Ok, I'll try. The purpose of Open Firmware is to build and manage a
data structure called the "device tree" that represents all devices
attached
to the system. There's a "root node" and everything descends from that.
Consider somewhere in the system is a SCSI controller supporting a
disk and a tape. The "parent" of the controller is probably a bridge
to another bus, maybe PCI. The disk and tape are its children. The
disk's parent is the controller. Software on the motherboard may
issue an OPEN to the SCSI disk. This command must be passed
down the tree, and results passed back up.
> But you correctly point out I have not yet read the OpenFirmware
> standard. (I like to work with a real system for awhile before I let
> the written standard distort my perspective.)
You have _no_ useful perspective without knowing the purpose
of the system under study, which is why it's important to read at
least the explanatory parts of the standard (you can ignore some
of the gory details for now). You need to get the "big picture".
Cheers,
Elizabeth
Elizabeth D. Rather
> > for most of your stated goals
>
> I'm not trying to be teasingly coy, I'm trying to be politely concise.
> If you find my posted thinking confused, please do tell me.
>
> > > what it takes
> > > to make unsigned Java applet development interactive.
> ...
> > GForth will provide a friendlier platform.
>
> I'm thinking OpenFirmware is a better simulation of a Java applet's
> sandbox precisely because it is less capable than GForth.
It isn't "less capable". It has _different_ capabilities, with a specific
purpose and focus. It is not designed as a general-purpose development
system. You will be continually finding your purposes at odds with
Open Firmware, as you have described here so far.
> Mac OpenFirmware makes it easy to read source files. Ditto Java: an
> unsigned applet can read the .html that launched it.
>
> Mac OpenFirmware makes it neither easy nor impossible to save source
> files. Ditto Java: an unsigned applet can save into the public ls -l
> space of an ftp incoming/ folder.
Any Forth should be able to provide you access to source.
> > At least you shouldn't have to write your own editor.
>
> To work in Mac OpenFirmware, I have to write my own source code
> editor. Ditto Java.
Why should you have to? If you like vi, you ought to just be able
to use it. Surely Java development systems don't require you to
write your own editor?
> > > free (gratis), interactive, personal, programming environments
> > GForth will provide a friendlier platform.
>
> By the GPL, GForth is free in the sense of libre (a la free speech),
> not gratis (a la free beer), per
> http://www.gnu.org/philosophy/categories.html
I'm not going to jump into the licensing snake pit. There are good,
usable Forth's around with a variety of licensing policies. Find
one that suits your needs, both in terms of licensing and technical
capabilities.
Cheers,
Elizabeth
Julian Fondren
> By the GPL, GForth is free in the sense of libre (a la free speech),
> not gratis (a la free beer), per
> http://www.gnu.org/philosophy/categories.html
Anton tells you that gforth is free in the sense of 'free beer' and
you go and use the GPL's assertion that a GPL'd program is free in
the sense of 'free speech' to (and this is where it gets wierd) say
that Anton is *wrong*. Logically put: your hidden assumption is
wrong, that the two types of freedom cannot refer to the same object
at the same time.
Pat LaVarre
> To work in Mac OpenFirmware,
> I have to write my own source code editor. Ditto Java.
...
> Why should you have to?
> If you like vi, you ought to just be able to use it.
> Surely Java development systems
> don't require you to write your own editor?
I mean to say, if my development environment is an unsigned Java
applet running on some still popular browser, then my environment
comes with java.lang.* and java.util.* and java.awt.* and so on ...
... but no classic source code editor. java.awt.TextArea gives me
about as much editing as ( hex 1B emit ) gives me in MacOF. Except
the max bytes per "screen" rises from about 8KiB to 32KiB and I can
scroll a smaller window thru the "screen".
If I'm cross-compiling, then, sure, only the target system lacks a
source code editor. But if I'm developing on the target system, then
there I don't have a source code editor.
I heard you say earlier I should cross-compile. For me that's
impractical: space, weight, dollar cost, etc.
> > Mac OpenFirmware makes it neither easy nor impossible
> > to save source files. Ditto Java: an unsigned applet
> > can save into the public ls -l space
> > of an ftp incoming/ folder.
...
> Any Forth should be able to provide you access to source.
Eh? Files, even blocks, are optional by Ans? That's Not a Bad Thing?
> > I'm thinking OpenFirmware is
> > a better simulation of a Java applet's sandbox
> > precisely because it is less capable than GForth.
...
> It isn't "less capable".
> It has _different_ capabilities,
> with a specific purpose and focus.
Yes.
> It is not designed as a general-purpose development system.
OF is intentionally incomplete: it's designed to run other code.
Most often that other code is an o.s., but that other code can just as
well be a simpler application, like emacs or vi.
> You will be continually finding your purposes
> at odds with Open Firmware,
> as you have described here so far.
Ouch, lost me here, sorry.
How did I say OF was at odds with my purposes?
> I'm not going to jump into the licensing snake pit.
Thank you.
Pat LaVarre
Elizabeth D. Rather
> > > At least you shouldn't have to write your own editor.
> ...
> > To work in Mac OpenFirmware,
> > I have to write my own source code editor. Ditto Java.
> ...
>
> > Why should you have to?
> > If you like vi, you ought to just be able to use it.
> > Surely Java development systems
> > don't require you to write your own editor?
>
> I mean to say, if my development environment is an unsigned Java
> applet running on some still popular browser, then my environment
> comes with java.lang.* and java.util.* and java.awt.* and so on ...
>
> ... but no classic source code editor. java.awt.TextArea gives me
> about as much editing as ( hex 1B emit ) gives me in MacOF. Except
> the max bytes per "screen" rises from about 8KiB to 32KiB and I can
> scroll a smaller window thru the "screen".
Then I suggest you look into some of the early Forths with block
editors. They don't use control codes, but instead single-key words
(e.g. I for insert, D for delete, F for find, etc) and are extremely
easy to implement on a platform such as you describe (or OF).
> > > Mac OpenFirmware makes it neither easy nor impossible
> > > to save source files. Ditto Java: an unsigned applet
> > > can save into the public ls -l space
> > > of an ftp incoming/ folder.
> ...
> > Any Forth should be able to provide you access to source.
>
> Eh? Files, even blocks, are optional by Ans? That's Not a Bad Thing?
Since Forth (in contrast to Open Firmware) is intended as a
development system, they either have an intrinsic editor (e.g. the
block editors in early primitive Forths such as I mentioned above)
or run on top of an OS where you can use any standard editor
that comes with it (such as vi). Not cross-platform standard,
but ubiquitous.
> > > I'm thinking OpenFirmware is
> > > a better simulation of a Java applet's sandbox
> > > precisely because it is less capable than GForth.
> ...
> > It isn't "less capable".
> > It has _different_ capabilities,
> > with a specific purpose and focus.
>
> Yes.
>
> > It is not designed as a general-purpose development system.
>
> OF is intentionally incomplete: it's designed to run other code.
>
> Most often that other code is an o.s., but that other code can just as
> well be a simpler application, like emacs or vi.
No, not really. OF is designed to configure the system and
_launch_ an OS, not to run "other code".
> > You will be continually finding your purposes
> > at odds with Open Firmware,
> > as you have described here so far.
>
> Ouch, lost me here, sorry.
>
> How did I say OF was at odds with my purposes?
You're having a terrible time writing your editor, for
example. And the fact that you need to is bad enough.
Cheers,
Elizabeth
Anton Ertl
>> > free (gratis), interactive, personal, programming environments
>> GForth will provide a friendlier platform.
>
>By the GPL, GForth is free in the sense of libre (a la free speech),
>not gratis (a la free beer), per
>http://www.gnu.org/philosophy/categories.html
Since we don't charge a fee for Gforth, it is also gratis, in addition
to being free software. You can download it gratis from any GNU
mirror site. OTOH, Open Firmware is neither gratis nor free.
- 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
Pat LaVarre
> some of the early Forths with block editors.
> They don't use control codes, but instead single-key words
> (e.g. I for insert, D for delete, F for find, etc)
Web links, anyone? The Forth books I have duck this issue with a blah
disclaimer along the lines of "source code editors vary
extraordinarily by system, please go read the fine manual".
> > How did I say OF was at odds with my purposes?
...
> You're having a terrible time writing your editor,
> for example.
Eh? No worries? I'm __learning__, at least til my stunning newbie
ignorance ceases to interest people here. This I do for fun.
For example, by now I've been persuaded that, in Forth, I can more
idiomatically map KEY sequences to strings to be EVALUATE'd, rather
than xt's to be EXECUTE'd, since Ans Forth doesn't offer .NAME and SEE
of an xt. Before, I didn't know that limitation was significant &
relevant.
> And the fact that you need to is bad enough.
This I can't fix, so long as my final development platform remains an
unsigned Java applet.
Pat LaVarre
Stephen J. Bevan
> > And the fact that you need to [write an editor] is bad enough.
>
> This I can't fix, so long as my final development platform remains an
> unsigned Java applet.
I don't really understand why you have to develop on the target
platform or exactly what restrictions this imposes on you. Is it not
possible to use an existing Java editor that can run in an applet, for
example http://anathoth.tripod.com/decaf/decaf.html?
Pat LaVarre
> > snake pit
Let me apologise to everyone for guessing wrongly what the Gnu-correct
way to say what I mean is. I meant to step around the snake pit, not
drag us all into it.
Clearly I failed. I was so violently misunderstood that I was quoted
misleadingly out of context. Ouch, sorry.
Can I hope that the Gnu folk here will volunteer to help me learn the
Gnu-correct way to say what I mean?
Maybe I should say I'm interested by environments that people use
without noticing how they pay for them separately? But that's not
concise.
I can give examples of what I mean.
1) On web browsers: Java .class & .jar files, Java script, ActiveX for
Windows, ... in particular, the Forth's that run as unsigned Java
applets.
2) On Dos & Windows: The x86 asm code without labels accepted as
stdin by the Debug application. Also .bat and .cmd scripts.
3) On Apple computers: The .java files understood by the javac that
appears pre-installed in any MacOS X Terminal. Also `sh` scripts.
Also MacOF scripts.
4) On Linux: The .c .cpp .h files understood by the gcc that often
appears pre-installed. Also `sh` scripts.
If these interpreters of code aren't "free", what are they?
Writing new source code to run in these environments doesn't clearly
obligate me to any further work. But copy-editing GForth Linux/etc.
.c* source code would obligate me at least to read & understand the
GPL, and then seemingly more beyond that.
In this sense, these interpreters of code are "more free" than GForth.
I hear, loud & clear, that I may not speak that truth that way, when
the community includes vocal Gnu folk.
I'm ok with that rule of discourse, if only someone could kindly
explain how I'm supposed to express concisely my greater interest in
these "more free" environments.
I'm most interested in the unsigned Java applet environment, because
it is in this sense "most free". When I write code for that
envrionment, I'm least likely to meet someone who can't run my code
without having to acquire and install some add-on. (Whether my code
works when they run it is a separate issue, known as the "write once
test everywhere" principle.)
I see value in the "as free as free speech" environments also. I'd
like to see GPL'ed code in Linux become the standard for measuring how
in/correctly peripherals talk, because such a standard might be
differently ambiguous than English standards and enduringly public.
But how I may I say that the freedom of free speech isn't the only
kind of freedom that interests me?
Thanks again in advance,
Pat LaVarre
Anton Ertl
>Can I hope that the Gnu folk here will volunteer to help me learn the
>Gnu-correct way to say what I mean?
>If these interpreters of code aren't "free", what are they?
Software that is not free software is proprietary software.
>Writing new source code to run in these environments doesn't clearly
>obligate me to any further work. But copy-editing GForth Linux/etc.
>.c* source code would obligate me at least to read & understand the
>GPL, and then seemingly more beyond that.
>
>In this sense, these interpreters of code are "more free" than GForth.
How about comparing apples to apples?
Writing new source code to run on Gforth does not obligate you to do
any further work. And modifying C source code (I guess that's what
you mean by writing "copy-editing ... .c* source code") of proprietary
software is usually not allowed, and certainly requires reading and
understanding the license of these packages; apart from that, you
often do not get the chance to modify the sources, because they are
not made available to you. If you think that this frees you, maybe
you also think that locking you up frees you, because you no longer
need to consider whether you are trespassing or not when you go
anywhere.
BTW, as it happens, the GPL allows you to modify GPLed source code
(that's one of the programming freedoms that it tries to protect).
>When I write code for that
>envrionment, I'm least likely to meet someone who can't run my code
>without having to acquire and install some add-on.
What you desire seems to be executable portability. This has little
to do with freedom, and much to do with installed base.
Pat LaVarre
> Date: 2002-06-04 16:54:27 PST
...
> I don't really understand
> why you have to develop on the target platform
Is the Forth community not full of people who prefer to develop on the
target platform? Has almost everyone switched over to the two-machine
model?
> or exactly what restrictions this imposes on you.
> Is it not possible to use an existing Java editor
> that can run in an applet, for example
> http://anathoth.tripod.com/decaf/decaf.html
> ?
Thank you for your interest & for the link new to me.
Yes Decaf is written in much the same spirit. I quote: "With Decaf,
you can write, compile, run, run in the appletviewer, and run in your
browser your applets". But that same page continues on, to tell us
Decaf requires the latest JDK, and that Decaf calls javac.
I conclude:
1) Decaf cannot itself compile code when run as unsigned Java applet:
because Decaf calls javac, which an unsigned Java applet may not do.
2) I can't interactively enter Forth to extend the Decaf editor:
instead I have to write Java in a ( begin edit compile execute again )
style, yuck.
3) To run applets, Decaf calls appletviewer.
The appletviewer of the latest JDK is an excellent simulation of the
latest Java browser plug-in from Sun ... and therefore an accordingly
significantly inaccurate simulation of the majority of installed Java
machines, namely those which come installed with Microsoft Internet
Explorer of Win 95/98/ME/2K (but not XP, except for the developer
releases).
> > http://members.aol.com/ppaatt/nqjava/applet/archive.htm
> > [ downloads 89364 bytes of .zip'ped .class'es to run ]
That applet doesn't let you write your own methods, but at least it
does let you ask your browser to evaluate simple fragments of Java.
Try the fragment { "".indexOf("") }, except without the { } curly
braces. If the result you see is 0, then congratulations, you have a
newer Java, and you have escaped my pain. But be aware some people
see -1.
In Forth you can try the analogy ( c-addr1 0 c-addr2 0 SEARCH ). Do
you see ( c-addr1 0 0 ) or ( c-addr1 0 -1 )? I've launched the thread
titled "in Forth, does the empty string contain itself?" to discuss
whether & how Ans Forth bothers to tell us what you should see. (I
think it doesn't.)
> > http://members.aol.com/ppaatt/java/demo/ReflectiveApplet.html
Once upon a time, this applet did print the Html that launched it.
Now this applet claims the Html that launched it was empty, at least
when run on Mac OS X.
Ok, so now let's try to find out why. We have the source:
http://members.aol.com/ppaatt/java/demo/ReflectiveApplet.java
Don't we almost already know the answer?
Not hardly. We have to ( begin edit compile execute again ) til we
can approach an answer. Where do we have to do this? In the target
browser, or a known equivalent.
Doesn't the nqjava applet help? Not directly - it's never been taught
to understand the "new" keyword.
> I don't really understand
> why you have to develop on the target platform
Better now?
I do appreciate the chance to learn how to express clearly why I want
an interactive development environment running on the target platform.
I had thought this desire was taken for granted among Forth folk? I
knew cross-compiling Forth's existed - but I didn't think they were
the norm?
Pat LaVarre
Pat LaVarre
> Date: 2002-06-05 02:30:11 PST
> ...
> What you desire seems to be executable portability.
Thanks again for helping me work thru the Gnu-correct way to say this.
I want my source code to be freely shareable. If I can execute, view,
search, annotate, edit, print the stuff ... then I want you to feel
free to do the same. I feel this way about things I create generally,
not only source code but also .html and .bmp and so on.
I find corporate drones often feel less free to share with me if I
label my stuff with the GPL. For me, whether they are wrong isn't the
point. In actual fact, they share more if I don't label my stuff with
the GPL, so I don't.
Also interesting is the phenomenon of people who mistake GPL to mean
public domain. Those people do advocate & share in GPL work, but only
under a false impression.
> [The freedom to share] has ... much to do with installed base.
Yes. Slippery over time.
> [The freedom to share] has little to do
> with [the] freedom [of free speech],
Yes if you accept the emendations in [square brackets], else you lost
me, sorry, please can you try again.
> Writing new source code to run on Gforth
> does not obligate you to do any further work.
Good to hear, thank you.
I have been thinking of running my code thru Gforth to help make sure
I've sharply distinguished what's distinct to MacOF and what's not.
But I thought I was starting to see GPL-ish licenses appear in web
pages, so that merely reading the Gforth manual (!!) might clearly
obligate me to read & understand the legalese of the licenses and then
thereby obligate me to more beyond that?
I expect SEE'ing into Gforth is a grey area? Am I SEE'ing GPL-ed
source code? SEE doesn't tell me that, does it?
> > > snake pit
...
> > these interpreters of code are "more free" than GForth ...
Is it then Gnu-correct for me to say the freedom to share interests me
more than the freedom to speak? Or do I still invite attack unless I
express this truth in yet some other way?
Curiously yours in stunning newbie ignorance,
Pat LaVarre
Bernd Paysan
> I find corporate drones often feel less free to share with me if I
> label my stuff with the GPL. For me, whether they are wrong isn't the
> point. In actual fact, they share more if I don't label my stuff with
> the GPL, so I don't.
Many corporate drones just don't set the policy of their corporation.
Normally, this policy is "everything we make is secret". If they do share,
they share against their company's policy, but probably nobody cares.
However, with the GPL, it becomes obvious to everyone that sharing is
obligated, and therefore, thumbs go down.
> But I thought I was starting to see GPL-ish licenses appear in web
> pages, so that merely reading the Gforth manual (!!) might clearly
> obligate me to read & understand the legalese of the licenses and then
> thereby obligate me to more beyond that?
No. Like running a GPL'd program, reading a GFDL'd text is always allowed.
The restrictions come when you want to change a GFDL'd text. They are less
restrictive than normal copyright, and for normal web pages, standard
copyright applies. Do you understand the implications of normal copyright
on a web page? Don't forget: You are not allowed to copy copyrighted
material, and the mere act of transfering it to your browser involves
several copy actions (including to caches and that like). Is that allowed?
Are you allowed to save a page?
> I expect SEE'ing into Gforth is a grey area? Am I SEE'ing GPL-ed
> source code? SEE doesn't tell me that, does it?
SEE doesn't know. And no, you don't see source code when you SEE a word. You
see decompiled code. That's different. Source code usually contains
comments and indenting/spacing/line breaks and other format stuff to make
it more readable for the author. With SEE, you just see binary in a
human-readable form. If this is derived from GPL'd source, it's also
covered by the GPL, because it's a derivative work.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Jeff Fox
> > I don't really understand
> > why you have to develop on the target platform
>
> Is the Forth community not full of people who prefer to develop on the
> target platform? Has almost everyone switched over to the two-machine
> model?
No. Yes. If you lurk for a while you can get a feel for the
demographics. On that subject you will be greatly outnumbered here.
best wishes,
Jeff Fox
Stephen J. Bevan
> > From: Stephen J. Bevan (ste...@dino.dnsalias.com)
> > Date: 2002-06-04 16:54:27 PST
> ...
> > I don't really understand
> > why you have to develop on the target platform
>
> Is the Forth community not full of people who prefer to develop on the
> target platform? Has almost everyone switched over to the two-machine
> model?
I don't know. I'll do either, it all depends on what tools are
available. If I have a target envrionment that has all the tools I
want then I'll use it. If it doesn't and I'd have to write my own
(e.g. write an editor), then I'd probably use some sort of
cross-compiler+tether solution.
Albert van der Horst
Pat LaVarre <ppa...@aol.com> wrote:
>Also interesting is the phenomenon of people who mistake GPL to mean
>public domain. Those people do advocate & share in GPL work, but only
>under a false impression.
Actually this is not a false impression. It only is legalistically
speaking.
The GPL captures the essence of what most people want by putting
things in the public domain better than a formal public domain
licence. Remember "public domain" is a legalistic term, and some
people would be surprised with what Microsoft is allowed to do
with things you have put under this licence.
--
Greetings Albert.
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Anton Ertl
>I want my source code to be freely shareable. If I can execute, view,
>search, annotate, edit, print the stuff ... then I want you to feel
>free to do the same. I feel this way about things I create generally,
>not only source code but also .html and .bmp and so on.
If the source code is not derived from anything else (e.g, from
decompiling Open Firmware), you have the copyright on it and can do
with it whatever you want and distribute it under any terms you
please.
>Also interesting is the phenomenon of people who mistake GPL to mean
>public domain. Those people do advocate & share in GPL work, but only
>under a false impression.
I have never encountered such people.
>Yes if you accept the emendations in [square brackets],
Certainly not, if I had meant that, I would have written it.
Executable portability is a convenience issue, not a freedom issue.
However, what you describe above as "freely shareable" are central
ideas of free software. But they have nothing to do with executable
portability.
>But I thought I was starting to see GPL-ish licenses appear in web
>pages, so that merely reading the Gforth manual (!!) might clearly
>obligate me to read & understand the legalese of the licenses and then
>thereby obligate me to more beyond that?
No, you don't need a permission to read (yet; with all the
enhancements of copyright that are proposed in various countries, this
might soon change).
>I expect SEE'ing into Gforth is a grey area? Am I SEE'ing GPL-ed
>source code? SEE doesn't tell me that, does it?
No, SEE does not show source code, it shows decompiled threaded code.
SEE does not tell you the license of the source code that resulted in
that decompiled code.
The GPL says nothing about that (it only covers "copying, distribution
and modification") except that it says: "The act of running the
Program is not restricted". OTOH, your country may have laws
forbidding decompilation (this then applies to all Forth systems,
including Open Firmware).
BTW, you seem to worry about these things a lot. You may save a lot
of time (ours, but also yours) by just reading the GPL instead of
spreading your fear, uncertainty, and doubt.
J E Thomas
> > From: Elizabeth D. Rather (era...@forth.com)
> > KEY can _only_ produce a single 7-bit ASCII value.
> Eh? Sez who? (Because you're Elizabeth, I know you know, but I
> don't get it, not yet. I see no rationale links for KEY. I went
> looking for explicit permission to delay all KEY results til
> Return/Enter was pressed, but I didn't find it.)
The standard says that KEY accepts all standard characters, and those
happen to be 7-bit ASCII values. Anything that isn't a 7-bit ASCII
value is supposed to be discarded if KEY gets it.
This means if what you're looking for is in the 20-7E range, you can use
KEY and not worry about what to do if you get something else. But if
you *want* something else you're supposed to use EKEY to get it.
> In MacOF, I have only KEY. I don't have EKEY. I could build an
> EKEY, but only by getting into undocumented distinctions between
> legacy ADB keyboards, USB keyboards, etc. etc.
How does it detect control keys etc? If it can't, you're out of luck.
If it can, you can build an EKEY provided you want to. But EKEY is
supposed to return a single cell. If what you actually get is a
sequence of bytes, maybe you'd be better off to do something
nonstandard. EKEY might help you put the nonstandard part all in one
place. Like, (to make an impractical example that shows the idea) if
you could have one table with all the actions in it, then later to port
your code to something where EKEY gave completely different values you
could rearrange the table.
Pat LaVarre
> Date: 2002-06-09 10:50:04 PST
> ...
> In MacOF, I have only KEY.
In MacOF, the implementation-defined char set received by KEY seems to
be x00..7E, not just x20..7E.
Specifically, if I leave Control pressed while I press some other KEY,
I get ( KEY HEX 1F AND ). For example, Control+` is HEX 00 because (
HEX 60 EMIT ) is `. And Ctrl+? is HEX 1F because ( HEX 3F EMIT ) is
?.
Do I understand correctly that you do know of an actual Forth whose
KEY input is only x20..7E: a Forth at that extreme of the freedom in
implementing KEY that the 1994 Ans allows to a Forth system?
> > > KEY can _only_ produce a single 7-bit ASCII value.
> > Eh? Sez who?
> ...
> The standard says that KEY accepts
> all standard characters,
> and those happen to be 7-bit ASCII values.
Maybe that was the thinking - but that's not the standard.
In Elizabeth's words:
> > on a system with 16-bit chars,
> > may KEY fetch and may EMIT store x0000..FFFF?
...
> From: Elizabeth D. Rather (era...@forth.com)
> Date: 2002-06-01 13:48:03 PST
> ... In theory, yes.
> Many programs in existence have a dependency on
> 1 byte = 1 char = 1 address unit, however.
And now again direct from:
http://www.forth.org/dpans/dpans6.htm#6.1.1750
"KEY ( -- char )
"Receive one character char, a member of the implementation-defined
character set. Keyboard events that do not correspond to such
characters are discarded until a valid character is received, and
those events are subsequently unavailable.
"All standard characters can be received. Characters received by KEY
are not displayed.
"Any standard character returned by KEY has the numeric value
specified in 3.1.2.1 Graphic characters. Programs that require the
ability to receive control characters have an environmental
dependency.
Pat LaVarre
h-peter recktenwald
J E Thomas <j2th...@swbell.net> wrote:
> Pat LaVarre wrote:
> > > From: Elizabeth D. Rather (era...@forth.com)
>
> > > KEY can _only_ produce a single 7-bit ASCII value.
>
> > Eh? Sez who? (Because you're Elizabeth, I know you know, but I
> > don't get it, not yet. I see no rationale links for KEY. I went
> > looking for explicit permission to delay all KEY results til
> > Return/Enter was pressed, but I didn't find it.)
>
> The standard says that KEY accepts all standard characters, and those
> happen to be 7-bit ASCII values.
which is true
> Anything that isn't a 7-bit ASCII value is supposed to be discarded if KEY gets it.
which is not:
6.1.1750 KEY CORE
( -- char )
Receive one character char, a member of the implementation-defined
character set. Keyboard events that do not correspond to such
characters are discarded until a valid character is received, and those
events are subsequently unavailable.
All standard characters can be received. Characters received by KEY are
not displayed.
Any standard character returned by KEY has the numeric value specified
in 3.1.2.1 Graphic characters. Programs that require the ability to
receive control characters have an environmental dependency.
>
> This means if what you're looking for is in the 20-7E range, you can use
> KEY and not worry about what to do if you get something else. But if
> you *want* something else you're supposed to use EKEY to get it.
>
> > In MacOF, I have only KEY. I don't have EKEY. I could build an
> > EKEY, but only by getting into undocumented distinctions between
> > legacy ADB keyboards, USB keyboards, etc. etc.
>
> How does it detect control keys etc? If it can't, you're out of luck.
> If it can, you can build an EKEY provided you want to. But EKEY is
> supposed to return a single cell. If what you actually get is a
> sequence of bytes, maybe you'd be better off to do something
> nonstandard. EKEY might help you put the nonstandard part all in one
> place. Like, (to make an impractical example that shows the idea) if
> you could have one table with all the actions in it, then later to port
> your code to something where EKEY gave completely different values you
> could rearrange the table.
--
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
NO abusive software patents http://petition.eurolinux.org/pr/pr17.html
Coos Haak
Pat LaVarre <ppa...@aol.com> schreef in berichtnieuws
2695edf1.02061...@posting.google.com...
> > From: J E Thomas (j2th...@swbell.net)
> > Date: 2002-06-09 10:50:04 PST
> > ...
> > In MacOF, I have only KEY.
> > ... How does it detect control keys etc?
>
> In MacOF, the implementation-defined char set received by KEY seems to
> be x00..7E, not just x20..7E.
>
> Specifically, if I leave Control pressed while I press some other KEY,
> I get ( KEY HEX 1F AND ). For example, Control+` is HEX 00 because (
> HEX 60 EMIT ) is `. And Ctrl+? is HEX 1F because ( HEX 3F EMIT ) is
> ?.
I know that a Mac is a PC of sorts, but my PC does not allow ^' nor ^?
The only control characters that may be keyed in are:
^@ (00, although with some pain)
^A..^Z (01..1A, maybe lowercase),
^[ (1B) ^\ (1C) ^] (1D) ^^ (1E) and ^_ (1F)
Coos Haak
p.s.
KEY 1F AND produces control characters from normal keypresses.
That's always standard.
J E Thomas
> J E Thomas <j2th...@swbell.net> wrote:
> > Pat LaVarre wrote:
> > > From: Elizabeth D. Rather (era...@forth.com)
> > > > KEY can _only_ produce a single 7-bit ASCII value.
> > > Eh? Sez who?
> > The standard says that KEY accepts all standard characters, and
> > those happen to be 7-bit ASCII values.
> which is true
> > Anything that isn't a 7-bit ASCII value is supposed to be
> > discarded if KEY gets it.
> which is not:
Oops! You're right. I'm sorry, I didn't review carefully enough.
OK, an implementation can let KEY return whatever it wants, provided
what it returns fits into a single cell on the stack. A portable
program can't depend on using KEY for anything but 32-126, and things
outside that range might get discarded.
So if you intend to write a portable program you can do EKEY and then
EKEY>CHAR . If you get a valid character you can use it. If you get
something else, you can do something nonportable with it. At least the
nonportable part will be concentrated in that one place. EKEY was
intended to allow implementors to pick up mouse events etc, it might
possibly even return the address of an extended array of data.
So a Forth implementor can have KEY work for as many events as he likes,
up to MAX-U of them. And an application programmer who isn't concerned
about portability can use KEY that way. The extended character things
will have to be rewritten if he ports his application, but they needn't
be harder to find than they would be if they were all on one side of an
IF .
Pat LaVarre
> > interactive, personal, programming environments
Here above you see my latest guess at Gnu-correct English for what I
mean. Have I got it right yet?
> From: Anton Ertl (an...@mips.complang.tuwien.ac.at)
> Date: 2002-06-08 00:51:20 PST
> ...
> BTW, you seem to worry about these things a lot.
Eh?
I'm just frustrated by losing my applet Forth thread in this snake
pit.
I know what I mean when I say "free ... interactive, personal,
programming environments", because I know one when I see one. I gave
the examples of Java applets, C source in Linux, Java source in Mac OS
X, debug source in Dos & Windows, ...
But on Usenet I know I'm not permitted to use the word "free" to
describe how these environments differ from GForth & friends. Gnu
folk have a deep history with the word "free", & they jump up and
object to anyone using it differently.
For example, we began with:
> you go and ... gets wierd)
And later we see:
> Executable portability is a convenience issue,
> not a freedom issue.
And elsewhere we see:
> > if you accept the emendations ...,
> > else you lost me, sorry, ...
...
> Certainly not, if I had meant that,
> I would have written it.
And finally we see:
> spreading your fear, uncertainty, and doubt.
I give, I surrender, I don't mean to be challenging anyone. I know
now to avoid the words "free", "gratis", and "freedom", among others.
But then I do need permission to use some other English to say what I
mean.
> I want my source code to be freely shareable.
> If I can execute, view, search, annotate, edit,
> print the stuff ... then I want you to feel free
> to do the same.
This is what I mean - is it not clear?
Our only issue is that, among Gnu folk, I'm not permitted to use the
words "freely shareable" to mean this?
Maybe the difference with GForth is that these other programming
environments don't walk me thru a licensing procedure every time I
launch them?
To download GForth or anything other licensed thing, such as the
"free" Java from Sun, I have to agree to a license? Naturally I
prefer a no-button install over a one-button install. And GForth then
reminds me of the one-button every time it launches.
> > http://www.gnu.org/licenses/gpl.html
...
> just reading the GPL
Yes I have read the GPL, over the years, time and again. No I don't
feel competent to interpret its legal American English. Outside the
Gnu community, I hear the GPL understood in a nutshell as a
self-propagating license: a legal virus.
On the other hand, I see people sell Linux systems that run not GPL'ed
code in order to boot, and I don't really understand why that's not a
GPL violation. Maybe you can easily explain how to properly include
not-GPL'ed code in a GForth boot?
What I'm trying to focus on here is how to explain that while I'd be
happy to use a GForth that ran as an unsigned Java applet, I'd not be
comfortable porting GForth to that environment myself.
I'm personally more comfortable with the fuzzy situation that arises
when people just share knowledge freely.
Maybe the Gnu folk are trying to tell me that's a dangerous delusion?
Maybe Gnu folk feel they cannot in good conscience let me continue to
mostly ignore the snake pit?
> From: Bernd Paysan (bernd....@gmx.de)
> Date: 2002-06-05 09:00:24 PST
...
> From: Albert van der Horst (alb...@spenarnc.xs4all.nl)
> Date: 2002-06-06 15:31:25 PST
Also enlightenting, thank you again.
> > free (unlicensed),
> > interactive, personal, programming environments
Here now is my latest guess at Gnu-correct English for what I mean.
Have I got it right yet? Or does this English remain an invitation
for attack?
Curiously yours in stunning newbie ignorance, thanks in advance,
Pat LaVarre
Pat LaVarre
> ... OK,
Helpful summary, thank you.
> ..., an implementation can let KEY return whatever it wants,
> provided what it returns fits into a single cell on the stack.
The Ans rule is just slightly tighter than this, yes? The value
returned has to fit inside a char? [[[I tried to say this once before
as the claim that ( addr C! addr C@ ) shouldn't alter the value,
someone replied to explain my English was unclear, and then we never
finished that digression.]]]
> A portable program can't depend on using KEY
> for anything but 32-126, and things
> outside that range might get discarded.
I think I read that Forth KEY may or may not lose keys outside of
x20..7E printable Ascii, but EMIT of x20..7E has to produce US Ascii
(i.e. the x20..7E of UTF-8 Unicode), except that EMIT of x24 may
produce something other than the '$' US currency symbol.
Pat LaVarre
Pat LaVarre
> Date: 2002-06-10 15:34:05 PST
> ...
> KEY 1F AND produces control characters from normal keypresses.
> That's always standard.
Some people use HEX 40 XOR, in particular `vi`, `emacs`, and other
classic Unix display engines. Over the domain of x20..7E, the
difference is that you can reach x7F as HEX 3F 40 XOR, whereas 1F AND
of x20..7E only lets you reach x00..1F.
> ... my PC ... The only control characters
> that may be keyed in ... 00..1F
Same in MacOF. But this is broken by design, not by necessity. The
keyboard itself produces more codes. For example, deep inside, the
software does know the difference between Shift+/? and
Control+Shift+/?.
Myself, originally I missed the right Ans Forth gives to have KEY
provide only x00..7E as input, and never x7F.
MacOF exercises this right fully by having its Backspace key always
produce the code x08 = char H hex 40 xor. Using only the keyboard,
you cannot produce the code x7F.
Deep inside, MacOF stores the code x08 twice, once as the meaning of
Backspace, then again as the meaning of Shift+Backspace. If you find
and patch this cell, then you find suddenly you can input the code
x7F.
Mac folk might like me to explain, by "Backspace" I mean the wide key
in the upper right that conventionally means delete-backward-char.
Apple labels this key "delete".
> ... I know that a Mac is a PC of sorts, ...
Yes, a Mac is a personal computer sold by Apple Computer to such niche
markets as programmers e.g. nowadays Java & Unix come built-in, and a
virtual PC is a US$100 add-on from Connectix.
I'm told Mac folk often reserve the term "PC" to mean an
IBM-compatible.
Pat LaVarre
Pat LaVarre
> From: Elizabeth D. Rather (era...@forth.com)
> Date: 2002-06-02 11:42:02 PST
> Subject: Re: OpenFirmware $CALL-METHOD isn't really about OOP?
> ...
> Ok, I'll try.
I hope you don't regret trying ...
> You need to get the "big picture".
Vital, aye. But where from & how? Maybe the OOP of OF, built for one
purpose, serves another equally well ... just as the COUNT of Ans
Forth, built for one purpose, serves another equally well?
We have virtual method dispatch. We have instance variables. What
else do we need?
> > (I like to work with a real system for awhile before I let
> > the written standard distort my perspective.)
...
> From: Elizabeth D. Rather (era...@forth.com)
> Date: 2002-06-02 11:42:02 PST
> ...
> You have _no_ useful perspective
> without knowing the purpose of the system under study,
How then do we stumble into insights like:
: type ( c-addr n -- ) 0 ?do count emit loop drop ;
I missed this idiom myself at first, at least in part because I read
the Ans Forth reference manual too soon.
> > http://www.jwdt.com/~paysan/html/gforth.html
> > http://www.forth.org/dpans/dpansf.htm
> > http://www.forth.org/dpans/dpans6.htm#6.1.0980
> > COUNT ( c-addr1 -- c-addr2 u )
> > Return the character string specification
> > for the counted string stored at c-addr1.
Wrong. If we say ( CHAR+ DUP C@ ) means C@ after CHAR+, then we can
say COUNT means C@ before CHAR+ (e.g. DUP CHAR+ SWAP C@ ).
Yes, yes, if a c-addr happens to point to a counted string, then aye
truly fetch-then-increment of that c-addr produces a char string spec.
But conversion from counted to char string is just the etymology, not
the whole meaning.
Anybody here know anybody who could/ would/ should get this explained
in the COUNT rationale of Ans Forth 2003?
> > because I read the reference manual too soon
Maybe I should also admit ...
Myself I fell into abusing BOUNDS where I could COUNT, into an
unnecessary dependency on CHAR+ being 1+, because I saw BOUNDS in use
in the real world and on the web without deprecation e.g.
http://home.earthlink.net/~neilbawd/toolbelt.html#BOUNDS
http://members.aol.com/plforth/moforth/2002/5/18/cat.of.txt
> > 1992 Forth: The New Model, by Jack J. Woehr
> > http://www.amazon.com/exec/obidos/ASIN/1558512772
Maybe I should also admit ...
Here I cheated on the "can you do anything useful with free stuff"
challenge. I borrowed hardcopy from a friend who paid real money for
it.
I just noticed now that thru that link shown you can reach a merged
copy of both of Amazon's Forth book lists: both "FORTH (Computer
program langua" and also "Forth (Programming Language)", but together.
Sorting by publication date puts "Forth: The New Model" at the top,
but with an "Out of Print--Limited Availability" tag and a used price
of around US$100.
Pat LaVarre
Bernd Paysan
> Maybe the difference with GForth is that these other programming
> environments don't walk me thru a licensing procedure every time I
> launch them?
>
> To download GForth or anything other licensed thing, such as the
> "free" Java from Sun, I have to agree to a license? Naturally I
> prefer a no-button install over a one-button install. And GForth then
> reminds me of the one-button every time it launches.
You don't have to agree to the GPL if you just launch Gforth. The two line
startup message it prints is the standard startup message the FSF
recommends for all interactive programs. E.g. if you start gnugo, you get
"This is GNU GO, a Go program. Contact gn...@gnu.org, or see
http://www.gnu.org/software/gnugo/ for more information.
Copyright 1999 by the Free Software Foundation.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation - version 2.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License in file COPYING
for more details.
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111, USA"
If you start gcc, you get nothing, because gcc is a batch-mode program. If
you start gforth in batch mode (i.e. with -e "bla bla bye"), you also get
nothing.
> Yes I have read the GPL, over the years, time and again. No I don't
> feel competent to interpret its legal American English. Outside the
> Gnu community, I hear the GPL understood in a nutshell as a
> self-propagating license: a legal virus.
This is exactly what Anton means with "FUD". Microsoft's EULA doesn't allow
you to modify or copy or look at their code at all. GPL allows it, but has
some conditions that basically ensure that you can't mix GPL with
Microsoft-like licenses.
You also worry a lot about GPL, while GPL does not put any restrictions on
mere use. It opens up a lot of possibilities to distribute derivated works,
which would not legally exist if you don't accept the license (because they
are prohibited by copyright). That's why you have to accept the license: It
grands you some rights you otherwise don't have.
> On the other hand, I see people sell Linux systems that run not GPL'ed
> code in order to boot, and I don't really understand why that's not a
> GPL violation. Maybe you can easily explain how to properly include
> not-GPL'ed code in a GForth boot?
Ship as source. Look, Gforth's image format is just a convenience, because
it starts faster. The only thing you can hide by compiling Forth to the
image format are comments, because you still can SEE the compiled words.
That's the same work an obfuscater does. So just ship source (if you like,
obfuscated), and let the user create an image for faster startup (that's
mere use, so that's allowed).
If you really want total free flow of information, I urge you to put your
sources into public domain. Just do it, and you'll never have to think
about GPL compatibility again, because public domain is GPL-compatible.
> Maybe the Gnu folk are trying to tell me that's a dangerous delusion?
> Maybe Gnu folk feel they cannot in good conscience let me continue to
> mostly ignore the snake pit?
The snake pit are commercial licenses. Did you ever read an EULA? You better
should. Some of them (like the FrontPage one) even sais that you aren't
allowed to express negative statements about Microsoft. Others (like parts
of the .NET license) disallow to creage GPL'd software with it. That looks
like a snake pit, smells like a snake pit, and probably is a snake pit.
They are forcing other people into specific licenses, even if there's no
copyright relationship between their work and other people's work (my
sources are my sources, whatever tool they will compile on, and whatever
editor I used to create them - Microsoft simply can't deny me the right to
ship my sources under GPL, even if they want to).
I feel a bit tired about arguing about the GPL. It's me, the author, who
chooses the license. If you don't like it, because you want to choose
another license for your code (which is incompatible with my license),
don't argue. Why should you have a right to demand which license I
generally should use, but at the same time deny me the right to demand
which license you should use under very specific and narrow conditions (the
desire to ship a Gforth image without sources, which is clearly a right
that I have to give you, because copyright doesn't allow it at all - can't
you just take the right I give you as is, without complaining? It's a gift,
after all!)?
Gary Chanson
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:2695edf1.02061...@posting.google.com...
>
> Yes, a Mac is a personal computer sold by Apple Computer to such niche
> markets as programmers e.g. nowadays Java & Unix come built-in, and a
> virtual PC is a US$100 add-on from Connectix.
>
> I'm told Mac folk often reserve the term "PC" to mean an
> IBM-compatible.
In common usage, "Personal Computer" can refer to a Mac, but "PC" refers
to an IBM-compatible.
--
-GJC
-gch...@TheWorld.com
-War is the last resort of the incompetent.
J E Thomas
> > From: J E Thomas (j2th...@swbell.net)
> > ..., an implementation can let KEY return whatever it wants,
> > provided what it returns fits into a single cell on the stack.
> The Ans rule is just slightly tighter than this, yes? The value
> returned has to fit inside a char?
That's a reasonable interpretation. The stack diagram (which they said
was supposed to be non-normative, but still...) says it returns a
"char".
But look at it this way. When the implementation returns things that
are outside the standard, does the standard say what happens to them if
you use C! ? It seems to me that if an implementor chooses to include
extra keystrokes that don't fit into a char, he can. And then it's your
lookout what you do with them.
This leads to the result that a completely standard program has
undefined results if you enter a key outside 20-7E. That sounds bad at
first, but of course it needs to be true. We can't require that Forth
programs decide what will happen if you press Alt-Tab or Cntl-Alt-Del.
> > A portable program can't depend on using KEY
> > for anything but 32-126, and things
> > outside that range might get discarded.
> I think I read that Forth KEY may or may not lose keys outside of
> x20..7E printable Ascii, but EMIT of x20..7E has to produce US Ascii
> (i.e. the x20..7E of UTF-8 Unicode), except that EMIT of x24 may
> produce something other than the '$' US currency symbol.
It's the same kind of thing. KEY is required to be dependable for
20-7E. EMIT is required to be dependable for 20-7E. Outside that range
the standard doesn't standardise. So an implementation can display
Unicode (at least one has) because it includes the right results for
20-7E. Or an implementation can display UTF similarly, for UTF codes
that can fit into a cell. I suppose EMIT could even check that inputs
within a certain range are addresses, and find longer strings at those
addresses to display.
I guess if you want to make sure a standard Forth program will run
correctly no matter what the user does, you could start by giving the
user a keyboard with only 20-7E on it. 8-)
a...@redhat.invalid
> Yes I have read the GPL, over the years, time and again. No I don't
> feel competent to interpret its legal American English. Outside the
> Gnu community, I hear the GPL understood in a nutshell as a
> self-propagating license: a legal virus.
> On the other hand, I see people sell Linux systems that run not GPL'ed
> code in order to boot, and I don't really understand why that's not a
> GPL violation.
Firstly, the Linux kernel is licensed with an exemption for
binary-only modules.
Secondly, if the boot code is not linked with the kernel and includes
no kernel code it's not a derived work.
> I'm personally more comfortable with the fuzzy situation that arises
> when people just share knowledge freely.
> Maybe the Gnu folk are trying to tell me that's a dangerous delusion?
The great advantage of the GPL is that it's clear beforehand what the
deal is. Too often people don't realize that if you don't receieve an
explicit clear licence upfront you're more likely to get involved with
lawyers if you want to use some code, not less.
In particular, anyone who distributes code, even in the public domain,
is well advised to state what they consider to be the limits of their
liability.
> Maybe Gnu folk feel they cannot in good conscience let me continue to
> mostly ignore the snake pit?
Your call.
Andrew.
J E Thomas
> > > COUNT ( c-addr1 -- c-addr2 u )
> > > Return the character string specification
> > > for the counted string stored at c-addr1.
> Wrong. If we say ( CHAR+ DUP C@ ) means C@ after CHAR+, then we can
> say COUNT means C@ before CHAR+ (e.g. DUP CHAR+ SWAP C@ ).
> Yes, yes, if a c-addr happens to point to a counted string, then aye
> truly fetch-then-increment of that c-addr produces a char string
> spec. But conversion from counted to char string is just the
> etymology, not the whole meaning.
You have of course missed the debate about this.
Remember that commercial Forth systems get used worldwide for important
purposes, and the standard label is worth money to them. Worldwide.
Chinese etc.
Traditional Forth systems worked just as you describe. When a character
takes up one byte, then you're limited to 127 character counted
strings. But if you want longer counted strings you might want to have
a 2-byte count, or a cell-size count. Then COUNT won't work on regular
characters unless they're all the same size as the count at the
beginning.
You might even have a registry of strings, where you have a token that
uniquely represents a particular string and COUNT gives you an address
and length. There's nothing in the standard that says a counted string
has to have the form {count-byte string}.
For chinese displays you might want UTF codes that have a variable
number of bytes per character. How do you tell which is the third
character when the first two have undetermined size? You don't need to,
TYPE will print out what the final user needs to see. You don't need to
byte through their chinese strings nearly as much as they need to
display them unchanged. So the argument was that COUNT does just what
its definition says. Given an address that somehow represents a string,
COUNT will return an address that actually does point to the beginning
of a string, and a length.
Some people have suggested using the name C@+ to stand for the
traditional behavior of COUNT . If you do that then it's natural to
also use @+ to stand for the traditional behavior of OUNT .
a...@redhat.invalid
> Yes I have read the GPL, over the years, time and again. No I don't
> feel competent to interpret its legal American English. Outside the
> Gnu community, I hear the GPL understood in a nutshell as a
> self-propagating license: a legal virus.
> On the other hand, I see people sell Linux systems that run not GPL'ed
> code in order to boot, and I don't really understand why that's not a
> GPL violation.
Firstly, Linus has stated that proprietary device drivers that use the
normal driver/kernel interfaces are OK.
Secondly, if the boot code is not linked with the kernel and includes
no kernel code it's not a derived work.
> I'm personally more comfortable with the fuzzy situation that arises
> when people just share knowledge freely.
> Maybe the Gnu folk are trying to tell me that's a dangerous delusion?
The great advantage of the GPL is that it's clear beforehand what the
deal is. Too often people don't realize that if you don't receieve an
explicit clear licence upfront you're more likely to get involved with
lawyers if you want to use some code, not less.
In particular, anyone who distributes code, even in the public domain,
is well advised to state what they consider to be the limits of their
liability.
> Maybe Gnu folk feel they cannot in good conscience let me continue to
> mostly ignore the snake pit?
Your call.
Andrew.
Pat LaVarre
...> Date: 2002-06-11 08:51:04 PST
> ... reasonable
So far so good.
> > http://www.forth.org/dpans/dpans6.htm#6.1.1750
> stack ... non-normative, but still...
With KEY we have normative text written in terms of the stack diagram?
I quote: "Receive one character char".
> a completely standard program has undefined results
> if you enter a key outside 20-7E ... needs to be true.
Fun thinking new to me thank you, by the way, but seriously ...
Undefined results, aye. But COMPLETELY undefined results? Ans
doesn't bother to say that a person typing outside of x20..7E thereby
creates "an ambiguous condition".
Is it reasonable to think that ( KEY DUP addr C! addr C@ = ) ought to
produce ( -1 ) always? Or should I continue as I began: in my newbie
ignorance, I had been writing ( KEY HEX 7F AND ) ...
Thus, outside of x00..7F, my code perhaps confusingly behaves as if
x00..7F has been input. I suppose I was thinking that input is by
definition typically highly structured but observably random til
explicitly transformed.
> EMIT is required to be dependable for 20-7E.
> Outside that range the standard doesn't standardise.
Aye, also fun.
Using ( HEX 0D EMIT 0A EMIT ) to mean CR involves an environmental
dependency as sure, though maybe less commonly troublesome, as the (
0C EMIT ) which is PAGE on MacOF (x0C is FormFeed in Ascii) and the (
0B EMIT ) which is undo-LF there (x0B is VerticalTab in Ascii).
Thanks again,
Pat LaVarre
Pat LaVarre
> where you have a token that uniquely represents
> a particular string and COUNT gives you an address and length.
> There's nothing in the standard that says a counted string
> has to have the form {count-byte string}
Whoa. Indeed There Was something in the standard I read:
http://www.forth.org/dpans/dpans2.htm#2.1
"counted string:
"A data structure consisting of one character containing a length
followed by zero or more contiguous data characters. Normally, counted
strings contain text.
That is, the 1994 Ans standard does require the form to be {
count-char string }. We need to know this for such purposes as
building our own counted string to pass to FIND.
Do you mean to be telling me Forth folk who work with Chinese chars
are advocating that the next Forth standard relax this restriction?
> ... Chinese ... UTF codes
> ... variable number of bytes per character
Yes the UTF-8 of http://www.unicode.org/charts/ gives us one OR MORE
bytes per char if we mix chars inside and outside of x00..7F. Much of
Greek appears as two bytes per char, much of Cyrillic as three.
Yes, even if we allot two bytes per char a la Java, still UTF-16 gives
us two OR MORE bytes per char if we mix chars inside and outside of
x0000..FFFF, e.g. to represent x1D11E musical-symbol-g-clef.
: type ( c-addr n -- ) 0 ?do xyz emit loop drop ;
Therefore, given a system where C@ fetches a byte, if we want this
definition of TYPE to work with a UTF-8 encoded string, then yes we
have to make XYZ fetch and step over a variable count of bytes.
For example, we'd want XYZ to fetch and step over the two bytes x C3
BF in order to emit xFF Latin-small-letter-y-with-diaeresis.
> the argument was that COUNT does just what its definition says.
Which definition?
Are you saying that COUNT may or may not be XYZ? Do you mean to be
saying the standard shouldn't promise me that COUNT produces the same
result as ( DUP CHAR+ SWAP C@ )?
As of 1994, I think the standard does promise this:
http://www.forth.org/dpans/dpans6.htm#6.1.0980
"6.1.0980 COUNT ( c-addr1 -- c-addr2 u )
"Return the character string specification for the counted string
stored at c-addr1. c-addr2 is the address of the first character after
c-addr1. u is the contents of the character at c-addr1, which is the
length in characters of the string at c-addr2.
I'm only saying I find the first sentence misleading. I'd say that
sentence reads like normative text - but it is merely rationale. The
normative text which follows makes that clear.
> the argument was that COUNT does just what its definition says.
Are you saying that Forth folk somewhere favour the first sentence
over the two that follow? You do know of COUNT implementations which
produce different results than ( DUP CHAR+ SWAP C@ )?
> > http://www.complang.tuwien.ac.at/forth/optimization.html
> > http://www.complang.tuwien.ac.at/forth/ansforth/proposals.html
> You have of course missed the debate about this.
> C@+ ... @+ ... tradition... OUNT
Thanks for the tip, it led me to the links shown.
I trust the tradition we mean is equivalent to:
: C@+ ( c-addr1 -- c-addr2 u ) DUP CHAR+ SWAP C@ ;
: @+ ( c-addr1 -- c-addr2 u ) DUP CELL+ SWAP @ ;
Pat LaVarre
Pat LaVarre
> > > interactive, personal, programming environments
>
> Here now is my latest guess at Gnu-correct English for what I mean.
> Have I got it right yet?
> Or does this English remain an invitation for attack?
Hey this is looking good.
Three replies, but no quotes of this main point of mine, and no
repetition of such seemingly please-shut-up remarks as "weird",
"Certainly not", "spreading your" FUD, and "I have never encountered
such".
With this much encouragement on the table, here forward I'll try to
remember to say "free (unlicensed)", and we'll see if people drag us
all into the snake pit less often than if I said "free" or "free
(gratis)" or ...
> If you really want total free flow of information,
Yes. "I want my source code to be freely shareable. If I can
execute, view, search, annotate, edit, print the stuff ... then I want
you to feel free to do the same."
> I urge you to put your sources into public domain.
Thank you ... but "public domain" is another legal term I don't feel
competent to interpret. For example, do I have a right to disclaim
the community property rights of my alien spouse?
I remain personally "more comfortable with the fuzzy situation that
arises when people just share knowledge freely".
> Too often people don't realize that
> if you don't receieve an explicit clear licence up front
> you're more likely to get involved with lawyers
> if you want to use some code, not less.
I'm guessing in the USA I'm reasonably safe so long as I don't ever
make any real money, and, as of the DMCA, I also refrain from exposing
the technical weaknesses of copy-protection schemes. If ever I made
some real money, then some of it would go as tribute to one lawyer to
defend me against others, sure.
> The great advantage of the GPL
> is that it's clear beforehand what the deal is.
Not to someone as stunningly ignorant of American law as Me.
> GPL does not put any restrictions on mere use.
Provided "mere use" does not involve the SEE of Gforth, etc.
> I feel a bit tired about arguing about the GPL.
1) Would be nice if gnu.org more directly answered what not Gnu folk
say about the GPL e.g. I wish I had found a link to tell me I must say
"free (unlicensed)", rather than "free (gratis)" when speaking to Gnu
folk.
2) Trust me, I was already tired of being attacked on Usenet for
saying "free" before ever I inadvertently invited that first attack.
In real life, I can say "free", and the other people in the
conversation clearly make an effort to understand what I mean, seeing
that I've discourteously failed to work out what I mean in detail in
advance.
I'm grateful to see this same polite convention working on Usenet when
I speak on entirely technical topics, but as soon as I explain I
prefer free (unlicensed) source, people drag me into the snake pit.
> Gforth ... It's a gift, after all!)?
I'm willing to work with anyone kind enough to volunteer to help me
learn the language I must speak here precisely because I greatly value
the public contributions of Gnu folk.
For example, I've personally arranged to donate hardware to support
Linux development.
And among my own web pages I link to the delightfully illuminating:
http://www.jwdt.com/~paysan/html/gforth.html
And so on.
Yes indisputably Gforth is a wonderful gift, thank you all.
I'm just saying Gforth is not all things to all people. Some people
value the freedom of free speech more highly, other people value more
highly the different freedom of unlicensed source.
http://members.aol.com/plforth/ofpong/index.html
is an example where I modified some unlicensed source and posted my
modifications.
http://gear.torque.net/sg/p/sg_v3_ho.html#PEXAMPLE
is an example where I haven't yet posted my corrections in part
because I'm unsure of how to deal with its "copyright":
Copyright (C) 2001 D. Gilbert
This program is free software. Version 1.01 (20020226)
In tweaking Pong to run on newer Mac's did I violate a copyright?
Maybe yes, maybe no. Nobody's complained to me yet.
The original source code had no copyright notice, neither does my
modified version. The original source code had no author's signature,
neither does my modified version.
The only indications we have of authorship are well-buried. From the
source, I quote:
http://members.aol.com/plforth/ofpong/20020313/ofpong.txt
\ \ See also http://members.aol.com/plforth/ofpong/index.html
...
\ \ To construct this file, we modified a copy of the
\ \ 1.0d1 MacHack '98 release of OFPong.of found in OFPONG.SIT.
\ \
\ \ 1) We copied the text into a SimpleText file, so that `boot`
\ \ knows it can read the text. (The original was a BBEdit file.)
\ \ To let us edit this in Mac OS X, we had to tell TextEdit to
\ \ make this a plain text file, not an Rtf text file.
\ \
\ \ 2) We commented out the source code below that begins with \.
\ \
\ \ 3) We added the source below that ends with \.
\ \
\ \ 4) We added the comments you see here that begin with \ \.
We then have to visit the index.html to discover that .SIT compressed
folder contained:
http://members.aol.com/plforth/ofpong/OFPong1.0d1/OFPongReadMe.txt
The OFPongReadMe text doesn't quite say but strongly suggests the
author of the first version was:
Marcus Jager Quinn -The Eskimo!- Late Night Silly Software
> > > free (unlicensed),
> > > interactive, personal, programming environments
>
> Here now is my latest guess at Gnu-correct English for what I mean.
> Have I got it right yet?
> Or does this English remain an invitation for attack?
Thanks again everyone,
Pat LaVarre
Bernd Paysan
>> > > free (unlicensed),
>> > > interactive, personal, programming environments
>>
>> Here now is my latest guess at Gnu-correct English for what I mean.
>> Have I got it right yet?
>> Or does this English remain an invitation for attack?
>
> Hey this is looking good.
>
> Three replies, but no quotes of this main point of mine, and no
> repetition of such seemingly please-shut-up remarks as "weird",
> "Certainly not", "spreading your" FUD, and "I have never encountered
> such".
"unlicensed" looks problematic to me. If you don't have a license, you have
ordinary copyright, which severely restricts your rights - it actually
grants a monopoly to the copyright holder on a number of things. Therefore,
you have to have either a license, or the formerly copyrighted code must be
in the "public domain" (which tells you that nobody claims ownership). Is
the latter what you mean with "unlicensed" - you can use it without needing
a license? "unlicensed" could also mean then you don't have a license for
what you do - and "free" in this case would be more like in "freebooter"
(i.e. "pirate").
> With this much encouragement on the table, here forward I'll try to
> remember to say "free (unlicensed)", and we'll see if people drag us
> all into the snake pit less often than if I said "free" or "free
> (gratis)" or ...
"Free" is a bit troublesome in English. In German, "Freie Software" is
pretty clear, because if it was just gratis, it would be "Freisoftware"
like "Freibier" (free beer). Also, in French "logiciel libre" clearly
distinguishs that from a possible price tag.
> I remain personally "more comfortable with the fuzzy situation that
> arises when people just share knowledge freely".
So you personally prefer ignorance about a problematic situation vs. the
difficulty to understand a well-formulated and waterproof legal text
(well-formulated to those who understand law)?
>> The great advantage of the GPL
>> is that it's clear beforehand what the deal is.
>
> Not to someone as stunningly ignorant of American law as Me.
;-).
>> GPL does not put any restrictions on mere use.
>
> Provided "mere use" does not involve the SEE of Gforth, etc.
You can SEE whatever you want. That's use. If you copy the output of SEE and
give it to someone else, that's distribution. The act of transferring
informations to someone else is distribution. The GPL says, yes, you can do
that, but don't take rights away.
>> I feel a bit tired about arguing about the GPL.
>
> 1) Would be nice if gnu.org more directly answered what not Gnu folk
> say about the GPL e.g. I wish I had found a link to tell me I must say
> "free (unlicensed)", rather than "free (gratis)" when speaking to Gnu
> folk.
I think GNU folks would have troubles with both words. A GPL'd program is
neither necessarily gratis, nor is it unlicensed.
We live in a complicated world, and the GPL is a typical engineering
approach at a legal problem (copyright prevents free flow of information).
It uses the enemy, copyright, to grant rights that are necessary for a free
flow of information. The rules are necessarily complex, and some tradeoffs
have to be accepted.
Roelf Toxopeus
> The OFPongReadMe text doesn't quite say but strongly suggests the
> author of the first version was:
> Marcus Jager Quinn -The Eskimo!- Late Night Silly Software
No suggestion, it's absolutely clear from the readme file who the
authors are, no digging needed:
Credits and Version History
1.0d1 (Jun 1998) First release, MacHack ’98.
Marcus Jager
Quinn “The Eskimo!”
Late Night Silly Software
19 Jun 1998
It was also one of the prize winning hacks at the time. I see no
reason to create a smokescreen regarding the authorship.
-Roelf
J E Thomas
> > From: J E Thomas (j2th...@swbell.net)
> ...
> > You might even have a registry of strings,
> > where you have a token that uniquely represents
> > a particular string and COUNT gives you an address and length.
> > There's nothing in the standard that says a counted string
> > has to have the form {count-byte string}
> Whoa. Indeed There Was something in the standard I read:
> http://www.forth.org/dpans/dpans2.htm#2.1
> "counted string:
> "A data structure consisting of one character containing a length
> followed by zero or more contiguous data characters. Normally,
> counted strings contain text.
You're right! That slipped by me and I think by a lot of people. I've
heard the repeated claim that counted strings don't have to be this way,
but the definition you quote says they do.
> Do you mean to be telling me Forth folk who work with Chinese chars
> are advocating that the next Forth standard relax this restriction?
I may have misunderstood, but the strong impression I had was that some
people at the reconvened standards committee argued that the current
standard doesn't have that restriction, and that nobody argued against
them. Maybe I misunderstood.
The wording you quote says that it works at the beginning of a string,
to get the string and count. If a counted string has to have the form
Count in the byte at the address
string in a contiguous length of bytes starting immediately after count
then what you say makes sense. I note that Dr. Koh in his HForth (which
includes support for Korean text) allows special characters to require
two keystrokes to enter (which after all is the way they enter those
Korean characters on a standard keyboard) and also allows EMIT to
display a partial character when it gets the first byte of a multiple
character and then finish up that same character with a later EMIT .
If you do it Dr. Koh's way then you can't tell how many characters will
actually be displayed by counting a string, and of course you can't tell
what will happen if you split a string arbitrarily and EMIT extra
characters. But the ambiguities are all in the display. If you require
that COUNT advance different distances along the string because it knows
where the end of the current character is, and that it put the entire
character into one cell on the stack (or put out a variable number of
stack items that EMIT will consume), you have troubles outside the
display.
There are commercial systems with a large worldwide user base that do
strings that are somehow not like ( count-byte byte-chars) . The
vendor for these systems said that his interpretation of the current
standard is that COUNT can only be reliably used to get the count at the
start of the string, and not for anything else. I had the strong
impression that his view prevailed.
What this means for you, is that when you try to write portable programs
and use COUNT to mean C@+ your programs will port to the vast majority
of Forth systems but perhaps not to some standard systems created by
this vendor, particularly if your text is in chinese etc.
J E Thomas
> > a completely standard program has undefined results
> > if you enter a key outside 20-7E ... needs to be true.
> Fun thinking new to me thank you, by the way, but seriously ...
> Undefined results, aye. But COMPLETELY undefined results? Ans
> doesn't bother to say that a person typing outside of x20..7E thereby
> creates "an ambiguous condition".
ANS does say that the character set is implementation-defined but must
include 20-7E. If an implementor chooses to have 8-bit characters but
still chooses to provide more than 256 chars by letting some of them use
more than 8 bits, you can argue with him about whether what he's done is
an environmental dependency or is nonstandard. But regardless, when a
user pushes a key and it's something outside 20-7E the result can't be
completely portable.
> Is it reasonable to think that ( KEY DUP addr C! addr C@ = ) ought to
> produce ( -1 ) always? Or should I continue as I began: in my newbie
> ignorance, I had been writing ( KEY HEX 7F AND ) ...
What do you want to happen when they press a function key or some weird
key combination? Whatever happens on your system, whatever you do about
it, the result won't be portable.
Jerry Avins
>
...
>
> Yes. "I want my source code to be freely shareable. If I can
> execute, view, search, annotate, edit, print the stuff ... then I want
> you to feel free to do the same."
>
seen without reverse engineering, then sell the executable result? If
not, you had better restrict the license at least a little bit.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Jerry Avins
>
...
> Undefined results, aye. But COMPLETELY undefined results? ...
Undefined -- COMPLETELY undefined
Dead -- COMPLETELY dead
Pregnant -- COMPLETELY pregnant
I'm finding it difficult to make appropriate distinctions.
Pat LaVarre
> Date: 2002-06-12 05:10:36 PST
Thought-provoking as always, thank you.
> "unlicensed" looks problematic to me.
Oh. Ouch. Well, thanks for saying.
> A GPL'd program is neither necessarily gratis,
This I didn't know.
> nor is it unlicensed.
This I knew. By "free (unlicensed)" I meant to refer to code that has
no explicit license. I meant to exclude GPL'ed stuff without inviting
attack: I meant to avoid advocating or deprecating GPL'ed stuff.
I'm not sure I have quite the right term.
I'd also want the code to have no explicit copyright, except that I
mean to include "public domain" stuff.
I do have an example of something I found on the web that I did not
myself create. Specifically, the text of:
http://members.aol.com/plforth/ofpong/OFPong1.0d1/OFPong.of.txt
has no copyright, no license, no statement of authorship.
It's just code: it looks like SEE output, with comments added.
And I have another example: all the fragments of code posted here on
comp.lang.forth without explicitly mention of copyright, GPL, or other
license.
What is the Gnu-correct term for such stuff?
If it's not "free", not "libre", and not distinctly "gratis" in
contrast with Gforth, what is it?
That OFPong.of.txt link above actually fetches a perhaps-now-obsolete
copy I made of:
ftp://ftp.machack.com/Hacks98/ofpong.sit/OFPong1.0d1/OFPong.of.txt
I made this copy because I know a lot of people who are stuck running
browsers that can't click thru ftp: and .sit/ links. I think you're
telling me that American law tells me I thereby violated someone's
copyright. I didn't know that either (and in a sense I still don't,
because I am not a lawyer).
So maybe my copy is illegal ... but what was the original. If it's
not "free", not "libre", and not distinctly "gratis" in contrast with
Gforth, what is it?
Curiously yours,
Pat LaVarre
Albert van der Horst
Bernd Paysan <bernd....@gmx.de> wrote:
>I feel a bit tired about arguing about the GPL. It's me, the author, who
>chooses the license. If you don't like it, because you want to choose
>another license for your code (which is incompatible with my license),
>don't argue. Why should you have a right to demand which license I
>generally should use, but at the same time deny me the right to demand
>which license you should use under very specific and narrow conditions (the
>desire to ship a Gforth image without sources, which is clearly a right
>that I have to give you, because copyright doesn't allow it at all - can't
>you just take the right I give you as is, without complaining? It's a gift,
>after all!)?
I feel the same way too. But in fact this should be no surprise.
Our adversaries have a budget of $ 1,000,000,000 annually
to impose their views. There can be no comprehensive
insight where and how this huge cash is flowing.
No doubt some people are payed to distribute what are clearly
unreasonable views, to make sure we hear it all the time.
There is no choice but to rebut again and again,
tired as we may become of it.
--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Pat LaVarre
> > doesn't quite say but strongly suggests
> Credits and Version History
>
> 1.0d1 (Jun 1998) First release, MacHack ’98.
>
> Marcus Jager
> Quinn “The Eskimo!”
> Late Night Silly Software
>
> 19 Jun 1998
>
> It was also one of the prize winning hacks at the time. I see no
> reason to create a smokescreen regarding the authorship.
I think you're not giving me adequate credit for ignorance. I could
see clearly that this text showed Marcus Jager as the author of the
documentation. I'm less clear on who wrote which parts of the code.
I wasn't there at the time. I didn't see Pong until recently - maybe
4Q01?
I take it you're telling me a person named Marcus Jager (not Marcus
Jager Quinn) wrote the whole thing in an inspired frenzy?
> no reason to create a smokescreen
Are you objecting only to my post or to my web page?
If to my web page, can you tell me more specifically what I should
correct?
Curiously yours,
Pat LaVarre
Pat LaVarre
> execute, view, search, annotate, edit, print the stuff ... then I want
> you to feel free to do the same."
>
> Date: 2002-06-12 10:12:04 PST
...
> Do you want me to be able to trivially change it in a way
> that can't be seen without reverse engineering,
> then sell the executable result? If not,
> you had better restrict the license at least a little bit.
Do I want you to do such a rude thing? Indeed no.
Do I want to try to acquire some legal power over you to tell you how
you may or may not change what I shared? No. I SHARED it. It's
yours now as much as mine.
Without such a legal power in hand, do I want to leave my name out of
the source code? Yes. If I had such a legal power, would I want to
come after you if you did do such a rude thing? No, I don't enjoy
non-technical conflict. Therefore when I have such a legal power, do
I still want to leave my name out of the source code? Yes.
Perhaps I should mention, my personal history of pain includes from
the early days an employer who had a network that worked. Someone
abused that network to take a some snippet of code which I had signed
in a comment and grew it into a monstrosity. I then got called, time
and again, to deal with the monstrosity - about which I had no clue.
"If I can execute, view, search, annotate, edit, print the stuff ...
then I want you to feel free to do the same."
Pat LaVarre
Elizabeth D. Rather
> > Do you mean to be telling me Forth folk who work with Chinese chars
> > are advocating that the next Forth standard relax this restriction?
>
> I may have misunderstood, but the strong impression I had was that some
> people at the reconvened standards committee argued that the current
> standard doesn't have that restriction, and that nobody argued against
> them. Maybe I misunderstood.
There has been a great deal of discussion about extended character
sets and internationalization, and some papers published by Stephen
Pelc and others. But since no new standard resulted there is no
effective change.
> > > ... Chinese ... UTF codes
> > > ... variable number of bytes per character
>
> > Yes the UTF-8 of http://www.unicode.org/charts/ gives us one OR MORE
> > bytes per char if we mix chars inside and outside of x00..7F. Much
> > of Greek appears as two bytes per char, much of Cyrillic as three.
>
>...
> There are commercial systems with a large worldwide user base that do
> strings that are somehow not like ( count-byte byte-chars) . The
> vendor for these systems said that his interpretation of the current
> standard is that COUNT can only be reliably used to get the count at the
> start of the string, and not for anything else. I had the strong
> impression that his view prevailed.
>
> What this means for you, is that when you try to write portable programs
> and use COUNT to mean C@+ your programs will port to the vast majority
> of Forth systems but perhaps not to some standard systems created by
> this vendor, particularly if your text is in chinese etc.
The present state-of-play depends on how an implementation defines
a 'char'. You can have 16-bit chars, in which case 1 char <> 1 byte,
but you can have a 16-bit count in a counted string. However, the
vast majority of applications have a dependency (intended or not)
on 1 char = 1 byte = 1 AU, and those will get in trouble. There is
at this time absolutely no provision for multiple or variable sizes
for char.
Cheers,
Elizabeth
J E Thomas
> J E Thomas wrote:
> > I may have misunderstood, but the strong impression I had was that
> > some people at the reconvened standards committee argued that the
> > current standard doesn't have that restriction, and that nobody
> > argued against them. Maybe I misunderstood.
> There has been a great deal of discussion about extended character
> sets and internationalization, and some papers published by Stephen
> Pelc and others. But since no new standard resulted there is no
> effective change.
I believe I heard the argument that using COUNT for anything other than
getting the count and start address of a counted string requires an
environmental dependency. That a standard system doesn't have to let
you use COUNT to get the next character address and the current
character, from any random string.
Was that argument made? Was it resolved?
> The present state-of-play depends on how an implementation defines
> a 'char'. You can have 16-bit chars, in which case 1 char <> 1 byte,
> but you can have a 16-bit count in a counted string. However, the
> vast majority of applications have a dependency (intended or not)
> on 1 char = 1 byte = 1 AU, and those will get in trouble. There is
> at this time absolutely no provision for multiple or variable sizes
> for char.
I believe that Dr. Koh's hForth shows how variable size characters might
possibly work. His KEY can accept a keystroke that serves to begin a
character, and a second KEY and keystroke is then required to complete
it. Similarly a pair of EMITs in the correct order display the entire
character. The Forth system doesn't have to notice anything unusual.
It is important not to split a character when splitting a string, and
not to do a CR after half a character. I have the strong impression
that if you can type in Korean well enough to actually use his Korean
system (he has a version that's all english too), you won't have any
problems with those restrictions.
Elizabeth D. Rather
> I believe I heard the argument that using COUNT for anything other than
> getting the count and start address of a counted string requires an
> environmental dependency. That a standard system doesn't have to let
> you use COUNT to get the next character address and the current
> character, from any random string.
>
> Was that argument made?
Yes, mainly by Stephen Pelc.
> Was it resolved?
No. Many people (including me) disagreed, and the matter was
deferred pending further work on internationalization.
Cheers,
Elizabeth
Roelf Toxopeus
> > > [separate file bundled together with source in a .sit compressed folder]
> > > doesn't quite say but strongly suggests
> ...
> > Credits and Version History
> >
> > 1.0d1 (Jun 1998) First release, MacHack ’98.
> >
> > Marcus Jager
> > Quinn “The Eskimo!”
> > Late Night Silly Software
> >
> > 19 Jun 1998
> >
> > It was also one of the prize winning hacks at the time. I see no
> > reason to create a smokescreen regarding the authorship.
>
> I think you're not giving me adequate credit for ignorance. I could
> see clearly that this text showed Marcus Jager as the author of the
> documentation. I'm less clear on who wrote which parts of the code.
What's that to you, if the authors don't make that distinction? It's
quite common in the art world to have shared ownership, specially
music:
Jagger/Richards, Lennon/McCartney, Rotten/Cook/Jones/Matlock.
The performance group I work in uses the group name for ownership.
Although internally we know who did what, we present it as a groups
effort to the outside world, we share the credits equally.
>
> I wasn't there at the time. I didn't see Pong until recently - maybe
> 4Q01?
>
> I take it you're telling me a person named Marcus Jager (not Marcus
> Jager Quinn) wrote the whole thing in an inspired frenzy?
AFAIK two persons...
http://www.hax.com/MacHack/BestOf98.html
>
> > no reason to create a smokescreen
>
> Are you objecting only to my post or to my web page?
Posting: "doesn't quite say but strongly suggests"
wrong, it clearly says.
The authorship isn't in any doubt just because you can't point your
finger on who did what. They wrote it as a team, they deserve their
rightful credits/kudos. Who owns it, is something different.
Your web page is none of my business.
curious: what's the ’ and others ?
-Roelf
Bernd Paysan
> I do have an example of something I found on the web that I did not
> myself create. Specifically, the text of:
> http://members.aol.com/plforth/ofpong/OFPong1.0d1/OFPong.of.txt
> has no copyright, no license, no statement of authorship.
International copyright law does not require to have an explicit copyright
message. Copyright just applies. That's what I say with that you are in the
"snake pit" when you have unlicensed code - because unlicensed code means
that you don't have a license for using, modifying, copying, etc. A Usenet
posting is definitively meant to be read, and copied between news servers -
that's implicit by posting it to Usenet. But the rest is not licensed. You
probably can say that you suppose that it is public domain, but if you
really want to know, you have to ask the author (and if there's no
statement of authorship, that could be quite difficult).
Generally, if you want to use a Usenet posting other than just reading it on
Usenet, you have to ask the author. E.g. if you print it into a journal.
Just because someone doesn't write (c) xxxx by yyyy, it doesn't mean that
it isn't copyrighted. E.g. if I contribute to a heated flame war, I'd
rather reject printing it into a journal. Perhaps I even set the X-archive:
no flag, so that Google won't see it, either.
So your code above grants you only one right: to read it (because it's a web
page, and web pages are meant to be read). You can't ask the author,
because it's not clear who wrote it - you can ask only the maintainer of
the web page, if he knows the author. You can't do anything else, because
there's no statement that you are allowed to do it. That's how copyright
works - that's what "unlicensed" means: no license for anything.
Stephen Pelc
The issue with COUNT in particular is that COUNT was/is widely
used to step through memory. This is not portable to byte
addressed systems with 16 bit characters (e.g. Unicode). There
are two papers available discussing these topics at the download
area of the MPE website.
Stephen
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
J E Thomas
> The issue with COUNT in particular is that COUNT was/is widely
> used to step through memory. This is not portable to byte
> addressed systems with 16 bit characters (e.g. Unicode). There
> are two papers available discussing these topics at the download
> area of the MPE website.
Thank you! That makes very good sense to me. If COUNT steps through
characters when characters are more than a byte, then it won't step
through bytes.
So it's more portable to use C@+ to step through bytes.
But wait! If a charsize is 16 bits, then you don't have a standard way
to step through bytes. All you can do is step through characters, and
C@ C! etc will do 16-bit things.
Could you step through address units? Sure there are machines out there
that don't use byte-size address units, but they may be rarer by now
than Forth systems that don't use byte-size characters.
No, I've lost track again. C@+ will step through memory, one char at a
time. COUNT appears to do the same thing. If one of them fails to give
you bytes so will the other one.
So what should C@+ do that COUNT may fail at?
J E Thomas
> Generally, if you want to use a Usenet posting other than just
> reading it on Usenet, you have to ask the author. E.g. if you print
> it into a journal. Just because someone doesn't write (c) xxxx by
> yyyy, it doesn't mean that it isn't copyrighted. E.g. if I contribute
> to a heated flame war, I'd rather reject printing it into a journal.
> Perhaps I even set the X-archive: no flag, so that Google won't see
> it, either.
> So your code above grants you only one right: to read it (because
> it's a web page, and web pages are meant to be read). You can't ask
> the author, because it's not clear who wrote it - you can ask only
> the maintainer of the web page, if he knows the author. You can't do
> anything else, because there's no statement that you are allowed to
> do it. That's how copyright works - that's what "unlicensed" means:
> no license for anything.
But then, does the license give you something more than the right to
sue? If Microsoft uses your code and you don't want them to, would you
feel up to suing them? On the other hand, if Joe's Software in Toledo
Ohio uses it for something that sells twenty copies, will you sue them
either?
The right-to-sue scares bankers and higher management, so it's good for
something. But ....
If you release software with no intention of suing, then it might not
matter too much to you which terms you use. Do something so you're less
likely to get sued yourself. Avoid getting called to fix somebody
else's revisions to your work. (Unless you feel like charging to fix
it. Then you can clean up the code until it works and it's
maintainable, get some money, and so on. If the guys who revised your
code and didn't even put their names on it try to sue you could have a
headache to deal with.) Anybody who wants to risk you suing them can
use it.
If you want to release code that will get the most use, ideally you'd do
whatever will best persuade people you won't sue. GPL isn't best at
that at the moment because of all the hype about special restrictions.
It might be better to have a disclaimer something like "I wrote this
software <checksum> and didn't copy anybody else. I swear I won't sue
anybody who uses it for any purpose, and I also accept no legal
liability for what gets done with it."
GPL has other goals that make it worth using if you care about the other
goals. People who put GPL code into commercial work and don't
acknowledge it are under a potential threat. I don't know for sure
whether this is a good thing. Probably the majority of all the Forth
vendors who have ever existed, started with a public-domain Forth and
gradually improved on it. Was Forth better off or worse off for that? I
can't tell. Maybe it was a wash. Certainly you should have the right
to put restrictions on commercial code if you want to. If it's enough
money to matter then you probably don't have enough money to sue, but
the threat is good for something.
If your own GPL'd product doesn't contain somebody else's GPL'd work,
you have the right to sell other licenses too, don't you? In that case
you could put in a statement something like "Contact me for nonGPL
licenses. Relatively inexpensive flat rate." Businesses are used to
the idea of paying a per-seat cost for tools, but they hate to pay
royalties on what they sell. There's the continuing cost versus the
cost of developing it themselves, and if they decide it's cheaper to pay
royalties then they've decided their product won't sell all that well
which leads to the question why not drop it and develop something that
they have hopes *will* sell.
To the extent that this post might be interpreted as free legal advice,
I refuse to accept any legal liability for it. I give no guarantee what
will happen if anyone interprets any of it as suggestions for their own
actions and follows them. Also, the fact that I put this disclaimer on
this post should not be interpreted as evidence that I guarantee
performance from any ideas in other posts.
Please do not sue me for any reason. I'd strongly prefer that you not.
geakazoid
> In article <2695edf1.02060...@posting.google.com>,
> Pat LaVarre <ppa...@aol.com> wrote:
>
> >Also interesting is the phenomenon of people who mistake GPL to mean
> >public domain. Those people do advocate & share in GPL work, but only
> >under a false impression.
>
> Actually this is not a false impression. It only is legalistically
> speaking.
> The GPL captures the essence of what most people want by putting
> things in the public domain better than a formal public domain
> licence. Remember "public domain" is a legalistic term, and some
> people would be surprised with what Microsoft is allowed to do
> with things you have put under this licence.
>
> --
> Greetings Albert.
Once again, I am adding that there are other GNU Compatible Licenses
and the choice of license may reflect features. After discussions with
the FSF
http://www.dolfina.org/bkuhn.htm I have been brought up The Clarified
Artistic License http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses
of course it states:
"Public Domain.
Being in the public domain is not a license--rather, it means the
material is not copyrighted and no license is needed. Practically
speaking, though, if a work is in the public domain, it might as well
have an all-permissive non-copyleft free software license. Public
domain status is compatible with the GNU GPL."
However, though I had not publically posted Questions and Answers I
received about Forth and The Compatible License with FSF, they were
not aware of some of the issues about Forth except for Gforth.
geakazoid
Stephen Pelc
wrote:
>Thank you! That makes very good sense to me. If COUNT steps through
>characters when characters are more than a byte, then it won't step
>through bytes.
>
>So it's more portable to use C@+ to step through bytes.
>
>But wait! If a charsize is 16 bits, then you don't have a standard way
>to step through bytes. All you can do is step through characters, and
>C@ C! etc will do 16-bit things.
The ANS standard does not define the size of a character, cell or byte
except to say that char<=cell. In practice the vast majority of Forths
run on byte-addressed machines and use 7/8 bit characters in an 8 bit
field. Because there are no standard ways of accessing 8 bit units,
common practice has been to use the character operations Cxx to
access byte-sized items in memory. Note also that ANS defines many
file operations in terms of characters.
Since Cxx words are linked to characters in ANS terminology, Greg
Bailey proposed the Bxx word set for accessing bytes. See also the
discussion of DCS, OCS and ACS (development, operating system, and
application character sets) in the papers on the MPE web site, and
then imagine a Russian trader (Russian ACS) using a PC in China
(Chinese OCS) running a South African application (English/American
DCS).
In general, internationalised applications are not small. Requiring
these to use B@ B@++ and friends to access 8 bit memory unit is
a non-issue in terms of code size, and may avoid serious
maintenance problems. Overall, establishing comon practice for
a set of byte operators in a EXT word set would be a positive
move. However, using a C prefix for these operators would be
a bad move.
h-peter recktenwald
Bernd Paysan <bernd....@gmx.de> wrote:
>
> This program is distributed in the hope that it will be
> useful, but WITHOUT ANY WARRANTY; without even the implied
> warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
^^^^^^^^^^^^^^^^^^^^^^^^^^^
my simple english leads me to the interpretation that a reader of
that document otherwise would be given credit to be such incredibly
dull that he deserves legal support of his incompetence to deciding
on what he could make a profit from.
i.e. not the 'entrepreneur' but those who offer something would have
to care for the fact that someone else is willg to pay for it?
silly. - i assume that i'm wrong:) please, could you explain?
regards,
hp
--
>>> pse, re ply to : clf -at- lxhp -dot- in-berlin -dot- de <<<
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml en/de
Bernd Paysan
> On Tue, 11 Jun 2002 15:51:18 +0200
> Bernd Paysan <bernd....@gmx.de> wrote:
>
>>
>> This program is distributed in the hope that it will be
>> useful, but WITHOUT ANY WARRANTY; without even the implied
>> warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> my simple english leads me to the interpretation that a reader of
> that document otherwise would be given credit to be such incredibly
> dull that he deserves legal support of his incompetence to deciding
> on what he could make a profit from.
>
> i.e. not the 'entrepreneur' but those who offer something would have
> to care for the fact that someone else is willg to pay for it?
"merchantability" doesn't just mean that you can sell it (that's one of two
possible meanings), but that you can generally use it. If you want a German
translation for difficult words, use http://dict.leo.org/. "Allgemeine
Gebrauchstauglichkeit" would be the propper term here.
J E Thomas
> <j2th...@swbell.net> wrote:
> In general, internationalised applications are not small. Requiring
> these to use B@ B@++ and friends to access 8 bit memory unit is
> a non-issue in terms of code size, and may avoid serious
> maintenance problems. Overall, establishing comon practice for
> a set of byte operators in a EXT word set would be a positive
> move. However, using a C prefix for these operators would be
> a bad move.
That sounds fine to me.
I imagine it would break a lot less existing code if the C prefix
referred to bytes while we got new names for things that are
specifically characters (which might not fit into bytes). But it would
be confusing for new people who wouldn't understand the history that led
us to label byte operations with a C. To the extent that
standardisation matters, it's more important to agree on something than
to bicker over which of the adequate choices is best.
But I'm not at all clear how COUNT should be different from C@+ . If a
counted string is required to be one char-size count at the first
address followed by the actual string starting at the second address,
what could you do with C@+ that would be different from COUNT ?
a...@redhat.invalid
>> <j2th...@swbell.net> wrote:
>> In general, internationalised applications are not small. Requiring
>> these to use B@ B@++ and friends to access 8 bit memory unit is
>> a non-issue in terms of code size, and may avoid serious
>> maintenance problems. Overall, establishing comon practice for
>> a set of byte operators in a EXT word set would be a positive
>> move. However, using a C prefix for these operators would be
>> a bad move.
>
> That sounds fine to me.
> I imagine it would break a lot less existing code if the C prefix
> referred to bytes while we got new names for things that are
> specifically characters (which might not fit into bytes). But it would
> be confusing for new people who wouldn't understand the history that led
> us to label byte operations with a C.
Right: The W prefix allows W@, W! and so on, and is very much like C's
wchar_t. That's Steve's proposal, and IMO is far better than breaking
all the programs that use C@ to access bytes.
Andrew.
J E Thomas
I think that's a different question. W things are supposed to give you
16-bits. B things would give you 8 bits. C things would give you a
character, whatever size that is on your system.
Gary Chanson
"J E Thomas" <j2th...@swbell.net> wrote in message
news:3D0A815E...@swbell.net...
It should, but it isn't very practical. Unfortunately, "C@" has to mean
8 bits and we have to use something else for a character. I don't like it
but I can't see a reasonable alternative.
--
-GJC
-gch...@TheWorld.com
-War is the last resort of the incompetent.
Stephen Pelc
wrote:
>But I'm not at all clear how COUNT should be different from C@+ . If a
>counted string is required to be one char-size count at the first
>address followed by the actual string starting at the second address,
>what could you do with C@+ that would be different from COUNT ?
COUNT should be sensitive to the layout of the string (e.g. variable
width characters). And so should C@+. But B@+ just operates on bytes.
J E Thomas
> <j2th...@swbell.net> wrote:
> >But I'm not at all clear how COUNT should be different from C@+ .
> >If a counted string is required to be one char-size count at the
> >first address followed by the actual string starting at the second
> >address, what could you do with C@+ that would be different from
> >COUNT ?
> COUNT should be sensitive to the layout of the string (e.g. variable
> width characters). And so should C@+. But B@+ just operates on bytes.
I think I understood that. So if you have characters that aren't all
the same width, some that are one byte and some two and some four etc,
COUNT should point to the next full character and not to the next
char-size address. This won't break existing code unless that code is
applied to text that includes variable-width characters.
Do I have it right?
a...@redhat.invalid
> a...@redhat.invalid wrote:
>> J E Thomas <j2th...@swbell.net> wrote:
>> > I imagine it would break a lot less existing code if the C prefix
>> > referred to bytes while we got new names for things that are
>> > specifically characters (which might not fit into bytes). But it
>> > would be confusing for new people who wouldn't understand the
>> > history that led us to label byte operations with a C.
>> Right: The W prefix allows W@, W! and so on, and is very much like
>> C's wchar_t. That's Steve's proposal, and IMO is far better than
>> breaking all the programs that use C@ to access bytes.
> I think that's a different question. W things are supposed to give you
> 16-bits.
That's not what the paper says: "W" is the Wide character prefix.
"1) Because of the existence of string parsing words widely used in
dictionary and wordlist construction such as PARSE, define the ANS
character as applying to the development character set (DCS). The
effect of this is to leave unbroken all existing systems that the
authors know of. For the reasons stated above, characters should be
stated to be unsigned. From the point of view of the ANS standard
document, the definition and use of the term character remains
unchanged, although (see below) some attention to the file and block
I/O words is needed.
"2) Define a wide character set such that the size of a wide character
is implementation dependent such that char<=widechar<=cell, and is
unsigned. The WIDECHAR wordset may be constructed from existing
character-oriented words by prefixing then with a W character and
replacing character by wide character in their definitions.
"3) For Unicode systems, in which the DCS is greater than 8 bits, it
well be sensible to define either an OCTET based character set or a
narrow character set which may be defined in a similar to the widechar
character set, but with an N prefix.
"4) Without adding several new I/O words, it appears that defining file
i/o in terms of address units will break almost no existing code,
except on some cell addressed machines. This can be handled by
defining the fam words such as BIN more carefully, and perhaps adding
a couple more. OCT has already been suggested for octets. This
approach is clean. Existing programs with an 8 bit DCS are unbroken,
including those that use COUNT to step through memory. A development
environment may migrate to Unicode either by making the DCS character
size 16 bits, and thus breaking some code, or by retaining an 8 bit
DCS, and defining the widechar as 16 bits or more."
> B things would give you 8 bits. C things would give you a
> character, whatever size that is on your system.
I understand what you mean, but I think it's the wrong thing to do.
Andrew.
Albert van der Horst
geakazoid <aze...@dolfina.org> wrote:
<SNIP>
>
>Once again, I am adding that there are other GNU Compatible Licenses
In the writings of FSF "GNU compatible license" has as very
technical meaning. For starters, without that context the following
is impossible to follow.
>and the choice of license may reflect features. After discussions with
>the FSF
>http://www.dolfina.org/bkuhn.htm I have been brought up The Clarified
>Artistic License http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicensesq
What is this? A passive sentence with an accusative.
I can't parse it.
>of course it states:
Assuming this is a new sentence. Of course!
>"Public Domain.
>Being in the public domain is not a license--rather, it means the
>material is not copyrighted and no license is needed. Practically
>speaking, though, if a work is in the public domain, it might as well
>have an all-permissive non-copyleft free software license. Public
>domain status is compatible with the GNU GPL."
So public domain is compatible with GPL, no surprise, and of
course
It is even compatible with companies patenting your ideas,
>
>However, though I had not publically posted Questions and Answers I
>received about Forth and The Compatible License with FSF, they were
>not aware of some of the issues about Forth except for Gforth.
Even if I make that
"However they were not aware ... Gforth"
and ignore "though ....FSF"
i can't make anything of it in the context?
>
>geakazoid
Albert van der Horst
No! If your software breaks because it assumes C@ is a byte,
it was broken (has a "software dependancy") al along.
If you go the path that C@ means byte fetch, which has never
been endorsed by the standard (!) you will be forever stuck
with a wrong name.
The problem the standard leaves us with, is there is no way to
officially address ``address units'' except by MOVE ,
not that there is much wrong with the way to address characters.
The W! B! C! for characters proposal above is excellent
and I vote for it (for what my vote is worth.)
From now I start byte addressing stuff (like an eprom programmer)
with
'C! ALIAS B! \ Change as appropriate.
>-GJC
Albert van der Horst.
Walter Rottenkolber
Stephen Pelc wrote in message <3d0aff56....@192.168.0.1>...
>On Fri, 14 Jun 2002 16:46:50 GMT, J E Thomas <j2th...@swbell.net>
>wrote:
>
>>But I'm not at all clear how COUNT should be different from C@+ . If a
>>counted string is required to be one char-size count at the first
>>address followed by the actual string starting at the second address,
>>what could you do with C@+ that would be different from COUNT ?
>
>COUNT should be sensitive to the layout of the string (e.g. variable
>width characters). And so should C@+. But B@+ just operates on bytes.
>
>Stephen
>--
defines C (something) as eight bits. It's a shame that the TC didn't bite
the bullet then to separate the definition of Char from Byte, but there you
are. But you are allowed to define dependencies so why not just define them
so? Perhaps in time, Comus will become Standard.
Walter Rottenkolber
Pat LaVarre
> Date: 2002-06-13 08:02:01 PST
> ... two papers available
> discussing these topics at the download area of the MPE website.
I trust we mean the web trails:
http://www.mpeltd.demon.co.uk/arena.htm
http://www.mpeltd.demon.co.uk/arena/i18n.propose.v7.PDF
PDF file: i18n.propose.v7.PDF Approx. Size:30K.
This is the draft ANS proposal for internationalisation.
http://www.mpeltd.demon.co.uk/arena/i18n.widechar.v7.PDF
PDF file: i18n.widechar.v7.PDF Approx. Size:20K.
This is the draft proposal for using wide character sets in ANS Forth.
Thanks much for sharing these,
Pat LaVarre
Pat LaVarre
> Date: 2002-06-13 01:19:17 PST
...
> I think you're not giving me adequate credit for ignorance.
This I stand by.
> Posting: "doesn't quite say but strongly suggests"
> wrong, it clearly says.
Clear to you if you say so, sure. NOT clear to me. I think you've
now persuasively refuted what I wrongly thought was strongly
suggested.
> > I take it you're telling me a person
> > named Marcus Jager (not Marcus Jager Quinn)
> > wrote the whole thing in an inspired frenzy?
More specifically, me, I thought for awhile we were speaking of One
author, whose name was Marcus Jager, whose nickname was Quinn The
Eskimo.
I think now we're speaking of two people, one named Marcus Jager,
another nicknamed Quinn The Eskimo. I'd say it's possible that
Quinn's legal name is Quinn The Eskimo, but unlikely.
> http://www.hax.com/MacHack/BestOf98.html
> ... Taking second place was
> OFPong by Marcus Jager and Quinn "The Eskimo!".
This English clearly suggests that Marcus & Quinn are two different
people. Thanks for the link.
> curious: what's the ’ and others ?
Natural consequence.
With a name like mine, thoughtlessly designed computers trick people
into producing misspellings such as Pat La, Pat L. Varre, Pat Varre,
Pat Lavarre, PAT LAVARRE, and so on.
With a name like Quinn "The Eskimo!", thoughtlessly designed computers
trick people into producing misspellings like the 31 chars:
Quinn “The Eskimo!”
123456789_123456789_123456789_1
I fell victim to such a trick in posting that post, I'm not sure which
trick where, whoops, sorry.
Pat LaVarre
Pat LaVarre
> Date: 2002-06-13 11:12:09 PST
> ...
> Please do not sue me for any reason.
> I'd strongly prefer that you not.
I'm with you here ... and I laughed out loud to read this, thank you.
> ... might be better to have a disclaimer
I mis/remember one lawyer once telling me that offering no disclaimer
lets my lawyer argue over what the implied disclaimers are more freely
than if I constructed an amateur disclaimer myself.
I don't know if that's good advice or bad ... but I find it a
plausible defence of the option that's easiest to follow i.e. do
nothing til someone rude does take advantage of ignorance of the law
being no excuse ...
Pat LaVarre
Elizabeth D. Rather
> It's interesting that ansForth desires to avoid system dependencies and then
> defines C (something) as eight bits.
No, no, no! ANS Forth absolutely does _not_ define Cthings as 8-bits!
ANS Forth is pretty good at liberating chars from any particular size. The
big flaw in ANS Forth on this topic is that it doesn't make any provision
for manipulating bytes or address units (with the exception of MOVE)
if they are _not_ the same as chars. So you can have 16-bit chars just fine,
but if you then want to manipulate 8-bit entities on that system you have
a problem. That's why the internationalization group is proposing to
add Bwords.
Cheers,
Elizabeth
> It's a shame that the TC didn't bite
> the bullet then to separate the definition of Char from Byte, but there you
> are. But you are allowed to define dependencies so why not just define them
> so? Perhaps in time, Comus will become Standard.
The TC spent a lot of time on this issue in the first round, but was not
able to solve the problem. The proposed Bwords are a good effort.
If you don't want to define or deal with them, just declare a dependency
on char=byte=au and get on with life.
Cheers,
Elizabeth
Stephen Pelc
wrote:
>So if you have characters that aren't all
>the same width, some that are one byte and some two and some four etc,
>COUNT should point to the next full character and not to the next
>char-size address. This won't break existing code unless that code is
>applied to text that includes variable-width characters.
>
>Do I have it right?
DCS (development character set). I know of no Forths using a variable
width DCS, and of one that uses a 16 bit Unicode DCS.