On 2 Mar 2018, at 21:31, Hilaire <hilaire@drgeo.eu> wrote:
Ah, you are right it is a 32bits image.
My bad, Dr.Geo does not build with 64bits image Pharo7.0-64bit-52a28a8
ConfigurationOfDrGeo class methodsFor: 'metacelUnmatched ' in string literal. ->
May be should try a more recent P7 64 bits image
Note: 52 MB is an overlarge image size for me (down 50% will be nice)
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed). There are things to look for: 1) wasted space due to not thinking about memory and just âhaving itâ. Of course some of it are things like duplications (we now have 2 browsers, 2 inspectors, 2 debuggers⦠time to clean up a bitâ¦). Then every test we add takes space, every âhelp topicâ, every feature... But of course sometimes being able to invest memory into a better system can be important, too. Not all growth in memory is negativ if you can afford it. I always like to play the game to think âwhat would they have done in 1978 if they had this amount of memory in even a $5 machine?" Of course one can go very quickly in the wrong direction, but nevertheless: sometimes it is really worth to think about âspending memoryâ to buy abstraction. (especially a there are counter measures⦠we under-utilise both compression and disk storage) 2) wasted space that is just not needed. e.g. there is issue https://pharo.fogbugz.com/f/cases/21172/ <https://pharo.fogbugz.com/f/cases/21172/> That we have some huge strings to init unicode. Do we need them? 3) Memory leaks, bit they are more for the case when the system is running for a while. Marcus