- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Schwab,Wilhelm K

AccesIO does the same thing with their driver DLL/SO; I use their C library for obvious reasons. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Serge Stinckwich [serge.stinckwich(a)gmail.com] Sent: Wednesday, November 23, 2011 10:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs On Thu, Nov 24, 2011 at 11:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >>> >>> >>> 2011/11/23 Stefan Marr <pharo(a)stefan-marr.de> >>>> >>>> Hi: >>>> >>>> On 23 Nov 2011, at 16:50, Igor Stasenko wrote: >>>> >>>> > build_arch to "i386" >>>> >>>> There used to be the +universal flag that made sure that all >>>> universal_archs where build, and then universal_archs was "x86_64 i386". >>>> >>>> Not sure what the easiest way is to get macports to rebuild all the >>>> dependencies, but when I update with the force option, I think it is doing >>>> that. >>>> >>>> Best regards >>>> Stefan >>>> >>> >>> I had the same problem with the OpenCV and the mysqlclient libraries that I >>> used through FFI. >>> For OpenCV I found a 32bits precompiled framework on the Web. >>> For mysqlclient, I did exactly what Stefan said i.e. configure universal >>> flavour for both i386 and x86_64 architectures and install (recompile all >>> dependencies) using the universal flag. >> >> Did you success on using OpenCV through FFI ? >> I was interested but i bit afraid by the amount of work to have a >> working prototype. >> > > it says that 2.1 version is implemented in C++... > making calls to C++ through FFI is completely different story, and unfortunately > there is no common standard for C++ dynamic libs. Unless it having C > API wrapper. Normally in the last version of OpenCV, they combine a C and C++ interfaces at the same time. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 24, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Schwab,Wilhelm K

It depends on how much ++ they used. Sometimes, it is simply a matter of annoying name mangling[*]. In one situation, I had success dumping the exported names and pasting the obvious into the FFI methods. An example: getErrorText:errorCode pBuffer:pBuffer bufferSize:bufferSize type:type "int GetErrorText(int errorCode, char* pBuffer, int bufferSize, enum MESSAGE_TYPE type)" < apicall: long '?GetErrorText@@YAHHPADHW4MESSAGE_TYPE@@@Z' ( long char* long long ) > ^self invalidCall. I was not happy with the vendor. All it takes is extern "C" to avoid the hassle. Bill [*] Yes, I know they call it "decoration" now, but there was a time when men were men, and they wrote compilers that MANGLED names :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, November 23, 2011 9:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >> >> >> 2011/11/23 Stefan Marr <pharo(a)stefan-marr.de> >>> >>> Hi: >>> >>> On 23 Nov 2011, at 16:50, Igor Stasenko wrote: >>> >>> > build_arch to "i386" >>> >>> There used to be the +universal flag that made sure that all >>> universal_archs where build, and then universal_archs was "x86_64 i386". >>> >>> Not sure what the easiest way is to get macports to rebuild all the >>> dependencies, but when I update with the force option, I think it is doing >>> that. >>> >>> Best regards >>> Stefan >>> >> >> I had the same problem with the OpenCV and the mysqlclient libraries that I >> used through FFI. >> For OpenCV I found a 32bits precompiled framework on the Web. >> For mysqlclient, I did exactly what Stefan said i.e. configure universal >> flavour for both i386 and x86_64 architectures and install (recompile all >> dependencies) using the universal flag. > > Did you success on using OpenCV through FFI ? > I was interested but i bit afraid by the amount of work to have a > working prototype. > it says that 2.1 version is implemented in C++... making calls to C++ through FFI is completely different story, and unfortunately there is no common standard for C++ dynamic libs. Unless it having C API wrapper. > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Best regards, Igor Stasenko.

Nov. 24, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Serge Stinckwich

On Thu, Nov 24, 2011 at 11:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >>> >>> >>> 2011/11/23 Stefan Marr <pharo(a)stefan-marr.de> >>>> >>>> Hi: >>>> >>>> On 23 Nov 2011, at 16:50, Igor Stasenko wrote: >>>> >>>> > build_arch to "i386" >>>> >>>> There used to be the +universal flag that made sure that all >>>> universal_archs where build, and then universal_archs was "x86_64 i386". >>>> >>>> Not sure what the easiest way is to get macports to rebuild all the >>>> dependencies, but when I update with the force option, I think it is doing >>>> that. >>>> >>>> Best regards >>>> Stefan >>>> >>> >>> I had the same problem with the OpenCV and the mysqlclientÂ libraries that I >>> used through FFI. >>> For OpenCV I found a 32bits precompiled framework on the Web. >>> For mysqlclient, I did exactly what Stefan said i.e. configure universal >>> flavour for both i386 and x86_64 architectures and install (recompile all >>> dependencies) using the universal flag. >> >> Did you success on using OpenCV through FFI ? >> I was interested but i bit afraid by the amount of work to have a >> working prototype. >> > > it says that 2.1 version is implemented in C++... > making calls to C++ through FFI is completely different story, and unfortunately > there is no common standard for C++ dynamic libs. Unless it having C > API wrapper. Normally in the last version of OpenCV, they combine a C and C++ interfaces at the same time. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 24, 2011

Re: [Pharo-project] experience with large images?

by Igor Stasenko

It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically. On 24 November 2011 00:55, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > It depends on the OS. The 500mb limit should be for Windows. > Unix and Mac should be more (kind of 2gb). > Search in the history a thread between Tudor and Igor about a windows VM > with more than 500mb for Moose. > > cheers > > On Wed, Nov 23, 2011 at 6:45 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: >> >> Hi! >> >> Apparently, without configuring anything, the Pharo image cannot go over >> 500 Mb. >> Can this limit be moved up, to, let's say, 4Gb? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko.

Nov. 24, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Igor Stasenko

On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >> >> >> 2011/11/23 Stefan Marr <pharo(a)stefan-marr.de> >>> >>> Hi: >>> >>> On 23 Nov 2011, at 16:50, Igor Stasenko wrote: >>> >>> > build_arch to "i386" >>> >>> There used to be the +universal flag that made sure that all >>> universal_archs where build, and then universal_archs was "x86_64 i386". >>> >>> Not sure what the easiest way is to get macports to rebuild all the >>> dependencies, but when I update with the force option, I think it is doing >>> that. >>> >>> Best regards >>> Stefan >>> >> >> I had the same problem with the OpenCV and the mysqlclientÂ libraries that I >> used through FFI. >> For OpenCV I found a 32bits precompiled framework on the Web. >> For mysqlclient, I did exactly what Stefan said i.e. configure universal >> flavour for both i386 and x86_64 architectures and install (recompile all >> dependencies) using the universal flag. > > Did you success on using OpenCV through FFI ? > I was interested but i bit afraid by the amount of work to have a > working prototype. > it says that 2.1 version is implemented in C++... making calls to C++ through FFI is completely different story, and unfortunately there is no common standard for C++ dynamic libs. Unless it having C API wrapper. > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Best regards, Igor Stasenko.

Nov. 24, 2011

Re: [Pharo-project] Athens work in progress: couple screenshots

by Igor Stasenko

On 24 November 2011 01:33, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Ah! So Athens is a facade, for a Canvas API, based on Paths, that > could have a Cairo, OpenGl or BallonCanvas rendering engine as a > backend. > Right. The only things which i don't want to be trapped with is to have minimal common denominator, which usually happens when you have different backends with different features. But i think we should be guided by our practical needs: instead of trying hard to support various fancy stuff, potentially usable in 0.001% cases, we should focus on things which we really need. That's why i took an effort with Morphic adoption. > In the current case, using BallonCanvas (bit map based), i guess you > are implementing the scalable fonts using the free type library? In > Gaucho, i've done exactly that, i have a FontLibrary which acts as a > cache for a particular font family, at a requested size. So when Â the > canvas renders a string with a given font, it asks the library for the > font at the current scale of the desired size. > In Athens i dont use cache for rendering freetype fonts, because it is pointless. I measured time to render text with and without letting freetype to render each separate glyph and found that glyphs rendering taking 1/3 of total rendering time. (so, it is memory bound - freetype renders a glyph into 8-bit grayscale bitmap, and then we blit it on 32bit bitmap, which explains given ratio, the cost of drawing shape(s) looks like completely neglectible ;). So, i don't see a big reason for having cache, and moreover it makes sense only if you render things horizontally, but if you allow an arbitrary angle and scale, then there is no way to make efficient cache of it (oh yeah.. unless you have terabytes of memory ;). The only thing which i imagine how to cache it is to capture the whole output of text into "cache bitmap", rather than bother with separate glyphs. But this is another level of caching, which potentially could be used for other things not just for text rendering. And actually it is easily doable by youself: we can create a separate surface, render stuff there, and then just blit ready for use parts to another surface, or redraw it, if something are changed. > Although i prefer the abstractions that are present in Athens, and > will try to use it instead eventually. Be careful, some abstractions are cruft :) Because i took the original work started by Cyrille , but all new classes i wrote was from scratch, while i left existing ones for review & future conversion. I should clean it to not confuse people. > > Fernando > pd: attached screen shot of Gaucho, using a scalable GCanvas (built on > top of the free type lib and FormCanvas). > > > On Wed, Nov 23, 2011 at 1:08 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> +1 >> >> Something big is happening in the Pharo World. >> >> Alexandre >> >> >> On 23 Nov 2011, at 08:44, StÃ©phane Ducasse wrote: >> >>> put it in the class comments somewhere. >>> Do not expect that people will know what you know. >>> Make the entry simple and immediate. >>> >>> Stef >>> >>>> On 23 November 2011 11:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Igor >>>>> >>>>> prepare the following: >>>>> Â Â Â - a class showing an example >>>>> Â Â Â Â Â Â Â with the transformation stuff (because it is unclear) >>>> >>>> There is one: >>>> AthensBalloonSurfaceExamples >>>> >>>> >>>>> >>>>> Â Â Â - a tester canvas so that people can to >>>>> >>>>> (CanvasTester testClass: CircleMorph) open. >>>>> >>>> err.. what is it? >>>> >>>> To test morphic display on Athens you can do following: >>>> >>>> | surf | >>>> Â Â Â surf := AthensBalloonSurface new form: (Form extent: Display extent depth: 32). >>>> >>>> Â Â Â surf drawDuring: [ :canvas | >>>> >>>> Â Â Â Â Â Â Â canvas fullDrawMorph: yourMorph. >>>> ]. >>>> >>>> Display getCanvas translucentImage: surf form at: 0@0 >>>> >>>> >>>> >>>> >>>>> People could then extend the Athens package with the method in the morph. >>>>> >>>>>> It would be great to help adapting all morphs for Athens. >>>>>> Morphs, that having own draw method(s), should also have own >>>>>> #drawOnAthensCanvas: >>>>>> >>>>>> I didn't covered all of them yet, so a little help with it would be nice. >>>>>> Also, it is good for checking the missing functionality in Athens API >>>>>> as well as learning it. >>>>>> >>>>>> There's not much to learn yet :) >>>>>> >>>>>> basicly what you should know is that you have coordinate system: >>>>>> >>>>>> canvas pathTransform >>>>>> Â (instance of AthensAffineTransform) >>>>>> >>>>>> which you can manipulate to achieve desirable results. >>>>>> >>>>>> And actual drawing: >>>>>> >>>>>> canvas setPaint: somePaintObject. ( color, gradient, or anything which >>>>>> conforms to AthensPaint protocol ). >>>>>> canvas drawShape: Â (rect or path or anything , which responds to: >>>>>> 'paintFillsUsing: aPaint on: anAthensCanvas' ). >>>>>> canvas draw: (anything , which responds to #drawOnAthensCanvas: ) >>>>> >>>>> think that we are dummies willing to help and do the two things I mention above. >>>>> I'm then sure you will get contributions. >>>>> >>>>> Stef >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > -- Best regards, Igor Stasenko.

Nov. 24, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Serge Stinckwich

On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > > 2011/11/23 Stefan Marr <pharo(a)stefan-marr.de> >> >> Hi: >> >> On 23 Nov 2011, at 16:50, Igor Stasenko wrote: >> >> > build_arch to "i386" >> >> There used to be the +universal flag that made sure that all >> universal_archs where build, and then universal_archs was "x86_64 i386". >> >> Not sure what the easiest way is to get macports to rebuild all the >> dependencies, but when I update with the force option, I think it is doing >> that. >> >> Best regards >> Stefan >> > > I had the same problem with the OpenCV and the mysqlclientÂ libraries that I > used through FFI. > For OpenCV I found a 32bits precompiled framework on the Web. > For mysqlclient, I did exactly what Stefan said i.e. configure universal > flavour for both i386 and x86_64 architectures and install (recompile all > dependencies) using the universal flag. Did you success on using OpenCV through FFI ? I was interested but i bit afraid by the amount of work to have a working prototype. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 24, 2011

Re: [Pharo-project] World intermittently becoming a mess

by Igor Stasenko

check maybe you have two UI processes running. On 24 November 2011 00:47, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Wed, Nov 23, 2011 at 11:38:42AM -0800, Sean P. DeNigris wrote: >> >> Every once in a while ... the World becomes a mess ... > > What a great subject line! A complete summary of world history, current > affairs, sociology, political science, and the art of software development > all condensed into a single sentence. Brilliant! > > :)) > > > -- Best regards, Igor Stasenko.

Nov. 24, 2011

Re: [Pharo-project] Java team looking into Smalltalk and Seaside

by Serge Stinckwich

On Thu, Nov 24, 2011 at 2:21 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Sean P. DeNigris wrote: >> Maybe someone with experience using Smalltalk on a team can answer this: >> http://stackoverflow.com/questions/8244502/version-control-for-smalltalk-se… > > Nice question. I've added a mixture of what we do and should be doing... Great reply ! Maybe a should write a more complete explanation on how everything integrate together. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 24, 2011

Re: [Pharo-project] GUI Testing Library

by Sean P. DeNigris

Alexandre Bergel-7 wrote > > I will invite you for a couple of beers at the next esug :-) > Paid in beer?! This is the best job ever ;-) -- View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4102097.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011