May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Zinc problem with PUT requests

by Sven Van Caekenberghe

Hi Damien, On 21 May 2013, at 10:20, Damien Cassou <damien.cassou(a)gmail.com> wrote: > It looks like Zinc has a problem handling PUT requests (at least > ZnZincServerAdaptor). If I replace ZnZincServerAdaptor by WAKom, then > things work fine. To reproduce: > > Setting up the Server > 1- Download a SmalltalkHub image > (https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/) > 2- Install mongodb on your computer (for Debian: apt-get install mongodb) > 3- Launch the SmalltalkHub image > 4- Evaluate: ZnZincServerAdaptor startOn: 8080 > 5- Visit http://localhost:8080/tools/hub, create an account and a project > > Setting up the Client > 6- In a different image, start monticello > 7- add the repository of your new project to Monticello (something > like http://localhost:8080/mc/YourUser/YourProject/main) don't forget > the username and password > 8- copy an existing package of your cache to the new repository > > You will get an error in the client: a ZnStringEntity(text/plain 512B > file is too short) > > If you install Seaside-Adaptors-Kommanche and use WAKom, things will > work just fine. > > You can configure Seaside to open a server-side error: just setup the > WAExceptionFilter to WADebugErrorHandler in > http://localhost:8080/config/mc > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill Thanks for the detailed instructions, now I have StHub & mongo running on my machine ;-) The problem you reported can easily be fixed by loading the latest version of Zinc-Seaaside (the one in the StHub image is very old). Now, it still does not fully work, but I don't understand all the Sh and MA stuff, I am afraid. But if you go up the stack until you find Seaside's aRequestContext and find the request body in it (the data which was PUT), you can do (ZipArchive new readFrom: self asByteArray readStream) members on it, so for me that means the data arrives OK. If you have another problem with the Zinc/Adaptor part, please let me know. HTH, Sven PS:

May 21, 2013

Re: [Pharo-dev] Printing of BlockClosures

by Marcus Denker

On May 20, 2013, at 6:12 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 20, 2013, at 6:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> One of the things that always positively surprised me about Smalltalk was the fact that BlockClosures are printing showing their actual source code, you don't get that in many languages. >> >> But now this seems to be gone, maybe temporarily, from 3.0 >> >> [ :n | n + 1 ] => [â¦] >> >> Was this intentional ? >> > Yes, the old compiler does it with lots of horrible code with decompilationâ¦ so I removed it for now, the new compiler > can do it very nicely. > > I will add it back for when Opal is running soon. The change is (BlockClosure): printOn: aStream aStream nextPutAll: self sourceNode formattedCode. this then uses the new AST and BC<-> AST Mappingâ¦ maybe a good way to test it. Marcus

May 21, 2013

Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31

by Max Leske

Sven, the build is back to stable. Thanks anyway! Max On 21.05.2013, at 10:27, Max Leske <maxleske(a)gmail.com> wrote: > > On 21.05.2013, at 10:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Max, >> >> On 21 May 2013, at 09:43, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Not sure if this is related, but my FileSystem-Git build for 2.0 broke this morning with a Zn stack trace (bad gateway): https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/PHARO=20,VERSION=… >> >> Assuming you are loading Zn's #bleedingEdge, could you send me the URL you try to access and that fails ? > > Hm, doesn't seem to be bleeding edge (although is 2.0 dev). The test is fine on my local machine, so perhaps there's something wrong at inria? > > Here's the incantation: > ZnClient new > url: aUrl asZnUrl / 'info' / 'refs'; > queryAt: 'service' put: 'git-upload-pack'; > "username: 'admin' password: 'admin';" > enforceHttpSuccess: true; > streaming: true; > get; > yourself > > with url: 'https://git.gitorious.org/gitorious/mainline.git' > > Thanks Sven. > >> >> I mean a standalone version of what is happening here >> >> ZnClient>>get >> GitDumbHTTPProtocol class>>initialRequestTo: >> GitDumbHTTPProtocol class>>connectTo: >> GitAbstractProtocol class>>url: >> GitSmartHTTPProtocolTest(GitAbstractProtocolTest)>>newProtocol >> GitSmartHTTPProtocolTest(GitAbstractProtocolTest)>>testTags >> GitSmartHTTPProtocolTest(TestCase)>>performTest >> >> If that is possible without giving out credentials. >> >> Sven >> >>> Max >>> >>> On 21.05.2013, at 09:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 21 May 2013, at 09:30, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>>> >>>>> - continue working on the configuration (it looks like Zinc has a bug with its handling of PUT requests) >>>> >>>> Hi Damien, please elaborate, maybe I can help. >>>> >>>> Sven >>>> >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> Proudly supporting Pharo >>>> http://pharo.org >>>> http://association.pharo.org >>>> http://consortium.pharo.org >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >

May 21, 2013

Fwd: [Pharo-fuel] (Identity)Dictionary benchmarks

by Max Leske

Begin forwarded message: > From: Camillo Bruni <camillobruni(a)gmail.com> > Subject: Re: [Pharo-fuel] (Identity)Dictionary benchmarks > Date: 21. Mai 2013 10:58:29 MESZ > To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > my random pessimistic comments > > a) your benchmarking script sucks! => use SMARK!! http://smalltalkhub.com/#!/~StefanMarr/SMark > b) check my master thesis for a more thorough testing of dictionary, including a cleaner implementation that defaults to something like a small dictionary without a special class: http://scg.unibe.ch/archive/masters/Brun11a.pdf > > the optimistic version: > > > On 2013-05-21, at 09:47, Max Leske <m.leske(a)netstyle.ch> wrote: > >> My coworker performed some interesting benchmarks on the various dictionary types in Pharo. If you look at the attachments you'll see four things: >> 1. SmallDictionary and SmallIdentityDictionary are totally useless when it comes to performance. Unless their existence is somehow justified by saving space (which might be important for embedded systems) I don't see why we should keep them around. > > yes their usage is not always justified, but be careful what you measure: as far as I see you only measure addition, no? (sorry again, but that benchmark brutally sucks, it's so damn hard to read... :P). Iteration and retrieval have to measure as well, also how the dictionaries behave under key hash collisions (though I am definitely not defending the small dicts.. :). > >> 2. The special Fuel collections for large numbers of elements could be a valuable addition to the basic collections > > THere is the pluggable key dictionary for that reason already, no? The main problem is the limited hashes which results in quite some hash collisions for very large dictionaries. > >> 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). > > that is really strange :/ > >> 4. Arrays are cool :) >> >> Should I open issues on FogBugz for any of these points? Especially point 3 bothers me because I feel that using a "primitive" type should be fast under all circumstances. >> >> You'll find below the benchmark data (collected in 1.4, verified in 2.0) and the code to run it. >> >> Cheers, >> Max >> >>> >> <performance.xlsx> >>> >>> >> <performance.xls> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------- >>> >>> ( comments are variations) >>> >>> sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 ). >>> "sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 1500 2000 2500 3000 3500 4000 4500 5000 6000 7000 8000 9000 10000 )." >>> "batches := sizes collect: [ :size | size -> ((10000000 / size) asFloat // 10) ]." >>> batches := sizes collect: [ :size | size -> 10000 ]. >>> alphabet := Character alphabet. >>> >>> batches do: [ :a | Transcript tab; show: a key asString ]. Transcript cr. >>> batches do: [ :a | Transcript tab; show: a value asString ]. Transcript cr. >>> "{ Dictionary. SmallDictionary. IdentityDictionary. SmallIdentityDictionary. FLLargeIdentityDictionary } " >>> { Dictionary. IdentityDictionary. FLLargeIdentityDictionary } >>> "{ Array }" >>> do: [ :class | >>> Smalltalk garbageCollect. >>> Transcript show: class name. >>> batches >>> do: [ :a | >>> | struct strings iterations | >>> "strings := (1 to: a key) collect: [ :i | i asString ]." >>> strings := (1 to: a key) collect: [ :i | >>> String streamContents: [ :s | >>> 20 atRandom timesRepeat: [ s nextPut: alphabet atRandom ] ] ]. >>> struct := class new. >>> "struct := (class = FLLargeIdentityDictionary >>> ifTrue: [ class new ] >>> ifFalse: [ class new: a key ])." >>> Transcript tab; show: ([ >>> a value timesRepeat: [ >>> 1 to: a key do: [ :i | struct at: (strings at: i)" i" put: i ] ] ] timeToRun). >>> strings := nil ] >>> displayingProgress: class name asString. >>> Transcript cr. ] >>> displayingProgress: 'Processing ...' >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/20 Igor Stasenko <siguctua(a)gmail.com> > also, going ahead.. how easy/hard would be to implement a password input > field, > when model contains what user types, but display all *** chars? > I forgot to implement it :)) It is easy. I will add it at next version.

May 21, 2013

[update 3.0] #30150

by Esteban Lorenzano

30150 ----- 10704 split package Text into smaller components https://pharo.fogbugz.com/f/cases/10704 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Tests-EstebanLorenzano.2… http://smalltalkhub.com/mc/Pharo/Pharo30/main/TextTests-EstebanLorenzano.7.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-EstebanLorenzano… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Scanning-EstebanLorenzan… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Core-EstebanLorenzano.2.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-EstebanLorenzano.74.diff

May 21, 2013

Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31

by Max Leske

On 21.05.2013, at 10:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Max, > > On 21 May 2013, at 09:43, Max Leske <maxleske(a)gmail.com> wrote: > >> Not sure if this is related, but my FileSystem-Git build for 2.0 broke this morning with a Zn stack trace (bad gateway): https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/PHARO=20,VERSION=… > > Assuming you are loading Zn's #bleedingEdge, could you send me the URL you try to access and that fails ? Hm, doesn't seem to be bleeding edge (although is 2.0 dev). The test is fine on my local machine, so perhaps there's something wrong at inria? Here's the incantation: ZnClient new url: aUrl asZnUrl / 'info' / 'refs'; queryAt: 'service' put: 'git-upload-pack'; "username: 'admin' password: 'admin';" enforceHttpSuccess: true; streaming: true; get; yourself with url: 'https://git.gitorious.org/gitorious/mainline.git' Thanks Sven. > > I mean a standalone version of what is happening here > > ZnClient>>get > GitDumbHTTPProtocol class>>initialRequestTo: > GitDumbHTTPProtocol class>>connectTo: > GitAbstractProtocol class>>url: > GitSmartHTTPProtocolTest(GitAbstractProtocolTest)>>newProtocol > GitSmartHTTPProtocolTest(GitAbstractProtocolTest)>>testTags > GitSmartHTTPProtocolTest(TestCase)>>performTest > > If that is possible without giving out credentials. > > Sven > >> Max >> >> On 21.05.2013, at 09:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 21 May 2013, at 09:30, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> >>>> - continue working on the configuration (it looks like Zinc has a bug with its handling of PUT requests) >>> >>> Hi Damien, please elaborate, maybe I can help. >>> >>> Sven >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >>> >> >> > >

May 21, 2013

Re: [Pharo-dev] (Identity)Dictionary benchmarks

by Max Leske

On 21.05.2013, at 10:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 21 May 2013, at 09:59, Max Leske <maxleske(a)gmail.com> wrote: > >> 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). > > Yeah, SmallInteger>>#hashMultiply looks weird and complicated. Probably some attempt at distributing keys better. That's exactly what I gathered from the issues I looked through on FogBugz. > > But like you say: if #hash can return self, why would #identityHash not do the same ? > > But I am no hashing expert...

May 21, 2013

Zinc problem with PUT requests

by Damien Cassou

It looks like Zinc has a problem handling PUT requests (at least ZnZincServerAdaptor). If I replace ZnZincServerAdaptor by WAKom, then things work fine. To reproduce: Setting up the Server 1- Download a SmalltalkHub image (https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/) 2- Install mongodb on your computer (for Debian: apt-get install mongodb) 3- Launch the SmalltalkHub image 4- Evaluate: ZnZincServerAdaptor startOn: 8080 5- Visit http://localhost:8080/tools/hub, create an account and a project Setting up the Client 6- In a different image, start monticello 7- add the repository of your new project to Monticello (something like http://localhost:8080/mc/YourUser/YourProject/main) don't forget the username and password 8- copy an existing package of your cache to the new repository You will get an error in the client: a ZnStringEntity(text/plain 512B file is too short) If you install Seaside-Adaptors-Kommanche and use WAKom, things will work just fine. You can configure Seaside to open a server-side error: just setup the WAExceptionFilter to WADebugErrorHandler in http://localhost:8080/config/mc -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 21, 2013

Re: [Pharo-dev] (Identity)Dictionary benchmarks

by Sven Van Caekenberghe

On 21 May 2013, at 09:59, Max Leske <maxleske(a)gmail.com> wrote: > 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). Yeah, SmallInteger>>#hashMultiply looks weird and complicated. Probably some attempt at distributing keys better. But like you say: if #hash can return self, why would #identityHash not do the same ? But I am no hashing expert...

May 21, 2013