Hilaire It is up to you to give a real try. 1) Did you look for REAL at our infrastructure? Because you can take the bootstrapped image and change our build scripts. It took us may years to produce the loading scripts and this is the future. In Pharo 7 we have the possibility to have a core and several images.
2) Now I see you complaining but you can also help we never rejected a fix that make the system more modular. And we worked a lot to make it modular and IT IS MUCH MORE MODULAR. Now we do not have the energy to invest in building different image based on the core. So if you that need to not do it then why should we? 3) We will start a new reduction of the bootstrap core with Carolina PhD and you see we will not keep it for us (while we could). We want to have Pharo running on IoT devices. 4) We are starting to remove duplicated tools: Nautilus will go out, EyeInspector too. Old text model and widgets. Now again I personnally do not really care if Pharo has one or two mb more. 5) even on my old iPhone 53 mb is not that large. But I want a much smaller core and we will get there. 6) You see we introduce Athens in particular for Moose and DrGeo. Personnally I do not use at all Athens-Cairo. So this is funny how people react. Stef On Sat, Mar 3, 2018 at 3:21 PM, Hilaire <hila...@drgeo.eu> wrote: > Le 02/03/2018 à 22:52, Marcus Denker a écrit : >> >> >> we should again do some analysis where space is going… the Pharo7 download >> is now 38MB (the image, decompressed). > > > Situation improved :) Remember P3 was just above 20 MB > >> >> 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... > > > It looks like this topic comes and goes since 20 years: new features added, > image growth then/or it becomes hard to unload ; on Squeak then now with > Pharo at a much higher rate. > > We all know about the right approach (GNU Smalltalk, CUIS Smalltalk), but it > is not the road chosen with Pharo and it is becoming extremely uninteresting > for me to code on DrGeo now. So far I fell ashame to ship end user > application with a 50MB DrGeo image, knowing only 10% has purpose related to > DrGeo domain. When situation improves, motivation may come back. For this > same reason and other, I turned to Python for a planed programming course to > mid high school students. > >> >> 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 > > > Very likely not that much. May be the wonders came because of the hight > constraints. > > >> 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) > > Helps could (should?) be file based, and maybe other stuff I don't know. > > How the image is considered in the Pharo team? A kind of sacred place, > where stuff are added following a few guidelines (you will not duplicate > features but replace/imprive/whatever -- aka funny shortcut mess, you will > make your code unloadable, etc...) or just like a forum where teams add > feature according to projects or vision. > > Sorry to discuss these topics again, really don't want but still need to > share a few thoughts. > >> >> 2) wasted space that is just not needed. e.g. there is issue >> 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. >> > > -- > Dr. Geo > http://drgeo.eu > > >
