May 2012 - Pharo-users - lists.pharo.org

Re: [Pharo-users] ZnClient>>#close & socket semaphores

by Sven Van Caekenberghe

Paul, On 15 May 2012, at 20:50, Paul DeBruicker wrote: > I ran into an out-of-external semaphores error when testing the Tropo API. It uses ZnEasy to post data to their api servers. Any idea at what rate you are posting, just a ballpark figure ? > I know I can raise the semaphore limit by running: > > Smalltalk vm maxExternalSemaphoresSilently: 3000. > > then saving. But I wondered if changing ZnClient>>#close to this: > > close > "Close any HTTP network connection that I might have kept open." > > connection > ifNotNil: [ > connection close: self isOneShot. > connection := nil. > state := #closed ]. > lastUsed := nil > > And then adding these two methods: > > ZdcAbstractSocketStream>>#close: > close: andDestroy > "Close the stream, flush if necessary" > > self flush. > socket isNil > ifTrue: [ ^ self ]. > self socketClose: andDestroy. > socket := nil > > ZdcAbstractSocketStream>>#socketClose: andDestroy > andDestroy > ifTrue: [ socket closeAndDestroy ] > ifFalse: [ socket close ] > > > might enable ZnClient to clean up after it issues 'one shot' requests in a safe manner. > > I can submit a change if so ( an a test! ). > > Thanks > Paul I am assuming you are on Pharo 1.3 or 1.4. But since you are talking about ZdcAbstractSocketStream you have Zodiac loaded as well. Are you using HTTPS then ? Because #close: does not exist on regular SocketStreams. If you are talking about regular HTTP, then you must have loaded the somewhat older/experimental ZdcNetworkingUtils, and are not using regular SocketStreams but ZdcOptimizedSocketStreams. Which is brave since this is something I am not doing myself ;-) Anyway, the close and/or destroy discussion puzzles me as well. When running all unit Zn tests I sometimes do see some cleanup happening in delayed fashion under finalization. I have not yet had problems with that. Note that ZnClient under #beOneShot behavior asks the other side to close as well. Socket>> closeAndDestroy does a wait of up to 20 seconds... Anyway, it is a good issue, but we should understand it better first I think. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 15, 2012

#allSendersOf:inPackageNamed: vs. #allCallsOn:localToPackage:

by Helene Bilbo

In SystemNavigation, what is the difference between #allSendersOf:inPackageNamed: and #allCallsOn:localToPackage: ? Is there a reason to prefer one over the other, when looking for senders of a specific message in a specific package? And why is the word âcalls" used? I was proud to have learned from the Pharo book that there are no calls, but only message sends? -- View this message in context: http://forum.world.st/allSendersOf-inPackageNamed-vs-allCallsOn-localToPack… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 15, 2012

ZnClient>>#close & socket semaphores

by Paul DeBruicker

I ran into an out-of-external semaphores error when testing the Tropo API. It uses ZnEasy to post data to their api servers. I know I can raise the semaphore limit by running: Smalltalk vm maxExternalSemaphoresSilently: 3000. then saving. But I wondered if changing ZnClient>>#close to this: close "Close any HTTP network connection that I might have kept open." connection ifNotNil: [ connection close: self isOneShot. connection := nil. state := #closed ]. lastUsed := nil And then adding these two methods: ZdcAbstractSocketStream>>#close: close: andDestroy "Close the stream, flush if necessary" self flush. socket isNil ifTrue: [ ^ self ]. self socketClose: andDestroy. socket := nil ZdcAbstractSocketStream>>#socketClose: andDestroy andDestroy ifTrue: [ socket closeAndDestroy ] ifFalse: [ socket close ] might enable ZnClient to clean up after it issues 'one shot' requests in a safe manner. I can submit a change if so ( an a test! ). Thanks Paul

May 15, 2012

Re: [Pharo-users] is Trait a behavior?

by Denis Kudriashov

Hello 2012/5/15 Martin Dias <tinchodias(a)gmail.com> > Hi all > > I have some methods receiving either a Class or a Trait instance as > parameter, so I usually call variables with names like > 'aClassOrTrait'. Searching for a more synthetic name, I wonder if > 'aBehavior' would be fine. > > But Trait isKindOf: Class => true So why "aClass" is not good for you? So aClass is bad

May 15, 2012

Re: [Pharo-users] is Trait a behavior?

by Martin Dias

Thanks! Would be nice to unify some names in the metamodel. On Mon, May 14, 2012 at 5:39 PM, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > +1 > I also want to distinct behavior objects from others and I need to include > Traits in that criteria. > > > On Mon, May 14, 2012 at 5:30 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Mon, May 14, 2012 at 10:19 PM, Martin Dias <tinchodias(a)gmail.com> >> wrote: >>> >>> Hi all >>> >>> I have some methods receiving either a Class or a Trait instance as >>> parameter, so I usually call variables with names like >>> 'aClassOrTrait'. Searching for a more synthetic name, I wonder if >>> 'aBehavior' would be fine. >> >> >> +1. For all my code that can handle both, traits and classes, I ALWAYS use >> the word Behavior rather than class. >> >> Problem is that aTrait isBehavior -> false. But I think it is an >> implementative details and I don't like it. As you say, a trait for me is a >> behevior and therefore I use that word. >> >> >>> >>> >>> But IMO these examples show contradictions: >>> >>> - Trait *is* a behavior: >>> >>> TBehaviorCategorization users ---> Â an IdentitySet(Class Trait) >>> >>> TPureBehavior users ---> an IdentitySet(TraitBehavior Behavior) >>> Â (actually this makes me think 'aPureBehavior' is another alternative >>> for my variables) >>> >>> - Trait is *not* a behavior: >>> >>> TBehaviorCategorization isBehavior ---> false >>> >>> TClassAndTraitDescription users ---> an IdentitySet(ClassDescription >>> TraitDescription) >>> Â (I both are behaviors, why not call it TBehaviorDescription?) >>> >>> >>> Thanks in advance for your help. >>> MartÃn >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

May 15, 2012

Monticello question (package renaming)

by Juan Ignacio Vaccarezza

Hi all, Question: Â¿ Is it posible to rename packages in monticello? Meaning by renaming not create a whole new history, but the history contemplates the renaming. Context: I started a project, with a category layout. Then I saved and track the project history using monticello. Then I realized that my package division was wrong (infered from the categories). So I decided to re-think my projects category layout and consecuently renamed the categories. Then new packages shall be created, and my project's history will be gone. Thanks for the help. Regards, Juan

May 15, 2012

Re: [Pharo-users] Pharo Questions on Stackexchange

by Robert Shiplett

cami, merci pour l'avis et vos efforts - je suis devenu abonnÃ© de l'Area 51 sur stackexchange encore une fois - bravo ! ciao, Robert Shiplett ( de la famille Chifflet, chassÃ©e du Jura il y a longtemps et au-j. sous le nom Shifflet aux E-U.) Fredericton, Nouveau-Brunswick, le Canada On 15 May 2012 05:54, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > I created stackexchange proposal which needs YOUR support: > > http://area51.stackexchange.com/proposals/40717/pharo?referrer=gXC4FWspxSud… > > we need now: > - 60 Followers > - 40 questions with some answers! > > I think this will greatly improve the efficiency of our discussions! > - tagging of discussions > - better archive for questions > > go go go! > cami

May 15, 2012

Pharo Questions on Stackexchange

by Camillo Bruni

I created stackexchange proposal which needs YOUR support: http://area51.stackexchange.com/proposals/40717/pharo?referrer=gXC4FWspxSud… we need now: - 60 Followers - 40 questions with some answers! I think this will greatly improve the efficiency of our discussions! - tagging of discussions - better archive for questions go go go! cami

May 15, 2012

Re: [Pharo-users] is Trait a behavior?

by Carla F. Griggio

+1 I also want to distinct behavior objects from others and I need to include Traits in that criteria. On Mon, May 14, 2012 at 5:30 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, May 14, 2012 at 10:19 PM, Martin Dias <tinchodias(a)gmail.com>wrote: > >> Hi all >> >> I have some methods receiving either a Class or a Trait instance as >> parameter, so I usually call variables with names like >> 'aClassOrTrait'. Searching for a more synthetic name, I wonder if >> 'aBehavior' would be fine. >> > > +1. For all my code that can handle both, traits and classes, I ALWAYS use > the word Behavior rather than class. > > Problem is that aTrait isBehavior -> false. But I think it is an > implementative details and I don't like it. As you say, a trait for me is a > behevior and therefore I use that word. > > > >> >> But IMO these examples show contradictions: >> >> - Trait *is* a behavior: >> >> TBehaviorCategorization users ---> an IdentitySet(Class Trait) >> >> TPureBehavior users ---> an IdentitySet(TraitBehavior Behavior) >> (actually this makes me think 'aPureBehavior' is another alternative >> for my variables) >> >> - Trait is *not* a behavior: >> >> TBehaviorCategorization isBehavior ---> false >> >> TClassAndTraitDescription users ---> an IdentitySet(ClassDescription >> TraitDescription) >> (I both are behaviors, why not call it TBehaviorDescription?) >> >> >> Thanks in advance for your help. >> MartÃn >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 14, 2012

Re: [Pharo-users] is Trait a behavior?

by Mariano Martinez Peck

On Mon, May 14, 2012 at 10:19 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi all > > I have some methods receiving either a Class or a Trait instance as > parameter, so I usually call variables with names like > 'aClassOrTrait'. Searching for a more synthetic name, I wonder if > 'aBehavior' would be fine. > +1. For all my code that can handle both, traits and classes, I ALWAYS use the word Behavior rather than class. Problem is that aTrait isBehavior -> false. But I think it is an implementative details and I don't like it. As you say, a trait for me is a behevior and therefore I use that word. > > But IMO these examples show contradictions: > > - Trait *is* a behavior: > > TBehaviorCategorization users ---> an IdentitySet(Class Trait) > > TPureBehavior users ---> an IdentitySet(TraitBehavior Behavior) > (actually this makes me think 'aPureBehavior' is another alternative > for my variables) > > - Trait is *not* a behavior: > > TBehaviorCategorization isBehavior ---> false > > TClassAndTraitDescription users ---> an IdentitySet(ClassDescription > TraitDescription) > (I both are behaviors, why not call it TBehaviorDescription?) > > > Thanks in advance for your help. > MartÃn > > -- Mariano http://marianopeck.wordpress.com

May 14, 2012