- Pharo-users - lists.pharo.org

Smalltalkhub needs your quick in the ass :)

by StÃ©phane Ducasse

Hi guys Nicolas released internally a new version of smalltalkhub and everyday he finds a good reason not to announce it. So please do us a favorâ¦ create some projects and push your code there so that nicolas gets the feel of a alive and kicking smalltalkhub :) Stef

May 15, 2012

Re: [Pharo-users] Monticello browser question

by Werner Kassens

Dale Henrichs a Ã©crit : > On second thought ... you may have loaded up the FsGit stuff? It is a work in progress as well ... yes exactly, that was it. werner

May 15, 2012

Re: [Pharo-users] [Pharo-consortium] We need your Pharo successes

by StÃ©phane Ducasse

Thanks Esteban for your cool slides: https://gforge.inria.fr/frs/download.php/30774/lawsuit3slides.pdf https://gforge.inria.fr/frs/download.php/30773/ibizlog3slides.pdf We want more! Stef

May 15, 2012

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

by Sven Van Caekenberghe

On 15 May 2012, at 22:48, Paul DeBruicker wrote: > Sven Van Caekenberghe wrote >> >> 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 ? > > Maybe 50 POSTs in half an hour. Just messing with sending and receiving SMS > messages. That is not fast enough to cause trouble I would think, maybe something else prevents the sockets from closing. > Using the ZnMultiThreadedServer to handle responses from their API. OK, these could also keep on lingering too long (nowadays its is the managing server that is the default, check the collection inside). > Also - since I sent this I changed from ZnEasy to just ZnClient. Maybe > keeping the the client around in the instance will cut down on > creating/keeping semaphores. But I still think its a relevant topic. ZnEasy uses ZnClient internally, so it comes down to the same thing, but yes reusing a client to access a server can be a good idea, mulitthreaded warnings apply. > Sven Van Caekenberghe wrote >> >> 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. > > Pharo 1.3 right now. Zodiac is loaded in the image but this is just an HTTP > post for testing purposes to 'http://api.tropo.com' . I'm making another > pass over the Stripe API later today and will be using Zodiac/SqueakSSL for > HTTPS for that. For production I plan to route all SSL through > nginx/apache. Stripe is interesting, I want to hear how it goes. > Sven Van Caekenberghe wrote >> >> 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 ;-) > > I have these versions loaded: Zodiac-Core-SvenVanCaekenberghe.17 & > Zinc-HTTP-SvenVanCaekenberghe.275 > > As far as I know I've done nothing to actively choose anything other than the defaults. What does ZnNetworkingUtils default socketStreamClass return ? > Sven Van Caekenberghe wrote >> >> 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... > > Socket>>#closeAndDestroy only waits if its still connected. Otherwise it > 'detroys' straight away and gets rid of the semaphore. From what I can see > 'close' doesn't dump the semaphore. Yes, but potentially it will wait, and as a busy server trying to cleanup/conserve resources, you don't want that. Sven

May 15, 2012

Re: [Pharo-users] Monticello browser question

by Werner Kassens

Dale, i see, thanks for your answer. werner

May 15, 2012

Re: [Pharo-users] Monticello browser question

by Dale Henrichs

On second thought ... you may have loaded up the FsGit stuff? It is a work in progress as well ... My plan was to integrate the FSGit stuff into Metacello at a later date: FSGit has to be ported to GemStone and Squeak to be used in Metacello, whereas the GitHub repository I'm currently working on is more portable. Dale ----- Original Message ----- | From: "Dale Henrichs" <dhenrich(a)vmware.com> | To: "A friendly place where any question about pharo is welcome" <pharo-users(a)lists.gforge.inria.fr> | Sent: Tuesday, May 15, 2012 2:00:26 PM | Subject: Re: [Pharo-users] Monticello browser question | | Werner, | | Not at the moment. I am currently working on some GitHub repository | type in addition to the current FileTree repository type. The work | will be available with the next Metacello in the next month or so | ... | | Dale | | ----- Original Message ----- | | From: "Werner Kassens" <wkassens(a)libello.com> | | To: "A friendly place where any question about pharo is welcome" | | <pharo-users(a)lists.gforge.inria.fr> | | Sent: Tuesday, May 15, 2012 1:41:30 PM | | Subject: [Pharo-users] Monticello browser question | | | | Hi, | | after having loaded some packages (dont remember which one was | | responsible), i noticed the package-type git could be added as | | repository in the monticello-browser. this leads me to the question | | whether i could add a repository on a github site directly, so that | | i | | dont have to clone that site first to my disk, before i can load a | | package? | | werner | | | | | |

May 15, 2012

Re: [Pharo-users] Monticello browser question

by Dale Henrichs

Werner, Not at the moment. I am currently working on some GitHub repository type in addition to the current FileTree repository type. The work will be available with the next Metacello in the next month or so ... Dale ----- Original Message ----- | From: "Werner Kassens" <wkassens(a)libello.com> | To: "A friendly place where any question about pharo is welcome" <pharo-users(a)lists.gforge.inria.fr> | Sent: Tuesday, May 15, 2012 1:41:30 PM | Subject: [Pharo-users] Monticello browser question | | Hi, | after having loaded some packages (dont remember which one was | responsible), i noticed the package-type git could be added as | repository in the monticello-browser. this leads me to the question | whether i could add a repository on a github site directly, so that i | dont have to clone that site first to my disk, before i can load a | package? | werner | |

May 15, 2012

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

by Paul DeBruicker

Sven Van Caekenberghe wrote > > 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 ? > Maybe 50 POSTs in half an hour. Just messing with sending and receiving SMS messages. Using the ZnMultiThreadedServer to handle responses from their API. Also - since I sent this I changed from ZnEasy to just ZnClient. Maybe keeping the the client around in the instance will cut down on creating/keeping semaphores. But I still think its a relevant topic. Sven Van Caekenberghe wrote > > 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. > Pharo 1.3 right now. Zodiac is loaded in the image but this is just an HTTP post for testing purposes to 'http://api.tropo.com' . I'm making another pass over the Stripe API later today and will be using Zodiac/SqueakSSL for HTTPS for that. For production I plan to route all SSL through nginx/apache. Sven Van Caekenberghe wrote > > 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 ;-) > I have these versions loaded: Zodiac-Core-SvenVanCaekenberghe.17 & Zinc-HTTP-SvenVanCaekenberghe.275 As far as I know I've done nothing to actively choose anything other than the defaults. Sven Van Caekenberghe wrote > > 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... > Socket>>#closeAndDestroy only waits if its still connected. Otherwise it 'detroys' straight away and gets rid of the semaphore. From what I can see 'close' doesn't dump the semaphore. -- View this message in context: http://forum.world.st/ZnClient-close-socket-semaphores-tp4630357p4630374.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 15, 2012

Monticello browser question

by Werner Kassens

Hi, after having loaded some packages (dont remember which one was responsible), i noticed the package-type git could be added as repository in the monticello-browser. this leads me to the question whether i could add a repository on a github site directly, so that i dont have to clone that site first to my disk, before i can load a package? werner

May 15, 2012

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