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

[Pharo-project] test pragmas
by Tudor Girba Oct. 1, 2009

Oct. 1, 2009

Hi, How can I mark a test as being an expected failure? Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

5 5

[Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel
by StÃ©phane Ducasse Oct. 1, 2009

Oct. 1, 2009

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

5 8

[Pharo-project] Pharo ESUG Video
by Torsten Bergmann Oct. 1, 2009

Oct. 1, 2009

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

4 5

[Pharo-project] Question about FFI and constants
by Mariano Martinez Peck Oct. 1, 2009

Oct. 1, 2009

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

3 2

[Pharo-project] Question about FFI and constants
by Torsten Bergmann Sept. 30, 2009

Sept. 30, 2009

Maybe you will use PoolDictionaries. See pool/class "FFIConstants" in FFI package for example. Check the class side #initialize method where the values are assigned. SharedPool subclass: #FFIConstants ... It is used in ExternalFunction for example: ExternalObject subclass: #ExternalFunction instanceVariableNames: 'flags argTypes' classVariableNames: 'FFIErrorMessages' poolDictionaries: 'FFIConstants' category: 'FFI-Kernel' Bye Torsten BTW: Would be nice if Pharo will support scoping for pools later, something in the like of Win32OLEConstants::S_OK Win32Constants::S_OK -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

1 0

[Pharo-project] tabs with icons?
by Tudor Girba Sept. 30, 2009

Sept. 30, 2009

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."

5 6

[Pharo-project] Fwd: [squeak-dev] Re: Alien & Squeak FFI issues on Snow Leopard.
by StÃ©phane Ducasse Sept. 30, 2009

Sept. 30, 2009

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: September 30, 2009 6:04:22 PM GMT+02:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > >, vm-dev-request(a)lists.squeakfoundation.org > Cc: johnmci(a)smalltalkconsulting.com, Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [squeak-dev] Re: [Pharo-project] Alien & Squeak FFI > issues on Snow Leopard. > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > Craig Latta found a simple work-around which is to set the VM's > Info.plist variable "SqueakPluginsBuiltInOrLocalOnly" to false, so > that libraries are found on Snow Leopard. Up until now things have > been being found through vagaries if the Mac OS X dlopen call which > would, I think, search the paths in an executable used to find > dlls. i.e. prior to Snow Leopard if you tried to run something in > libSystem.B.dylib and you traced the logic in > sqMacUnixExternalPrims.c you'd find that dlopen was "finding" > libSystem.B.dylib in VM.app/Contents/Resources, even though it is > not there. > > Personally I think that sqMacUnixExternalPrims.c is ripe for a > rewrite. It is torturously complex. But Craig's workaround works > for us and takes the pressure off. > > P.S. I'm not on the Pharo list. Can someone forward this for me? > > On Wed, Sep 30, 2009 at 12:52 AM, Andrey Larionov <anlarionov(a)gmail.com > > wrote: > I think it's related http://forums.newspeaklanguage.org/index.php?topic=88.0 > > On Wed, Sep 30, 2009 at 06:13, John M McIntosh > <johnmci(a)smalltalkconsulting.com> wrote: > > Someone finally managed to fire up a Sophie app http://www.opensophie.org/ > > on Snow Leopard and immediately found an issue that also affects > > Squeak users who do fascinating things with FFI > > The innocent FFI call was > > > > apifstat: afileNo statBuffer: buffer > > <cdecl: long 'fstat' (long MacStat* ) module: 'libc.dylib'> > > ^self externalCallFailed > > > > Now it seems BEFORE Snow Leopard *somehow* the Squeak external > > primitive call api which is part of the VM to assist in loading > > plugins or finding function entry points in executable binaries or > > libraries would > > return the entry point for fstat by *somehow* finding libc.dylib > which > > is via /usr/lib/libc.dylib -> libSystem.dylib -> libSystem.B.dylib > > > > Interestingly this is found implicitly since the mac carbon vm > lookup > > logic never looks in /usr/lib/ > > > > Now in Snow Leopard it seems they do less implicit searching, > perhaps > > a security concern? Then it fails. > > > > In the past the Unix VM would search a hundred(sic) more places, > but I > > understand less today, but it might still work? Maybe /usr/lib is in > > the hit list? > > > > This issue also applies to Alien because it calls back to the VM for > > it to find the module and function entry point. > > > > Since I have received a request to ensure that doing an explicit > full > > path should be allowed in the squeak carbon macintosh vm. > > Then a change would be: > > > > apifstat: afileNo statBuffer: buffer > > <cdecl: long 'fstat' (long MacStat* ) module: '/usr/lib/ > libc.dylib'> > > ^self externalCallFailed > > > > I'll look at doing this shortly. > > > > However the workaround is to go to Sophie.app/Contents/Resources > > and do a ln -s /usr/lib/libc.dylib libc.dylib > > to create a symbolic link in the Resources directory for libc.dylib > > since we do explicitly look for libc.dylib in the Resources > directory. > > > > Obviously if you have a FFI call like above where you are calling a > > system library Oracle? for example. > > You might find it no longer works with Snow Leopard on the > Macintosh, > > so you should check. > > > > > > -- > > = > > = > > = > > > = > = > ====================================================================== > > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > > squeaker68882 > > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > > = > > = > > = > > > = > = > ====================================================================== > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > >

1 0

[Pharo-project] Alien and special objects Array
by Torsten Bergmann Sept. 30, 2009

Sept. 30, 2009

>Could you tell us if you get that error? And more info on when it >crashes? It's not a crash in the special objects array (which typically results in closing the image). It crashes with "TempVariableNode(Object)>>doesNotUnderstand: #code:" while trying to compile 'Ccalloc: byteSize "<Integer> ^<Integer>" <primitive: ''primCalloc'' error: errorCode module: ''IA32ABI''> ^self primitiveFailed' The prereq's package (which I guess allows new synatx) is loaded. Just try it in latest #10462. with ScriptLoader loadLatestPackage: 'AlienLoader' from: 'http://www.squeaksource.com/Alien'. (Smalltalk at: #AlienLoader) load Bye T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

5 7

Re: [Pharo-project] [squeak-dev] Re: Alien & Squeak FFI issues on Snow Leopard.
by John M McIntosh Sept. 30, 2009

Sept. 30, 2009

The reason for the SqueakPluginsBuiltInOrLocalOnly was to prevent the VM from looking in about 100 places for a plugin before deciding to use the one built into the VM this saved several 10 of ms in launch time. At the time there was also a transition period between PowerPC and Universal plugins, the historical algorithm would try to load powerpc plugins lying loose in a developer's various libraries, versus using the newly complied ones supplied by the VM. So setting SqueakPluginsBuiltInOrLocalOnly to NO might lead to other interesting issues, versus for example doing a 'ln -s /usr/lib/ libc.dylib libc.dylib in the VM's resource folder. I will look at changing sqMacUnixExternalPrims.c to allow absolute paths, and also consider the changes Ian made lately to reduce the amount of searching that the original UnixExternalPrims.c did. On 2009-09-30, at 9:04 AM, Eliot Miranda wrote: > Craig Latta found a simple work-around which is to set the VM's > Info.plist variable "SqueakPluginsBuiltInOrLocalOnly" to false, so > that libraries are found on Snow Leopard. Up until now things have > been being found through vagaries if the Mac OS X dlopen call which > would, I think, search the paths in an executable used to find > dlls. i.e. prior to Snow Leopard if you tried to run something in > libSystem.B.dylib and you traced the logic in > sqMacUnixExternalPrims.c you'd find that dlopen was "finding" > libSystem.B.dylib in VM.app/Contents/Resources, even though it is > not there. > > Personally I think that sqMacUnixExternalPrims.c is ripe for a > rewrite. It is torturously complex. But Craig's workaround works > for us and takes the pressure off. > > P.S. I'm not on the Pharo list. Can someone forward this for me? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

[Pharo-project] Alien and special objects Array
by Torsten Bergmann Sept. 30, 2009

Sept. 30, 2009

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

2 1