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

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

by Mariano Martinez Peck

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. 10, 2011

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

by Igor Stasenko

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 :) > > ________________________________________ > 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 John Toohey

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] When will Fuel file format stabilize?

by Schwab,Wilhelm K

True, but what about reading data from five years ago? 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.

Oct. 10, 2011

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

by Schwab,Wilhelm K

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

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Mariano Martinez Peck

On Mon, Oct 10, 2011 at 9:44 PM, Michael Haupt <mhaupt(a)gmail.com> wrote: > Hi Mariano, > > On 10 October 2011 20:54, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > >> And as I understand it a BST file is pretty much the same intent as a > >> parcel or a fuel package containing code. > > > > Interesting. I would like to see the code and see if there is something I > > can learn from. > > the entry point for Strongtalk's BST files seems to be > bootstrap::parse_file() in > > http://code.google.com/p/strongtalk/source/browse/trunk/vm/runtime/bootstra… > . > > Thanks Michael for the point. > Best, > > Michael > > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011

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

by Igor Stasenko

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.

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Igor Stasenko

On 10 October 2011 20:06, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2011/10/10 Igor Stasenko <siguctua(a)gmail.com> >> >> Seems so. Except that fuel can contain data "objects" not just code >> "objects". >> >> Okay, 10 years later i hope we again have a new language, which will >> inherit all current crap + >> finally "everything is an object" concept :) >> > > Really? > > I dont see that classes are objects in dart and can be assigned to > variables. > yeah, it looks like people need another 10 years to realize the benefits of that. Because by reading dart specs i cannot leave the feeling that this language is a product of "not invented here" syndrome, rather than something fresh and new. Once, Microsoft did that with its C# project, now its seems like a Google's turn. :) -- Best regards, Igor Stasenko.

Oct. 10, 2011

Re: [Pharo-project] [squeak-dev] Any serializer can customize serialization strategy?

by Mariano Martinez Peck

I forgot to say something..... notice that using this hook is slower than a plain serialization. So what I mean is that if the strings are not that big, then it may happens that the usage of the hook + the compression is slower than a plain serialization + the regular string. I let you know because you may not expect that. I should benchmark the overhead of the hook.... Cheers On Mon, Oct 10, 2011 at 9:54 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Oct 10, 2011 at 9:35 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Is there any serializer (Fuel/StOMP/Ma object >> serialization/BOSS/SRP/SIXX??) which let me attach an external >> compressor/decompressor for specific Strings to the >> serialization/deserialization process? > > > In Fuel you can do: > > String >> fuelSubstitution > ^ ExternalCompressor compress: self > > String >> fuelAccept: aVisitor > ^ (ExternalCompressor shouldCompressString: self) > ifTrue: [aVisitor visitSubstitution: self] > ifFalse: [super fuelAccept: aVisitor] > > But the problem is that if #compress: answers an instance of String, you > should be careful that if #shouldCompressString: asnwers true to the > compressed string, then you will end up in an infinitive loop. > > See: http://rmod.lille.inria.fr/web/pier/software/Fuel/Hooks and > FLHookedSubstitutionTest > > I think StOMP should support this as well: > http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods > > The previous hook you let you replace the original String with its > compression during serialization. Which make sense because if you are going > to compress it is better to do it during serialization. > > With external I mean it could >> be in a separate binary (I could arrange the binding though). >> > > I am not sure if I understood. > > > > >> Thanks >> >> HernÃ¡n >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011

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

by Mariano Martinez Peck

Excellent news! On Mon, Oct 10, 2011 at 9:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hello everybody > > We got a final discussion with INRIA representatives and we will now set up > a consortium for pharo. > INRIA will support the consortium by funding on advanced engineer for a > year (may be two if the > consortium work well). So this is quite good around 55Keuros on consortium. > > There some strings attached: We will not be able to pay remote development > since this is regulated under the public market french laws > but we will be able to hire people (on french rate if they work in France). > We will have to see the legal period to spent the money. > > The general idea is to see how the consortium evolves: ideally we would > like to see if we can get it outside inria within a five years > period. > > Now what we plan to do: > - We would like to make the list of companies that sign the > agreement letter public. > Because this is important that other companies joins the consortium. > > - We will offer a free participation to any individual. > > - 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. > > - We could also have way to pay a license or a way to give money to > the consortium. > > 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. > > > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011