April 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] curious announcement interaction with halt

by Ben Coman

My understanding of Announcements is not so good yet, but here is another opportunity. While I was trying to trace some code execution to troubleshoot a ticket that I logged for Mondrian, I bumped into some behaviour that seems strange, which I would like to understand. At the end I propose a fix. For the short example, execute [MOEasel open] then <Generate View> on the following: ----8<---- view shape rectangle size: 20. view interaction registerForEvent: MOMouseDown forNode: #yourself updateNode: [ :v | "self halt." view forNode: v do: [ view nodes: (1 to: 2) ] ] updateLayout: true. view nodes: (1 to: 4). ----8<---- Click on a node and observe that node successfully has two nodes within it. Now uncomment the "self halt" and <Generate View>, then click on a node. When the pre-debugger for 'halt' appears, click <Proceed>. Surprisingly a MNU now occurs in MOAnnouncement>>registerForEvent:forNode:updateNode:updateLayout due to 'ann viewRenderer' now returning nil. Observe this occurs immediately after the execution of 'updateBlock' which contained the 'self halt' The extended example modifies MOAnnouncement>>registerForEvent:forNode:updateNode:updateLayout as follows... | domainNode btcRenderer1 btcRenderer1test btcRenderer2 btcRenderer2test btcRenderer1test2 | self on: eventClass do: [:ann | "----8<---- begin debug code " btcRenderer1 := ann viewRenderer. btcRenderer1test := (self viewRenderer == ann viewRenderer ). "self halt." btcRenderer2 := ann viewRenderer. btcRenderer2test := (self viewRenderer == ann viewRenderer ). { self viewRenderer. btcRenderer1. btcRenderer2. btcRenderer1test. btcRenderer2test. } inspect. "----8<---- end debug code " ann element removeAllEdges; removeAllNodes. <Generate View> on the same code as the short example with the 'self halt' commented out, then click on a node. An inspector pops up showing array { aMOViewRenderer. aMOViewRenderer. aMOViewRenderer. true. true. } Then uncomment the 'self halt' in the extended example, <Generate View> and click on a node. <Proceed> at the pre-debugger. An inspector pops up now showing array { aMOViewRenderer. aMOViewRenderer. nil. true. false. } 'ann viewRenderer ' has lost its value following the 'self halt.' Proposed fix: It can be seen from the second inspector that 'self viewRenderer' is identical to 'ann viewRenderer' and retains its value across the 'self halt', and so might be used in its place. thanks for you attention, your thoughts would be appreciated. cheers, -ben

April 9, 2012

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

by Mark Smith

On 9 Apr 2012, at 10:07, Norbert Hartl wrote: > > 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 That seems very reasonable. Is there a place I should put such documentation or should I just blog it and hope that someone finds it in Google? Mark >> >> 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 Mark Smith

I agree with Sven that monospace isn't needed. I've only ever found monospace useful when I've had to work on code with a large number of nested blocks e.g. for if if if if while if ;). In which case it does help expose the codes structure, but I haven't seen that in Smalltalk. I generally go for Geneva http://en.wikipedia.org/wiki/Geneva_(typeface) But I'm not suggesting it be the default in Pharo :). +1 for Droid Sans (licence permitting) but I'd up the point size to be more in line with Svens message. Mark On 9 Apr 2012, at 08:56, Sven Van Caekenberghe wrote: > > 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. > > <Screen Shot 2012-04-09 at 09.52.27.png> > > 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

[Pharo-project] [Urget, GSoC] A (second) for the "HMI with Amber and Pharo" project needed

by Dennis Schetinin

Here is the proposal. I find it really interesting. Anyone else? Best regards, Dennis Schetinin Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

April 9, 2012

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