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

Re: [Pharo-project] Socket timeout terminates COG VM

by Sven Van Caekenberghe

On 10 Oct 2011, at 22:19, John Toohey wrote: > I've had a problem since 1.0 with socket timeouts throwing exceptions > and invoking the debugger in my headless images. I don't know why a > socket timeout is considered exceptional A server should never 'leak' timeout exceptions. A timeout is very common and should just result in that connection/conversation being cleaned up. Sven

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by StÃ©phane Ducasse

Hi igor I imagine that if the server is not run headless then the screen will be filled up with debuggers and people can try if they succeed to connect to the image using a remote tools. Even if I prefer a real headless mode, is my sentence correct? Stef On Oct 11, 2011, at 1:05 AM, Igor Stasenko wrote: > On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> John, >> >> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software. >> > So you prefer leaving an image in some undefined state, potentially > leaking system resources, > because of unhandled exception which nobody cares to handle? > At best what you can have then is, when your critical process will > enter an endless error-producing loop > is just bogging all system resources or hanging an image, without > giving you any idea what's going on. > So , if you prefer such kind of punishment for your crimes, just use > image prior to 1.3 and be happy :) > >> Bill >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John Toohey [jt(a)parspro.com] >> Sent: Monday, October 10, 2011 5:24 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Socket timeout terminates COG VM >> >> The exception is not coming from my code, if it was I could trap it. >> Regardless, isn't shutting the VM down a bit of overkill in this case? >> >> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 10 October 2011 23:19, John Toohey <jt(a)parspro.com> wrote: >>>> Hi, >>>> >>>> I've had a problem since 1.0 with socket timeouts throwing exceptions >>>> and invoking the debugger in my headless images. I don't know why a >>>> socket timeout is considered exceptional, but I've gotten used to >>>> using VNC to log into the server and close the debuger windows. >>>> However, I've moved to COG and the latest one-click images, and now >>>> the error terminates the VM. >>>> >>>> My app is a standard Seaside server, using the streaming connector for >>>> Comet support. >>>> >>>> I've attached the PharoDebug.log. It would be appreciated if anyone >>>> could help me with this problem, as I'm at a loss where to even begin. >>>> >>> >>> So, just put an exception handler, and handle this exception in a >>> manner you want >>> and then your image will keep working! :) >>> >>>> >>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu) >>>> >>>> >>>> -- >>>> ~JT >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >> >> >> -- >> ~JT >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 11, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by StÃ©phane Ducasse

Mariano I think that evolution and migration is key if we want to use fuel for loading code. This is why in MCZ you have always the source files. In case of trouble. It is important to use the current situation as case for evolution. I like the idea of igor of having class that represent different versions. Stef On Oct 11, 2011, at 8:55 AM, Philippe Marschall wrote: > On 10/08/2011 10:42 PM, Mariano Martinez Peck wrote: >> s >> >>>> >>>> This is IMHO more than necessary for Fuel to become a production ready >>>> serializer and I'd say Fuel is now "old enough" to become such :) >>> >>> Yes. >>> Now what I would love is that even if fuel changes that the evolution of >>> information >>> is taken into account because like that it will be exercised for real. >>> >>> >> No, that's impossible, and if posible, it is not worth it. Migrating from an >> old format to a new one is extremelly complicated and innecessary. The >> easiest way to solve this is to take the correct version of Fuel, >> materialize the graph from the stream, load new version of Fuel, and >> seriaize it again. That the easiest, more secure, and more practical >> approach I can see. > > That is horribly naÃ¯ve an excludes fuel from a lot of use cases. You > can't use fuel for "archiving" objects outside of the image because you > will never know whether you will be able to read them in again because > the format changes. You will always need to have "live" ones in the image. > > That means you can't use fuel for anything Monticello related because > you may never be able to load those versions in again because the file > format has changed in the mean time. > > Cheers > Philippe > >

Oct. 11, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by StÃ©phane Ducasse

I think that somebody (probably not the fuel team which is full right now) should use a jSON or other formats to externatlise data out of fuel and this version should be use for old mgration. The point of evolution is important because we should be able to load old code in the future. Now let us make sure that fuel is really working well. On Oct 10, 2011, at 11:25 PM, Mariano Martinez Peck wrote: > > > On Mon, Oct 10, 2011 at 11:19 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > True, but what about reading data from five years ago? > > Well, can you load your 5-year-old code out of the box? No. You will probably need to update its code. The same here. > You can always take the same Fuel version and updated (without changing the format) to work in a new Pharo image. Just as you do with your own code. > As an example, the last stable version 1.6 of Fuel works if Pharo 1.2, 1.3 and 1.4. I think it is good enough. > > Cheers > > > I have ten year old Dolphin STB that I can still load. > > > > ________________________________________ > 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: Monday, October 10, 2011 4:59 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] When will Fuel file format stabilize? > > I concur with Mariano. > In production images, you want probably stick with concrete > verision(s) of frameworks you using and don't > follow the bleeding edge. Because if you do, then you spending time on > coping up with latest and greatest > versions of these frameworks instead of spending time on developing > your project :) > > -- > Best regards, > Igor Stasenko. > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 11, 2011

Re: [Pharo-project] socket.io

by Philippe Marschall

On 10/10/2011 09:47 PM, Herby VojÄÃk wrote: > Is there / planning a socket.io (server) support in Pharo? I am making suite > of client-server application where I strongly consider socket.io as the > communication layer; there is no problem with clients, but at the > server-side, socket.io seems only to be supported by its native node.js Without async IO supporting WebSockets does not seem to make much sense. > (which is not bad, but I'd like to consider Smalltalks as well, Pharo being > the first choice). Thanx, Herby > > p.s. If you get this message second time, I am sorry, I got confused by the > Nabble's messages. I received it only once :-) Cheers Philippe

Oct. 11, 2011

Re: [Pharo-project] Pharo Consortium News: let's make it real.

by StÃ©phane Ducasse

On Oct 11, 2011, at 2:27 AM, Alexandre Bergel wrote: >> - We are wondering if we could have a academic fee for the institution that want it: >> we have to discuss the fee. Any suggestions would be good: I was thinking that 500 Euros would be good for rich countries >> and 200 for the other ones. Now tell us. > > As you can imagine, pulling out some money is not easy for a University. However, what can be done (at least for me), is to allocate money to invite a PhD holder to stay at the Uni of Chile and work on a topic. I should also be able to buy books (why not a special edition of Pharo by Example at 80 euros?) but you can buy software? So you should be able to pay a license. We will work out of that. > >> - We could also have way to pay a license or a way to give money to the consortium. > > +1 > > Alexandre > >> >> Now the complex part: >> - we would like to collect money from companies and again we will need your help >> to understand what is the correct model. >> We are thinking: >> single person company: starting at 300 Euros >> "small company": starting at 2500 Euros >> large companies: starting at 5000 Euros. >> >> We would like to keep the model really simple and transparent. >> >> Now our goal is to be able to pay an engineer like igor full time because there is so much to do. >> But each day we get closer to what we want. >> >> Stef and Marcus. >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Oct. 11, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Philippe Marschall

On 10/08/2011 10:42 PM, Mariano Martinez Peck wrote: > s > >>> >>> This is IMHO more than necessary for Fuel to become a production ready >>> serializer and I'd say Fuel is now "old enough" to become such :) >> >> Yes. >> Now what I would love is that even if fuel changes that the evolution of >> information >> is taken into account because like that it will be exercised for real. >> >> > No, that's impossible, and if posible, it is not worth it. Migrating from an > old format to a new one is extremelly complicated and innecessary. The > easiest way to solve this is to take the correct version of Fuel, > materialize the graph from the stream, load new version of Fuel, and > seriaize it again. That the easiest, more secure, and more practical > approach I can see. That is horribly naÃ¯ve an excludes fuel from a lot of use cases. You can't use fuel for "archiving" objects outside of the image because you will never know whether you will be able to read them in again because the format changes. You will always need to have "live" ones in the image. That means you can't use fuel for anything Monticello related because you may never be able to load those versions in again because the file format has changed in the mean time. Cheers Philippe

Oct. 11, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Igor Stasenko

On 11 October 2011 00:57, Stefan Marr <pharo(a)stefan-marr.de> wrote: > > On 10 Oct 2011, at 23:25, Igor Stasenko wrote: > >> On 11 October 2011 00:19, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> True, but what about reading data from five years ago? Â I have ten year old Dolphin STB that I can still load. >>> >>> >> to my experience a 10 years old data has very small chances to be relevant :) > > You might want to reconsider that: > Some countries have laws, that regulate how long and what has to be archived: > > Switzerland: > http://www.itandlaw.ch/html/publikationen/pdf/KMUMagazin04.pdf > Germany: > http://www.recht-im-internet.de/themen/archivierung.htm > > 10 years is considered the minimum. > Then how about following idea: help implementing format migration code :) I think what can be done in Fuel is to have a separate class per each binary format version, so when you do format changes, instead of modifying existing class you creating a new one and put new stuff there. Then at a point of detecting incoming data, it could decide which class to use for deserialization. > But that might not be what Pharo or Fuel is supposed to be used for. > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > > -- Best regards, Igor Stasenko.

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by Schwab,Wilhelm K

Sockets are low-level beasts and should simply do what they are told and raise errors when the can't do so. Client and server abstractions on top of that are the soonest that one should think about timeouts and retries (and the latter is really an application level decision). These wrappers will indeed want to handle various errors to keep things clean, perhaps subsequently triggering events/notifications that something happened. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John Toohey [jt(a)parspro.com] Sent: Monday, October 10, 2011 10:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket timeout terminates COG VM I think the main source of the exceptions is in the WAListenerAdapter in the #process: aNativeRequest (Implemented in WAServerAdapter) My app uses Comet so I need a streaming server. I've wrapped an exception handler around this, and am testing now. Overall I think that the socket code, if it is going to detect timeouts, it should retry and the just close and cleanup that socket. If the calling app ever calls on that socket, then an exception should be thrown, and in this case, the app would be expecting it. On Mon, Oct 10, 2011 at 21:34, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Not knowing what exception this is, I'm not sure whether to agree or argue. However, given the importance of error handling to robust network apps, it should get handled. > > > > ________________________________________ > 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: Monday, October 10, 2011 7:05 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Socket timeout terminates COG VM > > On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> John, >> >> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software. >> > So you prefer leaving an image in some undefined state, potentially > leaking system resources, > because of unhandled exception which nobody cares to handle? > At best what you can have then is, when your critical process will > enter an endless error-producing loop > is just bogging all system resources or hanging an image, without > giving you any idea what's going on. > So , if you prefer such kind of punishment for your crimes, just use > image prior to 1.3 and be happy :) > >> Bill >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John Toohey [jt(a)parspro.com] >> Sent: Monday, October 10, 2011 5:24 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Socket timeout terminates COG VM >> >> The exception is not coming from my code, if it was I could trap it. >> Regardless, isn't shutting the VM down a bit of overkill in this case? >> >> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 10 October 2011 23:19, John Toohey <jt(a)parspro.com> wrote: >>>> Hi, >>>> >>>> I've had a problem since 1.0 with socket timeouts throwing exceptions >>>> and invoking the debugger in my headless images. I don't know why a >>>> socket timeout is considered exceptional, but I've gotten used to >>>> using VNC to log into the server and close the debuger windows. >>>> However, I've moved to COG and the latest one-click images, and now >>>> the error terminates the VM. >>>> >>>> My app is a standard Seaside server, using the streaming connector for >>>> Comet support. >>>> >>>> I've attached the PharoDebug.log. It would be appreciated if anyone >>>> could help me with this problem, as I'm at a loss where to even begin. >>>> >>> >>> So, just put an exception handler, and handle this exception in a >>> manner you want >>> and then your image will keep working! :) >>> >>>> >>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu) >>>> >>>> >>>> -- >>>> ~JT >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >> >> >> -- >> ~JT >> >> >> > > > > -- > Best regards, > Igor Stasenko. > > > -- ~JT

Oct. 11, 2011

Re: [Pharo-project] Migrating Complex in a separate package

by Serge Stinckwich

On Tue, Oct 11, 2011 at 1:28 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi, Hi Nicolas, > Facts: > - Complex is present in Squeak trunk image but not used in Kernel > - Complex is absent from Pharo image. > This breaks portability of some packages. Thank you for bringing up this issue ;-) > I suggest putting Complex in its own package in squeaksource. This can > work for Pharo alone. > I also suggest to optionally remove Squeak.Complex from trunk. Yes i think this will be easier for you to have just one package in Squeaksource for Pharo and Squeak. > There are then other choices: > - the name of the package : can be Complex or Math-Complex (I already > put a few Math-* in squeak source...) Math-Complex is ok for me. > - the name of the class can be Complex or ComplexNumber > Specifically I don't like isComplex, many objects could respond true > because complicated; > isComplexNumber is much more explicit. > We could also think of having complex expressions in a symbolic > algebra, and isComplexNumber would be true only for a literal value.. > > What I could eventually do is publish an old Complex in package > Complex for backard compatibility and an updated ComplexNumber in a > Math-Complex package... > > How many of you use Complex ? > What do you think of these proposals ? I'm mostly using Complex and Quaternion for my robotic development. So i want to be able to load these packages in a current Pharo image. Maybe you can merge everything about complex, quaternions (and latter octonions) numbers in a single package in order to avoid too much small packages with just a class (and a test class) ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Oct. 11, 2011