news

I sometimes 'try' to program in oberon - grandson of Pascal.
I used to program in Turbo-Pascal, and the do***entation had a nice
set/library of procedures/functions.

Apparently the C-lib is a big part of C. And a big part of it's
problems ?
Are there any libraries available on-line for any of the Wirthian
languages ?
It's dumb to have to derive all the procs from scratch ?

What I want to do immediately is make a: 'Transfer a file between
boxes via the par-port'.

Thanks for info,

== Chris Glur.

anoneds

Are you talking about, maybe, Units?

Try searching for Pascal Units. As for Oberon...?

noch

Hello
Please, provide information about compiler and operating system you are
using.
May be I'll can help you.


BTW, take a look at FreePascal (http://www.freepascal.org)
It is a modern 32/64 bit compiler available for almost all platforms.
It's introducing some new and nice features like smartlinking, and
produce code which doesn't depend on glibc, instead making direct
kernel calls.
And there are really huge set of libraries out of the box and strong
community of developers.

Anf if you are using oberon under windows, I'll recommend BlackBox
(http://www.oberon.ch)
or XDS compiler. Both have a reasonable set of libraries out of the
box.

If you are using oberon under Linux, then I'll recommend:
oo2c (oberon compiler which use C as a portable assembler, ooc.sf.net)
I recommend you to use latest version, not a version from the first
branch.
XDS
Ulm's Oberon System (available also for Sun) with a rather huge
library.
Last is just oberon, no oberon-2 compiler, which may be even better.
This compiler also produce code which doesn't depend on any C library.

Good Luck.

august karlstrom

How can you live without dynamically allocated arrays whose length is
unknown at compile time? How could anyone live without it in Modula-2?


August

ulrich

in Modula-2 hat man mit ALLOCATE(Variable, Größe) die Möglichkeit, dynamischen Speicher nach Bedarf zur Laufzeit anzufordern.
alle guten Modula-2-Programmierer, die ich kenne, setzten das mit Geschick ein.
dynamische Felder, d.h. eine Reihe von Elementen identischen Typs, sind ein Spezialfall davon, und üblicherweise hat man ein Modul dafür benutzt, das die nötigen Basisfunktionen zur Verfügung stellt.
was kann sich das Programmiererherz in einer Sprache mehr wünschen, in der der dynamische Speicher vom Programmierer verwaltet werden muss?
gibt es bessere Ansätze in anderen derartigen Sprachen?

wenn man in Oberon ohne die Mössenböckschen Erweiterungen dynamischen Speicher für Felder benötigt, deren tatsächliche Länge erst zur Laufzeit bekannt ist, dann muss man auf eine ähnliche Technik wie in Modula-2 zurückgreifen. das geht problemlos und stört das automatische Speicherreinigen sogar nicht.
wenn man speziell mit der Ulmer Oberon-Umgebung arbeitet, hat man eine fülle von Diensten zur Verfügung, so dass man in den meisten Fällen gar keine dynamischen Felder benötigt und in den wenigen Ausnahmefällen eine individuelle Lösung rasch mit Hilfe der beeindruckenden Menge an Diensten und Modulen entwickeln kann.

wär es möglich, die nötigen Informationen einzuholen, bevor gemeckert wird? Kommentare, die von einem schlecht informierten Autor stammen, überzeugen nicht und helfen niemandem - am wenigsten dem Autoren selbst!

Oberon has dynamically allocated arrays.

VAR
array : POINTER TO ARRAY OF WhateverTypeYouWant;

NEW(array, size);

Each Oberon system (System 3, V4, Pow ect) comes with its own
set of libraries. Back in the "good old days" when there was only
one Oberon system (V4 is the closest to this) there was one standard
set of libraries. Now the only modules that are standard accross
systems are the basic libraries In, Out, XYPlane, Files, Strings,
and Math. Even here there are some discrepencies, but these
are usually pretty standard.

I don't see that in the "C-Lib" index anywhere.

http://www.thinkage.ca/english/gcos/expl/index/c_lib.html

If this isn't standard for C then why would someone expect it
to be standard for Oberon? I agree with the general sentiment,
there should be more standard libraries in Oberon.

Anyway, here's a link to how you would do that in
Free Pascal (a Delphi compatible compiler).

http://wiki.lazarus.freepascal.org/index.php/Hardware_Access

Note that there isn't a built in "library" function. You have
to make calls to an OS-library (Windows or Linux).
All Oberon systems/compilers today have a way to
access the underlying operating system (except for
when Oberon IS the underlying operating system,
in which case it's just accessing itself).

Regards,

John M. Drake

august karlstrom

Oberon-2 has but original Oberon hasn't. I commented on noch saying:
"Last is just oberon, no oberon-2 compiler, which may be even better."


August

dr engelbert buxbaum

Check the SWAG (software archive group) library, they have several
libraries for the parallel port too.

Note however that the parallel port is a legacy device and bound to
vanish from the face of the earth, many newer computer don't have one.
Also, older operating systems up to Win98 came with a utility program
(Laplink) for data transfer between boxes using the parallel port (and a
special cable).

news

Yes, AFAIK TP had the various procs/functions grouped together
and nicely do***ented: Unit, syntax ...

ETH-oberon [S3] has got a good 'WatsonTool' which shows the
syntax of any exported proc., but you'd first have to
know/guess that/which module[unit] contains the required proc.

In S3 modules many procs. are repeated in multiple modules,
like ascii2 hex conversions...etc., instead of using libraries.

This apparently because the modules were 'student exercises',
and each student had to repeat the exercise in his project.

IMO, even the common [but unique to oberon]:
<open the scanner & get the 1st string as cmnd arg. proc.>
should be available from a library instead of being programmed
each time.

Obviously the partitioning of the procedures is a study in itself,
but the industry is mature enough now that the research should
have been done.

Java relies massively on libraries, and they would have been
able to bypass the mistakes of C.

So the ac***ulation of a library of procs. should almost be
RFC-task ?

== Chris Glur.