- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Questionn

by Francisco Garau

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? (I think they should go to a "reflection" module on top of the kernel) 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? - Francisco

May 4, 2012

Re: [Pharo-project] Which home for a class?[SEC=UNCLASSIFIED]

by Stephen Taylor

On Fri, 2012-05-04 at 14:18 +1000, James Ladd wrote: > Please adopt a lonely Class that needs a home, You've already sent that once.

May 4, 2012

[Pharo-project] Which home for a class?

by James Ladd

Please adopt a lonely Class that needs a home, and help Redline Smalltalk get to V1.0 http://www.redline.st/blog/2011/12/22/adopt-a-class.html

May 4, 2012

Re: [Pharo-project] OSProcess - is process done?

by Sean P. DeNigris

Sean P. DeNigris wrote > > As for #upToEnd Dave, thanks for being so patient and generous with the explanations! I'm still a little confused about blocking and output. I'm exploring some of your suggestions from the last message, but one thing is bothering me... PipeableOSProcess>>#upToEnd eventually calls AttachableFileStream>>#upToEnd, which tries to perform a buffered read by "self nextInto: 1000" (which eventually calls primitiveFileRead which calls sqFileReadIntoAt which calls fread with count arg of 1000). I'm pretty sure this sets up a race condition. In http://forum.world.st/Standard-input-in-Pharo-td2173080.html#a4607687 , I found out that fread blocks forever under the following conditions: 1. there is less data available than was asked for 2. no EOF is encountered I think this is why it seems that my (and others') reports of hanging OSP images are inconsistent. If the process has generated at least 1000 characters output before the call to #upToEnd, or if (e.g. "p pipeFromOutput next: 10") less output is asked for than is available, there is no problem. But as soon as one more character is asked for than is available, the vm hangs in fread forever. I don't know what the solution is, but the current behavior doesn't seem workable. I'd be happy to work with you as much as I can to fix it... Thanks again. Sean -- View this message in context: http://forum.world.st/OSProcess-is-process-done-tp4569088p4607761.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012