August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Philippe's WebClient patches

by StÃ©phane Ducasse

Excellent! No stress we will batch the improvements :) I do not see it as running after, more doing my little market of improvements. Everything is in the stance. ;D Stef On Aug 25, 2010, at 5:31 PM, Sven Van Caekenberghe wrote: > This is the merged version: > > http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… > > ==================== Summary ==================== > > Name: WebClient-Core-SvenVanCaekenberghe.72 > Author: SvenVanCaekenberghe > Time: 25 August 2010, 5:22:16 pm > UUID: 952161b4-521e-48fe-9338-ba90805327e3 > Ancestors: WebClient-Core-StephaneDucasse.71, WebClient-Core-pmm.68 > > Merged changed contributed by Philippe Marschall > > > 3 failures, 1 error; but these are different ones ;-) > I guess these should be fixable, but I had little time. > > Now Andreas is already 3 version further (all committed yesterday) .... > > Sven > > On 25 Aug 2010, at 14:04, StÃ©phane Ducasse wrote: > >> >> On Aug 25, 2010, at 1:56 PM, Sven Van Caekenberghe wrote: >> >>> I was afraid you were going to ask that ;-) >> >> but I'm easy going no :) >> >>> OK, I'll see what I can do later today. >>> I'll have to read up a bit about MC merging. Like here http://www.lukas-renggli.ch/blog/monticello-merging ? >>> Later on Philippe should maybe also have a look at what I did... >> >> Philippe? >> else I will do it. >> >> Stef >> _______________________________________________ >> 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

Aug. 25, 2010

Re: [Pharo-project] Philippe's WebClient patches

by Sven Van Caekenberghe

This is the merged version: http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… ==================== Summary ==================== Name: WebClient-Core-SvenVanCaekenberghe.72 Author: SvenVanCaekenberghe Time: 25 August 2010, 5:22:16 pm UUID: 952161b4-521e-48fe-9338-ba90805327e3 Ancestors: WebClient-Core-StephaneDucasse.71, WebClient-Core-pmm.68 Merged changed contributed by Philippe Marschall 3 failures, 1 error; but these are different ones ;-) I guess these should be fixable, but I had little time. Now Andreas is already 3 version further (all committed yesterday) .... Sven On 25 Aug 2010, at 14:04, StÃ©phane Ducasse wrote: > > On Aug 25, 2010, at 1:56 PM, Sven Van Caekenberghe wrote: > >> I was afraid you were going to ask that ;-) > > but I'm easy going no :) > >> OK, I'll see what I can do later today. >> I'll have to read up a bit about MC merging. Like here http://www.lukas-renggli.ch/blog/monticello-merging ? >> Later on Philippe should maybe also have a look at what I did... > > Philippe? > else I will do it. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Carla F. Griggio

(5 @ 1 ) + 5 doesn't really bother me :S In fact, when I started working with points, some kind of magic made me write that hoping it would work. 2010/8/25 Guillermo Polito <guillermopolito(a)gmail.com> > Wow, morphic doesn't allow me to change the point aritmethic :D. I > supossed it Â¬Â¬. > > Here is already some code: > http://code.google.com/p/pharo/issues/detail?id=2858 > > > On Wed, Aug 25, 2010 at 4:35 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> :) >> >> I accept code. We are in unstable so this is the time to shake the system. >> >> On Aug 24, 2010, at 10:17 PM, Nicolas Cellier wrote: >> >> > Noooo, we dooon't want to. >> > >> > Nicolas >> > >> > 2010/8/24 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> Do we reeeeeally want to do >> >> >> >> 5 + '4' >> >> >> >> 5 + 'hello' >> >> >> >> ? >> >> >> >> _______________________________________________ >> >> 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 >

Aug. 25, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Guillermo Polito

Wow, morphic doesn't allow me to change the point aritmethic :D. I supossed it Â¬Â¬. Here is already some code: http://code.google.com/p/pharo/issues/detail?id=2858 On Wed, Aug 25, 2010 at 4:35 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > :) > > I accept code. We are in unstable so this is the time to shake the system. > > On Aug 24, 2010, at 10:17 PM, Nicolas Cellier wrote: > > > Noooo, we dooon't want to. > > > > Nicolas > > > > 2010/8/24 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Do we reeeeeally want to do > >> > >> 5 + '4' > >> > >> 5 + 'hello' > >> > >> ? > >> > >> _______________________________________________ > >> 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 >

Aug. 25, 2010

Re: [Pharo-project] 'foo' asTime

by StÃ©phane Ducasse

cool now let us see where it breaks and fix. Stef On Aug 25, 2010, at 3:58 PM, Guillermo Polito wrote: > I fixed Integer>>readFrom: yesterday. Its in the inbox http://code.google.com/p/pharo/issues/detail?id=2857&q=String%20Number&cols… > > On Wed, Aug 25, 2010 at 4:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi nicolas > > If I understand you correctly we are in sync. > Yes readFrom: should read or fails raising an Error > and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants] > > Now we integrated your number parsers so this is strange that the behavior is not like you mention > did you make them backwards compatible? > > So I would give a try to get readFrom: clean. > Johan please give a try > > Stef > > > > > In squeak, (Integer readFromString: 'foo') ->Error > > > > Use: > > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > > - (Integer readFrom: 'foo' ifFail: []), to get nil > > > > Though it is possible, I dislike anwsering nil, because it would mean > > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > > 1) That's nonsense, readFrom:ifFail: already does the work. > > 2) you cripple the code with Error conditions and end up with > > unreadable C-looking like code > > (3 lines of Error condition crap for 1 line of underlying algorithm > > at every function call) > > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > > > But that conversation already took place many times... > > > > I'd like the readFrom:ifFail: form to be generalized to other objects, > > with default behaviour raising an Error. What do you think ? > > > > Nicolas > > > > 2010/8/24 Johan Brichau <johan(a)inceptive.be>: > >> > >> On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: > >> > >>> I thought that readFromString: was raising an error and that guessNumber* was returning zero > >> > >> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > >> But: > >> > >> 'foo' asInteger = nil > >> Integer readFromString: 'foo' = 0 > >> 'foo' asNumber -> Error > >> > >> aargh :-( > >> > >> disclaimer: currently testing this in pharo1.1 > >> > >> Johan > >> _______________________________________________ > >> 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

Aug. 25, 2010

Re: [Pharo-project] 'foo' asTime

by Guillermo Polito

I fixed Integer>>readFrom: yesterday. Its in the inbox http://code.google.com/p/pharo/issues/detail?id=2857&q=String%20Number&cols… On Wed, Aug 25, 2010 at 4:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi nicolas > > If I understand you correctly we are in sync. > Yes readFrom: should read or fails raising an Error > and we should use Integer readFrom: 'foo' ifFail: [the default value that > the client knows that he wants] > > Now we integrated your number parsers so this is strange that the behavior > is not like you mention > did you make them backwards compatible? > > So I would give a try to get readFrom: clean. > Johan please give a try > > Stef > > > > > In squeak, (Integer readFromString: 'foo') ->Error > > > > Use: > > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > > - (Integer readFrom: 'foo' ifFail: []), to get nil > > > > Though it is possible, I dislike anwsering nil, because it would mean > > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > > 1) That's nonsense, readFrom:ifFail: already does the work. > > 2) you cripple the code with Error conditions and end up with > > unreadable C-looking like code > > (3 lines of Error condition crap for 1 line of underlying algorithm > > at every function call) > > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > > > But that conversation already took place many times... > > > > I'd like the readFrom:ifFail: form to be generalized to other objects, > > with default behaviour raising an Error. What do you think ? > > > > Nicolas > > > > 2010/8/24 Johan Brichau <johan(a)inceptive.be>: > >> > >> On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: > >> > >>> I thought that readFromString: was raising an error and that > guessNumber* was returning zero > >> > >> I thought that too. I even have application code that shows that this > used to return nil in some version of Pharo... > >> But: > >> > >> 'foo' asInteger = nil > >> Integer readFromString: 'foo' = 0 > >> 'foo' asNumber -> Error > >> > >> aargh :-( > >> > >> disclaimer: currently testing this in pharo1.1 > >> > >> Johan > >> _______________________________________________ > >> 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 >

Aug. 25, 2010

Re: [Pharo-project] Philippe's WebClient patches

by StÃ©phane Ducasse

On Aug 25, 2010, at 1:56 PM, Sven Van Caekenberghe wrote: > I was afraid you were going to ask that ;-) but I'm easy going no :) > OK, I'll see what I can do later today. > I'll have to read up a bit about MC merging. Like here http://www.lukas-renggli.ch/blog/monticello-merging ? > Later on Philippe should maybe also have a look at what I did... Philippe? else I will do it. Stef

Aug. 25, 2010

Re: [Pharo-project] Fwd: About SPDF

by Sven Van Caekenberghe

On 25 Aug 2010, at 12:38, StÃ©phane Ducasse wrote: > come on france is not that bad on this level too.... :) Well, l'Equipe de France did some nice things during the last World Cup in South-Africa.

Aug. 25, 2010

Re: [Pharo-project] Philippe's WebClient patches

by Sven Van Caekenberghe

I was afraid you were going to ask that ;-) OK, I'll see what I can do later today. I'll have to read up a bit about MC merging. Like here http://www.lukas-renggli.ch/blog/monticello-merging ? Later on Philippe should maybe also have a look at what I did... On 25 Aug 2010, at 12:39, StÃ©phane Ducasse wrote: > Ok sven could publish the merge in the inbox? > Since you know your changes, else I will have to understand both :)

Aug. 25, 2010

Re: [Pharo-project] Why is readStream on SequenceableCollection and not on Collection?

by Henrik Johansen

Den 25.08.2010 12:58, skrev Bart Gauquie: > > > On Wed, Aug 25, 2010 at 10:38 AM, Henrik Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> > wrote: > > > > Den 24.08.2010 17:58, skrev Nicolas Cellier: > > 2010/8/24 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu>>: > > > >> This cropped up in Dolphin some years back. IIRC, OA's answer > was that streams historically worked on only Array and maybe > something else. Having said that, they relaxed a constraint > because it was harmless and a good idea. > >> > >> I'm not sure about streaming over a set; lack of order means > that it might be tricky to maintain a reasonable position?? > >> > >> > > Exactly, the Stream would hardly be positionable, unless you use a > > sort of OrderedSet... > > A ReadWriteStream would be problematic for the same reasons. > > > > What would be the interest of such a Stream ? > > (I mean something more than what just you can do with #do:or #add:) > > > > Nicolas > +1. > I don't quite see what use could would find in a stream of a > non-sequenced source that is not better served by using a different > abstraction, or the source itself.. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > Ok, but why can you then do a collect:[] / select:[] / do: [] over a > set? It also iterates over all the elements. So why is it then > strange to have a readstream over a set? I'm not saying it should be a > positionable stream. > > But I also agree that is more logical to only do a ReadStream over a > SequenceableCollection if you take into account positions ... Maybe > change the code so that it only accepts a SequenceableCollection? > > Haven't tried Nile yet. > > Kind Regards, > > Bart Yes they iterate of the elements, but they don't really care about which. sequence the elements are in. Sure you can write a block to pass to them which does, but I doubt you'd want to use that with a Set or a Dictionary. #next, #nextPut:, #upTo: and the rest of the Stream protocol certainly do care what sequence the elements are in. Cheers, Henry

Aug. 25, 2010