On Jun 27, 2009, at 9:24 PM, Hernan Wilkinson wrote:

...

With this fix, all changes made to classes like adding instance variables, class variables, changing method categories, changing class package, etc. are saved to the changes file. I spend some time trying to find the best way to do it, like Stef said some time ago, the code is not easy to understand, so I decided to do it the simplest way. So each method that changes something in the class, it also logs the change. The good thing is that no matter where the change is made, it is saved.

Did you pay attention that certain operation are silent (do not add to the change)

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

...

The drawback is that when changing a class from the browser's code panel, it saves the definition twice. All the changes are saved as "doit", so no change to the file in was necessary.

What do you mean by doit? Normally only class def (which is a mistake) are saved like doit.

I agree that it is a mistake, but I think that the first steep is to save everything. The next one should be to change the format.

yes having something more declarative and object-oriented

I needed this fix becuase I lost a lot of work because pharo hanged on me many times...

argh. Let us know if you can reproduce that. I think that we changed a lot and pharo 1.0 may be less stable than Squeak3.9

...

Ironically, I had a power down issue when testing it, so I did not loose anything! (and help me to find a bug). All the changes are tested. See ClassOrganizerTest, ClassTest and StandardSourceFileArrayTest

Hernan can you open an issue in the Bugtracker

I did, it is the 825, it is in the subject :-)

OK :)

Stef

...

Bye, Hernan.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef,

Sometimes I wonder whether the response times are to blame. <forDebate>Something that should happen in 0.1 seconds ends up taking several seconds, user gets suspicious that image has locked up, pokes around with the mouse (almost instinctive), and confuses the image</forDebate>.

I think that the input sensor was complex and that some existing code should be really fix and may be the sensor code contain some bugs. For example, we got some problem with moose and we could not bring a debugger. Stef

...

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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-

project

...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

On 30.06.2009, at 11:44, Douglas Brebner wrote:

Marcus Denker wrote:

...

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.

Didn't Tim change CompiledMethods so they referred to their source using a pointer so the source could be stored anywhere?

Yes, Tim did some changes (in 1998) to make compiledMethods normal objects that have a ByteArray for the bytecode and a normal instvar for the pointer to the source. IMHO the way to go, but it was never added to squeak... mostly because people feared the overhead (there are 40.000 methods, so adding another 40.000 is indeed noticable, as we have seen in 3.9 with the MethodProperties...). I personally like this change, as it makes the implementation higher- level and more OO, which I think is a good thing. I personally think that "more OO" is better than "more compact", considering that a laptop these days has 4GB (this is GIGABYTES) of RAM. I always wonder how Smaltalk would look like if it was disgned with the same philosophy in 1976 that people apply today. Using the "but it costs memory" philosphy that everyone favors today, Smalltalk would never have been done in 1976 at all. There is another patch floating around that allows larger sources/ changes without changing the mechanism too much.

...

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.

You mean something like LOOM? I would love to have that :)

Yes! :-) Marcus

Marcus Denker wrote:

On 30.06.2009, at 11:44, Douglas Brebner wrote:

...

Marcus Denker wrote:

...

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. Didn't Tim change CompiledMethods so they referred to their source using a pointer so the source could be stored anywhere?

Yes, Tim did some changes (in 1998) to make compiledMethods normal objects that have a ByteArray for the bytecode and a normal instvar for the pointer to the source. IMHO the way to go, but it was never added to squeak... mostly because people feared the overhead (there are 40.000 methods, so adding another 40.000 is indeed noticable, as we have seen in 3.9 with the MethodProperties...).

I so wish that had made it in.

I personally like this change, as it makes the implementation higher- level and more OO, which I think is a good thing. I personally think that "more OO" is better than "more compact", considering that a laptop these days has 4GB (this is GIGABYTES) of RAM.

Yes, it feels like an optimisation that simply isn't necessary any more. Worse, it makes it hard for tools to work on them. I can imagine quite a few tools that could be made with Tim style CompiledMethods.

I always wonder how Smaltalk would look like if it was disgned with the same philosophy in 1976 that people apply today. Using the "but it costs memory" philosphy that everyone favors today, Smalltalk would never have been done in 1976 at all.

Smalltalk (and Lisp too) have always looked to me like they were designed for future hardware rather than whatever was contemporary. Didn't Alan say something about that? The mind boggles at what a Smalltalk properly designed today would look like. Though I do believe it would feel similar to todays since the basic ideas of message passing and a live systems containing the tools would probably remain though on a much larger scale with multiple images working together. Personally, I feel that people are looking too hard at the artefacts like the image, the class structure and forgetting *why* they were built the way they were.

...

...

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.

You mean something like LOOM? I would love to have that :)

Yes! :-)

I'd also like to be able to store on remote images or even internet sites. Something like Craigs Spoon perhaps :)

Hi Bill, I have a good machine now... I'm running Ubuntu 9.04, 64 bits. I agree with you that OB is slow for some tasks like adding a package. I also lost code when not saving a method, going to another browser to change another method and going back to the original or things like that... I'll try to reproduce them and fix them. Hernan. 2009/6/27 Schwab,Wilhelm K <bschwab@anest.ufl.edu>

Hernan,

I've had some hangups, some of which I think were OB related; either it took a terribly long time to respond, or it got confused over package names - not sure which - I finally recovered what I could and started a new image. A few times, I have successfully broken out of an apparent lockup. BTW, that's another argument for keeping notifiers - why add add an extra second or two for the full debugger to open when a notifier is enough to let the user know the interrupt was "seen."

The other place I have lost work is accepts in either the debugger or (less of a problem) a browser going into the ether. In the case of the browser, I wonder whether the category or other context was correctly set??

Concerns over response times aside, which OS are you using?

Bill

------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [mailto: pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of *Hernan Wilkinson *Sent:* Saturday, June 27, 2009 2:24 PM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] [ANN] Fix to issue 825

...

...

With this fix, all changes made to classes like adding instance variables, class variables, changing method categories, changing class package, etc. are saved to the changes file. I spend some time trying to find the best way to do it, like Stef said some time ago, the code is not easy to understand, so I decided to do it the simplest way. So each method that changes something in the class, it also logs the change. The good thing is that no matter where the change is made, it is saved.

Did you pay attention that certain operation are silent (do not add to the change)

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?

...

...

The drawback is that when changing a class from the browser's code panel, it saves the definition twice. All the changes are saved as "doit", so no change to the file in was necessary.

What do you mean by doit? Normally only class def (which is a mistake) are saved like doit.

I agree that it is a mistake, but I think that the first steep is to save everything. The next one should be to change the format. I needed this fix becuase I lost a lot of work because pharo hanged on me many times...

...

...

Ironically, I had a power down issue when testing it, so I did not loose anything! (and help me to find a bug). All the changes are tested. See ClassOrganizerTest, ClassTest and StandardSourceFileArrayTest

Hernan can you open an issue in the Bugtracker

I did, it is the 825, it is in the subject :-)

...

Stef

...

Bye, Hernan.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project