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

Re: [Oberon] Oberon Digest, Vol 148, Issue 17
by Søren Renner 28 Sep '16

28 Sep '16

> There is a grey zone there. It is possible to generate at run time a text file, call at run time the compiler that compiles it, and load your dynamically generated code into memory and use that new program. > So, it is possible to generate even totally new modules "at run time". > Yes. Here is code that loads a PROCEDURE from a module that is never imported and so may have been compiled since the main program (a realtime raytracer) was running: PROCEDURE VoxelFromName*(modname: Name): Voxel; > VAR voxel: Voxel; fackery: VoxelFackery; > BEGIN > IF modname[0]='N' THEN > *GETPROCEDURE(modname, "thisvox", fackery );* > IF (fackery # NIL) THEN > voxel := fackery(); > END; > IF voxel=NIL THEN > Out.String("failed voxelfromname 1"); > voxel:=EMPTY > ELSE > voxel.code:=modname; > END; > ELSE > Out.String("failed voxelfromname 2"); > voxel:=EMPTY > END; > RETURN voxel > END VoxelFromName; GETPROCEDURE was added to Active Oberon and documented in a brief release note which I happened to read. On Tue, Sep 27, 2016 at 6:00 AM, <oberon-request(a)lists.inf.ethz.ch> wrote: > Send Oberon mailing list submissions to > oberon(a)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(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)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 for a C++ user. (Srinivas Nayak) > 2. Re: Elegance and simplicity (Brian Clausing) > 3. Re: Oberon for a C++ user. (J?rg) > 4. Re: Oberon for a C++ user. (Lars) > 5. Re: Oberon for a C++ user. (Skulski, Wojciech) > 6. Re: Oberon for a C++ user. (J?rg Straube) > 7. Re: Oberon for a C++ user. (Skulski, Wojciech) > 8. Re: Oberon for a C++ user. (Joerg) > 9. Re: Oberon for a C++ user. (J?rg Straube) > 10. Re: Oberon for a C++ user. (Joerg) > 11. Re: Oberon for a C++ user. (Felix Friedrich) > 12. Re: Oberon for a C++ user. (J?rg Straube) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 26 Sep 2016 14:31:18 +0530 > From: Srinivas Nayak <sinu.nayak2001(a)gmail.com> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: <57E8E3DE.3030504(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > >> - Modules can be seen as car manufacturer. > >> - Objects are the cars. > > > The program (Oberon System) is the car manufacturer. > > There is only a single car manufacturer per city (a single OS per FPGA). > > Modules are car factories. There are several factories in the city: Ford > Escort, Ford Whatever, etc. All factories are run by the same car > manufacturer. > > Objects are cars of different sorts manufactured by the car factories. > Each factory can manufacture and release an unlimited number of cars, > bounded only by the size of the parking lot (the size of the dynamic > memory). > > This is nice analogy. > But why stop here? Lets finish the whole story. > A factory can be closed or open. But two factories of same name can't > exist. (Module loading unloading) > Car specification (a record) is unique to manufacturer. Two factories > generally won't produce cars with same specification. But they can ask > other factories when they want. (importing of module) > > How shall we think about module exposing parts of a record? > Is it like, some parts of a car specification being patented by factories > and made public, but not others. > > > With thanks and best regards, > > Yours sincerely, > Srinivas Nayak > > Home: http://www.mathmeth.com/sn/ > Blog: http://srinivas-nayak.blogspot.in/ > > > > > ------------------------------ > > Message: 2 > Date: Mon, 26 Sep 2016 09:09:37 -0400 > From: Brian Clausing <brianclausing(a)earthlink.net> > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] Elegance and simplicity > Message-ID: <66a4afb8-7eb1-46d7-fb4b-6c87bf9a7fa3(a)earthlink.net> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Please excuse any error in sending this submission; it's my first time. > > May I recommend "The Search for Simplicity" by Per Brinch Hansen, the > Diamond Cutter, another grandmaster analyst and programmer. > > Brian Clausing > > > ------------------------------ > > Message: 3 > Date: Mon, 26 Sep 2016 16:37:03 +0200 > From: J?rg <joerg.straube(a)iaeth.ch> > To: "'ETH Oberon and related systems'" <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: <004b01d21803$73481cc0$59d85640$(a)iaeth.ch> > Content-Type: text/plain; charset="iso-8859-1" > > Examples that pop to my mind: > - The tires of a car could be used by another car > - The fuel tank can be filled by others > - The arm rest can't be reused as its dimensions are too specific to the > car > - the glass roof can't be reused as it too specific > > br > J?rg > > -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Srinivas > Nayak > Sent: Montag, 26. September 2016 11:01 > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > > > >> - Modules can be seen as car manufacturer. > >> - Objects are the cars. > > > The program (Oberon System) is the car manufacturer. > > There is only a single car manufacturer per city (a single OS per FPGA). > > Modules are car factories. There are several factories in the city: Ford > Escort, Ford Whatever, etc. All factories are run by the same car > manufacturer. > > Objects are cars of different sorts manufactured by the car factories. > Each factory can manufacture and release an unlimited number of cars, > bounded only by the size of the parking lot (the size of the dynamic > memory). > > This is nice analogy. > But why stop here? Lets finish the whole story. > A factory can be closed or open. But two factories of same name can't > exist. > (Module loading unloading) > Car specification (a record) is unique to manufacturer. Two factories > generally won't produce cars with same specification. But they can ask > other > factories when they want. (importing of module) > > How shall we think about module exposing parts of a record? > Is it like, some parts of a car specification being patented by factories > and made public, but not others. > > > With thanks and best regards, > > Yours sincerely, > Srinivas Nayak > > Home: http://www.mathmeth.com/sn/ > Blog: http://srinivas-nayak.blogspot.in/ > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > > ------------------------------ > > Message: 4 > Date: Mon, 26 Sep 2016 22:46:29 -0600 > From: "Lars" <noreply(a)z505.com> > To: "ETH Oberon and related systems" <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: > <730deb80e30fa4d10ba29ba2c5538a20.squirrel(a)gator3286.hostgator.com > > > Content-Type: text/plain;charset=iso-8859-1 > > On Thu, September 22, 2016 10:52 pm, J??rg Straube wrote: > > Lars > > > > > > Dynamic vs static is perhaps not the best distinction of modules vs > > objects. I try to make an analogon. > > - Modules can be seen as car manufacturer. > > - Objects are the cars. > > As you know, I'm no fan of Analogies, like Dijkstra, however I sin and use > them myself sometimes. > > A class, can be defined at design time like a module..but once the class > created (memory allocated on heap) it becomes an object (object is an > instance of class? according to Date and Darwen in Third Manifesto). So a > class definition, is very similar to a module definition (module file), > except one cannot dynamically create modules at run time. One may be able > to dynamically load a module in an oberon system, which is interesting, > but still not the same as allocating memory in a program on the heap for > one. > > Why even refer to analogies when one can describe exactly what a module is > and what it isn't: > > What is is not: an item that can be allocated at run time, it is only > typed out as a definition at design time. That's what I meant by static > because the module is not dynamically created on the heap. > > A class is like a static definition of an object, where the object can be > dynamically created (allocated) at run time. An object that is on the > stack is still allocated, just when the program begins. When is a module > ever allocated? It's compiled, but not so much allocated.. > > Again why use analogies when we can talk directly about what an object is, > and what it is not, and what a module is, and what it is not... > > Time to sin: > A car manufacturer has definitions (drawings) of the car. This is like an > object definition at the top of the source file (class). Once the factory > produces the car (object) from the design (class) papers, a new instance > of the car is allocated (steel is taken from the earth, along with > plastics and foam for seats). > > F*ck analogies! But that's as close as I can think of one... a class > definition is very similar to the drawings with all the restrictions, > specifications of the car. A module is similar to a class definition but > instead of creating a module on the heap at run time, the module is > compiled and generates a design time unit to be used by the programmer. > > An interesting thought: if one were to make a module allocated at run time > would this offer anything useful or different than an object being > allocated? Or would we reinvent object oriented programming if modules > could be allocated on the heap? If we just reinvented objects, now we > know exactly what modules are: design time objects without any heap > allocation at run time. > > > ------------------------------ > > Message: 5 > Date: Tue, 27 Sep 2016 05:14:15 +0000 > From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: > <CY1PR07MB22130D4264859B12E6ACCD2CFFCC0@CY1PR07MB2213. > namprd07.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Lars: > > >An interesting thought: if one were to make a module allocated at run time > >would this offer anything useful or different than an object being > >allocated? > > A module provides executable code. There is only one copy of the module's > code. An object provides data and pointers to the code, but it does not > provide the actual code. There can be multiple copies of the object. Each > copy can provide different data, but the same pointers to the same code. > Note that in this description I have in mind Oberon-2 objects rather than > Oberon-1 objects. Oberon-1 objects are more difficult to understand because > the pointers to the code can be installed at run time. Note however, that > Oberon-1 objects do not provide the code. Just the pointers. > > >Or would we reinvent object oriented programming if modules > >could be allocated on the heap? If we just reinvented objects, now we > >know exactly what modules are: design time objects without any heap > >allocation at run time. > > You put the module on the heap with its code, because it is the module's > goal to provide the code. OK. Now you need to execute that code from the > heap. OK. You allocate another copy of the module on the heap. So you put > the same executable code on the heap for the 2nd time. Now you can execute > it. (If you cannot, then allocating the code would make no sense.) So now > you have two copies of the same executable code on the heap. It makes > little sense. > > W. > > > ------------------------------ > > Message: 6 > Date: Tue, 27 Sep 2016 07:29:06 +0200 > From: J?rg Straube <joerg.straube(a)iaeth.ch> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: <B76A2A0E-A201-480C-8313-57FC61A01DB1(a)iaeth.ch> > Content-Type: text/plain; charset=utf-8 > > Lars > Actually Oberon modules ARE allocated on the heap. This is the beauty of > Oberon that you can load and unload them dynamically. > J?rg > > > Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech < > skulski(a)pas.rochester.edu>: > > > > Lars: > > > >> An interesting thought: if one were to make a module allocated at run > time > >> would this offer anything useful or different than an object being > >> allocated? > > > > A module provides executable code. There is only one copy of the > module's code. An object provides data and pointers to the code, but it > does not provide the actual code. There can be multiple copies of the > object. Each copy can provide different data, but the same pointers to the > same code. Note that in this description I have in mind Oberon-2 objects > rather than Oberon-1 objects. Oberon-1 objects are more difficult to > understand because the pointers to the code can be installed at run time. > Note however, that Oberon-1 objects do not provide the code. Just the > pointers. > > > >> Or would we reinvent object oriented programming if modules > >> could be allocated on the heap? If we just reinvented objects, now we > >> know exactly what modules are: design time objects without any heap > >> allocation at run time. > > > > You put the module on the heap with its code, because it is the module's > goal to provide the code. OK. Now you need to execute that code from the > heap. OK. You allocate another copy of the module on the heap. So you put > the same executable code on the heap for the 2nd time. Now you can execute > it. (If you cannot, then allocating the code would make no sense.) So now > you have two copies of the same executable code on the heap. It makes > little sense. > > > > W. > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > > ------------------------------ > > Message: 7 > Date: Tue, 27 Sep 2016 05:44:31 +0000 > From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: > <CY1PR07MB22132CC5D35A12910F50C1FAFFCC0@CY1PR07MB2213. > namprd07.prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > Actually Oberon modules ARE allocated on the heap. This is the beauty of > Oberon that you can load and unload them dynamically. > > Yes, but only a single copy. Duplication of the same code makes no sense. > In that sense modules are different from objects. > > BTW, how about safety of unloading the code? In BlackBox they do not > unload, they deactivate. How about the Oberon System? > > W. > > J?rg > > > Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech < > skulski(a)pas.rochester.edu>: > > > > Lars: > > > >> An interesting thought: if one were to make a module allocated at run > time > >> would this offer anything useful or different than an object being > >> allocated? > > > > A module provides executable code. There is only one copy of the > module's code. An object provides data and pointers to the code, but it > does not provide the actual code. There can be multiple copies of the > object. Each copy can provide different data, but the same pointers to the > same code. Note that in this description I have in mind Oberon-2 objects > rather than Oberon-1 objects. Oberon-1 objects are more difficult to > understand because the pointers to the code can be installed at run time. > Note however, that Oberon-1 objects do not provide the code. Just the > pointers. > > > >> Or would we reinvent object oriented programming if modules > >> could be allocated on the heap? If we just reinvented objects, now we > >> know exactly what modules are: design time objects without any heap > >> allocation at run time. > > > > You put the module on the heap with its code, because it is the module's > goal to provide the code. OK. Now you need to execute that code from the > heap. OK. You allocate another copy of the module on the heap. So you put > the same executable code on the heap for the 2nd time. Now you can execute > it. (If you cannot, then allocating the code would make no sense.) So now > you have two copies of the same executable code on the heap. It makes > little sense. > > > > W. > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists. > inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c= > kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_ > BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNC > DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e= > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists. > inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c= > kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_ > BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNC > DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e= > > > ------------------------------ > > Message: 8 > Date: Tue, 27 Sep 2016 08:27:57 +0200 > From: Joerg <joerg.straube(a)iaeth.ch> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: <3C72AA96-539F-4DB0-A558-FCB3BC933BB7(a)iaeth.ch> > Content-Type: text/plain; charset=utf-8 > > Wojtek > > Every module has a counter where it registers how many times it got > imported. As long there is a module X importing module Y you cannot unload > module Y. You first have to unload module X, the counter of Y is > decremented and when it is 0 you can unload Y. > > J?rg > > Am 27.09.2016 um 07:44 schrieb Skulski, Wojciech < > skulski(a)pas.rochester.edu>: > > > >> Actually Oberon modules ARE allocated on the heap. This is the beauty > of Oberon that you can load and unload them dynamically. > > > > Yes, but only a single copy. Duplication of the same code makes no > sense. In that sense modules are different from objects. > > > > BTW, how about safety of unloading the code? In BlackBox they do not > unload, they deactivate. How about the Oberon System? > > > > W. > > > > J?rg > > > >> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech < > skulski(a)pas.rochester.edu>: > >> > >> Lars: > >> > >>> An interesting thought: if one were to make a module allocated at run > time > >>> would this offer anything useful or different than an object being > >>> allocated? > >> > >> A module provides executable code. There is only one copy of the > module's code. An object provides data and pointers to the code, but it > does not provide the actual code. There can be multiple copies of the > object. Each copy can provide different data, but the same pointers to the > same code. Note that in this description I have in mind Oberon-2 objects > rather than Oberon-1 objects. Oberon-1 objects are more difficult to > understand because the pointers to the code can be installed at run time. > Note however, that Oberon-1 objects do not provide the code. Just the > pointers. > >> > >>> Or would we reinvent object oriented programming if modules > >>> could be allocated on the heap? If we just reinvented objects, now we > >>> know exactly what modules are: design time objects without any heap > >>> allocation at run time. > >> > >> You put the module on the heap with its code, because it is the > module's goal to provide the code. OK. Now you need to execute that code > from the heap. OK. You allocate another copy of the module on the heap. So > you put the same executable code on the heap for the 2nd time. Now you can > execute it. (If you cannot, then allocating the code would make no sense.) > So now you have two copies of the same executable code on the heap. It > makes little sense. > >> > >> W. > >> -- > >> Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related > systems > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists. > inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c= > kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_ > BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNC > DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e= > > > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists. > inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c= > kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_ > BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNC > DNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e= > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > > ------------------------------ > > Message: 9 > Date: Tue, 27 Sep 2016 07:45:59 +0200 > From: J?rg Straube <joerg.straube(a)iaeth.ch> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Oberon for a C++ user. > Message-ID: <953EB47C-DD0F-473C-B6F5-371E5E403A2D(a)iaeth.ch> > Content-Type: text/plain; charset="utf-8" > > Lars > To be precise the Oberon sysem has two types of heaps: A heap for code and > a heap for data. See Figure 8.1 in https://www.inf.ethz.ch/ > personal/wirth/ProjectOberon/PO.System.pdf > J?rg > > > Am 27.09.2016 um 07:29 schrieb J?rg Straube <joerg.straube(a)iaeth.ch>: > > > > Lars > > Actually Oberon modules ARE allocated on the heap. This is the beauty of > Oberon that you can load and unload them dynamically. > > J?rg > > > >> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech < > skulski(a)pas.rochester.edu>: > >> > >> Lars: > >> > >>> An interesting thought: if one were to make a module allocated at run > time > >>> would this offer anything useful or different than an object being > >>> allocated? > >> > >> A module provides executable code. There is only one copy of the > module's code. An object provides data and pointers to the code, but it > does not provide the actual code. There can be multiple copies of the > object. Each copy can provide different data, but the same pointers to the > same code. Note that in this description I have in mind Oberon-2 objects > rather than Oberon-1 objects. Oberon-1 objects are more difficult to > understand because the pointers to the code can be installed at run time. > Note however, that Oberon-1 objects do not provide the code. Just the > pointers. > >> > >>> Or would we reinvent object oriented programming if modules > >>> could be allocated on the heap? If we just reinvented objects, now we > >>> know exactly what modules are: design time objects without any heap > >>> allocation at run time. > >> > >> You put the module on the heap with its code, because it is the > module's goal to provide the code. OK. Now you need to execute that code > from the heap. OK. You allocate another copy of the module on the heap. So > you put the same executable code on the heap for the 2nd time. Now you can > execute it. (If you cannot, then allocating the code would make no sense.) > So now you have two copies of the same executable code on the heap. It > makes little sense. > >> > >> W. > >> -- > >> Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related > systems > >> https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon >

1 0

Re: [Oberon] Elegance and simplicity
by Brian Clausing 26 Sep '16

26 Sep '16

Please excuse any error in sending this submission; it's my first time. May I recommend "The Search for Simplicity" by Per Brinch Hansen, the Diamond Cutter, another grandmaster analyst and programmer. Brian Clausing

1 0

Einstein said...
by Srinivas Nayak 26 Sep '16

26 Sep '16

I am surprised to read... "I adhered scrupulously to the precept of that brilliant theoretical physicist L. Boltzmann, according to whom matters of elegance ought to be left to the tailor and to the cobbler." in "Relativity: The Special and the General Theory", by Albert Einstein. But following his statement, "Make things as simple as possible, but not simpler." (which surprisingly Einstein didn't mention in any of his writings!) are we not seeing simplicity as elegance? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

1 0

Re: [Oberon] revisions in sources.
by Chris Burrows 23 Sep '16

23 Sep '16

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > peter(a)easthope.ca > Sent: Saturday, 17 September 2016 12:43 AM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Re (2): revisions in sources. > > > If I am interested in the detail of the code changes I keep > snapshots > > of the source folder(s) and use a difference listing / merge tool > like > > BeyondCompare (a Windows application by Scooter Software) to > identify > > /synchronise the code changes. > > A personal archive. You don't sell Astobe with a list of revisions > for the buyer to make before using. Correct? > Not correct - 'sell' is the key difference here. Every release of the *commercial* version of Astrobe is accompanied by a document called e.g. 'What's New in Astrobe for Cortex-M4'. This summarises the new features and the bugs fixed since the last major release. For an example see: http://www.astrobe.com/Cortex-M4/WhatsNew.htm In my mind there is a clear distinction between commercial and non-commercial software. (Note that I deliberately refrain from the use of the ambiguous term 'free' - it means too many different things to different people). My comments were made in the context of software where the source code is provided without any monetary requirements or other strings attached e.g. Project Oberon. I am extremely grateful to such authors (e.g. Niklaus and Paul) and would not *expect* them to do any additional work which I am capable of doing myself. Anything above and beyond the source code itself that the authors *choose* to provide (e.g. documentation, support etc.) I consider to be an unexpected bonus - certainly not a requirement. However, I have very different requirements for the commercial software products that I willingly pay money for. I then have an expectation that I will have to spend less of my time in order to get productive use out of the product. I expect the vendor to comply with the terms and conditions that we have agreed upon. The more I pay for a product, the better service and support I expect. Everything that I do in relation to my commercial software is based on the assumption that my customers have the same expectations as me, Regards, Chris Chris Burrows CFB Software http://www.astrobe.com

4 3

Re (2): revisions in sources.
by peter＠easthope.ca 16 Sep '16

16 Sep '16

From: Chris Burrows <chris(a)cfbsoftware.com>, Wed, 14 Sep 2016 18:01:27 +0930 > If I am interested in the detail of the code changes I keep > snapshots of the source folder(s) and use a difference listing > / merge tool like BeyondCompare (a Windows application by > Scooter Software) to identify /synchronise the code changes. A personal archive. You don't sell Astobe with a list of revisions for the buyer to make before using. Correct? >From chris at cfbsoftware.com Thu May 7 00:19:29 2015 > That is the intention of the *existing* Oberon Community Platform > from ETH. It has a wiki, forum etc. > http://www.ocp.inf.ethz.ch/wiki/ Yes, It's admirable. I've contributed to it. Two significant capabilities are not in the OCP and are available with MediaWiki. Page specific history with convenient difference display. Page specific discussion. >From joerg.straube at iaeth.ch Wed Apr 20 18:50:55 2016 > I would appreciate a repository of ProjectOberon, where the > community can contribute instead of having independent forks. When two articles in Wikipedia address the same topic they are merged. Sooner or later. Very few competing articles on one topic survive more than a few years before merger. Eventally sanity prevails over ego. > In my point of view, WikiBook doesn't seem to be the best choice for this task. Acknowleged. What is better or best? Bernhard mentioned difficulty in configuring Sourceforge to archive Oberon source Texts while allowing convenient reading by a human. Oberon sources appear almost as plain texts. In a few places recent revisions are colored. The visual appearance is easily achieved with HTML. Therefore a question. Would a MediaWiki publication of sources as ASCII or HTML, having the same visual appearance as in Oberon, violate the ETH license? I can't discern the answer. Currently these are the two most relevant forms. https://en.wikibooks.org/wiki/Subject:Computing https://wikisource.org/wiki/Wikisource:About_Wikisource Hypothetically there might be a MediaOberon which handes a Text without corruption. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Oberon / Linux RISC-V
by Peter Matthias 14 Sep '16

14 Sep '16

Hi all, since everyone now knows the difference between RISC-V and RISC-5, I think it's time to publically announce a public preview of Oberon/Linux RISC-V. It is based on the MIPS version. Virtually only three Modules needed to be changed --Linux0, OPL and OPC. It is available here: http://oberon.wikidot.com To test, you need qemu from here: https://github.com/arsv/riscv-qemu , make risv32-linux-user target, compile RCompiler.CompileV from OLR.Make.Tool and link the static core via the next MBootLinker command. It still has lots of bugs but lots of modules compile and work, even parts of gadgets. Regards, Peter

1 0

revisions in sources; was: Project Oberon Hardware
by peter＠easthope.ca 14 Sep '16

14 Sep '16

Chris, >From chris at cfbsoftware.com Thu May 7 00:19:29 2015 > That is the intention of the *existing* Oberon Community Platform from ETH. > It has a wiki, forum etc. > > http://www.ocp.inf.ethz.ch/wiki/ Suppose that in NO, you fix a bug in one procedure. How would you record that in the OCP? Describe the change? One or two corrections in a fresh installation is not a difficulty. A few dozen corrections in a fresh installation is too time consuming. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

2 1

Re (2): RISC-5; was RISC5
by peter＠easthope.ca 12 Sep '16

12 Sep '16

From: Pablo Cayuela <pablo.cayuela(a)gmail.com>, Sat, 10 Sep 2016 19:46:12 -0300 > You could check Wirth's RISC versions here: > https://www.inf.ethz.ch/personal/wirth/FPGA-relatedWork/RISC.pdf Thanks Pablo. The glossary entry in https://en.wikipedia.org/wiki/Oberon_%28operating_system%29 now has the directory. Googling "risc-5" yields the article as the third result with the extract including "RISC-5". ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

Project Oberon video presentation / review
by Chris Burrows 12 Sep '16

12 Sep '16

I discovered an interesting video of a review of Project Oberon presented by Michal Gadja at one of the meetings of a group of engineers in Singapore last year: https://www.youtube.com/watch?v=8K84aG72Dw8 Regards, Chris Burrows CFB Software http://www.astrobe.com

2 1

Re (3): RISC5
by peter＠easthope.ca 11 Sep '16

11 Sep '16

From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu>, Sun, 11 Sep 2016 03:06:08 +0000 > BRAM means Block RAM. It is Xilinx terminology. > Other vendors (Altera, Lattice) name it differently. OK, thanks. I've added it to a disambiguation page. https://en.wikipedia.org/wiki/Bram "BRAM" is in red as long as an article with that name doesn't exist. This can be improved by describing BRAM in an existing article. See https://en.wikipedia.org/Computer_memory . Or by making an article dedicated to BRAM. Then by linking the disambiguation to the target. Anyone can work on it. Before that happens, any editor can remove the entry from the disambiguation page. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0