- Pharo-users - lists.pharo.org

How do i list the execution order of statements inside a method?

by mircea

Hello, I have this piece of code (taken from ProfStef). How do i programmatically get the order in which the objects are executed by Squeak. I know the order of execution from smalltalk documentation. But what if i need this information inside an app i'm building. tutorial: aTutorialClass lesson: aSelector | tutorial | tutorial := aTutorialClass new. self player tutorial: tutorial. self tutorial: aTutorialClass lessonAt: (tutorial indexOfLesson: aSelector). Thank you! -- View this message in context: http://forum.world.st/How-do-i-list-the-execution-order-of-statements-insid… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 25, 2013

SmalltalkInspect: Progressing with Pharo, an Interview with Stephane Ducasse

by Marcus Denker

"We start the fresh year 2013 with an interview with Stephane Ducasse from Inria, who started the Pharo Smalltalk project with a bunch of Smalltalkers [â¦] Aside from the product evolution of Pharo, we cover the new Pharo Consortium and Pharo Association, two organizations that were founded last year" http://smalltalkinspect.podspot.de/post/023-en-progressing-with-pharo-an-in…

Jan. 25, 2013

Re: [Pharo-users] Memory Leak with Zodiac?

by Sven Van Caekenberghe

On 24 Jan 2013, at 13:37, CHRIS BAILEY <cpmbailey(a)btinternet.com> wrote: > --- On Thu, 24/1/13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> From: Sven Van Caekenberghe <sven(a)stfx.eu> >> Subject: Re: [Pharo-users] Memory Leak with Zodiac? >> To: "A friendly place where any question about pharo is welcome" <pharo-users(a)lists.gforge.inria.fr> >> Date: Thursday, 24 January, 2013, 10:41 >> Hi Chris, >> >> On 24 Jan 2013, at 11:02, CHRIS BAILEY <cpmbailey(a)btinternet.com> >> wrote: >> >>> I'm having a little trouble with a possible memory leak >> with Zodiac. I'm running Pharo 1.4 Summer on Centos >> 6.3/Fedora 18 for deploy/dev. The plugin is using >> libssl.so.0.9.8, and I also seem to have another version >> kicking about which uses libssl.so.6 and am not really sure >> where I got that from. It may be an older one from the http://code.google.com/p/squeakssl/ site. Both have the >> same effect, i.e. when running 100 timesRepeat: [ ZnClient >> new url: 'https://www.google.com'; get ] VIRT and RES memory both >> go up about 70mb, but just using http doesn't accumulate >> any. I tried it in Pharo 2.0 which was the same, but the new >> NBCog doesn't include the libSqueaKSSL.so so I was only >> copying it over. >>> >>> Has anyone used it successfully in the same >> environment? I'll try it on Ubuntu when I get a chance. >>> >>> Thanks >>> Chris >> >> Thanks for testing this ;-) >> >> Note that although ZnClient is most often used to do just >> one request, it was also designed to be reused to do >> multiple request to the same host:port. Even when not taking >> care of resource cleanup, for casual use #close to the >> socket will eventually be sent where necessary due to >> finalization. Helping a bit makes for better performance. >> >> Either one of the following would be better: >> >> 100 timesRepeat: [ ZnClient new beOneShot; get: 'https://www.google.com' ]. >> >> 100 timesRepeat: [ ZnClient new get: 'https://www.google.com'; close ]. >> >> | client | >> client := ZnClient new. >> 100 timesRepeat: [ client get: 'https://www.google.com' ]. >> client close. >> >> Now, Zodiac TLS/SSL Streams are more resource intensive: >> they create ZdcPluginSSLSession instances which represent >> native native data structures from the OS's SSL libraries. >> These are only cleaned up when #destroy is sent, which is >> one by ZdcSecureSocketStream>>#close. I didn't write >> any explicit code to do this by finalization, so that >> probably does not happen. Maybe we should experiment with >> adding a #finalize to ZdcPluginSSLSession as an equivalent >> to #destroy. >> >> It would be cool if you could test again. Hopefully memory >> consumption improves. > > Hi Sven, thanks for the quick reply. > > Sorry, I didn't consider that when I reproduced it with the simplest example I could think of! I'm actually using it in the context of a single ZnClient being held open for an entire Seaside session which talks to an external web service. I therefore only send a close when the session ends. What solution would you recommend, as it is quite easy currently to run the image out of memory before the session gets unregistered. That is more a question about Seaside session management, which would be similar to managing database connections. My Seaside knowledge is rusty, but if I remember correctly, you can arrange for a method to be called on your custom Seaside session object whenever a session expires, there you could do some cleanup. Making sure sessions are expired quickly enough is also tuneable in various ways. What I have done in some projects is to have a single small pool of ZnClients ready to talk to a specific service. Each session then calls out to the pool to access the external service over HTTP(S). Of course, you have to be careful with multithreaded access, but also with timeouts, resource starvation, failures and cleanup, unwanted state sharing or caching, etc.. Or you could just try to be aggressive in closing the HTTP(S) clients after each use. There is not much point in keep those connections open for more than a couple of seconds as the other end will close them anyway. HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 24, 2013

Re: [Pharo-users] Memory Leak with Zodiac?

by CHRIS BAILEY

--- On Thu, 24/1/13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > From: Sven Van Caekenberghe <sven(a)stfx.eu> > Subject: Re: [Pharo-users] Memory Leak with Zodiac? > To: "A friendly place where any question about pharo is welcome" <pharo-users(a)lists.gforge.inria.fr> > Date: Thursday, 24 January, 2013, 10:41 > Hi Chris, > > On 24 Jan 2013, at 11:02, CHRIS BAILEY <cpmbailey(a)btinternet.com> > wrote: > > > I'm having a little trouble with a possible memory leak > with Zodiac. I'm running Pharo 1.4 Summer on Centos > 6.3/Fedora 18 for deploy/dev. The plugin is using > libssl.so.0.9.8, and I also seem to have another version > kicking about which uses libssl.so.6 and am not really sure > where I got that from. It may be an older one from the http://code.google.com/p/squeakssl/ site. Both have the > same effect, i.e. when running 100 timesRepeat: [ ZnClient > new url: 'https://www.google.com'; get ] VIRT and RES memory both > go up about 70mb, but just using http doesn't accumulate > any. I tried it in Pharo 2.0 which was the same, but the new > NBCog doesn't include the libSqueaKSSL.so so I was only > copying it over. > > > > Has anyone used it successfully in the same > environment? I'll try it on Ubuntu when I get a chance. > > > > Thanks > > Chris > > Thanks for testing this ;-) > > Note that although ZnClient is most often used to do just > one request, it was also designed to be reused to do > multiple request to the same host:port. Even when not taking > care of resource cleanup, for casual use #close to the > socket will eventually be sent where necessary due to > finalization. Helping a bit makes for better performance. > > Either one of the following would be better: > > 100 timesRepeat: [ ZnClient new beOneShot; get: 'https://www.google.com' ]. > > 100 timesRepeat: [ ZnClient new get: 'https://www.google.com'; close ]. > > | client | > client := ZnClient new. > 100 timesRepeat: [ client get: 'https://www.google.com' ]. > client close. > > Now, Zodiac TLS/SSL Streams are more resource intensive: > they create ZdcPluginSSLSession instances which represent > native native data structures from the OS's SSL libraries. > These are only cleaned up when #destroy is sent, which is > one by ZdcSecureSocketStream>>#close. I didn't write > any explicit code to do this by finalization, so that > probably does not happen. Maybe we should experiment with > adding a #finalize to ZdcPluginSSLSession as an equivalent > to #destroy. > > It would be cool if you could test again. Hopefully memory > consumption improves. > > Hi Sven, thanks for the quick reply. Sorry, I didn't consider that when I reproduced it with the simplest example I could think of! I'm actually using it in the context of a single ZnClient being held open for an entire Seaside session which talks to an external web service. I therefore only send a close when the session ends. What solution would you recommend, as it is quite easy currently to run the image out of memory before the session gets unregistered. Thanks Chris

Jan. 24, 2013

Re: [Pharo-users] Pharo 2.0 - System Error Handling Failed

by Ben Coman

Sean P. DeNigris wrote: > Sven Van Caekenberghe-2 wrote > >> Yeah, but the label should also convey some sense of urgency. >> >> I also think that UX is an element: it relates to what users (and we too >> BTW) encounter in the IDE, blocking them (us) from doing normal work. >> > > PoorUserExperience? or suggestions... > > > > -- > View this message in context: http://forum.world.st/Pharo-2-0-System-Error-Handling-Failed-tp4664742p4664… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > FirstImpressionsCount :)

Jan. 24, 2013

Re: [Pharo-users] Memory Leak with Zodiac?

by Sven Van Caekenberghe

Hi Chris, On 24 Jan 2013, at 11:02, CHRIS BAILEY <cpmbailey(a)btinternet.com> wrote: > I'm having a little trouble with a possible memory leak with Zodiac. I'm running Pharo 1.4 Summer on Centos 6.3/Fedora 18 for deploy/dev. The plugin is using libssl.so.0.9.8, and I also seem to have another version kicking about which uses libssl.so.6 and am not really sure where I got that from. It may be an older one from the http://code.google.com/p/squeakssl/ site. Both have the same effect, i.e. when running 100 timesRepeat: [ ZnClient new url: 'https://www.google.com'; get ] VIRT and RES memory both go up about 70mb, but just using http doesn't accumulate any. I tried it in Pharo 2.0 which was the same, but the new NBCog doesn't include the libSqueaKSSL.so so I was only copying it over. > > Has anyone used it successfully in the same environment? I'll try it on Ubuntu when I get a chance. > > Thanks > Chris Thanks for testing this ;-) Note that although ZnClient is most often used to do just one request, it was also designed to be reused to do multiple request to the same host:port. Even when not taking care of resource cleanup, for casual use #close to the socket will eventually be sent where necessary due to finalization. Helping a bit makes for better performance. Either one of the following would be better: 100 timesRepeat: [ ZnClient new beOneShot; get: 'https://www.google.com' ]. 100 timesRepeat: [ ZnClient new get: 'https://www.google.com'; close ]. | client | client := ZnClient new. 100 timesRepeat: [ client get: 'https://www.google.com' ]. client close. Now, Zodiac TLS/SSL Streams are more resource intensive: they create ZdcPluginSSLSession instances which represent native native data structures from the OS's SSL libraries. These are only cleaned up when #destroy is sent, which is one by ZdcSecureSocketStream>>#close. I didn't write any explicit code to do this by finalization, so that probably does not happen. Maybe we should experiment with adding a #finalize to ZdcPluginSSLSession as an equivalent to #destroy. It would be cool if you could test again. Hopefully memory consumption improves. Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 24, 2013

Memory Leak with Zodiac?

by CHRIS BAILEY

I'm having a little trouble with a possible memory leak with Zodiac. I'm running Pharo 1.4 Summer on Centos 6.3/Fedora 18 for deploy/dev. The plugin is using libssl.so.0.9.8, and I also seem to have another version kicking about which uses libssl.so.6 and am not really sure where I got that from. It may be an older one from the http://code.google.com/p/squeakssl/ site. Both have the same effect, i.e. when running 100 timesRepeat: [ ZnClient new url: 'https://www.google.com'; get ] VIRT and RES memory both go up about 70mb, but just using http doesn't accumulate any. I tried it in Pharo 2.0 which was the same, but the new NBCog doesn't include the libSqueaKSSL.so so I was only copying it over. Has anyone used it successfully in the same environment? I'll try it on Ubuntu when I get a chance. Thanks Chris

Jan. 24, 2013

Re: [Pharo-users] Is there a platform independent way to launch a web browser from Pharo?

by Sean P. DeNigris

Andy Burnett wrote > In order to do this, I need to initiate a session, with a web browser Search for ExternalWebBrowser on Squeaksource for a pre-made solution... or use OSProcess, which would be easy enough... or I guess you could probably use NB... -- View this message in context: http://forum.world.st/Is-there-a-platform-independent-way-to-launch-a-web-b… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 23, 2013

Re: [Pharo-users] Is there a platform independent way to launch a web browser from Pharo?

by Sven Van Caekenberghe

On 23 Jan 2013, at 21:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 January 2013 21:36, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: >> I want to use Pharo's new OAuth capabilities to access google's >> spreadsheets. However, I don't want to build a webapp, I just want to >> authenticate, and then pull the data down into Pharo. >> >> In order to do this, I need to initiate a session, with a web browser. Do I >> have to use OSProcess for this, or is there a mechanism already built in? >> > why you need a browser if you have Zinc? > You can initiate HTTP session from Pharo itself. > Or you need something extensive, like cookies etc? This is special stuff related to SSO: the other end, Google, Facebook, Twitter, etc, runs the authentication/authorization using their web apps, this is very hard, probably impossible to do with a programmatic HTTP client. >> Cheers >> Andy > > -- > Best regards, > Igor Stasenko.

Jan. 23, 2013

Re: [Pharo-users] Is there a platform independent way to launch a web browser from Pharo?

by Igor Stasenko

On 23 January 2013 21:36, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > I want to use Pharo's new OAuth capabilities to access google's > spreadsheets. However, I don't want to build a webapp, I just want to > authenticate, and then pull the data down into Pharo. > > In order to do this, I need to initiate a session, with a web browser. Do I > have to use OSProcess for this, or is there a mechanism already built in? > why you need a browser if you have Zinc? You can initiate HTTP session from Pharo itself. Or you need something extensive, like cookies etc? > Cheers > Andy -- Best regards, Igor Stasenko.

Jan. 23, 2013