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

Re: [Pharo-project] Fix the other dependencies of asContextWithSender:

by Juan Vuletich

Eliot Miranda wrote: > > > On Wed, Jul 7, 2010 at 11:46 AM, Juan Vuletich <juan(a)jvuletich.org > <mailto:juan@jvuletich.org>> wrote: > > > When I integrate stuff in Cuis, I always do my best effort to > understand it! > > Anyway, I see your new version, but in BlockClosure >> value it > still does > numArgs ~= 1 ifTrue: [self numArgsError: 1]. > even if the older version (9/3/2008) it checked for zero > arguments. Is this right? If so, what's the rationale? > > > No rationale there at all. Another mistake. I'm having a bad day /: Then I hope it gets better! Thanks, Juan Vuletich

July 7, 2010

Re: [Pharo-project] Monticello & proxy with security.

by laurent laffont

2010/7/7 Diogenes Moreira <diogenes.moreira(a)gmail.com> > hi folks. > > right now, i'm behind a squid proxy with security (user & pass).. in the > preferences, I find the proxy configuration, but only have ip and port. > Exists a way to set user and password in that connection??? > Hi Diogenes, Evaluate: HTTPSocket useProxyServerNamed:'192.168.1.1' port:3128 proxyUser:'user' password:'password' see http://book.pharo-project.org/book/TipsAndTricks/PharoRC/ Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > Thanks in advance. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2010

Re: [Pharo-project] Fix the other dependencies of asContextWithSender:

by Eliot Miranda

On Wed, Jul 7, 2010 at 11:46 AM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Eliot, > > Eliot Miranda wrote: > >> Hi Juan, >> >> >> On Wed, Jul 7, 2010 at 5:24 AM, Juan Vuletich <juan(a)jvuletich.org<mailto: >> juan(a)jvuletich.org>> wrote: >> >> Hi Eliot, >> >> There are several other changes in that package that could >> generate different behavior. Are they correct? They are: >> >> BlockClosure >> value >> used to call primitive 201, now calls 205 >> used to check for zero args, now checks for one (!?) >> >> BlockClosure >> value: >> used to call primitive 202, now calls 205 >> >> BlockClosure >> value:value: >> used to call primitive 203, now calls 205 >> >> BlockClosure >> value:value:value: >> used to call primitive 204, now calls 205 >> >> Primitive 205 was previously only used for >> #value:value:value:value:, so I wonder if this might be a mistake. >> >> >> Quite right, this is a mistake. I was careless copy-pasting the fix >> between them. I've committed fixes to trunk. In the VM these primitive >> numbers all bind to the same primitive so there was no visible effect. >> Thanks for checking! >> >> best >> Eliot >> > > When I integrate stuff in Cuis, I always do my best effort to understand > it! > > Anyway, I see your new version, but in BlockClosure >> value it still does > numArgs ~= 1 ifTrue: [self numArgsError: 1]. > even if the older version (9/3/2008) it checked for zero arguments. Is this > right? If so, what's the rationale? > No rationale there at all. Another mistake. I'm having a bad day /: > > Thanks! > Juan Vuletich > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2010

Re: [Pharo-project] Fix the other dependencies of asContextWithSender:

by Juan Vuletich

Hi Eliot, Eliot Miranda wrote: > Hi Juan, > > On Wed, Jul 7, 2010 at 5:24 AM, Juan Vuletich <juan(a)jvuletich.org > <mailto:juan@jvuletich.org>> wrote: > > Hi Eliot, > > There are several other changes in that package that could > generate different behavior. Are they correct? They are: > > BlockClosure >> value > used to call primitive 201, now calls 205 > used to check for zero args, now checks for one (!?) > > BlockClosure >> value: > used to call primitive 202, now calls 205 > > BlockClosure >> value:value: > used to call primitive 203, now calls 205 > > BlockClosure >> value:value:value: > used to call primitive 204, now calls 205 > > Primitive 205 was previously only used for > #value:value:value:value:, so I wonder if this might be a mistake. > > > Quite right, this is a mistake. I was careless copy-pasting the fix > between them. I've committed fixes to trunk. In the VM these > primitive numbers all bind to the same primitive so there was no > visible effect. Thanks for checking! > > best > Eliot When I integrate stuff in Cuis, I always do my best effort to understand it! Anyway, I see your new version, but in BlockClosure >> value it still does numArgs ~= 1 ifTrue: [self numArgsError: 1]. even if the older version (9/3/2008) it checked for zero arguments. Is this right? If so, what's the rationale? Thanks! Juan Vuletich

July 7, 2010

[Pharo-project] Suggestions for hotel/apartment for ESUG2010 in Barcelona?

by Stephan Eggermont

Does anyone have suggestions for a good (and cheap) place to stay during ESUG2010 in Barcelona? The conference is not in the city centre, and the only hotel which is close by (NH CornellÃ ) has no places available. We thought of renting a large appartment somewhere along the metro line 5 and sharing. Anyone interested? Stephan & Diego

July 7, 2010

[Pharo-project] [update 1.2] #12040

by StÃ©phane Ducasse

12039 ----- Issue 2635: Preparation. 12040 ----- Issue 2635: Uppercase extensions - first mail.

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by StÃ©phane Ducasse

ok in 12039 I integrated 5 (or just the categorizer) and now I'm integrating the first mail which should be 10 I guess On Jul 7, 2010, at 7:41 PM, Pavel Krivanek wrote: > Hi Stef, > > start with patch in comment 5 (reason in comment 2) and then with > comment 10 up to 19 (code/description) > > Cheers, > -- Pavel > > On Wed, Jul 7, 2010 at 7:05 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi Pavel >> >> where should I start? >> Because the changes you sent by emails are not in the same order than on the list? >> >> I was planning to start with the mail where you just uppercase the category? >> >> Stef >> >> On Jul 6, 2010, at 4:43 PM, Pavel Krivanek wrote: >> >>> Hi, >>> >>> I finished the list of changes for the issue >>> http://code.google.com/p/pharo/issues/detail?id=2635. >>> >>> This issue is the next step after already integrated packages >>> reorganization and the goal is to have compact package base a the >>> small headless PharoKernel image. >>> >>> Most changes are simple naming unification and some classes I skipped >>> because they need deeper refactorings. >>> >>> I will now check the list once more. >>> >>> -- Pavel >>> >>> _______________________________________________ >>> 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

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

Hi Stef, start with patch in comment 5 (reason in comment 2) and then with comment 10 up to 19 (code/description) Cheers, -- Pavel On Wed, Jul 7, 2010 at 7:05 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi Pavel > > where should I start? > Because the changes you sent by emails are not in the same order than on the list? > > I was planning to start with the mail where you just uppercase the category? > > Stef > > On Jul 6, 2010, at 4:43 PM, Pavel Krivanek wrote: > >> Hi, >> >> I finished the list of changes for the issue >> http://code.google.com/p/pharo/issues/detail?id=2635. >> >> This issue is the next step after already integrated packages >> reorganization and the goal is to have compact package base a the >> small headless PharoKernel image. >> >> Most changes are simple naming unification and some classes I skipped >> because they need deeper refactorings. >> >> I will now check the list once more. >> >> -- Pavel >> >> _______________________________________________ >> 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 >

July 7, 2010

Re: [Pharo-project] Fix the other dependencies of asContextWithSender:

by Eliot Miranda

Hi Juan, On Wed, Jul 7, 2010 at 5:24 AM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Eliot, > > There are several other changes in that package that could generate > different behavior. Are they correct? They are: > > BlockClosure >> value > used to call primitive 201, now calls 205 > used to check for zero args, now checks for one (!?) > > BlockClosure >> value: > used to call primitive 202, now calls 205 > > BlockClosure >> value:value: > used to call primitive 203, now calls 205 > > BlockClosure >> value:value:value: > used to call primitive 204, now calls 205 > > Primitive 205 was previously only used for #value:value:value:value:, so I > wonder if this might be a mistake. > Quite right, this is a mistake. I was careless copy-pasting the fix between them. I've committed fixes to trunk. In the VM these primitive numbers all bind to the same primitive so there was no visible effect. Thanks for checking! best Eliot > > Thanks, > Juan Vuletich > > Eliot Miranda wrote: > > >> >> On Tue, Jul 6, 2010 at 12:51 PM, stephane ducasse < >> stephane.ducasse(a)free.fr <mailto:stephane.ducasse@free.fr>> wrote: >> >> Eliot >> >> should this fix be applied to pharo? >> http://code.google.com/p/pharo/issues/detail?id=2655 >> >> >> Yes please. Almost everything I'm likely to put in Compiler, Kernel or >> System on Squeak 4.1 belongs in all dialects using the closure compiler. >> >> >> Is there a dependency? >> >> >> What's happing here is that very old primitive failure code that allowed >> the closure system to run on old VMs without closure support depended on >> BlockClosure>>asContext, which had a bug in it. So the changes reflect the >> bug fix but are enclosed in false ifTrue: [] because they really are >> obsolete, but the code is retained because its useful documentation of how >> the closure primitives should work. I hope this makes sense! >> >> best >> Eliot >> >> >> Stef >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2010

Re: [Pharo-project] feedup of selecting doit or typing " above and below expressions in comments?

by Eliot Miranda

On Tue, Jul 6, 2010 at 10:45 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Again: when I have a method > > > > foo > > self sendMessage: myMessage with: text. > > self sendSecondMessage: myMessage. > > > > B) In Pharo (with OB): I can only check the senders/implementors > > of #foo which is limiting and makes it hard to search > > for s/i of the other messages sent from within the > > method body. > > > > => So I'm limited with Pharo(OB) compared to Standard browser in Core. > > In OB you select (in the list or in the source code) whatever you want > to browse/references/implementors/senders of. There are no additional > pop-ups or questions. > > And please Torsten could you *finally* fix your e-mail client/account? > You are the only one in the whole Smalltalk world that constantly > messes up the mail threading. > +1 :) > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2010