August 2002 - Oberon - mailman3.inf.ethz.ch

Re: Major feature undocumented & dir-info
by cglur＠onwe.co.za 18 Aug '02

18 Aug '02

Peter Easthope wrote: > cg> Peviously my comments about the "menu frame collapsed into > a dropdown menu for SystemFrame usage", got no response. > .. > cg> Let me now be more direct: > HELLO!! Is anybody aware of this facility ? > > No. How do I see this phenomenon? Is it in TUI > or in GUI? GUI { Desktops.OpenDoc }. For n-o alpha 2001 try: 1. mark SystemTrack {F1} 2. Desktops.OpenDoc SysTrk ~ Now lets move on the the consequential question(s). Is it good that we have such 'unknown' features ? And if not, how do we prevent this ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The output of "System.Directory ...\d" can be filtered > with RX. This is good way to find files with a specific > date or range of dates. This would be a good solution. Charle's 1st format sequence: date, ID, size is best IMO, but messing with inner modules is a nono ! If someone can put it in a wrapper, that's good. But what happened to the earlier version panel that I mentioned ? We need some discipline in this factory !! I await a final working solution. > Since RX was extended (Patrik R., Andre F. ?) to > allow operation in TUI it is very useful. While on > the subject, let me ask this again. > > Can anyone explain why the search has a scope > of one line of a text file rather than the whole > text? This restriction prevents RX from making > changes extending beyond one line. For > example, I believe it can not join every successive > pair of lines into a single line. As far as I am > aware this is not an issue of the theory of regular > expressions. It must be necessitated by an > algorithm. Probably I should study the source > again but a little help would be fine. > Yes this is a serious limitation. I recently re-investigated it's use for a possible rough converter for WordPerfect files (my similar attempts for Postscript conversion was usefull - for me); and reading past line terminators is needed. What really annoyed me was the new Configuration.DoText which no longer read scripts with lines starting with space(s). So all my empirically derived translations embedded in script(s) were dead. > Also, RX.ReplaceAll fails to work for me. Can > anyone test? Is it a bug? re. alpha 2001, yes I re-tested it again recently (after long time no use) and found problems. Now, using TUI { Edit.Open } and marked {F1}. RX.SetSearch "(" (~"\") X0 RX.SetReplace X0 RX.ReplaceAll * seems to work. -- Chris Glur

1 0

ETH N-O Native/Beta directory display
by Charles Angelich 18 Aug '02

18 Aug '02

Hello Chris - On further reflection and with more tweaking I think I've come up with a more satifisfactory solution to your request to sort Oberon directories using reverse order by date. This has bee surprisingly useful here on my system which means we can both enjoy this minor alteration. :-) fwiw I took the time to count the chars allowed to display within the system and user tracks when using the VGA driver. 640x480 video display driver: System track = 36 Oberon10.Scn.Fnt chars User track = 63 Oberon10.Scn.Fnt chars Maintaining access to the menu bar commands in System.Tool, for instance, is a problem and other displays excede this space with text partially hidden. To increase the usefulness of the System.Directory display I have made the following changes.

2 1

Re: directory display using "\d"
by Peter Easthope 17 Aug '02

17 Aug '02

Charles, Stefan & others, Hopefully some of the good ideas you have both mentioned are implemented eventually. ca> I was trying to find a workable solution for all display sizes that would make the display useful. Not being able to easilly locate dates or filesizes makes me wonder why I would even bother to USE the "\d" switch? The output of "System.Directory ...\d" can be filtered with RX. This is good way to find files with a specific date or range of dates. Since RX was extended (Patrik R., Andre F. ?) to allow operation in TUI it is very useful. While on the subject, let me ask this again. Can anyone explain why the search has a scope of one line of a text file rather than the whole text? This restriction prevents RX from making changes extending beyond one line. For example, I believe it can not join every successive pair of lines into a single line. As far as I am aware this is not an issue of the theory of regular expressions. It must be necessitated by an algorithm. Probably I should study the source again but a little help would be fine. Also, RX.ReplaceAll fails to work for me. Can anyone test? Is it a bug? Thanks, Peter E. Peter Lyall Easthope http://carnot.pathology.ubc.ca/peter.html

1 0

Re: Major feature undocumented ?!
by Peter Easthope 17 Aug '02

17 Aug '02

Chris & others, cg> Peviously my comments about the "menu frame collapsed into a dropdown menu for SystemFrame usage", got no response. . cg> Let me now be more direct: HELLO!! Is anybody aware of this facility ? No. How do I see this phenomenon? Is it in TUI or in GUI? Thanks, Peter E. Peter Lyall Easthope http://carnot.pathology.ubc.ca/peter.html

1 0

n-o alpha 2001: please confirm/deny this bug
by cglur＠onwe.co.za 17 Aug '02

17 Aug '02

1. OFSTools.Mount <oldPartiton> AosFS IDE<IdeNo>#<partnNo> ~ 2. System.Directory <oldPartiton>:* 3. Select and open file ( < 1 screen viewer size) 4. cutNpaste viewer contents to <tempViewer> 5. Close viewer opened in 3. 6. OFSTools.Unmount <oldPartiton> 7. move or otherwise access <tempViewer> 8. Observer (or not): TRAP -14 NIL reference ( 0000006CH ) (PC Native 11.10.2001) Files.Set PC = 311 f = 00069300H pos = 49 r = 0000000CH Texts.OpenReader PC = 9676 R = 00000010H T = 0005FBA0H org = 3195 p = 00041100H pos = 3195 TextFrames.Extend PC = 3843 F = 0005FC20H L = 00043A80H R = 0000004CH botY = 26 curY = 356 newY = 17 org = 3195 TextFrames.Modify PC = 13496 F = 0005FC20H H = 402 Y = 17 dY = 18 id = 1 TextFrames.Handle PC = 22039 F = 0005FC20H F1 = 00000000H M = 00000020H MenuViewers.ModifyFrame PC = 1238 F = 0005FC20H ........................ ? Unresolved reference(s) ? -- Chris Glur. Where is the menu viewer popup (space saver) documented ?

1 0

Re: directory code for Chris G.
by Charles Angelich 17 Aug '02

17 Aug '02

>Message: 6 >From: cglur(a)onwe.co.za >Date: Sat, 17 Aug 2002 10:47:02 +0200 >To: oberon(a)inf.ethz.ch >Cc: cglur(a)onwe.co.za >Subject: [Oberon] Beginners only >Reply-To: oberon(a)inf.ethz.ch > > >>> You didn't say WHY the lines should not be broken? Any >>> particular reason you need just one line? >Yes. A one to one mapping is massively simpler (cognetively) than >a one to many. A jumbled line is a jumbled line - cognito ergo sum. >Charles Angelich wrote: >> The direcory display of N-O Sys 3 is not easilly used to locate >> a file by date or by size, only the filename is clearly visible. >> Any attempt to compare dates or sizes is extremely difficult >> without columnar tabbing. > ..... > >> I was trying to find a workable solution for all display sizes >> that would make the display useful. Not being able to easilly >> locate dates or filesizes makes me wonder why I would even bother >> to USE the "\d" switch? > >After downloading (eg. ftp) where there's a possible doubt of >error(s) like the *.zip(s) which still don't expand under (updated) >n-o (yet when moved to linux do), it's reassuring to be able to >confirm the right size. Size is perhaps the coursest check ? > >Date is most usefull. >I have SmartDir.Tool , given to me (to test) some years back, which >apparently hasn't been include in the standard distribution yet. >Another example of 'community fragmentation' . >I use it about 10 times a week; mostly for relocating files which I >know I've worked on recently, but have forgotten the name of. > >On my Ver 2.3.2, there is a 'findPanel' which I never knew how >to use, which has a setable date-parameter. Why this was dropped >from later versions I don't understand. I can't believe that other users >don't need files located by date order! Norton Commander, (cloned >to mc for linux - the best utility outside n-o) offers file listing ordered >by saved-time/reversed - most usefull. > >Perhaps Charles can use some of his excess energy If I were to slow down, for whom would I be waiting? >to refine the existing >code to give a listing ordered in reverse (most recent=first) date/time ? >I'll do the testing. Sure, test this:

1 0

Beginners only
by cglur＠onwe.co.za 17 Aug '02

17 Aug '02

>> You didn't say WHY the lines should not be broken? Any >> particular reason you need just one line? Yes. A one to one mapping is massively simpler (cognetively) than a one to many. Charles Angelich wrote: > The direcory display of N-O Sys 3 is not easilly used to locate > a file by date or by size, only the filename is clearly visible. > Any attempt to compare dates or sizes is extremely difficult > without columnar tabbing. ..... > I was trying to find a workable solution for all display sizes > that would make the display useful. Not being able to easilly > locate dates or filesizes makes me wonder why I would even bother > to USE the "\d" switch? After downloading (eg. ftp) where there's a possible doubt of error(s) like the *.zip(s) which still don't expand under (updated) n-o (yet when moved to linux do), it's reassuring to be able to confirm the right size. Size is perhaps the coursest check ? Date is most usefull. I have SmartDir.Tool , given to me (to test) some years back, which apparently hasn't been include in the standard distribution yet. Another example of 'community fragmentation' . I use it about 10 times a week; mostly for relocating files which I know I've worked on recently, but have forgotten the name of. On my Ver 2.3.2, there is a 'findPanel' which I never knew how to use, which has a setable date-parameter. Why this was dropped from later versions I don't understand. I can't believe that other users don't need files located by date order! Norton Commander, (cloned to mc for linux - the best utility outside n-o) offers file listing ordered by saved-time/reversed - most usefull. Perhaps Charles can use some of his excess energy to refine the existing code to give a listing ordered in reverse (most recent=first) date/time ? I'll do the testing. -- Chris Glur. PS. Charles, your desire to have 'all instruments always visible' like a sports aircraft is inappropriate for computing. A 500 page book has one pair of opposing pages visible at one time. If your desk project has 3 envelopes, 2 books, 5 documents and a map, then you need to move them around, from partly coverd to 'focused' as you work. That's life. A work in progress is a dynamic entity -- until it hopefully disapears on completion. This ability to rapidly shuffle the documents around is intimately related to the n-o interface. You can't do it wearing boxing-gloves.

1 0

Re: user-friendly website
by Charles Angelich 16 Aug '02

16 Aug '02

>Message: 5 >From: cglur(a)onwe.co.za >Date: Fri, 16 Aug 2002 02:40:16 +0200 >To: oberon(a)inf.ethz.ch >Cc: cglur(a)onwe.co.za >Subject: [Oberon] Project Voyager ? >Reply-To: oberon(a)inf.ethz.ch > >Having been directed here, from this mailing list: > > http://www.statlab.uni-heidelberg.de/projects/voyager/ > >> Voyager is a project to explore the feasibility of a portable and >> extensible system for simulation and data analysis systems. > >I still don't see how this differs from S3, which is also a portable, >extensible system for simulation and data analysis ? > >Perhaps some project to which this is specifically aimed could be >listed to justify further investigation ? > >I have long maintained that persons who have been long and >deeply involved in developing new 'systems' are unqualified to write >an introduction to their project. For obvious reasons they can't have >an outsider's view. > >-- Chris Glur. My reaction to the Voyager webpages was similar to your own reaction. It appeared that I could construct this myself were I to have a need for those particular displays. btw: The bar graph does not seem to follow the actual datapoints shown but that's not important right now. ;-) If you were to direct a random sampling of experienced PC computer users to the ETH Oberon Sys 3 website they would be confounded and annoyed attempting to determine exactly what N-O Sys 3 is and how to locate a stable fully functional version that accomodates their other existing installed software and hardware. Criticism, in this instance, is a double edged sword that "cuts both ways". ;-) Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

2 1

Re:3 letter prefix (reserved)
by Charles Angelich 16 Aug '02

16 Aug '02

>Message: 4 >Date: Thu, 15 Aug 2002 09:44:35 -0400 >From: "Douglas G. Danforth" <danforth(a)greenwoodfarm.com> >Organization: Greenwood Farm Technologies LLC >To: oberon(a)inf.ethz.ch >Subject: [Oberon] Prefix >Reply-To: oberon(a)inf.ethz.ch > >Charles Angelich wrote: >> >> I would suggest that four letter prefix relevant only to the OS and it's >> applications would be more useful and user-friendly than arbitrary >> initials that mean nothing to me or any other computer user. > >More than four letters are possible with the current BlackBox prefix. >For example: > System > BTrees > Audio > ... I suspect at this point there is a divirgence. BlackBox must be one of the variants using subdirectories. N-O Sys 3 uses just one directory. A system of reserved 3 letter prefix may be OK for BlackBox users but is BlackBox now the flagship variant for N-O Sys 3 users to follow? >Oberon is written in a platform independent style hence no >specific OS information should appear anywhere unless it >specifically states that this is only for a specific OS. Using predetermined well defined 4 or even 5 letter prefix that are relevant to the purpose/function of modules would in no way interfere with "platform independence". Maintaining a database of three letter reserved prefix interferes with just about everything I can think of right now for every variant of Oberon. Locating a binary for a particular purpose should be somewhat intuitive, not an encrypted anagram. >Again, for example > Host >is a directory under BlackBox that holds host specific code. Again, this is only relevant to those variants that support subdirectories which N-O Sys 3 does not do. >I would not expect anyone to know what Gft stands for. It is >only after one learns that, for example, an eigenvalue package exists >from Greenwood Farm Technologies and is called GftEigen that >one would then know the meaning of the Gft prefix. > >There may be many other eigenvalue packages and so the user >will establish some 'feeling' that GftEigen is good or bad >depending upon experience in the same way that one learns >that Buick or Nissan are good or bad depending upon experience. > >-Doug Are you not willing to realize that were Oberon to become as mainstream as Linux we would need another DNS lookup to be able to maintain all of these three letter prefix and their relevance, if any, to using Oberon? This could become a nightmarish arrangement in a short time. Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

1 0

Re:direcotry display using "\d"
by Charles Angelich 16 Aug '02

16 Aug '02

>Message: 3 >From: Stefan Salewski <Salewski(a)PHYSnet.Uni-Hamburg.de> >Organization: Uni Hamburg >To: oberon(a)inf.ethz.ch >Subject: Re: [Oberon] Re: Oberon digest, Vol 1 #45 - 6 msgs >Date: Thu, 15 Aug 2002 13:55:49 +0200 >Reply-To: oberon(a)inf.ethz.ch > >On 15.08.2002 08:42 Charles Angelich wrote: >> As it displays now the dates don't line up and the sizes don't >> line. You didn't say WHY the lines should not be broken? Any >> particular reason you need just one line? >> >If the width of System.Log is large enough, then the output >of System.Directory with option /D should occupy only one line >for an entry, just to use the available space optimal. The direcory display of N-O Sys 3 is not easilly used to locate a file by date or by size, only the filename is clearly visible. Any attempt to compare dates or sizes is extremely difficult without columnar tabbing. >The Viewer of my System.Log (1280 x 1024 Monitor) is width >enough for filename, date and size on one single line. Can you locate the dates easilly when reading this single jumbled line of text? >But I agree with you that dates and file-sizes should not follow >direct after the filename, they should be ordered in columns. N-O Sys 3 has a 32 character maximum filename size. If you were to allow 32 characters for the filename column and a TAB to the next column (4 chars?) all of the other text would be offscreen to the right for a 640x480 display size (35 chararcters). >So your solution seems to be indeed an improvement, but it is >not optimal for wide displays. I was trying to find a workable solution for all display sizes that would make the display useful. Not being able to easilly locate dates or filesizes makes me wonder why I would even bother to USE the "\d" switch? Are you advocating NO backwards compatibility with earlier installs simply because YOU have a 1280x1024 screen size? This seems to be creating a rift here between those who "have" and those who "have not". What happened to the "keep it simple but no simpler" philosophy I've seen mentioned here earlier? Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

1 0