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

[Pharo-project] ServerDirectory

by Camillo Bruni

how much do we still need ServerDirectory in 2.0? Isn't that almost fully included by Zn? ServerDirectory features a lot of references to FileDirectory hence I would like to nuke it :D

May 7, 2012

Re: [Pharo-project] users of thisContext

by Guillermo Polito

In the context menu of the workspace you have the option extended search... -> method source with it It's kinda hidden, but very helpful :). On Mon, May 7, 2012 at 11:25 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > my first guess... > Use the Finder and search the source code > > WorldMenu / Tools / Finder > > and change search mode to source code (note that it will take a while to > search the whole image) > > best > cami > > On 2012-05-07, at 10:27, Francisco Garau wrote: > > > Hi -- I am trying to find the methods who make reference to the > thisContext pseudo variable. > > > > Any ideas how to get that list? > > > > - Francisco > > >

May 7, 2012

Re: [Pharo-project] users of thisContext

by Camillo Bruni

my first guess... Use the Finder and search the source code WorldMenu / Tools / Finder and change search mode to source code (note that it will take a while to search the whole image) best cami On 2012-05-07, at 10:27, Francisco Garau wrote: > Hi -- I am trying to find the methods who make reference to the thisContext pseudo variable. > > Any ideas how to get that list? > > - Francisco

May 7, 2012

[Pharo-project] users of thisContext

by Francisco Garau

Hi -- I am trying to find the methods who make reference to the *thisContext * pseudo variable. Any ideas how to get that list? - Francisco

May 7, 2012

[Pharo-project] [update 2.0] #20055

by Marcus Denker

20055 ----- Issue 5817: privShrinkingProcess with new KMPragmaKeymapBuilder http://code.google.com/p/pharo/issues/detail?id=5817 Issue 5815: Break dependency between traits and ring http://code.google.com/p/pharo/issues/detail?id=5815 -- Marcus Denker -- http://marcusdenker.de

May 7, 2012

Re: [Pharo-project] NativeBoost help

by Igor Stasenko

On 7 May 2012 08:41, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Thank you Igor for the new version of NB. > I tested it and it works when returning structs. > !! perfect !! :) > #Luc > > > > 2012/5/4 Igor Stasenko <siguctua(a)gmail.com> >> >> On 4 May 2012 20:27, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >> wrote: >> > I found this link quite detailed on the subject, but restricted to C++ >> > (not entirely sure C compiler produces exactly the same...) >> > >> > http://www.shell-storm.org/papers/files/657.pdf >> > >> thanks for the link, nicolas.. the information about these conventions >> are really sparse. >> >> > See table 7 for the case of returning objects... >> > >> > See also stack cleanup by, 32 bit gcc use hybrid method for structure >> > passed by values thru a pointer... >> > >> > Nicolas >> > >> > 2012/5/4 Igor Stasenko <siguctua(a)gmail.com>: >> >> On 4 May 2012 19:18, Nicolas Cellier >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Yes, on max too >> >>> >> >>> https://developer.apple.com/library/mac/#documentation/developertools/Conce… >> >>> >> >>> Structures. The called function returns structures according to their >> >>> aligned size. >> >>> >> >>> Â Â Structures 1 or 2 bytes in size are placed in EAX. >> >>> >> >>> Â Â Structures 4 or 8 bytes in size are placed in: EAX and EDX. >> >>> >> >> >> >> okay.. i fixed it in Â NativeBoost-Core-IgorStasenko.58 >> >> >> >>> Â Â Structures of other sizes are placed at the address supplied by >> >>> the caller. For example, the C++ language occasionally forces the >> >>> compiler to return a value in memory when it would normally be >> >>> returned in registers. See âPassing Argumentsâ for more information. >> >>> >> >>> I wonder if a structure of size 3 bytes can exist or is automatically >> >>> extended on 4 bytes... >> >>> >> >> yes.. struct alignment is what i fear of.. >> >> IMO it is actually silly to not return struct in registers if it less >> >> than 8 bytes >> >> but not power of 2.. >> >> >> >> sounds like an artefact of establishing the standards :) >> >> >> >>> $ cat > test_call.c <<END >> >>> >> >>> #include <stdio.h> >> >>> typedef struct { char a,b,c; } abc; >> >>> int main() { >> >>> Â Â abc x; >> >>> Â Â printf("sizeof(abc)=%d\n",sizeof x); >> >>> Â Â return 0; >> >>> } >> >>> END >> >>> >> >>> $ gcc test_call.c >> >>> $ ./a.exe >> >>> sizeof(abc)=3 >> >>> >> >>> And what would be the calling conventions of cygwin gcc ? >> >>> >> >>> $ cat > test_call.c <<END >> >>> >> >>> #include <stdio.h> >> >>> typedef struct { char a,b,c; } abc; >> >>> abc sub() { >> >>> Â abc result; >> >>> Â result.a='a'; >> >>> Â result.b='b'; >> >>> Â result.c='c'; >> >>> Â return result; >> >>> } >> >>> int main() { >> >>> Â Â abc x=sub(); >> >>> Â Â printf("sizeof(abc)=%d abc.a=$c\n",sizeof x,x.a); >> >>> Â Â return 0; >> >>> } >> >>> END >> >>> >> >>> $ gcc test_call.c >> >>> $ ./a.exe >> >>> sizeof(abc)=3 abc.a=a >> >>> >> >>> $ gcc -S test_call.c >> >>> $ cat test_call.S >> >>> >> >>> Â Â Â Â .file Â "test_call.c" >> >>> Â Â Â Â .text >> >>> .globl _sub >> >>> Â Â Â Â .def Â Â _sub; Â .scl Â Â 2; Â Â Â .type Â 32; Â Â .endef >> >>> _sub: >> >>> Â Â Â Â pushl Â %ebp >> >>> Â Â Â Â movl Â Â %esp, %ebp >> >>> Â Â Â Â subl Â Â $16, %esp >> >>> Â Â Â Â movl Â Â 8(%ebp), %eax >> >>> Â Â Â Â movb Â Â $97, -3(%ebp) >> >>> Â Â Â Â movb Â Â $98, -2(%ebp) >> >>> Â Â Â Â movb Â Â $99, -1(%ebp) >> >>> Â Â Â Â movzwl Â -3(%ebp), %edx >> >>> Â Â Â Â movw Â Â %dx, (%eax) >> >>> Â Â Â Â movzbl Â -1(%ebp), %edx >> >>> Â Â Â Â movb Â Â %dl, 2(%eax) >> >>> Â Â Â Â leave >> >>> Â Â Â Â ret Â Â $4 >> >>> Â Â Â Â .def Â Â ___main; Â Â Â Â .scl Â Â 2; Â Â Â .type Â 32; Â Â .endef >> >>> Â Â Â Â .section .rdata,"dr" >> >>> LC0: >> >>> Â Â Â Â .ascii "sizeof(abc)=%d\12\0" >> >>> Â Â Â Â .text >> >>> .globl _main >> >>> Â Â Â Â .def Â Â _main; Â .scl Â Â 2; Â Â Â .type Â 32; Â Â .endef >> >>> _main: >> >>> Â Â Â Â leal Â Â 4(%esp), %ecx >> >>> Â Â Â Â andl Â Â $-16, %esp >> >>> Â Â Â Â pushl Â -4(%ecx) >> >>> Â Â Â Â pushl Â %ebp >> >>> Â Â Â Â movl Â Â %esp, %ebp >> >>> Â Â Â Â pushl Â %ecx >> >>> Â Â Â Â subl Â Â $36, %esp >> >>> Â Â Â Â call Â Â ___main >> >>> Â Â Â Â leal Â Â -11(%ebp), %eax >> >>> Â Â Â Â movl Â Â %eax, (%esp) >> >>> Â Â Â Â call Â Â _sub >> >>> Â Â Â Â subl Â Â $4, %esp >> >>> Â Â Â Â movl Â Â $3, 4(%esp) >> >>> Â Â Â Â movl Â Â $LC0, (%esp) >> >>> Â Â Â Â call Â Â _printf >> >>> Â Â Â Â movl Â Â $0, %eax >> >>> Â Â Â Â movl Â Â -4(%ebp), %ecx >> >>> Â Â Â Â leave >> >>> Â Â Â Â leal Â Â -4(%ecx), %esp >> >>> Â Â Â Â ret >> >>> Â Â Â Â .def Â Â _printf; Â Â Â Â .scl Â Â 2; Â Â Â .type Â 32; Â Â .endef >> >>> >> >>> But of course, you already were faster than me... >> >>> >> >>> Nicolas >> >>> >> >>> 2012/5/4 Igor Stasenko <siguctua(a)gmail.com>: >> >>>> On 4 May 2012 18:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>>>> >> >>>>> >> >>>>> On Fri, May 4, 2012 at 6:13 AM, Igor Stasenko <siguctua(a)gmail.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> 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. >> >>>>> >> >>>>> >> >>>>> IIRC x86 ABIs (all the ones I encountered at least, windows, mac, >> >>>>> linux, >> >>>>> solaris) Â support structure return (by-value structure return) by >> >>>>> passing a >> >>>>> hidden first argument which is a pointer to a structure into which >> >>>>> to copy >> >>>>> the result. Â The callee copies the result back through this pointer. >> >>>>> >> >>>>> Where these ABIs differ is in returning small structures. Â On win32 >> >>>>> structures a power-of-two in size of 8 bytes or less are returned in >> >>>>> EAX:EDX. Â IIRC on linux and mac all structures are returned through >> >>>>> the >> >>>>> hidden first argument pointer. Â See >> >>>>> ThreadedIA32FFIPlugin>>returnStructInRegisters: >> >>>>> >> >>>> on macs (at least what gcc generates) it also returns structs <=8 >> >>>> bytes size in registers: >> >>>> >> >>>> >> >>>> so , currently i implemented it like that: >> >>>> if sizeof(struct) <= 8 then i assume function returns it in EAX: EDX >> >>>> otherwise via hidden pointer. >> >>>> >> >>>>>> >> >>>>>> >> >>>>>> 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. >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> best, >> >>>>> Eliot >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Best regards, >> >>>> Igor Stasenko. >> >>> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

May 7, 2012

Re: [Pharo-project] NativeBoost help

by Luc Fabresse

Thank you Igor for the new version of NB. I tested it and it works when returning structs. #Luc 2012/5/4 Igor Stasenko <siguctua(a)gmail.com> > On 4 May 2012 20:27, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > wrote: > > I found this link quite detailed on the subject, but restricted to C++ > > (not entirely sure C compiler produces exactly the same...) > > > > http://www.shell-storm.org/papers/files/657.pdf > > > thanks for the link, nicolas.. the information about these conventions > are really sparse. > > > See table 7 for the case of returning objects... > > > > See also stack cleanup by, 32 bit gcc use hybrid method for structure > > passed by values thru a pointer... > > > > Nicolas > > > > 2012/5/4 Igor Stasenko <siguctua(a)gmail.com>: > >> On 4 May 2012 19:18, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >>> Yes, on max too > >>> > https://developer.apple.com/library/mac/#documentation/developertools/Conce… > >>> > >>> Structures. The called function returns structures according to their > >>> aligned size. > >>> > >>> Structures 1 or 2 bytes in size are placed in EAX. > >>> > >>> Structures 4 or 8 bytes in size are placed in: EAX and EDX. > >>> > >> > >> okay.. i fixed it in NativeBoost-Core-IgorStasenko.58 > >> > >>> Structures of other sizes are placed at the address supplied by > >>> the caller. For example, the C++ language occasionally forces the > >>> compiler to return a value in memory when it would normally be > >>> returned in registers. See âPassing Argumentsâ for more information. > >>> > >>> I wonder if a structure of size 3 bytes can exist or is automatically > >>> extended on 4 bytes... > >>> > >> yes.. struct alignment is what i fear of.. > >> IMO it is actually silly to not return struct in registers if it less > >> than 8 bytes > >> but not power of 2.. > >> > >> sounds like an artefact of establishing the standards :) > >> > >>> $ cat > test_call.c <<END > >>> > >>> #include <stdio.h> > >>> typedef struct { char a,b,c; } abc; > >>> int main() { > >>> abc x; > >>> printf("sizeof(abc)=%d\n",sizeof x); > >>> return 0; > >>> } > >>> END > >>> > >>> $ gcc test_call.c > >>> $ ./a.exe > >>> sizeof(abc)=3 > >>> > >>> And what would be the calling conventions of cygwin gcc ? > >>> > >>> $ cat > test_call.c <<END > >>> > >>> #include <stdio.h> > >>> typedef struct { char a,b,c; } abc; > >>> abc sub() { > >>> abc result; > >>> result.a='a'; > >>> result.b='b'; > >>> result.c='c'; > >>> return result; > >>> } > >>> int main() { > >>> abc x=sub(); > >>> printf("sizeof(abc)=%d abc.a=$c\n",sizeof x,x.a); > >>> return 0; > >>> } > >>> END > >>> > >>> $ gcc test_call.c > >>> $ ./a.exe > >>> sizeof(abc)=3 abc.a=a > >>> > >>> $ gcc -S test_call.c > >>> $ cat test_call.S > >>> > >>> .file "test_call.c" > >>> .text > >>> .globl _sub > >>> .def _sub; .scl 2; .type 32; .endef > >>> _sub: > >>> pushl %ebp > >>> movl %esp, %ebp > >>> subl $16, %esp > >>> movl 8(%ebp), %eax > >>> movb $97, -3(%ebp) > >>> movb $98, -2(%ebp) > >>> movb $99, -1(%ebp) > >>> movzwl -3(%ebp), %edx > >>> movw %dx, (%eax) > >>> movzbl -1(%ebp), %edx > >>> movb %dl, 2(%eax) > >>> leave > >>> ret $4 > >>> .def ___main; .scl 2; .type 32; .endef > >>> .section .rdata,"dr" > >>> LC0: > >>> .ascii "sizeof(abc)=%d\12\0" > >>> .text > >>> .globl _main > >>> .def _main; .scl 2; .type 32; .endef > >>> _main: > >>> leal 4(%esp), %ecx > >>> andl $-16, %esp > >>> pushl -4(%ecx) > >>> pushl %ebp > >>> movl %esp, %ebp > >>> pushl %ecx > >>> subl $36, %esp > >>> call ___main > >>> leal -11(%ebp), %eax > >>> movl %eax, (%esp) > >>> call _sub > >>> subl $4, %esp > >>> movl $3, 4(%esp) > >>> movl $LC0, (%esp) > >>> call _printf > >>> movl $0, %eax > >>> movl -4(%ebp), %ecx > >>> leave > >>> leal -4(%ecx), %esp > >>> ret > >>> .def _printf; .scl 2; .type 32; .endef > >>> > >>> But of course, you already were faster than me... > >>> > >>> Nicolas > >>> > >>> 2012/5/4 Igor Stasenko <siguctua(a)gmail.com>: > >>>> On 4 May 2012 18:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >>>>> > >>>>> > >>>>> On Fri, May 4, 2012 at 6:13 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >>>>>> > >>>>>> 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. > >>>>> > >>>>> > >>>>> IIRC x86 ABIs (all the ones I encountered at least, windows, mac, > linux, > >>>>> solaris) support structure return (by-value structure return) by > passing a > >>>>> hidden first argument which is a pointer to a structure into which > to copy > >>>>> the result. The callee copies the result back through this pointer. > >>>>> > >>>>> Where these ABIs differ is in returning small structures. On win32 > >>>>> structures a power-of-two in size of 8 bytes or less are returned in > >>>>> EAX:EDX. IIRC on linux and mac all structures are returned through > the > >>>>> hidden first argument pointer. See > >>>>> ThreadedIA32FFIPlugin>>returnStructInRegisters: > >>>>> > >>>> on macs (at least what gcc generates) it also returns structs <=8 > >>>> bytes size in registers: > >>>> > >>>> > >>>> so , currently i implemented it like that: > >>>> if sizeof(struct) <= 8 then i assume function returns it in EAX: EDX > >>>> otherwise via hidden pointer. > >>>> > >>>>>> > >>>>>> > >>>>>> 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. > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> best, > >>>>> Eliot > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Igor Stasenko. > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

May 7, 2012

Re: [Pharo-project] PBE1 update to Pharo 1.4 Re: Some Newbie problems

by Marcus Denker

On May 7, 2012, at 1:26 AM, Peredur wrote: > El 06/05/12 23:27, Ben Coman escribiÃ³: >> That would be welcome. I'll move further discussion to sbe-discussion(a)iam.unibe.ch list. Announce yourself there also. >> >> cheers -ben >> > > I tried, but the list rejected me: > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > > sbe-discussion-owner(a)iam.unibe.ch > you need to first subscribe to the list. It reject all mails from people not subscribed. https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion -- Marcus Denker -- http://marcusdenker.de

May 7, 2012

Re: [Pharo-project] Command Line Handling

by Camillo Bruni

On 2012-05-07, at 02:20, Sean P. DeNigris wrote: > Thanks for helping me think this through, Camillo... > > Camillo Bruni-3 wrote >> >> you >> conceptionally execute subcommands >> > Okay, I think I understand your intention better now. I was thinking of > options, like "-la" for "ls", but you're talking about different modes, like > you would never pass both a script and string, mixing basic code loader and > eval... exactly :) the goal was to go really in the direction of having separate subcommands (and right now with a minimal infrastructure). => maybe we should extend the class comments then to make this point clearer... > Camillo Bruni-3 wrote >> >>> * The priority concept seems premature. It adds complexity and confusion >>> (the handler for a specific flag is not obvious because it emerges from >>> an >>> interaction of all the handlers). >> ... >> and I disagree with you that it adds complexity. Just look at how much >> simpler... >> > I didn't mean that it increased complexity from the mess that you cleaned up > :) Just that it may add unnecessary complexity to your simple system. I > guess some real world use will reveal whether that's true... true :) so far I saw that it massively simplified the test cases, plus coral. in coral there used to be an issue withe the default handler interfering, which was not the case in the new implementation > Re registry vs. select... if I'm adding a handler that will mask another > handler, it seems like that'd be important to know, not to have it happen > silently. I'm wondering whether the criteria-based approach adds unneeded > flexibility at the cost of making the system less understandable. With a > registry, you can have ifPresent: etc... true, the override case is not properly handled I guess. however it is very easy to see what is registered in which way since everything is placed on the classes themselves. this avoids IMO to go and really inspect what has been put in the registry before (with all its condition blocks). my idea was: - you can always use the full class name as unique subcommand identifier - if you get a masking problem you can always add another handler which resolves this. - an easy way from the command line to see what is going on - list all active handlers - list all handlers for a certain input string - by using a real option parser and a decent default implementation you can resolve masking issues early on as you might figured out, my general assumption is that there are hardly any masking issues. this of course is very optimistic guess :P but since there are basically no cli applications out there in smalltalk it holds â so far :). best cami

May 7, 2012

Re: [Pharo-project] Question regarding: #addYellowButtonMenuItemsTo:event:

by Sean P. DeNigris

See if http://forum.world.st/Adding-a-context-menu-to-a-Morph-td3991117.html sheds any light... Sean -- View this message in context: http://forum.world.st/Question-regarding-addYellowButtonMenuItemsTo-event-t… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 7, 2012