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

Re: [Pharo-project] NativeBoost help

by Igor Stasenko

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.

May 4, 2012

Re: [Pharo-project] Artefact - a PDF framework

by Igor Stasenko

On 2 May 2012 16:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Stephan Eggermont wrote >> >> Don't you think it would be much less work >> to port Christian Haider's work to Pharo? The namespace extensions to ring >> should >> be helpful to make two-way changes from both the VW and Pharo side. >> > > I was thinking the same thing. The usual Smalltalk duplication of effort > seems to have been taken to new heights with PDF libs ;-) I totally > understand the enthusiasm, because I really want it to (although more > viewing than generating)! I looked at doing the port at ESUG last year, but > hit the namespace wall... > > Sean > > p.s. I was reading the Cairo website the other day and PDF is one of the > "output targets". Could that be helpful here? yes, you are right.. http://www.cairographics.org/manual/cairo-PDF-Surfaces.html > > -- > View this message in context: http://forum.world.st/Artefact-a-PDF-framework-tp4585877p4603431.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Eliot Miranda

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

May 4, 2012

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

by Denis Kudriashov

Hello Try World addDefferedUIMessage: [morph step]. and run your full loop with delays in separated process 2012/5/4, Martin Drautzburg <Martin.Drautzburg(a)web.de>: > 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? > > -- > Martin > >

May 4, 2012

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

by Igor Stasenko

On 4 May 2012 17:50, Martin Drautzburg <Martin.Drautzburg(a)web.de> wrote: > 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? > hard to say.. apparently every morph should be drawn only once per step. probably you mixing stepping and drawing/updating? during stepping you should change some state, like advance the counters, do some calculations etc.. and then _just_ invalidate morphs which need to be redrawn, but do not draw them directly. (use "self changed" for morph ) then morphic will take care about redrawing things which are changed. > 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? > because of deferred updates. you should use Display forceToScreen to actually update the display. > -- > Martin > -- Best regards, Igor Stasenko.

May 4, 2012

[Pharo-project] Drawing speed for animations?

by Martin Drautzburg

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? -- Martin

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Igor Stasenko

ok, Luc i just added support for our case in NB. See NativeBoost-Core-IgorStasenko.57 you can use structs as return value from functions now. let me know if it works :) -- Best regards, Igor Stasenko.

May 4, 2012

Re: [Pharo-project] Artefact - a PDF framework

by Stephan Eggermont

Why do we have so many ways to create pdfs, and why do most libraries/frameworks only provide a partial solution? At first it seems not to difficult to build something for what I need, so it makes sense to build it myself. But the pdf spec is large, and I don't use most of it. Building it myself makes more sense than trying to understand a current implementation. That is more complex than needed to solve the current problem, and building my own is a good way to understand the spec. Completing an implementation is hard to justify on project costs (as is mostly done for open source). More people seem to have followed the same road, so we end up with lots of partial solutions. Next time I need to create pdfs, I have different needs. Something with fonts, that seems like a lot of work. So I connect to a c library that already implements it. Only that has no way to create a document in-memory, just on diskâ¦ Artefact at the moment has very simple text layout and table algorithms. They are suitable for simple documents. High quality layout is complex as it needs to handle a.o. line breaking, justification, ligatures, kerning, hyphenation, text direction, text container shape, paragraph and page layout. PDF4Smalltalk is large because it is able to read and write pdfs, so it needs to have at least basic support for all pdf elements, and it contains lots of constants and mappings (glyph list, font metrics). Cairo (and Pango) by itself does not support reading pdfs. Stephan

May 4, 2012

[Pharo-project] [update 1.4] #14441

by Esteban Lorenzano

14441 ----- Issue 5445: Broken command-line arguments in 1.4 http://code.google.com/p/pharo/issues/detail?id=5445 (this is to enable running pharo tests in windows)

May 4, 2012

[Pharo-project] [update 2.0] #20049

by Marcus Denker

20049 ----- Issue 5751: SUnit-UI Interaction refactor http://code.google.com/p/pharo/issues/detail?id=5751 Issue 5445: Broken command-line arguments in 1.4 http://code.google.com/p/pharo/issues/detail?id=5445 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012