It seems that Modula is 'mature' on linux, yet Oberon
is nowhere.

The reason that people select a particular, from a
set of possibilities is often based on personal quirks.
These quirks may be difficult to explain, or perhaps not
even understood by the selecter.

For years, I've been a very heavy user of ETH-Oberon S3,
because it is superb for 'own use' text manipulation.
Many types of research entail just collecting text, mostly
from the net, and extracting the contents manually.

IMO S3's text handling power comes from the interface,
including the unconventional mouse-chording. This
HCI, is not dependant on Oberon, although I suspect that
Wirth's influence allowed it to develop.

So actually I'm committed to the S3 interface, rather
than to Oberon. For me S3 has some serious deficiencies.
The weak internet facilities, are now mostly alleviated
by the linux-ETH-Oberon, which allows handling the inet
by linux and using S3 to handle the text. There are other
usefull linux facilities: like I'm writing this now under
[Native] Oberon and might run it through a spell
checker [if I rememeber] before I post it via linux.
I can't mail with Oberon any longer because my ISP
demands TxAuthorisation which S3-oberon lacks.

Since linux-ETH-Oberon allows the linux inet facilities
to be easily used on ETH-Oberon text, I'm wondering if
any of OOC'f facilities can be conveniently used with
ETH-Oberon ?

Q - are there any OOC - libraries which might be
usefull for ETH-Oberon ?

Another facility of linux which can be leaveraged for
S3 usage is the [vim e.g.] syntax colouring.

== Chris Glur.

PS. I ran this text through ?spell, indirectly via
linux > mc (mc is another killer ap. for those who want
visual/WYSIWYG) and I'll use S3's ET.SearchDiff to
make a BIG RED 'refrigerator sticker' to help pull back
the degenerating brain-neurons.

What sytem other than S3 allows you to simultaniously
view & cut from 3 files: S3, linux & DOS formatted; and
to paste to different size, font, colour ? !
====
selector !selecter
dependent !dependant
useful !usefull
remember !rememeber
useful !usefull !!!
leveraged !leaveraged

stewart greenhill

Hi Chris,

It probably depends in part on what types of software people are
writing. The key things that Oberon adds to Modula is an object-oriented
data model (ie. polymorphism) and garbage collection. These lend
themselves to the development of large and complex systems. Garbage
collection improves modularity and safety, and polymorphism improves the
ability to generalise and abstract the semantics of a problem.

I suspect that like you say, its often quirks or cir***stance that
drives the decisions. An additional problem with Oberon is its
fragmentation and lack of standards. Its a small "niche", but there are
many different implementations which effectively dilute the user base
further.

That depends on what you need. I don't know what's missing in ETH-Oberon.

Some of the OOC V1 libraries might be usable, but the low-level modules
that interface to the OS (eg. Files, SysClock, Termination) are built on
FOREIGN "C" implementations that would not be useful outside OOC. That
probably just leaves things like maths, strings, text, etc which I guess
are already well supported by ETH oberon. Some of the V1 libraries use
OOC's structured name-space but would otherwise be OK. This includes the
abstract data type (ADT) modules and the XML parser. They use ABSTRACT
record types, but these are implemented in a way that is theoretically
backward compatible with standard Oberon-2 (via system flags).

With OOC V2, the situation is even worse. The libraries that were added
since V2 often rely on language extensions that are specific to OOC. For
example, the V2 IO framework uses the new STRING data type, as well as
abstract types and structured exception handling (RAISE/CATCH). While
these might be useful as a model, you would have to "port" them to
standard Oberon-2. Many of the ADT (abstract data type) modules use
OOC's parametric ("generic" or "template") type extensions (eg.
ArrayList, LinkedList, Dictionary) which again would have to be "ported"
to Oberon-2 (eg. by removing the type parameters).

So while a lot of useful code exists in the OOC libraries, I suspect it
would not be "conveniently used" within ETH Oberon. Your best bet would
be to look at the V1 code-base which is closest to standard Oberon-2.

Cheers,
Stewart

noch

I just want to mention that there is an obron compiler for linux which
could be used in real world apps.
Ulm's Oberon System.
It has very rich and powerful library set, and produces rather quick
native code.
It only lacks interfacing to C code (directly), but anyway it has
interfaces to X and tk via net and pipes.
Roots of that compiler is SYSTEM.UNIXCALL, SYSTEM.FORK, and
SYSTEM.SIGNAL functions.
It not depend on libc or other C library at all.


So, I really recommend you to try this compiler.
I believe one can write powerful and flexible Unix applications with
it.

Norayr
---
http://geocities.com/n0rayr """no-top-post ÐÉÓÁÌ(Á): """