December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Sven Van Caekenberghe

On 08 Dec 2010, at 10:48, Lukas Renggli wrote: > Very cool framework, I like it a lot! I definitely vote to eventually > replace HTTPSocket with Zinc HTTP Components. Thanks a lot, I am glad you like it. > I wonder why ZnFixedClient is not a subclass of ZnHttpClient? Well, ZnFixedClient is what I wrote earlier for my needs (I use it inside a T3RestJsonClient, then T3CachingRestJsonClient and finally a business specific T3Client, works very well). ZnHttpClient is Matt's later version, partially inspired by your idea of a builder-style API. > I think it would be cool to be able to use them polymorphic. We could maybe use some refactoring, consolidation, redesign (hint, hint). But for me, it is also a search for good solutions where I don't think that one size will fit all, but I could be wrong (for example, Matt's redirection, cookie and more advanced authoritzation support would be nice to have everywhere, it is just that I did not need it yet in my applications). Sven

Dec. 8, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Philippe Marschall

On 12/08/2010 12:32 AM, Levente Uzonyi wrote: > On Tue, 7 Dec 2010, Philippe Marschall wrote: > > snip > >> No, buffering should not be in a subclass or even the file stream class >> itself. Buffering should be an other class that wraps file stream. > > Stream wrappers are cool, but they are totally different from the > current stream design. One could create new stream classes that could do > buffering, conversion, compression, etc. and rewrite existing code to > use them, but if you just rewrite the existing code using an existing > stream library (for example XTreams), then you'll get pretty much the > same thing with less effort. Nope sorry, writing a stream that buffers is not less effort that porting and maintaining a whole stream library and rewriting your code. Cheers Philippe

Dec. 8, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Lukas Renggli

Very cool framework, I like it a lot! I definitely vote to eventually replace HTTPSocket with Zinc HTTP Components. I wonder why ZnFixedClient is not a subclass of ZnHttpClient? I think it would be cool to be able to use them polymorphic. Lukas On 8 December 2010 09:26, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Norbert, > > Thanks for you interest. > > On 07 Dec 2010, at 21:14, Norbert Hartl wrote: > >> I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port. > > This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look. > > I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components) > > The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them). > > Now, why is there not just one good client, why are there 4 different ones ? > > Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API. > > ZnClient is the simplest one: some class methods to fire off one shot requests. > > ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API. > > ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features. > > ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food. > > On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available. > >> Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not. > > The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution. > > Regards, > > Sven > > > -- Lukas Renggli www.lukas-renggli.ch

Dec. 8, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Sven Van Caekenberghe

On 08 Dec 2010, at 00:25, Levente Uzonyi wrote: >> Thanks for the explanation, some quick and dirty buffering makes a huge difference: >> >> [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | >> 1000 timesRepeat: [ >> fileStream nextPutAll: >> (String streamContents: [ :stream | >> 100 timesRepeat: [ stream print: 100 atRandom; space ] ]) ] ] ] timeToRun. >> 159 >> >> Still, the asymmetry is a bit strange. >> Can't the side effects be dealt with using #flush ? > > Lets go back in time. A year ago there was no read buffering (Pharo 1.0 was not released, Squeak 3.10.2 was out) and reading from a file was as slow as writing is currently. Read buffering could be added transparently, so it could give a huge speed improvement to all existing code. > Write buffering could be done the same way, but it would break code, because currently a write is immediately done, while with buffering it > wouldn't be. Some files would be written only when the finalization process closes the file. The solution for this could be automatic flushing on each write, which could be turned off by a method. But that would be the same as not using write buffering at all. > But with the same effort you could use another stream implementation, that does write buffering. And write buffering can't be used to speed up existing code without reviewing it. Thanks again for the explanation. OK, I tried writing my own buffered write stream class: [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | | bufferedStream | bufferedStream := ZnBufferedWriteStream on: fileStream. 100000 timesRepeat: [ bufferedStream print: 100 atRandom; space ]. bufferedStream flush ] ] timeToRun. 165 That wasn' too hard. And indeed, it is necessary to manually send #flush or #close to force the buffer out. But I do not completely agree with the fact that it would be that much work. Stream>>#flush is already a no-op. Adding it to #streamContents: and some others can not be that much work. In fact, SocketStream does already do both input and output buffering (and thus requires #flush or #close), so would potentially fail in certain situations according to your reasoning. No ? Sven

Dec. 8, 2010

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by Marcus Denker

On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote: > Ok, I've done some fixes to OB and OC, and committed them to PharoTaskForces as a temporary solution. > > To load current configuration: > > Gofer it squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. > > (ConfigurationOfPharo project version: '1.2-beta2') load. > > Can Hudson help us in building Dev images? Yes, will set up a build for 1.2 today. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 8, 2010

Re: [Pharo-project] Hudson and version number

by Luc Fabresse

I guess it was the latest version. Yes it would be good to integrate the version number to retrieve it after. Thanks for the info. #Luc 2010/12/8 Adrian Lienhard <adi(a)netstyle.ch> > That's how I did it: > > Install the "Hudson description setter plugin" [1] > > From Pharo, when you do the build and know the last build number, log this > version to stdout (e.g., "[version] 1.2 #12421"). > > In the job config enable "Set build description" and add the following > settings: > - Set build description: "\[version\] (.*)" > - Description: "\1" > > [1] http://wiki.hudson-ci.org/display/HUDSON/Description+Setter+Plugin > > Like this you get a description below each build as shown in the attached > screenshot. > > Cheers, > Adrian > > > > > > On Dec 8, 2010, at 09:39 , Marcus Denker wrote: > > > > > On Dec 8, 2010, at 9:35 AM, Marcus Denker wrote: > > > >> > >> On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote: > >> > >>> Hi all, > >>> > >>> I was looking the results of the 1.2 build #33. > >>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/ > >>> > >>> Where is displayed the version number of the 1.2 used for this build? > >>> Was it the12271? > >>> > >>> > >> I always loads all updates... so it's the version that was available at > the time > >> of build. It would be nice to display the update number... if anyone has > an > >> idea how to do that? > >> > > And I forgot: after an update is commited, the build starts automatically > within > > 2 minutes. So in the end this means: the latest build on Hudson is the > latest > > update available. > > > > Marcus > > > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > >

Dec. 8, 2010

Re: [Pharo-project] Hudson and version number

by Adrian Lienhard

That's how I did it: Install the "Hudson description setter plugin" [1] >From Pharo, when you do the build and know the last build number, log this version to stdout (e.g., "[version] 1.2 #12421"). In the job config enable "Set build description" and add the following settings: - Set build description: "\[version\] (.*)" - Description: "\1" [1] http://wiki.hudson-ci.org/display/HUDSON/Description+Setter+Plugin Like this you get a description below each build as shown in the attached screenshot. Cheers, Adrian On Dec 8, 2010, at 09:39 , Marcus Denker wrote: > > On Dec 8, 2010, at 9:35 AM, Marcus Denker wrote: > >> >> On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote: >> >>> Hi all, >>> >>> I was looking the results of the 1.2 build #33. >>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/ >>> >>> Where is displayed the version number of the 1.2 used for this build? >>> Was it the12271? >>> >>> >> I always loads all updates... so it's the version that was available at the time >> of build. It would be nice to display the update number... if anyone has an >> idea how to do that? >> > And I forgot: after an update is commited, the build starts automatically within > 2 minutes. So in the end this means: the latest build on Hudson is the latest > update available. > > Marcus > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. >

Dec. 8, 2010

Re: [Pharo-project] Problem updating Pharo Core

by Marcus Denker

On Dec 7, 2010, at 12:17 PM, Gary Chambers wrote: > Does the build server run Windows? (c.f. $: in package name). > No, we have right now just a Linux builder. But we will add Mac soon, after that windows. > Regards, Gary > ----- Original Message ----- > From: Marcus Denker > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, December 06, 2010 9:11 PM > Subject: Re: [Pharo-project] Problem updating Pharo Core > > > On Dec 6, 2010, at 7:59 PM, Guillermo Polito wrote: > >> I have the last prebuild pharo core (12261), and clicking on update stops in version 12266 with a DNU: >> >> nil does not understand binary >> >> It has something to do with the monticello a version with this info: 'Issue 3191: SparseLargeArray-MarcusDenker.2.mcz' >> >> Did someone had this same issue? >> > > the build server seems to have no problem: > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/ > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 8, 2010

Re: [Pharo-project] Hudson and version number

by Marcus Denker

On Dec 8, 2010, at 9:35 AM, Marcus Denker wrote: > > On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote: > >> Hi all, >> >> I was looking the results of the 1.2 build #33. >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/ >> >> Where is displayed the version number of the 1.2 used for this build? >> Was it the12271? >> >> > I always loads all updates... so it's the version that was available at the time > of build. It would be nice to display the update number... if anyone has an > idea how to do that? > And I forgot: after an update is commited, the build starts automatically within 2 minutes. So in the end this means: the latest build on Hudson is the latest update available. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 8, 2010

Re: [Pharo-project] Hudson and version number

by Marcus Denker

On Dec 8, 2010, at 8:25 AM, Luc Fabresse wrote: > Hi all, > > I was looking the results of the 1.2 build #33. > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/33/ > > Where is displayed the version number of the 1.2 used for this build? > Was it the12271? > > I always loads all updates... so it's the version that was available at the time of build. It would be nice to display the update number... if anyone has an idea how to do that? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 8, 2010