- Pharo-dev - lists.pharo.org

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

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

by Igor Stasenko

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.

Nov. 24, 2011

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

by Sean P. DeNigris

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 -- View this message in context: http://forum.world.st/How-turn-on-Halo-s-tp2227309p4104352.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 24, 2011

Re: [Pharo-project] GUI Testing Library

by Ben Coman

Sean P. DeNigris wrote: > I'm starting to put together some helpers for UI testing. What's out there > already? > > I started simulating keyboard events. It seems like the place to hook is > ActiveHand>>handleEvent:. This way, it will take into account the keyboard > focus and route the event the way it would for a real event. Does that sound > right? > > So far the API adds TestCase>>simulateKeyStrokes: which forwards to > ActiveHand>>handleEvent:, so you can put in a test: > testMyMorph > MyMorph new openInWorld. "MyMorph takes the keyboard focus in > #initialize" > self simulateKeyStrokes: 'abcd'. "keystrokes go to MyMorph instance" > > Obviously, there are things missing (like modifier keys), but what are your > thoughts on the general approach? > > Sean > > -- > View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4097866.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > Perhaps an event recorder and replay could be added. This may be useful for instance if a regression GUI bug is introduced between Pharo versions that I encounter when driving the GUI. Then in the earlier version I could record the expected output of what I do in the GUI, then save that as a test to be loaded into the later version, and also attached to the issue tracker. just idle chatter and wild speculation. cheers, Ben

Nov. 24, 2011

[Pharo-project] [update 1.4] #14235

by Marcus Denker

14235 ----- Issue 5019: testSourceByIdentifierEncoding dependent on Network UUID http://code.google.com/p/pharo/issues/detail?id=5019 Issue 5018: deprecated #addLast:times: http://code.google.com/p/pharo/issues/detail?id=5018 Issue 5012: [ENH]: UITheme>>exampleGroups doIt comment http://code.google.com/p/pharo/issues/detail?id=5012 Issue 3702: squeeze out a bit more speed from TextDiffBuilder http://code.google.com/p/pharo/issues/detail?id=3702 -- Marcus Denker -- http://marcusdenker.de

Nov. 24, 2011

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

by Ben Coman

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