September 2016 - Oberon - mailman3.inf.ethz.ch

Question
by Boris Ashkinazi 05 Sep '16

05 Sep '16

Do we (community) need Oberon System running on tablet? Sent from my iPod

5 6

Oberon language family and the master.
by Srinivas Nayak 05 Sep '16

05 Sep '16

Dear All, I am referring to http://www.oberon.ethz.ch/archives/languagearchive/genealogy. Here we see that Oberon language from its birth has gone through several revisions. Many times either NW or others have added new features to it if they feel a need of it. Or removed existing features, if they found it unnecessary. After all these iterations, Oberon might have got time tested. So today, can we say, whatever is present in Oberon-7 is time tested; and one doesn't need to add or remove anything from it; and this is the state-of-the-art; and is simple but not simpler? If so, one wouldn't worry about Oberon V, Oberon X, Active Oberon, Action Oberon, Object Oberon, Concurrent Oberon etc. etc. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

4 4

Re: [Oberon] Data transfer in large amounts
by Paul Reed 05 Sep '16

05 Sep '16

Dear Wojtek, > This size fits well in a NOR flash chip whose size is limited to 64 MB. I did consider an SPI flash chip, which would have been a more appropriate size, but (micro)SD-cards are more freely available for not much difference in cost. > "doing" is indicative of some sort of a plan. Would you mind sharing your > plan, a roadmap, and the future of FPGA Oberon? FWIW, I shared my own personal roadmap during Oberon Day 2011 (I've posted links to the talks here before), and posted here updates to what I'm doing and how and why some particular things were done. In general, the material is presented as-is, for careful study, in the hope that it may be useful. Some people have given us really great, considered and constructive feedback and excellent contributions of work, which often results in very satisfying fixes to certain issues. We are very grateful for this. But you are mistaken if you expect there is a team, an updating plan/roadmap, a version control system, ongoing feature development, "releases", a service-level agreement, sponsorship or finance like in a large open-source software or hardware project. And we are certainly not being secretive, rather, trying to help as much as we can with very limited resources! Perhaps you would be happier with one of those much bigger projects, several of which now run on FPGAs. You certainly seem to want a lot for nothing and appear to need the support of a much larger community - you do not carefully follow even the small amount of links provided both on Prof. Wirth's home page (where he notifies significant changes to his whole site in the news file) and for example the FAQ on http://projectoberon.com; and previous posts on this forum; where many of your questions would be answered and some of your criticisms rendered moot when you understand the context. HTH, Paul

5 5

Re: [Oberon] Oberon-07, recursion and type extension
by John R. Strohm 05 Sep '16

05 Sep '16

The fundamental fact is that some algorithms are far more concisely and understandably expressed in recursive form, while some algorithms are easier to express and understand in iterative form. Quicksort was very, very difficult for its inventor to express and explain iteratively. Expressed recursively, it is almost trivial. (Yes, you ARE expected to have at least a nodding familiarity with Quicksort.) Linear search, on the other hand, is more clearly expressed iteratively. So are many (most?) numerical algorithms. Binary search is pretty easy to express either way; the recursive formulation is interesting in that it is tail-recursive. The object of the exercise is to express algorithms clearly and concisely, so that the reader may determine quickly whether the algorithm is in fact correct, and the compiler may generate reasonable code for the algorithm. If the expression of the algorithm in the compiler's input language is big and messy, the odds are that the generated object code will be similarly big and messy. --- noreply(a)z505.com wrote: From: Lars <noreply(a)z505.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Oberon-07, recursion and type extension Date: Mon, 5 Sep 2016 03:48:01 -0600 I've always wondered if recursion, is a trick, and overrated (i.e. lisp) and should be avoided, or embraced. It is certainly powerful but creates, I find, confusing code. Dijkstra was skeptical of recursion at times, and proud of it at other times. I for one don't find all the tricks up Haskell or Lisps sleeve when using recursion to be more readable code, than say, non recursive code that avoids recursion as if it is a nasty trick... I'm wondering, if recursion is highly over rated and should be used in moderation, rather than embracing it like in functional languages... Maybe super intelligent humans (clever) can understand all sorts of recursive mind games, but should bone simple dumb readable programs contain recursion riddled throughout the code everywhere? Or should it be avoided and used in moderation? I don't mean to claim the original poster of this email thread was abusing recursion and riddling it throughout his code, as it was only a small example. Rather I wanted to start a small discussion of people's opinion on recursion and why everyone thinks it is so great when in fact often it seems like a clever trick. It is certainly a different way of thinking about a problem, but for humans, with our brain size.. is it worth abusing recursion? Functional languages do not consider it abuse, but should it be considered abuse? -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Data transfer in large amounts
by Paul Reed 05 Sep '16

05 Sep '16

Dear Wojtek, > ...possible applications of the FPGA Oberon... would be > easier to develop if the SD card could be read under the workstation OS > as a regular SD card. Are there any plans to develop the common file > system which would make it possible? > ...the prime reason to develop instruments > running the FPGA Oberon OS would be to collect data...if I collect a 2GB data file > then I would like to easily and efficiently transfer it to the analysis > environment. Trickling the file through the wireless or serial is not > quite adequate in this case. Clearly. But I don't think there is anything in the pipeline which would save you work in your specific use-case very much, it's quite outside the scope of what we are doing: a 2GB file won't fit on a 64MB filesystem, for a start. Sorry! But of course Oberon presents far fewer barriers to "doing it yourself", with absolute control, than other more mainstream systems. HTH Paul

5 11