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

Re: [Oberon] Reason for 'read pio error' ?
by cglur＠onwe.co.za 03 Sep '02

03 Sep '02

Andreas Drr <andreas.doerr(a)workingobjects.de> wrote: > > I have successfully installed Bluebottle on a Dell Inspiron 7500. > > Currently I use a 5GB partition for Bluebottle. While trying to format a > > second 5GB partition with AosFS I got an error '2820' at lba 12991229. > > Does anyone know what is a typical reason for such an error? > > Pieter wrote: > I'm not sure why the driver sees this ERR bit, and as you say, modern > disks should remap bad sectors automatically. I'm not sure if they > can do this without OS support. Perhaps the OS is required to retry > a failed transfer? But then a second Partitions.Format should work... > > > The only workaround I currently know is to define a small partition that > > includes the conspicuous block. This partition will not be used. Since the > > number of partitions is limited this is not a very good workaround :-( > > Unfortunately this is currently the only workaround, since the AosFS > file system does not handle bad blocks. What needs to be done is: > n-o formatting (as I remember) prompts "OK" (or not). I guess it's not actually checking for valid read/write ? So fast ? > 1. detect bad blocks in Partitions.Format > 2. create a file that contains all these bad blocks > > This will ensure that the bad blocks are ignored by the file system. > Part 2 is file system specific. > > If someone wants to attempt this, I suggest taking the relevant > Format code from Partitions.Mod and rewriting it in a new module. I did similar: Copied Partitions.Mod and modified to get: CG2Partitions.ShowBlocks IDE<No>#<PtNo> <1st> <NoOf> ~ to allow me to find/recover data from a n-o partition. 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 ? -- Chris Glur.

1 0

Re. [Oberon] Oberon FTP client
by cglur＠onwe.co.za 03 Sep '02

03 Sep '02

Patrick wrote: > Strangely, all Oberon clients (FTP.Mod, FTPDocs.Mod) available to me > (Windows Plugin Oberon 12/00 & 05/00, AosOberonSrc) work well if > I access an Aos FTP Server or a Unix FTP server, suggesting that they > correctly interpret RFCXXX. > However, they both fail when I try to access Microsoft FTP Server > (IIS 4.0, IIS 5.0). > Is this a known incompatibility, and how to get around it ? This is EXACTLY the impression I have from observations. Microsoft doesn't NEED to observe the RFCXXXs. And they offer ISPs "can't resist" arrangements. A specific example: 2 weeks back my ISP upgraded/merged and required users to change <username> to <username>@ibi.co.za for ppp connect. I.e. for ppp setup the username becomes <username>@ibi.co.za ?!? Like having a name: "John Post Box 46". Of course this is absurd, since "@" is a reserved token in this context, and our n-o alpha 2001 uses this fact to parse an input. Fortunately I'm able to 'drop back' to Ver 2.3.2 (199?) to connect to my ISP, now. Obviously the ISP tested their hack and it 'works' for the Microsoft masses. What annoys me most is that it is politically incorrect to criticise Microsoft in certain circles. -- Chris Glur.

1 0

Resizing partition for Bluebottle
by mcintosh＠vima.austin.tx.us 03 Sep '02

03 Sep '02

While installing Bluebottle on a machine with a windows 98 environment, I thought that I would resize the windows partition. I found the "ranish" partition resize software, and this worked as a first effort. I am now going to install Bluebottle on a production machine that has a Windows ME installation in a multi boot arrangement. For some reason, there are "unmovable" files in the ME partition out near the 8Gb limit, so I can't seem to shrink the partition smaller than this. I am about to launch "Partition Resizer" to move this partition back about 1 Gb, and put the Bluebottle partition at the front of the disk. If anyone has had trouble with "Partition Resizer", I would like to hear soon. I had also thought of using Bluebottle to copy the 7GB ME partition off to a file, then back to the newly moved partition. I haven't read the FAT-32 format, so I don't know if there are data that must be edited while doing this move. I thought that there would be some use for a Bluebottle equivalent of "xcopy" that would recursively copy all the files to another drive letter. This would surely be a limited use item, but things such as the ranish partition resizer and the partition resizer are in the same niche and seem to have their place in the world. Does anyone have such a tool in the Bluebottle environment? Did other people just do what I have envisioned above? -- Aubrey (Back on-line in Morris, Minnesota)

1 0

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

03 Sep '02

Patrick.Hunziker(a)unibas.ch wrote: > Here the FTP.Log of the working FTP client when a Unix server is used, > but the malfunction when a Windows NT/2000 Server is used. > Loggin in works, but FTP.Dir and FTP.GetFiles produce strange results, with FTP > entering the 'passive mode' instead of delivering a directory or transferring a > file. Passive mode is one of the two normal transfer methods. Perhaps there is some problem with the implementation (it was added later). I won't have time to look at this, so if anyone else wants to, feel free :-) BTW A good FTP client for Bluebottle would be a nice project for someone. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re (2): [Oberon] Homework on ZipTool (was Re: ZipTool1.Arc (Aug 5) can't handle DOS files ?)
by pat＠picoworks.com 03 Sep '02

03 Sep '02

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. 2) define \level and \strategy compression level 0 - none, 1 - best speed, 9 best compression, default maps to 6. strategy (from Zlib.Mod) (** compression strategies; the strategy only affects the compression ratio but not the correctness of the compressed output even if it is not set appropriately **) DefaultStrategy* = 0; (** for normal data **) Filtered* = 1; (** for data produced by a filter (or predictor); filtered data consists mostly of small values with a somewhat random distribution. In this case, the compression algorithm is tuned to compress them better. The effect of Filtered is to force more Huffman coding and less string matching; it is somewhat intermediate between DefaultStrategy and HuffmanOnly. **) HuffmanOnly* = 2; (** to force Huffman encoding only (no string match) **) 3) I don't understand the question. AddFile is for programs and Add is for users. Why shouldn't they both be exported? 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? Any reason you couldn't use "=>" to give it a consistent file name? 5) Add should follow Directory - Ok, This seem logical. Pat

1 0

loading of dll procedures - unknown EIP
by Patrick.Hunziker＠unibas.ch 03 Sep '02

03 Sep '02

Patrick.Hunziker(a)unibas.ch wrote: I am calling a windows dll ( ODBC32.dll ) from a Module ODBC (originally derived from V4). Loading the dll and its procedures appears to work, and the procedure variable address of some dll procedure is, according to "System.State ODBC": ... SQLDrivers = Unknown EIP = 1F819C05H ... What is the 'unknown EIP' when an address is found anyway ? It appears that the system has found ap procedure at the mentioned address. However, when I actually call ODBC.SQLDrivers, I get the error: ------------------ TRAP access violation in thread Oberon.Loop Unknown EIP = 77F821E1H EBP = 02EFF280H SQLBase.EnumDrivers PC = 3804 attribActLen = 0 attributes = "" cb = TestSQL.Enum PC = 254 cont = TRUE direction = 2 driver = "" driverActLen = 0 ret = 0 TestSQL.Do PC = 403 Interestingly, the unknown EIP and the procedure address, when added, give always 80000000H . Where does this mean, and how could this be remedied ? BTW: did anybody succeed in working with ODBC with ETH Oberon, and what are the hints to succeed ? Any most simple example code ? ----------------------- Pieter wrote: Unknown EIP means the EIP address could not be associated with any Oberon module and procedure. Normally the display would be something like: SQLDrivers = Module.Procedure PC = 1234 Is this a procedure variable pointing to an external C procedure or to an Oberon procedure? -- Pieter ----------------------- This is after a) loading an external dll (successful) written in an unknown language, probably C b) assigning dll exported procedures to procedures variable defined according to the structure of the exported variable. the assignement of procedure variables seems to work, otherwise the procedure variable is usually =NIL. The fact that calling the procedure variable fails with an EIP in the trap that is different from the EIP loaded (but complementary to 80000000H ) seems strange. ------------------------------------------------- This mail sent through IMP: igor.urz.unibas.ch

1 0

Oberon FTP.Client (2)
by Patrick.Hunziker＠unibas.ch 03 Sep '02

03 Sep '02

(*problems with the newest native sources from FTP.Mod; the same problems are encounterd with the FTPDocs.Mod sources.*) Here the FTP.Log of the working FTP client when a Unix server is used, but the malfunction when a Windows NT/2000 Server is used. Loggin in works, but FTP.Dir and FTP.GetFiles produce strange results, with FTP entering the 'passive mode' instead of delivering a directory or transferring a file. Greetings Patrick ------------------------- (*FTP.Open ftp.inf.ethz.ch user@host*) 220 ProFTPD 1.2.5 Server (ProFTPD for ftp.inf.ethz.ch) [dump] 331 Anonymous login ok, send your complete email address as your password. 230-+-------------------------------------------------------------------------+ | ETH-Zurich, Departement of Informatik | (* here follows also the usual welcome text*) 230 Anonymous access granted, restrictions apply. 200 Type set to I. 215 UNIX Type: L8 (*FTP.Dir: here, a file list is correctly shown in the System.Log*) (*FTP.Close*) 221 Goodbye.(*Now with an internal Microsoft FTP Server: FTP.Open mips:pwd@10.249.6.60*) 220 miptdm Microsoft FTP Service (Version 3.0). 331 Password required for mips. 230 User mips logged in. 200 Type set to I. 215 Windows_NT version 4.0 (* FTP.Dir: here, things begin to fail*) 227 Entering Passive Mode (10,249,6,60,4,102). 125 Data connection already open; Transfer starting. (*Here, other FTP clients show a list of files available, Oberon FTP client does not*) (*FTP.Dir again*) 226 Transfer complete. (*FTP.Dir again*) 227 Entering Passive Mode (10,249,6,60,4,103). (*FTP.Dir again*) 227 Entering Passive Mode (10,249,6,60,4,104). (*FTP.Dir again*) 227 Entering Passive Mode (10,249,6,60,4,105). (*FTP.Close*) 227 Entering Passive Mode (10,249,6,60,4,106). (*New try on the Windows FTP Server*) 220 miptdm Microsoft FTP Service (Version 3.0). 331 Password required for mips. 230 User mips logged in. 200 Type set to I. 215 Windows_NT version 4.0 (*FTP.CurDir*) 257 "/" is current directory. (*FTP.GetFiles TestFile.dat => Test.dat~*) 227 Entering Passive Mode (10,249,6,60,4,114). 550 TestFile.dat: Das System kann die angegebene Datei nicht finden. (*FTP.Close*) 221 ------------------------------------------------- This mail sent through IMP: igor.urz.unibas.ch

1 0

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

02 Sep '02

Gérard_Meunier <gmeunier(a)club-internet.fr> wrote: > Garbage collection is a blessing for most programmers, and makes system and > applications more robust. But sometimes it's a bane. I've written, in > Bluebottle, an interpreter for a language whose one of most important > features is that it produces no garbage. It allocates a lot of stuff in the > heap, but it knows exactly the lifetime of each chunk of memory. Therefore > it would be very interesting and efficient to dispose memory by hand. Is > there any way to do that? Not currently, but it would not be too difficult to add a Dispose procedure in AosHeap if someone would like to try. Basically the block to be disposed has to be added to the correct free list (global variable "freeList"). I'm not sure if this should be done, since disposing manually is error-prone and dangling pointers are horrible to debug. Do you currently have an efficiency problem with the garbage collector? By setting the "TraceHeap" config string you can see trace info about heap procedures in the kernel log, including the times of various phases of the collection. See the end of AosHeap.Mod for flag values for "TraceHeap". For accurate timings, set the config string "MHz" to the speed of your processor (e.g. "MHz=400"). The current collector still includes some debug code by default, viz. clearing all deallocated storage to the constant "0DEADDEADH". This can be quite an overhead. To disable, set DebugValue = 0 in AosHeap, recompile, relink the kernel and reinstall it on the boot device (see Aos.Tool). -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

2 1

Re: [Oberon] Homework on ZipTool (was Re: ZipTool1.Arc (Aug 5) can't handle DOS files ?)
by muller＠inf.ethz.ch 02 Sep '02

02 Sep '02

peter_easthope(a)gulfnet.sd64.bc.ca wrote: > OPEN ISSUES > 1. Does the module always insist on the suffix "Zip" for archive > names? I understand the rationale in creating an archive. > What about for Directory and Extract? The syntax in > the ZipTool could be a little more clear about the suffixes. > 2. What exactly is meant by "level" and "strategy" in > compression? This should be clarified in the ZipTool. > 3. Given the syntax and capabilities of Add and Extract, > is export of AddFile and ExtractFile justified? > 4. An attempt to extract an entry with a name not consistent > with the naming rules of the filesystem should produce an > error message and then continue. > 5. Logically, Add should follow Directory but in the module > Add follows ExtractAll. Anyone care to look at the source and answer these questions? -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re (5): [Oberon] Bug report: Character insert speed in Edit under 8.24 alpha NO
by muller＠inf.ethz.ch 02 Sep '02

02 Sep '02

pat(a)picoworks.com wrote: > You are correct, it looks to be a problem with memory transfer > speeds with the implementation of VESA on the display controller I'm using. Does the K6 support write-combine caching? The Bluebottle linear display driver (AosDisplayLinear.Mod) enables write-combine caching on processors that support it (using the MTTR registers). It improves performance significantly. > On the other had TextDocs spends far less time in Display but is far more consistent > with adding characters in the middle of the texts due to it's different architecture. Did you find which display primitive is so slow (is it CopyBlock, or CopyPattern, or ReplConst). Does Edit (TextFrames) call this very often, and why? > characters, total, time in Displays, Get, Set (the last two get and set are > SYSTEM.MOVE instructions in the procedure Displays.Transfer This seems to indicate CopyBlock. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0