October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Finalization question

by Schwab,Wilhelm K

Sig, Thanks for the quick reply. I finished my thought, which might help you figure out what I'm missing. As an aside, I would like to identify and finalize the Outlook hotkey that launched that email before I was ready - I've never seen Outlook do *anything* that fast. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 23, 2009 1:09 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization question 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > I have started to port some of my code that relies on Dolphin's finalization. Â The idea is that one sends #beFinalizable to the object requiring finalization. Â Dolphin sets a flag on the object (in its header??) that the vm later notices. a rough analogy is something like that: Object>>beFinalizable "A shallow copy of the receiver will receive a #finalize message, once the receiver become garbage" WeakRegistry default add: self > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)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 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

Re: [Pharo-project] Finalization question

by Schwab,Wilhelm K

Sorry for the extra message. Outlook - need I say more? Hello all, I have started to port some of my code that relies on Dolphin's finalization. The idea is that one sends #beFinalizable to the object requiring finalization. Dolphin sets a flag on the object (in its header??) that the vm later notices. The end result is the object in question receives #finalize and cleans up its own mess; it can also "cheat death" but I doubt I have need for that level of control. My question is that the Squeak/Pharo design appears to be built on ObjetFinalizer instances that are associated with finalizable objects, each recording what to do when an object expires. If that's true, then I'm wondering why objects understand #finalize. That seems to conflict with #toFinalize:send:to:with:, which looks like it expects just enough information to do the cleanup for the expired object. Any idea what I might be missing here or pointers to required reading? I found something from 2003 (Squeak 3.7) which might be out of date, or maybe I'm just working too late :) Bill

Oct. 23, 2009

Re: [Pharo-project] Finalization question

by Igor Stasenko

2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > I have started to port some of my code that relies on Dolphin's finalization. Â The idea is that one sends #beFinalizable to the object requiring finalization. Â Dolphin sets a flag on the object (in its header??) that the vm later notices. a rough analogy is something like that: Object>>beFinalizable "A shallow copy of the receiver will receive a #finalize message, once the receiver become garbage" WeakRegistry default add: self > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 23, 2009

[Pharo-project] Finalization question

by Schwab,Wilhelm K

Hello all, I have started to port some of my code that relies on Dolphin's finalization. The idea is that one sends #beFinalizable to the object requiring finalization. Dolphin sets a flag on the object (in its header??) that the vm later notices.

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Like I said, we're pretty clearly not going to agree. I see no advantage to witholding a good example that is itself useful only because a newbie might extrapolate too far; I see lost opporunity and buggy ad hoc implementations resulting from not providing the solid example. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, October 22, 2009 11:35 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > That's fine as far as it goes, but the building blocks are useful both as concrete components and as examples of how to protect something. > yeah, and given these examples one could easily write a thread-unsafe application. But then, when it doesn't working as expected, he scratching his head and saying: hey, what's going on! I'm using a thread-safe library, why the heck my application not thread-safe?!?! And instead of start writing a concurrent, thread-safe code, he chooses to write another library, which will be 100% thread-safe and then he can be 'assured' that his thread-unsafe code will magically become thread-safe because he using a 'right' tool :) > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor > Stasenko > Sent: Thursday, October 22, 2009 11:01 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Sig, >> >> It appears we are not going to agree. >> > It appears not. > > Thread-safe collections is too good to be true solutions for concurrency. Its too simplistic approach and in a long run , fairly ineffective. > In any real-world application the basic building blocks is not generic collections, but different objects which composing your domain model. > Some of your domain objects could use collections, some of them not. > But you can't predict how do they using them , and in what way to state that putting thread-safe collection in use will make the whole model thread safe. > And that's why i think thread-safety should be introduced at higher levels of abstractions. > >> Bill >> > > -- > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)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 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by Igor Stasenko

2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > That's fine as far as it goes, but the building blocks are useful both as concrete components and as examples of how to protect something. > yeah, and given these examples one could easily write a thread-unsafe application. But then, when it doesn't working as expected, he scratching his head and saying: hey, what's going on! I'm using a thread-safe library, why the heck my application not thread-safe?!?! And instead of start writing a concurrent, thread-safe code, he chooses to write another library, which will be 100% thread-safe and then he can be 'assured' that his thread-unsafe code will magically become thread-safe because he using a 'right' tool :) > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Thursday, October 22, 2009 11:01 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Sig, >> >> It appears we are not going to agree. >> > It appears not. > > Thread-safe collections is too good to be true solutions for concurrency. Its too simplistic approach and in a long run , fairly ineffective. > In any real-world application the basic building blocks is not generic collections, but different objects which composing your domain model. > Some of your domain objects could use collections, some of them not. > But you can't predict how do they using them , and in what way to state that putting thread-safe collection in use will make the whole model thread safe. > And that's why i think thread-safety should be introduced at higher levels of abstractions. > >> Bill >> > > -- > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 23, 2009

Re: [Pharo-project] Starting out: db and gui recommendation

by Mariano Martinez Peck

2009/10/22 Rick Morrison <rick(a)m45.us> > I am a Java & .Net application programmer who has flirted with Smalltalk > for a long time without doing the "deep dive" to really understand it. > Pharo and Seaside are making me think that everything is coming together now > for another try. That and some micro-ISV ambitions to give me a real reason > to write some code outside of work. > > Welcome!!! I hope you enjoy this wonderful world ;) > For my type of project I really need a db package and a gui package. That > leads to the questions: > 1. Right now, is SqeakDBX my best choice for a db interface? Sqlite is my > db of choice for the project I have in mind. > Of course!!! hahahahaha (I am one of the SqueakDBX authors). But it is a joke. There are several persitence alternatives. You can see this link: http://www.seaside.st/documentation/persistence There others nice solutions like Magma, CouchDB and TokyoTyrant, etc. The good thing is that you have several approaches. There must be one that fits better your needs. BTW, SqueakDBX works perfect with Sqlite3 in Linux, Mac and Windows. Which OS do you want to use? You can even create (I can help you if you want) a seaside one-click with the Sqlite3 and OpenDBX dlls. So, this type of app is very "portable": just unzip and double click :) For more details about SqueakDBX you can see http://www.squeakdbx.org/ 2. For the UI, I've been reading about the choices and I'm having a hard > time finding a currently supported project. Do I go with polymorph by > default? > > For the UI, what about "self-hosting" a Seaside instance and doing the UI > in the browser? Ie, the app starts a Seaside server and opens a browser > window pointed at the apps main window (home page). Can that be done? Is > it a good idea? > > Yes, I saw a lot of people doing this. They have a one click seaside image where you just do a double click and then open the browser with localhost And as I told you, you can have sqlite3 inside that zip. On there other hand, there is a very interesting project that let you build "heavy client apps" with Polymorph using a palette and drag and drop. You can see a video here: http://www.youtube.com/watch?v=CHbc1t83fEI > I hope you can give me some direction. I like the direction of Pharo and > Seaside is just plain cool. I want to do this to get my head outside the > coding box I'm kind of stuck in. And have some fun. > > There are 2 new books if you want: one for seaside and one for pharo: - http://www.pharobyexample.org/ - http://book.seaside.st/book > Thanks for any help, > You are wolcome! > Rick > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Sig, That's fine as far as it goes, but the building blocks are useful both as concrete components and as examples of how to protect something. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, October 22, 2009 11:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > It appears we are not going to agree. > It appears not. Thread-safe collections is too good to be true solutions for concurrency. Its too simplistic approach and in a long run , fairly ineffective. In any real-world application the basic building blocks is not generic collections, but different objects which composing your domain model. Some of your domain objects could use collections, some of them not. But you can't predict how do they using them , and in what way to state that putting thread-safe collection in use will make the whole model thread safe. And that's why i think thread-safety should be introduced at higher levels of abstractions. > Bill > -- 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

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by Igor Stasenko

2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > It appears we are not going to agree. > It appears not. Thread-safe collections is too good to be true solutions for concurrency. Its too simplistic approach and in a long run , fairly ineffective. In any real-world application the basic building blocks is not generic collections, but different objects which composing your domain model. Some of your domain objects could use collections, some of them not. But you can't predict how do they using them , and in what way to state that putting thread-safe collection in use will make the whole model thread safe. And that's why i think thread-safety should be introduced at higher levels of abstractions. > Bill > -- Best regards, Igor Stasenko AKA sig.

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Sig, It appears we are not going to agree. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, October 22, 2009 10:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > > Sig, > > What about things like managing connections to remote hosts? Â Do I have a socket going over there? Â No?? Â Let's make one. Â Sounds like a great job for a shared dictionary. > it depends on your model, what you need to manage and how. If your goal is to communicate with remote hosts, where are sockets come from is not really relevant to you. Mainly you just getting a reference to object, which provides some facilities to you. How that object manages a collection of sockets, or does it manages them at all is not your concern.. And i wouldn't say that having a thread-safe collections is a big win for managing connections comparing to other possible implementations which not require any thread-safety for collections. > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor > Stasenko > Sent: Thursday, October 22, 2009 8:34 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > 2009/10/23 Martin McClure <martin(a)hand2mouse.com>: >> >> It's probably possible to write a hashed collection that is >> thread-safe and semaphore-free for both read and write, but unless >> there's a very specific requirement for that it's probably simpler, >> faster, and more reliable to just use a semaphore. >> > +1. > If you traveling into the field of concurrency, you have to change the mindset. > You should pick different abstractions for that. And collections is one which you should leave to grow in single-threaded woods. > Or.. of course.. you can attempt to make them thread-safe.. But it will be clumpsy , rigid and very error prone. > >> Regards, >> >> -Martin >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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 > 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 > -- 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

Oct. 23, 2009