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

Re: [Pharo-project] NativeBoost help

by Luc Fabresse

2012/5/4 Igor Stasenko <siguctua(a)gmail.com> > On 4 May 2012 10:38, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > 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? > > > > i don't know.. this is a bit shady part of C ABI. > Some compilers use return-by-value, some return by pointer > by forcing a caller to pass a hidden implicit argument as a pointer to > the struct, which then filled with values by > the function you call. > > It is easy to add support for that, but to make it work correctly can > be tricky. > See this, for example: > > http://stackoverflow.com/questions/161788/are-there-any-downsides-to-passin… > > > >> > >> > >> 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. > > > > > you don't. if function takes an implicit struct pointer, you can just > rewrite the function signature from > NBCvSize cvGetSize(IplImage self) > to: > > void cvGetSize(NBCvSize hidden, IplImage self) > > and so, you pass a fresh instance of NBCvSize as argument, which > function then fill. > I will investigate if this is the case. But, I "suppose" that for small structs, gcc does not bother with that. > But if C compiler using registers to return struct.. then you're screwed :) > Yes I was thinking of this case ;-) > > Anyways, Luc i will try to read docs about C ABI and see if we can > easily add support for that. > Thank you Igor! Luc

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Igor Stasenko

On 4 May 2012 10:38, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > 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? > i don't know.. this is a bit shady part of C ABI. Some compilers use return-by-value, some return by pointer by forcing a caller to pass a hidden implicit argument as a pointer to the struct, which then filled with values by the function you call. It is easy to add support for that, but to make it work correctly can be tricky. See this, for example: http://stackoverflow.com/questions/161788/are-there-any-downsides-to-passin… >> >> >> 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. > you don't. if function takes an implicit struct pointer, you can just rewrite the function signature from NBCvSize cvGetSize(IplImage self) to: void cvGetSize(NBCvSize hidden, IplImage self) and so, you pass a fresh instance of NBCvSize as argument, which function then fill. But if C compiler using registers to return struct.. then you're screwed :) Anyways, Luc i will try to read docs about C ABI and see if we can easily add support for that. -- Best regards, Igor Stasenko.

May 4, 2012

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

by Camillo Bruni

most of it is in the class comments of CommandLineArguments and CommandLineHandler. Example: ======= Default options --------------- cogVM CommandLine/CommandLine.image --help cogVM CommandLine/CommandLine.image --version cogVM CommandLine/CommandLine.image --copyright List all the Installed handlers/subcommands ------------------------------------------- cogVM CommandLine/CommandLine.image --list Evaluate a String ----------------- cogVM CommandLine/CommandLine.image eval '1+2' cogVM CommandLine/CommandLine.image -e '1+2' cogVM CommandLine/CommandLine.image --evaluate '1+2' all in all I cleaned up the old command-line handling stuff and replaced it with something that's less static and slightly more flexible. On 2012-05-04, at 13:27, Sean P. DeNigris wrote: > > Marcus Denker-4 wrote >> >> Issue 5758: Improve CommandLine handling >> http://code.google.com/p/pharo/issues/detail?id=5758 >> > > Cool! This deserves some documentation... > > -- > View this message in context: http://forum.world.st/update-2-0-20045-tp4608123p4608400.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 4, 2012

[Pharo-project] [update 2.0] #20048

by Marcus Denker

20048 ----- Issue 5793: More flexible special objects array http://code.google.com/p/pharo/issues/detail?id=5793 Issue 5802: Clean Embedded Temp Names: CompiledMethodTrailer http://code.google.com/p/pharo/issues/detail?id=5802 Issue 5791: Merge ExpandedSourceFileArray into SourceFileArray (part3: remove ExpandedSourceFileArray) http://code.google.com/p/pharo/issues/detail?id=5791 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

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

by Marcus Denker

On May 4, 2012, at 1:30 PM, Sean P. DeNigris wrote: > > Marcus Denker-4 wrote >> >> Issue 5795: Merge System-BreakPoints with Tools-Debugger >> http://code.google.com/p/pharo/issues/detail?id=5795 >> > > Does this, by chance, take care of the problem where you add a breakpoint in > the Senders browser, and then it is not recognized by the Debugger? > No, I just moved the class around... Marcus -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

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

by Sean P. DeNigris

Sean P. DeNigris wrote > > ... then it is not recognized by the Debugger? > I meant browser... probably OB... don't know about the debugger... -- View this message in context: http://forum.world.st/update-2-0-20046-tp4608340p4608412.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

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

by Sean P. DeNigris

Marcus Denker-4 wrote > > Issue 5795: Merge System-BreakPoints with Tools-Debugger > http://code.google.com/p/pharo/issues/detail?id=5795 > Does this, by chance, take care of the problem where you add a breakpoint in the Senders browser, and then it is not recognized by the Debugger? Sean -- View this message in context: http://forum.world.st/update-2-0-20046-tp4608340p4608404.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

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

by Sean P. DeNigris

Marcus Denker-4 wrote > > Issue 5758: Improve CommandLine handling > http://code.google.com/p/pharo/issues/detail?id=5758 > Cool! This deserves some documentation... -- View this message in context: http://forum.world.st/update-2-0-20045-tp4608123p4608400.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

[Pharo-project] [update 2.0] #20047

by Marcus Denker

20047 ----- Issue 5782: Close ALL windows, no matter if they have unchanged changes http://code.google.com/p/pharo/issues/detail?id=5782 Issue 5792: Fix tempNamed and tempNamedPut http://code.google.com/p/pharo/issues/detail?id=5792 Issue 5790: Merge ExpandedSourceFileArray into SourceFileArray (part2 install and fix tests) http://code.google.com/p/pharo/issues/detail?id=5790 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

[Pharo-project] [update 2.0] #20046

by Marcus Denker

20046 ----- Issue 5789: Merge ExpandedSourceFileArray into SourceFileArray (part1 copy methods) http://code.google.com/p/pharo/issues/detail?id=5789 Issue 5804: Failing Test:testCommandLineHandlerCondition http://code.google.com/p/pharo/issues/detail?id=5804 Issue 5795: Merge System-BreakPoints with Tools-Debugger http://code.google.com/p/pharo/issues/detail?id=5795 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012