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

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

by Andres Valloud

That's not how ephemerons work, and they also get finalized. Both of you may be right... 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] Destiny of changed:/update:

by Levente Uzonyi

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] [ANN][Beta Release] DBXTools - Magritte Scaffolding - Phoseydon

by Ramiro Diaz Trepat

You guys are doing some fabulous and much needed work! Cheers r On 26 December 2011 18:46, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > Hi! > > I'm glad to announce the beta version of Phoseydon, one of the new dbxtalk > tools developed as part of the summer of talk project, supported by ESUG. > > So, > > *What is Phoseydon?* > It is a tool aimed to model and create applications easily, as Ruby does > with Rails or python with Django. You describe a model, and from that > model a relational database + an object model + an ORM mapping are fed from > that model. > > *What does Phoseydon beta includes?* > By now, it reads a database schema, builds a model description from it and > then allows us to: > - write classes from that description. > - serialize that description as Magritte descriptions on the created > classes. > - build a Glorp mapping from that description. > > Glorp descriptions right now support Simple mappings (Strings, numbers, > booleans..), OneToOne relationships, and ManyToOne relationships. > > *What does it do in the background?* > It tries to explode Magritte benefits to create apps. The model's > description is just a magritte descrition, so our class writer, magritte > serializer and Glorp mapping builder use magritte visitors to consume that > information. > This allows people to build i.e. SOAP web services from these same > magritte descriptions. > > *Where is the documentation? > *Download info from: http://dbxtalk.smallworks.com.ar/pier/Download > First Phoseydon doc: > http://dbxtalk.smallworks.com.ar/pier/Documentation/creating-your-first-dbx… > > *What is to come?* > - Editing your model descriptions in runtime > - Create your model descriptions without a database > - More easy Glorp mappings support :) (like embedding objects, inheritance > and more collections kinds) > > Please, feel free to provide feedback, critics and suggestions :). You'll > find the project's issue tracker and mailing list @ > http://dbxtalk.smallworks.com.ar/pier/Support > > Cheers, > The DBXTalk Team >

Dec. 26, 2011

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

by Schwab,Wilhelm K

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. 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. 26, 2011

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

by Levente Uzonyi

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. 26, 2011

[Pharo-project] [ANN][Beta Release] DBXTools - Magritte Scaffolding - Phoseydon

by Guillermo Polito

Hi! I'm glad to announce the beta version of Phoseydon, one of the new dbxtalk tools developed as part of the summer of talk project, supported by ESUG. So, *What is Phoseydon?* It is a tool aimed to model and create applications easily, as Ruby does with Rails or python with Django. You describe a model, and from that model a relational database + an object model + an ORM mapping are fed from that model. *What does Phoseydon beta includes?* By now, it reads a database schema, builds a model description from it and then allows us to: - write classes from that description. - serialize that description as Magritte descriptions on the created classes. - build a Glorp mapping from that description. Glorp descriptions right now support Simple mappings (Strings, numbers, booleans..), OneToOne relationships, and ManyToOne relationships. *What does it do in the background?* It tries to explode Magritte benefits to create apps. The model's description is just a magritte descrition, so our class writer, magritte serializer and Glorp mapping builder use magritte visitors to consume that information. This allows people to build i.e. SOAP web services from these same magritte descriptions. *Where is the documentation? *Download info from: http://dbxtalk.smallworks.com.ar/pier/Download First Phoseydon doc: http://dbxtalk.smallworks.com.ar/pier/Documentation/creating-your-first-dbx… *What is to come?* - Editing your model descriptions in runtime - Create your model descriptions without a database - More easy Glorp mappings support :) (like embedding objects, inheritance and more collections kinds) Please, feel free to provide feedback, critics and suggestions :). You'll find the project's issue tracker and mailing list @ http://dbxtalk.smallworks.com.ar/pier/Support Cheers, The DBXTalk Team

Dec. 26, 2011

[Pharo-project] [ANN] New DBXTalk Website Available

by Guillermo Polito

Hi! I'm glad to announce the new -but still in progress- dbxtalk website, which is held in http://dbxtalk.smallworks.com.ar/. Here we are documenting the whole project and it's new acquisitions (some of them which I'll be announcing in the following hours) as part of the summer of talk project, supported by ESUG. Please, feel free to provide feedback, critics and suggestions :). You'll find the project's issue tracker and mailing list @ http://dbxtalk.smallworks.com.ar/pier/Support BTW, if you need it for something (like information we didn't migrate yet), the previous website is still available @ http://squeakdbx.smallworks.com.ar/ Cheers, Guille

Dec. 26, 2011

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

by Schwab,Wilhelm K

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. 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. 26, 2011

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

by StÃ©phane Ducasse

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. 26, 2011

Re: [Pharo-project] How to handle Squeak / Pharo differences

by Sean P. DeNigris

laurent laffont wrote > > how to handle common Squeak / Pharo incompatibilities ? > Laurent, also see http://groups.google.com/group/metacello/browse_thread/thread/000ec71f38f27… for two ways to manage platform packages via Metacello -- View this message in context: http://forum.world.st/How-to-handle-Squeak-Pharo-differences-tp4234225p4234… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 26, 2011