On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebruic@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-td47046...) 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 will check this (after SUG)
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-...
I understand this is due to some leaks involving morphs and announcers and things that are fixed in pharo 3 but not pharo 2.
I have not gotten the impression that that fix will be backported, and even if it will it hasn't been yet so because of that and the RFB issue above I can't use Pharo 2 right now.
this is weird, because is the first time I see a report (well, I saw the other thread too) about this. and Pharo2 is productive since more than 8 months now (and I have some production stuff on it)... and I never seen it. This is likely not for the same reasons as pharo3 leaks (which btw are just partially solved, the leaks are still there). I would like to have that image to take a look, if possible, because is super-weird. Esteban ps: I would also like to know about other cases of this problem.
Hope this helps and thanks for following up
Paul