- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Standard input in Pharo?

by Sean P. DeNigris

Sean P. DeNigris wrote > > The attached changeset fixes stdin. > Fix works in 1.3, 1.4, and 2.0... -- View this message in context: http://forum.world.st/Standard-input-in-Pharo-tp2173080p4609820.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

[Pharo-project] [ANN] STON - Smalltalk Object Notation

by Sven Van Caekenberghe

Hi, STON - Smalltalk Object Notation is a lightweight text-based, human-readable data interchange format for class-based object-oriented languages like Smalltalk. It can be used to serialize domain level objects, either for persistency or network transport. As its name suggests, it is based on JSON (Javascript Object Notation). It adds symbols as a primitive value, class tags for object values and references. Please read the paper here: https://github.com/svenvc/ston/blob/master/ston-paper.md The project lives here: https://github.com/svenvc/ston The code can be found here as well: http://ss3.gemstone.com/ss/STON This implementation works on Pharo 1.3, 1.4 and 2.0 as well as on Squeak. Last week Dale Henrich helped me get started with filetree/git (https://github.com/dalehenrich/filetree) and I like it. Check it out! He also ported STON to Gemstone, and is working on Amber and Cuis ports (https://github.com/dalehenrich/ston) Enjoy, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 4, 2012

[Pharo-project] 51 registered participants to PharoConf :)

by StÃ©phane Ducasse

51 registered participants to PharoConf :) and from a lot of countries: belgium, ukraina, Switzerland, Romania, France, Netherlands, UKâ¦ It will be exciting. http://rmod.lille.inria.fr/web/pier/Events Don't forget to register if you want to participate. Stef

May 4, 2012

Re: [Pharo-project] Pharo Kernel 2.0

by StÃ©phane Ducasse

thanks pavel. I'm back to life after holidays without internet. I have to catch up with less exciting things than pharo but I'm trying to follow :) On May 4, 2012, at 7:04 PM, Pavel Krivanek wrote: > Hi, > > Markus added all packages to the Pharo 2.0 repository (THANKS!) so I was able to bring Pharo Kernel 2.0 image to life. Few notices: > > - I had to add FileSystem to the kernel. I added 'FileSystem-AnsiStreams' 'FileSystem-Core' 'FileSystem-Disk' and 'FileSystem-Memory' but maybe some are not necessary. > - CommandLine has poor packaging because it includes tests too. > - SimpleCodeLoader is now not needed and can be removed > - CommandLine package will need some some next changes like to be independent on Compiler (because of Fuel) > - KMPragmaKeymapBuilder needs better cleanup code. > - I added 'Ring-Core-Kernel' 'Ring-Core-Containers' and 'Fuel' 'FuelMetalevel' 'FuelPackageLoader' packages (Fuel from external repository) > > I will open the issues. > > Cheers, > -- Pavel

May 4, 2012

Re: [Pharo-project] Drawing speed for animations?

by Hilaire Fernandes

And what about using PasteUpMorph with an unique step in the message taking care of the update of the submorphs? Hilaire Le 04/05/2012 17:50, Martin Drautzburg a Ã©crit : > Hello all, > > I am doing some smooth scrolling expriments. I use a step method in which I > adjust the display. When I set stepTime to 0, the time between steps is still > between 10 and 40 msces. During a scroll which takes 10 steps I see apx 1000 > redraws of fairly simple Morphs. That is 100 redraws per step. When an average > step takes apx. 20 msec this is 0.2 msec per redaw. Does this look normal, or > should I hunt for flaws in my program? > > If this is the normal speed, then I cannot do animations in morphic, such that > I get a new frame every 14 msec (70 Hz), at least not the way I am trying to > do it. > > Another thing I cannot explain is the following: when I repeatedly call my > step method from another method (putting a Delay between the calls), the > display does not always update. I just see the end of the scroll, but not the > steps in between. Only when I add a World displayWorld I see the intermediate > scroll positions. However, when I call step from an explorer the Display > updates just fine, without an explicit displayWorld. Why is that so? > -- Dr. Geo -- http://www.drgeo.eu

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Igor Stasenko

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 4, 2012

Re: [Pharo-project] Pharo Kernel 2.0

by Edgar J. De Cleene

On 5/4/12 2:04 PM, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> wrote: > Hi, > > MarkusÂ added all packages to the Pharo 2.0 repository (THANKS!) so I was able > to bring Pharo Kernel 2.0 image to life. Few notices: > > - I had to add FileSystem to the kernel. I added 'FileSystem-AnsiStreams' > 'FileSystem-Core' 'FileSystem-Disk' and 'FileSystem-Memory' but maybe some are > not necessary. > - CommandLine has poor packaging because it includes tests too. > -Â SimpleCodeLoader is now not needed and can be removed > - CommandLine package will need some some next changes like to be independent > on Compiler (because of Fuel) > -Â KMPragmaKeymapBuilder needs better cleanup code. > - I added 'Ring-Core-Kernel' Â 'Ring-Core-Containers' and 'Fuel' > 'FuelMetalevel' 'FuelPackageLoader' packages (Fuel from external repository) > > I will open the issues. > > Cheers, > -- Pavel Great news !!! Edgar

May 4, 2012

Re: [Pharo-project] [Vm-dev] Re: Do we have the new primitive?? [WAS] Re: IdentitySet but using #hash rather than #identityHash ?

by Eliot Miranda

On Thu, Apr 26, 2012 at 8:19 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > >>>> Hi Eliot/Levente. What is the status of this? Do we have already the >>>> new primitive? If true, how can we adapt LargeIdentitySet to use such new >>>> primitive? >>>> >>> >>> AFAIK the new primitive is not implemented yet. Adding the primitive to >>> the interpreter VM is very easy, but it seems to be a lot more complicated >>> (to me) to add it to Cog, because the receiver can be a MethodContext which >>> needs special handling. >>> I'll rewrite both LargeIdentitySet and LargeIdentityDictionary when the >>> primitive is ready. >>> >> >> Thanks Levente. So we should wait Eliot. >> I will ping again in a couple of weeks/months ;) >> >> > Ping. So I did it :) > Eliot if you tell us what it is needed maybe I can push Esteban or Igor > (or me?) to do it ;) > Some form of accurate spec. e.g. a simulation in Smalltalk, along with a specification of the types. I'm not happy about the receiver being a MethodContext because that means the primitive has to check argument types. A primitive can assume the type of the receiver because the primitive can be put on a specific class in the hierarchy. Hence aBehavior adoptInstance: anObject is much better than anObject changeClassTo: aClass, because the former can know that the receiver is a valid behavior, and simply check that the argument is a suitable instance of the receiver, whereas the latter has to check both that aClass is a valid behavior (walking its hierarchy? checking it has a valid methodDictionary, etc, etc) /and/ that the receiver is a suitable instance of the argument. So if possible specify it as one or two primitives on LargeIdentitySet & LargeIdentityDictionary. > > Thanks! > > > >> >> >>> >>> >>> Levente >>> >>> >>> >>>> Thanks! >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Levente >>>> >>>> >>>> thanks >>>> >>>> On Fri, Dec 16, 2011 at 3:28 PM, Levente Uzonyi < >>>> leves(a)elte.hu> wrote: >>>> >>>> On Fri, 16 Dec 2011, Henrik Sperre Johansen wrote: >>>> >>>> On 16.12.2011 03:26, Levente Uzonyi wrote: >>>> >>>> >>>> How about my numbers? :) >>>> >>>> "Preallocate objects, so we won't count gc time." >>>> n := 1000000. >>>> objects := Array new: n streamContents: [ :stream | >>>> n timesRepeat: [ stream nextPut: Object new ] ]. >>>> >>>> set := IdentitySet new: n. >>>> Smalltalk garbageCollect. >>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. >>>> "4949" >>>> >>>> set := LargeIdentitySet new. >>>> Smalltalk garbageCollect. >>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. >>>> "331" >>>> >>>> set := (PluggableSet new: n) >>>> hashBlock: [ :object | object identityHash * 4096 + object >>>> class >>>> identityHash * 64 ]; "Change this to #basicIdentityHash in >>>> Pharo" >>>> equalBlock: [ :a :b | a == b ]; >>>> yourself. >>>> Smalltalk garbageCollect. >>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. >>>> "5511" >>>> >>>> >>>> I also have a LargeIdentityDictionary, which is relatively >>>> fast, but not >>>> as fast as LargeIdentitySet, because (for some unknown >>>> reason) we don't >>>> have a primitive that could support it. If we had a >>>> primitive like >>>> primitive 132 which would return the index of the element if >>>> found or 0 if >>>> not, then we could have a really fast >>>> LargeIdentityDictionary. >>>> >>>> >>>> Levente >>>> >>>> Hehe yes, if writing a version fully exploiting the limited range, >>>> that's >>>> probably the approach I would go for as well. >>>> (IAssuming it's the version at http://leves.web.elte.hu/** >>>> squeak/LargeIdentitySet.st<htt**p://leves.web.elte.hu/squeak/** >>>> LargeIdentitySet.st<http://leves.web.elte.hu/squeak/LargeIdentitySet.st> >>>> > >>>> ) >>>> >>>> Mariano commented in the version at http://www.squeaksource.com/** >>>> FuelExperiments <http://www.squeaksource.com/**FuelExperiments<http://www.squeaksource.com/FuelExperiments>> >>>> that it's >>>> slow for them, which I guess is due to not adopting #identityHash calls >>>> to >>>> #basicIdentityHash calls for Pharo: >>>> ((0 to: 4095) collect: [:each | each << 22 \\ 4096 ]) asSet size -> 1 >>>> So it basically uses 1 bucket instead of 4096... Whoops. :) >>>> >>>> Uploaded a new version to the MC repository which is adapted for Pharo, >>>> on the same machine my numbers were taken from, it does the same test >>>> as I >>>> used above in 871 ms. (181 with preallocation). >>>> >>>> >>>> Cool. One more thing: in Squeak the method using primitive 132 directly >>>> was renamed to #instVarsInclude:, so now #pointsTo: works as expected. >>>> If >>>> this was also added to Pharo, then the #pointsTo: sends should be >>>> changed >>>> to #instVarsInclude:, otherwise Array can be reported as included even >>>> if >>>> it wasn't added. >>>> I'll upload my LargeIdentityDictionary implementation to the same place >>>> this evening, since it's still 2-3 factor faster than other solutionts >>>> and >>>> there seem to be demand for it. >>>> >>>> >>>> Levente >>>> >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>>> >>>> >>>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- best, Eliot

May 4, 2012

[Pharo-project] better audio on meta-how-to video tutorial

by Lawson English

Here's a better version (better audio) of my "meta howto" video on how to deconstruct doing something in a class/package (Connectors) when the documentation isn't obvious: http://www.youtube.com/watch?v=xC6jcLw25Go&list=PL6601A198DF14788D&index=65… Lawson

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Nicolas Cellier

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 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. >

May 4, 2012