What Metacello line ? :-) I see that we are navigating the same kinds of waters with these things. Hopefully for the best. I am also quite concerned about the image doing blocking calls w/ databases etc.
Phil On Mon, Jul 29, 2013 at 2:11 PM, Mariano Martinez Peck < marianop...@gmail.com> wrote: > > > > On Mon, Jul 29, 2013 at 9:02 AM, p...@highoctane.be <p...@highoctane.be>wrote: > >> Yes, same for me here. >> >> I'll update my configuration to load everything in a fresh 2.0 and report >> the results. >> >> Thing is that loading that full configuration takes ages (GlorpDBX is >> taking 20 minutes to load...) and the VM gets the SmallInteger bug >> triggered with such a large config... >> > > It's easy to fix workaround SmallInteger add issue. Just one line of code > in Metacello. > And yes, it takes ages. I also build an app that loads Seaside, Magritte3, > GlorpDBX, etc and it takes quite a lot. > Esteban did something to improve Monticello loading in Pharo 3.0....but > that's 3.0, not 2.0... > > >> >> I really need to get to grips with what happens down there. >> >> Phil >> >> On Monday, July 29, 2013, Sebastian Tleye wrote: >> >>> Try loading the packages each one at time, and between packages save the >>> image and check if it is growing. >>> >>> >>> 2013/7/29 Sebastian Tleye <stl...@gmail.com> >>> >>> What also happened to me, is that, each time i saved the image (even if >>> i did nothing), the image was growing its size. >>> >>> >>> 2013/7/29 Sebastian Tleye <stl...@gmail.com> >>> >>> Mmm, so i'm not sure. >>> I remember, when i had this problem, i was using directly changeSets, i >>> solved the problem doing "FileIn entire file" instead of "Install into a >>> new change set" (when you drag a changeset into Pharo). But it was like a >>> random bug since i haven't had that problem again (even using "Install into >>> a new change set" >>> >>> >>> 2013/7/29 p...@highoctane.be <p...@highoctane.be> >>> >>> Hi Sebastian, >>> >>> No, not intentionally. My code is going into the default change set and >>> there isn't that much. >>> >>> But... when looking at the Changes Sorter, there are indeed a lot of >>> entries related to all of those modules (due to the configurations being >>> loaded I guess - see screenshots for samples, the list is much longer). >>> >>> Phil >>> >>> >>> >>> >>> On Mon, Jul 29, 2013 at 11:39 AM, Sebastian Tleye <stl...@gmail.com>wrote: >>> >>> Hi Phil >>> >>> Have you been using changeSets? >>> I had the same problem once, i couldn't figure out what the problem was, >>> but i think there is a problem in the sorter tool (and change sets). >>> >>> >>> >>> 2013/7/29 p...@highoctane.be <p...@highoctane.be> >>> >>> Hello, >>> >>> I've been loading all of those packages in order to build a full web >>> stack development image. >>> >>> Everything now loads fine and kind of works but... >>> >>> The image is really slowing down and the size is getting very large. >>> >>> Here is the current one: >>> >>> 332580684 29 jul 10:50 >>> Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image >>> >>> 300+ megs... >>> >>> I've been doing some development in there and started looking for why >>> this was getting so large and slow. >>> >>> I did a SpaceTally print analysis and imported the results in a >>> spreadsheet. >>> >>> Look at the top consumers, especially the Semaphore thing. It is way >>> beyond whatever was expected. There is something wrong there. >>> >>> There must be a leak of Points, MorphExtensions and I can't just figure >>> out why there are so many Floats. >>> >>> I've been running test suites for some of the packages (e.g. OpenDBX and >>> Glorp) and this may be the result. >>> >>> This image is kind of what one doing web dev would end up with. >>> >>> But then, it is very hard to get rid of that unwanted space. >>> >>> I am trying to build a system I can start using for business projects >>> and feel concerned about that memory growth very seriously. >>> >>> Any pointers (I chased some already but here, there are way too many >>> entries) >>> >>> Thx >>> >>> Phil >>> >>> >>> >>> >>> >> >> -- >> --- >> Philippe Back >> Dramatic Performance Improvements >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 >> Mail:p...@highoctane.be | Web: http://philippeback.eu >> Blog: http://philippeback.be | Twitter: @philippeback >> Youtube: http://www.youtube.com/user/philippeback/videos >> >> High Octane SPRL >> rue cour Boisacq 101 | 1301 Bierges | Belgium >> >> Featured on the Software Process and Measurement Cast >> http://spamcast.libsyn.com >> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value >> Added Reseller >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >
