November 2011 - Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

On 24 Nov 2011, at 01:38, Igor Stasenko wrote: > check maybe you have two UI processes running. Yes, see my comments on http://code.google.com/p/pharo/issues/detail?id=5013 > 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! >> >> :)) >> >

Nov. 24, 2011

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

by Stephan Eggermont

Francois Stephany wrote: > I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. > Alex, what is your use case (in practice!) for more than 500MB? We are doing data conversion with Moose. Raw data is 740 MB. No 64-bit means being forced to make decisions early, and therefore wrong. It also forces us to do some batch processing. We're very lucky the customer has a good idea on what data to keep. Stephan

Nov. 24, 2011

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

by Tudor Girba

I guess Alex talks about a Moose image. With Moose we can easily get to quite large images with millions of objects. For Windows, we indeed had a problem with the VM that Igor fixed. At that time, the problem appeared in images of over 200MB that could not be reopened (could be built, but once closed could not be reopened). I do not know what the status is with 500 MB. But, I also guess that Alex refers to the default values for memory when running the VM. Is that correct Alex? Cheers, Doru On 24 Nov 2011, at 07:27, Francois Stephany wrote: > I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. > Alex, what is your use case (in practice!) for more than 500MB? > > On 23/11/11 18:25, Igor Stasenko wrote: >> 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. > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Nov. 24, 2011

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

by Francois Stephany

I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB? On 23/11/11 18:25, Igor Stasenko wrote: > 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.

Nov. 24, 2011

[Pharo-project] Chasing Browsers

by Sean P. DeNigris

I have the setting enabled, but my implementors and senders are not... chasing. What gives? -- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4102608.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 24, 2011

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