- Pharo-dev - lists.pharo.org

Re: [Pharo-project] 1.4 ready?

by Mark Smith

Fantastic! :) On 9 Apr 2012, at 10:04, StÃ©phane Ducasse wrote: > > On Apr 9, 2012, at 9:23 AM, Pavel Krivanek wrote: > >> Hi, >> >> as I see on http://code.google.com/p/pharo/issues/list?can=2&q=label%3AMilestone-1.4, >> there are only three open issues for 1.4. Two of them are ready to >> integrate and one needs only CI configuration. Are we ready to >> release? > > Yes :) > > Stef > >> >> Cheers, >> -- Pavel >> > >

April 9, 2012

[Pharo-project] FFI definitions - structs

by recursive68＠gmail.com

Hi, The FFI documentation states the following in terms of defining a C struct fields when defining subclasses of ExternalStructure: ##################################### For example, a color structur might implemented so: - first, create a new class named color in the System Browser (subclass of ExternalStructure) - add class method 'fields' to color maybe, like this: ------------------------------ fields ^#((red 'byte') (green 'byte') (blue 'byte')) ########################################## It only mentions simple data types, int, byte etc, as do the all the examples I've been able to find. How do you define pointers to other structs that are fields that are part of the C struct. E.g. C definition: struct Statement { Stmt *stmt; /* statement handle */ Resultset **rsts; /* pointer to resultset list */ .... Thanks

April 9, 2012

Re: [Pharo-project] So I broke 100 Mbytes/s today

by StÃ©phane Ducasse

thanks philippe for this good energy. Stef On Apr 9, 2012, at 11:48 AM, Philippe Marschall wrote: > Hi > > This is a small update on the work I've been doing on the AJP adapter for Seaside. I've optimized the content rendering and reduced the amount of copying it does for content rendering (header rendering still does more copying than strictly necessary). > > The most dramatic change is with a 16k response (WAFastRequestHandler) where throughput is up from 75 Mbytes/s to 100 Mbytes/s [1]. This is now close to saturating a gigabit link. With an 8k response (WADwBenchHandler) we're now at about 7500 req/s [2] up from a about 6500 req/s. That's close to where the 2 byte response performance was back in February. Speaking of which a 2 byte response (WASmallRequestHandler) is now at 8700 req/s [3] up from about 8100 req/s. > > Apache 2.2.22 mpm_worker mod_proxy_ajp > CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz > Cog r2540 > > You can get the code in the Seaside-Benchmark package in the addons repository [4]. > > [1] https://gist.github.com/2339951 > [2] https://gist.github.com/2339947 > [3] https://gist.github.com/2339940 > [4] http://www.squeaksource.com/Seaside31Addons > > Cheers > Philippe > >

April 9, 2012

[Pharo-project] So I broke 100 Mbytes/s today

by Philippe Marschall

Hi This is a small update on the work I've been doing on the AJP adapter for Seaside. I've optimized the content rendering and reduced the amount of copying it does for content rendering (header rendering still does more copying than strictly necessary). The most dramatic change is with a 16k response (WAFastRequestHandler) where throughput is up from 75 Mbytes/s to 100 Mbytes/s [1]. This is now close to saturating a gigabit link. With an 8k response (WADwBenchHandler) we're now at about 7500 req/s [2] up from a about 6500 req/s. That's close to where the 2 byte response performance was back in February. Speaking of which a 2 byte response (WASmallRequestHandler) is now at 8700 req/s [3] up from about 8100 req/s. Apache 2.2.22 mpm_worker mod_proxy_ajp CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz Cog r2540 You can get the code in the Seaside-Benchmark package in the addons repository [4]. [1] https://gist.github.com/2339951 [2] https://gist.github.com/2339947 [3] https://gist.github.com/2339940 [4] http://www.squeaksource.com/Seaside31Addons Cheers Philippe

April 9, 2012

Re: [Pharo-project] Invalid socket handle in Zinc Server after image startup

by Norbert Hartl

Am 08.04.2012 um 18:56 schrieb Mark Smith: > Great :). I hope you succeed in coaxing Sven to write a chapter. > > The more written down the better :). > So, do it. Documentation written from a user perspective is often more useful than the one written by the developer. The problems you faced and solved are pretty much the same another user will encounter. So you can answer it best. Don't rely on Sven to write documentation but ask him about things you don't understand. Norbert > > On 8 Apr 2012, at 17:48, StÃ©phane Ducasse wrote: > >> I'm trying to make sven write a chapter :) >> So I added it to the server section :) >> >> Stef >> >>> Hi Sven, >>> >>> That makes a lot of sense :). >>> >>> Perhaps this could be added to the Getting Started section of the website? >>> >>> Thanks! >>> >>> Mark >>> >>> On 8 Apr 2012, at 17:11, Sven Van Caekenberghe wrote: >>> >>>> Mark, >>>> >>>> On 08 Apr 2012, at 16:11, Mark Smith wrote: >>>> >>>>> Hi all, >>>>> >>>>> Is anyone else having problems with Zinc servers not starting up correctly when the image is loaded? >>>>> >>>>> After the image starts up the server has an invalid socket handle. >>>>> >>>>> To reproduce, evaluate the following in a workspace, then save and quit the image. >>>>> >>>>> aServer := ZnServer on: 8080. >>>>> aServer delegate: ((ZnMonticelloServerDelegate new) >>>>> directory: (FileDirectory on: '/Users/sven/Tmp/monticello')). >>>>> aServer start >>>>> >>>>> Any ideas? >>>>> >>>>> Mark >>>> >>>> Only the default server (ZnServer default) is sent #register on #start so that it will be sent #start/#stop on System #startUp/#shutDown. >>>> Have a look at ZnSingleThreadedServer>>#start and/or follow ZnServer>>#register. >>>> >>>> To make this work, either change your example to >>>> >>>> aServer := ZnServer defaultOn: 8080. >>>> aServer delegate: ((ZnMonticelloServerDelegate new) >>>> directory: (FileDirectory on: '/Users/sven/Tmp/monticello')). >>>> aServer start >>>> >>>> or to >>>> >>>> aServer := ZnServer on: 8080. >>>> aServer delegate: ((ZnMonticelloServerDelegate new) >>>> directory: (FileDirectory on: '/Users/sven/Tmp/monticello')). >>>> aServer register. >>>> aServer start >>>> >>>> It is by design that not every server is registered (as not everyone needs this behavior). >>>> The default server is an exception because it is used for first time and more casual usage and many people expect this behavior in Smalltalk. >>>> >>>> HTH, >>>> >>>> Sven >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> http://stfx.eu >>>> Smalltalk is the Red Pill >>>> >>> >>> >> >> > >

April 9, 2012

Re: [Pharo-project] font reading problems

by StÃ©phane Ducasse

indeed much nicer. After this is a question of license to ship by default. For 1.4 we should probably put Bitmap DejaVu Sans Regular 12 or something like that. The default should be good. On Apr 9, 2012, at 10:59 AM, Alexis Parseghian wrote: > I have found Droid Sans to be quite pleasant to work with. > <PharoScreenshot.3.png>

April 9, 2012

Re: [Pharo-project] 1.4 ready?

by StÃ©phane Ducasse

On Apr 9, 2012, at 9:23 AM, Pavel Krivanek wrote: > Hi, > > as I see on http://code.google.com/p/pharo/issues/list?can=2&q=label%3AMilestone-1.4, > there are only three open issues for 1.4. Two of them are ready to > integrate and one needs only CI configuration. Are we ready to > release? Yes :) Stef > > Cheers, > -- Pavel >

April 9, 2012

Re: [Pharo-project] Using stdout in Windows --> 'File stdout is closed'

by StÃ©phane Ducasse

Can you check with squeak? Because we took stout from levente's work and I do not see why it would not work. Did you try with the latest VM? also the one of eliot? Because may be there is a primitive problem. Stef On Apr 9, 2012, at 1:31 AM, Martin Dias wrote: > Hi > > In my windows 7, I get an error when trying to write to "FileStream stdout" in both Pharo 1.4 and 1.3 (revisions #14423 and #13320). > > To reproduce, > > - download: > https://ci.lille.inria.fr/pharo/job/Pharo%201.4/373/artifact/Pharo-1.4.zip > > - evaluate: > FileStream stdout nextPutAll: 'a'. > > Is this a known issue? I couldn't find it in issue tracker. > > Thanks in advance. > MartÃn > <PharoDebug.log>

April 9, 2012

Re: [Pharo-project] font reading problems

by Alexis Parseghian

I have found Droid Sans to be quite pleasant to work with.

April 9, 2012

Re: [Pharo-project] font reading problems

by Sven Van Caekenberghe

On 08 Apr 2012, at 21:03, StÃ©phane Ducasse wrote: > I do not like the default font because there is not enough space around : > so this is difficult to see it for example in > > := <Screen Shot 2012-04-08 at 9.02.59 PM.pdf><Screen Shot 2012-04-08 at 9.03.22 PM.pdf> > > > so what can be done? > Can we modify this font? I always use a larger font, Bitmap DejaVu Sans Regular 12, currently called Medium I think. But now that you mention it, maybe it would be nice if colons were a bit more heavy. Smalltalk methods should be small, hence a bigger font still works. They also don't need monospace, let's keep it like that. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 9, 2012