October 2008 - Oberon - mailman3.inf.ethz.ch

Platform independent IDE?
by Douglas G. Danforth 09 Dec '08

09 Dec '08

2 2

Re: Oberon Digest, Vol 61, Issue 16
by Søren Renner 31 Oct '08

31 Oct '08

What's this {DELEGATE} syntax? What does that do? On Fri, Oct 31, 2008 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 and closures (Aubrey.McIntosh(a)Alumni.UTexas.Net) > 2. Re: Oberon and closures (Alexander Iljin) > 3. Re: Oberon and closures (B. Smith-Mannschott) > 4. Re: Oberon and closures (B. Smith-Mannschott) > 5. Re: Oberon and closures (Thomas Frey) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 30 Oct 2008 10:02:50 -0500 > From: Aubrey.McIntosh(a)Alumni.UTexas.Net > Subject: Re: [Oberon] Oberon and closures > To: "ETH Oberon and related systems" <oberon(a)lists.inf.ethz.ch> > Message-ID: > <6d278c720810300802ia8c47e0s2e2576523d1ff990(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I thing I read that procedure variables are being depreciated because > the literature finds some problem with them. I forget what the > problem is. Also, I haven't any clue what a "closure" is other than > this discussion, so I would appreciate any pointer to info that may be > more focused than my own Google search. > > Anyway, I tried to modify the example a bit more so that it used type > bound procedures, not procedure variables. Here is the version for > Component Pascal. > > > MODULE PrivClosureExample; > (* my oberon is also a little rusty *) > > TYPE > Printer = POINTER TO Closure; > > Closure = RECORD > n-: INTEGER; > END; > > VAR p, q: Printer; > > PROCEDURE (this:Printer) Print, NEW; > END Print; > > PROCEDURE CreatePrinter*(i: INTEGER): Printer; > VAR s: Printer; > BEGIN > NEW(s); s.n :=i; RETURN s > END CreatePrinter; > > BEGIN > p:=CreatePrinter(2); > q:=CreatePrinter(3); > p.Print; > q.Print > END PrivClosureExample. > > > On Thu, Oct 30, 2008 at 3:25 AM, Jörg Straube <joerg.straube(a)iaeth.ch> > wrote: > > > >>> From Wikipedia we find > >>> As a consequence, closures can be used to hide state, > >>> and thus to implement object-oriented programming > > > > As Oberon is object-oriented, we don't need the concept > > of "closures" to implement OOP. > > > > Joerg > > > > > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > > > > -- > -- > Aubrey McIntosh, Ph.D. > 1502 Devon Circle > Austin TX 78723-1814 > http://home.grandecom.net/~amcintosh/aubrey/Search/<http://home.grandecom.net/%7Eamcintosh/aubrey/Search/> > > > ------------------------------ > > Message: 2 > Date: Thu, 30 Oct 2008 21:11:05 +0600 > From: "Alexander Iljin" <ajsoft.gm(a)gmail.com> > Subject: Re: [Oberon] Oberon and closures > To: "ETH Oberon and related systems" <oberon(a)lists.inf.ethz.ch> > Message-ID: > <950bc9920810300811g1f930c2frc7227bd64c1bf01c(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello! > > On 10/30/08, Aubrey.McIntosh(a)alumni.utexas.net > <Aubrey.McIntosh(a)alumni.utexas.net> wrote: > > I would appreciate any pointer to info that may be > > more focused than my own Google search. > > http://en.wikipedia.org/wiki/Closure_(computer_science)<http://en.wikipedia.org/wiki/Closure_%28computer_science%29> > > > ------------------------------ > > Message: 3 > Date: Thu, 30 Oct 2008 17:54:24 +0100 > From: "B. Smith-Mannschott" <benpsm(a)gmail.com> > Subject: Re: [Oberon] Oberon and closures > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Message-ID: <9014DD6E-0B81-4246-9021-D52AF8A7291E(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > > On Oct 30, 2008, at 09:11, Jörg Straube wrote: > > > > > What about this? > > > > MODULE Example; > > (* my oberon is also a little rusty *) > > TYPE > > Printer = POINTER TO Closure; > > Closure = RECORD > > n-: INTEGER; > > Print: PROCEDURE(); > > END; > > PROCEDURE CreatePrinter*(i: INTEGER): Printer; > > VAR s: Printer; > > BEGIN > > NEW(s); s.n :=i; RETURN Printer > > END > > > > VAR p, q: Printer; > > BEGIN > > p:=CreatePrinter(2); > > q:=CreatePrinter(3); > > p.Print > > q.Print > > END Example. > > > > > > Joerg > > Indeed, there is an equivalence between objects (state with behavior) > and > closures (behavior with state). > > Anton van Straaten observed a few years ago (more humorously than I > could manage): > > <http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html > > > The venerable master Qc Na was walking with his student, Anton. > Hoping to > prompt the master into a discussion, Anton said "Master, I have heard > that > objects are a very good thing - is this true?" Qc Na looked pityingly > at > his student and replied, "Foolish pupil - objects are merely a poor > man's > closures." > Chastised, Anton took his leave from his master and returned to his > cell, > intent on studying closures. He carefully read the entire "Lambda: The > Ultimate..." series of papers and its cousins, and implemented a small > Scheme interpreter with a closure-based object system. He learned > much, and > looked forward to informing his master of his progress. > > On his next walk with Qc Na, Anton attempted to impress his master by > saying "Master, I have diligently studied the matter, and now understand > that objects are truly a poor man's closures." Qc Na responded by > hitting > Anton with his stick, saying "When will you learn? Closures are a poor > man's > object." At that moment, Anton became enlightened. > // Ben > > ------------------------------ > > Message: 4 > Date: Thu, 30 Oct 2008 18:00:28 +0100 > From: "B. Smith-Mannschott" <benpsm(a)gmail.com> > Subject: Re: [Oberon] Oberon and closures > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Message-ID: <7E838A5B-F59A-4033-A414-E59C97CC60C7(a)gmail.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Oct 30, 2008, at 09:16, Bob Walkden wrote: > > >>> So, yes, you can create a closure in Oberon. > >> > >> Well, no, not really. The Module being a single giant closure over > >> all the procedures defined in it is *not* what is generally meant by > >> "closure". In particular, languages which support closures generally > >> allow something like this: > >> > >> MODULE Example; > >> (* my oberon's a little rusty *) > >> TYPE > >> Printer = PROCEDURE(); > >> VAR > >> p, q: Printer; > >> > >> PROCEDURE CreateNumberPrinter(n: INTEGER): Printer; > >> PROCEDURE PrintingProcedure; > >> BEGIN Out.WriteInt(n) > >> END PrintingProcedure; > >> BEGIN > >> RETURN PrintingProcedure > >> END CreateNumberPrinter; > >> > >> BEGIN > >> p := CreateNumberPrinter(1); > >> q := CreateNumberPrinter(2); > >> p; (* prints 1 *) > >> q; (* prints 2 *) > >> END Example; > >> > >> Note that each invocation of CreateNumberPrinter creates a new > >> closure > >> over the nested procedure PrintingProcedure. In fact the fact that > >> Pascal/Modula/Oberon only allows top-level procedures as procedure > >> values appears to be a direct result of the fact that the language > >> doesn't support proper closures. (In order to support closures as > >> above you need something more involved than a simple stack as an > >> instance of PrintingProcedure needs to find its "n", even after the > >> CreateNumberPrinter that created it is no longer active on the > >> stack). > >> > > > > "the language doesn't support proper closures" > > > > What are the benefits of supporting this? It doesn't feel to me as > > though it is > > in 'the spirit of Oberon'. It feels like the kind of accident > > waiting to happen > > that Prof. Wirth preferred to avoid. > > Yes supporting full closures would have complicated the compiler and/or > the runtime system considerably and wouldn't have been in Wirth's style. > By choosing not to indulge in this feature he was able to keep his > languages > and compilers far smaller and simpler than they otherwise would have > been. > > There's no law that says that every language must support closures (or > tail call eliminiation, or mult-methods, continuations, or ...) and I > for > one am glad that Wirth chose to keep Oberon simple. > > // Ben > > > ------------------------------ > > Message: 5 > Date: Thu, 30 Oct 2008 20:58:26 +0100 > From: Thomas Frey <thomas.frey(a)alumni.ethz.ch> > Subject: Re: [Oberon] Oberon and closures > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Message-ID: <490A11E2.1070508(a)alumni.ethz.ch> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > In Active Oberon we have an additional way of simulating (strongly > typed) closures. > > Concept: > the reachable state of the closure function is stored in the fields of a > local OBJECT type (POINTER TO RECORD) (Note : Bound variables in > functional languages are "read only", here we rely on the programmer) > The closure itself is then a delegate procedure variable bound to a > method of an instance of the local OBJECT (class). The delegate > encapsulates the code and the state (as a closure) > > The advantage of this way of doing a "closure" is that the computational > effort is visible to the programmer and not hidden behind the scene as > in other languages. (Note : Using objects and delegates normally allows > for more natural solutions than the following example which tries to > mimic closures as closely as possible) > > MODULE Closure; (** AUTHOR "tf"; PURPOSE "closure simulation"; *) > > IMPORT > Out := KernelLog; > > TYPE > Printer = PROCEDURE {DELEGATE} (); > > (* creates a closure *) > PROCEDURE CreatePrinter(nr : LONGINT): Printer; > TYPE > (* container for the accessed scope *) > PrinterClosure = OBJECT > VAR nr : LONGINT; (* state *) > > (* functionality, able to access the "copied scope"*) > PROCEDURE Print; > BEGIN > Out.Int(nr, 0); Out.Ln; > END Print; > END PrinterClosure; > > VAR > closure : PrinterClosure; > BEGIN > (* create the container for the bound variables *) > NEW(closure); > (* "bind" the variables *) > closure.nr := nr; > (* return the closure *) > RETURN closure.Print; > END CreatePrinter; > > > PROCEDURE Test*; > VAR print : Printer; > BEGIN > print := CreatePrinter(5); > (* use the closure *) > print(); > END Test; > > END Closure. > > Closure.Test > > --Thomas > > B. Smith-Mannschott schrieb: > > > > On Oct 30, 2008, at 09:16, Bob Walkden wrote: > > > >>>> So, yes, you can create a closure in Oberon. > >>> > >>> Well, no, not really. The Module being a single giant closure over > >>> all the procedures defined in it is *not* what is generally meant by > >>> "closure". In particular, languages which support closures generally > >>> allow something like this: > >>> > >>> MODULE Example; > >>> (* my oberon's a little rusty *) > >>> TYPE > >>> Printer = PROCEDURE(); > >>> VAR > >>> p, q: Printer; > >>> > >>> PROCEDURE CreateNumberPrinter(n: INTEGER): Printer; > >>> PROCEDURE PrintingProcedure; > >>> BEGIN Out.WriteInt(n) > >>> END PrintingProcedure; > >>> BEGIN > >>> RETURN PrintingProcedure > >>> END CreateNumberPrinter; > >>> > >>> BEGIN > >>> p := CreateNumberPrinter(1); > >>> q := CreateNumberPrinter(2); > >>> p; (* prints 1 *) > >>> q; (* prints 2 *) > >>> END Example; > >>> > >>> Note that each invocation of CreateNumberPrinter creates a new closure > >>> over the nested procedure PrintingProcedure. In fact the fact that > >>> Pascal/Modula/Oberon only allows top-level procedures as procedure > >>> values appears to be a direct result of the fact that the language > >>> doesn't support proper closures. (In order to support closures as > >>> above you need something more involved than a simple stack as an > >>> instance of PrintingProcedure needs to find its "n", even after the > >>> CreateNumberPrinter that created it is no longer active on the stack). > >>> > >> > >> "the language doesn't support proper closures" > >> > >> What are the benefits of supporting this? It doesn't feel to me as > >> though it is > >> in 'the spirit of Oberon'. It feels like the kind of accident waiting > >> to happen > >> that Prof. Wirth preferred to avoid. > > > > Yes supporting full closures would have complicated the compiler and/or > > the runtime system considerably and wouldn't have been in Wirth's style. > > By choosing not to indulge in this feature he was able to keep his > > languages > > and compilers far smaller and simpler than they otherwise would have > been. > > > > There's no law that says that every language must support closures (or > > tail call eliminiation, or mult-methods, continuations, or ...) and I > for > > one am glad that Wirth chose to keep Oberon simple. > > > > // Ben > > -- > > 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 > > > End of Oberon Digest, Vol 61, Issue 16 > ************************************** >

3 2

Oberon and closures
by Martin Bishop 30 Oct '08

30 Oct '08

Is it possible to create a closure in Oberon? If not, why not? what prevent it?

8 10

Re[2]: [Oberon] Oberon and closures
by Alexander Iljin 30 Oct '08

30 Oct '08

Hello! BSM> Well, no, not really. The Module being a single giant closure over BSM> all the procedures defined in it is *not* what is generally meant by BSM> "closure". In particular, languages which support closures generally BSM> allow something like this: BSM> MODULE Example; BSM> (* my oberon's a little rusty *) BSM> TYPE BSM> Printer = PROCEDURE(); BSM> VAR BSM> p, q: Printer; BSM> PROCEDURE CreateNumberPrinter(n: INTEGER): Printer; BSM> PROCEDURE PrintingProcedure; BSM> BEGIN Out.WriteInt(n) BSM> END PrintingProcedure; BSM> BEGIN BSM> RETURN PrintingProcedure BSM> END CreateNumberPrinter; BSM> BEGIN BSM> p := CreateNumberPrinter(1); BSM> q := CreateNumberPrinter(2); BSM> p; (* prints 1 *) BSM> q; (* prints 2 *) BSM> END Example; BSM> Note that each invocation of CreateNumberPrinter creates a new closure BSM> over the nested procedure PrintingProcedure. In fact the fact that BSM> Pascal/Modula/Oberon only allows top-level procedures as procedure BSM> values appears to be a direct result of the fact that the language BSM> doesn't support proper closures. (In order to support closures as BSM> above you need something more involved than a simple stack as an BSM> instance of PrintingProcedure needs to find its "n", even after the BSM> CreateNumberPrinter that created it is no longer active on the stack). You can use virtual methods (AKA type-boud procedures) instead of procedure variables to achieve similar functionality. The problem with the example above is that no persistent memory storage is allocated for different values of 'n'. Simply passing a value as a parameter allocates the memory on stack, and that is automatically released when the procedure terminates, hence it is not persistent. MODULE Exapmle; TYPE Printer = RECORD (* closure context description *) n: INTEGER END; VAR p, q: Printer; (* memory for 'n' is allocated within the RECORD *) PROCEDURE (VAR prn: Printer) PrintingProcedure; (* type-bound procedure (AKA method) executed in the 'prn' context *) BEGIN Out.WriteInt(prn.n) END PrintingProcedure; PROCEDURE CreateNumberPrinter(n: INTEGER): Printer; VAR res: Printer; (* result *) BEGIN res.n := n; (* initialize the context *) RETURN res END CreateNumberPrinter; BEGIN p := CreateNumberPrinter(1); q := CreateNumberPrinter(2); p.PrintingProcedure; (* prints 1 *) q.PrintingProcedure; (* prints 2 *) (* ALTERNATIVELY *) p.n := 1; q.n := 2; p.PrintingProcedure; (* prints 1 *) q.PrintingProcedure; (* prints 2 *) END Example; Therefore, if you don't like the idea of a module being a single static closure over all the procedures, you can describe the context of your closure in a RECORD variable with all the required fields, and use type-bound procedures to execute the same actions in different data contexts. Of course, you can make Printer a POINTER TO RECORD instead of RECORD, if you want to be able to have 'uninitialized' value (NIL) for 'p' or 'q'. Then you'll have to allocate instances of your contexts using the NEW standard procedure. ---=====--- Alexander

1 0

[Fwd: [BLACKBOX] ZLib for BlackBox? Yes]
by Douglas G. Danforth 29 Oct '08

29 Oct '08

This is claimed (below) also to be relevant to Bluebottle.

2 1

Re. Platform independent IDE? & spurious formats
by Chris Glur 18 Oct '08

18 Oct '08

-Doug Danforth wrote: > On how many different operating systems does N-O work? > (I use the words "operating systems" because I am not really > interested in the hardware and strongly wish to avoid any > bit string manipulation to configure the system to a specific > hardware platform. Those settings should be "preset" for > each platform/operating system mix that is supported) Well I've got it on: 1. native = plain PC, where the file-topics are partitioned into HD 'partitions'; each HD-partitions having a flat [non-heirarchial dir]. 2. DOS-based, where the Obn-files are embedded in a big DOS-file; 3. Linux-based, where the Obn-files are individually [by default in the dir, from where you started] as linux files and each edit creates a <fileName>.Bak; but you can, with some inconvenience access other directories of the Linux system. 4. then I've heard about a/the Win installation; There might be others. This is a classical question for the 1st level FAQ. Since Linux-Aos/BB is now listed for Linux, Solaris and MacOSX, then perhaps N-O is too ? BTW for anyone running Linux-ETH-oberon, you *must* use [probably several processes of] 'mc' [the clone/improvement of the original brilliant DOS-Norton-Commander]. It's visual, like N-O. Not Walt Disney [cartoon based] like Win, but like a spreadsheet, you 'see and select, what you want to process', instead of imagining the machines state and writing appropriate notes to the little man in the box. Here's an example of 'writing a note..' instead of 'see and do' which is the limit of my piano-playing-showing-off and only possible because I gave the file a one-letter-mnemonic name: 'o'. I want to see [to copy for pasting] that path mentioned in file /root/o The proper way, like with ETH-oberon [get the fileName, open the file and 'see' to copy] is to use mc: 1. go to dir; 2. open/view-file [by single click or <F3>]. But piano-playing-note-writing [comand line input]can do: 'cat /root/o' which is OK if you are prepared to burden your memory with the file's name. And lucky the output is only 2 lines, so it won't scroll off the screen and be difficult to locate. What I'm emphasising is that without mc [which integrates well with ETH-Oberon] Linux-ETHoberon and perhaps Linux-Aos/BB isn't so convenient. ----------- > Academia vs Business > With all of the lovely work going on at ETHZ it continually > amazes me that there are not more spin-offs to commercialize > that work. > > Oberon Microsystems was one such effort. I don't want to > characterize it as to a success or failure but simply say that > what they produced is very acceptable from the commercial > side. If they had completed their goal of platform independence, > I believe, they would have been more successful. One does not > have to dominate a market in order to be a success. > > So why isn't Bluebottle supported as a shrink wrapped product > for the major platforms? ----------- I guess it's not about technology or rational economic decisions. Like the current global [now correcting] economic behaviour: everybody did it because every body else did it. Although ETH-Oberon remains irrelevant in the PC market, it may feature in the growing portable/less-power-consumption market ? ----------- Treutwein Bernhard wrote: > Re 1: ETHZ is struggling for industry cooperation, see > "http://www.oberon-industry.ethz.ch/" and > http://www.oberon.ethz.ch/partnerships/index That sounded interesting, but my 'proper-browser' is holding text with diagrams. So I tried with my Lixux-ETH-oberon browser [images disabled by default] and evaluate both pages to be poor, based on the ratio of images & java-script to valuable text info. By contract, MIT's brilliant: "http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html" loads perfectly under Lixux-ETH-oberon, and after I've confirmed that the contents is more than "Life is better with Coke", I d/l the diagrams. And then I multicolour the text while studying it. And end up with a personally customised tutorial, where I can cutNpaste the text and even the diagrams to other files. So IMO the 2 http://www.oberon* fail to distinguish themselves from the multitude of art-school-kiddie derived 'pages', which I would normally just skip-over. OTOH, to mention something astounding of ETH-Oberon which seems not to be well known: the Scheme and Vinci system is a complete Scheme system [which I've only done preliminary tests on so far] on top of which is abstracted a remarkable VHL graphics rendering application. Together they give a stunning example of building levels of abstraction. Scheme is built on top of Oberon and Vinci is built on Scheme. Has this been carried over to BB/Aos ? Perhaps Layla is similar to Vinci ? == Chris Glur.

1 0

Re. Platform independent IDE? & spurious formats
by Chris Glur 17 Oct '08

17 Oct '08

On Date: Sun, 12 Oct 2008 16:09:12 -0700 "Douglas G. Danforth" <danforth(a)greenwoodfarm.com> using User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 was asking some interesting question/s. I only decode-read the first: > (1) Does a cross platform IDE (Integerated Development Environment) > exist for Oberon? Because I resent having to decode eg: } .....<br> }  (I know Since I wrote in my previous post how I value N-O's ability to mult-colour-mark text, perhaps some people find html/mime email valuable ? Re. IDE, one should perhaps formally define the expected components ? ? all module-files grouped together & easily accessible ? minimum effort compile-edit-run cycling ? perhaps debugging facilities N-O has hex-view/edit of files & decodeX86 seems interesting but buggy [my 2001 version] & not used/maintained. The Trap and 'find error position (select PC line in Trap viewer)' facilities are excellent, but perhaps only available for X86 machines. I used to wonder why N-O's development environment was, for me, inferior to DOS-Turbo-Pascal's. Now I realise it's because N-O program development is integrated into the "universe" ! Not just restricted to compile-edit-run cycling. Eg. it has easy access to email, ftp, http ...google, DOS, MAC, Unix formatting ...etc which are all potentially part of the development cycle. So for a narrow/restricted Jonny-in-the-work-cubible view, DOS-Turbo-Pascal's IDE was more productive. But for development on a higher level eg. investigating what algorithms to use, N-O is superior. == Chris Glur.

2 1

Re: [Oberon] Platform independent IDE
by Douglas G. Danforth 17 Oct '08

17 Oct '08

Treutwein Bernhard wrote: > Re 1: ETHZ is struggling for industry cooperation, see > http://www.oberon-industry.ethz.ch/ and > http://www.oberon.ethz.ch/partnerships/index I have some experience in this regards and so can commiserate. Stanford's Center for the Study of Language and Information (CSLI) has an Industrial Affiliates program where members pay $50k a year to get access to professors' research and a limited amount of time co-developing prototypes projects. It was my task to support some of those affiliates and also establish new ones. Support I was able to do. To find new ones I failed miserably. This is not easy. One must be in sales and marketing to attract. As a researcher I don't have those skills (or desire). In retrospect I probably should have established contacts with Stanford's business school and gotten some graduate students who were interested in sales and marketing and have them act on my behalf in a cooperative and money sharing deal (with approval, of course, of all parties involved). -Doug Danforth

1 0

What can BB/Aos do more than N-O ?
by Chris Glur 16 Oct '08

16 Oct '08

I'm considering installing the 29MB LinuxAos over the weekend, since LinuxOberon has proved very useful. Having 4 installations of LinuxOberon running simultaneously may seem absurd. But I find the ability to colour a text, like a scholar would use koki-pens on paper texts, very powerfull. Often I need 20 sessions of 10 minutes each to absorb a text. And this may be stretched over 10 days. So I want to have immediate access to at least 3 currently coloured texts, each having the full user-track. The other installation is for miscelaneous use. I had a near mishap-disaster, which is unlikely to be known about, with a sparse LinuxOberon user-population. I nearly lost a whole dir-tree, by trying to write an ET-text directly to a specified linux <path>/<fileName> by editing the ET-text's Menu-name. My error was to write: <path> <space> <fileName>, which wasn't detected as an error. But was interpreted as: <path> . Fortunately I looked at the directory via linux > mc before making another bad store, and found that the directory tree had been renamed to <name>.Bak If LinuxOberon, LinuxAos gains wider usage, it should have a public listing of warnings for such quirks, like N-0 developed a type of 'hints-page/s'. == Chris Glur.

1 0

RE: [Oberon] Platform independent IDE
by Treutwein Bernhard 15 Oct '08

15 Oct '08

For Linux, Solaris and MacOSX see: http://www.informatik.uni-bremen.de/~fld/UnixAos/Readme.txt but I don't have any experiences with it ... -- Bernhard > -----Original Message----- > From: Søren Renner [mailto:soren.renner@gmail.com] > Sent: Tuesday, October 14, 2008 4:05 PM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Platform independent IDE > > > Maybe WinAos? > > On Linux, "wine WinAos.exe" works fairly well. > > >

2 1