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

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

by StÃ©phane Ducasse

Alex two remarks: - what is the level of reification because we reify a lot and it can be discarded. - did you check the orion model because with orion you only represent the delta and this is a big difference. Stef On Nov 24, 2011, at 2:05 PM, Alexandre Bergel wrote: > Having a reification in Moose of 100 versions of Mondrian for example :-) > > Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory > > Alexandre > > > On 24 Nov 2011, at 03: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. >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Nov. 24, 2011

Re: [Pharo-project] object format of true, false, nil and others...

by StÃ©phane Ducasse

> We do the same for our bootstrapper. First allocate space for the objects used by the metamodel: Metaclass, Class, Behavior, Object, UndefinedObject, True, False, their instances, metaclasses, etc. Each object of its corresponding size. how do you compute the size? > After that, fill the header and fields of these objects. Finally, new objects can be created by sending messages to objects in this kernel. I was planning to do the same so I would like to see your code. Tomorrow I want to read it. Stef > > Cheers, > Javier. > > On Wed, Nov 23, 2011 at 10:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > imagine that I want to bootstrap our nice kernel. > I will need to somehow create a new nil, true, false, instances of new classes Undefined, True, False. > Such instances will then be put on the SpecialObjectArray somehow. > > Now I can create a dummy object playing such roles and then use SystemTracer to substitute my placeholder with the true nil falseâ¦. > or another trick to swap them. Now anybody has other ideas? > > Stef > > > > -- > Lic. Javier PimÃ¡s > Ciudad de Buenos Aires

Nov. 24, 2011

Re: [Pharo-project] Pharo 1.3 vs 1.2.1 some results for ConfigurationOfODBC

by StÃ©phane Ducasse

did you check the plugins? are they the same? Stef On Nov 24, 2011, at 3:31 PM, Ben Coman wrote: > I have a Microsoft Access database on Microsoft Windows that I want to process using Pharo. ConfigurationOfODBC looked promising so followed instructions at http://www.pharocasts.com/2010/12/access-database-through-odbc.html, > though using a blank MDB file rather than SQLLite, and 'TestMDB' as the ODBC DSN, I executed... > --8<--- > Gofer new > squeaksource: 'ODBC'; > package: 'ConfigurationOfODBC'; load. > (Smalltalk at: #ConfigurationOfODBC) load. > > connection := ODBCConnection dsn: 'TestMDB' user: '' password: ''. > connection execute: 'CREATE TABLE user(name varchar(10), age smallint)'. > connection execute: 'INSERT INTO user VALUES(''Old Bob'', 100)'. > contents := (connection query: 'select * from user;') execute: ''. > contents asTable inspect. > connection close. > --8<--- > which failed on Pharo 1.3 but worked on Pharo 1.2.1. To debug this I compared each by single stepping 1.3 & 1.2.1 side-by-side. > I executed... connection := ODBCConnection dsn: 'TestMDB' user: '' password: ''. > which seemed to worked the same on both platforms up to the inserted 'self halt' shown here... > --8<--- > ODBCConnection>>connect > "Connect to the database" > self registerForFinalization. > hEnv := self sqlAllocEnv. > false ifTrue: > [ self > sqlSetEnvAttr: 200 > value: 2 "SQL_ATTR_ODBC_VERSION" ]. > self halt. > hdbc := self sqlAllocConnect: hEnv. > --8<--- > ODBCConnection>>sqlAllocConnect: envHandle > | h | > h := SQLHDBC new. > self checkSQLReturn: (ODBCLibrary default > sqlAllocConnectEnvironment: hEnv connection: h > ). > ^h > --8<--- > ODBCLibrary(Object)>>sqlAllocConnectEnvironment: environmentHandle connection: connectionHandle > "SQLRETURN > SQLAllocConnect( > SQLHENV EnvironmentHandle, > SQLHDBC *ConnectionHandle);" > <cdecl: short 'SQLAllocConnect' (SQLHENV SQLHDBC*)> > ^ self externalCallFailed > --8<--- > ODBCConnection>>checkSQLReturn: sqlReturn > "private - check the sqlReturn and generates an exception if corresponds" > self > checkSQLReturn: sqlReturn > environment: hEnv > connection: hdbc > statement: nil > --8<--- > If you've followed the call chain down to here, then the result is... > In Pharo 1.2.1 (WinXP & Win7) primitive SQLAllocConnect primitive succeeds, with sqlReturn=0 > In Pharo 1.3 (WinXP & Win7) primitive SQLAllocConnect primitive succeeds, with sqlReturn=-2 > I cannot find what -2 may mean on any of the Microsoft ODBC API pages, nor a few header files I checked (though I may have missed some header file) > ================= > To investigate further, I thought to try running the bypassed code... > --8<--- > ODBCConnection>>connect > "Connect to the database" > self registerForFinalization. > hEnv := self sqlAllocEnv. > self halt. > true ifTrue: > [ self > sqlSetEnvAttr: 200 > value: 2 "SQL_ATTR_ODBC_VERSION" ]. > --8<--- > sqlSetEnvAttr: attr value: value > self checkSQLReturn: (ODBCLibrary default > sqlSetEnvAttr: hEnv attr: attr value: value length: 0 > ) > --8<--- > sqlSetEnvAttrPtr: hEnv attr: attr value: value length: length > "SQLRETURN SQLSetEnvAttr( > SQLHENV EnvironmentHandle, > SQLINTEGER Attribute, > SQLPOINTER ValuePtr, > SQLINTEGER StringLength);" > <cdecl: short 'SQLSetEnvAttr' (SQLHENV long void* long)> > ^ self externalCallFailed > --8<--- > For both 1.2.1 and 1.3 'self externalCallFailed' is executed > for 1.2.1 errCode=12 'No module to load address from' > for 1.3 errCode=13 'Unable to find function address' > --8<--- > Pointers anyone? > btw, In parallel I am also trying out DBXTalk. >

Nov. 24, 2011

Re: [Pharo-project] How turn on Halo's?

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > option-shift-click for show halos > Yes, that cycles from front to back. What was removed was back to front (option-click) -- View this message in context: http://forum.world.st/How-turn-on-Halo-s-tp2227309p4105053.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 24, 2011

Re: [Pharo-project] How turn on Halo's?

by Sven Van Caekenberghe

On 24 Nov 2011, at 16:42, Sean P. DeNigris wrote: > > StÃ©phane Ducasse wrote >> >> in pharo halos are there but only when you really want them. :) >> > > In Squeak, you can cycle through the halos either front to back or reverse. > I'd like to get that behavior back on my personal images as I use it all the > time. Does anyone know where the functionality lived? I checked the issue > tracker but didn't find the actual code that was integrated to remove it. > > Thanks. > Sean On my Mac it is option-shift-click for show halos ctrl-click for the menu HTH, Sven

Nov. 24, 2011

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

by David T. Lewis

Much larger images can be supported. This may be of interest: <http://lists.squeakfoundation.org/pipermail/vm-dev/2010-November/005731.html> In practical use, the current garbage collector will probably be the limiting factor. Dave On Thu, Nov 24, 2011 at 01:29:26PM -0300, Alexandre Bergel wrote: > As Stefan put it, the current system forces us to make early decisions, which are likely to be wrong on some point. > > Since there is no other option, we are thinking very hard on what do we really need. > We are implementing ad-hoc caching as you suggested, but this clearly puts some strong constraints on what can be done. > > Alexandre > > > On 24 Nov 2011, at 13:13, Igor Stasenko wrote: > > > I think you looking for solution in a wrong direction. > > Just ask yourself, how much of that data you need to keep in operative > > memory at single moment of time > > to efficiently compute results. > > If today you need to deal with >500Mb data sets, > > tomorrow you may need to deal with multigigabyte datasets, which can > > easily surpass > > the amount of operative memory your computer has. > > > > I know, it is easier to find cheap solution, without spending time > > implementing own > > data caching scheme, but you just delaying inevitable. > > > > With things like Fuel, i think it won't take too much effort to do it. > > > > On 24 November 2011 14:06, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>> But, I also guess that Alex refers to the default values for memory when running the VM. Is that correct Alex? > >> > >> Yes. > >> > >> Alexandre > >> > >>> > >>> > >>> 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." > >>> > >>> > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Nov. 24, 2011

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

by Francois Stephany

On 24/11/11 05:05, Alexandre Bergel wrote: > Having a reification in Moose of 100 versions of Mondrian for example :-) > > Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory > > Alexandre Oh ok, I hadnt Moose in mind ;)

Nov. 24, 2011

Re: [Pharo-project] object format of true, false, nil and others...

by Javier PimÃ¡s

We do the same for our bootstrapper. First allocate space for the objects used by the metamodel: Metaclass, Class, Behavior, Object, UndefinedObject, True, False, their instances, metaclasses, etc. Each object of its corresponding size. After that, fill the header and fields of these objects. Finally, new objects can be created by sending messages to objects in this kernel. Cheers, Javier. On Wed, Nov 23, 2011 at 10:59 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi > > imagine that I want to bootstrap our nice kernel. > I will need to somehow create a new nil, true, false, instances of new > classes Undefined, True, False. > Such instances will then be put on the SpecialObjectArray somehow. > > Now I can create a dummy object playing such roles and then use > SystemTracer to substitute my placeholder with the true nil falseâ¦. > or another trick to swap them. Now anybody has other ideas? > > Stef > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Nov. 24, 2011

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

by Schwab,Wilhelm K

Sig, There is an oddly similar conversation on the Plplot-devel mailing list: "Unnecessary library linkage". Very likely, it's the Cairo folks who need to read it though. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Wednesday, November 23, 2011 10:05 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs 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] experience with large images?

by Alexandre Bergel

As Stefan put it, the current system forces us to make early decisions, which are likely to be wrong on some point. Since there is no other option, we are thinking very hard on what do we really need. We are implementing ad-hoc caching as you suggested, but this clearly puts some strong constraints on what can be done. Alexandre On 24 Nov 2011, at 13:13, Igor Stasenko wrote: > I think you looking for solution in a wrong direction. > Just ask yourself, how much of that data you need to keep in operative > memory at single moment of time > to efficiently compute results. > If today you need to deal with >500Mb data sets, > tomorrow you may need to deal with multigigabyte datasets, which can > easily surpass > the amount of operative memory your computer has. > > I know, it is easier to find cheap solution, without spending time > implementing own > data caching scheme, but you just delaying inevitable. > > With things like Fuel, i think it won't take too much effort to do it. > > On 24 November 2011 14:06, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> But, I also guess that Alex refers to the default values for memory when running the VM. Is that correct Alex? >> >> Yes. >> >> Alexandre >> >>> >>> >>> 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." >>> >>> > > > -- > Best regards, > Igor Stasenko. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 24, 2011