- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Zinc time outs too fast

by Sven Van Caekenberghe

On 13 Jul 2011, at 22:32, Igor Stasenko wrote: > well, the problem that it doesn't works as expected. > Jenkins still failing with timeout and walkback shows that its 30 seconds. > > While code says 1 hour: > https://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ke… hmm, that should work. I'll add a unit test for ZnConnectionTimeout behavior tomorrow, just to make sure it works. Sven

July 13, 2011

[Pharo-project] crLog:

by Nicolas Cellier

I noticed that crLog: is sometimes sent to Transcript. This completely ruin the goal of eliminating direct reference to Transcript, doesn't it ? Another thing, I couldn't find a reference to crLog: in the issue tracker... I'm really not sure how the issue tracker can be used to track changes back (maybe it simply can't). Nicolas

July 13, 2011

Re: [Pharo-project] [Vm-dev] new Cog VMs available

by Tudor Girba

Thanks, Eliot. Do these VMs include the fix of Igor for handling large images on Windows? Cheers, Doru On 13 Jul 2011, at 22:56, Eliot Miranda wrote: > Hi All, > > find new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2459/. These have functional ALien callbacks. Previous VMs had buggy code that could easily crash when heavily stressed, as discovered with Vassili Bykov's native Hopscotch UI in Newspeak on Win32. Be aware that there are Newspeak VMs in that same directory. Be sure to use the archives beginning with Cog, not nsvm or Newspeak for Squeak, Pharo et al. > > enjoy > -- > best, > Eliot > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

July 13, 2011

[Pharo-project] new Cog VMs available

by Eliot Miranda

Hi All, find new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2459/. These have functional ALien callbacks. Previous VMs had buggy code that could easily crash when heavily stressed, as discovered with Vassili Bykov's native Hopscotch UI in Newspeak on Win32. Be aware that there are Newspeak VMs in that same directory. Be sure to use the archives beginning with Cog, not nsvm or Newspeak for Squeak, Pharo et al. enjoy -- best, Eliot

July 13, 2011

Re: [Pharo-project] Zinc time outs too fast

by Igor Stasenko

On 13 July 2011 09:49, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi Igor, > > On 13 Jul 2011, at 00:00, Igor Stasenko wrote: > >> i think on time out it should verify that socket are still connected >> and try again. >> Or, add a check that if image is in non-interactive mode, ignore >> timeout and keep waiting for longer till socket will be closed by OS. > > Note that as far as I understand it, ConnectionTimedOut also applies to the situation where the other side simply does not start the conversation, like when trying to connect to the wrong port on an existing host. > > As things are now, timeouts are under the control of the client/user. > > There is a kind of global timeout ZnNetworkingUtils class>>#defaultSocketStreamTimeout that can be set globally with ZnNetworkingUtils class>>#defaultSocketStreamTimeout: seconds. The current default default is 30. > > This default is used by a DynamicVariable called ZnConnectionTimeout. This allows you to override the timeout on a per request / per process basis even if you do not have access to the HTTP client yourself (like with MC) where there are also options to change the timeout, of course. > > ZnConnectionTimeout value: 3600 during: [ ... ] will give you a one hour timeout. I am using that to actually shorten the default timeout ;-) If a server does not answer in 10 seconds, it most probably never will and I hate waiting. > well, the problem that it doesn't works as expected. Jenkins still failing with timeout and walkback shows that its 30 seconds. While code says 1 hour: https://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ke… > There currently is not option for indefinitive timeout, apart from something silly like SmallInteger maxVal or 52 weeks asSeconds. But do anyone really want to wait a year for a timeout ? > > Anyway, timeouts and other exceptions are just part of networking, the network is unreliable. > > Sven > > > -- Best regards, Igor Stasenko AKA sig.

July 13, 2011

Re: [Pharo-project] ZeroMQ support

by Philippe Marschall

On 13.07.2011 07:21, John Toohey wrote: > Maybe "enterprise" is the wrong word. I have a system with multiple > servers, some in Java, some in Clojure, and the Console servers > developed in Seaside running on Pharo. I need to have all these > servers talk to each other, and today I'm using JMS over ActiveMQ to > do that. I need to use Stomp as a protocol to allow my Console > servers to push data updates to the main servers, and its fragile. What does to wrong? What are the problems you are seeing? Do you have trouble with the clients or the message broker? > It > could be that my implementation is wrong, and you could advise on > that. What is your experience in pushing messages from Smalltalk VMs > to Java and C servers? Any help would be most appreciated. (My systems > supports 200 end to end transactions per seconds, with many thousand > concurrent transactions. It's deployed on 16 servers in an EC2 cloud) > > Why would ZeroMq be better? I have 20 year experience writing network > servers, and to honest, I'm not even sure where to start with an > answer to that question. Again, if you could help me out here, it > would be most appreciated. Perhaps, your experience in developing > large scale network applications, would be insightful here. No, sorry, I was just curious and trying to better understand your problem because normally I would associate ActiveMQ with "enterprise" and not ZeroMQ. Cheers Philippe

July 13, 2011

Re: [Pharo-project] how to get new inspector running in 1.4

by Igor Stasenko

As i already told to Camillo, new inspector needs refactoring for integrating into 1.4 it should not use ToolSet and instead it should register itself as #inspector in tool registry. Smalltalk tools register: NewInspector as: #inspector in its #registerToolsOn: (Note that Inspector also registers itself as #inspector, so, its the order how they are installed will affect which one is used) Maybe we should extend a ToolRegistry protocol to make sure that one tool can override another one, so if you reset a tools, then overrides will be applied in right order. Also , since we removed toolbuilder, a code for building its UI should also rewritten. -- Best regards, Igor Stasenko AKA sig.

July 13, 2011

[Pharo-project] how to get new inspector running in 1.4

by Camillo Bruni

is there an easy way to get newinspector running in a 1.4 image? thanks cami

July 13, 2011

Re: [Pharo-project] Python like generators for Pharo

by Damien Pollet

On 13 July 2011 16:12, Max Leske <maxleske(a)gmail.com> wrote: > Cool Lukas, good to know. > > I agree, closures usually do the trick. But it's still good to know. Maybe, someday I will have to parse GB's of Apache logs in Pharo... :D xstreams look pretty nice too for the kind of lazy iteration generators provide, no ? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 13, 2011

Re: [Pharo-project] About Cocoa VMs

by Damien Pollet

On 13 July 2011 16:14, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 13 July 2011 15:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> what should answer? > > Whatever, but the same on all VMs I think it should point to the binary, since that's the behavior of the older VMs and probably what most existing code expects. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 13, 2011