- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Progress Report] Zinc HTTP Components
by StÃ©phane Ducasse Oct. 2, 2010

Oct. 2, 2010

Matt Sven I love to see your framework emerging like that. Keep pushing. This is a warm feeling for us (with our head in the gory details of the system) so see that other people are creating cool abstractions on top of it. Stef > Hi everyone, > > On Oct 1, 2010, at 8:10 AM, Lukas Renggli wrote: > >> Wow, very impressive. >> >> What I would like to see is some kind of high-level API for convenient >> access to all features. Something along >> >> response := ZnHttp new >> url: 'http://www.foo.com'; >> userAgent: 'FakeAgent'; >> cookieAt: 'something' put: '123'; >> parameterAt: 'q' put: 'smalltalk'; >> onFailure: [ :error | self inform: 'failed' ]; >> onProgress: [ :status | ... ]; >> get >> >> Lukas >> > > This is actually where I'd like to head with the client API. I had started my own HTTP client about 2 days before Sven announced Zinc, so it made more sense contribute to his project. My initial work was a subclass off of ProtocolClient and was kind of monolithic, so my first steps have been to make things mesh nicely with Zinc. > > My initial prototype before I started working on Zinc had a very similar API to your example, so my thoughts are definitely aimed for that direction. > > Matt > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
by Mariano Martinez Peck Oct. 2, 2010

Oct. 2, 2010

On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 1 October 2010 08:48, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> > wrote: > >> > >> Hi all, > >> > >> I am planning to put online a minimal image that contains AspectMaps, > with > >> some models pre-loaded. Two questions: > >> - Is there an easy way to strip this image of dev tools et cetera? > > > > Not really. The easiest way is to have a Configuration of Metacello that > > takes care of loading all your code with all your dependencies. Then, > take a > > PharoCore and load your code there. > > In addition, you may want to evaluate "ScriptLoader cleanUpForProduction" > at > > the end. Check the method to see what it does. > > > >> > >> - How can I make it so that I can distribute it without the changes > file? > >> (Right now the image complains of a missing changes file if it is not > there > >> ...) > >> > > > > I am aware of "Smalltalk abandonSources" to avoid using .sources. You > won't > > see things like the temp names, and stuff will be decompiled instead. > > With a little effort, you can embed source code into method trailers. > Then you won't need .sources nor .chanes to see the real source > instead of decompiling it. > But you will loose method stamps. > I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar. thoughts? > > > For the .changes you can start the image without them, there will raise a > > popup at the beginning. The problem is if you then do sometthing that > should > > be written there. Not sure here... > > > yeah. > > > cheers > > > > Mariano > > > > > > > >> > >> Thanks in advance! > >> -- > >> Johan Fabry > >> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> > >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile > >> > >> > >> > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> Pharo-users(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

4 3

Re: [Pharo-project] [update 1.2] #12161 - #12172
by StÃ©phane Ducasse Oct. 2, 2010

Oct. 2, 2010

OK marcus will give a try. We will have to clean all these points with weakstuff once for all and getting more or less aligned with the work levente did. Stef On Oct 1, 2010, at 5:48 PM, Igor Stasenko wrote: > Here what happens: > > Original method WeakKeyDictionary>>finalizeValues > > WeakKeyDictionary>>finalizeValues > "Clear all associations with nil keys" > array do:[:assoc| > 1 to: array size do:[:i | | assoc | > assoc := array at: i. > assoc ifNotNil:[ > assoc expire ifTrue:[ > expired := expired + 1. > tally := tally - 1. > ]. > ]. > ]. > > And i noticed that after recompilation of this method, it starts > spending much more time to scan 14k entries: > > [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun > 167 > > (my guess that this method was never recompiled with new Eliot's closures). > > Now, if i change it to: > finalizeValues > "Clear all associations with nil keys" > 1 to: array size do:[:i | | assoc | > assoc := array at: i. > array do:[:assoc| > assoc ifNotNil:[ > assoc expire ifTrue:[ > expired := expired + 1. > tally := tally - 1. > ]. > ]. > ]. > > so, #to:do: is inlined by compiler, then numbers is much better: > > [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun > 4 > > Just try it yourself, if you not believe. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] "A Mentoring Course on Smalltalk" Code License
by DeNigris Sean Oct. 2, 2010

Oct. 2, 2010

I emailed Andres, the author, and he said "the code didn't have a license because I meant to put no restrictions on it... The MIT license is fine with me. In fact, I released the Hash Analysis Tool and Assessments under the MIT license already." Then he asked a great question: "Let me know what you need and I'll put it in. Or do you need that the book explicitly states the code mentioned therein is MIT?" I've been contacting many people to declare code as MIT. What "proof" is considered acceptable? I've been announcing it on the mailing list, so anyone could search back, contact me, and I could send them the email I received from the author, but that requires remembering the post, finding it, etc. What's the best way to go about this? License gurus? Sean

5 5

[Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
by Mariano Martinez Peck Oct. 1, 2010

Oct. 1, 2010

Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with "Objects as methods", and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano

6 7

[Pharo-project] Chilean mailing list
by Alexandre Bergel Oct. 1, 2010

Oct. 1, 2010

Hi All! We've just create a mailing list for discussing about Pharo/Smalltalk in Chile. pharo-chile(a)googlegroups.com http://groups.google.com/group/pharo-chile Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

[Pharo-project] loading groups with metacello
by Veronica Isabel Uquillas Gomez Oct. 1, 2010

Oct. 1, 2010

Hi Mariano, You already saw my problem. With this you can check what is happening: (ConfigurationOfGlamour project version: 'default') record: #('Core' 'Tests' 'Extras') all the pre-requisites are being loaded and not only the groups. Regards, Veronica

3 4

Re: [Pharo-project] haltOnce and haltOnCount
by Marcus Denker Oct. 1, 2010

Oct. 1, 2010

On Oct 1, 2010, at 8:08 PM, Hernan Wilkinson wrote: > > PS: A #haltIf: aBlock message would be handy too :-) already there: 1 haltIf: [1<2]. 1 haltIf: [:rec | rec isInteger]. 1 haltIf: (1<2). 1 haltIf: #doIt especially putting a symbol is very useful. e.g. you can out the selector of the test and then even put a haltIf: into system methods called all the time. (e.g. collections). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Oct. 1, 2010

+ 1 really really important On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote: > I used haltOnce quite often when I had to debug the rendering facilities in Mondrian. > Putting "self halt" in a drawOn: method can easily freeze your image. > > Alexandre > > > > On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote: > >> Hi, >> when are these messages used? what are the scenarios? >> I just want to understand why they are there... >> >> -- >> HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
by Igor Stasenko Oct. 1, 2010

Oct. 1, 2010

I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002 I tested applying them in Pharo-Core-#12159 and then updating an image after that. After update: MCMethodDefinition cachedDefinitions size is 18668 But image don't feels slow. As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects). This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations. I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage. -- Best regards, Igor Stasenko AKA sig.

2 4