[Oberon] Oberon Digest, Vol 90, Issue 5
soren.renner at gmail.com
Wed Jul 6 15:27:14 CEST 2011
Woo hoo! I can has moderator status! sr is 0b3r0n-133t!
On Wed, Jul 6, 2011 at 10: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
> 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: Oberon Day 2011 Recordings (Jack Johnson) (Paul Reed)
> 2. Re: A2 developers has (sic) no time to look into the forum
> (Yaroslav Romanchenko)
> Message: 1
> Date: Tue, 5 Jul 2011 13:53:33 +0100
> From: "Paul Reed" <paulreed at paddedcell.com>
> Subject: Re: [Oberon] Oberon Day 2011 Recordings (Jack Johnson)
> To: oberon at lists.inf.ethz.ch
> <97c28195e18bd72ee505dbac4909a7da.squirrel at webmail.gradwell.com>
> Content-Type: text/plain;charset=iso-8859-1
> > 1. Re: Oberon Day 2011 Recordings (Jack Johnson)
> > I have a few questions about your part of the keynote.
> > Did you do your UTF-8 integration from scratch or did you look at
> > other code for inspiration? Did it require extensive modification, or
> > mainly just to Texts? What is your end goal for UTF-8 integration, and
> > how do you see that ultimately affecting the simplicity of the system?
> I added UTF string handling as an experiment (with a view to using it in
> other projects), and tried various schemes, including UTF-16/UCS-2 and
> even UTF-32 before finally settling on UTF-8. I didn't find much code for
> inspiration, since most of what's available is in C ;-) but I was very
> definitely inspired by the story of the invention of UTF-8 and its
> integration into the Plan 9 from Bell Labs operating system.
> UTF-32 is the only implementation where there is a linear mapping between
> character length and byte length (UTF-16 has surrogate pairs, which breaks
> that), but it is impractical on small systems because of the memory
> footprint. UTF-8 performs well in practice, except for some Asian
> locales, in which case an alternative encoding would be sensible (and
> indeed advised by the Unicode documents).
> Re-implementing Texts using UTF-8 is a really nice exercise (Luca?) :),
> since the details of the Text system are so well explained in the book.
> Certainly you would have to decide whether Files.Read would read a byte or
> a UTF-8 char, and be careful about lengths and byte offsets. I had an
> attempt, but ran out of time and will have to return to it [insert apology
> to Fermat here]. For the Oberon System demo, it wasn't strictly necessary
> so it didn't get in (along with a lot of other things I need to go back
> and do properly).
> > Are you using or have you considered using Oberon-07? How might that
> > affect the rest of the original Oberon System code?
> Yes it's all Oberon-07, I'm sorry if that wasn't clear. The main changes
> were obvious: removal of SHORTINT, LOOP, and WITH, for example; and this
> doesn't really change the text of the book that much, which is the aim.
> > Have you had chats with Wirth or others about what they might have
> > done differently if they could do it all over again?
> :) I'm reminded that they asked Ken Thompson what he would change about
> Unix, if he had the chance to go back and do it again. His answer was
> that he would add an 'e' on the end of the 'creat' system call.
> I once asked Prof. Wirth, after a retrospective lecture on Pascal, Modula
> and Oberon, what he would do differently. He simply said he would have
> called them Pascal, Pascal-2, etc.
> > I noted the
> > discussion of Objects in Appendix A of Project Oberon and aside from
> > the Gadgets implementation it alludes to the idea that if the Objects
> > module had existed at the outset it might have further simplified the
> > original system.
> This is Prof. Gutknecht's view, yes. Especially since the changes would
> have been small, for the power it gives. But with power comes
> responsibility, something we're not much good at in software IMNSHO. As
> well as simplicity, and elegance, there should also be a clarity test.
> That's why the book stands out.
> > Did you consider resurrecting slim binaries, or does that add more
> > complexity than it removes?
> No, and yes. The slim binaries approach relies on the more complex OP2
> compiler, with its high-level intermediate representation. I have no IR,
> I basically just translate RISC instructions into x86 opcodes (if it's not
> a RISC module, eg if it's a device driver). This adds a few hundred lines
> at most to the compiler (for x86 and for ARM32 put together).
> > Are the FPGA-based systems available?
> Working on it. The compiler generates code which runs on the FPGA (as
> does the Oberon-0 compiler, more-or-less unchanged, from Compiler
> Construction). But more hardware needs to be implemented for the system
> to be self-hosting, which is the aim.
> Message: 2
> Date: Tue, 05 Jul 2011 18:16:13 +0400
> From: Yaroslav Romanchenko <tobject at bk.ru>
> Subject: Re: [Oberon] A2 developers has (sic) no time to look into the
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Message-ID: <E1Qe6Q9-0000eW-00.tobject-bk-ru at f193.mail.ru>
> Content-Type: text/plain; charset="utf-8"
> Sounds like a deal! You are now Global Moderator
> Congratulations to Soren!
> Cheers, SAGE
> -------------- next part --------------
> An HTML attachment was scrubbed...
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> End of Oberon Digest, Vol 90, Issue 5
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon