- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] Command Line Handling

by Sean P. DeNigris

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... 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... 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... Sean -- View this message in context: http://forum.world.st/Command-Line-Handling-tp4612779p4613781.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 7, 2012

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

by Peredur

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. Cheers Peter -- *Peter Bradley* peredur.net <http://www.peredur.net>

May 6, 2012

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

by Ben Coman

Peredur wrote: > El 06/05/12 13:17, Mariano Martinez Peck escribiÃ³: >> >> >> On Sun, May 6, 2012 at 12:51 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> >> >> >> > >> > The new book focuses on different issues than the old book. It >> would be sad to let the old book languish entirely and end up with >> a poor first impression for newcomers, so I am willing to >> participate in updating it to Pharo 1.4. I am getting a lot from >> Pharo and this is something I can contribute. I think it fair the >> main developers continue with implementing and documenting the >> advanced features, while the community maintains the more >> established things. A quick scan pegs this effort at updating >> about 170 images, plus hopefully a minimal amount of text. How >> would I proceed with this? >> > >> >> >> >> That would be AWESOME. Really. > > I would be the last person who could really help, directly with this, > but I'd be happy (other pressures permitting) to do some proof-reading > for you and to act as a guinea pig for you - along the lines of, "If > it's clear to me it's probably going to be clear to other readers > since my prior knowledge is nil". > > :-) > > > Peter That would be welcome. I'll move further discussion to sbe-discussion(a)iam.unibe.ch list. Announce yourself there also. cheers -ben

May 6, 2012

Re: [Pharo-project] Command Line Handling

by Camillo Bruni

Hi sean, thanks for the response... though I'll be mostly standing against your observations here :). On 2012-05-06, at 14:41, Sean P. DeNigris wrote: > I've played a lot with the new command line argument handling. Here's a few > thoughts: > * I think we should not allow the use of raw handler names (e.g. 'eval') and > restrict ourselves to flags. For example, disallow 'eval' and stick to '-e' > or '--evaluate'. The raw name introduces ambiguity in parsing the command > line, especially since custom commands can be added at will that may > conflict and see next item... there is no ambiguity, since you can always push a command further up by changing it's priority. besides adding switching is not that nice since you conceptionally execute subcommands > * The current implementation chooses the single matching handler with the > highest priority, but usually command line tools may have multiple > non-conflicting flags I disagree with that. AFAIK there is no unix tool that does that. The only way that this happens is for subcommands that may inherit from their parents some options (see all git sub commands that still allow for --repository from the main command). If you want to support multiple ones you can still add a specific handler that will merge your N other handlers. > * 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). 1. the input is given to all handlers which decide whether they can do something with it or not. 2. the handler with the highest priority is chosen > Maybe a registry would be better? A > dictionary could just map flags to handlers e.g. -e -> EvalHandler, > --evaluate -> EvalHandler, etc. again, I want to have subcommands, and not some smalltalk specific handling... (like for instance the super weird -LONGOPTIONNAME from the vm...) and I disagree with you that it adds complexity. Just look at how much simpler the tests are now, the system doesn't work globally any more. or for instance for coral... I didn't have to manually unregister the default option anymore. In my optinion the system got much easier to use. Of course the goal would be to use some option parsing mechanisms from coral. but I think the base system should be rather flexible and very small and simple.

May 6, 2012