X903@DMAFHT1.BITNET (Marc Wachowitz) (05/16/91)
There is an Oberon compiler for MS-DOS, but it is missing almost every- thing (documentation of internals, REALs/LONGREALs, not even to mention garbage collection - i.e. what you once have allocated with NEW lasts forewer; no runtime checks, only addition/subtraction allowed for LONGINT, ASH doesn't work, SIZE returns INTEGER, and more similar nonsense). Additionally it has some very low internal limits, which result in completely unrelated error messages when exceeded. Names are silently cut after some number of characters (I don't remember the exact value, but I remember it's too low for me), names in object files are all-uppercase, etc, etc. Enough? In case you still want to get it, it's on the recently announced host at ETH Zurich, neptune.inf.ethz.ch (129.132.101.33). I'm currently writing my own extended Oberon compiler for 80286 or later (but intended to simplify porting to other systems; I'm even playing with the idea of generating C source code). The result will be available under the terms of the GNU Public Licence (but has no other relation to the FSF); since the project is still far from complete, don't ask where to get it :-) (flame on) In fact, I don't consider Oberon the right language for a beginner course, I would recommend some Lisp-like language, preferably Scheme. First teach people how to express clearly what they think, then how to implement it efficiently. I feel Oberon is better suited for people who already have a good knowledge about algorithms and data structures, and some experience in systems programming. Though that's of course only my personal opinion. (flame off) Marc Wachowitz X903@DMAFHT1.BITNET
UNBCIC@BRFAPESP.BITNET (05/17/91)
I couldn't find the MS-DOS Oberon in the ftp site at Zurich. Could anybody
help me?
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET
P.S.: I know it isn't good, but is for learning purposes.brandis%INF.ETHZ.CH@UCF1VM.CC.UCF.EDU (Marc Brandis) (05/21/91)
We decided to delete Oberon-M from our server because it did not get up to our expectations. Anyway, it is much better to have a look at both the Oberon language and the system. If you have access to a Mac II, a Sun SPARC or a DEC DecStation (or just an X-terminal to it), have a look at these systems. There are also ports to the IBM RS/6000 and the PC under works. The PC version will certainly require a 386 processor. I cannot comment on the exact environment it will run under. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
erv@everest.TANDEM.COM (E. Videki) (05/23/91)
In article <BAFE9C2140000681@brfapesp.bitnet>, UNBCIC@BRFAPESP.BITNET writes: |> I couldn't find the MS-DOS Oberon in the ftp site at Zurich. Could anybody |> help me? |> |> (8-DCS) |> Daniel C. Sobral |> UNBCIC@BRFAPESP.BITNET |> |> P.S.: I know it isn't good, but is for learning purposes. I just don't understand the "it isn't good" statement. There is only ONE known bug in the compiler, and it and its libraries have been in use by many individuals since 1989! True it doesn't support dynamic loading and garbage collection, but that is because most DOS users have told me they don't want such things. They want a well behaved application program which won't make it impossible to keep running Lotus or whatever. The code generation is excellent, everything runs fast, and I've seen several impressive applications written on it, one of which is going commercial by the fall. The explanitory note I received from ETH was that they have a policy that only software they write is going to be housed on their servers. All the other places have been happy to keep it. -- E. Videki (author of Oberon-M) PS: The single known bug is the one reported elsewhere in this newsgroup. Specifically, when you have an open-array of pointers, and index that array, the automatic dereferencing gets a little too ambitious and dereferences the indexed array element. Thus, the following statement will get a type incompatibility error: ptrvar := arrayofptrs[someindex] it is acting like ptrvar:=arrayofptrs[someindex]^ . This only applies to open-arrays. If you have a fixed array you can work around this. If it is critical, you can remember that range checking won't stop you from going to a very large array (larger than the type definition). I've already done the fix, and on the next distribution it will appear at all the sites. --EV
UNBCIC@BRFAPESP.BITNET (05/23/91)
=> From: editor%ucf1vm.BITNET@LILAC.BERKELEY.EDU
=> Subject: RE: Oberon for MS-DOS
=> |> (8-DCS)
=> |> Daniel C. Sobral
=> |> UNBCIC@BRFAPESP.BITNET
=> |>
=> |> P.S.: I know it isn't good, but is for learning purposes.
=>
=>
=> I just don't understand the "it isn't good" statement. There is only ONE
=> known bug in the compiler, and it and its libraries have been in use by
=> many individuals since 1989! True it doesn't support dynamic loading
Sorry. It was another message that gived me that impression. BUT:
=> and garbage collection, but that is because most DOS users have told me
=> they don't want such things. They want a well behaved application program
^^^^^^^^^^^^^^^^^^ (garbage collection)
This is because they don't understand what garbage collection implies. They
didn't have this before.
=> which won't make it impossible to keep running Lotus or whatever. The
You have only to track the pointers.
=> code generation is excellent, everything runs fast, and I've seen
=> several impressive applications written on it, one of which is going
=> commercial by the fall. The explanitory note I received from ETH was
=> that they have a policy that only software they write is going to be
=> housed on their servers. All the other places have been happy to keep it.
(We trully need an Oberon Interest Group!) Ok, ok. I didn't test your compiler.
Anyway, I got it, uploaded it to Brazilian BBSs and made some messages about
it. And I'll use it to learn Oberon.
Thanks for the compiler.
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET
P.S.: Are your Bitnet or Internet address in Oberon Documentation?Ben.Stuyts@p6.f202.n281.z2.fidonet.org (Ben Stuyts) (05/25/91)
Marc Brandis writes:
MB> Anyway, it is much better to have a look at
MB> both the Oberon language and the system. If you have access to a Mac
MB> II, a Sun SPARC or a DEC DecStation (or just an X-terminal to it),
MB> have a look at these systems.
So, how difficult would it be to produce a Sun-3 version? Basically
everything seems to be already there: the codegenerator for the Mac-II
and the operating system support from the Sun SPARC version.
I'd be more than happy to volunteer for doing such a port. B-)
Best regards,
Ben
--
uucp: uunet!m2xenix!puddle!2!281!202.6!Ben.Stuyts
Internet: Ben.Stuyts@p6.f202.n281.z2.fidonet.org