[Oberon] Re: N-O Scanner structure confusing ?
easlab at absamail.co.za
Sat Feb 10 09:17:00 MET 2007
> > > Here's a simple job which I can't acheive -- directly yet.
> > > 1. set the caret
> > > 2. scan from the caret until the token "END"
> > > 3. reset the caret after the found token.
> > >
> > Texts.Scan(S);
> > IF (S.class = Texts.Name) & (S.s = "END") THEN
> > TextFrames.SetCaret(F, Texts.Pos(S));
> > Some longer fraction of Version4 code, leaving out full
> > preconditioning related to the frame:
> > PROCEDURE Do*; (* Test.Do *)
> > VAR F: TextFrames.Frame; S: Texts.Scanner;
> > BEGIN
> > F := Oberon.FocusViewer.dsc.next(TextFrames.Frame);
> > IF F.hasCar THEN
> > Texts.OpenScanner(S, F.text, F.carloc.pos); Texts.Scan(S);
> > WHILE ~S.eot & ((S.class # Texts.Name) OR (S.s # "END")) DO
> > Texts.Scan(S)
> > END;(***)
> > IF ~S.eot THEN
> > TextFrames.SetCaret(F, Texts.Pos(S))
> > END
> > END
> > END Do;
> > In a frame viewing all lines of this procedure at once
> > place the caret within these lines in front of the first "END"
> > which is of class Texts.Name (before "(***)"), invoke the
> > "Test.Do" command, the caret should show up
> > just to the right of the semicolon that follows this "END".
> > Invoke the command again and the caret jumps to a position
> > behind the next END.
Bob Walkden wrote:-
> I use the ETH version for Windows, and the native version on bare
> Intel hardware. N-O does not seem to have Oberon.FocusViewer.
> Anybody know where the FocusViewer variable is in N-O?
If I had ETH version for Windows and time perhaps I'd examine
what "Oberon.FocusViewer" does; and then see if N-O needs/has
the same requirement.
Re. TextsScanner being designed for command parameter read,
and not used for the compiler, it's difficult to prove a
The compiler seems to have over 20 modules.
The algorithm to search if/where the compiler uses the TextsScanner
to get the tokens is interesting:
1. Watson.ShowDef Compiler.Compile == shows <list of imports>
2. Search in <list of imports>.Mod for "Texts.Scan"
3. and list the containing PROC names
4. manually examine the <list of PROC names> for a likely
'get next token' task.
5. manually analyse the containing code.
And back to the original question, let's use a more theoretical
Q- is it true that the Scanner is a descendant of the Reader ?
Q- and that the Scanner 'uses' its parent to step&read as part
of its scanning task ?
Q - and that if the reader's char-position was publicly
available, this would relate to the scanner's token position,
since the scanner uses the reader ?
Q - but the reader explicitly makes the read-postn-variable
unavailable; isolating it via a function [procedure] ?
Thanks for any feedback,
== Chris Glur.
PS. for the first time 'TextMail.Directory' locked, for me.
Luckily, with the recent Transmit authenticate requirement by
my ISP I had investigated using Telnet to 'manually step'
the pop-server. BTW when I occasionally look at the
Transmit-authenticate field of mails which I've received, I never
see ANY that are authenticated ? Except for ones which I've
sent. I'm guessing that the ISP is putting a special requirement
on me because I don't use M$-outsp00k !!
It was a big problem to 'unlock TextMail.Directory' :
I've got 2 'names' and the one directory had no problem.
Also from watching the modem lights, I could see that some of the
first few dir-entries were down-loading, before it locked.
Under N-O I could use <Ctrl/Break> to escape the lock.
A finer point is that the 'down-loaded but not yet displayed'
dir-entries I think can be seen at the head of the next download;
but which I didn't confirm.
Under linux-ETH-Oberon, I could not recover. I need to setup
an interupt, mentioned in the documentation
Currently I've got about 40 mails which I leave on the server,
and via telnet I could see that some mail after No.50 was causing
the SERVER TO HANG. Ie. also with telnet the server was hanging.
So it seems not to be a N-O problem. I suspect it was one of our
ETH-posts re. "sound & video recording and reverse playback...etc.",
because one of the fields was very long and full of non-ascii chars.
Perhaps this bad format only arrived at *MY* ISP.
But I'm interested to know if others also had a bad header.
The reason why I couldn't investigate deeper was:
1. with a dozen spam a day, the job can't be left, while spam could
overflow my box, due to inability to delete.
2. the manual-telnet operation is complex, since after deleting, the
higher numbered mail 'fall down to fill the hole', but only after
3. On line costs.
More information about the Oberon