- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ZeroMQ support

by Philippe Marschall

On 13.07.2011 02:34, John Toohey wrote: > Hi all, > Wondering if anyone here is working on adding binding for ZeroMQ > (http://www.zeromq.org/) to Pharo? I think this type of enterprise > support is something that would greatly benefit Pharo. What's enterprise about ZeroMQ? > In one of my > systems today, I use Stomp over a socket in Pharo to send and receive > messages to and from ActiveMQ, and from there to my servers. This > works, but is fragile, ... Why? How would ZeroMQ be better? > I use zeromq in my Clojure based servers, but have no experience of > writing bindings for C libraries in Smalltalk. I would be more than > happy to help out, if such a project was started. > Cheers Philippe

July 13, 2011

Re: [Pharo-project] [Pharo-users] Group windows as tab screencast

by Tudor Girba

Very nice! I would love to have that integrated in Glamour. Would you be interested in taking a look? Doru On 12 Jul 2011, at 23:53, laurent laffont wrote: > Here's a screencast: http://magaloma.blogspot.com/2011/07/twm-docking-windows.html > > Test and feedback welcome. > > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > -- www.tudorgirba.com "Presenting is storytelling."

July 13, 2011

Re: [Pharo-project] About Cocoa VMs

by Sean P. DeNigris

Igor Stasenko wrote: > > Please file the ticket on cog issue tracker. So it will serve as a > reminder. > Done... ID â¼ Type â¼ Status â¼ Priority â¼ Milestone â¼ Owner â¼ Summary + Labels â¼ ... 49 Defect New Medium ---- ---- Mac Stack VM 4.0.0 is missing the ObjectiveC plugin 48 Defect New Medium ---- ---- Mac Stack VM 4.0.0 is missing the Quicktime plugin 47 Defect New Medium ---- ---- Mac Stack VM 4.0.0 is missing the Applescript plugin HTH, Sean -- View this message in context: http://forum.world.st/About-Cocoa-VMs-tp3654044p3664159.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 13, 2011

Re: [Pharo-project] Pharo/Squeak an iOS

by Steve Taylor

Thanks to all who replied. I'll be sure to report back to the list if I succeed in making anything pretty. Steve

July 13, 2011

[Pharo-project] ZeroMQ support

by John Toohey

Hi all, Wondering if anyone here is working on adding binding for ZeroMQ (http://www.zeromq.org/) to Pharo? I think this type of enterprise support is something that would greatly benefit Pharo. In one of my systems today, I use Stomp over a socket in Pharo to send and receive messages to and from ActiveMQ, and from there to my servers. This works, but is fragile, and I would love to be able to use zeromq here. I use zeromq in my Clojure based servers, but have no experience of writing bindings for C libraries in Smalltalk. I would be more than happy to help out, if such a project was started. -- blog.meta-spaces.com ~JT

July 13, 2011

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

by Schwab,Wilhelm K

Sig, With respect, that's almost correct. Sockets should not time out. Period. Clients can do so, but sockets should not. Servers should listen until they are told to stop doing so. One can do that iff socket calls block only the calling Process, which should also be the case. I am of the opinion that we have these features to enable workspace experiments, and they are hurting us. I'll shut up now :) Bill ________________________________________ 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: Tuesday, July 12, 2011 6:00 PM To: Pharo Development Subject: [Pharo-project] Zinc time outs too fast ConnectionTimedOut: Data receive timed out. 12 July 2011 10:39:11 pm VM: unix - i686 - linux - Squeak4.1 of 17 April 2010 [latest update: #9957] Image: Pharo1.4a [Latest update: #14034] [ConnectionTimedOut signal: 'Data receive timed out.'] in Socket>>waitForDataFor: Receiver: a Socket[connected] Arguments and temporary variables: .... Socket>>waitForDataFor:ifClosed:ifTimedOut: Receiver: a Socket[connected] Arguments and temporary variables: .... ZnHTTPSocketFacade class>>httpGet:args:user:passwd: Receiver: ZnHTTPSocketFacade Arguments and temporary variables: urlObject: 'http://www.squeaksource.com/Pharo/?C=M;O=D' queryArguments: nil username: '' password: '' url: http://www.squeaksource.com/Pharo/?C=M%3BO%3DD stream: SocketStream[inbuf:4kb/outbuf:4kb] request: a ZnRequest(GET /Pharo/?C=M%3BO%3DD) 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. -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

[Pharo-project] Zinc time outs too fast

by Igor Stasenko

ConnectionTimedOut: Data receive timed out. 12 July 2011 10:39:11 pm VM: unix - i686 - linux - Squeak4.1 of 17 April 2010 [latest update: #9957] Image: Pharo1.4a [Latest update: #14034] [ConnectionTimedOut signal: 'Data receive timed out.'] in Socket>>waitForDataFor: Receiver: a Socket[connected] Arguments and temporary variables: .... Socket>>waitForDataFor:ifClosed:ifTimedOut: Receiver: a Socket[connected] Arguments and temporary variables: .... ZnHTTPSocketFacade class>>httpGet:args:user:passwd: Receiver: ZnHTTPSocketFacade Arguments and temporary variables: urlObject: 'http://www.squeaksource.com/Pharo/?C=M;O=D' queryArguments: nil username: '' password: '' url: http://www.squeaksource.com/Pharo/?C=M%3BO%3DD stream: SocketStream[inbuf:4kb/outbuf:4kb] request: a ZnRequest(GET /Pharo/?C=M%3BO%3DD) 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. -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

[Pharo-project] Group windows as tab screencast

by laurent laffont

Here's a screencast: http://magaloma.blogspot.com/2011/07/twm-docking-windows.html Test and feedback welcome. Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

July 12, 2011

Re: [Pharo-project] Socket objects created twice ?

by Igor Stasenko

On 12 July 2011 20:53, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Sounds good, with the possible exception of removing #remove:. Â Letting things happen is great, and giving the finalizer a recognizable name would be wonderful. Â Otherwise, one should be able to do explicit cleanup if desired[*]. Â Whether that applies to WeakRegistry, I'm not sure. Â I would want to be able to remove items from weak arrays, dictionaries, etc. > it only applies to weak registry. > [*] I am thinking of things like tight loops with database activity, etc. Â There have been times when I have had to explicitly clean up finaizable things, and cleaning the weak registrations at the same time always seemed reasonable. > yes, unless cleaning takes much more time than adding. Accessing weak registry is synchronized through semaphore. And for servers, where you expect to have high load on your image, the less critical sections you locking, the better. > Bill > > > ________________________________________ > 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: Tuesday, July 12, 2011 10:13 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Socket objects created twice ? > > On 12 July 2011 15:17, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Rather than changing the handle (making it harder to associate the handle with the "real" socket), it would be nicer to have a SocketFinalizer or something - it could even be a subclass of socket?? >> > > I just thought about it after posting previous mail. Yes it would be > nice to add an explicit class, named SocketFinalizer > and then add an inst var to Socket - a finalizer. > Then when you deleting a socket, a socket could tell a finalizer to > nil-out handle, instead of asking WeakRegistry to unregister the > socket > which is much slower. > And a finalization action for nilled out handle will be no-op, once > already closed socket become garbage. > > In that way, someday we could eliminate the #remove: protocol from > WeakRegistry. > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

Re: [Pharo-project] About Cocoa VMs

by Igor Stasenko

On 12 July 2011 21:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote: >> >> Yes, but lurking and remain silent won't helps to make it available. >> Now, thanks to you we know what is missing. :) >> > > I've reported plugin issues whenever I've found them, but the VM maintainers > are overworked, and I feel incredibly lucky to have them doing all the work > they do, and I understand that the Applescript plugin is probably not a > priority, so I am waiting patiently. > Please file the ticket on cog issue tracker. So it will serve as a reminder. > While we're on the subject, two other plugins that I use that seem to be > missing are: > * Obj-C bridge > * Quicktime > > Thanks again for all the hard work. > > Sean > > -- > View this message in context: http://forum.world.st/About-Cocoa-VMs-tp3654044p3663155.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

July 12, 2011