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

[Pharo-project] [ANN] Hackers wanted - Zinc HTTP Components

by Sven Van Caekenberghe

Fellow Pharoers, HTTP is arguably the most important and most widely used networking protocol. It is paramount for any programming environment to have a good implementation of this protocol. Sadly, the current one in HTTPSocket is incomplete and of low quality. Furthermore, an HTTP implementation in Smalltalk should be clear enough so that others can understand it, learn from it and extend it. Zinc HTTP Components is an attempt at filling this gap. Started September 1st and currently under development, it is an open source, MIT licensed, open development Smalltalk framework to deal with the HTTP protocol. Please have a look at it, please help make this something we can be proud of. http://www.squeaksource.com/ZincHTTPComponents.html http://homepage.mac.com/svc/Zinc-HTTP-Components/index.html http://homepage.mac.com/svc/Zinc-HTTP-Components/getting-started.html Check out what works today (Status) and what still needs to be done (Todo). HTTP is fun, relatively easy and is something every programmer should understand, I hope that Zinc HTTP Components can make a difference here. Sven

Sept. 24, 2010

Re: [Pharo-project] Pharo Mailing List on MarkMail

by Mariano Martinez Peck

On Fri, Sep 24, 2010 at 11:04 AM, Alberto Bacchelli < alberto.bacchelli(a)usi.ch> wrote: > On 9/24/10 10:02 AM, Mariano Martinez Peck wrote: > >> Thanks for the initiative. >> >> which are the advantages over http://forum.world.st/Pharo-f1294836.html ? >> > > First of all, unfortunately, I was not aware of the existence of such link. > I see that it is in the http://pharo-project.org/community page, but I > missed it. Shame on me. > > I use Markmail quite often, and I find it to have a very intuitive > interface and to present results very quickly. I also like the interactive > bar chart, and that you can refine your searches step-by-step in real time. > Finally, I like how messages are displayed: it is very clean and simple. > > Anyway, the more the merrier: Now one can pick the preferred one among > Nabble, Gmane, and Markmail! > > Yes, excellent. We can ask Adrian to add it in http://pharo-project.org/community too. Cheers mariano > > Ciao, > Alberto > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2010

Re: [Pharo-project] Pharo Mailing List on MarkMail

by Alberto Bacchelli

On 9/24/10 10:02 AM, Mariano Martinez Peck wrote: > Thanks for the initiative. > > which are the advantages over http://forum.world.st/Pharo-f1294836.html ? First of all, unfortunately, I was not aware of the existence of such link. I see that it is in the http://pharo-project.org/community page, but I missed it. Shame on me. I use Markmail quite often, and I find it to have a very intuitive interface and to present results very quickly. I also like the interactive bar chart, and that you can refine your searches step-by-step in real time. Finally, I like how messages are displayed: it is very clean and simple. Anyway, the more the merrier: Now one can pick the preferred one among Nabble, Gmane, and Markmail! Ciao, Alberto

Sept. 24, 2010

Re: [Pharo-project] Pharo Mailing List on MarkMail

by Mariano Martinez Peck

Thanks for the initiative. which are the advantages over http://forum.world.st/Pharo-f1294836.html ? cheers mariano On Fri, Sep 24, 2010 at 9:22 AM, Alberto Bacchelli <alberto.bacchelli(a)usi.ch > wrote: > Hi, > > MarkMail [1] is a very nice web service for searching emails in mailing > list archives. It also registers to the mailing lists that it archives, so > it is always updated. > > A few days ago, I wrote to the administrators to ask them to add the > pharo mailing list to their service. > They just wrote me that the Pharo archive is up! > > You can reach the Pharo archive directly from this address, > and compose the queries you want: > http://pharo.markmail.org/ > > I hope this will be useful for everybody. > > Ciao, > Alberto > > > [1] http://markmail.org/ > [2] http://pharo.markmail.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2010

Re: [Pharo-project] Pharo Mailing List on MarkMail

by laurent laffont

On Fri, Sep 24, 2010 at 9:22 AM, Alberto Bacchelli <alberto.bacchelli(a)usi.ch > wrote: > Hi, > > MarkMail [1] is a very nice web service for searching emails in mailing > list archives. It also registers to the mailing lists that it archives, so > it is always updated. > > A few days ago, I wrote to the administrators to ask them to add the > pharo mailing list to their service. > They just wrote me that the Pharo archive is up! > > You can reach the Pharo archive directly from this address, > and compose the queries you want: > http://pharo.markmail.org/ > > I hope this will be useful for everybody. > I like it. Thank you. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > > Ciao, > Alberto > > > [1] http://markmail.org/ > [2] http://pharo.markmail.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2010

[Pharo-project] Pharo Mailing List on MarkMail

by Alberto Bacchelli

Hi, MarkMail [1] is a very nice web service for searching emails in mailing list archives. It also registers to the mailing lists that it archives, so it is always updated. A few days ago, I wrote to the administrators to ask them to add the pharo mailing list to their service. They just wrote me that the Pharo archive is up! You can reach the Pharo archive directly from this address, and compose the queries you want: http://pharo.markmail.org/ I hope this will be useful for everybody. Ciao, Alberto [1] http://markmail.org/ [2] http://pharo.markmail.org/

Sept. 24, 2010

[Pharo-project] Smalltalks 2010 --- Registration and invitation

by Andres Valloud

======== INGLES The FundaciÃ³n Argentina de Smalltalk (FAST) invites you to the 4th Smalltalk Conference of Argentina, to be held on November 11, 12 and 13, 2010 at the ConcepciÃ³n del Uruguay site of the Universidad TecnolÃ³gica Nacional. Everyone, including teachers, students, researchers, developers and entrepreneurs, are welcome as speakers or attendees. Registration is free and now open athttp://www.fast.org.ar. The goal of the conference is to strengthen the Argentine and international Smalltalk community through the exchange of works, experiences and anecdotes connected with this technology or related matters. Renowned members of the international Smalltalk community will visit the conference. Moreover, this edition of the conference will have a Research Session with publications reviewed by an international committee, as well as an Industry Track for those preferring a more relaxed environment. We look forward to see your submissions. You can propose papers or talks know through our website, or by sending an email toinfo(a)fast.org.ar. See you there! ======== SPANISH La FundaciÃ³n Argentina de Smalltalk (FAST) los invita a la 4ta Conferencia de Smalltalk de Argentina, a realizarse desde el 11 al 13 de Noviembre del 2010 en la sede de ConcepciÃ³n del Uruguay de la Universidad TecnolÃ³gica Nacional. Esperamos verlos a todos entre la audiencia o como oradores, ya sean profesores, estudiantes, investigadores, desarrolladores o empresarios. La registraciÃ³n es gratis y estÃ¡ disponible enhttp://www.fast.org.ar. El objetivo de la conferencia es afianzar los vÃnculos entre las comunidades Smalltalk de Argentina y del mundo, a travÃ©s del intercambio de trabajos, experiencias y vivencias conectadas con esta tecnologÃa. De hecho, este aÃ±o nos visitarÃ¡n personalidades de renombre de la comunidad internacional. AdemÃ¡s, en esta ediciÃ³n de la conferencia tendremos un track de investigaciÃ³n formal con publicaciones y referato de un comitÃ© internacional. TambiÃ©n tendremos un track de industria para aquellos que prefieran un ambiente mÃ¡s informal. Pueden enviarnos sus propuestas de charlas o papers mediante nuestra pÃ¡gina web, o enviÃ¡ndonos un mail ainfo(a)fast.org.ar. Nos vemos en la conferencia!

Sept. 24, 2010

[Pharo-project] [Digest] Opal Compiler

by StÃ©phane Ducasse

A little digest of the Opal activity. Thanks marcus, jorge and jb Name: OpalCompiler-Core-MarcusDenker.39 Author: MarcusDenker Time: 22 September 2010, 12:49:03 pm UUID: f0990355-584c-4f3e-b72e-4ef73c915e20 Ancestors: OpalCompiler-Core-JorgeRessia.38 -> escaping now destinguishes between escapingRead and escapingWrite -> write on an escapingRead Temp makes it escapingWrite, too -> fixed ASTranslator to correctly use the copying vars of the outer scope when calling IRBuilder to create a block -> Cleanups Name: OpalCompiler-Core-JorgeRessia.41 Author: JorgeRessia Time: 22 September 2010, 7:28:07 pm UUID: a22e64f9-0181-45a0-a531-2b929c2bd969 Ancestors: OpalCompiler-Core-MarcusDenker.40 - fixing optimezed blocks remote temps Name: OpalCompiler-Core-JorgeRessia.42 Author: JorgeRessia Time: 23 September 2010, 10:48:37 am UUID: b144fc34-6ed0-4acd-a538-3dd8fa386143 Ancestors: OpalCompiler-Core-JorgeRessia.41 Fixing optimized Block analysis Name: OpalCompiler-Tests-JorgeRessia.41 Author: JorgeRessia Time: 23 September 2010, 11:26 am UUID: f0c522bc-5b78-442f-942c-181e4fe03f98 Ancestors: OpalCompiler-Tests-JorgeRessia.40 New cases for the optimized blocks Name: OpalCompiler-Tests-JorgeRessia.43 Author: JorgeRessia Time: 23 September 2010, 2:29:09 pm UUID: dcca39e4-660f-4a9e-9349-021743f3773b Ancestors: OpalCompiler-Tests-JorgeRessia.42 Lexical Analysis and Closure Analysis green tests Name: OpalCompiler-Core-JorgeRessia.43 Author: JorgeRessia Time: 23 September 2010, 2:02:56 pm UUID: 8208019f-9941-4279-b969-ed5c63a92fc2 Ancestors: OpalCompiler-Core-JorgeRessia.42 Fixing optimized Block analysis Name: OpalCompiler-Core-JorgeRessia.45 Author: JorgeRessia Time: 23 September 2010, 7:20:04 pm UUID: e3dbc461-ba42-4153-af21-bf321b07f131 Ancestors: OpalCompiler-Core-JorgeRessia.44 Refactoring and fixing code ==================== Summary ==================== Name: OpalCompiler-Core-JorgeRessia.44 Author: JorgeRessia Time: 23 September 2010, 6:10:02 pm UUID: 971894ca-6ca7-4f21-9ac2-bb1c47be0958 Ancestors: OpalCompiler-Core-JorgeRessia.43 - Fixed problems with optimized block in the semantic analysis - Fixed bug with the copied temp in a block in the semantic analysis. - new test for special cases of optimized loops. - fixed ASTClosureAnalysisTest for testing the copied values.

Sept. 24, 2010

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 Fri, 24 Sep 2010, Igor Stasenko wrote: > >> 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. > > > 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(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. > > _______________________________________________ > 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. 24, 2010

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

by Levente Uzonyi

On Fri, 24 Sep 2010, Igor Stasenko wrote: > 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. 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(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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 24, 2010