November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About end of line convention

by StÃ©phane Ducasse

Thanks It makes sense to me. I like to have a good default and give the power to the programmer. Stef On Nov 20, 2009, at 7:39 PM, Nicolas Cellier wrote: > 2009/11/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> It was more on file streams or text when you edit a file. >> In particular this was in context of >> http://code.google.com/p/pharo/issues/detail?id=1458 >> >> Because before integrating it I wanted to know what it was about. >> >> Stef >> > > Hi Stephane, > > These changes just make it possible to handle various line delimiters > for splitting lines in a String. > > Discussion was lengthy in trunk about whether or not these various > line delimiters should have made their path inside the image. > Some would prefer to stick to simple st-80 cr-only handling in image > and carry ALL the conversions at read/write to the complex external > world. > The rationale is that complexity should not enter the image. > > My POV differs. > > 1) because handling cr-lf-crlf in image is not that complex (judge how > complex is the new code versus the old one) > 2) because it is not CPU intensive (The line splitting methods were > not optimized, thus I reduced the cost of splitting, and therefore, I > reject the argument that it does matter that much) > 3) because making the right decision about conversion can depend on > applications and can be complex, that's why it should ultimately be in > the hands of programmer. > > I see no contradiction in using detectLineEndConventions in Pharo tools. > Though the current algorithm fail to handle mixed-conventions files > correctly, that's a good default policy. > But this simple trick can NOT handle ALL the cases (the > mixed-conventions is an example). > > A universal line end converter fitting all possible use cases does not > exist and would be more than complex. > Let the grown up programmer decide what better fits his application > and provide decent tools to him (her). > > If you decide to reject these modifications, then please revert > http://code.google.com/p/pharo/issues/detail?id=1356 for consistency. > > cheers > > Nicolas > > >> On Nov 20, 2009, at 6:09 PM, Philippe Marschall wrote: >> >>> StÃ©phane Ducasse wrote: >>>> Hi nicolas >>>> >>>> I was dicussing today with juan vuletich about the management of end of line convention and I think that >>>> he is right. When we edit a file we should be in control about that we want to have. >>>> In CUIS when you edit a file you can decide the convention or change it. >>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform. >>>> My point of view on this is : >>>> - when I manipulate the text object may be we should have the platform convention. >>>> - when I edit a file I should get the control because I may want to edit a file on mac with unix convention. >>>> >>>> So nicolas I saw that you pushed a slice about fixing end of line. >>>> What is the design behind it? >>> >>> End of line convention in which context? The changes file? File outs? >>> File streams? >>> >>> Cheers >>> Philippe >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] CrLfStream bug.

by Nicolas Cellier

2009/11/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Thanks henrik and nicolas. > this is cool to have you around. > Software is so complex and life so short.... > Tsss... It does not have to be complex, what Smalltalk was made for? ;) Does it have to be short ? unfortunately I do not have the answer this time... Nicolas > Stef > > On Nov 20, 2009, at 8:50 PM, Nicolas Cellier wrote: > >> 2009/11/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> 2009/11/20 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>>> Speaking of end of line conventions, here's issue 1472 :) >>>> >>>> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized. >>>> detectLineEndConvention gets called before converter is installed, and later on, >>>> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil. >>>> >>>> Alternatives: >>>> >>>> 1. ensure lineEndConvention installation: >>>> >>>> MultiByteFileStream>>open: fileName forWrite: writeMode >>>> Â Â Â Â | result | >>>> Â Â Â Â result := super open: fileName forWrite: writeMode. >>>> Â Â Â Â result ifNotNil: [ >>>> Â Â Â Â Â Â Â Â Â Â Â Â converter ifNil: [converter := UTF8TextConverter new]. >>>> Â Â Â Â Â Â Â Â Â Â Â Â lineEndConvention ifNil: [ self detectLineEndConvention ] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [self installLineEndConventionInConverter] >>>> Â Â Â Â ]. >>>> Â Â Â Â ^result >>>> >>>> 2. Use converter: instead, since that installs the lineEndConvention: >>>> MultiByteFileStream>>open: fileName forWrite: writeMode >>>> Â Â Â Â | result | >>>> Â Â Â Â result := super open: fileName forWrite: writeMode. >>>> Â Â Â Â result ifNotNil: [ >>>> Â Â Â Â Â Â Â Â Â Â Â Â converter ifNil: [self converter: UTF8TextConverter new]. >>>> Â Â Â Â Â Â Â Â Â Â Â Â lineEndConvention ifNil: [ self detectLineEndConvention ] >>>> >>>> Â Â Â Â ]. >>>> Â Â Â Â ^result >>>> >>>> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P >>>> >>>> I'm Â submitting a slice with approach 2 to inbox. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>> >>> Oh, I see now why I missed this one. >>> trunk does not have Keith change: >>> Â Â Â Â Â Â Â Â Â Â Â Â lineEndConvention ifNil: [ self >>> detectLineEndConvention ] >>> but a direct call to: >>> Â Â Â Â Â Â Â Â Â Â Â Â self detectLineEndConvention >>> So trunk always set the line end convention in the converter and I >>> decided it was not necessary to use self converter: here... >>> Integrating Keith change has broken this fragile constuction, don't >>> know when it came in. >> >> http://code.google.com/p/pharo/issues/detail?id=1013 in 10400 >> http://bugs.squeak.org/view.php?id=6086 >> >> Now I know >> >>> I approve solution 2) >>> >>> Cheers >>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 20, 2009

Re: [Pharo-project] Application screenshots

by StÃ©phane Ducasse

Adrian you can put a link to www.ibizlog.com :) Stef On Nov 20, 2009, at 9:13 PM, Adrian Lienhard wrote: > I changed the image to the one you suggested below. > > Adrian > > On Nov 20, 2009, at 19:34 , Gary Chambers wrote: > >> Of course, the screenshot piccy is from our "Report Builder"... >> though that >> will be integrated into the "Enterprise" version for customisation >> of the >> relabels (Database/barcode integration etc.). More reuse coming for >> that! >> Thanks for the exposure though, perhaps change the pic to >> http://www.flickr.com/photos/12018791@N06/4120335614/in/set-721576016593932… >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Adrian Lienhard" <adi(a)netstyle.ch> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Friday, November 20, 2009 6:25 PM >> Subject: Re: [Pharo-project] Application screenshots >> >> >>> Great, thanks for sharing! >>> >>> I added an entry to the top of >>> http://www.pharo-project.org/about/success-stories >>> >>> If other companies like to get their Pharo project featured on the >>> success stories page, please send me information. >>> >>> Cheers, >>> Adrian >>> >>> >>> On Nov 20, 2009, at 18:57 , Gary Chambers wrote: >>> >>>> Here for now: >>>> http://www.flickr.com/photos/12018791@N06/sets/72157601659393251/ >>>> >>>> Some explanation... >>>> >>>> The application is designed to improve efficiency with relabelling >>>> of packages/groups-of-packages within the logistics industry. Often >>>> the pre-existing labelling is hard to read and/or covered with >>>> polywrap etc. >>>> >>>> MBagger provides a simple means of rescanning labels with >>>> algorithmic clean-up suitable for re-printing with commerically >>>> available thermal printers (1 bit per pixel) >>>> >>>> Sorry for "plug" bust some details here: >>>> http://www.pinesoft.co.uk/what/logisticsproducts >>>> >>>> Certainly an interesting project. Leveraging the lean approach of >>>> Pharo with the visual appeal of Polymorph. >>>> >>>> All designed to be fully usable with just a touchscreen and simple >>>> to use. Runs happlily on an Eeetop..., image processing initially >>>> implemented in Smalltalk, optimised in Smalltalk then transcoded >>>> into Slang for a plugin. Sharpen filter taken from Diego's image >>>> processing library. Custom hardware support for Datalogic scanners, >>>> based around an asynchronous device framework developed in house for >>>> other projects (who say we can't get large-scale reuse!). Webcam >>>> support is also available (VideoForLinux plugin) if required, all >>>> customisable via configuration files (XML-based). >>>> >>>> Here's to all the dedicated Pharo users for helping to make this >>>> possible. >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- >>>> From: Schwab,Wilhelm K >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Sent: Friday, November 20, 2009 5:13 PM >>>> Subject: Re: [Pharo-project] Application screenshots >>>> >>>> >>>> Great, thanks, good luck, can't wait, etc. >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>>> ] On Behalf Of Gary Chambers >>>> Sent: Friday, November 20, 2009 11:54 AM >>>> To: Pharo Development >>>> Subject: [Pharo-project] Application screenshots >>>> >>>> >>>> Some coming for our (Pinesoft) first "shrink wrapped" product >>>> solution. Pharo based, of course ;-) >>>> >>>> Give me an hour or so, will be on my Flickr pages since given the >>>> go-ahead. >>>> >>>> Regards, Gary >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project________… >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] About working with XML

by HernÃ¡n Morales Durand

Hi Jorge, There is a XPath parser in http://www.squeaksource.com/XPath.html though provides pretty basic support (no functions, operators yet). Cheers, HernÃ¡n 2009/11/18 Jorge Silva - 10Pines <jorge.silva(a)10pines.com>: > Hi guys! > I'm new to this group, so nice to meet you. > I'm starting to work with Pharo and my first issue is how to work with XML. > Can someone tell me about some package or "framework" to work with XML > (parse it and serialize objects to it). > Any help would be appreciated. > Cheers, > Jorge > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 20, 2009

Re: [Pharo-project] Application screenshots

by Gary Chambers

Ar, good choice (personally I quite like the translucency/overlay aspect). Regards, Gary ----- Original Message ----- From: "Adrian Lienhard" <adi(a)netstyle.ch> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, November 20, 2009 6:25 PM Subject: Re: [Pharo-project] Application screenshots > Great, thanks for sharing! > > I added an entry to the top of > http://www.pharo-project.org/about/success-stories > > If other companies like to get their Pharo project featured on the > success stories page, please send me information. > > Cheers, > Adrian > > > On Nov 20, 2009, at 18:57 , Gary Chambers wrote: > >> Here for now: >> http://www.flickr.com/photos/12018791@N06/sets/72157601659393251/ >> >> Some explanation... >> >> The application is designed to improve efficiency with relabelling >> of packages/groups-of-packages within the logistics industry. Often >> the pre-existing labelling is hard to read and/or covered with >> polywrap etc. >> >> MBagger provides a simple means of rescanning labels with >> algorithmic clean-up suitable for re-printing with commerically >> available thermal printers (1 bit per pixel) >> >> Sorry for "plug" bust some details here: >> http://www.pinesoft.co.uk/what/logisticsproducts >> >> Certainly an interesting project. Leveraging the lean approach of >> Pharo with the visual appeal of Polymorph. >> >> All designed to be fully usable with just a touchscreen and simple >> to use. Runs happlily on an Eeetop..., image processing initially >> implemented in Smalltalk, optimised in Smalltalk then transcoded >> into Slang for a plugin. Sharpen filter taken from Diego's image >> processing library. Custom hardware support for Datalogic scanners, >> based around an asynchronous device framework developed in house for >> other projects (who say we can't get large-scale reuse!). Webcam >> support is also available (VideoForLinux plugin) if required, all >> customisable via configuration files (XML-based). >> >> Here's to all the dedicated Pharo users for helping to make this >> possible. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: Schwab,Wilhelm K >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Friday, November 20, 2009 5:13 PM >> Subject: Re: [Pharo-project] Application screenshots >> >> >> Great, thanks, good luck, can't wait, etc. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Gary Chambers >> Sent: Friday, November 20, 2009 11:54 AM >> To: Pharo Development >> Subject: [Pharo-project] Application screenshots >> >> >> Some coming for our (Pinesoft) first "shrink wrapped" product >> solution. Pharo based, of course ;-) >> >> Give me an hour or so, will be on my Flickr pages since given the >> go-ahead. >> >> Regards, Gary >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project________… >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] CrLfStream bug.

by StÃ©phane Ducasse

Thanks henrik and nicolas. this is cool to have you around. Software is so complex and life so short.... Stef On Nov 20, 2009, at 8:50 PM, Nicolas Cellier wrote: > 2009/11/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2009/11/20 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> Speaking of end of line conventions, here's issue 1472 :) >>> >>> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized. >>> detectLineEndConvention gets called before converter is installed, and later on, >>> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil. >>> >>> Alternatives: >>> >>> 1. ensure lineEndConvention installation: >>> >>> MultiByteFileStream>>open: fileName forWrite: writeMode >>> | result | >>> result := super open: fileName forWrite: writeMode. >>> result ifNotNil: [ >>> converter ifNil: [converter := UTF8TextConverter new]. >>> lineEndConvention ifNil: [ self detectLineEndConvention ] >>> ifNotNil: [self installLineEndConventionInConverter] >>> ]. >>> ^result >>> >>> 2. Use converter: instead, since that installs the lineEndConvention: >>> MultiByteFileStream>>open: fileName forWrite: writeMode >>> | result | >>> result := super open: fileName forWrite: writeMode. >>> result ifNotNil: [ >>> converter ifNil: [self converter: UTF8TextConverter new]. >>> lineEndConvention ifNil: [ self detectLineEndConvention ] >>> >>> ]. >>> ^result >>> >>> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P >>> >>> I'm submitting a slice with approach 2 to inbox. >>> >>> Cheers, >>> Henry >>> >>> >> >> Oh, I see now why I missed this one. >> trunk does not have Keith change: >> lineEndConvention ifNil: [ self >> detectLineEndConvention ] >> but a direct call to: >> self detectLineEndConvention >> So trunk always set the line end convention in the converter and I >> decided it was not necessary to use self converter: here... >> Integrating Keith change has broken this fragile constuction, don't >> know when it came in. > > http://code.google.com/p/pharo/issues/detail?id=1013 in 10400 > http://bugs.squeak.org/view.php?id=6086 > > Now I know > >> I approve solution 2) >> >> Cheers >> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] [update 1.1] #11052

by StÃ©phane Ducasse

:) I could not check that it was working (not sure if there is not a proxy cache here). Stef On Nov 20, 2009, at 8:12 PM, Marcus Denker wrote: > > Not done by me, but not yet announced: > > 11052 > ----- > Issue 1424 CompiledMethodAnaloguous fixes > > -- > Marcus Denker -- marcus(a)2denker.de > http://www.2denker.de > > 2denker UG (haftungsbeschrÃ¤nkt) > Sitz KÃ¶ln > Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 > GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] Application screenshots

by Adrian Lienhard

I changed the image to the one you suggested below. Adrian On Nov 20, 2009, at 19:34 , Gary Chambers wrote: > Of course, the screenshot piccy is from our "Report Builder"... > though that > will be integrated into the "Enterprise" version for customisation > of the > relabels (Database/barcode integration etc.). More reuse coming for > that! > Thanks for the exposure though, perhaps change the pic to > http://www.flickr.com/photos/12018791@N06/4120335614/in/set-721576016593932… > > Regards, Gary > > ----- Original Message ----- > From: "Adrian Lienhard" <adi(a)netstyle.ch> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, November 20, 2009 6:25 PM > Subject: Re: [Pharo-project] Application screenshots > > >> Great, thanks for sharing! >> >> I added an entry to the top of >> http://www.pharo-project.org/about/success-stories >> >> If other companies like to get their Pharo project featured on the >> success stories page, please send me information. >> >> Cheers, >> Adrian >> >> >> On Nov 20, 2009, at 18:57 , Gary Chambers wrote: >> >>> Here for now: >>> http://www.flickr.com/photos/12018791@N06/sets/72157601659393251/ >>> >>> Some explanation... >>> >>> The application is designed to improve efficiency with relabelling >>> of packages/groups-of-packages within the logistics industry. Often >>> the pre-existing labelling is hard to read and/or covered with >>> polywrap etc. >>> >>> MBagger provides a simple means of rescanning labels with >>> algorithmic clean-up suitable for re-printing with commerically >>> available thermal printers (1 bit per pixel) >>> >>> Sorry for "plug" bust some details here: >>> http://www.pinesoft.co.uk/what/logisticsproducts >>> >>> Certainly an interesting project. Leveraging the lean approach of >>> Pharo with the visual appeal of Polymorph. >>> >>> All designed to be fully usable with just a touchscreen and simple >>> to use. Runs happlily on an Eeetop..., image processing initially >>> implemented in Smalltalk, optimised in Smalltalk then transcoded >>> into Slang for a plugin. Sharpen filter taken from Diego's image >>> processing library. Custom hardware support for Datalogic scanners, >>> based around an asynchronous device framework developed in house for >>> other projects (who say we can't get large-scale reuse!). Webcam >>> support is also available (VideoForLinux plugin) if required, all >>> customisable via configuration files (XML-based). >>> >>> Here's to all the dedicated Pharo users for helping to make this >>> possible. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: Schwab,Wilhelm K >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Sent: Friday, November 20, 2009 5:13 PM >>> Subject: Re: [Pharo-project] Application screenshots >>> >>> >>> Great, thanks, good luck, can't wait, etc. >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>> ] On Behalf Of Gary Chambers >>> Sent: Friday, November 20, 2009 11:54 AM >>> To: Pharo Development >>> Subject: [Pharo-project] Application screenshots >>> >>> >>> Some coming for our (Pinesoft) first "shrink wrapped" product >>> solution. Pharo based, of course ;-) >>> >>> Give me an hour or so, will be on my Flickr pages since given the >>> go-ahead. >>> >>> Regards, Gary >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project________… >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] CrLfStream bug.

by Nicolas Cellier

2009/11/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/11/20 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> Speaking of end of line conventions, here's issue 1472 :) >> >> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized. >> detectLineEndConvention gets called before converter is installed, and later on, >> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil. >> >> Alternatives: >> >> 1. ensure lineEndConvention installation: >> >> MultiByteFileStream>>open: fileName forWrite: writeMode >> Â Â Â Â | result | >> Â Â Â Â result := super open: fileName forWrite: writeMode. >> Â Â Â Â result ifNotNil: [ >> Â Â Â Â Â Â Â Â Â Â Â Â converter ifNil: [converter := UTF8TextConverter new]. >> Â Â Â Â Â Â Â Â Â Â Â Â lineEndConvention ifNil: [ self detectLineEndConvention ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [self installLineEndConventionInConverter] >> Â Â Â Â ]. >> Â Â Â Â ^result >> >> 2. Use converter: instead, since that installs the lineEndConvention: >> MultiByteFileStream>>open: fileName forWrite: writeMode >> Â Â Â Â | result | >> Â Â Â Â result := super open: fileName forWrite: writeMode. >> Â Â Â Â result ifNotNil: [ >> Â Â Â Â Â Â Â Â Â Â Â Â converter ifNil: [self converter: UTF8TextConverter new]. >> Â Â Â Â Â Â Â Â Â Â Â Â lineEndConvention ifNil: [ self detectLineEndConvention ] >> >> Â Â Â Â ]. >> Â Â Â Â ^result >> >> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P >> >> I'm Â submitting a slice with approach 2 to inbox. >> >> Cheers, >> Henry >> >> > > Oh, I see now why I missed this one. > trunk does not have Keith change: > Â Â Â Â Â Â Â Â Â Â Â Â lineEndConvention ifNil: [ self > detectLineEndConvention ] > but a direct call to: > Â Â Â Â Â Â Â Â Â Â Â Â self detectLineEndConvention > So trunk always set the line end convention in the converter and I > decided it was not necessary to use self converter: here... > Integrating Keith change has broken this fragile constuction, don't > know when it came in. http://code.google.com/p/pharo/issues/detail?id=1013 in 10400 http://bugs.squeak.org/view.php?id=6086 Now I know > I approve solution 2) > > Cheers > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Nov. 20, 2009

[Pharo-project] [ANN] Core 1.1 #11053

by Marcus Denker

http://gforge.inria.fr/frs/download.php/24823/PharoCore-1.1-11053-alpha.zip -- Marcus Denker -- http://www.marcusdenker.de

Nov. 20, 2009