- Pharo-dev - lists.pharo.org

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

[Pharo-project] HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading

by Peter Hugosson-Miller

Both these methods suffer from the same problem, and I speculate that this is due to copy/paste. In both cases there is a local variable "response" which is set to a WriteStream on "buf" ( := String new: 2000). However "response" is never written to using the methods on WriteStream, but "buf" is written to directly via the #primSocket:receiveDataInto: method. In several places, "response position" is used to determine how many characters have been read into "buf", and what's worse, the value of "response position" is updated using #instVarAt:put: (!!) The methods have each two possible returns. In one, "response position" is used as the second argument to #copyFrom:to:, and in the other, "response contents" is used to achieve the same effect. In other words, "response" is not being used as a WriteStream, but as a placeholder for an integer: its "position". There is a comment in each method ("horrible, but fast") next to the invocation of #instVarAt:put:, but the true significance has been missed. I have made a new version of the methods using a new temporary variable "position", initialized to 0, and used throughout as an Integer. This reveals the true intent of the method much better than the rather ugly implementations currently in place. Here is the link to the issue: http://code.google.com/p/pharo/issues/detail?id=1152 I have made the fix, and will submit it as soon as 10432 is available. -- Cheers, Peter

Sept. 3, 2009

Re: [Pharo-project] [ANN]

by Schwab,Wilhelm K

Sig, One of the great things about Smalltalk is that we are seldom forced to do anything, and certainly not in this case. It is easy to define #readStream where appropriate, and IMHO Pharo should do so. Not only does it give cleaner code, it will help us insert Nile when the time comes, and we can simply add the missing methods. I submit that the problem is instead all of the external code that will still explicitly reference ReadStream. That is not a reason to not make the change, and I am hoping that a little leadership by example will cause the right thing to happen across the board. More challenging still are the inconsistencies in exhaustion behavior. Referring to my proposal on the wiki, I stand ready to help if we want to enforce EndOfStreamError on any "unauthorized" exhaustion, but I have my doubts that we will do so; Cincom considered and declined the proposal. I can also not afford to wait for the decision to be made and imlemented. For now, I am gradually moving my code toward #nextOne, #nextMany:, etc., which again can be done simply by adding new code. If Pharo adopts EndOfStreamError, I can easily change from my new protocol to the more generic messages. FWIW, one of the first things I did was define #readStream on various collections and collection classes. Dolphin (sorry to keep beating the drum, but it sets a wonderful example!) has had #readStream "everywhere" for a long time if not from its earliest days. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, September 03, 2009 10:42 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] the problem that not all classes define #readStream.. as far as i remember, i had some issues with it, and forced to use "ReadStream on:" instead 2009/9/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > - Issue 1144: Â Many occurrences of "ReadStream on: aCollection" which > can be replaced with "aCollection readStream" > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ 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] Coral using NewCompiler

by Luc Fabresse

2009/9/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Excellent! Excellent! Excellent! > I want to > - fix the problem about the path of the script so that you do not > have to put the full path > - have a better way to define classes > Object > Point (may be like ruby) > > - use use use it > > We should fix the to do > - !#/usr/bin > > I granted you access. I want coral to work. > Can you publish? > Ok done. Just load LoadCoral to test. #Luc > Stef > > On Sep 3, 2009, at 9:59 AM, Luc Fabresse wrote: > > > I modified LoadCoral and Coral so that it works in the > > pharo1.0-10418-BETAdev09.08.3 image and uses NewCompiler. > > Since I cannot commit on the Coral repository, I attached the files. > > > > To test it : > > 1- file in LoadCoral that installs dependencies and the Coral > > version on ss > > 2- file in Coral and Coral-DeadCode > > 3- save image as coral.image > > 4- create coral.sh script : > > > > #! /bin/sh > > vm='/Applications/SqueakVMs/Squeak 4.1.1beta2U.app/Contents/MacOS/ > > Squeak VM Opt' > > "$vm" "coral.image" $1 > > > > 5- create hello.st > > [ > > Console print: 'Hello World' > > ] > > > > 6- execute : ./coral.sh hello.st > > > > ------- > > > > Below another script using Rio (File-Kernel, File-Base). > > 1- Installer ss project: 'Rio' ; install: 'File-Kernel'; install: > > 'File-Base' > > syntax error on loading (just comment the pragma and accept) > > 2-create rio-test.st > > > > [ > > Object subclass: #SaBox > > instanceVariableNames: 'bob' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'SandBox' > > ] > > > > "a dummy example that convert a class in a file hierarchy" > > SaBox>>convertToFiles: aClass inDirectory: rootDir > > [ > > | classDir categoryNames | > > classDir := (rootDir / aClass asString) mkdir. > > categoryNames := aClass organization categories collect: > > [ :aCategory | aCategory asString ]. > > categoryNames do: [ :aCategoryName | | protocolDir | > > protocolDir := (classDir / aCategoryName) mkdir. > > (aClass methodsInCategory: aCategoryName) do: [ :aSelector > | > > (protocolDir / (aSelector asFileName replaceAll: $: > with: $_)) > > asFile contents: (aClass sourceCodeAt: aSelector) > > ] > > ]. > > ^classDir > > ] > > > > > > [ > > SaBox new convertToFiles: Object inDirectory: Directory home. > > ] > > 3- ./coral.st rio-test.sh > > > > > > > > #Luc > > <Coral.st><Coral- > > DeadCode > > .st><LoadCoral.st>_______________________________________________ > > 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 Igor Stasenko

the problem that not all classes define #readStream.. as far as i remember, i had some issues with it, and forced to use "ReadStream on:" instead 2009/9/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > - Issue 1144: Â Many occurrences of "ReadStream on: aCollection" which > can be replaced with "aCollection readStream" > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 3, 2009

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

by csrabak＠bol.com.br

+1 Em 03/09/2009 11:46, Peter Hugosson-Miller < oldmanlink(a)gmail.com > escreveu: > 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. >

Sept. 3, 2009