- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by StÃ©phane Ducasse

Yes I think that we should just get better at packaging/loading.... But this package is important so it should be a supported package. Stef > Due to the size issue, I wouldn't include them all by default. > > Maybe we could make some clever set of MC packages that you can load for each font size that you want ? > Or load the spec data from a file/url ? > > You have a point here. Maybe we don't need to put all the families and all the size in the core....just the most used ones. > > Then, in the Dev image we can load all the rest, and the settings to set the Demo Fonts. > > what do you think alain? > > Anyway, all these fonts should be removed in #cleanUpForProduction I think. > > cheers > > mariano > > > I think most people will only need one or two sizes. The fallback should just be miminal. > > Sven > > > _______________________________________________ > 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

Sept. 23, 2010

Re: [Pharo-project] Class comment in OB

by StÃ©phane Ducasse

but can you check in latest 1.2 to be sure. On Sep 22, 2010, at 10:34 PM, Schwab,Wilhelm K wrote: > Stef, > > I noticed it in 1.1, so it's probably old news. >

Sept. 23, 2010

Re: [Pharo-project] ESUG actions (was: Best Spreading Smalltalk Actions)

by StÃ©phane Ducasse

:) This is fun because one of the board member raised the question just before this remark. We are not sure that rebranding is good but so far I like your slogan. And we welcome any smalltalker. The goals of esug are simple (you can see that in the first talk of esug and also the one of serge about future actions) - create energy in the community (via the conf via new user groups) - support open-source development - support business in Smalltalk - push/help teacher teaching Smalltalk - bring open-source and business together (check my last talk at Barcelona - we need strong vendors and strong open-source) ESUG never took into account geographic perspective, we sent books all over the world in the past. And student volunteers came from everywhere :) Stef > > I think ESUG has been an outstanding success for Smalltalk globally and > therefore deserves to be called The Smalltalk Users Group. TSUG. Such a name > change will also give a better impression to Smalltalk and is not untrue. > > All the best, > Aik-Siong Koh > -- > View this message in context: http://forum.world.st/Best-Spreading-Smalltalk-Actions-tp2542307p2551292.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Hannes Hirzel

> > Why can't we have stuff from Sophie back to Squeak/Pharo? > - only the Sophie developers are familiar with the code and they are not > motivated enough to extract it Not necessarily their task..... :-) Writing libraries and reusable components is a different project. > - the license is BSD, so the code can't be included in Pharo/Squeak I googled for BSD MIT license compatibility and found some interesting information see for example http://www.dwheeler.com/essays/floss-license-slide.html the paragraph about BSD in http://producingoss.com/en/license-choosing.html The license might be compatible depending on the "version" of the BSD license. And if not you could extract code and then ask the developers to release it as MIT. MIT and BSD are very close (or the same depending on the version) To summarize: The statement "the license is BSD, so the code can't be included in Pharo/Squeak" is too strong. There might be some problems including code, but they may be solved easily with by writing a few emails.... --Hannes

Sept. 23, 2010

Re: [Pharo-project] ESUG actions (was: Best Spreading Smalltalk Actions)

by Norbert Hartl

On 23.09.2010, at 03:42, askoh wrote: > > I think ESUG has been an outstanding success for Smalltalk globally and > therefore deserves to be called The Smalltalk Users Group. TSUG. Such a name > change will also give a better impression to Smalltalk and is not untrue. > So you would say it is "Everyones Smalltalk User Group" ? :) The abbreviation would than be .... ESUG .. oh, great! Norbert

Sept. 23, 2010

[Pharo-project] osprocess does not work on Squeak 5.8b10

by Tudor Girba

Hi, On the Coq VM from Eliot, invoking OSProcess on a Mac worked well. On Squeak 5.8b10 it crashes by saying: "process accessor module not available". Is there a way to fix this? Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Sept. 23, 2010

Re: [Pharo-project] ESUG actions (was: Best Spreading Smalltalk Actions)

by Tudor Girba

+1 Doru On 23 Sep 2010, at 03:42, askoh wrote: > > I think ESUG has been an outstanding success for Smalltalk globally and > therefore deserves to be called The Smalltalk Users Group. TSUG. Such a name > change will also give a better impression to Smalltalk and is not untrue. > > All the best, > Aik-Siong Koh > -- > View this message in context: http://forum.world.st/Best-Spreading-Smalltalk-Actions-tp2542307p2551292.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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 "Some battles are better lost than fought."

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes. If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it: Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork. What do you mean by "servers"? ConnectionQueue? Levente > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Wednesday, September 22, 2010 9:55 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> the one running the gui > > In that case, you're wrong. The UI Process will be able to run, because > other processes using Sockets will wait on Semaphores and not because of > "time limits". So I just convinced myself (and hopefully you too) about > that using Socket instances will not hang the entire image, just the > Process that uses the Socket. Therefore the SocketPlugin is as good as > possible. > > > Levente > >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Monday, September 20, 2010 10:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. >> >> Where? In the Socket class? And what's the "main thread"? >> >> >> Levente >> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 8:13 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Levente, >>>> >>>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >>> >>> I guess you're using Socket>>#connectTo:port: which uses >>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >>> the default timeout, use #connectTo:port:waitForConnectionFor: or >>> implement your own low level method which waits on semaphore until it's >>> signaled. If you want to terminate the connection attempt, just signal the >>> semaphore yourself, like here: >>> >>> s := Socket newTCP. >>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >>> s semaphore waitTimeoutMSecs: 1000. >>> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >>> >>> And for ConnectionQueue, simply don't use it if you don't like it. It >>> doesn't have to poll at all, AFAIK it's just implemented that way. >>> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >>> don't block the image at all. But correct me if I'm wrong. >>> >>> >>> Levente >>> >>>> >>>> Bill >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Monday, September 20, 2010 7:01 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>> >>>>> Guillermo, >>>>> >>>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>>> >>>> When does a Socket block the image? >>>> >>>> >>>> Levente >>>> >>>>> >>>>> Bill >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>>> >>>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>>> >>>>> Guille >>>>> >>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>>> >>>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>>> where you can add any properties to object >>>>> on the fly, without need of adding a methods or declaring additional >>>>> instance variable in class... >>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>> >>>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>>> hi guys >>>>>>> >>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>>> So we should really have a way to specify silent ui action. >>>>>>> Does anybody have an idea how I could do that? >>>>>>> >>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>>> >>>>>> >>>>>> use morph propertyAt: #borderStyle >>>>>> so you don't have to break your head with it :) >>>>>> >>>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>>> them even don't using any >>>>>> kind of borders. That's makes me wonder if anything like color, border >>>>>> style etc should belong to root classes >>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>>> properties (which is currently sits in morphic >>>>>> extensions are more appropriate storage for them). The only problem is >>>>>> that accessing them is much slower than ivars. >>>>>> >>>>>>> Stef >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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 >

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Levente, Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > the one running the gui In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible. Levente > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Monday, September 20, 2010 10:14 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. > > Where? In the Socket class? And what's the "main thread"? > > > Levente > >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Monday, September 20, 2010 8:13 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Levente, >>> >>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >> >> I guess you're using Socket>>#connectTo:port: which uses >> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >> the default timeout, use #connectTo:port:waitForConnectionFor: or >> implement your own low level method which waits on semaphore until it's >> signaled. If you want to terminate the connection attempt, just signal the >> semaphore yourself, like here: >> >> s := Socket newTCP. >> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >> s semaphore waitTimeoutMSecs: 1000. >> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >> >> And for ConnectionQueue, simply don't use it if you don't like it. It >> doesn't have to poll at all, AFAIK it's just implemented that way. >> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >> don't block the image at all. But correct me if I'm wrong. >> >> >> Levente >> >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 7:01 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Guillermo, >>>> >>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>> >>> When does a Socket block the image? >>> >>> >>> Levente >>> >>>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>> Sent: Sunday, September 19, 2010 10:56 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>> >>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>> >>>> Guille >>>> >>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>> >>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>> where you can add any properties to object >>>> on the fly, without need of adding a methods or declaring additional >>>> instance variable in class... >>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>> hi guys >>>>>> >>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>> So we should really have a way to specify silent ui action. >>>>>> Does anybody have an idea how I could do that? >>>>>> >>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>> >>>>> >>>>> use morph propertyAt: #borderStyle >>>>> so you don't have to break your head with it :) >>>>> >>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>> them even don't using any >>>>> kind of borders. That's makes me wonder if anything like color, border >>>>> style etc should belong to root classes >>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>> properties (which is currently sits in morphic >>>>> extensions are more appropriate storage for them). The only problem is >>>>> that accessing them is much slower than ivars. >>>>> >>>>>> Stef >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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 >>>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] HashedCollection showstopper :(

by Levente Uzonyi

On Wed, 22 Sep 2010, Igor Stasenko wrote: > Unfortunately, when preparing new finalization stuff, i got stuck with > HashedCollection > which is not yet integrated to Pharo. > (Sets with nils also depending on that). > > In Squeak, old WeakRegistry does the trick by setting a #finalizer: to > WeakKeyDictionary instance. > > Levente, can i ask you to give me a bits, (changesets or mcz packages), > which contain HashedCollection refactorings. I could extract them from the Squeak trunk, but it wouldn't be usable for Pharo, because these rely on previous changes done to Sets/Dictionaries in Squeak. Even if those are extracted it's still very hard to add them to Pharo, because there were serveral changes applied to Sets/Dictionaries in Pharo. The most important are: - AndrÃ©s' changes were integrated with additional stuff to change #identityHash -> #basicIdentityHash and #scaledIdentityHash -> #identityHash. - WeakKeyDictionaries were replaced with another implementation (http://code.google.com/p/pharo/issues/detail?id=1565 ) Levente > > Or, we can follow an easier path, just extract the delta from two packages, > which i found in mail archives: > --- > I uploaded two packages which contain this change. To load it evaluate > the following: > > (Installer squeakfoundation project: 'inbox') > install: 'Collections-ul.310.mcz'; > install: 'Collections-ul.311.mcz' > --- > > these are only related to WeakKeyDictionary, made by Levente to > speedup old finalization. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010