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

[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

[Pharo-project] How do I get the user directory?

by Torsten Bergmann

Damien Pollet wrote: >Besides I have no idea what an untrusted user directory is. Perhaps a >Windowsish concept ? Read the class comment of SecurityPlugin in the following changeset and you will be find answers: [1] Looks like "My Squeak" is hard coded, see sqUnixSecurity.c [2] for Unix. Have fun Torsten [1] http://ftp.squeak.org/updates/3527VMSecurity-ar.cs [2] http://tracker.squeakland.org/secure/attachment/13397/sqUnixSecurity.c -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Sept. 3, 2009

Re: [Pharo-project] ODBCWarning

by csrabak＠bol.com.br

Em 03/09/2009 09:56, Benoit St-Jean < bstjean(a)yahoo.com > escreveu: > Cool! > If that's of any help, I volunteer to test your stuff on Windows XP > (SP3) for both clients & RDBMS. At the moment, I can test for > MySQL, InterBase, SQL Server 2000. But if you need it, I could take > some time and set up a DB2 server and an Oracle server for the same > platform. > Cool! Very very cool! > Question : I know it's usually not recommended to test stuff that > requires external output (such as setting up user, password, DSN, > etc) but I think we should design a very simple database, on all > those RDBMS and use SUnit to automate testing. What do you guys > think ? > I think this is a case where this 'rule' needs to be broken if we intend to ascertain the full functionality of these package. The only proviso I would put forward is that the Unit Tests be packaged individually for each RDBMS so interested developers could download the one(s) [s]he intends to develop for without having to worry about the ones there will be no interest. Probably we'll need to add more than just Smalltalk file outs to these SUnit packages. . . My 0.019999...

Sept. 3, 2009

[Pharo-project] [ANN]

by StÃ©phane Ducasse

- Issue 1144: Many occurrences of "ReadStream on: aCollection" which can be replaced with "aCollection readStream"

Sept. 3, 2009

[Pharo-project] How do I get the user directory?

by Damien Pollet

aka $HOME or ~/ There is SecurityManager default untrustedUserDirectory but on my machine this returns '/Users/damien/Library/Preferences/Squeak/Internet/My Squeak' and SecurityManager default secureUserDirectory but this one returns nonsense like '/foobar/tooBar/forSqueak/bogus' Besides I have no idea what an untrusted user directory is. Perhaps a Windowsish concept ? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Sept. 3, 2009

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

by Peter Hugosson-Miller

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 >

Sept. 3, 2009