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

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Nicolas Cellier

2011/9/20 Igor Stasenko <siguctua(a)gmail.com>: > On 20 September 2011 22:43, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Tue, Sep 20, 2011 at 10:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> Hmm, >>> storing (and then restoring) weak containers as they are , i don't see >>> anything special which must be done there. >>> >>> The special logic how to deal with weak containers are still remains >>> same, as long as you correctly restoring the object, >>> and as long as this logic is correctly written. So, i cannot see what >>> Fuel needs to do special with weak containers. >> >> Yes, we thoght the same. But we wanted to ask just to be sure... >> Bill said the same, so we all agree :) >> >> >>> >>> You may need to deal with storing instances of WeakRegistry, since it >>> registers itself into WeakDependents array, >>> which is scanned for finalization. So, you have to make sure that if >>> WeakRegistry instance was registered in weak-dependents >>> array, then you should also register it when restoring it back. (and >>> if it was not registered - then of course not register). >>> >>> But WeakRegistry is a regular object (not a weak container by itself, >>> and only indirectly it using >>> weak containers by delegation). >> >> Yes, thanks for the pointer. > > if you look at the problem in wider perspective, then right question > to ask, is how to deal > with objects which are register themselves in global facilities, like > weak finalization, > startup/shutdown lists etc. > For those objects you need to have special (de)serialization cases. > But for objects with particular format (weak) you don't have to do > anything special. > Except that you must not forget to follow the weak links in order to trace the whole object graph... But since you use in-image serialization and no special garbage-collector like VM trick, it must not be a problem. Unless... wait, wait. A bad case would be to serialize a bunch of objects still pointed only by the WeakCollection, but not yet garbage collected. You would just waste space and time because they will die soon after materialization. So it might be a bad idea to follow those links... A worst case would be to serialize some objets weakly shared by your graph, but strongly shared by unsaved objects. In which case the graph you would save would not be a correct delimitation... If you wanted to check that, you should garbage collect first, then assert there is no weak orphan (an object pointed only weakly in your graph...). Nicolas >> >>> >>> On 20 September 2011 20:55, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>> wrote: >>> > Good question. Â I *think* the answer is to take the referenced objects >>> > across as one normally would, and then wrap them in a weak collection (if >>> > that is what was serialized). Â If one had only a weak collection holding the >>> > objects, they will be short-lived. Â However, something like a registry >>> > should be able to save/re-loaded, probably much like Dolphin's STBProxies: >>> > the effect of serializing the weak collection includes running some code to >>> > recreate conditions as needed. >>> > >>> > Looking forward to a lively debate... >>> > >>> > Bill >>> > >>> > >>> > >>> > >>> > ________________________________________ >>> > From: pharo-project-bounces(a)lists.gforge.inria.fr >>> > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez >>> > Peck [marianopeck(a)gmail.com] >>> > Sent: Tuesday, September 20, 2011 1:38 PM >>> > To: Pharo Development >>> > Subject: [Pharo-project] Should a serializer do something in particular >>> > with Â Â weak references? >>> > >>> > Hi guys. Martin and I were discussing whether we should do something in >>> > particular in Fuel with Weak references, such as WeakArray. Should we >>> > serialize it the same way we serialize all objects, or should we do >>> > something special? Â what could be the impact of materializing such weak >>> > references in a new image for example? >>> > >>> > Thanks your sharing your thoughts. >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > > -- > Best regards, > Igor Stasenko. > >

Sept. 20, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Levente Uzonyi

On Tue, 20 Sep 2011, Mariano Martinez Peck wrote: > Hi guys. Martin and I were discussing whether we should do something in > particular in Fuel with Weak references, such as WeakArray. Should we > serialize it the same way we serialize all objects, or should we do > something special? what could be the impact of materializing such weak > references in a new image for example? You should ignore (serialize nil instead of them) the elements of a weak object (#weakSubclass:...) which aren't referenced strongly from other serialized objects. Levente > > Thanks your sharing your thoughts. > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 20, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Mariano Martinez Peck

On Tue, Sep 20, 2011 at 10:51 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 September 2011 22:43, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Tue, Sep 20, 2011 at 10:37 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> Hmm, > >> storing (and then restoring) weak containers as they are , i don't see > >> anything special which must be done there. > >> > >> The special logic how to deal with weak containers are still remains > >> same, as long as you correctly restoring the object, > >> and as long as this logic is correctly written. So, i cannot see what > >> Fuel needs to do special with weak containers. > > > > Yes, we thoght the same. But we wanted to ask just to be sure... > > Bill said the same, so we all agree :) > > > > > >> > >> You may need to deal with storing instances of WeakRegistry, since it > >> registers itself into WeakDependents array, > >> which is scanned for finalization. So, you have to make sure that if > >> WeakRegistry instance was registered in weak-dependents > >> array, then you should also register it when restoring it back. (and > >> if it was not registered - then of course not register). > >> > >> But WeakRegistry is a regular object (not a weak container by itself, > >> and only indirectly it using > >> weak containers by delegation). > > > > Yes, thanks for the pointer. > > if you look at the problem in wider perspective, then right question > to ask, is how to deal > with objects which are register themselves in global facilities, like > weak finalization, > startup/shutdown lists etc. > For those objects you need to have special (de)serialization cases. > But for objects with particular format (weak) you don't have to do > anything special. > > This is easy: you implement #fuelAfterMaterialization and do whatever you want. > > > >> > >> On 20 September 2011 20:55, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > >> wrote: > >> > Good question. I *think* the answer is to take the referenced objects > >> > across as one normally would, and then wrap them in a weak collection > (if > >> > that is what was serialized). If one had only a weak collection > holding the > >> > objects, they will be short-lived. However, something like a registry > >> > should be able to save/re-loaded, probably much like Dolphin's > STBProxies: > >> > the effect of serializing the weak collection includes running some > code to > >> > recreate conditions as needed. > >> > > >> > Looking forward to a lively debate... > >> > > >> > Bill > >> > > >> > > >> > > >> > > >> > ________________________________________ > >> > From: pharo-project-bounces(a)lists.gforge.inria.fr > >> > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano > Martinez > >> > Peck [marianopeck(a)gmail.com] > >> > Sent: Tuesday, September 20, 2011 1:38 PM > >> > To: Pharo Development > >> > Subject: [Pharo-project] Should a serializer do something in > particular > >> > with weak references? > >> > > >> > Hi guys. Martin and I were discussing whether we should do something > in > >> > particular in Fuel with Weak references, such as WeakArray. Should we > >> > serialize it the same way we serialize all objects, or should we do > >> > something special? what could be the impact of materializing such > weak > >> > references in a new image for example? > >> > > >> > Thanks your sharing your thoughts. > >> > > >> > -- > >> > Mariano > >> > http://marianopeck.wordpress.com > >> > > >> > > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Sept. 20, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Igor Stasenko

On 20 September 2011 22:43, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, Sep 20, 2011 at 10:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Hmm, >> storing (and then restoring) weak containers as they are , i don't see >> anything special which must be done there. >> >> The special logic how to deal with weak containers are still remains >> same, as long as you correctly restoring the object, >> and as long as this logic is correctly written. So, i cannot see what >> Fuel needs to do special with weak containers. > > Yes, we thoght the same. But we wanted to ask just to be sure... > Bill said the same, so we all agree :) > > >> >> You may need to deal with storing instances of WeakRegistry, since it >> registers itself into WeakDependents array, >> which is scanned for finalization. So, you have to make sure that if >> WeakRegistry instance was registered in weak-dependents >> array, then you should also register it when restoring it back. (and >> if it was not registered - then of course not register). >> >> But WeakRegistry is a regular object (not a weak container by itself, >> and only indirectly it using >> weak containers by delegation). > > Yes, thanks for the pointer. if you look at the problem in wider perspective, then right question to ask, is how to deal with objects which are register themselves in global facilities, like weak finalization, startup/shutdown lists etc. For those objects you need to have special (de)serialization cases. But for objects with particular format (weak) you don't have to do anything special. > >> >> On 20 September 2011 20:55, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> wrote: >> > Good question. Â I *think* the answer is to take the referenced objects >> > across as one normally would, and then wrap them in a weak collection (if >> > that is what was serialized). Â If one had only a weak collection holding the >> > objects, they will be short-lived. Â However, something like a registry >> > should be able to save/re-loaded, probably much like Dolphin's STBProxies: >> > the effect of serializing the weak collection includes running some code to >> > recreate conditions as needed. >> > >> > Looking forward to a lively debate... >> > >> > Bill >> > >> > >> > >> > >> > ________________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr >> > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez >> > Peck [marianopeck(a)gmail.com] >> > Sent: Tuesday, September 20, 2011 1:38 PM >> > To: Pharo Development >> > Subject: [Pharo-project] Should a serializer do something in particular >> > with Â Â weak references? >> > >> > Hi guys. Martin and I were discussing whether we should do something in >> > particular in Fuel with Weak references, such as WeakArray. Should we >> > serialize it the same way we serialize all objects, or should we do >> > something special? Â what could be the impact of materializing such weak >> > references in a new image for example? >> > >> > Thanks your sharing your thoughts. >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko.

Sept. 20, 2011

Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158

by Igor Stasenko

On 20 September 2011 22:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Sep 20, 2011 at 12:50 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> yes please send it. >> How do you determine ancestry? > > Here's the phrase: > ChangeSet directAncestryOfVersions: (ChangeSet > scanVersionsOf: method > class: self > meta: self isMeta > category: category > selector: selector) > the scanVersionsOf: is standard, and then I addedÂ directAncestryOfVersions: > to filter appropriately. > > Find attached. Â You'll need to understand it, test it and integrate it, but > it worked fine for me. Â I haven't had time or occasion to push it to Squeak > trunk. Â But if people like it I'll think about doing so. Â I agree with > Henrik that this is a useful default. Â I love method versions, and noise is > noise, so this is having one's cake and eating it too :) +1 > Enjoy! >> >> Stef >> >> On Sep 20, 2011, at 9:32 PM, Eliot Miranda wrote: >> >> > >> > >> > On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen >> > <henrik.s.johansen(a)veloxit.no> wrote: >> > On 20.09.2011 14:49, Marcus Denker wrote: >> > Hi, >> > >> > The .changes have gotten really large... (32MB...) >> > >> > So I will do a condense in the next update. >> > >> > NOTE: this will take quite some time to finish, so maybe wait for a >> > pre-built image or Jenkins... >> > >> > Â Â Â Â Marcus >> > >> > >> > -- >> > Marcus Denker -- http://marcusdenker.de >> > >> > >> > Noooooooooo, please please don't... >> > Method history is so much more useful than 20 extra MB's on my HD :S >> > >> > This is /not/ a dichotomy. Â For my image I wrote a condenseSources that >> > preserves history. Â It edits out duplicates, and cuts off branches in the >> > history that lead nowhere. Â So at the end you get all the versions of each >> > method that are ancestors of the current version. Â I can email you the code >> > and you could consider making it the default. Â Let me know. >> > >> > >> > Cheers, >> > Henry >> > >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

Sept. 20, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Mariano Martinez Peck

On Tue, Sep 20, 2011 at 10:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hmm, > storing (and then restoring) weak containers as they are , i don't see > anything special which must be done there. > > The special logic how to deal with weak containers are still remains > same, as long as you correctly restoring the object, > and as long as this logic is correctly written. So, i cannot see what > Fuel needs to do special with weak containers. > Yes, we thoght the same. But we wanted to ask just to be sure... Bill said the same, so we all agree :) > You may need to deal with storing instances of WeakRegistry, since it > registers itself into WeakDependents array, > which is scanned for finalization. So, you have to make sure that if > WeakRegistry instance was registered in weak-dependents > array, then you should also register it when restoring it back. (and > if it was not registered - then of course not register). > > But WeakRegistry is a regular object (not a weak container by itself, > and only indirectly it using > weak containers by delegation). > Yes, thanks for the pointer. > > On 20 September 2011 20:55, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > wrote: > > Good question. I *think* the answer is to take the referenced objects > across as one normally would, and then wrap them in a weak collection (if > that is what was serialized). If one had only a weak collection holding the > objects, they will be short-lived. However, something like a registry > should be able to save/re-loaded, probably much like Dolphin's STBProxies: > the effect of serializing the weak collection includes running some code to > recreate conditions as needed. > > > > Looking forward to a lively debate... > > > > Bill > > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez > Peck [marianopeck(a)gmail.com] > > Sent: Tuesday, September 20, 2011 1:38 PM > > To: Pharo Development > > Subject: [Pharo-project] Should a serializer do something in particular > with weak references? > > > > Hi guys. Martin and I were discussing whether we should do something in > particular in Fuel with Weak references, such as WeakArray. Should we > serialize it the same way we serialize all objects, or should we do > something special? what could be the impact of materializing such weak > references in a new image for example? > > > > Thanks your sharing your thoughts. > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Sept. 20, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Igor Stasenko

Hmm, storing (and then restoring) weak containers as they are , i don't see anything special which must be done there. The special logic how to deal with weak containers are still remains same, as long as you correctly restoring the object, and as long as this logic is correctly written. So, i cannot see what Fuel needs to do special with weak containers. You may need to deal with storing instances of WeakRegistry, since it registers itself into WeakDependents array, which is scanned for finalization. So, you have to make sure that if WeakRegistry instance was registered in weak-dependents array, then you should also register it when restoring it back. (and if it was not registered - then of course not register). But WeakRegistry is a regular object (not a weak container by itself, and only indirectly it using weak containers by delegation). On 20 September 2011 20:55, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Good question. Â I *think* the answer is to take the referenced objects across as one normally would, and then wrap them in a weak collection (if that is what was serialized). Â If one had only a weak collection holding the objects, they will be short-lived. Â However, something like a registry should be able to save/re-loaded, probably much like Dolphin's STBProxies: the effect of serializing the weak collection includes running some code to recreate conditions as needed. > > Looking forward to a lively debate... > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] > Sent: Tuesday, September 20, 2011 1:38 PM > To: Pharo Development > Subject: [Pharo-project] Should a serializer do something in particular with Â Â weak references? > > Hi guys. Martin and I were discussing whether we should do something in particular in Fuel with Weak references, such as WeakArray. Should we serialize it the same way we serialize all objects, or should we do something special? Â what could be the impact of materializing such weak references in a new image for example? > > Thanks your sharing your thoughts. > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Best regards, Igor Stasenko.

Sept. 20, 2011

Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158

by Eliot Miranda

On Tue, Sep 20, 2011 at 12:50 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > yes please send it. > How do you determine ancestry? > Here's the phrase: ChangeSet directAncestryOfVersions: (ChangeSet scanVersionsOf: method class: self meta: self isMeta category: category selector: selector) the scanVersionsOf: is standard, and then I added directAncestryOfVersions: to filter appropriately. Find attached. You'll need to understand it, test it and integrate it, but it worked fine for me. I haven't had time or occasion to push it to Squeak trunk. But if people like it I'll think about doing so. I agree with Henrik that this is a useful default. I love method versions, and noise is noise, so this is having one's cake and eating it too :) Enjoy! Stef > > On Sep 20, 2011, at 9:32 PM, Eliot Miranda wrote: > > > > > > > On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > > On 20.09.2011 14:49, Marcus Denker wrote: > > Hi, > > > > The .changes have gotten really large... (32MB...) > > > > So I will do a condense in the next update. > > > > NOTE: this will take quite some time to finish, so maybe wait for a > pre-built image or Jenkins... > > > > Marcus > > > > > > -- > > Marcus Denker -- http://marcusdenker.de > > > > > > Noooooooooo, please please don't... > > Method history is so much more useful than 20 extra MB's on my HD :S > > > > This is /not/ a dichotomy. For my image I wrote a condenseSources that > preserves history. It edits out duplicates, and cuts off branches in the > history that lead nowhere. So at the end you get all the versions of each > method that are ancestors of the current version. I can email you the code > and you could consider making it the default. Let me know. > > > > > > Cheers, > > Henry > > > > > > > > > > -- > > best, > > Eliot > > > > > -- best, Eliot

Sept. 20, 2011

Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158

by Marcus Denker

On Sep 20, 2011, at 9:55 PM, Henrik Sperre Johansen wrote: >> >> This is /not/ a dichotomy. For my image I wrote a condenseSources that preserves history. It edits out duplicates, and cuts off branches in the history that lead nowhere. So at the end you get all the versions of each method that are ancestors of the current version. I can email you the code and you could consider making it the default. Let me know. > > Can't speak for the others, but I would _very_ much appreciate that being the default. Yes, and run regularly... Marcus -- Marcus Denker -- http://marcusdenker.de

Sept. 20, 2011

Re: [Pharo-project] Looking for a machine

by Marcus Denker

On Sep 20, 2011, at 9:49 PM, StÃ©phane Ducasse wrote: > Hi guys > > I'm checking our machines and I'm looking for the following one. > > > W884943C1GN 00:23:6c:8d:16:c4 00:23:32:de:7c:da Gesvres MacBook Pro Unibody intel 15 Previously Simon Decembre 2008 - ebiscuss Leopard 4Gb inria RMOD > > > Does anybody know where it is? > Could you check the machines you see (this is not the one in the drawer room 117 I checked it). > Wrong mailinglist :-) Marcus -- Marcus Denker -- http://marcusdenker.de

Sept. 20, 2011