January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Adding hudson links from pharo webpage?

by Schwab,Wilhelm K

I would not have thought to put it there, but it's a good idea. I think there should also be a link on the download section?? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Tudor Girba [tudor.girba(a)gmail.com] Sent: Friday, January 07, 2011 1:53 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Adding hudson links from pharo webpage? Currently, the link is here: http://pharo-project.org/community Cheers, Doru On 7 Jan 2011, at 19:22, Mariano Martinez Peck wrote: > Now that hudson seems to be working fine, I think it is a good moment to link hudson links from the pharo website. > > cheers > > mariano -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Adrian Lienhard

On Jan 7, 2011, at 10:15 , Johan Brichau wrote: > > On 07 Jan 2011, at 09:05, StÃ©phane Ducasse wrote: > >> I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport). >> I would favor push metacello so that in one click people can load what they want. > > +1 +1 I would also be rather conservative with regard to adding packages that are not developer tools. If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore). It appears to me that preloading packages like XML is just points out that a good package manager is missing. Cheers, Adrian

Jan. 7, 2011

[Pharo-project] What feature you want to see in Mondrian

by Alexandre Bergel

Hi! I am willing to spend some time on Mondrian the coming weeks. I would like to know what are the feature/issue what are the most pressing for you? http://code.google.com/p/moose-technology/issues/list?can=2&q=Mondrian&cols… Lazy edges? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 7, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by Nicolas Cellier

2011/1/7 <csrabak(a)bol.com.br>: > Em 07/01/2011 15:10, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: > > You make excellent points Nicolas! > > >> All the other messages could have had the copy prepended if it was a >> question of homogeneitty Â with existing API. Â The fact Â is that they >> were added Â later than Â copy and copyFrom:to: >> Â Of course, we Â can as well remove the Â copy prefix, but do we really care Â ? > > I think we should, as the removal would have ripple effects in production code. > Our reasoning should be some sort of ROI on it. > >> Is it really what makes the message ambiguous ? > > I would argue that the presence of 'copy' suffix makes them _less_ ambiguous as > far as the methods in question effectively do a copy on the receiver. > >> Â If Â I wouldn't know Â about the Â message, my Â question would Â not be >> about Â whether or Â not the Â message triggers Â a copy. Â It Â would be >> whether the argument are elements or indices. > > You mean that once you have removed the 'copy' prefix or as the method names stand right now (and I mean for the ones this issue number is about)? > >> Â I could expect: >> Â #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. >> Â to work like: >> Â #( 'foo' 'bar' 'baz') after: 'foo'. > > I would like to elaborate on your half million question Â« Is it really what makes the message ambiguous ? Â» > > If you attempt your example in plain Pharo image > > #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. > > You get a MNU > > ByteString(Object)>>doesNotUnderstand: #- > Array(SequenceableCollection)>>copyFrom:to: > . > . > . > > So what would be your point: > > 1) copyFrom:to: is not 'polymorphic enough' for Pharo Smalltalk ideal of a dynamic language? > > 2) the message name is to be changed to copyFromIndex: start toIndex: end? > > 3) some other concoction I missed? > > > HTH > > -- > Cesar Rabak > > Here is what I mean: I agree that #copyFrom: is ambiguous and could be renamed, with all deprecation precautions. But concerning #copyFrom:to: I think this name is a non issue for code readability. I decided to play advocatus diaboli just to push a bit absurdness of this ubuesque thread. In Smalltalk, you have to trust what you read, and to me (aString copyFrom: 2 to: aString size - 3) is obviously a copy, and arguments are obviously indices, what else could it be ? So no, I don't suggest to drop the copy though it's not strictly necessary, nor to append an Index to the name. Who never browsed senders of such message in squeaksource code base could have such a foolish idea. For writing code, we can't just guess an API, so this is a non issue too. I can't guess the name, it could be #copyFromStartIndex:toStopIndex: or just #from:to:, no way the API will fit everyone's brain. For writing code we have these alternatives: - Open a Browser and browse the collection classes - learn idioms from reading other code - learn idioms from a tutorial or a help system - type a keyword in a message finder, or some receiver arguments and expected results. All these actions will clearly disambiguate the semantic of copyFrom:to: arguments. We can tolerate some level of ambiguity when the send sites will disambiguate. As for homogeneity, I don't propose anything but statu quo. I understand (aString first: 3) as well as extending (aString first), and I can reasonnably guess it will answer a copy too, why the hell would this innocent message change aString state ? Does (aString first) do ? So no, I don't need to add a copy prefix to this message, and no i don't really care for a higher homogeneity. If we change a few missnamed selectors here and there, that's OK, but if we change a large amount of Kernel messages with many senders, it's a recipee for Pharo rejection, because we would make developer's life a hell for no valid reason. Nicolas

Jan. 7, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by csrabak＠bol.com.br

Em 07/01/2011 16:43, pharo(a)googlecode.com escreveu: > Comment #19 on issue 3436 by step...(a)stack.nl: #copyFrom: is broken > http://code.google.com/p/pharo/issues/detail?id=3436 > Nicolas wrote: > > All the other messages could have had the copy prepended if it was > > a question of homogeneitty with existing API. The fact is that > > they were added later than copy and copyFrom:to: Of course, we can > > as well remove the copy prefix, but do we really care ? Is it > > really what makes the message ambiguous ? > It is one of the ambigueties. The ambiguity is of course a thing we have to qualify. The Collection hierarchy of Smalltalk uses Integers for indices for accessing elements. This is something you need to learn to be able to use these classes. > > > If I wouldn't know about the message, my question would not be > > about whether or not the message triggers a copy. It would be > > whether the argument are elements or indices. > > - does it return a copy or change self does it return a collection Well the word 'copy' seems to indicate the it doesn't change self, if it did, we should open another issue and search for a fix. The other part of the enthymeme of yours must be pointed out to practicality and the sensible thing to do. The return would most of the time be the most appropriate collection given the intent of the extraction done by the method. Pathological cases should be issued and discussed for a fix. > - or an element are arguments elements or indices There is a limit on the 'non knowledge' you can [not] have in order to use the methods of a determined class. In Pharo you have as a last recourse the browsing of the method implementation itself. > should be reflected in the naming of the method, if one wants to > avoid having to read the implementation/comments. There should be a balance between the three. Otherwise you'll end up with too verbose API ("interface") for doing the daily chores, and people will frown and stop using the language. Even with OCompletion and friends, the most common operations should strive to have short method names and be relatively mnemonic for people who get trained in the environment/technology/language. > Currently, every method having copy in its name has to be examined > closely, to be able to decide what behavior should be > expected. Once we get evidence on this we could proceed. Do you have any case to show us? > Overriding semantics is less than helpful, as that leads > to more confusion. As long as there is no clear naming convention, > it is better to add new method names than to overlay new behavior on > existing ones. No. We have a history and production code to live with as well. In extremis your suggestion is better accomplished with a proposal for a new, parallel, hierarchy of classes with a 'better' interface, which put in the ecosystem should show if its benefits make developers to change to it instead of the present one. my 0.019999... -- Cesar Rabak

Jan. 7, 2011

Re: [Pharo-project] [ANN] Amazon AWS S3 Client

by Sven Van Caekenberghe

On 06 Jan 2011, at 10:44, Marcus Denker wrote: > Nice! Thx. > Did you check the work of Ernst Micklei and Jan van de Sandt? > They implemented smalltalk libraries for S3, but in addition other services (e.g. SimpleDB) > > > http://blog.doit.st/ > http://www.slideshare.net/esug/cloudfork Yeah, I know about that project, they did some cool stuff. I did an S3 client myself for two reasons: (1) I wanted it for myself (always a very good reason) (2) I consider it a validation for Zn (and I was happy with it, the code is quite elegant) Sven

Jan. 7, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by csrabak＠bol.com.br

Em 07/01/2011 15:10, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: You make excellent points Nicolas! > All the other messages could have had the copy prepended if it was a > question of homogeneitty with existing API. The fact is that they > were added later than copy and copyFrom:to: > Of course, we can as well remove the copy prefix, but do we really care ? I think we should, as the removal would have ripple effects in production code. Our reasoning should be some sort of ROI on it. > Is it really what makes the message ambiguous ? I would argue that the presence of 'copy' suffix makes them _less_ ambiguous as far as the methods in question effectively do a copy on the receiver. > If I wouldn't know about the message, my question would not be > about whether or not the message triggers a copy. It would be > whether the argument are elements or indices. You mean that once you have removed the 'copy' prefix or as the method names stand right now (and I mean for the ones this issue number is about)? > I could expect: > #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. > to work like: > #( 'foo' 'bar' 'baz') after: 'foo'. I would like to elaborate on your half million question Â« Is it really what makes the message ambiguous ? Â» If you attempt your example in plain Pharo image #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. You get a MNU ByteString(Object)>>doesNotUnderstand: #- Array(SequenceableCollection)>>copyFrom:to: . . . So what would be your point: 1) copyFrom:to: is not 'polymorphic enough' for Pharo Smalltalk ideal of a dynamic language? 2) the message name is to be changed to copyFromIndex: start toIndex: end? 3) some other concoction I missed? HTH -- Cesar Rabak

Jan. 7, 2011

Re: [Pharo-project] Issue 3516 in pharo: Failing tests in MetaCello

by pharo＠googlecode.com

Comment #4 on issue 3516 by da...(a)teleport.com: Failing tests in MetaCello http://code.google.com/p/pharo/issues/detail?id=3516 The test failure is due to a test bug ... apparently a recent update to Pharo1.2 has changed the printString for some symbols. #>= used to print as #'>=' and now prints as #>= which affected the two tests ... This test bug will be fixed in Metacello 1.0-beta.28.

Jan. 7, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by Sven Van Caekenberghe

On 07 Jan 2011, at 13:58, StÃ©phane Ducasse wrote: > I was just reading the code with olivier auverlot. > I would love to have a small if possible replacement to the HTTPSocket. There really is a lot of cleanup to do. The key/core replacement of HTTP client functionality is done, but HTTPSocket does so much stuff in such bizar ways that it will require a concerted effort of many people to clean it up. Then again, if Pharo won't do it, who will ? Sven

Jan. 7, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by Sven Van Caekenberghe

I was in meeting all day, hence the late reply. On 07 Jan 2011, at 14:08, StÃ©phane Ducasse wrote: > Sven > > two questions: > - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces. I don't think that would make a lot of sense: HTTP is a client-server protocol, the client and server sides have a lot in common; a split in three pieces would be possible but each piece would be rather small. Having the necessary pieces for a simple HTTP server present will lower the bar for others, so that makes sense too. (For example, the Seaside adaptor is really very little code, no more need for Kom unless you really want it). > - do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP? Maybe, finding shared code can only be done by doing both implementations I'm afraid ;-) Another, related point is the following: maybe you noticed browsing the code that I have a number of classes in Zn that redo some standard functionality (ZnMimeType, ZnUrl, ZnCharacterEncoder, and some of the code in the utils classes), a bit like Seaside does. The reason is that the existing classes were broken beyond repair (IMHO), or that I was not confortable extending them. Now, if the existing classes could be improved/replaced, it would make sense to replace the Zn variant with a good system wide one. This is a search for the best solution. Sven

Jan. 7, 2011