Re: Continuing problems with OberonF "append"

Reinhard Bürger (burgwolf@t-online.de)
Wed, 27 Aug 1997 19:09:24 +0100

Les,

I have reproduced, that Views.Old(dontAsk,...) does not assign a view

to variable v. This seems to be false. Therefore I downloaded Version

1.3 beta1 and now it works correctly. Version 1.3 beta2 is due next

week,

and the final release by the end of September.

As nothing is to be viewed (no user interaction) in your application,

Views.Old is probably the worst way to append.

I cannot comment on your other questions now.

Irrespective of the exact process of appending physically to a disk

file,

I think it is worth while to find a way to keep log files small

(e.g. constant size ring buffer, new log file when size exceeds limit,

...).

I´ve had lots of trouble with that kind of 24-hour-applications

filling all disk space with log-scrap until the system is down.

Reinhard
Les Snively wrote:
>
> Gentlemen,
> Thank you all for your informative responses to my call for help
> appending data to the end of a file. I've tried the two different
> suggestions contained in the three responses. However, I continue to
> have problems making the append work, as well as have a more general
> question about I/O in OberonF. If you have a moment to help me again, I
> would appreciate it very much.
> Below is a small modification to the Module "ObxOpen1" as
> recommended to me by Mr. Burger. (I've changed the name to make
> modifications and add some test features.) In this case, I can't get it
> to work when I use the "dontAsk" version of the Views.Old or equivalent
> Views.OldView commands. It works fine on the same file if I use the
> "ask" variation. Curiously, I don't have the same problem with the
> Views.Register command. Note that "loc.res" comes back with a value of 0
> in both cases, but in the dontAsk version no View is assigned to the
> variable v. Since the final code will be used in an unattended, 24 hour
> a day application, I can't use the "ask" formulation. (By the way,
> "TestFile" is just a one line ASCII file for the purpose of checking to
> see if things "appended".
>
> MODULE WfsOpen1;
>
> IMPORT Converters, Files, Views, Dialog, TextModels, TextMappers,
> TextViews, Services, Out;
>
> PROCEDURE Do*;
> VAR loc: Files.Locator; name: Files.Name; conv: Converters.Converter;
> v: Views.View; t: TextModels.Model; f: TextMappers.Formatter;
> res, i, time : LONGINT;
> BEGIN
> loc :=Files.dir.This( "Logs:") ;
> Out.Int(loc.res, 0) ; Out.Ln ;
> name := "TestFile"; conv := NIL;
> v := Views.Old(Views.dontAsk, loc, name, conv);
> Out.Int(loc.res, 0) ; Out.Ln ;
> IF (v # NIL) & (v IS TextViews.View) THEN
> Out.Int(Services.Ticks(), 0) ; Out.String(" ") ;
> t := v(TextViews.View).ThisModel();
> f.ConnectTo(t);
> f.SetPos(t.Length());
> Out.Int(Services.Ticks(), 0) ; Out.String(" ") ;
> FOR i := 1 TO 5 DO
> f.WriteString("This is line: ") ; f.WriteInt(i) ; f.WriteLn ;
> Views.Register(v, Views.dontAsk, loc, name, conv, res) ;
> Out.Int(Services.Ticks(), 0) ; Out.Ln ;
> END ; (* for *)
> END
> END Do;
>
> END WfsOpen1.
>
> The other method is to use the "Files.dir.Old" command with no text
> formating. It turns out for other reasons that this is probably not the
> way I can use this in my application, but I tried the technique anyway.
> The following code snipet is what I used for the test. In this case I
> keep getting a returned loc.res of "4" after the execution of the line f
> := Files.dir.Old command. The documentation on Files does not show that
> as being one of the possible return values, so I don't know what it
> means. On the assumption that it means what it does for some of the
> other File commands, that it can't find the file, I wrote the little
> routine to GetFileList for that directory location to check that it sees
> the file. (This is commented out in the program list below. It finds
> the file without any problem.) Running the program with
> Files.dir.Old(....Shared=TRUE) opens the file fine, but of course doesn't
> actually allow the file data to change. I'm stumped. Any thoughts?
>
> PROCEDURE AppendFile* (aStr : ARRAY OF CHAR) ;
>
> VAR
> f : Files.File ; w : Files.Writer ;
> loc : Files.Locator ;
> infoList : ARRAY 16 OF Files.Info ;
> i : INTEGER ;
>
> BEGIN
> loc := Files.dir.This('From the net:') ;
> Out.Int(loc.res,0) ; Out.String(" ") ;
> (* Files.dir.GetFileList(loc, infoList) ;
> i := 0 ;
> WHILE infoList[i].name#"" DO
> Out.String(infoList[i].name) ; Out.String(" ") ;
> INC(i) ;
> END ; (* while *)
> Out.Ln ;
> *) f := Files.dir.Old(loc, "TestFile", FALSE) ;
> Out.Int(loc.res,0) ; Out.String(" ") ; Out.Int(Strings.Len(aStr),0) ;
> w := f.NewWriter(w) ; w.SetPos(f.Length()) ;
> w.WriteBytes(aStr, 0,Strings.Len(aStr)) ;
> Out.Int(w.Pos(),0) ; Out.Ln ;
> f.Close()
> END AppendFile ;
>
> Finally, a question. The TextModel version shown above as the first
> example, appears to actually write the whole file each time it is
> registered, not just append text to the end of the file. My tests show
> that disk write process takes longer as the file gets longer.
> Presumably, if it were just appending data at the end, the time would be
> relatively constant. Since I have a performance constraint in the
> transaction processing system I'm writing, is there any way to bypass
> this limitation without resorting to the simple WriteBytes command in
> Files? (And I don't know that WriteBytes truly "appends" data at the end
> rather than writing the whole file since I can't get it to operate.) It
> would seem that OberonF has a large performance penalty if it has to
> write the entirety of a log file each time I add data, perhaps such that
> I can't use the language. Have I missed something here, or is this a
> "known" limitation of the implementation?
>
> Again, thanks to you for taking a few minutes to think about and
> respond to this plea.
>
> Regards,
>
> Les Snively