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

native oberon communty structure ?
by cglur＠onwe.co.za 05 Sep '02

05 Sep '02

> Stefan Salewski <Salewski(a)physnet.uni-hamburg.de> wrote: > > To gain new users (and developers) outside of ETH, the following may > > be usefull: > > - A clear statement of ETH about the planned future of Native-Oberon > > and BlueBottle. Pieter wrote: > While I can obviously not speak for the ETH and Prof. Gutknecht, I > can give you my opinion. > > > I think that the Active-Oberon-Language with BlueBottle-OS is very > > interesting. But at the same time I fear, that ETH-Oberon will die if > > the big ETH people like Pieter Muller and Patrik Reali will leave ETH. The oberon (world) community exists in/via NewsGroup c.l.o. and mailing-list(s). The re-structuring of the mailing-list(s) has sucked the life out of NewsGroup c.l.o. I think this is an unintended consequence ? The waves of 'what Wirth forgot to include in his design', which regularly used the sweep c.l.o. are now invading the mailing-list. I think these 'higher level' arguments apply to S3, V4, Black-box ...etc., and should liven up c.l.o. instead of infiltrating the mailing-list; which is better restricted to specific implememtation details. I.e. "philosophy of language design" is for c.l.o. Debugging of existing versions is for mailing list(s) - 'open', like linux. Not hidden. Software practice acknowledges the advantages of 'the several pairs of eyes' approach. Are any of you aware (have read) the social/psychological aspects of collaboration, analysed for the linux community ? Also for educational value and the spreading of competence through the n-o community, the fixing of errors should be open, with proper description of the analyses and proposed fix(s). Apparently because of the academic cycle, I got no response to some serious queries over the last 10-12 months. Fortunately I've kept my unreplied-to queries, to retry, with the now increased actively. -- Chris Glur.

1 0

Re (5): [Oberon] Homework on ZipTool
by peter_easthope＠gulfnet.sd64.bc.ca 05 Sep '02

05 Sep '02

Pat & others, p> ... documentation or as easily modified commands? ETHOberon seem to prefer the latter as do I. So the *.Tool files are really examples of command syntax rather than rigorous definitions except that options can shown in [] brackets. Is the content of a Tool file, a text in a formal language? I believe so. Hence the syntax can be specified by EBNF notation. In any case I forgot to include the .zip suffix along with .Zip. ZipTool.Directory [\d | \D] Zipfile.Zip ~ ZipTool.Directory [\d | \D] Zipfile.zip ~ ZipTool.Directory [\d | \D] Zipfile ~ (Suffix optional.) ZipTool.Directory [\d | \D] ^ p> Extraction of unconventional filenames. p> Are the offending filenames clearly identified by ZipTool.Directory? ... p> It's not clear to me how to modify ExtractAll to meet your needs. The strategy you suggest seems sensible. If someone wants to extract a specific file or files with unconventional names, replacement names are specified. When someone wants all the files extracted they let Extractall get all the files with conventional names and the unconventional names are listed in the process. These can be extracted later using "ZipTool.Extract badfilename1 => goodfileanme1 badfilename2 => goodfilename2 ~" as you said. Automation of Extractall beyond this appears inappropriate. Thanks, Peter E. Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Re (4): [Oberon] Homework on ZipTool
by pat＠picoworks.com 05 Sep '02

05 Sep '02

ZipTool contents. It depends on how you use .Tool files. As documentation or as easily modified commands? ETHOberon seem to prefer the latter as do I. Which raises the question where should this stuff be documented? Perhaps Andre' has an opinion, he has far more experience documenting the system than most. For a programmer the source code is the documentation. For those of us who need more help additional documentation can be very useful. See Project Oberon book. Anything similar for System3? Will there be for Bluebottle? RX.Tool may be a useful prototype. At the end of the tool is more detailed documentation including EBNF for the expression. DefaultStrategy Yes it appears the the default strategy is string matching. Extraction of unconventional filenames. Are the offending filenames clearly identified by ZipTool.Directory? If so I would edit the results into a command ZipTool.Extract badfilename1 => goodfileanme1 badfilename2 => goodfilename2 ~ RX should be able to help quickly build the conversion list. At least it should. I haven't used it yet. It's not clear to me how to modify ExtractAll to meet your needs. Anyone else want to chime in on this? Pat

1 0

screen scrolling and some idle talk
by Yuri M. Skripkah 05 Sep '02

05 Sep '02

Helo, All. Anybody know how to make horizontal and vertical scrolling for whole desktop(framebuffer)(for all TUI GUI Desktops) in n-o, as it is in X Window or some NT(tm) videodrivers? This may be useful for users with old monitors without affecting spirit of big screen. (* And in addition: Sorry, but mailing list content divided into two stream: a) ask about some definite topic and b) idle talk about marketing issues. IMHO for attracting new users ( if this goal is at all ) is more better publish all documentation in one tree in Oberon site as html (most of potentially users have web-browser :)),than extend support for various mouses. Now part of documentation is on paper in books, part hidden in articles, part in ps files. It is in dependence with copyright, of course, but may be one source is possible? And other problem with documentation including in installation is it intermediate level. It is not for full dummies, but not contain a lot of algorithmic grounds (source not give all grounds and not quite readable even by Oberon language ), especially in kernel. This make some difficulties for non-purposeful or busy user :( ,but: I think developers in ETH have not enough lifetime to support this users: it is their lifetime.*) -- Yuri mailto:yurix@i.com.ua

2 3

Re (2): [Oberon] Partitions -> Killer-ap
by cglur＠onwe.co.za 05 Sep '02

05 Sep '02

> > (it still needs to be refined to be ORDERED by date). Pieter wrote: > Try Sort.Sort * from Sort.Tool . This confirms (again) all the stuff that's available, but not used. Also Its good to be able to use existing facilities, instead of adding. <fileID>\ft \ System.Directory ^ \ F1 \ Sort.Sort * (almost) would be great to show the dir-STACK. Pity the date-format is 'mix-endian' instead of most significant left to right ordered. Several applications would want the date format to be 'machine (not human) style'. ------------------- Re. example for outside users of what n-o can do. Imagine a 1M4 diskette which starts/runs in a few seconds: - showing the ETH logo (discrete [swiss like]) - utility best to be menu driven - obviously need to be ML activated (perhaps any/all button) - perhaps also num-pad driveable for users without a mouse. - for eg. Partitions.Show detail ~ - perhaps enter a set of strings and partition, block-range to search/recover lost data. - and other facilities to 'see' various hardware... I have IDEs which various linux have problems fdisk-ing (FAT-partitions) and MS-DOS 6.22 & Win 98 can't see. Every time n-o sees every thing, without fail. Now with increasing numbers of linux experimenters, restoring MBRs is often needed. MS- fdisk \MBR failed for me and also my aquaintence who uses only the latest MS. Despite much effort I can't get confirmation (or not) that MBR's depend on the geometry. In which case A valid MBR can be recreated from the interogated geometry ? -- Chris Glur.

1 0

Partitions -> Killer-ap
by cglur＠onwe.co.za 04 Sep '02

04 Sep '02

> Since backingUp partitons is currently very tedious, I wondered if > one could backUp between IDE0/1 by having the same size > for corresponding partitions, and copying blocks n to last, where > n is the first few that have the 'partition linking info' ? > I.e copy the contents and don't mess with the 'house-keeping'. > Is this viable (for say 16 to 64 Mb sizes) ? > > PS. as I remember Partitions.Mod also has much undocumented > facilities ? Andr wrote: > Do you mean "disk image"? > Look for it in http://www.oberon.ethz.ch/betadocu.html > > If I don't err, that's what you looking for. > It is a viable approach. > OK, that would do. Although rather than the 'backup' (parachute) view, I prefer to view the project(s) cycling through a sequence of partitions -- in this case, just 2. So one could use the existing commands to: SrcPartn -> TempPartn -> DestPartn where sizeSrcPartn = sizeDestPartn =< sizeTempPartn But It is essential that bad blocks are detected. Important is that it can be done with a few clux (n-o cording) in a Tool or a script. Prof Gutknecht mentioned some years back that the dir-heirarchy was too liable for 'getting lost in'. I understood that he had some magic alternative; but since it has not yet been revealed, I've found the 3 level 'tree' concept works well for me, with n-o partitions. I use the 3 level heirachy: partition / file / section In <Personqal.Tool> I've got (colour coded mnemonically): Configuration.DoText MountSocEcon Configuration.DoText MountPop11 Configuration.DoText MountDevlp .. Configuration.DoText MountTechn Configuration.DoText MountLegal --- Where MountTech is:---- ! OFSTools.Mount Techn AosFS IDE1#18 ~ OFSTools.Mount Techn AosFS IDE0#25 ~ System.Directory Techn:* ! OFSTools.Unmount Techn -------- which immediately goes to level 2: the Dir.:- ........ Techn:DataSlicr.gif Techn:DigiModem Techn:DiskStores Techn:FAX.OCR ......... ----and at level 3, different sub-topics are easily managed in a single file with n-o's fast Edit.Search and paste. The Index is on top. eg. Techn:DigiModem starts like this:- 2. simulating an analog modem on the digital link. 3. audio synthesis, analysis and coding 4. Algorithmen der Mustererkennung und ihre Realisierung 5. articulatory synthesizer of nasal vowels 6. Voice over IP in networked virtualenvironments ... ... ------------ Find.Panel is often used. And colour coding helps. I mention this personal arrangement which works well for me, because I have not found a good 'development enviroment' and hope other(s) can tell me their successful arrangement. Here I'm refering to the: edit, compile, test-run cycle; which seems inferior to the old Turbo-Pascal IntgDevEnvr. Even my small source codes rapidly become unmanagable. * what line width do ETH developers use for source code ? * screen layout: User + System track or not ? * fancy aids like 'source code folding' ? > Incidentally, try using the google search on the home gae and search for > "disk image" or "copy partition". > OK. > Which facility exactly is not documented? > A small hint can help a lot. Well it's months since I looked at this (and got no replies from this mail list for several queries ! That everybody now just appears is perhaps the weather and/or academic cycle ? ) Perhaps I'm mistaken about "not documented", I'll investigate, but try this (from yesterday's memory): I want to find the 3rd-last *.Obj that I created (I don't want/need to remember names). Recently it was revealed that System.Directory has flags (which I tested/confirmed) to show the date as the first column of the dir listing (it still needs to be refined to be ORDERED by date). To find which flag (without touching the key board), I should be able to: *.Tool / System.Directory ^ / System.Tool It fails; as does: System.Directory ^ / Watson.ShowDef ^ That this can't be fixed is due to 'inconsistent syntax', which I'll address in another post. Back to Partitions.Mod (since apparently the mail-list now has answerers): I was forced to investigate IDEs: partitioning, MBRs etc; when I ended up with 6 IDE's all unable to boot PC-DOS. Substantial investigation with the standard Microsoft & linux tools showed that n-o alpha 2001 was much more capable and convenient. Even 'special tools' downloaded from Seagate and WestnDig. could not do what n-o did immediately. Next to ppp, I believe that IDE problems (losing MBR, partition & booting problem) are the biggest problems for users (based on Usenet queries). I think single a 1M4 diskettes with standalone utilitie(s), would well demonstrate the power of n-o, to potential users. Single diskette mulinux is usefull for investigating the hardware eg. IDE(s), but single diskett n-o for diagnosing IDEs could be a killer (got to have) application. -- Chris Glur.

1 0

Re (3): [Oberon] Homework on ZipTool
by peter_easthope＠gulfnet.sd64.bc.ca 04 Sep '02

04 Sep '02

Pat, Pieter & others, p> ... perused the source code. ... I'm not an expert. Most of us are in the same boat. Thanks for the help. p> 1) ZipTool.(Directory | Extract | ExtractAll) do not require a .Zip extension. Good. How is this shown properly in the Zip.Tool? *.Tool texts are a quasi-EBNF which I don't understand well. Here is a speculation. ZipTool.Directory [\d | \D] <Zipfile>.Zip ~ ZipTool.Directory [\d | \D] <Zipfile> ~ .Zip suffix optional. ZipTool.Directory [\d | \D] ^ p> 2) ... DefaultStrategy* = 0; (** for normal data **) Is the default, string matching only and no Huffman coding? p> 3) I don't understand the question. AddFile is for programs and Add is for users. Why shouldn't they both be exported? Agreed. I plead absent mindedness. p> 4) non-consistent file name should give error and continue I take by this you may have consistent and non-consistent entries in the same zipfile and you would like to extract the consistent ones. Correct? Yes. p> Any reason you couldn't use "=>" to give it a consistent file name? OK for Extract. How should ExtractAll operate when the archive contains many files and only a few have exceptional names? At least it should extract all the files with conventional names and report the non -conventional names. The user could then rename or extract to an appropriate filesystem. More ambitiously, ExtractAll might accept the renaming arguments but this would incur significant checking in the case of an archive containing many files with only a few being renamed. Probably not justified. Regards Peter Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Partitions -> Killer-ap
by cglur＠onwe.co.za 04 Sep '02

04 Sep '02

> Since backingUp partitons is currently very tedious, I wondered if > one could backUp between IDE0/1 by having the same size > for corresponding partitions, and copying blocks n to last, where > n is the first few that have the 'partition linking info' ? > I.e copy the contents and don't mess with the 'house-keeping'. > Is this viable (for say 16 to 64 Mb sizes) ? > > PS. as I remember Partitions.Mod also has much undocumented > facilities ? Andr wrote: > Do you mean "disk image"? > Look for it in http://www.oberon.ethz.ch/betadocu.html > > If I don't err, that's what you looking for. > It is a viable approach. > OK, that would do. Although rather than the 'backup' (parachute) view, I prefer to view the project(s) cycling through a sequence of partitions -- in this case, just 2. So one could use the existing commands to: SrcPartn -> TempPartn -> DestPartn where sizeSrcPartn = sizeDestPartn =< sizeTempPartn But It is essential that bad blocks are detected. Important is that it can be done with a few clux (n-o cording) in a Tool or a script. Prof Gutknecht mentioned some years back that the dir-heirarchy was too liable for 'getting lost in'. I understood that he had some magic alternative; but since it has not yet been revealed, I've found the 3 level 'tree' concept works well for me, with n-o partitions. I use the 3 level heirachy: partition / file / section In <Personqal.Tool> I've got (colour coded mnemonically): Configuration.DoText MountSocEcon Configuration.DoText MountPop11 Configuration.DoText MountDevlp .. Configuration.DoText MountTechn Configuration.DoText MountLegal --- Where MountTech is:---- ! OFSTools.Mount Techn AosFS IDE1#18 ~ OFSTools.Mount Techn AosFS IDE0#25 ~ System.Directory Techn:* ! OFSTools.Unmount Techn -------- which immediately goes to level 2: the Dir.:- ........ Techn:DataSlicr.gif Techn:DigiModem Techn:DiskStores Techn:FAX.OCR ......... ----and at level 3, different sub-topics are easily managed in a single file with n-o's fast Edit.Search and paste. The Index is on top. eg. Techn:DigiModem starts like this:- 2. simulating an analog modem on the digital link. 3. audio synthesis, analysis and coding 4. Algorithmen der Mustererkennung und ihre Realisierung 5. articulatory synthesizer of nasal vowels 6. Voice over IP in networked virtualenvironments ... ... ------------ Find.Panel is often used. And colour coding helps. I mention this personal arrangement which works well for me, because I have not found a good 'development enviroment' and hope other(s) can tell me their successful arrangement. Here I'm refering to the: edit, compile, test-run cycle; which seems inferior to the old Turbo-Pascal IntgDevEnvr. Even my small source codes rapidly become unmanagable. * what line width do ETH developers use for source code ? * screen layout: User + System track or not ? * fancy aids like 'source code folding' ? > Incidentally, try using the google search on the home gae and search for > "disk image" or "copy partition". > OK. > Which facility exactly is not documented? > A small hint can help a lot. Well it's months since I looked at this (and got no replies from this mail list for several queries ! That everybody now just appears is perhaps the weather and/or academic cycle ? ) Perhaps I'm mistaken about "not documented", I'll investigate, but try this (from yesterday's memory): I want to find the 3rd-last *.Obj that I created (I don't want/need to remember names). Recently it was revealed that System.Directory has flags (which I tested/confirmed) to show the date as the first column of the dir listing (it still needs to be refined to be ORDERED by date). To find which flag (without touching the key board), I should be able to: *.Tool / System.Directory ^ / System.Tool It fails; as does: System.Directory ^ / Watson.ShowDef ^ That this can't be fixed is due to 'inconsistent syntax', which I'll address in another post. Back to Partitions.Mod (since apparently the mail-list now has answerers): I was forced to investigate IDEs: partitioning, MBRs etc; when I ended up with 6 IDE's all unable to boot PC-DOS. Substantial investigation with the standard Microsoft & linux tools showed that n-o alpha 2001 was much more capable and convenient. Even 'special tools' downloaded from Seagate and WestnDig. could not do what n-o did immediately. Next to ppp, I believe that IDE problems (losing MBR, partition & booting problem) are the biggest problems for users (based on Usenet queries). I think single a 1M4 diskettes with standalone utilitie(s), would well demonstrate the power of n-o, to potential users. Single diskette mulinux is usefull for investigating the hardware eg. IDE(s), but single diskett n-o for diagnosing IDEs could be a killer (got to have) application. -- Chris Glur.

1 0

Re: [Oberon] Homework on ZipTool
by Michael Karas 04 Sep '02

04 Sep '02

Hi has everyone seen, that there is also a ZipTool.Open Command. You can view the contents of a file without extracting. This was a function I prefered in the Compress-Package. Since it was not implemented in the Zip I send Stefan Walther the new function and it was released in a native-alpha-version 1 year ago. Unfortunately I forgot to change the Zip.Tool (ZipDocs is changed). Can Pieter / Stefan change that? Why is the Command 'Open'? Perhaps 'View' (as WinZip) would be better but then it is not consistent with the Compress.Tool Mike Karas > Ok, I perused the source code. This is the first time I've looked > at the > compression routines so I'm not an expert. :-) (not even close). > 1) ZipTool.(Directory | Extract | ExtractAll) do not require a > .Zip extension. > Pat

1 0

Re (2): [Oberon] DISPOSE
by muller＠inf.ethz.ch 03 Sep '02

03 Sep '02

Gérard_Meunier <gmeunier(a)club-internet.fr> wrote: > I don't understand all the outputs, The following command can be used to set traceHeap without booting. MODULE AosGCTest4; IMPORT AosHeap, In; PROCEDURE TraceHeap*; (* {n} ~ *) VAR n: LONGINT; BEGIN In.Open; In.LongInt(n); AosHeap.traceHeap := {}; WHILE In.Done DO IF (n >= 0) & (n <= 31) THEN INCL(AosHeap.traceHeap, n) END; In.LongInt(n) END END TraceHeap; END AosGCTest4. System.OpenKernelLog AosGCTest4.TraceHeap ~ AosGCTest4.TraceHeap 7 ~ AosGCTest4.TraceHeap 12 ~ The flags are: 0 1 NR NEW record 1 2 NA/NV NEW array 2 4 NS SYSTEM.NEW 3 8 DR deallocate record # 4 16 DA deallocate array # 5 32 DS deallocate sysblk # 6 64 NT NewType 7 128 8 256 FB show free blocks # 9 512 DP deallocate protrec # 10 1024 finalizers 11 2048 live/dead # # influences timing The timings are always reported, and are in us, if your MHz config string correctly defines the processor speed, e.g. MHz=180 for a 180MHz processor. Example output with AosGCTest4.TraceHeap 12 ~ : [P0@180MHz GC tot=30855 mod=4171 obj=21275 fin=18 swp=5391 clr=0 rts=1039 rch=8842 fre=348 fina=35 find=0 CG] {P0 Heap: 12460 total, 4556 free, 2583 largest, Mem: 48768 total, 608 low, 35400 high} tot is the total GC time (30855us = 30.8ms in this case). mod is the time for tracing the module list (all globals and their children). obj is the time for root objects fin is the time to check finalized objects swp is the sweep time clr is the debug (0DEADDEADH) clearing time (0 here because I disabled it) rts is the number of root objects rch is the number of reachable (live) objects fre is the number of freed objects (in the free lists) fina is the number of live finalized objects find is the number of dead finalized objects It would be interesting to see what output you get for AosGCTest4.TraceHeap 12 ~ and a typical GC on your application. BTW I have some ideas on how to improve the garbage collector, but it would be quite a big and intricate project. Implementing DISPOSE should be easier. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

2 1