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

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

by Schwab,Wilhelm K

You have the idea. If Fuel turns out to meet my expectations, it would be nice to be able to use it for such things. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stefan Marr [pharo(a)stefan-marr.de] Sent: Monday, October 10, 2011 5:57 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] When will Fuel file format stabilize? 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. 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

Oct. 10, 2011

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

by Schwab,Wilhelm K

The data in question are medical records - they *really* need to load when demanded. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Monday, October 10, 2011 5:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] When will Fuel file format stabilize? 2011/10/10 Igor Stasenko <siguctua(a)gmail.com>: > 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 :) > The problem is that if it ever is relevant, you have very small chance to know because you cannot load ;) Nicolas >> >> ________________________________________ >> 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. >> >> >> > > > > -- > Best regards, > Igor Stasenko. > >

Oct. 10, 2011

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

by Schwab,Wilhelm K

YES - EXACTLY !!!!! :) ________________________________________ 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:28 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket timeout terminates COG VM I agree. In my own networking code, my sockets handlers on both side never timeout. I have a manager/monitor process that I use if I have to kill them. On Mon, Oct 10, 2011 at 17:18, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > John, > > Let me see if I can turn you to the dark side :) Sockets should **never** timeout. Socket servers (distinct from server sockets) should listen for and accept connections until told to stop. Client sockets should assume the server will respond a"any minute now" until they are told to give up. Sockets should use events vs. polling (one exception is arguably if a socket function call is running on a separate OS thread). All socket calls should block the calling Process while other Process instances run and the image remains responsive - no one would ever run a socket call on the gui thread, right? > > Harsh, I know, but it makes sense once you try it. Part of why I mention OS threads and blocking calls is that I would very much like to see us have in-image support for SSL, and OpenSSL is a nice way to do that. The OpenSSL non-blocking API is kinda scary, so blocking calls make a lot of sense. > > 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 4:19 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Socket timeout terminates COG VM > > 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. > > > Using Pharo1.3 #13298 on Lucid32 (Ubuntu) > > > -- > ~JT > > -- ~JT

Oct. 10, 2011

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

by Schwab,Wilhelm K

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. 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

Oct. 10, 2011

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

by Henrik Sperre Johansen

On 10.10.2011 23:28, John Toohey wrote: > I agree. In my own networking code, my sockets handlers on both side > never timeout. I have a manager/monitor process that I use if I have > to kill them. Then raise Smalltalk vm maxExternalSemaphoresSilently: to an appropriate number (max amount of socket handlers * 3 + some headroom), save your image, and you should be set. While it has a max limit of 64k, the socket plugin code on at least windows will max out at much less than 20k open sockets, as it uses 3 OS threads per socket. (Around 1k IIRC) Semaphore timeouts were the old symptoms of running out of this space, now it gives you an explicit exception instead. maxExternalSemaphores: is what is raising the error, some info _should_ be written to wherever crLog: redirects to with a NonInteractiveUIManager before the image terminates. Cheers, Henry

Oct. 10, 2011

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

by Stefan Marr

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. 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

Oct. 10, 2011

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

by Nicolas Cellier

2011/10/10 Igor Stasenko <siguctua(a)gmail.com>: > 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 :) > The problem is that if it ever is relevant, you have very small chance to know because you cannot load ;) Nicolas >> >> ________________________________________ >> 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. >> >> >> > > > > -- > Best regards, > Igor Stasenko. > >

Oct. 10, 2011

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

by Igor Stasenko

On 11 October 2011 00:24, John Toohey <jt(a)parspro.com> wrote: > 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? > No, it is not. For handling an unhandled exception, without knowing its source and cause which led to it, i don't see any other alternative. In headless mode there is no user who could respond to unhandled exception popups, therefore if your software doesn't handles it by itself, by default an image just quits to OS. > 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. 10, 2011

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

by John Toohey

I agree. In my own networking code, my sockets handlers on both side never timeout. I have a manager/monitor process that I use if I have to kill them. On Mon, Oct 10, 2011 at 17:18, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > John, > > Let me see if I can turn you to the dark side :) Â Sockets should **never** timeout. Â Socket servers (distinct from server sockets) should listen for and accept connections until told to stop. Â Client sockets should assume the server will respond a"any minute now" until they are told to give up. Â Sockets should use events vs. polling (one exception is arguably if a socket function call is running on a separate OS thread). Â All socket calls should block the calling Process while other Process instances run and the image remains responsive - Â no one would ever run a socket call on the gui thread, right? > > Harsh, I know, but it makes sense once you try it. Â Part of why I mention OS threads and blocking calls is that I would very much like to see us have in-image support for SSL, and OpenSSL is a nice way to do that. Â The OpenSSL non-blocking API is kinda scary, so blocking calls make a lot of sense. > > 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 4:19 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Socket timeout terminates COG VM > > 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. > > > Using Pharo1.3 #13298 on Lucid32 (Ubuntu) > > > -- > ~JT > > -- ~JT

Oct. 10, 2011

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

by Mariano Martinez Peck

On Mon, Oct 10, 2011 at 11:25 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> 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. > > Ahhh and if you are so worried about that, then use a proper database strategy than a simple/plain object serializer. > 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 > > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011