[Pharo-project] Quickly browse through large repositories
When clicking on a package in a large repository the browser usually takes ages to refresh. The following fix in the inbox fixes this problem. Lukas Name: MonticelloGUI-lr.5 Author: lr Time: 30 September 2009, 9:04:31 am UUID: fd2ef6fb-d926-49a6-a5d6-557e4218576b Ancestors: MonticelloGUI-stephane_ducasse.4 - quickly browse through large repositories -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Alien & Squeak FFI issues on Snow Leopard.
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 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 > > ^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 > > ^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 Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Assignment operator in new core packages
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Assignment operator in new core packages
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 > 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Quickly browse through large repositories
http://code.google.com/p/pharo/issues/detail?id=1256 On Wed, Sep 30, 2009 at 9:05 AM, Lukas Renggli wrote: > When clicking on a package in a large repository the browser usually > takes ages to refresh. The following fix in the inbox fixes this > problem. > > Lukas > > Name: MonticelloGUI-lr.5 > Author: lr > Time: 30 September 2009, 9:04:31 am > UUID: fd2ef6fb-d926-49a6-a5d6-557e4218576b > Ancestors: MonticelloGUI-stephane_ducasse.4 > > - quickly browse through large repositories > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] tabs with icons?
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"
To: "Pharo Development"
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@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Alien and special objects Array
>> > > 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Assignment operator in new core packages
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 > 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel
I agree with andreas point. :) Begin forwarded message: > From: codesite-nore...@google.com > Date: September 29, 2009 6:31:41 PM GMT+02:00 > To: stephane.duca...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Assignment operator in new core packages
We should actually run them every night and post the results in the list :-) Lukas 2009/9/30 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 >> 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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel
On Wed, Sep 30, 2009 at 12:07 PM, Stéphane Ducasse 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, 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel
On Sep 30, 2009, at 12:55 PM, Damien Cassou wrote: > On Wed, Sep 30, 2009 at 12:07 PM, Stéphane Ducasse > 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, 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] tabs with icons?
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"
> To: "Pharo Development"
> 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@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@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@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Alien and special objects Array
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.bric...@uclouvain.be ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Alien and special objects Array
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 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.bric...@uclouvain.be > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Alien and special objects Array
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update] #10464
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Question about FFI and constants
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)"
^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@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] tabs with icons?
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"
>> To: "Pharo Development"
>> 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@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@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@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."
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Alien and special objects Array
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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Johan Brichau johan.bric...@uclouvain.be ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: Alien & Squeak FFI issues on Snow Leopard.
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. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] tabs with icons?
Is possible add and remove tabs dinamically?
Exists a method for add tabs ( #labelsAndPages or something similar ) , but
not is possible add a tab, and later remove by key, for example, without
remove alls with that method?
Regards, and excuse me if is a stupid question :)
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"
> To: "Pharo Development"
> 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@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
--
View this message in context:
http://n2.nabble.com/tabs-with-icons-tp3738940p378.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Alien and special objects Array
I was tlakling about BlockClosure (but I'm certainly wrong) On Sep 30, 2009, at 4:43 PM, Johan Brichau 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.bric...@uclouvain.be > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [squeak-dev] Re: Alien & Squeak FFI issues on Snow Leopard.
Begin forwarded message: From: Eliot Miranda Date: September 30, 2009 6:04:22 PM GMT+02:00 To: The general-purpose Squeak developers list >, vm-dev-requ...@lists.squeakfoundation.org Cc: john...@smalltalkconsulting.com, Pharo-project@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 > 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 > 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 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 > >^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 >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. McIntoshTwitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > = = == > > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] tabs with icons?
check if it makes sense and submit in the UITheme example like methods.
This is important to have examples inside the image.
stef
On Sep 30, 2009, at 4:07 PM, 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"
>> To: "Pharo Development"
>> 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@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@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@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] tabs with icons?
There are no stupid question!
Just if you ask 5 times the same. But never before this is that people
did not answer well
Stef
On Sep 30, 2009, at 8:23 PM, nullPointer wrote:
>
>
> Is possible add and remove tabs dinamically?
>
> Exists a method for add tabs ( #labelsAndPages or something
> similar ) , but
> not is possible add a tab, and later remove by key, for example,
> without
> remove alls with that method?
>
> Regards, and excuse me if is a stupid question :)
>
>
> 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"
>> To: "Pharo Development"
>> 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@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>
> --
> View this message in context:
> http://n2.nabble.com/tabs-with-icons-tp3738940p378.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharo ESUG Video
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] StrikeFont Accujen in Pharo
Hallo, I'm porting a Squeak-Project to Pharo and I really need the "Accujen" StrikeFont with size 9. I know: those bitmap fonts look worse than the great FreeType fonts. But for my special case I need a very small/narrow but still readable font and there's nothing better than Accujen. 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. Thanks for any help, if possible! Jochen ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Question about FFI and constants
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Question about FFI and constants
Another alternative to what Andreas suggested is to reify in
meaningful messages the constants, see senders of
YAZODRFFILibrary>>odrCreate: in the Z3950 project at SqueakSource.
Cheers,
Hernán
2009/9/30 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)"
>
> ^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@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [OT] Pharo logo openInWorld
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
