- Pharo-dev - lists.pharo.org

[Pharo-project] changing the class of an existing object to a subclass

by Ben Coman

greetings all, I am using ConfigurationOfODBC in Pharo 1.3. I have had success with getting an ODBCResultTable(OrderedCollection) containing ODBCRow containing about 30 fields. By default the fields are accessed by "row at: #fieldName" but I wanted to add some convenience methods to instead go "row fieldName." My searching and experimentation led me to subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on each ODBCRow to convert it to the subclass. This was to avoid having to having to understand and change any of the ConfigurationOfODBC code. I had tried copyFrom: but some of the instance variables inherited from ODBCRow were not filled in, generating exceptions in some of the inherited methods. I had also considered "become:" but that didn't seem appropriate. Using "adoptInstance:" worked fine until I added a new instance variable to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = #'bad receiver'. The "adoptInstance:" method comment says it follows the same rules as "primitiveChangeClassTo:" (yet note that "primitiveChangeClassTo:" never worked) The "primitiveChangeClassTo:" method comment says "The primitive will fail in most cases that you think might work [...] The facility is really provided for certain, very specific applications (mostly related to classes changing shape) and not for casual use" so I wondered if there was another way to achieve this. The full code is hopefully not too long to include for reference below. The use of "adoptInstance:" in the last section listed. ------ ODBCRow subclass: #EAPPackage instanceVariableNames: 'parent' "note adoptInstance works without this instance variable, and not with" classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackage >> name ^ self at: #Name ------ ODBCResultTable subclass: #EAPPackages instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackages class >> newFromConnection: connection | packages parent | packages := (connection query: 'select * from t_package;') execute asTable. self adoptInstance: packages. packages do: [ :row | EAPPackage adoptInstance: row. ]. ^packages. ------ In a Workspace I successfully evaluate the following three lines without : connection := ODBCConnection dsn: 'CIM' user: '' password: ''. packages := EAPPackages newFromConnection: connection. connection close. ------ I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One alternative I've considered is to somehow pass through a custom SomeClass in a variable to replace the hard reference to ODBCRow - but I don't want to chase back all the cascading call references. Is there another way to change an existing object to another class, such that it can be specialised with both additional methods and instance variables? I would appreciate any pointers. regards, Ben

Dec. 28, 2011

[Pharo-project] Pharo Launcher app

by Fernando Olivero

Hi, i created an app for launching Pharo, which remembers the last opened vm+image . Maybe some of you find it useful (for MacOS X) Fernando pd:Working on a version with arguments entry also.

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Schwab,Wilhelm K

FWIW, I see neither on Ubuntu lucid, 32 bit. There is not even a /lib32. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Tuesday, December 27, 2011 4:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting. and is there a /lib32/tls? (I hope not). Does anyone have a linux system with either of the following? /lib32/tls /lib64/tls TIA Eliot On Tue, Dec 27, 2011 at 1:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>> wrote: Hi Phillipe, On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <kustos(a)gmx.net<mailto:kustos@gmx.net>> wrote: On 27.12.2011 19:18, Eliot Miranda wrote: Hi Phillipe, what does ldd answer for the squeak vm? $ldd coglinux/lib/squeak/4.0-2515/squeak linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) libm.so.6 => /lib32/libm.so.6 (0xf7687000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) libc.so.6 => /lib32/libc.so.6 (0xf750c000) /lib/ld-linux.so.2 (0xf76fe000) It's a 64bit system with 32bit compatibility libraries (only for cog, everything else is 64bit). Ah, ok. Makes sense. So I expect the relevant code needs to read # On some old linuxes there is a /lib/tls thread-local-storage version of the C # library which the VM may use and if so should take precedence over /lib libc. case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; /lib/libc*) SVMLLP="/lib:/usr/lib";; /lib32/libc*) SVMLLP="/lib32:/usr/lib32";; *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; exit 1 esac Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of /usr/lib? Cheers Philippe -- best, Eliot -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] Programmatic creation of classes Re: [ANN][Beta Release] DBXTools - Magritte Scaffolding - Phoseydon

by StÃ©phane Ducasse

if you compileSilently instead of compile the changes are not logged and this improves the time. Stef On Dec 27, 2011, at 6:15 PM, Guillermo Polito wrote: > DBXMagritteClassBuilderVisitor>>buildAccessorForAttribute: attribute inClass: aClass > could you give me a pointer to read up on what the curly-brace-numbers are? > > The curly braces in the string are just for string formatting, the second one is a dynamic array: > > 'hello {1}! How's your {2}?' format: { 'Ben' 'metaprogramming' }. > > What that method does is creating the accessors, ending up in a final string like this for the mutator: > > 'someAccessor: aParam > instVar := aParam' > > > btw, Can you advise how is the compiling activated? If you had about 800 classes that need to be created, would temporarily turning off the compile assist the program execution time significantly? > > I cannot give a good answer here. Maybe someone has better knowledge on the compiler and it's settings. Maybe creating a giant script with all the class creations is faster than 800 scripts. Or Maybe not significantly :P. Maybe disabling the UI notification enhances it a little bit. > > I've never worried about it a lot :P. > > Cheers, > Guille

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Eliot Miranda

and is there a /lib32/tls? (I hope not). Does anyone have a linux system with either of the following? /lib32/tls /lib64/tls TIA Eliot On Tue, Dec 27, 2011 at 1:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Phillipe, > > On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <kustos(a)gmx.net>wrote: > >> On 27.12.2011 19:18, Eliot Miranda wrote: >> >>> Hi Phillipe, >>> >>> what does ldd answer for the squeak vm? >>> >> >> $ldd coglinux/lib/squeak/4.0-2515/**squeak >> linux-gate.so.1 => (0xffffe000) >> libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) >> libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) >> libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) >> libm.so.6 => /lib32/libm.so.6 (0xf7687000) >> libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) >> libc.so.6 => /lib32/libc.so.6 (0xf750c000) >> /lib/ld-linux.so.2 (0xf76fe000) >> >> It's a 64bit system with 32bit compatibility libraries (only for cog, >> everything else is 64bit). >> > > Ah, ok. Makes sense. So I expect the relevant code needs to read > > # On some old linuxes there is a /lib/tls thread-local-storage version of > the C > # library which the VM may use and if so should take precedence over /lib > libc. > case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in > /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; > /lib/libc*) SVMLLP="/lib:/usr/lib";; > /lib32/libc*) SVMLLP="/lib32:/usr/lib32";; > *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; > exit 1 > esac > > Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of > /usr/lib? > > > >> Cheers >> Philippe >> >> >> > > > -- > best, > Eliot > > -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Eliot Miranda

Hi Phillipe, On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 27.12.2011 19:18, Eliot Miranda wrote: > >> Hi Phillipe, >> >> what does ldd answer for the squeak vm? >> > > $ldd coglinux/lib/squeak/4.0-2515/**squeak > linux-gate.so.1 => (0xffffe000) > libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) > libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) > libm.so.6 => /lib32/libm.so.6 (0xf7687000) > libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) > libc.so.6 => /lib32/libc.so.6 (0xf750c000) > /lib/ld-linux.so.2 (0xf76fe000) > > It's a 64bit system with 32bit compatibility libraries (only for cog, > everything else is 64bit). > Ah, ok. Makes sense. So I expect the relevant code needs to read # On some old linuxes there is a /lib/tls thread-local-storage version of the C # library which the VM may use and if so should take precedence over /lib libc. case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; /lib/libc*) SVMLLP="/lib:/usr/lib";; /lib32/libc*) SVMLLP="/lib32:/usr/lib32";; *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; exit 1 esac Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of /usr/lib? > Cheers > Philippe > > > -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Philippe Marschall

On 27.12.2011 19:18, Eliot Miranda wrote: > Hi Phillipe, > > what does ldd answer for the squeak vm? $ldd coglinux/lib/squeak/4.0-2515/squeak linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) libm.so.6 => /lib32/libm.so.6 (0xf7687000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) libc.so.6 => /lib32/libc.so.6 (0xf750c000) /lib/ld-linux.so.2 (0xf76fe000) It's a 64bit system with 32bit compatibility libraries (only for cog, everything else is 64bit). Cheers Philippe

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Andres Valloud

I don't know how to parse "weak set nilling is totally unrelated to finalization", maybe we're talking about different things when we use the term "finalization", I don't know. On 12/27/11 10:59 , Schwab,Wilhelm K wrote: > Is it unrelated by chance/evolution or because that is the correct thing to do? Dolphin does not scope finalization, and the purity of the design is tangible. As I have said, Dolphin began with structured exceptions, hindsight regarding multi-processing, and finalization all in clear view, and these features work together as a result. > > Squeak (and hence Pharo), by its roots in Smalltalk-80 has a bit more baggage and some associated rough spots. > > > ________________________________________ > 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: Tuesday, December 27, 2011 9:33 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Destiny of changed:/update: > > (quote fixed by hand) > > On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote: > >> I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. >> It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). >> What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)? > > Weak collections are used outside of the scope of finalization, otherwise > most of them wouldn't exist. For example Symbols are stored in WeakSets, so when > a symbol is not used anymore, itcan be garbage collected. And this is > _totally_ unrelated to finalization. > > > 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, December 26, 2011 9:06 PM > To: Pharo-project(a)lists.gforge.inria.fr; andres.valloud(a)gmail.com > Subject: Re: [Pharo-project] Destiny of changed:/update: > > On Mon, 26 Dec 2011, Andres Valloud wrote: > >> That's not how ephemerons work, and they also get finalized. Both of you may >> be right... > > Well, yes, with ephemerons you can implement a finalization mechanism > which is triggered when the object is _about to be_ garbage collected > (note that the finalize() method in java is similar). But it doesn't mean > that finalization has anything to do with weak collections or that weak > collections should be thread safe, which is what Bill wrote. > > > Levente > >> >> On 12/26/11 16:49 , Levente Uzonyi wrote: >>> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >>> >>>> Levente, >>> >>> Not meaning to be confrontational, but finalization does not happen "in" >>> any type of collection. It happens *to* elements that can be held in any >>> type of weak collection. As a result, they should all be thread safe and >>> self-repairing. >>> >>> >>> I guess you're wrong. A weak collection is a collection which doesn't hold >>> strong references to its elements, so they can be garbage collected when >>> there are no other strong references to them. >>> Finalization is a service which triggers an action when an object is >>> garbage collected. >>> Some finalization techniques require the use of weak collections, but >>> otherwise weak collections are independent of finalization. >>> >>> >>> 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, December 26, 2011 3:10 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Destiny of changed:/update: >>> >>> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >>> >>>> Stef, >>> >>> I completely agree that events/announcements are cleaner and easier to >>> understand than changed/update. I don't really care whether or not the >>> latter is removed, because I never (directly) use it. Others might prefer >>> to have it retained?? >>> >>> I'm not supposed to say where<g>, but I have seen events, weak collections >>> and finalization done *really* well. In fairness, my working image is old >>> and I need to take another stab at building a recent image, but when I last >>> reviewed them, Pharo's weak collections were lacking features. They have >>> to be thread safe, and they need to clear nil entries left behind by >>> finalization (which is why they must be thread safe). The better we get >>> with events (#on:send:to and friends), the more the current weak >>> collections will appear to be lacking. >>> >>> >>> Finalization only happens in WeakRegistries and those are thread safe. The >>> other weak collections are not subject to finalization, therefore they >>> don't have to be thread safe, that's why they aren't. >>> >>> >>> Levente >>> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse >>> [stephane.ducasse(a)inria.fr] >>> Sent: Monday, December 26, 2011 10:56 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Destiny of changed:/update: >>> >>> using on:send: instead of changed/ is a nice way to reduce extra updates. >>> In Cuis juan kept only one mechanism and I like that. >>> >>> In VisualWorks you have to use on:send:to: this way you can select with >>> facet is refreshed. >>> So I would like to deprecated changed. >>> >>> Stef >>> >>>> Will changed:/update: disappear and be totally replaced by Announcements? >>>> >>>> I ask because I'm using ListModel and noticed that it sends a generic >>>> "self >>>> changed: #selectionIndex". I built a GUI that had two of them, and >>>> couldn't >>>> differentiate between the updates, so I was going to enhance it a little. >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> >>>> . >>> >> >> > >> > > . >

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Schwab,Wilhelm K

Eliot, I apologize if this is retreaded ground. I am still using an older, hacked, vm for most of my work. The hacks provided diagnostic information in two ares: (1) can't load an external library? Then it helps to see the full path that was used; at least once, it ended up having an extra slash appended somewhere; various other times, I had not registered something correctly, and the mistake was obvious as soon as I saw what the vm was ultimately trying to load; (2) Can't open a serial port? Then it helps to see how the vm mapped it too. I wish I remembered more of the details on this type of problem. At least some of the trouble I have had is due to the realities of newer hardware forcing me to use USB to serial converters, which I find to be unreliable. I am still sorting through the combination of Linux and some excellent hardware that I have used for years. The short version is that when a library can't load or a port can't open, etc., and the vm did some translation of a name to a number (or vice versa), or manipulated a string, it would be nice to have syslog()/OutputDebugString() output to show what the vm tried to do. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Tuesday, December 27, 2011 1:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting. Hi Phillipe, what does ldd answer for the squeak vm? The script is trying to work out what default LD_LIBRARY_PATH to supply. The choice is between /lib/tls:/lib:/usr/lib/tls:/usr/lib and /lib:/usr/lib. Older linuxes had two versions of the pthreads library, an experimental one (now the default) using thread-local storage (hence tls) and an older one, I think using the stack pointer to identify the current thread. The script uses ldd to find out what the VM is linked against. Here's the code: # On some old linuxes there is a /lib/tls thread-local-storage version of the C # library which the VM may use and if so should take precedence over /lib libc. case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; /lib/libc*) SVMLLP="/lib:/usr/lib";; *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; exit 1 esac On Tue, Dec 27, 2011 at 9:51 AM, Philippe Marschall <kustos(a)gmx.net<mailto:kustos@gmx.net>> wrote: Hi With the latest cog VMs I get: can't infer base LD_LIBRARY_PATH. Aborting. Gentoo 64bit, Linux 3.1 LD_LIBRARY_PATH is not set but libtool is present. Cheers Philippe -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Schwab,Wilhelm K

Is it unrelated by chance/evolution or because that is the correct thing to do? Dolphin does not scope finalization, and the purity of the design is tangible. As I have said, Dolphin began with structured exceptions, hindsight regarding multi-processing, and finalization all in clear view, and these features work together as a result. Squeak (and hence Pharo), by its roots in Smalltalk-80 has a bit more baggage and some associated rough spots. ________________________________________ 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: Tuesday, December 27, 2011 9:33 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: (quote fixed by hand) On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote: > I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. > It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). > What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)? Weak collections are used outside of the scope of finalization, otherwise most of them wouldn't exist. For example Symbols are stored in WeakSets, so when a symbol is not used anymore, itcan be garbage collected. And this is _totally_ unrelated to finalization. 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, December 26, 2011 9:06 PM To: Pharo-project(a)lists.gforge.inria.fr; andres.valloud(a)gmail.com Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Andres Valloud wrote: > That's not how ephemerons work, and they also get finalized. Both of you may > be right... Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente > > On 12/26/11 16:49 , Levente Uzonyi wrote: >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Levente, >> >> Not meaning to be confrontational, but finalization does not happen "in" >> any type of collection. It happens *to* elements that can be held in any >> type of weak collection. As a result, they should all be thread safe and >> self-repairing. >> >> >> I guess you're wrong. A weak collection is a collection which doesn't hold >> strong references to its elements, so they can be garbage collected when >> there are no other strong references to them. >> Finalization is a service which triggers an action when an object is >> garbage collected. >> Some finalization techniques require the use of weak collections, but >> otherwise weak collections are independent of finalization. >> >> >> 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, December 26, 2011 3:10 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Stef, >> >> I completely agree that events/announcements are cleaner and easier to >> understand than changed/update. I don't really care whether or not the >> latter is removed, because I never (directly) use it. Others might prefer >> to have it retained?? >> >> I'm not supposed to say where<g>, but I have seen events, weak collections >> and finalization done *really* well. In fairness, my working image is old >> and I need to take another stab at building a recent image, but when I last >> reviewed them, Pharo's weak collections were lacking features. They have >> to be thread safe, and they need to clear nil entries left behind by >> finalization (which is why they must be thread safe). The better we get >> with events (#on:send:to and friends), the more the current weak >> collections will appear to be lacking. >> >> >> Finalization only happens in WeakRegistries and those are thread safe. The >> other weak collections are not subject to finalization, therefore they >> don't have to be thread safe, that's why they aren't. >> >> >> Levente >> >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse >> [stephane.ducasse(a)inria.fr] >> Sent: Monday, December 26, 2011 10:56 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> using on:send: instead of changed/ is a nice way to reduce extra updates. >> In Cuis juan kept only one mechanism and I like that. >> >> In VisualWorks you have to use on:send:to: this way you can select with >> facet is refreshed. >> So I would like to deprecated changed. >> >> Stef >> >>> Will changed:/update: disappear and be totally replaced by Announcements? >>> >>> I ask because I'm using ListModel and noticed that it sends a generic >>> "self >>> changed: #selectionIndex". I built a GUI that had two of them, and >>> couldn't >>> differentiate between the updates, so I was going to enhance it a little. >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >>> . >> > > >

Dec. 27, 2011