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

Re: [Pharo-project] Pharo ESUG Video

by StÃ©phane Ducasse

I'm not sure that this is wise to put this video on the webpage. Stef On Sep 30, 2009, at 11:14 PM, Torsten Bergmann wrote: > http://mimer.msc.se/esug/M2U00055.mp4 > > includes Stef's presentation on Pharo from ESUG. > > Anyone able to link it on the webpage. > > 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

Oct. 1, 2009

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

by Henrik Johansen

On Oct 1, 2009, at 5:23 47PM, Miguel Enrique CobÃ¡ Martinez wrote: > +1 to fix it one and for all. > > Remember, from the pharo-project.org page: > > "We want to create a better Smalltalk and be free to enhance it > without > fear of backwards compatibility to Squeak." > > This discussion is trying to achieve backwards compatibility even if > that means not fixing this bug. > > So, lets fix it and as the packages are going ported to Pharo, make > the > necessary changes to them. When a lot of packages (if any) are using > the > new semantics, the Squeak guys might consider to use the Pharo fix. > > No more discussion using the backwards compatibility argument. > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project To quote myself: "I agree, the issue is whether the default behaviour of handling empty input and cancel the same way is what's broken, or the fact that no way of handling such a case at all is provided. Considering the amount of times I've had to add ifEmpty: clauses doing the same as ifNil: to request: call return values in VW (which returns nil), I'd say the latter." Recognizing there is a bug doesn't mean that there is just one possible solution, or that the one which is not backwards compatible is necessarily the best. Cheers, Henry

Oct. 1, 2009

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

by Miguel Enrique CobÃ¡ Martinez

+1 to fix it one and for all. Remember, from the pharo-project.org page: "We want to create a better Smalltalk and be free to enhance it without fear of backwards compatibility to Squeak." This discussion is trying to achieve backwards compatibility even if that means not fixing this bug. So, lets fix it and as the packages are going ported to Pharo, make the necessary changes to them. When a lot of packages (if any) are using the new semantics, the Squeak guys might consider to use the Pharo fix. No more discussion using the backwards compatibility argument. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 1, 2009

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

by Henrik Johansen

On Sep 30, 2009, at 1:27 47PM, StÃ©phane Ducasse wrote: > > On Sep 30, 2009, at 12:55 PM, Damien Cassou wrote: > >> >> 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 Deprecation sounds like a bad solution in this case to me. It's useful when functionality has either been - Moved - Removed - Changed in a way that results in a silent failure In this case, either: -It's changed in both Squeak and Pharo, and you get MNU's everywhere for the old ifEmpty. None of the 3 cases above is satisfied, so I don't really see the benefit of deprecation here. You still have to change your app, replacing all calls to the now deprecated to the new one, plus make sure the code at each spot handles the nil case. - It's deprecated just one place, leading to extra porting overhead if you have to change both the method name and the answer handling. (plus the other dialect would have to add a deprecated ask: method telling you how to conform to semantics). > >> >> 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. That's false. I suspect you only considered the case of porting Squeak code to Pharo (which doesn't fail silently anyways, which is the major PITA, you get an UndefinedObject >> MNU). Porting code written in Pharo, f.ex. using ifNotNil: to handle an action where empty input is allowed, WILL fail silently in Squeak if request:* is not modified, resulting in a cancel action replacing the previous value with an empty string. >> >> >>> 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 agree, the issue is whether the default behaviour of handling empty input and cancel the same way is what's broken, or the fact that no way of handling such a case at all is provided. Considering the amount of times I've had to add ifEmpty: clauses doing the same as ifNil: to request: call return values in VW (which returns nil), I'd say the latter. >> >> 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. Andreas has a good point, changing the current behaviour will either: a) Lead to a lot of changes (albeit simple ones) for everyone if adopted everywhere. b) Lead to subtle errors when porting between dialects if adopted just in one place. The fact it's been the way it is without getting changed so far, and my anecdotal experiences in VW implies to me that the case where you want to distinguish between an empty response and a cancel is the exception rather than the rule. Therefore, I support the option of adding explicit onCancel: aBlock versions, and use those in the cases it's needed, rather than changing the underlying behaviour, leading to either situation a) or b) above. Cheers, Henry

Oct. 1, 2009

Re: [Pharo-project] StrikeFont Accujen in Pharo

by Jochen

Damien Cassou schrieb: > 2009/9/30 Jochen <ich(a)nichtich.com>: > >> So my question is, if it's possible to get the Accujen into Pharo. The >> StrikeFont class still exists but it seams like all fonts but DejaVu are >> missing now. >> > > What happens when you browse the list of available fonts (World > menu->System->Preferences->System fonts->default text fonts) ? > > In this list the available fonts are all TrueType fonts in my System (Windows) and the fonts in the "Fonts" subdirectory of Pharo (that are all versions of DejaVU*.ttf). Also there's the font "Accuny" that is afaik a StrikeFont. But unfortunatly no "Accujen".

Oct. 1, 2009

Re: [Pharo-project] [squeak-dev] Question about FFI and constants

by Fernando olivero

Hi Mariano, what about the rule in Kent Beck Smalltalk best practices book, put magic numbers into a method. OpenDBUnix>>odbxErrBackend. ^ 1 OpenDBUnix apiError: handle number: OpenDBUnix odbxErrBackend. Or i you prefer also can code a mapping method like this one ( although the first solution is much more elegant ) OpenDBUnix>>errorFromString: 'ODBX_ERR_BACKEND' OpenDBUnix apiError: handle number: ( OpenDBUnix errorFromString: 'ODBX_ERR_BACKEND') > 2009/9/30 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> 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 >> >> >> >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2009

Re: [Pharo-project] StrikeFont Accujen in Pharo

by Damien Cassou

2009/9/30 Jochen <ich(a)nichtich.com>: > So my question is, if it's possible to get the Accujen into Pharo. The > StrikeFont class still exists but it seams like all fonts but DejaVu are > missing now. What happens when you browse the list of available fonts (World menu->System->Preferences->System fonts->default text fonts) ? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Oct. 1, 2009

[Pharo-project] [OT] Pharo logo openInWorld

by Torsten Bergmann

see http://images.google.de/images?q=Cape+Hatteras+Lighthouse ;) -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Oct. 1, 2009