January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Congrats

by Igor Stasenko

> The Royal Academy of Engineering recognizes a researcher at INRIA > > Stephane Ducasse Â© INRIA > > StÃ©phane Ducasse, Director of Research Rmod team, was awarded the > Distinguished Visiting Fellowship Award. > > The objective of this award is multiple: > > * Promote joint initiatives and complementary that could form the basis for > future collaboration and strategic alliance research > * Allow the sharing of latest developments, experiences and knowledge of > various fields of engineering and technology > > It is in this context of international exchanges and collaborations, > StÃ©phane Ducasse has been discerned a visitor price Emeritus, by the Royal > Academy of Engineering (Distinguished Visiting Fellowship Award). > > As supported by a research team English at York University, he spent three > weeks with daily team of Manuel Oriol, whose research focuses on software > engineering and testing automated software engineering. > Keywords: > Still i don't get it, what the catch? :) Sounds like Stef will be away for 3 weeks, right? -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2011

[Pharo-project] "Bindable" or "Observable" collections on Pharo/Smalltalk?

by nullPointer

Hi, excuse me for my poor english. Exist some type of collection for bind to widgets like a listView or grid? I want say a special collection than allow know, externally, when a object is added, removed, changed the "current" etc for represent changes on a GUI. For example, I have a collection connected on a grid. When I add or remove a element on collection I have refresh the grid set again the collection like datasource, and select the same object of before. That is hard for the widget when I have very items. I want "capture", with events or others, and remove only the row of grid, and not refresh all again. I donÂ´t know if I do the question correctly. Regards -- View this message in context: http://forum.world.st/Bindable-or-Observable-collections-on-Pharo-Smalltalk… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 14, 2011

Re: [Pharo-project] Congrats

by Jimmie Houchin

On 1/14/2011 1:41 PM, Steven Baker wrote: > I can't find an english translation. Can someone summarize this in > english for me? > > Thanks, > -Steven > > On Fri, Jan 14, 2011 at 8:17 AM, Miguel CobÃ¡<miguel.coba(a)gmail.com> wrote: >> Congrats StÃ©ph, >> >> http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/actualites/… Congratulations Stef. Steven, here is a rough translation provided by http://translate.google.com HTH. Jimmie The Royal Academy of Engineering recognizes a researcher at INRIA Stephane Ducasse Â© INRIA StÃ©phane Ducasse, Director of Research Rmod team, was awarded the Distinguished Visiting Fellowship Award. The objective of this award is multiple: * Promote joint initiatives and complementary that could form the basis for future collaboration and strategic alliance research * Allow the sharing of latest developments, experiences and knowledge of various fields of engineering and technology It is in this context of international exchanges and collaborations, StÃ©phane Ducasse has been discerned a visitor price Emeritus, by the Royal Academy of Engineering (Distinguished Visiting Fellowship Award). As supported by a research team English at York University, he spent three weeks with daily team of Manuel Oriol, whose research focuses on software engineering and testing automated software engineering. Keywords: * Rmod * Distinguished Visiting Fellowship Award * Royal Academy of Engineering * Research Centre INRIA Lille - Nord Europe

Jan. 14, 2011

Re: [Pharo-project] Congrats

by Miguel CobÃ¡

El vie, 14-01-2011 a las 11:41 -0800, Steven Baker escribiÃ³: > I can't find an english translation. Can someone summarize this in > english for me? Not a translation but the main point: http://rmod.lille.inria.fr/web/pier/blog/2011-01-14 > > Thanks, > -Steven > > On Fri, Jan 14, 2011 at 8:17 AM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > > Congrats StÃ©ph, > > > > http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/actualites/… > > > > Cheers > > -- > > Miguel CobÃ¡ > > http://twitter.com/MiguelCobaMtz > > http://miguel.leugim.com.mx > > > > > > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 14, 2011

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

by Sven Van Caekenberghe

Martin, Wilhelm, On 14 Jan 2011, at 20:31, mkobetic(a)gmail.com wrote: > "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: >> Each #acceptWaitTimeout seconds, 'Wait for accept timed out' is printed on the log and another accept/wait starts. This looping improves liveliness and responsiveness to other events. > > Given that accept is generally done on the server side, usually in a background process, I have to say I'd be inclined to side with Wilhelm on this one. I don't see much that the server can do than go back into another accept loop. You can't predict how long will it take for the next client to connect, so a timeout isn't a sign of an issue. So I don't see much use for timeout on accept. > > I'm not quite sure what you mean by "improving liveliness". If the implementation needs to get out of accept to let other processes respond to events, then I wouldn't call that a feature. But these are really more philosophical points. In practice, wrapping a loop around an accept timeout isn't a big deal either, as long as it works as needed. On 14 Jan 2011, at 20:45, Schwab,Wilhelm K wrote: > Sven, > > Thanks for the code! > > The fact that I have to decide what constitutes an "infinite" delay seems wrong to me. It should just do what I tell it and either calmly wait for an event to let the code move forward (assuming that only the calling thread is blocked). One example: if I know I typed an incorrect address, then any time is wasted. If it's correct and the connection is slow (I downloaded a pdf of a paper earlier this week, and it was miserably slow but worked fine), I probably want the code to keep running without trying to think for itself. > > > "This looping improves liveliness and responsiveness to other events." > > Why does looping on things that should be blocking until events arrive improve response to other events? This seems like a bailing wire solution to the problem. Of course it would be better if there was an #waitForAccept variant that waited forever. The fact that you keep looping can be handy to do periodic tasks like cleanups without starting a new thread. In Java you can set the timeout of a ServerSocket and the accept will fall through as well, it is just an option. Sven

Jan. 14, 2011

Re: [Pharo-project] [SPAM] Congrats

by Sven Van Caekenberghe

On 14 Jan 2011, at 17:17, Miguel CobÃ¡ wrote: > Congrats StÃ©ph, > > http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/actualites/… > > Cheers > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx FÃ©licitations, StÃ©phane! Sven

Jan. 14, 2011

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

by Schwab,Wilhelm K

Sven, Thanks for the code! The fact that I have to decide what constitutes an "infinite" delay seems wrong to me. It should just do what I tell it and either calmly wait for an event to let the code move forward (assuming that only the calling thread is blocked). One example: if I know I typed an incorrect address, then any time is wasted. If it's correct and the connection is slow (I downloaded a pdf of a paper earlier this week, and it was miserably slow but worked fine), I probably want the code to keep running without trying to think for itself. "This looping improves liveliness and responsiveness to other events." Why does looping on things that should be blocking until events arrive improve response to other events? This seems like a bailing wire solution to the problem. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Friday, January 14, 2011 9:36 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket question (Was Re: Xtreams up to date) On 14 Jan 2011, at 12:54, Schwab,Wilhelm K wrote: I don't understand why this would bother you: it is the 'client/user' that decides about the timeout (you could use some very large number for an 'infinite' timeout). You need of course a loop around it. Here is the code from ZnSingleThreadedServer (which started from the Blackfoot example): listenLoop "We create a listening Socket, then wait for a connection. After each connection we also check that the listening Socket is still valid - if not we just make a recursive call to this method to start over." self initializeServerSocket. [ [ serverSocket isValid ifFalse: [ "will trigger #ifCurtailed: block and destroy socket" ^ self listenLoop ]. self serveConnectionOn: serverSocket ] repeat ] ifCurtailed: [ self releaseServerSocket ] serveConnectionOn: listeningSocket "We wait up to acceptWaitTimeout seconds for an incoming connection. If we get one we wrap it in a SocketStream and #executeOneRequestResponseOn: on it" | stream socket | socket := (listeningSocket waitForAcceptFor: self acceptWaitTimeout) ifNil: [ ^ self log: 'Wait for accept timed out' ]. stream := ZnNetworkingUtils socketStreamOn: socket. [ [ [ self executeOneRequestResponseOn: stream ] ensure: [ self log: 'Closing stream'. stream close ] ] ifCurtailed: [ self log: 'Destroying socket'. socket destroy ] ] forkAt: Processor highIOPriority named: 'Zinc HTTP Server Worker' Each #acceptWaitTimeout seconds, 'Wait for accept timed out' is printed on the log and another accept/wait starts. This looping improves liveliness and responsiveness to other events. Sven

Jan. 14, 2011

Re: [Pharo-project] Congrats

by Steven Baker

I can't find an english translation. Can someone summarize this in english for me? Thanks, -Steven On Fri, Jan 14, 2011 at 8:17 AM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > Congrats StÃ©ph, > > http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/actualites/… > > Cheers > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > >

Jan. 14, 2011

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > Each #acceptWaitTimeout seconds, 'Wait for accept timed out' is printed on the log and another accept/wait starts. This looping improves liveliness and responsiveness to other events. Given that accept is generally done on the server side, usually in a background process, I have to say I'd be inclined to side with Wilhelm on this one. I don't see much that the server can do than go back into another accept loop. You can't predict how long will it take for the next client to connect, so a timeout isn't a sign of an issue. So I don't see much use for timeout on accept. I'm not quite sure what you mean by "improving liveliness". If the implementation needs to get out of accept to let other processes respond to events, then I wouldn't call that a feature. But these are really more philosophical points. In practice, wrapping a loop around an accept timeout isn't a big deal either, as long as it works as needed.

Jan. 14, 2011

Re: [Pharo-project] How to bundle an application with icons?

by Hilaire Fernandes

Le 14/01/2011 15:03, Dimitry Golubovsky a Ã©crit : > Hi, > > Fernando Olivero wrote: > >> Hi Dimitry , i've did an external icon family importer and manager. > >> It's in squeaksource, under the name of ExternalIconFamily. > >> Gofer it >> squeaksource: 'ExternalIconFamily'; >> package: 'ExternalIconFamily'; >> load. > >> This framework allows importing and managing any external icon family. >> Once imported , the icon family is reified into the image, as a >> subclass of ExternalIconFamily. >> As an example it comes with a tiny subset of the Oxygen icon family imported. > > [skip] > > Thanks a lot. I am currently working on other aspects of the > application, but this icon importer will be a great customization > tool. I'll definitely give it a try. > You may want to take a look at DrGeo, in the DrGIcons class for icons import and handling. Hilaire

Jan. 14, 2011