That is an interesting idea. I am not opposed to it, but it would not be my first choice because the additional traces require decompression to view them, and because a potentially memory starved system has to compress them to write them to disk. That said, it it makes people happy enough to adopt the change when concatenation would be refused[*], then I'm all for it.
[*] I think I "heard" Stef say "send the code and it's in the core." So, I think the simpler "just keep adding to the file" option will be adopted. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Saturday, August 22, 2009 7:51 PM To: [email protected] Subject: Re: [Pharo-project] Line end convention in MultiByteFileStream Em 22/08/2009 16:20, Schwab,Wilhelm K <[email protected]> escreveu: > > I saw that, but one wonders whether we might be alone and should just > stop whining :) I cannot understand how ignoring errors is a feature, > but maybe it is to some??? One argument against the idea is that the > file could grow very large over time, but it should not be too bad, > and I would certainly want to know if my image is generating huge > numbers of unhandled execeptions. That is all the more true on > servers and embedded systems. > A possible compromise is something I did a while back and need to > press back into service: a rotating (for lack of a better name) file > stream. It uses one stream for a set period of time, then opens a new > file and begins writing to it. It leaves a seriies of files named for > when they were opened. I did it to avoid having something get hung up > (the concern was mostly defective USB drivers) and taking out all of > our data from an experiment vs. just costing us the last ten minutes > worth. Something even simpler could probably work here. Bill, Perhaps we can address both with a 'technology' used in a lot of Linux distributions: instead of opening a lot of newer files, the (let' call it such way) current file is a regular text file (maybe following the host OS line end conventions [it is a minor concern for me as I intend to develop and test in a dual boot machine]) and the accumulated history is compressed with some of the available methods in the devel image, so we have to take care of only two files, 'normal' (thinking of present) behaviour is almost not changed and the aditional benefits for the situations you mention in addition to be able to see earlier backtraces for all developers. -- Cesar Rabak _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
