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

[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

Re: [Pharo-project] About Cocoa VMs

by Sean P. DeNigris

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

July 12, 2011

Re: [Pharo-project] MorphicModel needs serious cleaning

by Igor Stasenko

On 12 July 2011 20:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > :) > > I'm sure that there are other little gremlins that we will kill one day or the others. i would say this is an elder gremlin, fat and grumpy one :) > open a ticket. http://code.google.com/p/pharo/issues/detail?id=4513 > I still want to remove the setName and friend on Morph :) > Stef > -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

Re: [Pharo-project] Old Hudson still builds?

by StÃ©phane Ducasse

> i'd prefer people to do manage their jobs by own (to have less > pressure on Marcus and me). > > Marcus, can we register new users on Jenkins? Marcus is on holiday until 19 and I think that we cannot add non inria people. Now what would be good is to have a repository that contains metacello spec and that we run they all systematically > >> Best regards >> Janko >> > > > -- > Best regards, > Igor Stasenko AKA sig. >

July 12, 2011

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

by Schwab,Wilhelm K

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. [*] 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. 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.

July 12, 2011

Re: [Pharo-project] MorphicModel needs serious cleaning

by StÃ©phane Ducasse

:) I'm sure that there are other little gremlins that we will kill one day or the others. open a ticket. I still want to remove the setName and friend on Morph :) Stef On Jul 12, 2011, at 3:24 AM, Igor Stasenko wrote: > Just found that scrollbars are assigned 'slotname' when you creating them > and when it comes to send events to their model, it end up in this method: > > use: cachedSelector orMakeModelSelectorFor: selectorBody in: selectorBlock > | selector | > model ifNil: [^ nil]. > cachedSelector ifNil: > ["Make up selector from slotname if any" > selector := (slotName ifNil: [selectorBody] > ifNotNil: [slotName , selectorBody]) asSymbol. > (model class canUnderstand: selector) ifFalse: > [(self confirm: 'Shall I compile a null response for' > , Character cr asString > , model class name , '>>' , selector) > ifFalse: [self halt]. > model class compile: (String streamContents: > [:s | selector keywords doWithIndex: > [:k :i | s nextPutAll: k , ' arg' , i printString]. > s cr; nextPutAll: '"Automatically generated null response."'. > s cr; nextPutAll: '"Add code below for appropriate behavior..."'.]) > classified: 'input events' > notifying: nil]] > ifNotNil: > [selector := cachedSelector]. > ^ selectorBlock value: selector > > > this is incredible.. > > -- > Best regards, > Igor Stasenko AKA sig. >

July 12, 2011

Re: [Pharo-project] reloaded Transcript reopens issue 3112

by StÃ©phane Ducasse

Ok we should check that. On Jul 12, 2011, at 11:23 AM, Pavel Krivanek wrote: > The new changes in Transcript return issue 3112 back to the game. It > makes Transcript dependent on Morphic. > > http://code.google.com/p/pharo/issues/detail?id=3112 > > -- Pavel >

July 12, 2011