HDTenEightyP/NetNews huggingface dataset:
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Distant Drums
Date: 9 Jan 93 12:51:02 GMT
Organization: EIEI-U

Category 14,  Topic 8
Message 90        Fri Jan 08, 1993
ELLIOTT.C                    at 14:02 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 01-03-93 (07:49)
   To: PAUL GUIJT
 From: JACK WOEHR
 Subj: HI THERE!

 -> Had a great Christmas: Hotline BBS in Amsterdam, the
 Netherlands (+31-20-6891014, Fido 2:500/245) is now linked
 into ForthNet! -
 > CU -> Paul -> -> ... OFFLINE 1.39 -> ----> *
 Hotline BBS, Amsterdam, The Continental Hub  xx-31-20-6891014 ->
 HST-DS * PostLink(tm) v1.04  HOTLINE (#210) : RelayNet(tm)
 Regional -> Hub -> NET/Mail : The GrapeVine BBS 2.4 gigs (501)
 753-8121 Dual Standard

         Howdy, Paul ... Greetings from the RCFB, nestled by the
 foothills of the Rocky Mountains, in Golden, Colorado.

                 =jax=

 NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for
 Forth! ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.04  GRAPEVINE (#318) : RelayNet(tm) Hub
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
Newsgroups: comp.lang.forth
From: dadraper@cc.utah.edu
Subject: PC-Yerks
Organization: University of Utah Computer Center
Date: 11 Jan 93 00:42:45 MDT

In forth deminsion not too long ago there was several articles about
object-oriented forth.  One article was about PC-Yerks.  Is this code available
some where? Can anyone tell me where I might find PC-yerks or does anyone have
any redcommended object-0riented forth.  Thanks!!
Newsgroups: comp.lang.forth
From: dave@moci.uucp (Dave Ruske)
Subject: Re: What's the abbreviation DPMI ?
Organization: ICOM, Inc., West Allis, WI
Date: Thu, 7 Jan 93 14:14:20 GMT

In article <1ih23pINNe0k@nz12.rz.uni-karlsruhe.de> DAHMS@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) writes:
>I have a quite good knowledge about computers, but never heard about "DPMI"
>outside this newsgroup, so I what does it mean?

DPMI stands for "DOS Protected Mode Interface".  The DPMI spec defines services
which allow protect-mode DOS applications to coexist, and was developed by
Microsoft, Intel, Lotus, Phar Lap, and about a dozen other companies.  DPMI
addresses some shortcomings of the earlier VCPI (Virtual Control Program
Interface) spec.

I believe copies of the DPMI spec are available from Intel.

Cheers,
Dave Ruske     ...!uwm.edu!moci!dave     GEnie: D.RUSKE1
From: DAHMS@ifk20.mach.uni-karlsruhe.de (Heribert Dahms)
Newsgroups: comp.lang.forth
Subject: What's the abbreviation DPMI ?
Date: 7 Jan 1993 10:53:45 GMT
Organization: University of Karlsruhe, FRG (Dept. of Mechanical Engineering)
Distribution: world
NNTP-Posting-Host: ifk29.mach.uni-karlsruhe.de
X-News-Reader: VMS NEWS 1.20

I have a quite good knowledge about computers, but never heard about "DPMI"
outside this newsgroup, so I what does it mean?


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
Newsgroups: comp.lang.forth
From: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
Subject: Re: What's the abbreviation DPMI ?
Originator: pazsan@hphalle5h.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 8 Jan 1993 10:10:35 GMT


In article <1ih23pINNe0k@nz12.rz.uni-karlsruhe.de>, DAHMS@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) writes:
|> I have a quite good knowledge about computers, but never heard about "DPMI"
|> outside this newsgroup, so I what does it mean?

DOS Protected Mode Interface. Because MS-DOS is still a non-reentrant real mode
exception handler (and will be for the next time), some people invented DOS
Extenders (Phar Lap, Lotus, and even MS-Windows has or is a DOS Extender). They
decided (hopefully) to standardize the features of their DOS Extenders, which
resulted in DPMI. If you don't work with DOS, forget it. No other OS is so nasty
that it needs an extender for actual and widespread machines it supports (er, DOS
isn't a real OS... don't let you irritate by the letters OS in DOS).
-- 
Bernd Paysan
"Late answers are wrong answers!"
Newsgroups: comp.lang.forth
From: sasrer@unx.sas.com (Rodney Radford)
Subject: Looking for Z8 (or Super/8) forth
Date: Fri, 8 Jan 1993 15:02:36 GMT
Organization: SAS Institute Inc.

I have recently acquired several of the bound-out Z8s (4K EPROM rides 
piggy-back on the Z8 CPU chip), and I would love to be able to put a
version of Forth in it.

Has anyone done this yet in a PD package (this is for a personal hobby, 
and is NOT job related). I noticed in an old copy of the FAQ a reference
to MPE and their cross compilers (I really would prefer a native Forth) -
anybody have any idea how much their products run...?

Thanx.
--
---
Rodney Radford          || Computer Graphics/Imaging
sasrer@unx.sas.com      || SAS Institute, Inc.
(919) 677-8000 x7703    || Cary, NC  27513

Newsgroups: comp.lang.forth
From: strohm@mksol.dseg.ti.com (john r strohm)
Subject: Re: Documenting
Organization: Texas Instruments, Inc
Date: Thu, 7 Jan 1993 19:01:02 GMT

Larry Maturo asks for reasons why one user prefers blocks over files.

I offer the following for consideration.

Blocks forces every single chunk of code to fit in a very restricted window,
and it makes it darned near impossible to "slide" the window.  In my
personal opinion, based on the code that I have seen, this restriction
TENDS to force a greater degree of modularization, conciseness, and
coherence, as compared to code developed under programming support
environments that allow and even encourage the programmer to ramble on for
hundreds of lines.

FORTH is traditionally used in certain very specific domains of discourse.
In those domains, it is very rare to encounter a routine which cannot be
expressed elegantly and understandably in some number of small fragments,
i.e., blocks.  In the larger domain of programming, I know of only one
domain that routinely needs monstrously-long programs (scripts for automated
test equipment test sequences).  Outside of that, I have seen exactly one
FORTRAN subroutine that was more than one printed page of code, that really
couldn't be broken up any farther, and that really needed to be three pages.
(It was the Photon Torpedo handler from the classic Star Trek game of the
mid-1970s.  That code was quite involved.  This is not exactly your common
everyday run-of-the-mill checkbook balancer here.)
From: dwp+@cs.cmu.edu (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Summary: something salient, shortly stated, sadly seldom satoric
Date: 5 Jan 93 03:03:10 GMT
Organization: EIEI-U

In article <C0CsnE.CrC@starnine.com> mikeh@starnine.com (Mike Haas) writes:
+They [screens] are also incredibly wasteful... if you only enter one 1-line
+definition on a screen, you are wasting all the rest of the storage
+space, as screens must occupy 1024 characters, regardless of how
+much is white-space and what is not.  Just the remainder of whitespace
+on each line following the last non-white character is a waste.
+
+All because of the inability to handle an "end-of-line" character!
+And what OS doesn't provide THAT?
[Tedious list of the first line "documentation" for a group of screens
elided.  -dwp]
+Simple.  Each is in it's own file.  Clean, clear, and no waste of space.

Whoa a minute here.  Most OS's (those that have EOL characters), also have
file systems with allocations in units of sectors (or multiple-sector
unitss), and bunches of tiny files will waste a lot of space.  If this is
really an issue, then let's be clear about it.

+I always wonder how many proponents of screens have never tried
+a good file implemtation.
+
+The fact that many still argue for screens is a statement as to 
+why Forth will never be accepted by the mainsteam.

How about:  The fact that many still argue over screens vs. files is a
statement as to why Forth will never be accepted by the mainstream?

Is Forth so rigid as to require one and disallow the other?

-Doug
-- 
---
email to: dwp@willett.pgh.pa.us is preferred to From: address but both work.
Newsgroups: comp.lang.forth
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: learning forth
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Distribution: comp
Date: Mon, 11 Jan 1993 22:20:53 GMT

However, note that 'Starting Forth' covers only Chuch Moore's dialect.
Newsgroups: comp.lang.forth
From: "elliott chapin" <elliott.chapin@canrem.com>
Subject: learning forth
Reply-To: "elliott chapin" <elliott.chapin@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 11 Jan 93 12:00:59 EST

TO: Garbanzo!lisa_christine@under.mind.ORG

Look for Leo Brodie's  "Starting Forth" and the ForthNet FAQs.

Elliott Chapin
---
  DeLuxe 1.12 #4315  elliott.chapin@canrem.com
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.lang.forth
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: Re: Documenting
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 8 Jan 1993 07:18:28 GMT

mikeh@starnine.com (Mike Haas) writes:

>+ Some potential Forth'ers might be turned off by seeing heated "screens vs
>+ files" composing half the net traffic.  :(
>
> Ah... that must be the reason Forth is not very popular...
>
> because we discuss it's rough edges on the net.
>
> Sorry.  So what would you like us to talk about, Nick?

Hey, I'm just voicing the complaints I've seen from lots of people.  They're
really tired of the endless "screens vs files" arguing.

It's an argument between two factions of established Forth'ers.  I can't see
it being helpful in attracting newcomers.

Maybe it's something that should be left to e-mail?

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.lang.forth
From: jax@well.sf.ca.us (Jack J. Woehr)
Subject: Re: learning forth
Organization: Whole Earth 'Lectronic Link
Distribution: comp
Date: Tue, 12 Jan 1993 07:04:02 GMT

In <1993Jan11.222053.25700@netcom.com> jimlynch@netcom.com (Jim Lynch) writes:

>However, note that 'Starting Forth' covers only Chuch Moore's dialect.

	Not so the Second Edition (Prentice-Hall, 1985) which covers
Forth-83 also.

		=jax=
-- 
 # jax@well.{UUCP,sf.ca.us}  # #  Member  # # Vice President,       #
 # du!isis!koscej!jax        # # X3J14 TC # #  Forth Interest Group #
 # JAX on GEnie              # # for ANS  # #   P.O. Box 2154       #
 # SYSOP RCFB (303) 278-0364 # #  Forth   # #    Oakland, CA 94621  #
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Distant Drums
Date: 8 Jan 93 12:21:00 GMT
Organization: EIEI-U

Category 14,  Topic 8
Message 89        Thu Jan 07, 1993
ELLIOTT.C                    at 19:11 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 01-04-93 (17:28)
   To: ALL
 From: ERIC SCALES
 Subj: New Participant

           EDSDEVEL is now carrying this conference

 ---
    SFUTI 3.16   (Unregistered)
  * EDS Development (Programmer's BBS) 812-423-3394
  * PostLink(tm) v1.04  EDSDEVELOP (#1620) : RelayNet(tm)


-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: Interface!cceye@under.mind.ORG
Newsgroups: comp.lang.forth
Subject: your wish is my command-line-interface
Date: 10 Jan 93 07:14:00 -0500
Organization: Interface BBS, 707-544-9661
X-newsreader: Fortress v1f-75

  
 Wish files, filespec [*.*] 
     
 FORTHPS.SCR  |  18983 93Feb14 Universal Postscript emulator- 
              |                interpreter for IBMPC. 
 FASTLINE.BLK |  61956 93Apr01 Fast screen graphics for above 
              |                postscript emulator. ANY board. 
 DICTWNDO.SCR |  43821 93Jul04 Shows dictionary entries as a 
              |                tree of small windows, all the 
              |                way down the thread of the def. 
 CANOPEN.PYG  |   5630 93Dec25 Point'n'shoot file opener for 
              |                Pyg. Threads files. Relative LOAD   
   
 OK, this is what <EYE> want. Someday I'll create them, but I 
 feel that others  more expert will do the job first. 
     
 WHAT IS that utility I see that allows users to QUOTE others? 
 with a | or a < down the left side? Sometimes see TWO levels of 
 reference. Can it be possible it's all done in real time, using 
 our perfect brains, fast fingers, and free phone time. 
     
 Actually it it silly to send back a whole quote, wasting all 
 those bits. I am looking at a proposal for Ted Nelson's Xanadu: 
 in his system quotes are done by simply issuing a POINTER to the 
 original material. Up it comes! No "in-line coding". Sounds very 
 threaded and forthlike. 
   
 Here's a way a cheapo bbs could handle it: The various 
 conversational "threads" would be available, and downloaded at 
 the beginning of one's session, as a compressed file. It would 
 be unzipped in the backround by my local com software and 
 displayed somehow in another window or on the right side of my 
 screen. Then quoting, additions to and references to stuff would 
 be EASY, i would just have to type a NUMBER, draw a LINE or some 
 other screen hack, and send it back. It would appear in the next 
 guy's compressed download. Current threads, such as the one 
 about screen vs textfile input in Forth, could be carried on 
 cheaply New ones, such as THIS would be more "expensive", but 
 who knows, I may be continuing an old thread that is too old for 
 the New Messages umbrella. 
 Speeking of Xanadu, has anyone coded HUMBERS (humongus numbers) 
 in Forth? <Nelson, Literary Machines 90.1, 4/13> 
   
 CC<eye>, perpetual Forth novice 
 vx 415-861-0919 
 fx 415-863-2233 

--
via Fortress Gateway at uumind.mind.ORG
Newsgroups: comp.lang.forth
From: tcevans@mishima.mn.org (Thomas C. Evans)
Subject: Validation suite for Forth?
Organization: Alternate Realities
X-Newsreader: TIN [version 1.1 PL7]
Date: Fri, 8 Jan 1993 02:11:11 GMT

I would like to know if a validation or test suite is available
for any of the standard Forths.

Please e-mail replies to tcevans@mishima.MN.ORG or tcevans@lilly.com
and I will post a summary.  

Thanks in advance.
--
tom
From: fish@ecst.csuchico.edu (Kevin Haddock)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 8 Jan 93 09:49:12 GMT
Organization: California State University, Chico
NNTP-Posting-Host: cscihp.ecst.csuchico.edu

In article <1ii5teINNclv@transfer.stratus.com> nick@sw.stratus.com (Nicolas Tamburri) writes:
[...]
>
>brought up on other languages.  More importantly, it flies in the face of the
>Forth phylosophy that the language should not get in the way of the programmer.
>The language should not TEND to force modularization upon the programmer, it
>should trust the programmer to do the right thing.  Most Forthers do.
>
>I don't mean to be judgmental on screens/blocks.  If you are more productive with
>them, then by all means use them, and rejoice in the fact that you use a language
>which lets you choose the best way to work.
>
>								/nt


This reminds me of a joke:

Man:  Doctor, it hurts when I do this <rasing up his right arm>.
Doctor:  well then, don't do that!

I would argue that it does not fly in the face of Forth phylosophy to use
screens because if you do your code correctly screens do not get in the way
and since they are vastly simpler to impliment and use in creative ways
in your source code they VERY MUCH fit into Forth phylosophy.

A lot of Forth is EXACTLY this way.  For instance: only really being
able to get to the top few items on the stack (no problem if you
are factoring properly), highly restrictive control structures (same
reason), RPN math (take two minutes to unravel the occaisional formula)
space delimited tokens (and the SIMPLE single character parser WORD),
'gas tank' style linear memory management, pointers with fetch and store,
etc, etc, etc,......

I would argue that a very, very simple Forth gives one a feeling of
confidence.  It is predictable.  If the tool is as simple as possible
(yet flexible) it allows ones mind to concentrate on the complexity of
the problem instead of the complexity of the tool.  This "it's so simple
it has to work" phylosophy eliminates variables and vastly reduces the
time spent hunting for bugs.

I have worked with 4gl's that amount to 10mb of buggy, low performance
code, and I would still prefer to write everything myself in pygmy
(which I can tuck away for future projects) than write patches and
kludges around this gargantuan glob of rank spagetti.  That is
a very frustrating situation.  It is not programming, creating or
discovering new algolrythms and tools.  It is rote memorization and
hopeless searches for information that will change with the winds of
the next 'release'.


-Kevin
fish@cscihp.ecst.csuchico.edu

-------
There are no complex problems; only complex solutions!
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: FORTH:, Filters and Esperanto
Date: 8 Jan 93 12:20:57 GMT
Organization: EIEI-U

Category 10,  Topic 42
Message 6         Thu Jan 07, 1993
ELLIOTT.C                    at 19:10 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 01-06-93 (13:06)
   To: B.DUNN5 [BRIAN]
 From: STEVE PALINCSAR
 Subj: Esperanto

 >Most of the world population has never heard of Esperanto.  Many
 programmers >have heard of Forth.  There is a start.

 I wouldn't be surprised if you could put it a bit stronger than
 that: probably most Forth programmers _have_ heard of Esperanto,
 and perhaps a significant number of the true Esperanto fans have
 either heard of Forth or are Forth programmers.  Which I doubt is
 achance coincidence. ---
    Via ProDoor 3.4R
  * The Running Board 301-229-5623/5342
  * PostLink(tm) v1.04  RUNNINGA (#2) : RelayNet(tm)
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
Newsgroups: comp.lang.forth
From: mikc@hal.gnu.ai.mit.edu (Mike Coughlin)
Newsgroups: comp.lang.forth
Subject: Re: Forth Standard Debate
Date: 7 Jan 93 16:19:11 GMT
Organization: /etc/organization
NNTP-Posting-Host: hal.gnu.ai.mit.edu

In article <1993Jan4.214739.11660@netcom.com> jimlynch@netcom.com (Jim Lynch) writes:
:Whoever wrote the following:
:>>>>>
:Forth has not been standardized, not at all, ever.
:<<<<<
:
:(with apologies in advance) is sorely mistaken and misinformed.
:
:I was there, I saw the standards come out and I have copies of the figFORTH
:installation manual (somewhere) as well as the FORTH-79 and FORTH-83 standard
:descriptions.
:
:On the contrary, there's more than one standard! :)
:
  I confess, it was picky hard to please me that wrote that.
  If you have more than one standard, it seems to me that you
  have no standard at all. A double standard is condemmed,
  and we seem to have at least three of them (with another
  comming soon).


-- 
   Michael Coughlin             mikc@gnu.ai.mit.edu
From: cgra@btma74.nohost.nodomain
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 12 Jan 93 08:25:47 GMT
Reply-To: cgra@se.alcbel.be


I was a novice Forth user once (weren't we all?) - now I guess you could
call me an ex-user.  Neither transition was voluntary - I was given the
job of programming a piece of test equipment which happened to think Forth,
so I did; for my current task the choice is between C and 386 assembler, so
I use them.  Curiously enough, the test equipment had a screen, keyboard,
and a floppy drive, just like a PC (or even more like my ST, since it had
a 68000 inside); whereas my current task is for an imbedded system. Funny old
world.

To get to the point: I came from a background of Algol/Pascal/CHILL (not C),
sat down in front of a Forth machine with "stream" files, opened a textbook,
and got hacking.  I ended up with a sizeable application which validated
levels 2 and 3 of our X.25 implementation more thoroughly than any PTT had
done (i.e., found bugs they never did :-)).  In the course of doing so I
kind of "evolved" a style out of my block-structured background and the
screen-oriented style of the literature:

: FOO ( -- )
  BAR BAZ JEREMY BEADLE DWEEZY DUP ROT ZOOI ( dig potatoes ) @
;

A lot of the embedded comments were running commentaries on the state of the
stack - if _I_ needed to write it down, then I left it in for any poor sucker
who might have to maintain the code.  (Write-only code is way out of fashion).

Nested control structures?  Didn't seem to need 'em.  For the basic state
machine, I used defining words supplied with the equipment - and added some
of my own.  For the only really logic-intensive part (checking X.25 facilities)
I ended up defining more words than expected - if some great monolithic word
didn't work then I'd split it up for debugging purposes, and once it was
working there was no compelling reason to put it back together again.  And it's
surprising how often these 'sub-words' come in useful again...

I found the "Forth experience" instructive, and I'd happily repeat it.
It will probably affect my coding style in block-structured languages, in the
sense of making my procedures shorter and my nesting shallower.

So if one day you come across an X.25 implementation written in strangely
"horizontal" C, check the author's name...

__________________________________________________________________________
Chris Gray        | Any views expressed are those of the author and not of 
cgra@se.alcbel.be | any organisation with the author may be associated.
From: bs764@cleveland.Freenet.Edu (Fred H Olson)
Newsgroups: comp.lang.forth
Subject: Re: Documenting - blocks source to target
Date: 8 Jan 1993 12:50:32 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: hela.ins.cwru.edu


                                  Fred H. Olson    ( WB0YQM )
                                  1221 Russell Av N
                                  Minneapolis, MN 55411
                                  (612) 588-9532
                                  (Internet: fred%jwh@vx.cis.umn.edu)
 
In a message about blocks vs text files cbbrowne@csi.uottawa.ca
(Christopher Browne) states:
 
>In the case of an embedded controller, there may not BE anything
>connected in the end, aside from an RS-232 connection.  In this case,
>"streams" win out, since there is nothing that even resembles a BLOCK.
>I think that EForth works this way.
 
   Blocks can work fine here without going to 'serial block
emulation'. It is trivial to send blocks as a stream...  (Not so
the other way.) On an old fig based target where I used "insitu
development"  ( compiler is on the target and source downloaded
serially *) it worked like this. The word like LOAD on the target
simply expected a stream of source code. However there was some
protocol with control characters and error checking (the latter
really wasnt needed in the situation). The target compiled
whatever came along till the control char for the end was
received. On the host the source code blocks were sent with a
'SEND block' completely analagous to a LOAD block.  One feature
of such a system was that the host could filter the blocks before
sending them -- not sending 'trailing spaces' or anything after a
;S on a block for example. I even contemplated putting some
conditional compiler like features in the SEND routine.
 
Certainly text files would work fine for this, but so will
blocks.
 
* I have a 1988 8K text file describing my insitu development
approach to low budget embedded system development.  If anyone is
interested, contact me.  I still use this system in tandem with
LMI's metacompiler for the best of both worlds.
 
Fred
-- 
Newsgroups: comp.lang.forth