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

Re: [Pharo-project] Server sockets, ephermal ports, and a Linux VM crash

by Igor Stasenko

2009/11/2 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > Is there a preferred way to create TCP servers? Â KomServices and ConnectionQueue are options; there has been some discussion of the future of KomServices??? > > A nice trick is to use "ephmeral" ports, which is a fancy way of saying to pass zero for the listening port and let the OS assign a port. Â I have used that on Windows and it seems to work on Linux. Â TcpService does a lot to hide its listening socket; some small changes would allow it to use ephemeral ports. Â Any interest? Â They seem to work now, but there is no clean way to query the port that is ultimately chosen; the goal is to be able to so allocate a port and then send it to the other side for out of band communications. > Never tried it. A #localPort should answer the port number to which a given socket is bound. There is also #getOption: , but i'm not sure if it works similar on all platforms. > Perhaps related to my toying with port numbers (but I doubt that), I have had my older image crash a few times today. Â I created a TcpService on port zero, the listening socket gets a port and all seems reasonably well until I later inspect a few aspects of the TcpService, at which point the vm crashes. > > Bill > > > > > _______________________________________________ > 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.

Nov. 3, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/3 Igor Stasenko <siguctua(a)gmail.com>: > I just uploaded the modified announcer code + new tests. > Please check the > > http://www.squeaksource.com/PharoInbox/Announcements-Slice-Igor_Stasenko.1.… > > and send a feedback > oh.. for those who interested , but too lazy (or busy) to check it out.. - added a generic #subscribe: form of subscription. - added weak subscriptions support (except block subscriptions). Also, unsubscribing is allowed during handling an announcements, as well as nested announcements (these two features should work ok, but i didn't covered them with tests). > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

I just uploaded the modified announcer code + new tests. Please check the http://www.squeaksource.com/PharoInbox/Announcements-Slice-Igor_Stasenko.1.… and send a feedback -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/2 Alain Plantec <alain.plantec(a)free.fr>: > Igor Stasenko wrote: >> 2009/11/1 Tudor Girba <tudor.girba(a)gmail.com>: >> >>> Indeed, the main and only goal of Announcement is to provide an object- >>> oriented (Exception-like) way to handle notifications. >>> >>> I have used the Announcements implementation of Lukas on several >>> occasions and I did not feel the need for anything else. >>> >>> You indeed should subclass Announcement for any specific announcement, >>> but that is not a drawback, it is a nice feature. If you want to have >>> an announcement that you want to identify by a special single field, >>> you are free to implement that in one announcement class on top. >>> >>> >> >> Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow. >> > Hi Igor and all, > just reading this interesting thread... >> In other thread, I had proposed to use field to identify an event type >> instead of class, and someone said >> that i'm doing it wrong. >> > I guess you speak about my remark in the "ClassOrganizer oddities" thread. > Here is what I said: > ------------------------------------- >> You defined a set of announcement classes, each one is for a particular >> kind of event. >> So, no need for #changeKind and #parameters dictionary instance variable >> (please no!). > -------- end---------- > > just to be clear, the "please no!" was for the dictionary because > it can make the code difficult to maintain (Morph properties ...). > why not the #changeKind variable even I prefer expressing them by > subclasses. (see the end of this post) >> While i thinking that the way how the framework identifies events >> kinds (by default) not always best one, and as i illustrated its not >> good for everything. >> > yes and having a well defined announce hierarchy is not so easy. > that's why for sketching purposes, i'm using dictionary of arguments, not keyword messages and not building a class hierarchy of different change kinds. At this stage it is unclear what follows what, what is the final set of arguments for each change kind, and so i prefer to generate events using less 'early-bound' way. > Cheers > Alain > > > _______________________________________________ > 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.

Nov. 2, 2009

Re: [Pharo-project] lastKeystroke: ???

by HernÃ¡n Morales Durand

Hi Stef, maybe they were removed cleaning eToys, because the methods #lastKeystroke and #lastKeystroke: were under *etoys-e-toy support method category. I've attached both under 'event handling' category now. Cheers, HernÃ¡n 2009/11/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > apparently typing a character on the world -> DNU > lastKeystroke: from PasteUpMorph is not there. > Apparently the senders was integrated by me on 26 of October but I > could not find its trace. > So does anybody know from where this bug is coming? > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 2, 2009

Re: [Pharo-project] Fwd: MouseOverHandler

by Schwab,Wilhelm K

Gary, You raise an important point: I never said I was interested in your fixes. Given your track record, I would find it difficult not to be interested. Dolphin's deferred messages work in most situations. I learned the hard way[*] that menus left open[**] block Dolphin's out-of-the-box queued actions. Steve Waring wrote an alernate queue that was not so easy to hobble, and has served me well for years. I have yet to challenge Pharo's queued messages; in Dolphin, they work very quickly, sometimes only with Steve's help. That said, I look forward to seeing what you created; it might save me from problems I do not even yet know I have. Bill [*] Experience is not always the best teacher, but it is usually the most dramatic. I wish I could say I thought of that :) [**] You haven't lived until you've built software for physicians =:0 -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Monday, November 02, 2009 4:36 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: MouseOverHandler No arguments on weak stuff... VisualAge did a good job of those things (perhaps the garbage collector was better integrated with the concept). The driving force for our synchronisation stuff was the need to provide timely feedback, in terms of screen redraws, driven from separate processes that, for instance, were monitoring keystrokes from non-standard keypad devices, network messages etc. Was a necessity and proven in the field! I can get things together as a package later in the week. Very small footprint for a generalised per-object/sub-object scheme. On Mon, 2009-11-02 at 16:24 -0500, Schwab,Wilhelm K wrote: > Stef, Gary, > > Having recently ranted a little about thread safety for weak > collection, how can I argue? Well, let me see if I can do so and keep > my credibility intact :) > > Squeak's weak collections, and we have not moved beyond their limitations, do not clean themselves after their elements are finalized. That means they do half of what they should do; once they do all of it, they need to be thread safe; hence they do one third of what they should do. > > The GUI is arguably a little different. #addDeferredUIMessage: provides a clean way to interact with it from background threads, and that might be enough. IDE specific messages (e.g. #inspect) could probably stand to be queued to make them safe w/o horrible penalties, with the remainder of the GUI understood not to be thread safe for performance reasons. A backround thread can do expensive calculations and then queue a GUI update to safely update the display. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > StÃ©phane Ducasse > Sent: Monday, November 02, 2009 3:28 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > Hi gary > do you think that it make sense to have it in general (my gut feeling > is saying yes but I'm not thread-safe) > > If yes, yes we are interested for 1.1 > > BTW hernan I integrated your changes now it would be interesting to understand from where this nil is coming. > > Stef > On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote: > > > Yet the cause is unexplained. I still think it is due to non-ui > > processes fiddling with morphs (likely delettion or creation). > > The Morphic event loop remains non-thread safe. We have some > > modifications to ensure thread safety, based on a generalised > > synchronisation protocol if anyone is interested. > > > > Regards, Gary > > ----- Original Message ----- > > From: Hernan Wilkinson > > To: Pharo-project(a)lists.gforge.inria.fr > > Sent: Monday, November 02, 2009 7:45 PM > > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > > > Hi Adrian, > > the current implementation has problems, ie. send messages to nil, > > and it bothers a lot when that happens because it comes from > > nowhere... > > I've been using this implementation for a long time in my images > > and I did not get those problems anymore (and it is more > > readable...) > > > > On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > Hi Hernan, > > > > The reason this was not integrated is that nobody marked it as 'fixed' > > nor tagged it as 1.0. > > > > Is this critical for 1.0? > > > > Cheers, > > Adrian > > > > BTW, if anybody sees changes/fixes not being integrated please ask > > on the mailing list. > > > > > > On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: > > > > > > > > > > > Begin forwarded message: > > > > > >> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > > >> Date: October 29, 2009 2:02:32 PM GMT+01:00 > > >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > >> Subject: MouseOverHandler > > >> > > >> Hi Stef, > > >> do you know why the MouseOverHandler version I made is not in > > >> the main image? the current version is not working well, under > > >> heavy use it generates exceptions... > > >> I'm attaching the version I wrote that I'm using without > > problem... > > >> > > >> Hernan. > > > <MouseOverHandler.st> > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-projec > > > t > > > > > > _______________________________________________ > > 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 2, 2009

Re: [Pharo-project] Fwd: MouseOverHandler

by Gary Chambers

No arguments on weak stuff... VisualAge did a good job of those things (perhaps the garbage collector was better integrated with the concept). The driving force for our synchronisation stuff was the need to provide timely feedback, in terms of screen redraws, driven from separate processes that, for instance, were monitoring keystrokes from non-standard keypad devices, network messages etc. Was a necessity and proven in the field! I can get things together as a package later in the week. Very small footprint for a generalised per-object/sub-object scheme. On Mon, 2009-11-02 at 16:24 -0500, Schwab,Wilhelm K wrote: > Stef, Gary, > > Having recently ranted a little about thread safety for weak collection, how can I argue? Well, let me see if I can do so and keep my credibility intact :) > > Squeak's weak collections, and we have not moved beyond their limitations, do not clean themselves after their elements are finalized. That means they do half of what they should do; once they do all of it, they need to be thread safe; hence they do one third of what they should do. > > The GUI is arguably a little different. #addDeferredUIMessage: provides a clean way to interact with it from background threads, and that might be enough. IDE specific messages (e.g. #inspect) could probably stand to be queued to make them safe w/o horrible penalties, with the remainder of the GUI understood not to be thread safe for performance reasons. A backround thread can do expensive calculations and then queue a GUI update to safely update the display. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Monday, November 02, 2009 3:28 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > Hi gary > do you think that it make sense to have it in general (my gut feeling is saying yes but I'm not thread-safe) > > If yes, yes we are interested for 1.1 > > BTW hernan I integrated your changes now it would be interesting to understand from where this nil is coming. > > Stef > On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote: > > > Yet the cause is unexplained. I still think it is due to non-ui > > processes fiddling with morphs (likely delettion or creation). > > The Morphic event loop remains non-thread safe. We have some > > modifications to ensure thread safety, based on a generalised > > synchronisation protocol if anyone is interested. > > > > Regards, Gary > > ----- Original Message ----- > > From: Hernan Wilkinson > > To: Pharo-project(a)lists.gforge.inria.fr > > Sent: Monday, November 02, 2009 7:45 PM > > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > > > Hi Adrian, > > the current implementation has problems, ie. send messages to nil, > > and it bothers a lot when that happens because it comes from > > nowhere... > > I've been using this implementation for a long time in my images and > > I did not get those problems anymore (and it is more readable...) > > > > On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > Hi Hernan, > > > > The reason this was not integrated is that nobody marked it as 'fixed' > > nor tagged it as 1.0. > > > > Is this critical for 1.0? > > > > Cheers, > > Adrian > > > > BTW, if anybody sees changes/fixes not being integrated please ask on > > the mailing list. > > > > > > On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: > > > > > > > > > > > Begin forwarded message: > > > > > >> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > > >> Date: October 29, 2009 2:02:32 PM GMT+01:00 > > >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > >> Subject: MouseOverHandler > > >> > > >> Hi Stef, > > >> do you know why the MouseOverHandler version I made is not in the > > >> main image? the current version is not working well, under heavy > > >> use it generates exceptions... > > >> I'm attaching the version I wrote that I'm using without > > problem... > > >> > > >> Hernan. > > > <MouseOverHandler.st> > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 2, 2009

Re: [Pharo-project] Fwd: MouseOverHandler

by Schwab,Wilhelm K

Stef, Gary, Having recently ranted a little about thread safety for weak collection, how can I argue? Well, let me see if I can do so and keep my credibility intact :) Squeak's weak collections, and we have not moved beyond their limitations, do not clean themselves after their elements are finalized. That means they do half of what they should do; once they do all of it, they need to be thread safe; hence they do one third of what they should do. The GUI is arguably a little different. #addDeferredUIMessage: provides a clean way to interact with it from background threads, and that might be enough. IDE specific messages (e.g. #inspect) could probably stand to be queued to make them safe w/o horrible penalties, with the remainder of the GUI understood not to be thread safe for performance reasons. A backround thread can do expensive calculations and then queue a GUI update to safely update the display. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Monday, November 02, 2009 3:28 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: MouseOverHandler Hi gary do you think that it make sense to have it in general (my gut feeling is saying yes but I'm not thread-safe) If yes, yes we are interested for 1.1 BTW hernan I integrated your changes now it would be interesting to understand from where this nil is coming. Stef On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote: > Yet the cause is unexplained. I still think it is due to non-ui > processes fiddling with morphs (likely delettion or creation). > The Morphic event loop remains non-thread safe. We have some > modifications to ensure thread safety, based on a generalised > synchronisation protocol if anyone is interested. > > Regards, Gary > ----- Original Message ----- > From: Hernan Wilkinson > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, November 02, 2009 7:45 PM > Subject: Re: [Pharo-project] Fwd: MouseOverHandler > > Hi Adrian, > the current implementation has problems, ie. send messages to nil, > and it bothers a lot when that happens because it comes from > nowhere... > I've been using this implementation for a long time in my images and > I did not get those problems anymore (and it is more readable...) > > On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > Hi Hernan, > > The reason this was not integrated is that nobody marked it as 'fixed' > nor tagged it as 1.0. > > Is this critical for 1.0? > > Cheers, > Adrian > > BTW, if anybody sees changes/fixes not being integrated please ask on > the mailing list. > > > On Oct 31, 2009, at 14:29 , StÃ©phane Ducasse wrote: > > > > > > > Begin forwarded message: > > > >> From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > >> Date: October 29, 2009 2:02:32 PM GMT+01:00 > >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> Subject: MouseOverHandler > >> > >> Hi Stef, > >> do you know why the MouseOverHandler version I made is not in the > >> main image? the current version is not working well, under heavy > >> use it generates exceptions... > >> I'm attaching the version I wrote that I'm using without > problem... > >> > >> Hernan. > > <MouseOverHandler.st> > > > > _______________________________________________ > > 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

Nov. 2, 2009

[Pharo-project] Server sockets, ephermal ports, and a Linux VM crash

by Schwab,Wilhelm K

Hello all, Is there a preferred way to create TCP servers? KomServices and ConnectionQueue are options; there has been some discussion of the future of KomServices??? A nice trick is to use "ephmeral" ports, which is a fancy way of saying to pass zero for the listening port and let the OS assign a port. I have used that on Windows and it seems to work on Linux. TcpService does a lot to hide its listening socket; some small changes would allow it to use ephemeral ports. Any interest? They seem to work now, but there is no clean way to query the port that is ultimately chosen; the goal is to be able to so allocate a port and then send it to the other side for out of band communications. Perhaps related to my toying with port numbers (but I doubt that), I have had my older image crash a few times today. I created a TcpService on port zero, the listening socket gets a port and all seems reasonably well until I later inspect a few aspects of the TcpService, at which point the vm crashes. Bill

Nov. 2, 2009

[Pharo-project] IRC link in webpage is wrong

by Mariano Martinez Peck

If you go to http://www.pharo-project.org/community and see the link of " irc.freenode.net" you will see the link is http://www.pharo-project.org/irc.freenode.net but that is wrong. I think it should be irc://irc.freenode.net/#pharo-project This was reported in the IRC channel. Thanks to the reporter ;) Best regards, Mariano

Nov. 2, 2009