Line end convention in MultiByteFileStream
Locked
Line end convention in MultiByteFileStream
 
|
Hi,
when creating a file, the line end convention of the OS is not enforced by default. As an example, FileStream forceNewFileNamed: 'test' do: [:stream | stream nextPut: $a; cr; nextPut: $b; cr] always creates a file with MacOS X line end convention. To enforce the line end convention of the system, one has to do the following: ... do: [:stream | stream wantsLineEndConvention: true; ... is it the desired behavior? If yes, should we ensure that #wantsLineEndConvention is called each time Pharo generates a file for the user (e.g., PharoDebug.log). -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Line end convention in MultiByteFileStream
|
|
About PharoDebug.log: http://code.google.com/p/pharo/issues/detail?id=1082
-- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Line end convention in MultiByteFileStream
|
|
Something else that I would very much like to see done to the debug log is to append new entries vs. overwriting them. A lot of useful information is destroyed that way. What do others think?
Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Damien Cassou Sent: Saturday, August 22, 2009 11:35 AM To: Pharo Development Subject: Re: [Pharo-project] Line end convention in MultiByteFileStream About PharoDebug.log: http://code.google.com/p/pharo/issues/detail?id=1082 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In another thread I asked to count one vote plus for this.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Line end convention in MultiByteFileStream
|
|
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
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Saturday, August 22, 2009 12:53 PM To: [hidden email] Subject: Re: [Pharo-project] Line end convention in MultiByteFileStream In another thread I asked to count one vote plus for this.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Line end convention in MultiByteFileStream
|
|
send code :)
Stef On Aug 22, 2009, at 9:20 PM, Schwab,Wilhelm K wrote: > 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 > > > > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of [hidden email] > Sent: Saturday, August 22, 2009 12:53 PM > To: [hidden email] > Subject: Re: [Pharo-project] Line end convention in > MultiByteFileStream > > In another thread I asked to count one vote plus for this. > > > Em 22/08/2009 13:56, Schwab,Wilhelm K < [hidden email] > > escreveu: > > > Something else that I would very much like to see done to the debug > log is to append new entries vs. overwriting them. A lot of useful > information is destroyed that way. What do others think? > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Damien Cassou > Sent: Saturday, August 22, 2009 11:35 AM > To: Pharo Development > Subject: Re: [Pharo-project] Line end convention in > MultiByteFileStream > > About PharoDebug.log: http://code.google.com/p/pharo/issues/detail?id=1082 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Line end convention in MultiByteFileStream
|
|
Fair enough.
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Saturday, August 22, 2009 3:53 PM To: [hidden email] Subject: Re: [Pharo-project] Line end convention in MultiByteFileStream send code :) Stef On Aug 22, 2009, at 9:20 PM, Schwab,Wilhelm K wrote: > 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 > > > > From: [hidden email] > [mailto:[hidden email] > ] On Behalf Of [hidden email] > Sent: Saturday, August 22, 2009 12:53 PM > To: [hidden email] > Subject: Re: [Pharo-project] Line end convention in > MultiByteFileStream > > In another thread I asked to count one vote plus for this. > > > Em 22/08/2009 13:56, Schwab,Wilhelm K < [hidden email] > > escreveu: > > > Something else that I would very much like to see done to the debug > log is to append new entries vs. overwriting them. A lot of useful > information is destroyed that way. What do others think? > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Damien Cassou > Sent: Saturday, August 22, 2009 11:35 AM > To: Pharo Development > Subject: Re: [Pharo-project] Line end convention in > MultiByteFileStream > > About PharoDebug.log: http://code.google.com/p/pharo/issues/detail?id=1082 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
Em 22/08/2009 16:20, Schwab,Wilhelm K <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Line end convention in MultiByteFileStream
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Saturday, August 22, 2009 7:51 PM To: [hidden email] Subject: Re: [Pharo-project] Line end convention in MultiByteFileStream Em 22/08/2009 16:20, Schwab,Wilhelm K <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |