[Pharo-project] we need to find a way to declare that an action is UIless
hi guys I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that? [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. Stef
Stef, I could be wrong, but I suspect the correct path is to take the GUI manipulation out of the base classes, and if we are still so slow as to need some progress indication, it could be readily hacked (in a good way) as follows: (1) Transcript output, provided it works on the fly vs. appearing all at once at the end (I fear the latter might hold at present??) (2) via a good logging system and an external process (cross-platform analog to OutputDebugString() and DebugView on Windows) (3) trigger an event and let anything that wants to observe them, with nothing doing so by default. I would really like to see (2) grow as an option for us. I periodically do some work with Pharo on a particular Windows system (getting to be ever more rare in my world<g>), but I do greatly appreciate the real-time tracing. Even if we end up doing it with a separate image and sockets, it would be nice to have. The separate image could be a nice example of deploying an "executable" as well as a potential show piece for Polymorph. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Sunday, September 19, 2010 6:12 AM To: Pharo Development Subject: [Pharo-project] we need to find a way to declare that an action is UIless hi guys I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that? [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
    [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :) BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :) BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Slow access can be a big problem. Â Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
    [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. Guille On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [ siguctua@gmail.com]
Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes this was my exact point. Stef On Sep 20, 2010, at 4:56 AM, Guillermo Polito wrote:
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Guillermo, One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. Guille On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image? Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente, If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image? Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here: s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong. Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here: s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong. Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"? Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
the one running the gui ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"? Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible. Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente, Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible. Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes. If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it: Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork. What do you mean by "servers"? ConnectionQueue? Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente, We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one. ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes. If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it: Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork. What do you mean by "servers"? ConnectionQueue? Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory. And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around. Here is an example for a blocking connection without a timeout: Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_. Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente, I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands. Sockets don't decide when to free resources. Threads and users do. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory. And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around. Here is an example for a blocking connection without a timeout: Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_. Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Sep 23, 2010 at 10:01 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
Levente,
I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands.
Sockets don't decide when to free resources. Threads and users do.
Wilhelm, asking a socket to timeout after a while is /not/ a socket "deciding when to free resources". The socket doesn't decide for itself. The client of the socket, be that a server or a user or whatever, does.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory.
And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around.
Here is an example for a blocking connection without a timeout:
Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my
idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ leves@elte.hu]
Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ leves@elte.hu]
Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ leves@elte.hu]
Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ leves@elte.hu]
Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ leves@elte.hu]
Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com]
Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu <mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:
pharo-project-bounces@lists.gforge.inria.fr> [ pharo-project-bounces@lists.gforge.inria.fr<mailto: pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [ siguctua@gmail.com<mailto:siguctua@gmail.com>]
Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto: Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse < stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto: Pharo-project@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@lists.gforge.inria.fr<mailto: Pharo-project@lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:
Pharo-project@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@lists.gforge.inria.fr<mailto: Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot, The presumption is still incorrect, because it charms that time interval rather than the conditions, whether that be other network traffic, or simply whether the user is thinking "geez, I know that machine was up five minutes ago" or "just cancel already so I can type the correct address this time." Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda@gmail.com] Sent: Thursday, September 23, 2010 2:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, Sep 23, 2010 at 10:01 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Levente, I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands. Sockets don't decide when to free resources. Threads and users do. Wilhelm, asking a socket to timeout after a while is /not/ a socket "deciding when to free resources". The socket doesn't decide for itself. The client of the socket, be that a server or a user or whatever, does. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves@elte.hu<mailto:leves@elte.hu>] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory. And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around. Here is an example for a blocking connection without a timeout: Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_. Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves@elte.hu<mailto:leves@elte.hu>] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves@elte.hu<mailto:leves@elte.hu>] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves@elte.hu<mailto:leves@elte.hu>] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves@elte.hu<mailto:leves@elte.hu>] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves@elte.hu<mailto:leves@elte.hu>] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Guillermo Polito [guillermopolito@gmail.com<mailto:guillermopolito@gmail.com>] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr><mailto:stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands.
Oh really? Here is a simple example of a "timeout-free" server and a simple client that you can try in a workspace: "Start a new echo server on 127.0.0.1:12345" [ [ serverSocket := Socket new. serverSocket listenOn: 12345 backlogSize: 10 interface: #[127 0 0 1]. [ serverSocket statusString = 'waitingForConnection' ] whileTrue: [ serverSocket semaphore wait. serverSocket statusString = 'connected' ifTrue: [ | socket | socket := serverSocket accept. [ [ | data | data := socket receiveData. socket sendData: data. socket close ] ensure: [ socket destroy ] ] fork ] ]. serverSocket close ] ensure: [ serverSocket destroy ] ] fork. "Fire up a client which tests the above server and writes it's output to the Transcript." Transcript open. [ clientSocket := Socket new. clientSocket connectTo: #[127 0 0 1] port: 12345. clientSocket sendData: 'Hello Wolrd!'. Transcript show: clientSocket receiveData; cr. clientSocket close ] ensure: [ clientSocket destroy ]. "Stop the server" serverSocket close. If you know how to use Sockets, then it's really easy to do what you want.
Sockets don't decide when to free resources. Threads and users do.
That's right, user timeouts are optional as I showed you in various examples. Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory.
And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around.
Here is an example for a blocking connection without a timeout:
Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Please delve into #connectTo:port: - you will find a timeout there. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 7:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands.
Oh really? Here is a simple example of a "timeout-free" server and a simple client that you can try in a workspace: "Start a new echo server on 127.0.0.1:12345" [ [ serverSocket := Socket new. serverSocket listenOn: 12345 backlogSize: 10 interface: #[127 0 0 1]. [ serverSocket statusString = 'waitingForConnection' ] whileTrue: [ serverSocket semaphore wait. serverSocket statusString = 'connected' ifTrue: [ | socket | socket := serverSocket accept. [ [ | data | data := socket receiveData. socket sendData: data. socket close ] ensure: [ socket destroy ] ] fork ] ]. serverSocket close ] ensure: [ serverSocket destroy ] ] fork. "Fire up a client which tests the above server and writes it's output to the Transcript." Transcript open. [ clientSocket := Socket new. clientSocket connectTo: #[127 0 0 1] port: 12345. clientSocket sendData: 'Hello Wolrd!'. Transcript show: clientSocket receiveData; cr. clientSocket close ] ensure: [ clientSocket destroy ]. "Stop the server" serverSocket close. If you know how to use Sockets, then it's really easy to do what you want.
Sockets don't decide when to free resources. Threads and users do.
That's right, user timeouts are optional as I showed you in various examples. Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory.
And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around.
Here is an example for a blocking connection without a timeout:
Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Please delve into #connectTo:port: - you will find a timeout there.
As I said, only the server is timeout free. If you want a timeout-free example for a client, you can find one in this thread. Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 7:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands.
Oh really? Here is a simple example of a "timeout-free" server and a simple client that you can try in a workspace:
"Start a new echo server on 127.0.0.1:12345" [ [ serverSocket := Socket new. serverSocket listenOn: 12345 backlogSize: 10 interface: #[127 0 0 1]. [ serverSocket statusString = 'waitingForConnection' ] whileTrue: [ serverSocket semaphore wait. serverSocket statusString = 'connected' ifTrue: [ | socket | socket := serverSocket accept. [ [ | data | data := socket receiveData. socket sendData: data. socket close ] ensure: [ socket destroy ] ] fork ] ]. serverSocket close ] ensure: [ serverSocket destroy ] ] fork.
"Fire up a client which tests the above server and writes it's output to the Transcript." Transcript open. [ clientSocket := Socket new. clientSocket connectTo: #[127 0 0 1] port: 12345. clientSocket sendData: 'Hello Wolrd!'. Transcript show: clientSocket receiveData; cr. clientSocket close ] ensure: [ clientSocket destroy ].
"Stop the server" serverSocket close.
If you know how to use Sockets, then it's really easy to do what you want.
Sockets don't decide when to free resources. Threads and users do.
That's right, user timeouts are optional as I showed you in various examples.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory.
And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around.
Here is an example for a blocking connection without a timeout:
Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/9/24 Levente Uzonyi <leves@elte.hu>:
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Please delve into #connectTo:port: - you will find a timeout there.
As I said, only the server is timeout free. If you want a timeout-free example for a client, you can find one in this thread.
In your example a server won't work reliably, since 'socket sendData' as well as 'socket receiveData' may fail, and so, you will quit the process with unhandled error. This is what actually all of us don't want to see happened on mission critical services. If you don't sure how to use timeouts, and don't want to handle every tiny error, which can happen inside a server loop, then simply wrap it with error eater, then at least it won't stop serving requests. Even better approach is to set up a watchdog process, which checks that server is alive, and unconditionally terminates server process and starting a fresh new one, if there is no 'i'm still alive' signal received from server process in reasonable amount of time. Then you can minimize the service down time to period, which you using in your watchdog process.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 7:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
I never said that. Â I said that if it were built properly and used naively, it would have led to problems. Â Enter timeouts that should not be present. Â The server side is almost impossible to defend as it stands.
Oh really? Here is a simple example of a "timeout-free" server and a simple client that you can try in a workspace:
"Start a new echo server on 127.0.0.1:12345" [ Â Â Â [ Â Â Â Â Â Â Â serverSocket := Socket new. Â Â Â Â Â Â Â serverSocket listenOn: 12345 backlogSize: 10 interface: #[127 0 0 1]. Â Â Â Â Â Â Â [ serverSocket statusString = 'waitingForConnection' ] whileTrue: [ Â Â Â Â Â Â Â Â Â Â Â serverSocket semaphore wait. Â Â Â Â Â Â Â Â Â Â Â serverSocket statusString = 'connected' ifTrue: [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | socket | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket := serverSocket accept. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | data | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â data := socket receiveData. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket sendData: data. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket close ] Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ensure: [ socket destroy ] ] fork ] ]. Â Â Â Â Â Â Â serverSocket close ] ensure: [ serverSocket destroy ] ] fork.
"Fire up a client which tests the above server and writes it's output to the Transcript." Transcript open. [ Â Â Â clientSocket := Socket new. Â Â Â clientSocket connectTo: #[127 0 0 1] port: 12345. Â Â Â clientSocket sendData: 'Hello Wolrd!'. Â Â Â Transcript show: clientSocket receiveData; cr. Â Â Â clientSocket close ] ensure: [ clientSocket destroy ].
"Stop the server" serverSocket close.
If you know how to use Sockets, then it's really easy to do what you want.
Sockets don't decide when to free resources. Â Threads and users do.
That's right, user timeouts are optional as I showed you in various examples.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. Â I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. Â There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory.
And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around.
Here is an example for a blocking connection without a timeout:
Transcript open. [ Â Â Â | s | Â Â Â [ Â Â Â Â Â Â Â s := Socket new. Â Â Â Â Â Â Â s connectNonBlockingTo: #[172 16 0 1] port: 12345. Â Â Â Â Â Â Â Transcript show: 'Connecting...'; cr. Â Â Â Â Â Â Â [ s statusString = 'waitingForConnection' ] whileTrue: [ Â Â Â Â Â Â Â Â Â Â Â s semaphore wait. "No timeout." ]. Â Â Â Â Â Â Â Transcript show: s statusString; cr. Â Â Â Â Â Â Â s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. Â It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. Â The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [    | s |    [        s := Socket new.        s connectNonBlockingTo: #[172 16 0 1] port: 12345.        s            waitForConnectionFor: 10            ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ].        s isConnected ifTrue: [            Transcript show: 'Connected.'; cr. ].        s close ] ensure: [            s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Â Severs that listen for a limited time are broken by design. Â ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Â Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. Â But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. Â If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Â Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
   [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Fri, 24 Sep 2010, Igor Stasenko wrote:
2010/9/24 Levente Uzonyi <leves@elte.hu>: On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Please delve into #connectTo:port: - you will find a timeout there.
As I said, only the server is timeout free. If you want a timeout-free example for a client, you can find one in this thread.
In your example a server won't work reliably, since 'socket sendData' as well as 'socket receiveData' may fail, and so, you will quit the process with unhandled error. This is what actually all of us don't want to see happened on mission critical services. If you don't sure how to use timeouts, and don't want to handle every tiny error, which can happen inside a server loop, then simply wrap it with error eater, then at least it won't stop serving requests. Even better approach is to set up a watchdog process, which checks that server is alive, and unconditionally terminates server process and starting a fresh new one, if there is no 'i'm still alive' signal received from server process in reasonable amount of time. Then you can minimize the service down time to period, which you using in your watchdog process. The exampel is simple, not complete. The error in #sendData and #receiveData won't kill the server, just the process which had the error. There are plenty of other possible error sources in that code. The point of the example is that you can accept connections without defining timeouts, because timeouts are why Bill considers the current Socket implementation crap. Levente
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 7:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
I never said that. Â I said that if it were built properly and used naively, it would have led to problems. Â Enter timeouts that should not be present. Â The server side is almost impossible to defend as it stands.
Oh really? Here is a simple example of a "timeout-free" server and a simple client that you can try in a workspace:
"Start a new echo server on 127.0.0.1:12345" [ Â Â Â [ Â Â Â Â Â Â Â serverSocket := Socket new. Â Â Â Â Â Â Â serverSocket listenOn: 12345 backlogSize: 10 interface: #[127 0 0 1]. Â Â Â Â Â Â Â [ serverSocket statusString = 'waitingForConnection' ] whileTrue: [ Â Â Â Â Â Â Â Â Â Â Â serverSocket semaphore wait. Â Â Â Â Â Â Â Â Â Â Â serverSocket statusString = 'connected' ifTrue: [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | socket | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket := serverSocket accept. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | data | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â data := socket receiveData. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket sendData: data. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket close ] Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ensure: [ socket destroy ] ] fork ] ]. Â Â Â Â Â Â Â serverSocket close ] ensure: [ serverSocket destroy ] ] fork.
"Fire up a client which tests the above server and writes it's output to the Transcript." Transcript open. [ Â Â Â clientSocket := Socket new. Â Â Â clientSocket connectTo: #[127 0 0 1] port: 12345. Â Â Â clientSocket sendData: 'Hello Wolrd!'. Â Â Â Transcript show: clientSocket receiveData; cr. Â Â Â clientSocket close ] ensure: [ clientSocket destroy ].
"Stop the server" serverSocket close.
If you know how to use Sockets, then it's really easy to do what you want.
Sockets don't decide when to free resources. Â Threads and users do.
That's right, user timeouts are optional as I showed you in various examples.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. Â I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. Â There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory.
And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around.
Here is an example for a blocking connection without a timeout:
Transcript open. [ Â Â Â | s | Â Â Â [ Â Â Â Â Â Â Â s := Socket new. Â Â Â Â Â Â Â s connectNonBlockingTo: #[172 16 0 1] port: 12345. Â Â Â Â Â Â Â Transcript show: 'Connecting...'; cr. Â Â Â Â Â Â Â [ s statusString = 'waitingForConnection' ] whileTrue: [ Â Â Â Â Â Â Â Â Â Â Â s semaphore wait. "No timeout." ]. Â Â Â Â Â Â Â Transcript show: s statusString; cr. Â Â Â Â Â Â Â s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. Â It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. Â The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [    | s |    [        s := Socket new.        s connectNonBlockingTo: #[172 16 0 1] port: 12345.        s            waitForConnectionFor: 10            ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ].        s isConnected ifTrue: [            Transcript show: 'Connected.'; cr. ].        s close ] ensure: [            s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Â Severs that listen for a limited time are broken by design. Â ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Â Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. Â But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. Â If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Â Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
   [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/9/24 Levente Uzonyi <leves@elte.hu>:
On Fri, 24 Sep 2010, Igor Stasenko wrote:
2010/9/24 Levente Uzonyi <leves@elte.hu>: On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Please delve into #connectTo:port: - you will find a timeout there.
As I said, only the server is timeout free. If you want a timeout-free example for a client, you can find one in this thread.
In your example a server won't work reliably, since 'socket sendData' as well as 'socket receiveData' may fail, and so, you will quit the process with unhandled error.
This is what actually all of us don't want to see happened on mission critical services.
If you don't sure how to use timeouts, and don't want to handle every tiny error, which can happen inside a server loop, then simply wrap it with error eater, then at least it won't stop serving requests.
Even better approach is to set up a watchdog process, which checks that server is alive, and unconditionally terminates server process and starting a fresh new one, if there is no 'i'm still alive' signal received from server process in reasonable amount of time. Then you can minimize the service down time to period, which you using in your watchdog process.
The exampel is simple, not complete. The error in #sendData and #receiveData won't kill the server, just the process which had the error. There are plenty of other possible error sources in that code. The point of the example is that you can accept connections without defining timeouts, because timeouts are why Bill considers the current Socket implementation crap.
Its not a crap. But there are always space for improvement.
Levente
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 7:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
I never said that. Â I said that if it were built properly and used naively, it would have led to problems. Â Enter timeouts that should not be present. Â The server side is almost impossible to defend as it stands.
Oh really? Here is a simple example of a "timeout-free" server and a simple client that you can try in a workspace:
"Start a new echo server on 127.0.0.1:12345" [ Â Â Â [ Â Â Â Â Â Â Â serverSocket := Socket new. Â Â Â Â Â Â Â serverSocket listenOn: 12345 backlogSize: 10 interface: #[127 0 0 1]. Â Â Â Â Â Â Â [ serverSocket statusString = 'waitingForConnection' ] whileTrue: [ Â Â Â Â Â Â Â Â Â Â Â serverSocket semaphore wait. Â Â Â Â Â Â Â Â Â Â Â serverSocket statusString = 'connected' ifTrue: [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | socket | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket := serverSocket accept. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | data | Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â data := socket receiveData. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket sendData: data. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â socket close ] Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ensure: [ socket destroy ] ] fork ] ]. Â Â Â Â Â Â Â serverSocket close ] ensure: [ serverSocket destroy ] ] fork.
"Fire up a client which tests the above server and writes it's output to the Transcript." Transcript open. [ Â Â Â clientSocket := Socket new. Â Â Â clientSocket connectTo: #[127 0 0 1] port: 12345. Â Â Â clientSocket sendData: 'Hello Wolrd!'. Â Â Â Transcript show: clientSocket receiveData; cr. Â Â Â clientSocket close ] ensure: [ clientSocket destroy ].
"Stop the server" serverSocket close.
If you know how to use Sockets, then it's really easy to do what you want.
Sockets don't decide when to free resources. Â Threads and users do.
That's right, user timeouts are optional as I showed you in various examples.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
We can twist words indefinitely. Â I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. Â There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one.
My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory.
And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around.
Here is an example for a blocking connection without a timeout:
Transcript open. [ Â Â Â | s | Â Â Â [ Â Â Â Â Â Â Â s := Socket new. Â Â Â Â Â Â Â s connectNonBlockingTo: #[172 16 0 1] port: 12345. Â Â Â Â Â Â Â Transcript show: 'Connecting...'; cr. Â Â Â Â Â Â Â [ s statusString = 'waitingForConnection' ] whileTrue: [ Â Â Â Â Â Â Â Â Â Â Â s semaphore wait. "No timeout." ]. Â Â Â Â Â Â Â Transcript show: s statusString; cr. Â Â Â Â Â Â Â s close ] ensure: [ s destroy ] ] fork.
ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. Â It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs.
ConnectionQueue is just a high level API, you can always use _Sockets_.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 11:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. Â The client code is bad enough; the servers are horrible.
If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes.
If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it:
Transcript open. [ 10 timesRepeat: [    | s |    [        s := Socket new.        s connectNonBlockingTo: #[172 16 0 1] port: 12345.        s            waitForConnectionFor: 10            ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ].        s isConnected ifTrue: [            Transcript show: 'Connected.'; cr. ].        s close ] ensure: [            s ifNotNil: [ s destroy ] ] ] ] fork.
What do you mean by "servers"? ConnectionQueue?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
the one running the gui
In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible.
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 10:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Scratch around, and you will find that the time limits are there to allow calls to made on the main thread.
Where? In the Socket class? And what's the "main thread"?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 8:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Levente,
If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Â Severs that listen for a limited time are broken by design. Â ConnectionQueue polls as a result - it's pretty bad.
I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here:
s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc."
And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 7:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Guillermo,
One has to be careful with assuming that something affects only part of the image. Â Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. Â But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe.
When does a Socket block the image?
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito@gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
+1 to Bill's. Â If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S.
And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image.
Guille
On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
Slow access can be a big problem. Â Any such change should be made based on measurements so we know what benefit we get at what cost.
Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class...
________________________________________ From:
pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>
[pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Sunday, September 19, 2010 7:56 PM To:
Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
   [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
This is not the point :) I know the extension. I wanted to check if I can do the change to follow CUIS design and the system is not robust enough to let me change it wile running it. Stef On Sep 20, 2010, at 1:56 AM, Igor Stasenko wrote:
On 19 September 2010 13:12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
use morph propertyAt: #borderStyle so you don't have to break your head with it :)
BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Stef, this is a tricky thing to do from _within_ Morphic, because even if you avoid progress notification completely during recompilation by doing something like this in a workspace [ ClassBuilder beSilent: true. Morph subclass: #BorderedMorph instanceVariableNames: 'borderWidth borderColor borderStyle' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Kernel'. ] ensure: [ ClassBuilder beSilent: false] the recompilation will succeed, but you'll end up with an error from the TextMorph (or subclass of it) of the workspace you've "done" this code in, because it is also a subclass of BorderedMorph.You can ignore the debugger or wrap that code in an error handler that just does a resume, but yes ... it's not ideal. Alex 2010/9/19 Stéphane Ducasse <stephane.ducasse@inria.fr>:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
    [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi alexander I did: BloclClosure>>silent ^[ self value ] on: ProgressInitiationException do: [ :ex | ex sendNotificationsTo: [ :min :max :curr | Transcript show: min printString,' ',max printString,' ',curr printString; cr ]. ]. On Sep 20, 2010, at 10:33 AM, Alexander LazareviÄ wrote:
Hi Stef,
this is a tricky thing to do from _within_ Morphic, because even if you avoid progress notification completely during recompilation by doing something like this in a workspace
[ ClassBuilder beSilent: true.
Morph subclass: #BorderedMorph instanceVariableNames: 'borderWidth borderColor borderStyle' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Kernel'.
] ensure: [ ClassBuilder beSilent: false]
the recompilation will succeed, but you'll end up with an error from the TextMorph (or subclass of it) of the workspace you've "done" this code in, because it is also a subclass of BorderedMorph.
Yes I got it too :)
You can ignore the debugger or wrap that code in an error handler that just does a resume, but yes ... it's not ideal.
Alex
2010/9/19 Stéphane Ducasse <stephane.ducasse@inria.fr>:
hi guys
I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. So we should really have a way to specify silent ui action. Does anybody have an idea how I could do that?
[BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Alexander LazareviÄ -
Eliot Miranda -
Guillermo Polito -
Igor Stasenko -
Levente Uzonyi -
Schwab,Wilhelm K -
Stéphane Ducasse