- Pharo-dev - lists.pharo.org

[Pharo-project] generic completion
by Tudor Girba Oct. 2, 2009

Oct. 2, 2009

Hi, I would need a generic completion mechanism that can be used for any text and that I can configure. I took a brief look at the EC model, but it looks like it is geared towards code. Does anyone have an example for using EC, or similar, to handle generic completion? Cheers, Doru -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

2 1

[Pharo-project] New inspector
by Schwab,Wilhelm K Oct. 2, 2009

Oct. 2, 2009

Hello all, I would rather not have to rain on the parade, but how do I disable the new inspector? Bill

2 2

[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] [OT] Pharo logo openInWorld
by Torsten Bergmann Oct. 1, 2009

Oct. 1, 2009

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

1 0

[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

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