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

Slim Binaries - what happened ?
by Bernhard Treutwein 10 Oct '02

10 Oct '02

Once upon a time there was Slim Binaries for Mac (as opposed to Fat Binaries, where the executables contained both the 68000 and the PowerPC instructions). As far as I understood it it was the compressed parse tree of the compiler, which was compiled on the fly during the load by a so called compiling loader dubbed OMI (Oberon Module Interchange ?). It was also ported to the Intel architecture. In that time we had portable code for really different platforms. As far as I understand, OMI is now history and not implemented in the current ETH Oberon system, although it referenced heavily in the "Oberon Companion". I ask myself, why did is it dead ? More info about Slim Binaries: http://www.ics.uci.edu/~franz/SlimBinaries.html If I understand the compiler genealogy (http://www.oberon.ethz.ch/compiler/) correct, I guess that OMI has never been updated to the "enhanced" features Patrik Reali implemented. Is there any principle problem with that ? regards Bernhard

3 2

Native 24.08.2002: Compiler Bug
by Stefan Salewski 07 Oct '02

07 Oct '02

Hello, I think there is something wrong with the DIV statement. ========== MODULE StSTest; IMPORT Out; PROCEDURE Do*; VAR i,j,k:LONGINT; BEGIN Out.String("Output is:"); Out.Ln; i:=10; j:=3; k:=-(-i DIV j); Out.Int(k,8); Out.Ln; i:=-i; k:=-(i DIV j); Out.Int(k,8); Out.Ln; END Do; BEGIN END StSTest. StSTest.Do ~ Output is: 3 4 ========== Best regards Stefan Salewski

3 4

Re: Re. [Oberon] PC Makers Hit Speed Bumps - Oberon opportunity
by Antony Tersol 07 Oct '02

07 Oct '02

C had some initial success because it was the language in which Unix was written. In the late '70s, Unix was given away by AT&T to universities, where it enjoyed popularity in computer science departments. If one wanted to understand Unix, one had to learn C. Remember, this was when systems were moving from batch-processed punch-cards to time-sharing terminals. At the time, AT&T was a regulated telephone company, and was not able to sell computers or operating systems. It was shortly thereafter that the consent decree split AT&T and also removed the restrictions. Some have speculated that AT&T was looking forward to that day by seeding the market with C and Unix expertise. When people graduated and entered the workplace they would continue with what they knew. (The Feds proposed "punishment" for Microsoft includes giving away product to schools. Apple has long had a policy of generous discounts for education.) This was also the time of Apple II computers and UCSD Pascal. After the PC first came out, the trade press carried articles about the OS that would replace MS-DOS. At that time, the leading candidates were considered to be Unix and the UCSD p-system. Now, 25 years later, Linux's small success is built on that early seeding. Unix and MS-Dos grew as the computer industry transitioned from main frames to PCs. Today, the transition is starting from PCs to embedded devices. Other OSs will gain ascendency, but technical excellence is not the only factor. Antony Tersol > Date: Sun, 06 Oct 2002 20:36:06 -0400 > From: "Douglas G. Danforth" <danforth(a)greenwoodfarm.com> > Organization: Greenwood Farm Technologies LLC > To: oberon(a)inf.ethz.ch > Subject: Re: Re. [Oberon] PC Makers Hit Speed Bumps - Oberon opportunity > Reply-To: oberon(a)inf.ethz.ch > > Linux is a collaborative effort that built on an existing > unix base (e.g. SUN OS, IBM AIX, ...). Oberon did not and does > not have that base. > > I must admit that I do not understand why the (seemingly) inferior > almost always wins out. > > If the C language had been developed somewhere other than Bell Labs > would it have suceeded? Politics and momentum frequently overpower quality. > One needs a very strong advocate who is willing to weather the storm to > bring forth what should be "as simple as possible". > > -Doug >

1 0

Re. [Oberon] PC Makers Hit Speed Bumps - Oberon opportunity
by eas-lab＠absamail.co.za 07 Oct '02

07 Oct '02

"Douglas G. Danforth" <danforth(a)greenwoodfarm.com> wrote: > The way I see it, sufficient PC speed was passed 2 years ago > for most of us. Absolutely. A 10 times faster computer, would save me 10 seconds a day and 100 times faster would save 11 seconds -- working with n-o. >The real need is simplicity and reliability. > I can see a real paradigm shift in how software is distributed > and maintained. Well, what is needed has been known and articulated for decades, but the situation seems not to be getting better. > (I am currently struggling with HP-UX and Linux using a company > in-house extension of "make" that coordinates the "build" > of an executable (a fairly large executable)for different > unix platforms. On my slow 50 Mhz HP-UX box to start from > scratch and "make" the system takes 25 minutes! It is > making for only one platform. I calculate that to do > the same "compilation" with Oberon should take 25 seconds! > This does not include the "load time" for Oberon.) Yes, I can't understand what linux is doing with all the huffing & puffing. Of course for an occasional installation, where you can go away for an hour, waiting for it to finish, it's acceptable. What really traumatised me was an attempt to write a little bit more than 'Hello World', which led to a 600 line 'man <compiler ? gcc>' read... to a n00 line 'man make' read... to a m00 line 'man diff' read ...etc. For us, linux is important: * to see how dispersed collaboration can/can't work, * possibly copy some of it's openly available algorithms/ideas, * coming later has the advantage: we can also learn what NOT to do. -- Chris Glur.

4 3

Re: [Oberon] PC Makers Hit Speed Bumps - Oberon opportunity
by eas-lab＠absamail.co.za 05 Oct '02

05 Oct '02

On Thu, Oct 03, 2002 at 07:02:57PM +0200, eas-lab(a)absamail.co.za wrote: > > For us, linux is important: > > * to see how dispersed collaboration can/can't work, > > * possibly copy some of it's openly available algorithms/ideas, > > * coming later has the advantage: we can also learn what NOT to do. Frank wrote: > I think you will find that your idea of who came later is mistaken. Yes I realised this as I wrote it. I'm thinking of who 'trod the path first'. Consider the space of possibilities, covered by a wondering path. Since linux has perhaps one thousand 'explorers' for every one that oberon has. They will have covered nearly all possibilities before oberon. Thank you linux explorers. > The Oberon project dates from the 1980s; "Project Oberon" places it in > the years 1986-1989. "Project Oberon" itself was published in 1992. > The Oberon-2 language report is dated 1993. > > The initial public release of the linux kernel was in late 1991. > According to > <http://www.oreilly.com/catalog/debian/chapter/ch01_02.html> the > first really usable linux OS dates from 1992, a good 3-5 years after the > Oberon System became a practical OS. However, if you count the > publication of "Project Oberon" as the public release of Oberon, then > they are pretty much contemporaries. > > Oberon started as an academic research project and after 15 years > that's pretty much what it still is. Linux started off as a student's > hobby project and after 10 years it is now a serious competitor to > every other major OS. Apparently this supports my contention that a formal approach is best. I don't agree with the conclusion of "the bazaar vs. the cathederal." > So who do you think has worked out what NOT to do? By definition, the one that has travelled the most of the path, would be the first to know what NOT to do. Except that their commitment often prevents them from backtracking. The outside observer who has not yet 'gone down that route' has great advantage in observing the fore-runners mistakes. Yes, if you put microsoft in the sample of 3, then the popularity is consistently inversely related to the 'value'. Which says much about human nature. -- Chris Glur.

1 0

Oberon v Linux, and DIV and MOD
by Paul Reed 05 Oct '02

05 Oct '02

> From: Frank Copeland <fjc(a)wossname.apana.org.au> > Oberon started as an academic research project and after 15 years > that's pretty much what it still is. Linux started off as a student's > hobby project and after 10 years it is now a serious competitor to > every other major OS. > > So who do you think has worked out what NOT to do? > > Frank I agree with you Frank, that Linux is the more successful, by yielding to people's desires to "add more features". There are now no simple versions of Linux. What Wirth and Gutknecht showed us with Oberon, is that people who don't want the extra features shouldn't have to pay for them. See (again) Wirth's "A Plea for Lean Software" (IEEE Computer, Feb 1995). I feel for the maintainers of Oberon, trying to keep it simple, but also having to field complaints that it doesn't have enough features. As a result of long, bitter experience, I am happy to forgo features in exchange for reduced complexity, everywhere that I can. That said, I wouldn't be able to get many jobs done without Linux or BSD. > From: eas-lab(a)absamail.co.za > My re-reading the following post emphasised again the need for > greater formalism:- > > Stefan Salewski wrote:- > > when rounding Reals to Integers we have at least four ways: > This seems also to relate to the recent 'DIV query' ? > I'm guessing (could be very wrong) that the numerical roundings > are defined by 'the matematical authorities', and n-o's task is to > implement those higher definitions. In the case of DIV and MOD, they are often used for rounding and masking, and that practical use seems to take precedence over being faithful to a mathematical concept. For example, hi := SHORT(long DIV 10000H); lo := SHORT(long MOD 10000H); should work even when long is negative; also INC(size, (-size) MOD 4); increases size to the next longword boundary. You see this sort of thing a lot in Project Oberon. But as Pieter says, a lot of these things have been discussed before. Paul Reed

1 0

Appeal for greater formalism vs. quick temporary fix.
by eas-lab＠absamail.co.za 05 Oct '02

05 Oct '02

My re-reading the following post emphasised again the need for greater formalism:- Stefan Salewski wrote:- > when rounding Reals to Integers we have at least four ways: > 1. rounding to -Infinite (floor() in C) > 2. roundind to +Infinite (ceil() in C) > 3. rounding to nearest > 4. rounding to zero > > ENTIER(x) will provide rounding to -Infinite, > ENTIER(x+0.5D0) should provide rounding to nearest, > -ENTIER(-x) should provide rounding to +Infinite. > > IF x>0 THEN RETURN ENTIER(x) ELSE RETURN -ENTIER(-x) END; > should provide rounding to zero. > > Is there a better (faster) solution. > Sometimes I use x:=ENTIER(x+0.5D0). > I guess this is not very fast. > > In http://www.oberon.ethz.ch/native/WebAlpha.html I read: > > > Reals.Mod - Default rounding mode is now towards negative > > infinity (like ENTIER). This allows ENTIER to be compiled much > > more efficiently, because it does not need to set the rounding > > mode. If you set another rounding mode with Reals.SetFCR, be > > aware that ENTIER will also use this rounding mode! > > I do not fully understand this. Which parameters does > Reals.SetFCR() need, which other functions exect ENTIER() does > Reals.SetFCR() modify. > This seems also to relate to the recent 'DIV query' ? It seems to me that there is a heirarchy of authorities, which must be, obeyed. Because 'just hacking it' is such fun, a formalism needs to be in place (like a constitution) to impose discipline. I'm guessing (could be very wrong) that the numerical roundings are defined by 'the matematical authorities', and n-o's task is to implement those higher definitions. > > compiled much more efficiently should be replace by 'overall more efficiently', where the user's time/effort is the overwhelminly major component of overall efficiency. As a recent contributor observed: saving machine cycles seldom makes sense today if it wastes users time -- overall. ======================== Working formally from the 'higher authority' specification is vital for internet usage. > > I could investigate the RFCs, but am reluctant to do so, given my > > perception of ETH's 'management policy': individuals hacking away > > privately and submitting results without feedback/openness. > > Edgar wrote: > As long as it concerns PPP I would be happy to receive bugfixes or > improvements. OK good, but who is concerned with TextMail.Mod ? There's much more than PPP to be looked into. eg. TextMail.Directory expects the number of mails on the server to be supplied, which my new ISP doesn't do. And when other n-o users find they can't connect because of ISP changes, they will just revert to M$. Then everybody can be a top-poster. ============ Previous poster(s) have mentioned n-o 'falling apart' as the specialists become no longer available. This is the problem with systems which are personality-based instead of organisationaly-based. It's like a society: the colaborators need to know what the rules are - independant of any one/few person(s). -- Chris Glur.

1 0

RE: [Oberon] AntsInFields a1.01
by Felix Friedrich 02 Oct '02

02 Oct '02

Hi Flurin, >I tried to compile Voyager and ran into the following compile Error. I >must say it's been a while since I've used Oberon and I've forgotten how >to jump to the releveant position. >I'm running Oberon Plugin on Windows NT. > >compiling vyGraphBase0 > pos 1863 err 152 symbol file of imported module > not found > >Can you help? Voyager needs an installed Package "Images" to compile. For PluginOberon on Windows execute "Packages.Install Images.oaf" before executing the compile commands. If there are errors while installing Images try "Packages.Install \R- Images.oaf". Anyway, if you already have a windows environment, I recommend to use the Installer.exe (in www.antsinfields.de/download/windows) to install everything at once and use the "compact" option to prevent from overwriting any Oberon registry items. Felix. -- Felix Friedrich Institut für Biomathematik und Biometrie GSF - Forschungszentrum für Umwelt und Gesundheit, GmbH Ingolstädter Landstraße 1, D-85764 Neuherberg Tel: ++49 89 3187 2436 email: friedrich(a)gsf.de --

1 0

AntsInFields a1.01
by Felix Friedrich 02 Oct '02

02 Oct '02

Hello Oberoners, the first public version (a1.01) of my software package "AntsInFields" is available on the web via http://www.antsinfields.de. It is a software package for simulation and Bayesian inference on Gibbs fields and serves in this version as a host of interactive demonstration panels for the second edition of G.Winkler's Book "Image Analysis, Random Fields and Markov Chain Monte Carlo Methods". Even if you are not interested in Markov Chains and Gibbs Fields etc., it might still be interesting for some of you, since in this distribution I tried to make it work (on Windows) with people who do not know anything about Oberon beforehand. And, I think it works. For example, I have made the panels scalable by modifying Organizers (-> antsOrganizers.Mod) such that the content is scalable (even Fonts); closing a Windows-window stops the running thread if it is attached to the window; threads are controlled and activity is displayed etc. Check it out, if you like. AntsInFields is distributed with the Lesser General Public License as provided from the GNU foundation and so you may use anything you need. All sources are distributed and can be found in the file "antsFileList.Text" (see the docu). The base system used (and distributed) is "ETH Plugin Oberon for Windows", many many many thanks to E. Zeller for making all the Windows views and dialogs etc. ! The version on the web is not specifically designed for windows but at the moment you need a windows 95/98/NT/XP/ME/2000 operating system for an easy installation. If you use Oberon on Windows already, I recommend to perform a COMPACT installation (select "compact" while installation progress), since then only the AntsInFields registry is written to disk and it does hence not affect your (Windows-) oberon. AntsInFields is then installed seperately from your Oberon. (The installer does not provide an installation into an Oberon system) If you like it or hate it: please send some feedback to ants(a)antsinfields.de Felix -- Felix Friedrich Institut für Biomathematik und Biometrie GSF - Forschungszentrum für Umwelt und Gesundheit, GmbH Ingolstädter Landstraße 1, D-85764 Neuherberg Tel: ++49 89 3187 2436 email: friedrich(a)gsf.de --

2 1

Re.[Oberon] Native 24.08.2002: Compiler Bug
by eas-lab＠absamail.co.za 01 Oct '02

01 Oct '02

Stefan Salewski wrote: > I think there is something wrong with the DIV statement. Yes, it's the same with n-o alpha 2001. Also using constants: 10 DIV 3 = 3 - 10 DIV 3 = - 3 // DIV has precendence over "-" -(-10 DIV 3) = 3 (-10) DIV 3 = - 4 // truncates toward minus-infinity ?! -((-10) DIV 3) = 4 Besides this, looking into DIV raised other issues for me. Desktops.OpenDoc Oberon.Report.Text ~ shows: They are related by the following formulas defined for any x and positive divisors y: x = (x DIV y) * y + (x MOD y) 0 <= (x MOD y) < y Examples: x y x DIV y x MOD y 5 3 1 2 -5 3 -2 1 ====== I would expect DIV to 'truncate towards zero'. Not towards minus infinity ? And when I try to analyse the 'rules' further I'm confused: * From Oberon.Report.Text operator DIV: first operand = integer ; second operand = integer result type = smallest integer type including both operands So here Oberon.Report.Text DIV defines the 2 operands 'symetically', but elsewhere "positive divisors y" (x may not be positive). * Then let's see the definition/syntax of "integer":- integer = digit {digit} | digit {hexDigit} "H". real = digit {digit} "." {digit} [ScaleFactor]. ScaleFactor = ("E" | "D") ["+" | "-"] digit {digit}. It seems to me, that from the above "-10" would fail the syntax of an integer ? ! Where is my reasoning wrong ? Apparently "integer" is not type INTEGER ? So my queries are: 1. is -10 a n-o 'integer' ? 2. are the valid two operands of DIV of the same type ? 3. are these claims of mine of inconsistency in Oberon.Report.Text valid ? -- Chris Glur.

1 0