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

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

by Johan Brichau

I'm not talking about BlockContext>>fixTemps but about Encoder>>fixTemp: I'm not familiar with this code, but we are not talking about the same method here... On 30 Sep 2009, at 17:01, Torsten Bergmann wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Sept. 30, 2009

Re: [Pharo-project] tabs with icons?

by Tudor Girba

Fantastic! Thanks, Gary. Doru On 30 Sep 2009, at 16:07, Alexandre Bergel wrote: > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

Sept. 30, 2009

[Pharo-project] Question about FFI and constants

by Mariano Martinez Peck

Hi folks: I am calling to the OpenDBX library and this library uses C constants. Suppose something like this: enum odbxerr { ODBX_ERR_SUCCESS, #define ODBX_ERR_SUCCESS ODBX_ERR_SUCCESS ODBX_ERR_BACKEND, #define ODBX_ERR_BACKEND ODBX_ERR_BACKEND ODBX_ERR_NOCAP, #define ODBX_ERR_NOCAP ODBX_ERR_NOCAP ODBX_ERR_PARAM, ......... Then I have a function like this: char* odbx_error( odbx_t* handle, int error ) In that case the int error es the index of the array or I can use the constant. Right now, I am using int from 0 to N. But I would like to invoke calls to that function using Smalltalk Strings that represent C constants. For example, now I have this: OpenDBXUnix>>apiError: handle number: err "long odbx_error(odbx_t*, int)" <cdecl: char* 'odbx_error' (ulong long) module: 'opendbx' > ^self externalCallFailed And I call them this way for example: OpenDBXUnix apiError: handle number: 1. But, I would love to do: OpenDBXUnix apiError: handle number: 'ODBX_ERR_BACKEND'. Of course this fails because it cannot coerce and String to a long. So, that someone know how can I do this (if I can) ? Thanks Mariano

Sept. 30, 2009

[Pharo-project] [update] #10464

by Marcus Denker

10464 ------ Issue 1255: isMorphic left overs in Debugger and ChangesOrganizer Issue 1061: Not all FreeType fonts load properly in Windows Issue 1173: DisplayText have no accessor #form: Issue 1131: 2 Bad comments -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 30, 2009

[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