February 2003 - Oberon - mailman3.inf.ethz.ch

Re (4): [Oberon] PPP
by peter_easthope＠gulfnet.sd64.bc.ca 14 Feb '03

14 Feb '03

Edgar & Chris, es> So the question would be whether Chris could trace PPP and get some log which shows this going down. Chris, before collecting the log you might compile in my modification which numbers frames. This will allow any discussion, between you and Edgar for example, to refer to "frame n". That should be easier than saying "Look at the frame containing this hex string '...'". I don't remember which module but it is described in my PPPnotes Web page. es> Then I could find out perhaps where some action is missing. Edgar, are you hypothesizing that somewhere near the end of the session PPP should reset the modem and then relinquish the serial port? Presumeably the modem reset would be done by a counterpart of Dialer.Dial; Dialer.Hangup or Dialer.Close? Then the serial port would be relinquished by the hypothetical uninstall procedure which is absent from NetBase? Regards, Peter E. Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Re (3): [Oberon] PPP
by Edgar＠EdgarSchwarz.de 13 Feb '03

13 Feb '03

Chris and Peter wrote: > cg> * After a ppp session, V24.Panel cannot be opened - need to first re-boot. > > * Apparently V24.Panel wants the port to be found as being closed ? > > * I use this: > > PROCEDURE CloseCOM2*; ... > > This Remove procedure is from PPPMain.Mod. > Note Edgar's comment. > > (* Remove - Remove the PPP-Instance completely *) > PROCEDURE Remove*(VAR id:PPPid); > BEGIN Stop(id); > (*es??? no unistall for devices in NetBase found > id.task.UnInstall; (* Remove Task *) > PT.UnInstallDevice(id.me); > es*) > id:=NIL; > END Remove; > > Chris, are you and Edgar referring to the > same defect? Perhaps Pieter can incorporate > a repair in NetBase in the next release. If > that works we can proceed to use it in V24 > and PPP. Hi, I'm just reading at the moment because I'm working on WebDAV. One thought concerning something Chris wrote: If it's necessary to close the serial port after an interruption it's necessary to know in which state PPP is. In theory IIRC the PPP protocol has timeouts and goes back to some initial state. Perhaps in this state transition the serial port isn't closed. So the question would be whether Chris could trace PPP and get some log which shows this going down. Just the end of the log would be of interest I guess. Then I could find out perhaps where some action is missing. Finally I want to remember Chris that I'm inviting him to state such problems in my Oberon forum. See my signature. The advantage in comparison to the mailing list for me are the following: - Information concerning PPP in the mailing list is distributed. In the forum it would be concentrated. - I will get a personal mail if an article is entered. - I can edit the material if necessary so that it makes sense for others to read. Cheers, Edgar -- edgar(a)edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein

1 0

Re (2): [Oberon] PPP
by peter_easthope＠gulfnet.sd64.bc.ca 13 Feb '03

13 Feb '03

Chris, cg> * After a ppp session, V24.Panel cannot be opened - need to first re-boot. > * Apparently V24.Panel wants the port to be found as being closed ? > * I use this: > PROCEDURE CloseCOM2*; ... This Remove procedure is from PPPMain.Mod. Note Edgar's comment. (* Remove - Remove the PPP-Instance completely *) PROCEDURE Remove*(VAR id:PPPid); BEGIN Stop(id); (*es??? no unistall for devices in NetBase found id.task.UnInstall; (* Remove Task *) PT.UnInstallDevice(id.me); es*) id:=NIL; END Remove; Chris, are you and Edgar referring to the same defect? Perhaps Pieter can incorporate a repair in NetBase in the next release. If that works we can proceed to use it in V24 and PPP. cg> I can't reset/initialise a modem more than by powering-down. If your dial script contains ATZ that should reset the modem each time Dialer.Dial is invoked. Regards, Peter E. Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Re: [Oberon] PPP
by eas-lab＠absamail.co.za 13 Feb '03

13 Feb '03

I'm taking this thread to the NewsGroup too. Do any V4 users also use PPP ? > cg> ... further dial-ups fail to dial the modem !! > .... the 'system' is caught in an unanticipated state. > .... The modem lights react, but no dial tone is available. > > peter_easthope(a)gulfnet.sd64.bc.ca wrote: > I wonder whether the modem simply fails to > get initialized properly again? Also, I still > don't understand very well what happens to a > serial port in this case. PPP.Log should help. I can't reset/initialise a modem more than by powering-down. It could be of interest to use the V24 terminal facility at this stage to manipulate the modem directly, i.e. not via the 'ppp & dialer'. This can't be done. And the reason why , is an example of what I'm suspecting is the (seldom occuring) ppp problem which I described. * After a ppp session, V24.Panel cannot be opened - need to first re-boot. * Apparently V24.Panel wants the port to be found as being closed ? * I use this: PROCEDURE CloseCOM2*; BEGIN PrtLine('Close COM2'); V24.Stop(1) END CloseCOM2; * after CloseCOM2, V24.Panel can open and close port(s), repeatedly. That the ppp/dial-up sequence does not leave the 'system' in the reset stage (of the FSM) when it's finished is what I'm refereing too. With the ppp/dialer, serial-port, modem ... etc, you have several nested FSMs ! The 'fail to reset after unusual error' which I described in my previous post, is analogous to the 'fail to reset for V24.Panel usage after ppp-usage' which I describe above. Debugging the 'ppp-hangs problem' is further complicated by: * now that the weather changed, my system does not fail at the previously described critical point. { I could perhaps simulate a poor line to get back to the error.} * each test run cost an extra phone call charge. What needs to be done is to ask at each state of the ppp/dialer: if the line is cut now, will the system fail so as to be able to restart ? I.e. will it get back to the initial/reset state ? The problem is not one of failure, which must be expected, but rather one of how the failure is handled. Parhaps M$-Win users accept that re-boot is the solution ? I don't. -- Chris Glur.

1 0

Garbage Collection in Aos
by Paul Reed 12 Feb '03

12 Feb '03

> From: Pieter Muller <pieter.muller(a)alumni.ethz.ch> > > ...tasks would need to be prohibited from doing anything that would affect > > the heap. I would imagine > > that there is a large class of RT problems > > that could be handled this way, but this > > would require much programming discipline. > > But I agree, implementing an incremental GC > > is the best overall solution. > > Even worse, such tasks are not allowed to *use* pointers, since the GC > modifies all pointers while traversing the heap. This is due to the > pointer rotation algorithm. Yes, I forgot this recently when I made changes to my GC to support walking the stack - duh-oh!. And I forgot that I had made an assumption about pointers only pointing to the beginning of heap blocks, rather than anywhere in their interior - duh-oh again!. But the great thing about the Schorr-Waite algorithm is that it is beautifully simple, although apparently not simple enough for me... :) Pointers are only reversed inside complex structures, so if you had a root variable which pointed directly to a flat buffer, the buffer would be marked, the traversal of pointers would be complete, and GC would move on to the next root. If at interrupt time, the notion of a "current buffer" was used but not changed, that would be ok. If you have buffers in a doubly-linked list, you could go one way with Oberon pointers and the other way with SYSTEM.ADRs. Sounds kludgy, but we are talking about device-driver-land. If buffers are in a least-recently-used list, this may in fact make even more sense. Oberon's module list and file list use untyped pointers to side-step the GC. It may be that untyped pointers are actually used anyway from time to time, if they are referred to at the lowest level by hand-optimised machine code... :) The original Oberon system shows that careful design under a partly-restrictive set of criteria can lead to dramatically reduced complexity of the entire system. I am happy to take extra care when writing device drivers if it means that the system ends up being simpler as a whole. Paul Reed

1 0

I have returned to the fold. Slay the fatted calf!
by Soren Renner 11 Feb '03

11 Feb '03

Colleagues: My new box is running the 1/29/03 Bluebottle. Please welcome me back to our little community. Already a voxel renderer is running -- soon you can see it. sr

2 1

It beats me...
by rotaru＠centrum.cz 10 Feb '03

10 Feb '03

The previous mail was sent (unvoluntarily) when it wasn't finished. It is not even signed. Essential: the code (if someone wants it) is in the attachment of previous mail. Hope this may help someone (May be even me :) Vasile Rotaru -------------------- Darujte k Valentýnu Modré z nebe od Orionu. Pošlete zdarma přání, loga a melodie na mobil! http://user.centrum.cz/redir.php?url=http://www.orionmodreznebe.cz

1 0

RE: Input.Time
by Michael A. McGaw 10 Feb '03

10 Feb '03

Hello all: I too, use NO in real-time applications, and have a two commercial applications that utilize NO in data acquisition and servo control. I have also spent a fair amount of time implementing a version of the task handling as described by Wirth in his Tasks vs. Threads paper, and see this as a potentially viable path for those who need pre-emptive facilities, within a given class (tasks that have no context to preserve across many activations), using NO as the basis. This is very attractive, as NO is impressively powerful, but is compact enough that it can be understood and modified by one person. BB appears to follow this philosophy as well, and this is a major attraction. I agree with the comments of Dr. Sedlacek, in their entirety: NO and BB certainly have application to real-time projects. However, a serious consideration of which classes of real-time BB may be suited to is warranted. The impact of the GC on deterministic system behavior cannot be underestimated. I can understand the reasons as to why the current GC implementations are in use: when NO and BB are used as testbeds for the trial of concepts and approaches of compiler technology or other systems-level notions, a _functioning_ GC is sufficient. It is when we discuss hard real-time needs that the GC is found to be a significant issue. I personally can see great application for BB in hard real-time: I can easily envision applications in which one CPU is loaded very heavily handling multi-loop servo control and data acquisition. Another CPU would be free to offer additional services that are tightly time coordinated with the first, but that could not be accomodated as background tasks due to resource utilization. Now, there is an argument to made that faster CPUs come all of the time, and one might just wait to use a faster CPU (as the primary). The problem is, designers wish always to take advantage of this performance increase. Here, the problem is not neccessarily software largess in the commonly understood sense, but, compact software that requires increasing compute bandwidth. Another use for the multitasking (if not multiprocessing) is in applications in which a given task must be preemptable, and yet must preserve its state or context. Here, I am thinking of (a kind of) binary tree processing that is regularly, periodically interrupted (e.g., hard deadlines) so that I/O can be performed based on the tree processing result at that time, and where the state of the recursion must be preserved. This latter example is all but impossible to implement under NO, as far as I have been able to see, but could be easily done in BB. I have not studied the internals of BB to know what may be possible, but, I have considered the following with regard to NO, and its GC: 1. Remove automatic GC, and instead implement the calling of the GC under user control. This must be done with care, as some system elements require calling GC periodically to function properly. 2. Examine the core system for object usage, and redesign, where necessary and possible, using only statically allocated structures. Without the interface handling, the need for dynamic structures diminishes, and, in some embedded systems, the interface is dispensed with. This approach leaves the management of the GC totally at the user's descretion. 3. Remove GC and use Dispose (!) 4. Implement some type of incremental GC, that is bounded (e.g., deterministic) in its behavior. I have done 1, upon occasion. 4. appears to be the most desireable state of affairs, from my perspective. I would think that 4. would be a very interesting project, unfortunately, it is beyond my skill (I am trained in aerospace engineering, not computer science). An enterprising student may find this problem an attractive project, however(!). Thanks, Mike Michael McGaw, Ph.D. McGaw Technology, Inc.

3 2

Re (2): [Oberon] PPP
by peter_easthope＠gulfnet.sd64.bc.ca 10 Feb '03

10 Feb '03

Chris & others, cg> Yes thanks. PPP ... Welcome. The notes put some of my Christmas "break" time to good use. cg> A problem which rarely occured in the past, now happens daily for me. Apparently because of telco line degradation. Chris, could this be a problem with modem initialization? Have you tested with the V24 panel as described in my notes? You might also test with Kermit. cg> ---- up to here is OK, then the following 2 lines do not occur: End of script IPCP is finally ready. Device opened. Trials against the Vicom router in GulfNet ended the same way until I discovered the lack of DNS negotiation. Refer to the notes on my Web site. cg> ... further dial-ups fail to dial the modem !! ... the 'system' is caught in an unanticipated state. ... The modem lights react, but no dial tone is available. So the modem is external. That should help. I wonder whether the modem simply fails to get initialized properly again? Also, I still don't understand very well what happens to a serial port in this case. PPP.Log should help. cg> Obviously I've tested several modems and computers and n-o versions. Good tip. My notes could list specific models of modems and init strings which have tested OK. cg> Can someone point me to a broad overview of PPP before I analyse the RFCs and source code ? Yes, the RFCs are tough going and I have yet to find a good overview of PPP. The UBC Bookstore did not have the O'Reilly book on TCP/IP (ISBN 0-596-00297-1) when I checked. Someone please let us know what it has about PPP. Regards, Peter E.

1 0

Re: Some questions about BB evolution.
by eas-lab＠absamail.co.za 10 Feb '03

10 Feb '03

> > Even with 'zero cost' hardware (redundant machines > > from 1st world) > > usage will not grow without applications. > > Net-working (email & > > newsgroups: fidonet is strong in ex-soviet > > countries) would drive usage. > > I remember the days when 300 Baud connection speeds > > were OK. > > I believe that a minimumal cost modem - manchester > > modem perhaps - > > could suffice for < 2400 Baud. I've tested the > > transmit side driver from > > a par.port via a few resistors: D to A; and > > speculate/hope that the > > receive side is doable with minimum cost. Since > > the ex-soviet countries > > have functioning telephone networks with low > > charges, minimal cost > > networking could build oberon user base ? > John Drake wrote: > At such low speeds you can skip the phone company > and go with packet radio. > Yes, packet radio is good for low-density (rural), but it doesn't fit the near zero cost model ? I guess old modems get lost & discarded easier than computers because of the size ? So a new modem needs to be bought ? I guess 20 redundant computers could be bought for the price of a packet radio installation ? In asia and africa packet radio is applicable, but ex-soviet countries HAVE a functioning telco network. > > Can any one remember when data was stored to audio > > cassettes ? > > Yes. It was a very bad experience for me. I had > a trs-80 Coco. I had to balance the slow tedious > process of saving programs with the very real > prospect of a power drop. (I lived in a rural > area). It's very difficult for a US resident to appreciate the value of minimal vital information when we are bombarded with masses of garbage. Imagine yourself 300 years ago, on a hill top in England scanning the sea-horizon for the ship returning from distant lands: a timely single-bit of information - perhaps by a flag, could determine your life's savings ! > > I had a cassette version of a subset of Pascal from > > Microsoft, with a > > 10 page A4 pamphlet, for the Z80 based TRS. The > > software consisted > > of a small p-code interpreter, and the compiler was > > directly from > > Wirth's book. It was better than n-o, because as > > the source was > > scanned it was written to display, and just stopped > > at the error! > > I really think 'smart compilers' that claim to find > > multiple errors are > > a bluff. > > > > I don't see how you can charecterize that as > "better". Getting a compiler to stop at the first > error is trivial to do. With a "smart compiler" > you can still treat it as a "dumb compiler" if > you so wish. All you have to do is work from > the top down, only fix the first error and > recompile. Well, the first time n-o compiled in 2 miliseconds instead of 2'000 I was impressed at the 1998ms. saved. But after I had to select the position number and MM 'locate', I was less impressed. I suspect there is great value seeing the source code scroll past, during the recursive descent compilation, as it helps imprint the sources 'structure' on the mind. The newish popup facility to easily locate PROC <id> suggests that others besides me get lost in navigating even small source code. > But after gaining some familiarity > with the language and system being used I've > found that you can be much more productive with > the smart compilers. I always start at the > top of the code and work my way down fixing > compile errors. That way if the error I'm > looking at was actually produced by something > I just fixed higher in the code I'll already > be aware of that and move on to the next error. > Also compilation is so fast in Oberon that > it's practically instant. Since the compiler > and editor are much better integrated than in > the "Pascal" days it's more of an "edit/test" > cycle then an "edit/compile/test" cycle. In the days when you had to submit and wait for a compilation it might have justified trying to fix multiple errors. Now it's not. And it discourages successive refinement - small steps. -- Chris Glur.

2 1