March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Igor Stasenko

On 17 March 2011 03:20, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > I'm also seeing that NBCoInterpreter and NBCoObjectMemory onlyÂ haveÂ small > modifications compared to the non NB ones. Maybe it is possible to merge > them directly into cog with an enable/disable flag, so that building NB is > the same as building Cog with NB enabled. > Yes, the changes are very small, but i wanted to keep them separate, so its easy to see them. So if you can't wait, you can just patch the original classes and then generate VM sources using usual command. But don't forget to include NativeBoostPlugin as internal one. If you using CMakeVMMaker, you do it like following: | config | config := CogUnixConfig new. config internalPlugins: (cog internalPlugins copyWith: #NativeBoostPlugin). config generateSourceFiles. config generate. -- Best regards, Igor Stasenko AKA sig.

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Javier PimÃ¡s

Maybe it is too much to ask, but having a NBCogUnixDebugConfig would be pretty useful in this context! On Wed, Mar 16, 2011 at 11:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 March 2011 03:10, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > Hi! I'm following the steps on the wiki to generate the NativeBoost > plugin. > > First of all I'd like to know if these steps are up to date (there has > been > > some activity since december when they were written). Then, I > successfully > > generated sources but don't know what to do next. Is it possible to > generate > > a CMakeFile, or how do I build everything? > > Piece of cake... I will create a separate CMakeVMMaker config for it.. > so you will do something like: > > NBCogUnixConfig generateWithSources > > and then in command line do as usual: > cmake . > make > > :) > > > Thanks! > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Igor Stasenko

On 17 March 2011 03:10, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > Hi! I'm following the steps on the wiki to generate the NativeBoost plugin. > First of all I'd like to know if these steps are up to date (there has been > some activity since december when they were written). Then, I successfully > generated sources but don't know what to do next. Is it possible to generate > a CMakeFile, or how do I build everything? Piece of cake... I will create a separate CMakeVMMaker config for it.. so you will do something like: NBCogUnixConfig generateWithSources and then in command line do as usual: cmake . make :) > Thanks! > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > -- Best regards, Igor Stasenko AKA sig.

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Javier PimÃ¡s

I'm also seeing that NBCoInterpreter and NBCoObjectMemory only have small modifications compared to the non NB ones. Maybe it is possible to merge them directly into cog with an enable/disable flag, so that building NB is the same as building Cog with NB enabled. On Wed, Mar 16, 2011 at 11:10 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > Hi! I'm following the steps on the wiki to generate the NativeBoost plugin. > First of all I'd like to know if these steps are up to date (there has been > some activity since december when they were written). Then, I successfully > generated sources but don't know what to do next. Is it possible to generate > a CMakeFile, or how do I build everything? > > Thanks! > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 17, 2011

[Pharo-project] Building NativeBoost plugin (on linux)

by Javier PimÃ¡s

Hi! I'm following the steps on the wiki to generate the NativeBoost plugin. First of all I'd like to know if these steps are up to date (there has been some activity since december when they were written). Then, I successfully generated sources but don't know what to do next. Is it possible to generate a CMakeFile, or how do I build everything? Thanks! -- Javier PimÃ¡s Ciudad de Buenos Aires

March 17, 2011

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

by Eliot Miranda

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. > >

March 16, 2011

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

by Ken Treis

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. Or maybe there's a cleaner solution that's beyond my hazy view at the moment. -- Ken Treis Miriam Technologies, Inc.

March 16, 2011

Re: [Pharo-project] Breakpoints in Pharo

by Marcus Denker

On Mar 16, 2011, at 8:58 PM, Sven Van Caekenberghe wrote: > > On 16 Mar 2011, at 19:48, Marcus Denker wrote: > >> >> On Mar 16, 2011, at 7:41 PM, Noury Bouraqadi wrote: >> >>> A break point should not turn the MC package into dirty as opposite to inserting a self halt or self haltIf:[...]. >>> >> and >> -> one could remove all breakpoints with a menu entry >> -> disable but not remove >> -> watchpoints (viewers for values and expressions), even conditonal >> -> nice integration in the IDE... >> >> Marcus > > I have elementary breakpoint support in my Pharo images (Toggle Breakpoint in the Selector menu) and I use it all the time and I am quite happy with it (together with 'Debug it'). Indeed more options would be nice. But at least I don't have to do a self halt any more in most cases. > > I don't know how it works, I guess it comes with OB ? I think it was a [ENH] sent to the squeak mailinglist a looong time ago... see this mail from 2003: At 8:43 PM +0100 3/3/03, Torsten.Bergmann at phaidros.com wrote: >Hi all, > >this is an older but usefull little change set adding breakpoint >support to squeak. File it in and use the context menu in the >method pane of a browser to set/reset a breakpoint >for the method. It's very usefull since you dont have >to write a "self halt" if you want to debug a single >method. > >It was coded by Ernest Micklei from Philemonworks (thanks a >lot Ernest !!!) in an older squeak version. A short test >in 3.4 final showed it is still usefull. Note that it >doesnt work if you have RB installed. If others find it usefull >too we can register it on SqueakMap or add it to the base image. > It lived on SqueakMap for a while http://map.squeak.org/package/07469ced-289a-4b6f-bd17-27ec567e681a I guess we merged it in Squeak 3.6 or 3.7 in the image. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 16, 2011

[Pharo-project] [COTDC] - 33 StrikeFontSet

by laurent laffont

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 16, 2011

Re: [Pharo-project] [COTDC] 32 - MCScanner

by laurent laffont

On Wed, Mar 16, 2011 at 8:08 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > To read the metadata (package name, version info, ancestry, > dependencies) from .mcz files. > Thanks Lukas. I put: I scan / tokenize metadata (package name, version info, ancestry, dependencies, ...) found in .mcz files. For example, try: MCScanner scan: '(name ''MyPackage-ll.6'' message ''Fix bug xxx'' id ''b21dbd73-f1c3-2746-a3cc-92f1d4edea28'')' readStream Laurent. > > Lukas > > On 16 March 2011 20:05, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > Someone ? > > I had a quick look. I've seen that > > self assert: (MCScanner scan: '(a #b c)' readStream) = #(a #b c) > > but I still don't know why we need this > > Laurent. > > On Tue, Mar 15, 2011 at 6:28 PM, laurent laffont < > laurent.laffont(a)gmail.com> > > wrote: > >> > >> Today: MCScanner > >> > >> 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 > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > >

March 16, 2011