[Oberon] Oberon Digest, Vol 160, Issue 21
Søren Renner
soren.renner at gmail.com
Thu Sep 28 14:47:09 CEST 2017
Also, AOS and Oberon will become much more widely noticed as soon as my
raytracing research receives the attention and praise that it deserves.
On Thu, Sep 28, 2017 at 6:00 AM, <oberon-request at lists.inf.ethz.ch> wrote:
> Send Oberon mailing list submissions to
> oberon at lists.inf.ethz.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
> oberon-request at lists.inf.ethz.ch
>
> You can reach the person managing the list at
> oberon-owner at lists.inf.ethz.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
>
>
> Today's Topics:
>
> 1. Re: General - Academic vs Commercial applications
> (Felix Friedrich)
> 2. Re: General - Xerox PARC 1970 (Tomas Kral)
> 3. Re (2): General - Academic vs Commercial applications
> (peter at easthope.ca)
> 4. NativeOberon's FileName limitations - HOW2 extend? (eas lab)
> 5. Re: General - Academic vs Commercial applications (eas lab)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 27 Sep 2017 12:17:23 +0200
> From: Felix Friedrich <felix.friedrich at inf.ethz.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] General - Academic vs Commercial applications
> Message-ID: <d04806c6-955e-fa5d-d726-09ba6622c2c5 at inf.ethz.ch>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> In fact Oberon is still taught at ETH Zurich.
>
> We are giving a course on System Construction and discuss some Oberon
> language dialects, Oberon inspired operating or runtime systems and
> programmable hardware supporting or based on Oberon related languages
> and systems. In more detail we teach
>
> (a) The Minos Runtime System (based on HeliOS, system control for
> unmanned helicopters), programmed in a dialect of Oberon07 [FF]
> (b) The A2 runtime system and GUI together with Active Oberon [FF]
> (c) Oberon running on FPGAs: the RISC processor [Paul Reed]
> (d) Systems on a Chip, FPGA and Hybrid Systems, programmed using Active
> Cells, another dialect of Oberon [FF]
>
> cf. http://lec.inf.ethz.ch/syscon/2017/
>
> Without exaggeration and with a little bit of pride I can say that
> students like this course a lot -- because we really show how these
> systems work behind the scenes over all levels. We (Paul and I) can say
> that we understand every single bit of it and bring this accross as a
> strong argument for simplicity.
>
> Apart from that I am the "last man standing" for Oberon at ETH. I have a
> lecturer position at ETH and am giving large computer science service
> courses at ETH (hundred of students, C++, Java or whatever is
> requested), which limits my time for working with and for Oberon. I love
> to play around with the language, compiler and runtime systems and
> optimize them according to what I, personally, find the most optimal way
> to present or use the langauge. Because much is driven by personal
> taste, I hesitate to sell my own ideas as "the truth", while I have some
> strong opinions. I feel responsible for the A2 repository comprising the
> A2 Multicore OS, its graphical user Interface and the FoxCompiler
> toolchain.
>
> I should not forget to mention that the dialects of Oberon and the
> systems that we teach are in use in real-world commercial systems sold
> by companies that in fact use Oberon for commercial development. For our
> course this is a very important argument underpinning that following the
> principle of simplicity can have very positive practical impact, even if
> it is hard to sell academically.
>
> Kind regards
> Felix Friedrich
>
>
>
>
> > On Tue, 26 Sep 2017 10:36:35 +0000
> > Treutwein Bernhard <Bernhard.Treutwein at Verwaltung.Uni-Muenchen.DE>
> > wrote:
> >
> >> yes, afaik, with the retirement of J?rg Gutknecht the "Native Systems
> >> Group" was shut down.
> > Having said that, Oberon is no longer taught, developed, and included
> > in informatics research sylabus, at ETH University?
> >
> > So is AOS dropped as well?
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 27 Sep 2017 12:49:38 +0200
> From: Tomas Kral <thomas.kral at email.cz>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] General - Xerox PARC 1970
> Message-ID: <20170927124938.6c945698 at raspberrypi>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, 24 Sep 2017 03:30:24 -0700
> Douglas G Danforth <danforth at greenwoodfarm.com> wrote:
>
> > She showed me the Alto when I visited PARC.? Its hard drive was a
> > large platter which, iirc, held only of data.
>
> 14MB given the enthropy of information may seem like today's 14GB, as I
> see similar stuff on Alto's screen as on mobile displays, say from
> a higher level of perspective, so to speak. That is 1970.
>
> I remember a decade after (1982 ZX/ATARI, etc), popular 8-bit home
> computing, 64K of RAM was unheard of limit, possible only in mainframes
> before.
>
> Then `1984' - Orwell's Big Brother was chosen as the main theme of
> Apple's marketing campaign, for their computer released 1984.
>
> Workstation's like Alto, were a dream, also the price $40.000,
> something like that. Which was not a market price just the cost of
> development, probably?
>
> I am lead to believe, that what maters is relative performance.
>
> Between various releases of today's user s/w, I usually notice, slower,
> more complicated and requiring faster h/w, but that could well be my
> paranoia as I get older :-)
>
> --
> Tomas Kral <thomas.kral at email.cz>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 27 Sep 2017 09:58:27 -0700
> From: peter at easthope.ca
> To: oberon at lists.inf.ethz.ch
> Subject: [Oberon] Re (2): General - Academic vs Commercial
> applications
> Message-ID: <E1dxFfH-0000rF-Hc at xo-53-1d-bb.localdomain>
>
> Felix,
>
> Thanks for your overview.
>
> From: Felix Friedrich <felix.friedrich at inf.ethz.ch>
> Date: Wed, 27 Sep 2017 12:17:23 +0200
> > Apart from that I am the "last man standing" for Oberon at ETH.
>
> One is better than zero. Thanks for your dedication! This
> circumstance is a good argument for incuding the language report for
> Active Oberon as HTML in the wikibook. Being a wiki, anyone can work
> on it. Subject to your permission of course.
>
> Incidentally, accesses to the front page has settled to 400-500/month.
> https://en.wikibooks.org/w/index.php?title=Oberon&action=info
> Certain to climb as the content increases and improves.
>
> Regards, ... Lyall E.
> --
>
> 123456789 123456789 123456789 123456789 123456789 123456789 123456789
> Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757
> http://easthope.ca/Peter.html Bcc: peter at easthope. ca
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 27 Sep 2017 17:09:16 +0000
> From: eas lab <lab.eas at gmail.com>
> To: <oberon at inf.ethz.ch>
> Subject: [Oberon] NativeOberon's FileName limitations - HOW2 extend?
> Message-ID:
> <CAN3-DLH2igPv3gRQFWk8CCPh_frLdqLEpode9r-5sFjCYJ67Pg@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Linux : X11 is a monster, but LNO [121104] runs in a FrameBuffer nicely;
> also under 64bit.
> Why would you NEED LNO ?
> 1. to have multiple files visible together on the same screen;
> 2. with powerfull mouse-chording ability;
> PublicDomain wily [needs X11], copied from ETHO, is even better, except
> lacks
> 3. ETHO's coloring capability: to give an extra dimension to
> complex relationships between texts, possibly in multiple files.
>
> Mildly complex tasks, soon need 4, 5, 6 ...TextFrames viewable-together.
> Since screen-area is the limiting factor, M$'s wastefull <staggered
> frames>,
> copied by Aos, is NOT acceptable. The paper-book, where each of hundreds
> of pages "automatically line-up", is a magical concept!
>
> The big problem/weakness of LNO: not being able to immediately read/write
> to files anywhere in the file-tree, can be reduced by:
> 1. use a convenient file-navigator, like mc, which allows to
> 2. <push a button> at the reqired-file, which stores its /PATH/Name to a
> fixed location, which
> 3. is accessed by LNO to mount the file-to-be-accessed by LNO.
>
> Right now, while composing this text, via USBstik:Linux:TinyCore46:LNO
> I want to access some Oberon:V4 files on the M$-partition.
> I failed: apparently LNO can't mount FATFS, like LEO can.
> It shouldn't be difficult to extend the capability?
>
> But read/write to V4 files in LinuxFS, is OK via:
> FileSystem.Mount V4 LinuxFS /mnt/sdb2/CRG/ETHO/V4dirTree/
> usr/local/oberon/Text/~
>
> The 4-string command/M.P had the last/long string stored in the known
> location;
> so "V4" is my chosen name and string1, string3 are in the <Tools Text>;
> and the user need only add his chosen name to make the 4-string command.
> Then System.Directory ^ V4:* lists the directory contents; giving
> immediate
> access to the 96 files:-----------
> V4:.
> V4:..
> V4:Analyzer.Tool
> V4:AsciiCoder.Tool
> V4:Backup.Tool
> V4:Balloon.Text
> V4:BalloonIdx.hlp
> ...
> V4:Find.Tool
>
> V4:Welcome.Text
> V4:Xref.Tool
>
> 96 files ----------------
> LNO can access all: Aos, *nix, FATFS and presumably V4 formats.
> The PROBLEM remains, to access eg. "tmp:mc-root", where "mc-root"
> is not a valid <FileName>.
> AFAIR <Linux ETH Oberon> was able to access such filenames by quoting?
> Can we extend LNO, perhaps based on LEO?
>
> == Chris Glur.
>
> PS. The fact that ETHO's System.Directory output is not available:
> ordered by recentcy, is a serious deficiency: not acknowledging that
> <the stack and tree> are central to cognition & thus computing ?
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 28 Sep 2017 01:51:22 +0000
> From: eas lab <lab.eas at gmail.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] General - Academic vs Commercial applications
> Message-ID:
> <CAN3-DLGTDX=a5fnxA7=w54ZsMjzh6ZY4Y22xMtga2OtrJ++Oww at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Looks like a brilliant syllabus: teaching universal 1st-principles,
> and not just the current FB, twitter fads.
>
> When RPi first came out, I wanted to build a P-code interpreter,
> as I had done in the 70s for Fairchild-F8, 63xx/68xx, Intel16bit;
> but I couldn't see how to <single step design asm-instructions>
> [as I had always done - I coded the F8 via a teletype in *HEX*]
> since appaently the ARM assembler takes the user's <intentions>
> and OPTIMISES it, in the background, to generate the actual.
> single-instructions.
>
> No one on the RPi NNTP could understand my query, because today
> it's always "doA, doB...", without understanding the underlying
> principles. But now, I see the critical reference to "OPTIMIZED" in
> http://lec.inf.ethz.ch/syscon/2017/slides/LSC17Slides0926.pdf
>
> == Chris Glur.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> ------------------------------
>
> End of Oberon Digest, Vol 160, Issue 21
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170928/7e9b0ed0/attachment.html>
More information about the Oberon
mailing list