- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] NBOpenGL update

by Schwab,Wilhelm K

+1. I have it loaded on Linux, but have *no* clue what to try, or if it even has hope of working (I see Win32 and Mac categories, but no linux-specifics). Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Damien Cassou [damien.cassou(a)gmail.com] Sent: Monday, April 09, 2012 11:04 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] NBOpenGL update On Fri, Apr 6, 2012 at 3:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I did not tested the update thoroughly.. so i would appreciate if > people will try it out and tell how it goes. please tell us what we can do to test. I'm on linux. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 9, 2012

Re: [Pharo-project] FFI definitions - structs

by Schwab,Wilhelm K

Try something like what appears below. If you search the Squeak archives, you'll probably find some useful posts by Andreas Raab. Don't expect too much documentation. Overall, Squeak/Pharo's FFI still falls far short of Dolphin's (sorry, but it's true), and structure mapping is a big area of relative weakness. Note that you *might* have to add an instance variable and accessors to allow the struct to hold a reference to the "real" target object - otherwise the GC might pull things out from under you. Somewhere in the Dolphin image, there are examples of the phenomenon. HTH. Bill ============================== fields " Gsl_wavelet defineFields struct { const gsl_wavelet_type *type; const double *h1; const double *g1; const double *h2; const double *g2; size_t nc; size_t offset; }" ^#( ( type 'Gsl_wavelet_type*' ) ( h1 'double*' ) ( g1 'double*' ) ( h2 'double*' ) ( g2 'double*' ) ( nc 'long' ) ( offset 'long' ) ) ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of recursive68(a)gmail.com [recursive68(a)gmail.com] Sent: Monday, April 09, 2012 8:04 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] FFI definitions - structs 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] Invalid socket handle in Zinc Server after image startup

by Sven Van Caekenberghe

On 08 Apr 2012, at 18:48, StÃ©phane Ducasse wrote: > I'm trying to make sven write a chapter :) > So I added it to the server section :) Yes, I have to write some (more) documentation, I know. It is on my list. And one day it will happen. Sven

April 9, 2012

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

by Sven Van Caekenberghe

On 09 Apr 2012, at 11:48, 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 That is great news, Philippe. I like the WADwBenchHandler because it does dynamically create a 25x25 table on each request. Proves that you can get far by optimizing really hard. Another datapoint for those asking performance related questions. Are the rendering optimizations that you did something that will be/become part of Seaside proper ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 9, 2012

Re: [Pharo-project] [ANN] NBOpenGL update

by Damien Cassou

On Fri, Apr 6, 2012 at 3:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I did not tested the update thoroughly.. so i would appreciate if > people will try it out and tell how it goes. please tell us what we can do to test. I'm on linux. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 9, 2012

Re: [Pharo-project] [ANN] NBOpenGL update

by Javier PimÃ¡s

Cool!, I'll check on linux when I have some free time. Cheers. On Fri, Apr 6, 2012 at 10:31 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi there, > > for those, who interested, i updated a NBOpenGL configuration. > > Changes are: > > - updated GL API to most recent available (taken directly from opengl > specs). Now there is about 300 more methods to explore :) > - finally dealt with win32 support code and made it working again > - fixed the GLX function prefix , which should be 'glX' not 'glx' > > To load it in 1.4 use: > > Gofer new > squeaksource: 'NBOpenGL'; > package: 'ConfigurationOfNBOpenGL'; > load. > > > and then > > (ConfigurationOfNBOpenGL project version: '1.0.2') load > > I did not tested the update thoroughly.. so i would appreciate if > people will try it out and tell how it goes. > > > -- > Best regards, > Igor Stasenko. > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

April 9, 2012

[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