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

Re: [Pharo-project] FileReference convenience

by Guillermo Polito

On Fri, May 4, 2012 at 11:17 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > no! :) > > fileIn is too complex (and too important) to be a convenience method > (IMHO, it should never be in a Stream), it needs it's own class: CodeLoader > or something like that. > > but of course, while I disagree with your particular example, I agree in > adding convenience methods when their are convenient ;) > Don't be so hard, as an extension method should be fine :P. Now, The CodeLoader is a different story, I'll have a look tomorrow to see how hard is to move it :). > > best, > Esteban > > On May 4, 2012, at 11:08 PM, Sean P. DeNigris wrote: > > > Now that Filesystem is built-in, how about starting to add some > convenience > > methods, like this simple one... > > > > FileReference>>#fileIn > > > > FileStream fileIn: self fullName. > > > > -- > > View this message in context: > http://forum.world.st/FileReference-convenience-tp4609828.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > >

May 4, 2012

Re: [Pharo-project] FileReference convenience

by Esteban Lorenzano

no! :) fileIn is too complex (and too important) to be a convenience method (IMHO, it should never be in a Stream), it needs it's own class: CodeLoader or something like that. but of course, while I disagree with your particular example, I agree in adding convenience methods when their are convenient ;) best, Esteban On May 4, 2012, at 11:08 PM, Sean P. DeNigris wrote: > Now that Filesystem is built-in, how about starting to add some convenience > methods, like this simple one... > > FileReference>>#fileIn > > FileStream fileIn: self fullName. > > -- > View this message in context: http://forum.world.st/FileReference-convenience-tp4609828.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 4, 2012

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

by Guillermo Polito

:) I remember a few months ago I stepped with stdin hanging. Thanks for fixing :) On Fri, May 4, 2012 at 11:06 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > 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] FileReference convenience

by Sean P. DeNigris

Now that Filesystem is built-in, how about starting to add some convenience methods, like this simple one... FileReference>>#fileIn FileStream fileIn: self fullName. -- View this message in context: http://forum.world.st/FileReference-convenience-tp4609828.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2012

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