On Sep 4, 2013, at 8:57 AM, Marcus Denker <marcus.den...@inria.fr> wrote:
> > On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebr...@gmail.com> wrote: > >> On 09/03/2013 12:25 PM, Stéphane Ducasse wrote: >>> If you do not give us more information we will never be able to fix it. >>> And may be 3.0 will still have the problem and you will start using system >>> that is 3 year old. >>> I can understand that you get in a situation where you cannot do otherwise >>> but do not expect >>> us to fix magically things. >>> >>> Stef >> >> >> Hi Stef, >> >> For reporting the RFB issue I made a thread >> (http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-td4704639.html) >> and uploaded a Pharo 2 image to dropbox where if you execute this code: >> >> >> RFBServer start >> Smalltalk snapshot: true andQuit: false >> >> >> The image locks up using the 'pharo' VM and works fine using eliots vm. >> The uploaded image is Pharo-20619 with only RFB loaded. >> >> > I really do not like RFB… we do not use it at all in the daily development, > yet it people > load it for production environments. > > For me, the system we use every day should be identical to the production > environment, > else it is very hard to get a stable system. > > (We need to make what people get of of using RFB part of the base system: > remote browsing > and debugging). I undertand what you want and why do you say that you do not like RFB... but we are still far from the real answer and also people will always load their own third part libraries and that should be possible. Of course, since they not part of the core libraries, we do not have to take responsibility of those packages (we cannot take responsibility for all packages around)... but problem reported is a VM freeze, and that is of interest for us, so I still will take a look. Also, as I said... I have RFB running in 2.0 so it shouldn't have problems. > >> >> >> The other problem I had with Pharo 2 is the ever growing image size I >> reported here: >> >> http://forum.world.st/development-image-memory-use-180MB-in-Pharo-2-vs-40MB-in-Pharo-1-4-tp4699207.html >> >> I understand this is due to some leaks involving morphs and announcers >> and things that are fixed in pharo 3 but not pharo 2. >> > We are in the process of fixing them, but have not fixed all yet. I always > thought that we would > back port when we have fixed the problem completely in 3.0 I'm not sure what we are seeing in pharo3 is the same problem reported in pharo2. Of course if it is, we will backport. But "inflation" problem in ph3 is very consistent and repeatable, the problem reported in ph2... well, I never seen it before, and we have just one report (and I assume that we have more than one hundred production projects with that version). So is likely something different (also some of the detected leaks are due to changes in ph3, not present in the older version). Esteban > > Marcus > >
