August 2002 - Oberon - mailman3.inf.ethz.ch

screen scrolling and some idle talk
by Yuri M. Skripkah 05 Sep '02

05 Sep '02

Helo, All. Anybody know how to make horizontal and vertical scrolling for whole desktop(framebuffer)(for all TUI GUI Desktops) in n-o, as it is in X Window or some NT(tm) videodrivers? This may be useful for users with old monitors without affecting spirit of big screen. (* And in addition: Sorry, but mailing list content divided into two stream: a) ask about some definite topic and b) idle talk about marketing issues. IMHO for attracting new users ( if this goal is at all ) is more better publish all documentation in one tree in Oberon site as html (most of potentially users have web-browser :)),than extend support for various mouses. Now part of documentation is on paper in books, part hidden in articles, part in ps files. It is in dependence with copyright, of course, but may be one source is possible? And other problem with documentation including in installation is it intermediate level. It is not for full dummies, but not contain a lot of algorithmic grounds (source not give all grounds and not quite readable even by Oberon language ), especially in kernel. This make some difficulties for non-purposeful or busy user :( ,but: I think developers in ETH have not enough lifetime to support this users: it is their lifetime.*) -- Yuri mailto:yurix@i.com.ua

2 3

Re. [Oberon] Reason for 'read pio error' ?
by cglur＠onwe.co.za 31 Aug '02

31 Aug '02

Andreas wrote: > Currently I use a 5GB partition for Bluebottle. While trying to format a > second 5GB partition with AosFS I got an error '2820' at lba 12991229. > > Some source code reading revealed the origin of that error code. It comes > from the procedure "ReadPIO", which is part of module "AosATADisk". "2820" > means "pio read error". As I understand it, the pio protocol is used to > communicate with the hard disk. > > Does anyone know what is a typical reason for such an error? My first guess > was a bad block on the hard disk. However, a modern IDE hard disk (it is an > IBM-DARA-218000) should handle bad blocks at the hardware layer. For > example with something like transparent bad block swapping. > > The only workaround I currently know is to define a small partition that > includes the conspicuous block. This partition will not be used. Since the > number of partitions is limited this is not a very good workaround :-( ? number of partitions is limited ? Is this the Microsoft limit of 4 ? Under native-oberon I use dozens of partitions - as directories. Linux would check for 'bad blocks'. And I guess native-oberon does too, during format. Since Micro$hit's policy is to squash all other OS's, perhaps best give it the prime location of the first partiton(s), and let the others 'hide behind the fence'. For those who dare to step outside M$ limits with PC's, it's good to be allied with linux. There are many soldier to clear the way for you. Pioneering a new OS together with a new computer/IDE is daring. -- Chris Glur.

1 0

Reason for 'read pio error' ?
by Andreas Dörr 31 Aug '02

31 Aug '02

First of all, I want to congratulate everyone involved in the development of Bluebottle for coming up with such a great and promising system! I also appreciate, that the source code has been released under a respected open source licence. I have successfully installed Bluebottle on a Dell Inspiron 7500. Currently I use a 5GB partition for Bluebottle. While trying to format a second 5GB partition with AosFS I got an error '2820' at lba 12991229. Some source code reading revealed the origin of that error code. It comes from the procedure "ReadPIO", which is part of module "AosATADisk". "2820" means "pio read error". As I understand it, the pio protocol is used to communicate with the hard disk. Does anyone know what is a typical reason for such an error? My first guess was a bad block on the hard disk. However, a modern IDE hard disk (it is an IBM-DARA-218000) should handle bad blocks at the hardware layer. For example with something like transparent bad block swapping. The only workaround I currently know is to define a small partition that includes the conspicuous block. This partition will not be used. Since the number of partitions is limited this is not a very good workaround :-( Kind regards, --Andreas

2 1

Native/Alpha Install to FAT file
by Charles Angelich 31 Aug '02

31 Aug '02

The install for Native/Alpha to a single FAT file is less "user friendly" than the previous Beta install. I would hazard a guess that 1 in 10 would be able to install Alpha to a single FAT file. Once installed the assumption that the addon Zip files are already copied to the system directory is premature since there are no commands listed to put them there. I would think new users would have little to no idea how to unZip these into the sytem directory using what "clues" are available to them from within the included System.Text. In short, the intall is _capable_ of working but it's unlikely to work for new users unfamiliar with ETH Oberon. It seems that my suggestions were _reversed_ to make installs by average persons even LESS likely and more hazardous for those who do not fully understand the software they used to download Oberon with. The additons of "SYS:" to the filename for each file in the System.Directory is almost insulting considering the amount of available space for display in the system track display. My first impression is that this is a disappointment after two years of waiting the two years don't show an improvement. Possibly this is a "joke" release? Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

1 0

RE: Oberon digest, Vol 1 #57 - 10 msgs
by Frank van Riet 30 Aug '02

30 Aug '02

Hi all I', really happy that I sparked some productive discussion which does not revolve around mice and fonts :) ! I'm really uncomfortable with trying to hide the size of variables i.e. having a single integer type. I feel that this actually detracts from the portability of the code. In representing numbers we have physical representations of abstract entities. We only have a finite number of bits available on a given machine. That in itself is usually not a problem, the problem arises when we have need to port code to a different machine as was pointer out by Patrick. Most people are aware of the architecture specific nature of C's "int"-type. I believe programming should be very pedantic. In fact, in a programming language on which I worked we did away with "generic terms" for integer variables. The basic integer types of the language were UINT8,INT8 UINT16,INT16 UINT32,INT32 The sub-class super class semantice are the same as for Oberon namely a larger integer type contains the smaller type. Signed and unsigned types are incompatible. In fact the concept was taken even further to contain explicit set sizes: SET8,SET16 and SET32 Internally operations are still performed on 32-bit sets, but does the necessary conversions on loading and storing. As such it is mostly syntactic lolli-pops, but does get rid of all those ghastly SYSTEM.VALs The benifit of all this is that it is easy to extend to say UINT64 of INT128 to add support for new architectures without breaking existing code or the other way around. In the interim the most sensible solution would be to simply write a separate module for each architecture, that implements unsigned operations and types. Patrik don't worry I don't expect changes to Oberon any time soon. It's just ideas being tossed around. In the final analysis that why were here :) Frank --------------------------------------- Frank van Riet (Software Developer) Datavoice (Pty) Ltd Snail mail PO Box 582 Stellenbosch 7599 South Africa Tel +27 21 888-2118 Mobile +27 82 970 5704 Web http://www.datavoice.co.za ----------------------------------------

4 3

DISPOSE
by Gérard Meunier 30 Aug '02

30 Aug '02

Hello, Garbage collection is a blessing for most programmers, and makes system and applications more robust. But sometimes it's a bane. I've written, in Bluebottle, an interpreter for a language whose one of most important features is that it produces no garbage. It allocates a lot of stuff in the heap, but it knows exactly the lifetime of each chunk of memory. Therefore it would be very interesting and efficient to dispose memory by hand. Is there any way to do that? Thanks for any help. Gérard

1 0

Unsigned comparisons
by muller＠inf.ethz.ch 29 Aug '02

29 Aug '02

Frank van Riet <Fvanriet(a)spescom.com> wrote: > A stack pointer > (for instance) is an unsigned value the size of a machine word -period. Just a quick hint. To compare two stack addresses a, b: LONGINT, you could use: SYSTEM.LSH(a, -2) < SYSTEM.LSH(b, -2), since the addresses are always multiples of 4. LSH is a logical (unsigned) shift. -1 instead of -2 will also work. This is much more text than a, b: CARDINAL and a < b, but the code is not significantly slower on a modern processor. Defining an inline UnsignedLess(a, b) CODE procedure is also an option, but is not portable to non-Intel ETH Oberon systems. BTW Someone mentioned that the bit order of SET is implemented differently in different compilers. This was the case with the PowerPC compiler, but in the meantime Günter Feldmann has fixed this. If you use the latest releases, in low level code you can now assume that SYSTEM.VAL(LONGINT, {0}) = 1 on all current ETH Oberon systems. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re (2): [Oberon] Tracing Oberon-0 boot problems
by muller＠inf.ethz.ch 28 Aug '02

28 Aug '02

"Douglas G. Danforth" <danforth(a)greenwoodfarm.com> wrote: > Summary: > 1) Booting with keyboard connected to USB fails (no cursor) > 2) Booting with keyboard connected to USB to round converter works > to the extent that cursor and mouse work but keyboard does not. > 3) Once booted, reconnecting keyboard directly to USB makes keyboard work. > > USB handler for keyboard definitely needs upgrading. It would help if you could trace the problem some more on an installed system. Try adding debug output to the Usb*Mod modules to find out where exactly it is hanging. Good to see that you at least found a workaround to install the system. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re: [Oberon] (no subject)
by muller＠inf.ethz.ch 28 Aug '02

28 Aug '02

"Frank van Riet" <Fvanriet(a)spescom.com> wrote: > 3) Dynamic array headers: Why was the decision made to to stick the header > in the middle of the structure > and not in-front as with other structures. Not only is it > non-intuitive nit having the pointer point > to the firts element, but it would also make language > interoperability very difficult. Let alone the > nightmare of porting older code in which this was not the case... I think the heap structures are evolutionary and there were some backward-compatability issues. Remember that the Ceres GC didn't support pointers in array elements at all. Re-doing and simplifying the heap structures would be a nice improvement. > Again I'm doing system programming, where we really don't use GC, so if I > want to pass a > pointer to an array to a C rountine (say) I don't want the GC specific stuff > to get in the way. A workaround is to declare the parameter of the C procedure as a LONGINT in the Oberon signature and pass the address of the first element: SomeProc(SYSTEM.ADR(arrayptr[0])) > To conclude. Let me be clear about this. I work in Oberon every day, and I > enjoy it. That does > not mean that one should not think about what goes on behind the scenes, and > what the reasons > are (or agree with all of the choices). If anything this will only make us > better programmers. Good to hear. I wonder how many of us here use Oberon every day? > Would anyone who'd like to write > a runtime system in Java please raise their hands :) This is not so far-fetched. Java is used for embedded systems work, and there are even Java VMs written in Java (with some interesting bootstrapping): http://researchweb.watson.ibm.com/jalapeno/ -- Pieter P.S. The absence of unsigned numeric types in Oberon is one of the perennial topics in Oberon discussion forums. Search a bit in comp.lang.oberon a few years back: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.lang.oberon Some others are: the absence of enumerated types, System 3 vs. V4, the 3-button mouse interface, the flat file name space, the absence of processes, extending the user base. So much for progress :-) -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Future of Native Oberon and Bluebottle
by muller＠inf.ethz.ch 28 Aug '02

28 Aug '02

Stefan Salewski <Salewski(a)physnet.uni-hamburg.de> wrote: > To gain new users (and developers) outside of ETH, the following may > be usefull: Thanks for these suggestions. > - A clear statement of ETH about the planned future of Native-Oberon > and BlueBottle. While I can obviously not speak for the ETH and Prof. Gutknecht, I can give you my opinion. > I think that the Active-Oberon-Language with BlueBottle-OS is very > interesting. But at the same time I fear, that ETH-Oberon will die if > the big ETH people like Pieter Muller and Patrik Reali will leave ETH. In a sense, both of us have "left" the ETH some time ago already :-) E.g. I stopped working as research assistant in December 2001 (as can be seen on my home page). You'll find I am now listed as a "voluntary contributor" on Prof. Gutknecht's group page. This is basically the same status that André Fischer, who is retired and works on Oberon documentation and user support as a "labour of love", has had since 1994. If all us ETH Oberon oldtimers should stop working on Oberon, I think among the current users there are several programmers who could take over maintenance and development of the system. I'm certain Prof. Gutknecht at the ETH would be happy to provide resources (e.g. web hosting) for the continued development of the Oberon system. Even if that is not the case, since Oberon is freely released under a BSD-style license, anyone could "pick it up" and continue development. Bluebottle is currently being developed actively at the ETH by two assistants (Thomas Frey and Bernhard Egger). It still largely depends on Oberon for Aos as development environment. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0