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

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Igor Stasenko

2010/9/24 Levente Uzonyi <leves(a)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(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >> [leves(a)elte.hu] >> Sent: Thursday, September 23, 2010 7:04 PM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>> [leves(a)elte.hu] >>> Sent: Thursday, September 23, 2010 12:25 PM >>> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>>> [leves(a)elte.hu] >>>> Sent: Wednesday, September 22, 2010 11:51 PM >>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>>>> [leves(a)elte.hu] >>>>> Sent: Wednesday, September 22, 2010 9:55 PM >>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>>>>> [leves(a)elte.hu] >>>>>> Sent: Monday, September 20, 2010 10:14 PM >>>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>>>>>> [leves(a)elte.hu] >>>>>>> Sent: Monday, September 20, 2010 8:13 PM >>>>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>>>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>>>>>>> [leves(a)elte.hu] >>>>>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr >>>>>>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito >>>>>>>>> [guillermopolito(a)gmail.com] >>>>>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>>>>> To: Pharo-project(a)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(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K >>>>>>>>> <bschwab(a)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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> >>>>>>>>>> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] >>>>>>>>>> On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>>>>> To: >>>>>>>>>> Pharo-project(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Thursday, September 23, 2010 7:04 PM > To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Thursday, September 23, 2010 12:25 PM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Wednesday, September 22, 2010 11:51 PM >>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Wednesday, September 22, 2010 9:55 PM >>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>> Sent: Monday, September 20, 2010 10:14 PM >>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>>> Sent: Monday, September 20, 2010 8:13 PM >>>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>>>> To: Pharo-project(a)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(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>>>> To: Pharo-project(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Please delve into #connectTo:port: - you will find a timeout there. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Thursday, September 23, 2010 7:04 PM To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Thursday, September 23, 2010 12:25 PM > To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Wednesday, September 22, 2010 11:51 PM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Wednesday, September 22, 2010 9:55 PM >>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Monday, September 20, 2010 10:14 PM >>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>> Sent: Monday, September 20, 2010 8:13 PM >>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>>> To: Pharo-project(a)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(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>>> To: Pharo-project(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] Launching class form command line ...

by David T. Lewis

On Tue, Sep 21, 2010 at 04:44:19PM +0200, Henrik Johansen wrote: > > On Sep 21, 2010, at 4:21 22PM, Nicolas Cellier wrote: > > > 2010/9/21 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> On Sep 21, 2010, at 8:16 53AM, Lukas Renggli wrote: > >> > >>>> How does Pharo execute classes from the command line? > >>> > >>> You can pass the filename of a .cs/.st file to the VM that gets > >>> filed-in on startup. > >>> > >>>> Is there a way to specify the class and the method to be called? > >>> > >>> Not directly. > >>> > >>>> Are command line arguments available? > >>> > >>> $ squeak --help > >>> Usage: squeak [<option>...] [<imageName> [<argument>...]] > >>> squeak [<option>...] -- [<argument>...] > >>> > >> > >> BTW, dunno if it's a crossplatform Cog issue ( haven't checked others) but in John's new OSX Cog-based VMs (last tested 5.8b9), it doesn't look like the arguments are present in systemAttributes at position 2 onwards. > >> Thus, ProjectLauncher will fail to execute scripts at all. > >> > >> > >> In -help: > >>> -encoding <enc> set the internal character encoding (default: MacRoman) > >> > >> Sounds strangel, should probably be updated to Latin1/ removed (depending on how it's actually used)? > >> > > > > I bet less than 1 out of 1000 machines running squeak shall use this > > MacRoman thing nowadays. > > > > Nicolas > > Just ran -help on 5.2.5 and 5.8b9, the -encoding option is not mentioned in any of those. > > The only current use case I could think of would be Cuis, who might want to set it to Latin15 in order to interpret ? correctly. > Sure, the StrikeFonts (taken from Cuis) included in Pharo/Squeak actually cover Latin15 as well, but everywhere else, encoding of ByteStrings is assumed to be Latin1... > So better with some visual discrepancies, namely displaying ? as ?, ? as ?, etc. than reading/writing the wrong characters to/from external sources Regarding command line arguments available to the image, see #getSystemAttribute: Squeak has #argumentAt: for getting command line options passed to the image. This is no longer present in Pharo, but the implementation is just this: argumentAt: i "Answer the i-th argument of the command line, or nil if not so many argument." ^self getSystemAttribute: 2 + i Dave

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Thursday, September 23, 2010 12:25 PM > To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Wednesday, September 22, 2010 11:51 PM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Wednesday, September 22, 2010 9:55 PM >>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Monday, September 20, 2010 10:14 PM >>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>> Sent: Monday, September 20, 2010 8:13 PM >>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>>> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>>> To: Pharo-project(a)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(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>>> To: Pharo-project(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] Multiple finalizers per single object

by Igor Stasenko

On 24 September 2010 00:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > No argument here. Â In fact, I'll raise you :) Â Weak collections in general, not just the finalizer registry, need to repair themselves in a thread-safe manner. > > Â http://thread.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/15001/focus=1… > Â http://article.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/14732 > > * Weak collections are of reduced value if they hang onto empty slots. > * Enter a high-priority thread to strip away such junk; the weaklings must now be threadsafe. > * You and others come along wanting to do things like #at:ifAbsentPut: (ensuring one-off registration, etc.) and suddenly find that you are doing this via a thread-safe collection that can get this stuff right. > Bill, weak collections are thread-safe, if you using them correctly. :) All weaklings dying in thread-safe manner when GC sweeps garbage, and replaced by nils. This is an atomic operation, seen from language side and having no chance to be interrupted. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Thursday, September 23, 2010 4:23 PM > To: The general-purpose Squeak developers list; Pharo Development; Levente Uzonyi > Subject: [Pharo-project] Multiple finalizers per single object > > Hello, > > i'd like to raise this subject once more, because i don't like it (or > don't understand?). > > In all scenarios, where i met the need to use finalization, a single > finalizer is sufficient. > Moreover, there is always a single object who controls a weak > reference, and it never leaks it out, to prevent > the case, when some other object may obtain a strong reference on it, > making it permanently held in object memory. > > Multiple different finalizers for single object, from design point of > view, means that you having two different, not related frameworks, > which using same object, and want to do something when it dies. > A scenario, where its possible and userful, still don't comes into my mind. > In contrary, whenever i see a use of finalizers, its in most cases > about graceful control over external resource, such as: > - file > - socket > - external memory > > and i really don't see how multiple finalizers per single resource > could do any good. > > Suppose one finalizer closing a file handle, while another one > flushing it buffer cache. > Now, how you going to ensure, that one finalizer will execute first, > before another one? > And what if third framework comes into play and wants to add another > finalizer on top of that, which should do something in the middle > between flushing a cache and closing file handle? > > From the above, the only conclusion can be made: use a single > finalizer, and put all logic & operation ordering into it. > And also, prevent leakage of object pointer (such as file handle) > outside of your model, otherwise it may cause harm. > > That's why i think a current WeakRegistry model provoking bad design practices. > I think a better behavior would be to raise an error, if something > wants to register finalizer twice for a single object. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] GSoC Project for Namespaces

by Guillermo Polito

Great! On Thu, Sep 23, 2010 at 7:09 PM, James Foster <Smalltalk(a)jgfoster.net>wrote: > GermÃ¡n Leiva was accepted in Google Summer of Code 2010 and developed a > Namespaces implementation for Pharo Smalltalk. A video at > http://www.youtube.com/watch?v=n4I7fSVNX2A is based on his presentation at > ESUG in Barcelona last week. You can get the code at > http://www.squeaksource.com/Environments.html. > > James Foster > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

[Pharo-project] GSoC Project for Namespaces

by James Foster

GermÃ¡n Leiva was accepted in Google Summer of Code 2010 and developed a Namespaces implementation for Pharo Smalltalk. A video at http://www.youtube.com/watch?v=n4I7fSVNX2A is based on his presentation at ESUG in Barcelona last week. You can get the code at http://www.squeaksource.com/Environments.html. James Foster

Sept. 23, 2010

Re: [Pharo-project] XMLRPC Project - Progress Report

by GermÃ¡n Arduino

ok, ConfigurationOfXMLRPC is on MetacelloRepository, documentation on #workspace method. Suggestions or corrections from the Metacello experts are more than welcome. Next Step: The real work start now :) Cheers. GermÃ¡n. 2010/9/23 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, Sep 23, 2010 at 12:49 AM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: >> >> El miÃ©, 22-09-2010 a las 19:16 -0300, GermÃ¡n Arduino escribiÃ³: >> > Hi Everybody: >> > >> > I reorganized the XMLRPC packages, integrating the changes of Skrish >> > (currently on PharoGoodies) renaming the packages in four categories: >> > >> > XMLRPC-Client-Core >> > XMLRPC-Client-Tests >> > XMLRPC-Server-Core >> > XMLRPC-Server-Tests >> > >> > Next step: Build the following metacello configurations: >> > >> > ConfigurationOfXMLRPCClient >> > ConfigurationOfXMLRPCServer >> > ConfigurationOfXMLRPCAll >> >> You don't need three configurations, just create one and create 3 groups >> 'All','Server', 'Client'. >> > > You were faster than :) I was going to answer exactly the same...one > ConfigurationOfXMLRPC and different groups: > - 'All' > - 'Server' > - 'Server with Tests' > - 'Client' > - 'Client with Tests' > -etc.... > > Check ConfigurationOfMagma since it does almost the same I think. > > cheers > > mariano > >> Cheers >> > >> > >> > I want to ask to any person wanting to contribute with XMLRPC project >> > take contact with me to coordinate efforts. >> > >> > >> > Cheers. >> > >> > >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] Multiple finalizers per single object

by Schwab,Wilhelm K

Sig, No argument here. In fact, I'll raise you :) Weak collections in general, not just the finalizer registry, need to repair themselves in a thread-safe manner. http://thread.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/15001/focus=1… http://article.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/14732 * Weak collections are of reduced value if they hang onto empty slots. * Enter a high-priority thread to strip away such junk; the weaklings must now be threadsafe. * You and others come along wanting to do things like #at:ifAbsentPut: (ensuring one-off registration, etc.) and suddenly find that you are doing this via a thread-safe collection that can get this stuff right. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, September 23, 2010 4:23 PM To: The general-purpose Squeak developers list; Pharo Development; Levente Uzonyi Subject: [Pharo-project] Multiple finalizers per single object Hello, i'd like to raise this subject once more, because i don't like it (or don't understand?). In all scenarios, where i met the need to use finalization, a single finalizer is sufficient. Moreover, there is always a single object who controls a weak reference, and it never leaks it out, to prevent the case, when some other object may obtain a strong reference on it, making it permanently held in object memory. Multiple different finalizers for single object, from design point of view, means that you having two different, not related frameworks, which using same object, and want to do something when it dies. A scenario, where its possible and userful, still don't comes into my mind. In contrary, whenever i see a use of finalizers, its in most cases about graceful control over external resource, such as: - file - socket - external memory and i really don't see how multiple finalizers per single resource could do any good. Suppose one finalizer closing a file handle, while another one flushing it buffer cache. Now, how you going to ensure, that one finalizer will execute first, before another one? And what if third framework comes into play and wants to add another finalizer on top of that, which should do something in the middle between flushing a cache and closing file handle? >From the above, the only conclusion can be made: use a single finalizer, and put all logic & operation ordering into it. And also, prevent leakage of object pointer (such as file handle) outside of your model, otherwise it may cause harm. That's why i think a current WeakRegistry model provoking bad design practices. I think a better behavior would be to raise an error, if something wants to register finalizer twice for a single object. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010