Dan Parnete wrote:
I'm writing a simple database engine based on Library. Practically I'm collecting objects in lib and store libs in a database file. For now I have a running version with volatile indexes, witch is a nice experience with less the 5000 libs stored, but above that, building indexes on the fly is no more funny. Expecialy do to an anoing problem with Objects.LoadLibrary procedure.
I should like to do that:
PROCEDURE ReadLib*( f: Files.File, pos: LONGINT ): Objects.Library; VAR i, len: LONGINT; L: Objects.Library; BEGIN NEW( L ); Objects.OpenLibrary( L ); Objects.LoadLibrary( L, f, pos+1, len ); RETURN L END ReadLib;
But the result is:
TRAP 7 Index out of range in thread Oberon.Loop
Files.ReadString PC = 7278 R = 00411878H Files.Rider ch = 00000020X i = 64 x = " " ... Objects.LoadLibrary PC = 6475 @for = 8223 @for = 13 L = 014E0200H Objects.LibDesc N = 8224 R = 00411878H Files.Rider dict = 00000000H (Objects.ListDictDesc) dorg = 595 entry = 00000000H (Objects.EntryDesc) f = 01C1CA20H Files.File gorg = 512 i = 14 ind = 014AAF40H Objects.ArrayIndexDesc key = 8224 len = 597 n = 0 pos = 200017 version = 1380272450 DpsDb.ReadLib PC = 11734 <----- compare with source code L = 014E0200H Objects.LibDesc ch = 00000000X <---- this does not correspond with code above f = 01C1CA20H Files.File fl = 00000000H (Files.File) i = 0 len = 597 rl = 00411878H Files.Rider size = 597
!! This trap info does not come from the code above !!
And is nothing wrong with the data because doing that:
PROCEDURE ReadLib*( size: LONGINT; f: Files.File; r: Files.Rider ): Objects.Library; VAR i, len: LONGINT; ch: CHAR; fl: Files.File; rl: Files.Rider; L: Objects.Library; BEGIN fl := Files.New( "TempLib" ); Files.Set( rl, fl, 0 ); FOR i:=0 TO size-1 DO Files.Read( r, ch ); Files.Write( rl, ch ) END; Files.Register( fl ); fl := Files.Old( "TempLib" ); NEW( L ); Objects.OpenLibrary( L ); Objects.LoadLibrary( L, fl, 1, len ); RETURN L END ReadLib;
The trap info could be from this code. My 2001 ver. of Files.ReadString looks different. But I'm guessing that LEN(x) = 64 [0...63] and you had an overflow ? Just look at the source code of the last 3 [before it trapped] procs. Files.ReadString < Objects.LoadLibrary < DpsDb.ReadLib and compare the reported values of the varialbles to what you expect. This usually allows you to debug it. Perhaps put some trace info in proc DpsDb.ReadLib , to help see how the arg 'ripples-through' to trap in Files.ReadString ? -- Chris Glur.
eas-lab@absamail.co.za wrote:
Dan Parnete wrote:
I should like to do that:
PROCEDURE ReadLib*( f: Files.File, pos: LONGINT ): Objects.Library; VAR i, len: LONGINT; L: Objects.Library; BEGIN NEW( L ); Objects.OpenLibrary( L ); Objects.LoadLibrary( L, f, pos+1, len ); RETURN L END ReadLib;
But the result is:
TRAP 7 Index out of range in thread Oberon.Loop
Files.ReadString PC = 7278 R = 00411878H Files.Rider ch = 00000020X i = 64 x = " " ... Objects.LoadLibrary PC = 6475 @for = 8223 @for = 13 L = 014E0200H Objects.LibDesc N = 8224 R = 00411878H Files.Rider dict = 00000000H (Objects.ListDictDesc) dorg = 595 entry = 00000000H (Objects.EntryDesc) f = 01C1CA20H Files.File gorg = 512 i = 14 ind = 014AAF40H Objects.ArrayIndexDesc key = 8224 len = 597 n = 0 pos = 200017 version = 1380272450 DpsDb.ReadLib PC = 11734 <----- compare with source code L = 014E0200H Objects.LibDesc ch = 00000000X <---- this does not correspond with code above f = 01C1CA20H Files.File fl = 00000000H (Files.File) i = 0 len = 597 rl = 00411878H Files.Rider size = 597
!! This trap info does not come from the code above !!
Yes, ch was declared there but not used, and I deleted it when I write the email.
And is nothing wrong with the data because doing that:
PROCEDURE ReadLib*( size: LONGINT; f: Files.File; r: Files.Rider ): Objects.Library; VAR i, len: LONGINT; ch: CHAR; fl: Files.File; rl: Files.Rider; L: Objects.Library; BEGIN fl := Files.New( "TempLib" ); Files.Set( rl, fl, 0 ); FOR i:=0 TO size-1 DO Files.Read( r, ch ); Files.Write( rl, ch ) END; Files.Register( fl ); fl := Files.Old( "TempLib" ); NEW( L ); Objects.OpenLibrary( L ); Objects.LoadLibrary( L, fl, 1, len ); RETURN L END ReadLib;
The trap info could be from this code.
No, was not from this one.
My 2001 ver. of Files.ReadString looks different.
But I'm guessing that LEN(x) = 64 [0...63] and you had an overflow ?
Yes, but why? I'm not controlling the LoadLibrary. And the data is correct, if the second version works. I finally found the answer: you cannot LoadLibrary from a different position then was StoreLibrary. I was doing that: store Lib on a temporary file (pos=0), then insert the content of temp file in the database file (pos=200000 or more). When I tried to load Lib from the database, it ended in the Trap. Now, the db engine LoadLib from the temp file and then StoreLib on the db file, and everything work fine. Thank you for the suggestion, Dan Parnete
Hello all, After taking a break from trying to get WebDAV to work right under WinAOS I took another shot at it. I'm using the latest WebDAV build (WebDAV.1.0.0.Zip) and the latest version of WinAOS (Version 1.03, although for some reason it still says "1.02" in the log and in the Distribution.Text file. But I know I downloaded from the 1.03 link, and I did this twice just to make sure). Anyway on to the strange problem. Before I could do everything with WebDAV except download the file. I could create/delete folders, upload files ect. Now whenever I do the first step (deleting the old folders) Oberon locks up hard. I traced the lock up to a call to procedure WebHTTP.ParseReply(). PROCEDURE ParseReply*(VAR in: AosIO.Reader; VAR header: ResponseHeader; VAR res: LONGINT; log : TFLog.Log); VAR s: ARRAY 32 OF CHAR; af: AdditionalField; i :LONGINT; ch :CHAR; BEGIN GetToken(in, s); GetVersion(s, header.maj, header.min); GetToken(in, s); i := 0; GetInt(i, s, header.statuscode); in.Ln(header.reasonphrase); IF header.maj >= 1 THEN REPEAT GetToken(in, s); Utilities.TrimRight(s, ":"); IF s = "Server" THEN in.Char(ch); in.Ln(header.server) ELSIF s = "Date" THEN in.Char(ch);in.Ln(header.date) ELSIF s = "Content-Type" THEN in.Char(ch); in.Ln(header.contenttype) ELSIF s = "Content-Length" THEN in.Char(ch); in.Ln(s); Utilities.StrToInt(s, header.contentlength) ELSIF s = "Transfer-Encoding" THEN in.Char(ch); in.Ln(header.transferencoding) ELSE NEW(af); COPY(s, af.key); in.Char(ch); in.Ln(af.value); af.next := header.additionalFields; header.additionalFields := af END; UNTIL (in.res # AosIO.Ok) OR in.EOLN(); in.SkipLn(); res := OK ELSE IF log # NIL THEN log.Enter; log.String("Unsupported HTTP version :"); log.Int(header.maj, 5); log.Exit END; res := VersionNotSupported END; END ParseReply; Upon further inspection I traced the lock up to the line: UNTIL (in.res # AosIO.Ok) OR in.EOLN(); Specifically the call to in.EOLN(). So then I looked up in.EOLN(). It checks for the end of line by calls to in.Peek() to "look" at the next charecter in the input stream to see if it's an end-of-line charecter. So why should this be a problem? I have no idea. I did notice that the lines: IF s = "Server" THEN in.Char(ch); in.Ln(header.server) position the input stream past an end of line charecter. (The call to in.Ln(header.server) reads all of the charecter in the input stream up to and including the end of line charecters). But if there's nothing else past that, shouldn't that simply return an in.res = EOF or something rather than just hanging up? Another wierd problem. In the procedure DCT.CheckIn there is the following line: IF resHeader.statuscode # WebHTTP.MultiStatus THEN This does not compile under the latest WinAOS because WebHTTP.MultiStatus is not defined. I changed this to WebHTTP.OK just to get it to compile. This can't be the cause of my other problem though because I haven't gotten to DCT.CheckIn yet. I'm not sure what to do next. Regards, John M. Drake __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
participants (3)
-
Dan Parnete -
eas-lab＠absamail.co.za -
John Drake