(Re: [Oberon] Programming Editor) & etc.

[eas-lab at absamail.co.za]

Aubrey McIntosh wrote:

> Can some kind soul provide a Tool (or name some existing ones) that
> have a few relevant commands for the { Edit Compile } Store cycle?

I got no reply to the same questions.
Eth 'insiders' are obviously hiding the good stuff from us.
I recently revisited 1980's DOS Turbo-Pascal Edit/Compile/Store
facilities  - much more productive than what I have to use with S3.
That's why I don't do oberon programming.
S3 is superb for general text handling;  why such weak programming tools?
I can't believe that eth 'insiders' use what we are offered ?

peter_easthope at gulfnet.sd64.bc.ca  wrote:

> In PC Native 24.08.2002 my Oberon.Text:System:
> InitCommands contains "ET.ReplaceSystemEditor" 
> yet MM+MR on a file name opens Edit.  Do I have 
> something configured incorrectly; is this a
> repaired bug or a pending repair?

For me MM+MR opens the editor type: Edit/ET/Sctript/Desktops;
according to the type which 'contains' the file name.
OK !   But not for ET.   Seems to be an inconsistency.
I'm using ver. beta?alpha 2001.
I'd be interested to know the mechanism whereby
MM+MR DOES opens an editor of the same 'type'  as where
the MM+MR was executed.
Where is the system wide mouse handling done ?
An early tutorial showed how MM <Module>.<Proc>
caused the M.P to be executed.  I guess the MM+MR
handling is related to this ?

> Friday, 2002-07-19 Chris Glur suggested,
> cg> You shouldn't try writing video drivers 
> before doing simpler experiments.  Use 
> successive refinement.  After you've done 
> RS232 and UBS 'experiments' you will better
> cope with a video driver.
> 
> A reasonable suggestion, although I have no 
> USB hardware yet.

Nor I. Nor do I know what UBS is; except that as a 'few-pin'
interface replacing the serial port, it must be much simpler than
a video driver.

The correct route to start from zero experience for writing
hardware drivers is:
 * get hands-on-feedback as soon as possible, by exercising the
  simplest case.  The PC-speaker is ideal. Unfortunately our 
http://www.oberon.ethz.ch/speaker.html is a dud, because it
introduces much irrelevant complications.
  * the next hardware that can be played with, without crashing
the machine is the parallel port.   Again, results must be observable.
A speaker (isolated via a capacitor) can give observable output.
Parallel port can also exercise inputs. 
After this it's time to be able to see voltage changes caused on
outputs: voltmeter, oscilloscope ....etc.
  * Even if you use n-o's : "s := s - {0, 1}" syntax, you have to think in
terms of bits, bytes, registers - not sets. 
I.e use the terminology & paradigm of the hardware device/card 
suppliers.


> I spent a good part of the Christmas break 
> studying RFCs and Edgar's PPP modules.  It 
> was a good learning exercise and this system 
> can now connect to the GulfNet Vicom router 
> once again.

Is it difficult to condense your newly aquired knowledge and
explain what the problem was and what are the essential steps
and material to cover, to understand the ppp process ?
Eg. a sequence of: "Doc: xyz explains xxx, which is essential."

Even knowing exactly what to read is a big part of the knowledge
of having researched something.

-- Chris Glur.