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

Re: [Pharo-project] Added package SLICE-RemoveReferencesToReadStreamOn-PeterHugossonMiller.3 to PharoInbox

by Henrik Johansen

Err, please replace asReadStream with asWriteStream in that last sentence :) On Sep 4, 2009, at 12:04 55AM, Henrik Johansen wrote: > In VW, the methods are called readStream and writeStream. > > Personally, I prefer that, as a method starting with as... to me > indicates having created a new equivalent object, not just a wrapper > which is used to access the original object. > There's a big difference between calling f.ex. _as_Array on an > SequenceableCollection, then messing with the elements of the object > returned, and doing the same with a method called asReadStream. > > Cheers, > Henry > > On Sep 3, 2009, at 4:46 13PM, Peter Hugosson-Miller wrote: > >> I don't know how this is done in VW, but in any case I would also >> prefer the method to be called #asReadStream, since it more clearly >> expresses the fact that there is a conversion happening. >> >> In the same way, I would like to suggest the method >> SequenceableCollection>>#writeStream would be better named >> #asWriteStream, and I also think that the creation of a new method >> SequenceableCollection>>#asReadWriteStream would be a good idea. >> >> -- >> Cheers, >> Peter >> >> On Thu, Sep 3, 2009 at 4:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> > wrote: >> I'm integrating your changes. >> Now I was wondering if somebody knows if it VW we get readStream too >> because I would prefer to have a better message than readStream >> aCol asReadStream ? >> >> What do you think? >> >> Stef >> >> >> >> On Sep 2, 2009, at 9:59 PM, Peter Hugosson-Miller wrote: >> >> > On Wed, Sep 2, 2009 at 9:30 PM, Adrian Lienhard <adi(a)netstyle.ch> >> > wrote: >> > Welcome, Peter! >> > >> > When you commit a change it would be good to also open an issue >> in the >> > tracker (and tell there which slice this is and in the slice >> comment >> > say which issue number it is). Like this it is easier to keep >> track of >> > changes. >> > >> > Cheers, >> > Adrian >> > >> > Strange, I thought I had done that, but it was probably just the >> > wrong part of the system (I'm just learning). >> > >> > This is the issue I created for the slice: http://code.google.com/p/pharo/issues/detail?id=1144 >> > so could you please tell me what I should have done instead (or as >> > well ;-))? >> > >> > Thanks in advance, >> > Peter >> > _______________________________________________ >> > 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

Sept. 3, 2009

Re: [Pharo-project] Added package SLICE-RemoveReferencesToReadStreamOn-PeterHugossonMiller.3 to PharoInbox

by Henrik Johansen

In VW, the methods are called readStream and writeStream. Personally, I prefer that, as a method starting with as... to me indicates having created a new equivalent object, not just a wrapper which is used to access the original object. There's a big difference between calling f.ex. _as_Array on an SequenceableCollection, then messing with the elements of the object returned, and doing the same with a method called asReadStream. Cheers, Henry On Sep 3, 2009, at 4:46 13PM, Peter Hugosson-Miller wrote: > I don't know how this is done in VW, but in any case I would also > prefer the method to be called #asReadStream, since it more clearly > expresses the fact that there is a conversion happening. > > In the same way, I would like to suggest the method > SequenceableCollection>>#writeStream would be better named > #asWriteStream, and I also think that the creation of a new method > SequenceableCollection>>#asReadWriteStream would be a good idea. > > -- > Cheers, > Peter > > On Thu, Sep 3, 2009 at 4:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > I'm integrating your changes. > Now I was wondering if somebody knows if it VW we get readStream too > because I would prefer to have a better message than readStream > aCol asReadStream ? > > What do you think? > > Stef > > > > On Sep 2, 2009, at 9:59 PM, Peter Hugosson-Miller wrote: > > > On Wed, Sep 2, 2009 at 9:30 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > Welcome, Peter! > > > > When you commit a change it would be good to also open an issue in > the > > tracker (and tell there which slice this is and in the slice comment > > say which issue number it is). Like this it is easier to keep > track of > > changes. > > > > Cheers, > > Adrian > > > > Strange, I thought I had done that, but it was probably just the > > wrong part of the system (I'm just learning). > > > > This is the issue I created for the slice: http://code.google.com/p/pharo/issues/detail?id=1144 > > so could you please tell me what I should have done instead (or as > > well ;-))? > > > > Thanks in advance, > > Peter > > _______________________________________________ > > 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

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Miguel Enrique CobÃ¡ Martinez

El vie, 04-09-2009 a las 09:33 +1200, Michael van der Gulik escribiÃ³: > > > On Fri, Sep 4, 2009 at 3:21 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > - Issue 1144: Many occurrences of "ReadStream on: > aCollection" which > can be replaced with "aCollection readStream" > > > For what it's worth, I prefer the style of "ReadStream on: xxx". I > prefer to choose the stream class rather than let the collection > choose it for me. But don't you always have the option to call ReadStream on: object, even though object class has a readStream method? > > > Gulik. > > -- > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 3, 2009

Re: [Pharo-project] [Bulk] Re: Rio: binary mode copy not keep

by Schwab,Wilhelm K

FWIW, I recently had a very similar problem bite me, and had to set the binary mode to fix it. I _thought_ I had tested the offending code, and maybe I did?? I am still on web 09.07.2; the code has been with me since 6-08, and I noted the failure last month. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Keith Hodges Sent: Thursday, September 03, 2009 4:31 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Bulk] Re: Rio: binary mode copy not keep Vicnet wrote: > Hello, > > Keith Hodges a Ã©crit : > >>> The src directory I use containts jpeg file. >>> addTree fails because FileKernel use a FileJpeg in InputStream and >>> there is a input pb on this file. >>> >> an input what? >> > > UTF8TextConverter(Object)>>error:'Invalid utf8 input detected' > > In fact, there is nothing to deal with FileJpeg, File make the same > error on my image (Exupery with Pharo on Windows). > > >>> I try to add binary mode : >>> base binary addTree: dest. >>> > > Files from base are not copy in binary mode. > > >>> addTree collect files/dirs to copy but dot not transmit the binary flag. >>> Is it normal ? >>> Directory home binary files first isBinary ==> false ! >>> Should it be true ? >>> > > >> copyLocalFile:toLocalFile: chooses from a variety of copying methods >> I understand that there is a bug here >> > > Not sure that the pb What the heck is pb? > is here. > > I think it is in #entries (or #files,...) method that collect files > from source dir without reporting binary mode from parent. > Peharps, #select: should do the job ? > > > but I am not really sure what the > > problem is with the jpeg file. > > Rigth, the pb is not with jpeg but with copy mode that not transmit. > > > However, here is a suggestion: > FileKernel>>entries is defined as > self select: [:e | true ] > a block that only return true is strnage for me. > Why not #contentsIn: in executive that return all entries (like > contents in Collection) ? > Because #select: already does everything you need in an elegant manner. The squeak wiki Rio page documents this > a+ > Vicnet > Sorry but I dont understand most of your email. All file copies are in binary mode by default, so there should be no need to copy the binary flag. Keith _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Schwab,Wilhelm K

Then #readStreamXYZ would do the job. Depending on how you write the methods, both you and the collection have a say, or you can also have complete control. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael van der Gulik Sent: Thursday, September 03, 2009 4:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] On Fri, Sep 4, 2009 at 3:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: - Issue 1144: Many occurrences of "ReadStream on: aCollection" which can be replaced with "aCollection readStream" For what it's worth, I prefer the style of "ReadStream on: xxx". I prefer to choose the stream class rather than let the collection choose it for me. Gulik. -- http://gulik.pbwiki.com/

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Michael van der Gulik

On Fri, Sep 4, 2009 at 3:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > - Issue 1144: Many occurrences of "ReadStream on: aCollection" which > can be replaced with "aCollection readStream" > For what it's worth, I prefer the style of "ReadStream on: xxx". I prefer to choose the stream class rather than let the collection choose it for me. Gulik. -- http://gulik.pbwiki.com/

Sept. 3, 2009

Re: [Pharo-project] [Bulk] Re: Rio: binary mode copy not keep

by Keith Hodges

Vicnet wrote: > Hello, > > Keith Hodges a Ã©crit : > >>> The src directory I use containts jpeg file. >>> addTree fails because FileKernel use a FileJpeg in InputStream and there is >>> a input pb on this file. >>> >> an input what? >> > > UTF8TextConverter(Object)>>error:'Invalid utf8 input detected' > > In fact, there is nothing to deal with FileJpeg, File make the same > error on my image (Exupery with Pharo on Windows). > > >>> I try to add binary mode : >>> base binary addTree: dest. >>> > > Files from base are not copy in binary mode. > > >>> addTree collect files/dirs to copy but dot not transmit the binary flag. >>> Is it normal ? >>> Directory home binary files first isBinary ==> false ! >>> Should it be true ? >>> > > >> copyLocalFile:toLocalFile: chooses from a variety of copying methods >> I understand that there is a bug here >> > > Not sure that the pb What the heck is pb? > is here. > > I think it is in #entries (or #files,...) method that collect files from > source dir without reporting binary mode from parent. > Peharps, #select: should do the job ? > > > but I am not really sure what the > > problem is with the jpeg file. > > Rigth, the pb is not with jpeg but with copy mode that not transmit. > > > However, here is a suggestion: > FileKernel>>entries is defined as > self select: [:e | true ] > a block that only return true is strnage for me. > Why not #contentsIn: in executive that return all entries (like contents > in Collection) ? > Because #select: already does everything you need in an elegant manner. The squeak wiki Rio page documents this > a+ > Vicnet > Sorry but I dont understand most of your email. All file copies are in binary mode by default, so there should be no need to copy the binary flag. Keith

Sept. 3, 2009

[Pharo-project] [update] #10433

by Marcus Denker

10433 Issue 1140: Remove popUp and test fail of Issue 1145: Fix for SoundBuffer being removed from the system but not from BitmapStreamTests>>#testOtherClasses. not reproducable: Issue 747: FileBrowser UndefinedObject(Object)>>doesNotUnderstand: #pathParts -- 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

Sept. 3, 2009

Re: [Pharo-project] [Bulk] Re: Rio: binary mode copy not keep

by Vicnet

Hello, Keith Hodges a Ã©crit : >> The src directory I use containts jpeg file. >> addTree fails because FileKernel use a FileJpeg in InputStream and there is >> a input pb on this file. > an input what? UTF8TextConverter(Object)>>error:'Invalid utf8 input detected' In fact, there is nothing to deal with FileJpeg, File make the same error on my image (Exupery with Pharo on Windows). >> I try to add binary mode : >> base binary addTree: dest. Files from base are not copy in binary mode. >> addTree collect files/dirs to copy but dot not transmit the binary flag. >> Is it normal ? >> Directory home binary files first isBinary ==> false ! >> Should it be true ? > copyLocalFile:toLocalFile: chooses from a variety of copying methods > I understand that there is a bug here Not sure that the pb is here. I think it is in #entries (or #files,...) method that collect files from source dir without reporting binary mode from parent. Peharps, #select: should do the job ? > but I am not really sure what the > problem is with the jpeg file. Rigth, the pb is not with jpeg but with copy mode that not transmit. However, here is a suggestion: FileKernel>>entries is defined as self select: [:e | true ] a block that only return true is strnage for me. Why not #contentsIn: in executive that return all entries (like contents in Collection) ? a+ Vicnet

Sept. 3, 2009

Re: [Pharo-project] MC Packages and namespaces (renamed: ODBCWarning)

by Brian Brown

On Sep 2, 2009, at 10:51 PM, Schwab,Wilhelm K wrote: > Brian, > > I'm not sure if I did it correctly, but it did not quite do the > right thing. It caught the extension methods, but there are a few > required classes that are still in the ODBC branch of the > Dolphincompatibility package. Does that sound familiar and fixable? > > Bill > Others can chime in here, but If I have the following: MyPackage-Core MyPackage-UI MyPackage-Web and I create a new MC Package called MyPackage and save it, it will get all three PackageInfo categories. If, however, I create a new MC Package called MyPackage-Core, then the MC file should only contain the classes in the MyPackage-Core PackageInfo category. IIRC, I've done this many times..... If it's not working, either I'm daft, or something is broken. Thoughts? - Brian

Sept. 3, 2009