- Pharo-dev - lists.pharo.org

[Pharo-project] Alien and special objects Array

by Torsten Bergmann

Only the lates core counts ;) In Core #10463 we have: BlockContext>>fixTemps -> the old implementation BlockClosure>>fixTemps -> the empty no-op for compatibility Bye T. -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Sept. 30, 2009

Re: [Pharo-project] Alien and special objects Array

by Mariano Martinez Peck

In my pharo1.0-10451-BETAdev09.09.3 I don't have fixTemp: neither fixTemp The only thing I have is BlockClosure>>fixTemps On Wed, Sep 30, 2009 at 11:43 AM, Johan Brichau <johan.brichau(a)uclouvain.be>wrote: > > On 30 Sep 2009, at 12:04, StÃ©phane Ducasse wrote: > > >>> > >> > >> I thought #fixTemp was for code compatibility but isn't really needed > >> because of real closures? > > > > this is just for backward compatibility normally the method is empty > > on pharo > > In 10462 Encoder>>fixTemp: is not empty > > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2009

Re: [Pharo-project] Alien and special objects Array

by Johan Brichau

On 30 Sep 2009, at 12:04, StÃ©phane Ducasse wrote: >>> >> >> I thought #fixTemp was for code compatibility but isn't really needed >> because of real closures? > > this is just for backward compatibility normally the method is empty > on pharo In 10462 Encoder>>fixTemp: is not empty ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Sept. 30, 2009

Re: [Pharo-project] tabs with icons?

by Alexandre Bergel

I added the snippet here: http://code.google.com/p/pharo/wiki/CodeSnippets Alexandre On 30 Sep 2009, at 05:31, Gary Chambers wrote: > TabGroupMorph/TabSelectorMorph support arbitrary morphs as well as > text > labels. > > An example: > > > |dialog| > dialog := (UITheme builder newPluggableDialogWindow: 'Example tabs') > useDefaultOKButton. > dialog contentMorph: ( > dialog newTabGroup: { > (dialog newRow: {dialog newImage: MenuIcons smallFindIcon. dialog > newLabel: 'Page 1'})-> > dialog newPanel. > 'Page 2'->dialog newPanel}). > dialog model: nil. > World openModal: dialog > > Regards, Gary > > ----- Original Message ----- > From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 29, 2009 10:01 PM > Subject: [Pharo-project] tabs with icons? > > >> Hi, >> >> In Glamour we are using a TabGroupMorph (actually we use a subclass >> that specifies LazyTabs). The question is if there is a way to add an >> icon instead of a string? >> >> Or perhaps is there another solution for a tab control that allows >> for >> icons in the tabs? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "What we can governs what we wish." >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 30, 2009

Re: [Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by StÃ©phane Ducasse

On Sep 30, 2009, at 12:55 PM, Damien Cassou wrote: > On Wed, Sep 30, 2009 at 12:07 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I agree with andreas point. :) > > Hi Andreas, > > this is an interesting discussion and I think I understand your point > : you see the problem of the current API but want to avoid impacting > immediately all the code base. To do that, you propose to introduce > the following 4 new methods: #request:onCancel:, > #request:initialAnswer:onCancel:, > #multiLineRequest:centerAt:initialAnswer:answerHeight:onCancel: and > #requestPassword:onCancel:. Am I correct? > > To me, this is introducing needless complexity. The nil value is here > exactly to indicate the absence of a value. When the first > implementation of the #request: method was created, I have no idea why > they didn't choose to return nil upon cancel. I really have no idea > how users of this library never had the need to distinguish an empty > answer from a cancel. I can see so many examples where it is crucial > to distinguish. Do you agree with me that the current API is broken? > I'm not talking about adding a feature, I'm talking about fixing a > bug. yes it is a bug. > I see two options: > > - yours is to complicate the API in order to keep backward > compatibility with the code base and thus avoiding bugs. > - mine is to fix the problem once and for all. Yes, it also means bugs > will appear during the period of fixing which can take some time the point andreas is to deprecate request:* so that when you see where to change instead of getting bitten. Stef > > Please let me comment on your reasons: > > On Tue, Sep 29, 2009 at 6:31 PM, <codesite-noreply(a)google.com> wrote: >> 1) It is subtle breakage that creates a major and completely >> unnecessary >> PITA for anyone who needs to write UIManager code that works across >> Pharo, Squeak, >> Croquet etc. > > I do not agree. Squeak doesn't have to change its implementation of > #request:. Clients can just test for the nil value without wondering > if it is going to be returned (in Pharo) or not (in Squeak). > > This has an immediate consequence : you can apply the two changesets > which replace #isEmpty by #isEmptyOrNil after each call to #request:. > You don't have to change #request: for this. > > >> 2) It weakens the framework. Toolbuilder is based on having the same >> semantics across >> platforms and UIs and this change means that the entire family of >> input >> requests is >> no longer reliable as it will behave differently between Pharo and >> anything >> else in >> existence. > > > To me, UIManager is broken. I don't understand why fixing it would > weaken anything. > Moreover, I'm quite sure all UIs can perfectly distinguish between the > 2 buttons ok and cancel. For example, the Polymorph library returns > nil by default and nil was translated to the empty string in > PSUIManager to follow the behavior of UIManager. > >> 3) The alternatives are every bit as good. The protocol >> complication of >> using >> onCancel: are minimal to non-existent (since in many cases the >> ability to >> provide a >> cancel action is what you'll want anyway) and even if that were the >> case, a >> new >> protocol that over time can be supported by other UIs would solve >> that >> completely and >> in a proper evolutionary way. > > I agree that #onCancel: can be interesting on its own. However, I see > it more as a new interesting feature whereas I'm talking about bug > fixing. > > >> 4) With the choice you've made, you need to touch every user of >> that method >> anyway. > > True > >> If that's true, there is no penalty for changing the protocol > > here I don't agree. Changing the protocol means adding complexity. My > solution does not complicate the protocol, it just fixes its meaning. > >> and it will make >> migration easier since you can simply browse for all senders of >> #request: >> and find >> those that haven't been converted yet. > > I agree. > >> Please do consider these issues carefully. I really don't think >> there is any >> advantage for you or your users by introducing such a subtle >> breakage. > > I can see pros and cons of each approach. Yours is more pragmatic I > think while mine is more long-term. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 30, 2009

Re: [Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by Damien Cassou

On Wed, Sep 30, 2009 at 12:07 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I agree with andreas point. :) Hi Andreas, this is an interesting discussion and I think I understand your point : you see the problem of the current API but want to avoid impacting immediately all the code base. To do that, you propose to introduce the following 4 new methods: #request:onCancel:, #request:initialAnswer:onCancel:, #multiLineRequest:centerAt:initialAnswer:answerHeight:onCancel: and #requestPassword:onCancel:. Am I correct? To me, this is introducing needless complexity. The nil value is here exactly to indicate the absence of a value. When the first implementation of the #request: method was created, I have no idea why they didn't choose to return nil upon cancel. I really have no idea how users of this library never had the need to distinguish an empty answer from a cancel. I can see so many examples where it is crucial to distinguish. Do you agree with me that the current API is broken? I'm not talking about adding a feature, I'm talking about fixing a bug. I see two options: - yours is to complicate the API in order to keep backward compatibility with the code base and thus avoiding bugs. - mine is to fix the problem once and for all. Yes, it also means bugs will appear during the period of fixing which can take some time Please let me comment on your reasons: On Tue, Sep 29, 2009 at 6:31 PM, <codesite-noreply(a)google.com> wrote: > 1) It is subtle breakage that creates a major and completely unnecessary > PITA for anyone who needs to write UIManager code that works across Pharo, Squeak, > Croquet etc. I do not agree. Squeak doesn't have to change its implementation of #request:. Clients can just test for the nil value without wondering if it is going to be returned (in Pharo) or not (in Squeak). This has an immediate consequence : you can apply the two changesets which replace #isEmpty by #isEmptyOrNil after each call to #request:. You don't have to change #request: for this. > 2) It weakens the framework. Toolbuilder is based on having the same > semantics across > platforms and UIs and this change means that the entire family of input > requests is > no longer reliable as it will behave differently between Pharo and anything > else in > existence. To me, UIManager is broken. I don't understand why fixing it would weaken anything. Moreover, I'm quite sure all UIs can perfectly distinguish between the 2 buttons ok and cancel. For example, the Polymorph library returns nil by default and nil was translated to the empty string in PSUIManager to follow the behavior of UIManager. > 3) The alternatives are every bit as good. The protocol complication of > using > onCancel: are minimal to non-existent (since in many cases the ability to > provide a > cancel action is what you'll want anyway) and even if that were the case, a > new > protocol that over time can be supported by other UIs would solve that > completely and > in a proper evolutionary way. I agree that #onCancel: can be interesting on its own. However, I see it more as a new interesting feature whereas I'm talking about bug fixing. > 4) With the choice you've made, you need to touch every user of that method > anyway. True > If that's true, there is no penalty for changing the protocol here I don't agree. Changing the protocol means adding complexity. My solution does not complicate the protocol, it just fixes its meaning. > and it will make > migration easier since you can simply browse for all senders of #request: > and find > those that haven't been converted yet. I agree. > Please do consider these issues carefully. I really don't think there is any > advantage for you or your users by introducing such a subtle breakage. I can see pros and cons of each approach. Yours is more pragmatic I think while mine is more long-term. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 30, 2009

Re: [Pharo-project] Assignment operator in new core packages

by Lukas Renggli

We should actually run them every night and post the results in the list :-) Lukas 2009/9/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > lukas implemented a smallLint rule that convert all the code. We run > it in the past and we should run it again. > > stef > > On Sep 30, 2009, at 11:04 AM, Peter Hugosson-Miller wrote: > >> Isn't there a test case for this, or similar coding customs? In my >> day job we have some, and they are most useful for detecting misses >> like that. >> >> If anyone thinks it's a good idea I could write one, then this kind >> of problem shouldn't turn up again the future. >> >> -- >> Cheers, >> Peter >> >> 2009/9/30 Torsten Bergmann <astares(a)gmx.de> >> Classes like "SHA1" (now included in core) use _ again instead >> of := >> >> Shouldnt we clean up such packages? >> >> Thx >> T. >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 30, 2009

[Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by StÃ©phane Ducasse

I agree with andreas point. :) Begin forwarded message: > From: codesite-noreply(a)google.com > Date: September 29, 2009 6:31:41 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Issue 1129 in pharo: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > > > Comment #22 on issue 1129 by andreas.raab: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > http://code.google.com/p/pharo/issues/detail?id=1129 > > I'll give it one last shot: From my perspective, the problem is not > how difficult it > is to fix it, the problem is that there is a change in semantics of > a widely deployed > method that affects every single place that uses it. I could follow > your reasoning > more easily if the situation where such that for 80% of the users > everything stays > the same but the change you are proposing necessitates that every > single place that > uses these methods needs to be changed. And not being able to tell > whether a > particular place has been fixed or not is just bad engineering since > you are making > it strictly harder for your users to determine whether they still > need to do > something for addressing this issue or not. That's what deprecations > are for - > telling users that there is something they need to take care of. > > I think that the change you are proposing is a decidedly bad choice > and urge you to > reconsider for the following reasons: > > 1) It is subtle breakage that creates a major and completely > unnecessary PITA for > anyone who needs to write UIManager code that works across Pharo, > Squeak, Croquet etc. > > 2) It weakens the framework. Toolbuilder is based on having the same > semantics across > platforms and UIs and this change means that the entire family of > input requests is > no longer reliable as it will behave differently between Pharo and > anything else in > existence. > > 3) The alternatives are every bit as good. The protocol complication > of using > onCancel: are minimal to non-existent (since in many cases the > ability to provide a > cancel action is what you'll want anyway) and even if that were the > case, a new > protocol that over time can be supported by other UIs would solve > that completely and > in a proper evolutionary way. > > 4) With the choice you've made, you need to touch every user of that > method anyway. > If that's true, there is no penalty for changing the protocol and it > will make > migration easier since you can simply browse for all senders of > #request: and find > those that haven't been converted yet. > > Please do consider these issues carefully. I really don't think > there is any > advantage for you or your users by introducing such a subtle breakage. > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

Sept. 30, 2009

Re: [Pharo-project] Assignment operator in new core packages

by StÃ©phane Ducasse

lukas implemented a smallLint rule that convert all the code. We run it in the past and we should run it again. stef On Sep 30, 2009, at 11:04 AM, Peter Hugosson-Miller wrote: > Isn't there a test case for this, or similar coding customs? In my > day job we have some, and they are most useful for detecting misses > like that. > > If anyone thinks it's a good idea I could write one, then this kind > of problem shouldn't turn up again the future. > > -- > Cheers, > Peter > > 2009/9/30 Torsten Bergmann <astares(a)gmx.de> > Classes like "SHA1" (now included in core) use _ again instead > of := > > Shouldnt we clean up such packages? > > Thx > T. > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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. 30, 2009

Re: [Pharo-project] Alien and special objects Array

by StÃ©phane Ducasse

>> > > I thought #fixTemp was for code compatibility but isn't really needed > because of real closures? this is just for backward compatibility normally the method is empty on pharo

Sept. 30, 2009