- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cog/FFI Return Values

by Eliot Miranda

Hi Ken, On Thu, Mar 17, 2011 at 5:38 PM, Ken Treis <ken(a)miriamtech.com> wrote: > See attached for changes vs VMMaker-oscog.40. I added a couple of simple > test methods to the preamble and used them in my test cases. > > The push/popRemappableOop stuff is over my head. I basically cloned the > code quoted below, but I had to introduce a temporary variable. I'm guessing > that it doesn't need the same treatment, but no doubt you can clean that up > for me if needs be. > > With this change, GemTools work in Cog for me. Thanks for the guidance and > encouragement. > woot! Thanks so much for this Ken! Welcome to the Cog team!! > > > Ken > > On Mar 16, 2011, at 4:45 PM, Eliot Miranda wrote: > > > > On Wed, Mar 16, 2011 at 4:25 PM, Ken Treis <ken(a)miriamtech.com> wrote: > >> On Mar 15, 2011, at 3:36 PM, Eliot Miranda wrote: >> >> > I expect that if the standard FFI plugin answers an instance of >> OopType64 then you've found a bug in the ReentrantFFIPlugin. If you're >> brave you'll have a look at both plugins and try and verify that that's the >> case. But I have to say that the FFI plugins are not simple. >> >> Brave, yes. Smart, no. Here's what it looks like to my untrained eye: >> >> 1. When the ExternalFunction is compiled, the return argType is not >> flagged as a structure. So the primitives, old and new, see this as a >> regular non-struct callout, but with return class = OopType64. So far, so >> good. >> >> 2. The old plugin had this one-slot "wrapping" capability at the bottom of >> #ffiCreateReturn: (which is called only for non-pointer, non-structure >> functions): >> >> ffiRetClass := interpreterProxy popRemappableOop. >> ffiRetClass == interpreterProxy nilObject ifTrue:[ >> "Just return oop" >> ^interpreterProxy push: retOop]. >> "Otherwise create an instance of external structure and store the >> return oop" >> interpreterProxy pushRemappableOop: retOop. >> retOop := interpreterProxy instantiateClass: ffiRetClass >> indexableSize: 0. >> oop := interpreterProxy popRemappableOop. >> interpreterProxy storePointer: 0 ofObject: retOop withValue: oop. >> ^interpreterProxy push: retOop. >> >> 3. There's some very similar code in FFIPlugin>>ffiCreateReturnStruct and >> ReentrantIA32FFIPlugin>>ffiReturnStruct:ofType:in: -- the main difference is >> a memcpy(). >> >> Am I on the right track? If so, how would you like to see the code >> structured to get this feature restored? We could add a new >> wrap-if-necessary return method, or we could try to reuse >> #ffiReturnStruct:ofType:in: if we guarded the memcpy() with a flag check for >> FFIFlagStructure. >> > > If you're happy producing a fix I'll take whatever works, a test case and > the I can always muck it up if I disapprove :) > > >> >> Or maybe there's a cleaner solution that's beyond my hazy view at the >> moment. >> > > I think you're on the right track. I probably misread when I wrote my > first cut. Apologies. > > best > Eliot > > >> >> -- >> Ken Treis >> Miriam Technologies, Inc. >> >> > > -- > Ken Treis > Miriam Technologies, Inc. > > >

March 18, 2011

Re: [Pharo-project] Cog/FFI Return Values

by Ken Treis

See attached for changes vs VMMaker-oscog.40. I added a couple of simple test methods to the preamble and used them in my test cases. The push/popRemappableOop stuff is over my head. I basically cloned the code quoted below, but I had to introduce a temporary variable. I'm guessing that it doesn't need the same treatment, but no doubt you can clean that up for me if needs be. With this change, GemTools work in Cog for me. Thanks for the guidance and encouragement. Ken On Mar 16, 2011, at 4:45 PM, Eliot Miranda wrote: > > > On Wed, Mar 16, 2011 at 4:25 PM, Ken Treis <ken(a)miriamtech.com> wrote: > On Mar 15, 2011, at 3:36 PM, Eliot Miranda wrote: > > > I expect that if the standard FFI plugin answers an instance of OopType64 then you've found a bug in the ReentrantFFIPlugin. If you're brave you'll have a look at both plugins and try and verify that that's the case. But I have to say that the FFI plugins are not simple. > > Brave, yes. Smart, no. Here's what it looks like to my untrained eye: > > 1. When the ExternalFunction is compiled, the return argType is not flagged as a structure. So the primitives, old and new, see this as a regular non-struct callout, but with return class = OopType64. So far, so good. > > 2. The old plugin had this one-slot "wrapping" capability at the bottom of #ffiCreateReturn: (which is called only for non-pointer, non-structure functions): > > ffiRetClass := interpreterProxy popRemappableOop. > ffiRetClass == interpreterProxy nilObject ifTrue:[ > "Just return oop" > ^interpreterProxy push: retOop]. > "Otherwise create an instance of external structure and store the return oop" > interpreterProxy pushRemappableOop: retOop. > retOop := interpreterProxy instantiateClass: ffiRetClass indexableSize: 0. > oop := interpreterProxy popRemappableOop. > interpreterProxy storePointer: 0 ofObject: retOop withValue: oop. > ^interpreterProxy push: retOop. > > 3. There's some very similar code in FFIPlugin>>ffiCreateReturnStruct and ReentrantIA32FFIPlugin>>ffiReturnStruct:ofType:in: -- the main difference is a memcpy(). > > Am I on the right track? If so, how would you like to see the code structured to get this feature restored? We could add a new wrap-if-necessary return method, or we could try to reuse #ffiReturnStruct:ofType:in: if we guarded the memcpy() with a flag check for FFIFlagStructure. > > If you're happy producing a fix I'll take whatever works, a test case and the I can always muck it up if I disapprove :) > > > Or maybe there's a cleaner solution that's beyond my hazy view at the moment. > > I think you're on the right track. I probably misread when I wrote my first cut. Apologies. > > best > Eliot > > > -- > Ken Treis > Miriam Technologies, Inc. > > -- Ken Treis Miriam Technologies, Inc.

March 18, 2011

[Pharo-project] GSOC 2010 results

by Torsten Bergmann

While reading about the last GSOC 2010 at: http://code.google.com/p/google-summer-of-code-2010-esug/downloads/list I wonder what happened to the results. Are they just available to play with them in private. Or will Pharo/the overall Smalltalk community profit from them since they can be usefull for the next step. Therefore especially two questions: 1. Is the Namespace code conceptually the one we want to have for Pharo and if so are there any plans to integrate it (Pharo 1.3/1.4./... ?) 2. Is the code from Cross-Dialect Smalltalk FFI ready or what is the state/strategy for Alien/FFI these days. Thx T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

March 17, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Marcus Denker

On Mar 17, 2011, at 7:13 PM, Lukas Renggli wrote: > I've got my complete Jenkins server building on Pharo 1.2 now: > > http://jenkins.lukas-renggli.ch/ > > Some stuff is still a bit broken, but it looks good so far. > Very good! We then can release the 1.2 Full soon, too. I wonder if we should adopt your OB codebase for that? Or do we wait for 1.2.1? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 17, 2011

Re: [Pharo-project] [COTDC] - 33 StrikeFontSet

by laurent laffont

Someone ? Laurent. On Wed, Mar 16, 2011 at 9:47 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: StrikeFontSet > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

March 17, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by StÃ©phane Ducasse

> >> I've got my complete Jenkins server building on Pharo 1.2 now: >> >> http://jenkins.lukas-renggli.ch/ >> >> Some stuff is still a bit broken, but it looks good so far. >> > cool. > > We need to put a pressure on INRIA guys to upgrade to jenkins.. > because right now > some things are not working well they know it and they have their own agenda. For me I'm happy that they take care of the infrastructure. Stef

March 17, 2011

Re: [Pharo-project] why RefactoringEnvironment requires AST-Core

by StÃ©phane Ducasse

On Mar 17, 2011, at 7:05 PM, Lukas Renggli wrote: >> and I was wondering where is used the selectionIntervalFor: > > To accurately highlight matches (senders, implementers, parse tree > matches, lint issues) in the tools. so this could be packaged separated so that we can use the environment without having to have the AST-core + parser loaded. In our version we will separate that. When AST-Core will be the default AST the problem will be less important. >> Then I saw that BrowserEnvironmentWrapper introduces environment (which is good) > > 'BrowserEnvironment' implements a composite pattern. The variable > 'environment' refers to another 'BrowserEnvironment' instance, not to > a 'SystemDictionary'. > >> Now the superclass uses directly Smalltalk globals so may be this would be good to move enviroment above >> this way we can have a selection of the environemt as in BrowserEnvironment > > No, BrowserEnvironment represents the system. In a system with > multiple namespaces it represents a merged view of all the classes in > the complete system no matter what namespace they are in. If we had > namespaces a new subclass (NamespaceEnvironment) could provide a view > onto a particular namespace, just like the PackageEnvironment does > today. but why not having environment = a parametrizing namespace in the browser environment this way we avoid all the Smalltalk globals everywhere and suddenly we can use the same environment to browse remote images and have currentSelectionEnvironment = the composite. I do not see why Wrapper is needed. >> also have a browser that can browse a remote environment. > > This was once possible, but since Class/Metaclass/SmalltalkDictionary > moved so far away from RBClass/RBMetaclass/BrowserEnvironment (they > were once polymorphic) it is very hard to do anything that works on > different models. We will fix. I think that we will clone the code and see what we can do. Stef

March 17, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Igor Stasenko

On 17 March 2011 19:11, Lukas Renggli <renggli(a)gmail.com> wrote: > I've got my complete Jenkins server building on Pharo 1.2 now: > > Â Â http://jenkins.lukas-renggli.ch/ > > Some stuff is still a bit broken, but it looks good so far. > cool. We need to put a pressure on INRIA guys to upgrade to jenkins.. because right now some things are not working well > Lukas > > On 16 March 2011 18:09, Lukas Renggli <renggli(a)gmail.com> wrote: >> Excellent! Can somebody update >> >> Â Â http://www.pharo-project.org/pharo-download/stable-core >> >> because it still points to Pharo 1.1.1, thus the build server picks up >> the old image. >> >> Lukas >> >> On 14 March 2011 22:13, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >>> Saturday, 1.2 worked with a Cog-Stack VM. >>> >>> Noury >>> On 14 mars 2011, at 15:17, Marcus Denker wrote: >>> >>>> >>>> On Mar 14, 2011, at 3:08 PM, laurent laffont wrote: >>>> >>>>> >>>>> On Mon, Mar 14, 2011 at 2:40 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>>> Please check... >>>>> >>>>> >>>>> Â Â Â Â https://gforge.inria.fr/frs/download.php/28340/PharoCore-1.2.zip >>>>> >>>>> >>>>> What is the official VM for Pharo 1.2 ? Running all tests with Cog (OSX) => crash. >>>>> >>>> >>>> Not cog yet... all the time the integration server did *not* run cog, so I would not push >>>> it in the last second. Just one tiny step at a time... 1.3 then we should start to >>>> use Cog (for integration, too)... first we need to finish the hudson build of Cog, though. >>>> >>>> >>>> Â Â Â Marcus >>>> >>>> -- >>>> Marcus Denker Â -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>> >>> Noury Bouraqadi >>> http://car.mines-douai.fr/noury >>> -- >>> -6th National Conference on >>> âControl Architecture of Robotsâ >>> 24-25 may 2011, Grenoble area, France >>> http://car2011.inrialpes.fr/ >>> >>> -19th ESUG International Smalltalk Conference >>> 22-26 August 2011, Edinburgh, UK >>> http://www.esug.org/Conferences/2011 >>> >>> -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) >>> http://www.univ-valenciennes.fr/congres/jfsma2011/ >>> 17-19 Octobre 2011, Valenciennes, France >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Best regards, Igor Stasenko AKA sig.

March 17, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Lukas Renggli

I've got my complete Jenkins server building on Pharo 1.2 now: http://jenkins.lukas-renggli.ch/ Some stuff is still a bit broken, but it looks good so far. Lukas On 16 March 2011 18:09, Lukas Renggli <renggli(a)gmail.com> wrote: > Excellent! Can somebody update > > Â Â http://www.pharo-project.org/pharo-download/stable-core > > because it still points to Pharo 1.1.1, thus the build server picks up > the old image. > > Lukas > > On 14 March 2011 22:13, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> Saturday, 1.2 worked with a Cog-Stack VM. >> >> Noury >> On 14 mars 2011, at 15:17, Marcus Denker wrote: >> >>> >>> On Mar 14, 2011, at 3:08 PM, laurent laffont wrote: >>> >>>> >>>> On Mon, Mar 14, 2011 at 2:40 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> Please check... >>>> >>>> >>>> Â Â Â Â https://gforge.inria.fr/frs/download.php/28340/PharoCore-1.2.zip >>>> >>>> >>>> What is the official VM for Pharo 1.2 ? Running all tests with Cog (OSX) => crash. >>>> >>> >>> Not cog yet... all the time the integration server did *not* run cog, so I would not push >>> it in the last second. Just one tiny step at a time... 1.3 then we should start to >>> use Cog (for integration, too)... first we need to finish the hudson build of Cog, though. >>> >>> >>> Â Â Â Marcus >>> >>> -- >>> Marcus Denker Â -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >> >> Noury Bouraqadi >> http://car.mines-douai.fr/noury >> -- >> -6th National Conference on >> âControl Architecture of Robotsâ >> 24-25 may 2011, Grenoble area, France >> http://car2011.inrialpes.fr/ >> >> -19th ESUG International Smalltalk Conference >> 22-26 August 2011, Edinburgh, UK >> http://www.esug.org/Conferences/2011 >> >> -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) >> http://www.univ-valenciennes.fr/congres/jfsma2011/ >> 17-19 Octobre 2011, Valenciennes, France >> >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

March 17, 2011

Re: [Pharo-project] why RefactoringEnvironment requires AST-Core

by Lukas Renggli

> and I was wondering where is used the selectionIntervalFor: To accurately highlight matches (senders, implementers, parse tree matches, lint issues) in the tools. > Then I saw that BrowserEnvironmentWrapper introduces environment (which is good) 'BrowserEnvironment' implements a composite pattern. The variable 'environment' refers to another 'BrowserEnvironment' instance, not to a 'SystemDictionary'. > Now the superclass uses directly Smalltalk globals so may be this would be good to move enviroment above > this way we can have a selection of the environemt as in BrowserEnvironment No, BrowserEnvironment represents the system. In a system with multiple namespaces it represents a merged view of all the classes in the complete system no matter what namespace they are in. If we had namespaces a new subclass (NamespaceEnvironment) could provide a view onto a particular namespace, just like the PackageEnvironment does today. > also have a browser that can browse a remote environment. This was once possible, but since Class/Metaclass/SmalltalkDictionary moved so far away from RBClass/RBMetaclass/BrowserEnvironment (they were once polymorphic) it is very hard to do anything that works on different models. Lukas -- Lukas Renggli www.lukas-renggli.ch

March 17, 2011