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

Re: [Oberon] System Freeze on module unloading
by Felix Friedrich 21 Aug '02

21 Aug '02

Hi Frank, >I believe the best way to solve the problem is to have a termination handler >for each module. It is no problem to implement a termination Handler, there is a mechanism in Oberon for that, but: A module does not trace the opened objects. It is THE advantage of automatic garbage collection, that one does not have to dealloc (and therefore trace) objects. (Maybe the system could check allocated memory ? On the other hand: I want to be the boss of my computer: I say System.Free and I want the system to execute System.Free unless there are very specific reasons not to do, like depending modules. I do not accept depending objects as a reason since there seems to be no way to check if displayed objects depend on any of the freed objects. ) Felix.

1 1

System Freeze on module unloading
by Frank van Riet 21 Aug '02

21 Aug '02

I believe the best way to solve the problem is to have a termination handler for each module. Which should be called by the system whenever a module is unloaded. This handler can then free the required memory and patch up any dangling references. If memory serves there is already such a mechanism in place - don't ask me for the details though I haven't had a look at the code in ages and besides I still use 2.3.6... Anyway if it is no longer there such a mechanism is easy to implement. The problem is of course that this is such a schlep to implement in each module after the fact. It is of course trivial to implement if incorporated during module development. Frank --------------------------------------- Frank van Riet (Software Developer) Datavoice (Pty) Ltd Snail mail PO Box 582 Stellenbosch 7599 South Africa Tel +27 21 888-2118 Mobile +27 82 970 5704 Web http://www.datavoice.co.za ---------------------------------------- > -----Original Message----- > From: oberon-request(a)inf.ethz.ch [mailto:oberon-request@inf.ethz.ch] > Sent: 21 August 2002 12:00 > To: oberon(a)inf.ethz.ch > Subject: Oberon digest, Vol 1 #51 - 3 msgs > > > Send Oberon mailing list submissions to > oberon(a)inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)inf.ethz.ch > > You can reach the person managing the list at > oberon-admin(a)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: Project Oberon Source Code (Pat Hacker) > 2. Re: ETH Oberon/Gadgets: System Freeze in unloading > (Patrick, Dr. med. Hunziker) > 3. Re: ETH Oberon/Gadgets: System Freeze in unloading > (Felix Friedrich) > > --__--__-- > > Message: 1 > From: "Pat Hacker" <pat(a)picoworks.com> > To: <oberon(a)inf.ethz.ch> > Subject: Re: [Oberon] Project Oberon Source Code > Date: Tue, 20 Aug 2002 07:04:28 -0700 > Reply-To: oberon(a)inf.ethz.ch > > Felix, > Thanks for the pointers. As you mention there seems to be > minor differences > in the core modules between the source in the Project Oberon > book and V4 so > I'm using V4 source for now. > Pat > > > > --__--__-- > > Message: 2 > Date: Tue, 20 Aug 2002 13:40:07 +0200 > From: "Patrick, Dr. med. Hunziker" <PHunziker(a)uhbs.ch> > To: <oberon(a)inf.ethz.ch> > Subject: Re: [Oberon] ETH Oberon/Gadgets: System Freeze in unloading > Reply-To: oberon(a)inf.ethz.ch > > >>Gadgets.Insert BasicGadgets.NewButton > >>to Insert a button somewhere. > >>Then I execute > >>System.Free BasicGadgets~ > >> makes the system freeze... > > >Felix wrote: > >Don't be so cruel to the poor Button. You have stolen its > Handler. ;-) > >Seriously: The Problem is: When freeing a Module, Oberon > checks if there > >are still other Modules depending on that module but it > cannot check if > >Objects are still using any Allocated Memory in that Module. In that > >special case the allocated Memory was the Handler and moreover any > >type-checks and type-casts could't work since the Module did > not exist any > >more (after successful freeing it) etc. > > >So the "solution" is: Do not System.Free a Module when its > Objects are > >still displayed, since they are not deallocated and the > Handler is called > >any time a Display.Broadcast (or update message) is sent > (which is the case > >when new Viewers like a Trap-View are opened.) > > >Felix. > > Thanks for the info. > I see the problem. > However, in several years of working with Oberon, I have only > found three ways to produce C-like system freezes > apart from using the unsafe SYSTEM feature: > A) calling C programs from within Oberon > B) passing very large arrays as value parameters in procedure headings > C) unloading modules whereby some visual gadget is still > hanging around somewhere, as mentioned above. > I feel system stability is a prominent one of the many > highlights of Oberon, so the points B and C hurt the more... > Greetings > Patrick > > > --__--__-- > > Message: 3 > Date: Wed, 21 Aug 2002 10:58:44 +0200 > To: oberon(a)inf.ethz.ch > From: Felix Friedrich <friedrich(a)gsf.de> > Subject: Re: [Oberon] ETH Oberon/Gadgets: System Freeze in unloading > Reply-To: oberon(a)inf.ethz.ch > > Hi Patrick > > >However, in several years of working with Oberon, I have > only found three > >ways to produce C-like system freezes > >apart from using the unsafe SYSTEM feature: > >A) calling C programs from within Oberon > >B) passing very large arrays as value parameters in > procedure headings > >C) unloading modules whereby some visual gadget is still > hanging around > >somewhere, as mentioned above. > >I feel system stability is a prominent one of the many highlights of > >Oberon, so the points B and C hurt the more... > > I agree. By the way problem B) occurs because the max stacksize of an > Oberon.Thread (in Windows) is approx. like 100kB. I have > increased that > value to 1MB in my threads, but anyway, the best "solution" > is to take > VAR-pars or Pointers. As far as I know, in Windows-Oberon it is a > Windows-Problem, since the Windows-thread crashes when the > size of the > stack is too small. Maybe there should be some built in > range-check for the > stack in Oberon. (possible?) > Do you see a solution for C) ? > > Felix. > -- > > Felix Friedrich > > Institut für Biomathematik und Biometrie > GSF - Forschungszentrum für Umwelt und Gesundheit, GmbH > Ingolstädter Landstraße 1, D-85764 Neuherberg > > Tel: ++49 89 3187 2436 > email: friedrich(a)gsf.de > > -- > > > > --__--__-- > > -- > Oberon(a)inf.ethz.ch mailing list for ETH Oberon and related systems > http://www.lists.inf.ethz.ch/mailman/listinfo/oberon > > > End of Oberon Digest >

1 0

ETH Oberon/Gadgets: System Freeze in unloading module
by Patrick.Hunziker＠unibas.ch 20 Aug '02

20 Aug '02

I have encountered a strange behaviour in the Oberon System with Gadgets: I execute: Gadgets.Insert BasicGadgets.NewButton to Insert a button somewhere. Then I execute System.Free BasicGadgets~ This will unrecoverably freeze the Oberon System (from some strange hints in the System.Track possibly by an infinite chain of traps). I observed this behaviour on "ETH PlugIn Oberon for WindowsTM / Win32 2.4 (15.12.2000)on Windows 2000 Version 5.0.2195 Service Pack 2" Can other confirm this using other versions ? Any ideas about possible causes ? ------------------------------------------------- This mail sent through IMP: igor.urz.unibas.ch

3 4

columnar formatting re: TAB
by Charles Angelich 20 Aug '02

20 Aug '02

Hello All - After searching through many ETH Oberon Native modules to correct the directory "\d" display for Oberon's one large directory of files I am now wondering if the TAB char is working properly within Oberon? If the TAB char is dependent upon the Scn.Fnt libraries it would seem that the whitespace being only one-half of a full char would have an adverse affect on the TAB char? For proper columnar alignment the TAB should be equal in size to a full char, possibly the letter "A" or "H" (uppercase)? I have not tracked this down as yet but I'm concerned that other modules and future modules will be coded for half sized TABs preventing the correction of this nonstandard character within Oberon. Any input on this would be helpful. 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

Oberon SSH
by Patrick, Dr. med. Hunziker 19 Aug '02

19 Aug '02

This works great - thanks, Guenter Feldmann ! How much development effort is needed for the SSH server side ? Is there an ongoing development in this regard ? Greetings Pat

2 1

programming within ETH Oberon now and 2020
by Charles Angelich 19 Aug '02

19 Aug '02

Hello All - This is about keeping Oberon viable into the near future as hardware improves our user display access to the system and the information maintained within that system. If the user interface becomes less than comfortable with many addons dependent on hard-coding the road back will be a trip no one will be willing to take. The lack of columnar alignment and possible problems with the use of the TAB character are basic requirements for a textually oriented OS. I see no options there. I would also expect some form of word-wrap when displaying text files and the addition of code to intercept the file attributes to increase or decrease the embedded font sizes based on the available space when using various display sizes. Reset of the Font.Default is only one-half the solution when going to a larger display size continues to use the files embeded font size to display existing source code in miniature sized characters on a larger display. It seems that Native/Beta 08.12.00 is hard coded in many places to assume Oberon10.Scn.Fnt sizes. As video displays increase in size this will become an increasing weakness of existing Oberon code. Font.Default should be user selectable and button sizes, menu bars, and user input textual interface should ALL calculate sizes based on the Font.Default maximum letter size. Hard coding saves time and helps keep Oberon binaries small and fast but it's a problem waiting to interfere with further developments in the near future. note: On my 1024x768 display I use a Font.Default of Oberon14.Scn.Fnt. I don't see Gadgets panels re-sizing for display size which means at some point THAT user interface will be putting icon sized user panels on larger display sized screens. If they do resize and I am mistaken I apologize for my assumptions. When programming, being able to see a colon ":" as different from a semi-colon ";" is necessary. The period "." must not be mistaken for a comma "," nor the letter "O" for the digit zero "0". Miniature font sizes are not going to promote error free coding. The "zero" should include a dot or a slash within the character to differentiate it from the "O" and the number one "1" should not be kerned all the way to the right having an adverse affect on the appearance of columnar alignment of digits within Oberon displays. If the whitespace (empty char) within the font libraries is, in fact, one-half the size of the letter "A" this should be corrected within the font libaries (all of them if need be). Comments? 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

W31 install of ETH Oberon 3
by Charles Angelich 19 Aug '02

19 Aug '02

Hello All - It appears that the W31 install of ETH Oberon 3 is no longer being developed but I am using this version for comparison to other installs here. I do not expect anyone here to be interested in updating the W31 version. After installing this variant of ETH Oberon I must admit it is much easier to use as a learning environment to make the transition less awkward. Being able to move from Oberon to W31 and back again is quite convenient. :-) I noticed that this 1997 version has Syntax#.Scn.Fnt and an Arial#.Scn.Fnt missing from the ETH N-O Beta install. I like the Syntax font myself, and the Arial bold is definitely bold as solid characters. I also notice that Font.Default is a user option within the INI file for W31 Oberon. All versions of Oberon should allow this as a user option IMO from within whatever version of a configuration file that variant of Oberon makes use of. If there are additional Scn.Fnt file that are not to be included within the install of ETH Oberon they _should_ be available separately as addons for those who would prefer a different font style IF the option to chose the Font.Default was made configurable within Natve Oberon (it should be). 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: Oberon digest, Vol 1 #49 - 2 msgs
by Charles Angelich 19 Aug '02

19 Aug '02

>Message: 2 >From: cglur(a)onwe.co.za >Date: Sun, 18 Aug 2002 22:40:14 +0200 >To: oberon(a)inf.ethz.ch >Cc: cglur(a)onwe.co.za >Subject: [Oberon] Re: Major feature undocumented & dir-info >Reply-To: oberon(a)inf.ethz.ch > > >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 ? I will try to remember to do this in my N-O Beta. I don't know exactly what the problem is right now. >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 ! I disagree. If there are errors, omissions, or oversight within the inner modules they must be "messed with" before moving on to cause futher dependenies on code that is not doing what it should be doing. >If someone can put it in a wrapper, that's good. The numbers of separate modules could be infinite but the code I refer to within ETH Oberon is a very basic function of the OS that needs to be corrected or other future code that depends on these functions will become an entanglement. At present ETH Oberon is the only OS I can think of that does not line up it's directory display within a proper columnar format. This should have been corrected at the time the code was originally added to Oberon. >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. I don't quite understand your need to combine lines. Could you include an example of when this is necessary for a search/replace to be effective? 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: RX (was Re: Major feature undocumented & dir-info)
by Peter Easthope 19 Aug '02

19 Aug '02

Chris, 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 ? OK; yes it works. At least the window and the drop down menue open. How can the menue be closed without closing the window? Not sure how beneficial it is. cg> Now, using TUI { Edit.Open } and marked {F1}. RX.SetSearch "(" (~"\") X0 RX.SetReplace X0 RX.ReplaceAll * seems to work. Thanks Chris. Works here also. Will have to look for an error in usage next time text is edited with RX. Regards, Peter E. Peter Lyall Easthope http://carnot.pathology.ubc.ca/peter.html

1 0

Re: [Oberon] ETH N-O Native/Beta directory display
by Charles Angelich 19 Aug '02

19 Aug '02

>Message: 1 >From: Stefan Salewski <Salewski(a)PHYSnet.Uni-Hamburg.de> >Organization: Uni Hamburg >To: oberon(a)inf.ethz.ch >Subject: Re: [Oberon] ETH N-O Native/Beta directory display >Date: Sun, 18 Aug 2002 14:31:03 +0200 >Reply-To: oberon(a)inf.ethz.ch > >On Sat, 17 Aug 2002 21:56:35 Charles Angelich wrote: > >> 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. >> >Hello Charles, > >nice to see that you have overcome your problems with >mouse-buttons, narrow displays and few documentation of >ETH-Oberon. Thanks. I have a short learning curve in combination with 4 installs of Oberon. I now have ETH Oberon 3 for W31, ETH Native/Beta (640x480 and 1024x768 displays on dif machines) and Oberon V4 for W31 executing on two machines. I can read the documentation on the 1024 without reformatting but as I said the font is really too small even for younger eyes IMO. I modified Oberon.Mod to autodetect display sizes and increased the Font.Default to Oberon14.Scn.Fnt for the 1024 and above display settings. ;-) >A few words to your changes of System.Directory \d: >If System.List() is only called by System.Directory(), then it >will cause no trouble if you change it to your desire. But >Texts.WriteInt*() is used by many other Procedures! So your >changes will have system wide consequences. If you need these >changes, it may be better to make a copy of this Procedure (with >a new name) and call this modified copy from within List(). I agree but it seems that the whitespace (empty char) within the Oberon#.Scn.Fnt is only one-half a full "box" for the char? Any routine attempting to pad with a whitespace would be "off" by one half the required spaces as the code is written. Either the fonts files need to be corrected or this doubling of whitechar is necessary. I haven't verified this using the fonteditor but I do intend to pursue this further to be certain my assumptions are correct on this. >I think your solution can not be perfect with proportional >(kerned) fonts: I guess not all digits will have the same width. I thought that too but it appears the digits do, in fact, all use the same `box' size (they are not kerned). The number "1" (one) is offset in it's box which causes what appears to be misalignment when it is the first digit used. This should be corrected within the font file IMO. >Please keep in mind: Modifications in the code of an operating >system can have bad consequences. With ETH-Oberon it is not too >diffical to do such modificions, but before we can integrate a >modification in the next version (distribution), we have to be >very carefully. I agree with your concerns which is why I put the code here in the list for others to review. If there are obvious conflicts or not so obvious I am open to suggestions or further refinements to isolate this from interference with other routines dependent on less-than-accurate whitespacing. Consider this as an observation being made by a person who has taken the time to RTFM for more than one version of Oberon and who has now installed 3 versions of Oberon: The existing display of the directory when using "\d" looks like a last-minute hack rather than a finished piece of code. It detracts from Oberon and does not add to it's appeal. Again this is not to be insulting, I have taken the time to find a way to correct this omission and am not just hammering ETH or it's people. I want to be helpful when I am able and this really really looks bad as it is now IMO. 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