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

Re: [Pharo-project] #getSource is broken for temp names

by Marcus Denker

On May 4, 2012, at 11:19 AM, Mariano Martinez Peck wrote: > > I don't know. In Fuel we have tests for each kind of trailer, included those which store temp names. > If this kind of trailer is not supported any more, I can remove the tests. > Yes! > If you want to remove temp names, then I think we still need to remove: > > #hasTempNames > #encodeTempsNamesQCompress > #encodeTempsNamesZip > #encodeUsingQCompress > #encodeUsingZip > #tempNames > #tempNames: > #decodeTempsNamesQCompress > #decodeTempsNamesZip > > remove the trailer type from #trailerKinds > Yes. One step at a time. Marcus -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

Re: [Pharo-project] #getSource is broken for temp names

by Mariano Martinez Peck

On Fri, May 4, 2012 at 11:09 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 4, 2012, at 11:03 AM, Mariano Martinez Peck wrote: > > > | trailer materializedCompiledMethod method | > > > > trailer := CompiledMethodTrailer new tempNames: 'param1 param2 temp1 > temp2'. > > self assert: trailer kind = #TempsNamesQCompress. > > self assert: trailer kindAsByte = 8. > > method := (self class >> #fooWith:and:) copyWithTrailerBytes: > trailer. > > self assert: (method getSource includesSubString: 'param1'). > > > > > > this last assert fails. > > > > Problem is that #getSource is broken and somehow it looks like if the > part of tempNames was removed. I propose to put back its original verison > or just add at the beginning: > > > > trailer tempNames ifNotNil: [:namesString | > > "Magic sources -- decompile with temp names" > > ^ ((class decompilerClass new withTempNames: namesString) > > decompile: selector in: class method: self) > > decompileString]. > > > > > > agree? if true I open an issue. > > No, the idea was to remove temp name embedding because it is not needed. > > Why do you need it? > > I don't know. In Fuel we have tests for each kind of trailer, included those which store temp names. If this kind of trailer is not supported any more, I can remove the tests. If you want to remove temp names, then I think we still need to remove: #hasTempNames #encodeTempsNamesQCompress #encodeTempsNamesZip #encodeUsingQCompress #encodeUsingZip #tempNames #tempNames: #decodeTempsNamesQCompress #decodeTempsNamesZip remove the trailer type from #trailerKinds and maybe more stuff. We should analyze this with care. Cheers > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Mariano http://marianopeck.wordpress.com

May 4, 2012

Re: [Pharo-project] [update 2.0] #20043

by Marcus Denker

On May 4, 2012, at 11:04 AM, Mariano Martinez Peck wrote: > > > On Thu, May 3, 2012 at 10:44 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20043 > ----- > > Issue 5744: Clean up Temp Embedding 2): DoIts > http://code.google.com/p/pharo/issues/detail?id=5744 > > > - Doits are now compiled with source embedded > - embedding sources for doits pretty prints from AST as doits are compiled specially (with a return added) > > CompiledMethod: > > - remove blockExtendsToTempsMap: Not needed anymore, all calls go the MethodNode > - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource > - remove #holdsTempNames. Temp name embedding not needed > > > I didn't understand. I have a test in fuel where I serialize/materialize a compiled method with an empty trailer. so after the materialization one of the things I test are: > > self assert: method sourcePointer = 0. > self deny: method holdsTempNames. > > of course I can still do: > > self deny: method trailer hasTempNames Just remove the test. The idea is to remove the implementation from the Trailer, too (later). Marcus -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

Re: [Pharo-project] #getSource is broken for temp names

by Marcus Denker

On May 4, 2012, at 11:03 AM, Mariano Martinez Peck wrote: > | trailer materializedCompiledMethod method | > > trailer := CompiledMethodTrailer new tempNames: 'param1 param2 temp1 temp2'. > self assert: trailer kind = #TempsNamesQCompress. > self assert: trailer kindAsByte = 8. > method := (self class >> #fooWith:and:) copyWithTrailerBytes: trailer. > self assert: (method getSource includesSubString: 'param1'). > > > this last assert fails. > > Problem is that #getSource is broken and somehow it looks like if the part of tempNames was removed. I propose to put back its original verison or just add at the beginning: > > trailer tempNames ifNotNil: [:namesString | > "Magic sources -- decompile with temp names" > ^ ((class decompilerClass new withTempNames: namesString) > decompile: selector in: class method: self) > decompileString]. > > > agree? if true I open an issue. No, the idea was to remove temp name embedding because it is not needed. Why do you need it? Marcus -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

Re: [Pharo-project] [update 2.0] #20043

by Mariano Martinez Peck

On Thu, May 3, 2012 at 10:44 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 20043 > ----- > > Issue 5744: Clean up Temp Embedding 2): DoIts > http://code.google.com/p/pharo/issues/detail?id=5744 > > > - Doits are now compiled with source embedded > - embedding sources for doits pretty prints from AST as doits are compiled > specially (with a return added) > > CompiledMethod: > > - remove blockExtendsToTempsMap: Not needed anymore, all calls go the > MethodNode > - remove #copyWitTempsFromMethodNode: All senders use #copyWithSource > - remove #holdsTempNames. Temp name embedding not needed > I didn't understand. I have a test in fuel where I serialize/materialize a compiled method with an empty trailer. so after the materialization one of the things I test are: self assert: method sourcePointer = 0. self deny: method holdsTempNames. of course I can still do: self deny: method trailer hasTempNames but just wondering... > - add isDoit > - schematicTempNamesString always returns the schematic string > representation of all temps > - tempNames forwards to methodNode > - remove tempNamesString. Concatenate yourself if you need that. > > Debugger>>selectedMessage asks the selectedContext directly for the > source. No need for the methodMap. > > DebuggerMethodMap > > - no special handling of methods that encode temps. Just as for methodNode > always. > > MethodNode > > - generateWithSource. embedd pretty printed code in case of doit > - remove generateWithTempNames > > In general: rewrite code to use #generateWithSource > > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Mariano http://marianopeck.wordpress.com

May 4, 2012

[Pharo-project] #getSource is broken for temp names

by Mariano Martinez Peck

| trailer materializedCompiledMethod method | trailer := CompiledMethodTrailer new tempNames: 'param1 param2 temp1 temp2'. self assert: trailer kind = #TempsNamesQCompress. self assert: trailer kindAsByte = 8. method := (self class >> #fooWith:and:) copyWithTrailerBytes: trailer. self assert: (method getSource includesSubString: 'param1'). this last assert fails. Problem is that #getSource is broken and somehow it looks like if the part of tempNames was removed. I propose to put back its original verison or just add at the beginning: trailer tempNames ifNotNil: [:namesString | "Magic sources -- decompile with temp names" ^ ((class decompilerClass new withTempNames: namesString) decompile: selector in: class method: self) decompileString]. agree? if true I open an issue. -- Mariano http://marianopeck.wordpress.com

May 4, 2012

[Pharo-project] [update 2.0] #20045

by Marcus Denker

20045 ----- Issue 5801: remove #testLiteralsForGlobalBehaviorsAreCorrect http://code.google.com/p/pharo/issues/detail?id=5801 Issue 5758: Improve CommandLine handling http://code.google.com/p/pharo/issues/detail?id=5758 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Luc Fabresse

Hi Igor, > there is a workaround. > all structs in C is returned via pointer. > so, actually a true return type of a function is CvSize* > I agree that usually structs are returned through pointers. But here it is not the case. I want to wrap this function: CvSize cvGetSize( const CvArr* arr ); and the CvSize struct is returned by value. Am I wrong? > > so, what you do is to change the return value to simple void* > and then copy the contents of struct into instance of corresponding > NBExternalStructure subclass > using #fromPointer: method.. to conveniently access its fields values. > yes I saw that in NB tests. > > > but this is in general, in your case this function is actually inlined > by compiler (as CV_INLINE suggests), so there could be even no > exported symbol for it in dynamic library. > and the function is actually so simple, that you don't need to wrap it at > all. > you can just create a subclass of NBExternalStructure , named CvSize, > implement fieldDesc method as: > > fieldsDesc > ^ #( > int width; > int height > ) > and if you invoke: > > CvSize new width: 1 height:2 > > it will be equivalent as if you will call cvSize(1,2) function. > yes it is exactly what I did. So my problem is: NBCvSize implemented as a subclass of NBExternalStruct with fieldDesc correctly set up. Then wrap the function cvGetSize: getSize self nbCall: #(NBCvSize cvGetSize(IplImage self)) module: LIB_CV. But I get a debugger because: NBExternalStruct>>coerceReturn: gen " ... should we support handling return of external structures? " self error: 'returning pointer to structure?' And I have no idea how to implement this (black magic EAX pop push ;-)) to coerce result of struct. Luc

May 4, 2012

[Pharo-project] [update 2.0] #20044

by Marcus Denker

20044 ----- Issue 5785: Nautilus: - Fix BreadCrumb plugin - Add Guillermos plugin - Fix Package Removal http://code.google.com/p/pharo/issues/detail?id=5785 Issue 5784: Clean FSReference from comments http://code.google.com/p/pharo/issues/detail?id=5784 Issue 5792: Fix tempNamed and tempNamedPut http://code.google.com/p/pharo/issues/detail?id=5792 Issue 5788: methodsWithUnboundGlobals should search by identity http://code.google.com/p/pharo/issues/detail?id=5788 Issue 5794: Move DebuggerMethodMap to Kernel http://code.google.com/p/pharo/issues/detail?id=5794 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

Re: [Pharo-project] Questionn

by Marcus Denker

On May 4, 2012, at 9:44 AM, Francisco Garau wrote: > On 2 May 2012 18:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > First class instance variables will bring a lot to the system: > foundation for a lot of innovation > - relationships support > - meta description. > - bitfields description > ... > > > I like the idea -- you could even have a BroadcasterSlot that whenever it's changed send notifications (although this might not be necessary with the Announcement framework, I haven't looked into that). > > But there are a couple of points that I don't understand: > > 1) Slots and Layouts are descriptions of Objects and Classes and, as such, they are reflection facilities. Will this go into the "minimal" kernel image that you are trying to bootstrap? yes, because the ClassBuilder will use the layout descriptions. And because the system itself might use them. > (I think they should go to a "reflection" module on top of the kernel) > In the futuer, yes. But that is hard. In theory, you can think about a reflection-less system where reflection can be added later by loading something. But this is a hard problem in itself. Nik did some research experiments in that direction: http://rmod.lille.inria.fr/web/pier/publications/bib?&query=Papo11a In the end we want to go there, but for the bootstrap this is not the first goal. (ie, we will do a boostrap that has reflection first). > 2) Let's say you have a subclass of point with typed slots called FloatPoint with a couple of getter/setters. Would the generated bytecodes of the setter by the same as for the same method in the superclass? > yes. (if I understand you question correctly) Marcus -- Marcus Denker -- http://marcusdenker.de

May 4, 2012