June 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Fix to issue 825

by Marcus Denker

On 29.06.2009, at 22:19, Hernan Wilkinson wrote: > > there are two answers: > in Squeak the changes file gets full too quickly > > Ups, I did not know about that. what is the limit? why? > Smalltalk was originally realized for a *very* resource contrained machine. (a self-build, very impressive design. Amazing for the time and in some aspects even today). But: Lots of design desicions had to be made that where purely driven by resource constraints. So for the sources and changes this meant: a) changes and sources use the same mechanism. b) they are not nicely object-oriented in the image but outside. c) the way this is done is a wonderful ugly hack. The last bytecodes of any method are not bytecodes at all, but instead they form a pointer to the sources and changes files. The end of the story is that this means that both can be max. 32MB in size. Plenty even 10 years ago, not enough to update from 3.8 to 3.9 today. (changes file needs to be reseted at some point). I personally think that with today's resources (my laptop has 4GB of Ram, not 256Kb), we should rethink some of the design-desicions taken 30 years ago. But many people are violently against this, fighting a battle by citing "embedded systems". If one manages to convince them that "embedded" these days does not equal "small", they mumble about "smart dust" and obscure things just to be able to fight for hacks not needed these days... Exploring new ways with the resources we have today does not mean that everything needs to live in the image. It means that one can affort to invest resources into very general, reusable solution to problems like this. One interesting aspect of the source/changes "outside the image" is that this problem of data that is not used often and thus can live on disk vs. memory is a general one. Hacking it into the system just for the sources is just that: a hack. Providing a general, scalable way to let objects live on disk that are not needed is much better, as everyone can than use it. The system can use it for other resources (fonts, images...). Programmers can use it to keep their domain data on disk automatically. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

June 30, 2009

Re: [Pharo-project] List of very big objects

by Adrian Lienhard

SpaceTally new printSpaceAnalysis: 100 on: 'space.txt' Prints the top 100 classes with the most instances. Adrian On Jun 30, 2009, at 09:20 , Damien Cassou wrote: > Hi, > > one of my images, with a web application in it, is getting larger and > larger. How can I find which object(s) take(s) so much place? > > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2009

[Pharo-project] List of very big objects

by Damien Cassou

Hi, one of my images, with a web application in it, is getting larger and larger. How can I find which object(s) take(s) so much place? Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 30, 2009

[Pharo-project] Omnibrowser chapter

by Alexandre Bergel

Dear All, I think the chapter can be significantly improved on a number of points: - how to create a command needs to be described - how to import icon into pharo, without that, hard to see how someone can create new icons - using Filter I will sync with Oscar today. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2009

Re: [Pharo-project] VM buid from source on debian linux - pls help

by GÃ¶ran Krampe

danil osipchuk wrote: >> "make" yields >> >> - disabledPlugins.c:21: error: redefinition of 'RomePlugin_exports' >> >> and stops. Easy hack fix: Remove one of those lines in disabledPlugins. Then it works fine. regards, GÃ¶ran

June 29, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Hernan Wilkinson

> > > there are two answers: > in Squeak the changes file gets full too quickly Ups, I did not know about that. what is the limit? why? > > can you post an email in a separate thread to ask for review? I did, it is under the subject: [ANN] MouseOverHandler refactoring I hope it helps! Bye, Hernan. > > > But it is ok, I understand that pharo is getting better and it takes > > time to have an stable system. > > Thanks. > > > > > Bye, > > Hernan. > > > > > > > > > > > Stef > > > > > > > > Bye, > > > > Hernan. > > > > > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > > project > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 29, 2009

Re: [Pharo-project] VM buid from source on debian linux - pls help

by danil osipchuk

Hello Andreas, I just have hit the same problem on kubuntu. Apparently there is a problem with config/configure script - It somehow disables RomePlugin twice in disabledPlugins.c: 20: sqExport RomePlugin_exports[] = { 0, 0, 0 }; 21: sqExport RomePlugin_exports[] = { 0, 0, 0 }; You can: 1) install both freetype6-dev and pango-dev packages to make RomePlugin eligible for compilation and to make problem go away 2) remove one offending line from the disabledPlugin.c after configure stage 3) try to fix the configure script In any case install also libx11-dev and libxt-dev - this will help you down the road regards, Danil 2009/6/29 Andreas Leidig <Andreas.Leidig(a)gmx.net>: > Dear list, > > > lenny (clean and new), GCC, > http://squeakvm.org/unix/release/Squeak-3.10-5.src.tar.gz: > > "make" yields > > Â - disabledPlugins.c:21: error: redefinition of 'RomePlugin_exports' > > and stops. > > > Same result with > > svn export http://squeakvm.org/svn/squeak/tags/unix-3.10-5 or > svn co http://squeakvm.org/svn/squeak/trunk Â Â squeak-svn > > I cannot find a working source package for a current vm. > > Can somebody please give me some hints how/where/from whom to get a > current working source package for a vm on debian linux? > > > > Best regards, > > Andreas > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 29, 2009

Re: [Pharo-project] different behavior between Dictionary and MethodDictionary for #add:

by Lukas Renggli

>> -> #add: Â return the association that has been added except for >> SmallDictionary for which #add: return the value of the association. > > I do not know. Does anybody know? SmallDictionary is an optimized dictionary originally written for the refactoring browser. I does not use associations internally and thus it would probably lose some of its performance returning an association. Maybe this is also a left-over because that code was originally written on a different Smalltalk and inheriting from Dictionary seems to be a bit dangerous in such a case anyway. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 29, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by StÃ©phane Ducasse

> > > > right now is saving all the changes to the log. I saw something > > about doit silent but I do not understand why a change should not be > > save, why is that? > > because sometimes you want to install code without polluting the > changes set > - halt > - breakpoint > and all kinds of trickery > > I did not change anything of that. This fix saves class definition > changes (like add a variable, change a class category, rename a > class, etc) and method categorization changes. I did not modify > anything related to changing methods so this should work as before. ok we should have a look at your fixes. > Now, about polluting the changes file (no the changes set, I think > they are two different things) I would not be so conservative, I > mean disk space is not a big issue now don't you think? > I think it is better to save all the necessary info in the changes > file to get back to what you have before a hang. That is how > VisualWorks and VisualAge works. there are two answers: in Squeak the changes file gets full too quickly even in VW you do now want to log generated code so having the possibility to choose is good. > > > > > I needed this fix becuase I lost a lot of work because pharo hanged > > on me many times... > > > yes, I did. Some were related to MouseOverHandler (I uploaded a new > version of that class to the pharo-inbox too), others to the > inputsensor change. can you post an email in a separate thread to ask for review? > But it is ok, I understand that pharo is getting better and it takes > time to have an stable system. Thanks. > > Bye, > Hernan. > > > > > > > Stef > > > > > > Bye, > > > Hernan. > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 29, 2009

Re: [Pharo-project] different behavior between Dictionary and MethodDictionary for #add:

by StÃ©phane Ducasse

Hi cyrille > Hi, > > I'm trying to test all subclasses of Dictionary cool. > and I just find a specific behavior for MethodDictionary : > > -> #add: return the association that has been added except for > SmallDictionary for which #add: return the value of the association. I do not know. Does anybody know? > Is there a reason for such an implementaion? probably lack of test reuse :) this is a good example showing that reusing tests using traits is a good way to offer consistent behavior.

June 29, 2009