[ANN] Fix to issue 825
Locked
 
|
Hi,
I uploaded the following package to pharo-inbox: --------------------- Name: SLICE-ChangesFile-Fixes-Hernan_Wilkinson.2 ---------------------Author: Hernan Wilkinson Time: 26 June 2009, 7:31:40 pm UUID: 54cc49c6-ee34-4d99-b8fe-6b8b3446ea6c Ancestors: SLICE-ChangesFile-Fixes-Hernan Wilkinson.1 Dependencies: Kernel-Hernan Wilkinson.350, KernelTests-Hernan Wilkinson .119, Traits-Hernan Wilkinson.281, Files-Hernan_Wilkinson.ducasse.57 2009-06-26: Fixes to save class changes in the changes file 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. 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.
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
Bye, Hernan. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> Hi, > I uploaded the following package to pharo-inbox: > --------------------- > Name: SLICE-ChangesFile-Fixes-Hernan_Wilkinson.2 > Author: Hernan Wilkinson > Time: 26 June 2009, 7:31:40 pm > UUID: 54cc49c6-ee34-4d99-b8fe-6b8b3446ea6c > Ancestors: SLICE-ChangesFile-Fixes-Hernan Wilkinson.1 > Dependencies: Kernel-Hernan Wilkinson.350, KernelTests-Hernan > Wilkinson .119, Traits-Hernan Wilkinson.281, Files- > Hernan_Wilkinson.ducasse.57 > > 2009-06-26: Fixes to save class changes in the changes file > --------------------- > > 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) > 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. > 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 Stef > > Bye, > Hernan. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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?
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...
I did, it is the 825, it is in the subject :-)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hernan.wilkinson
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: [hidden email] [mailto:[hidden email]] On Behalf Of Hernan Wilkinson Sent: Saturday, June 27, 2009 2:24 PM To: [hidden email] Subject: Re: [Pharo-project] [ANN] Fix to issue 825
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?
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...
I did, it is the 825, it is in the subject :-)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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>. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Saturday, June 27, 2009 3:37 PM To: [hidden email] Subject: Re: [Pharo-project] [ANN] Fix to issue 825 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 _______________________________________________ Pharo-project mailing list [hidden email] 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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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. 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.
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. But it is ok, I understand that pharo is getting better and it takes time to have an stable system. Bye, Hernan.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
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 <[hidden email]>
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hernan.wilkinson
> > > > 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 > > > [hidden email] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Ups, I did not know about that. what is the limit? why?
I did, it is under the subject: [ANN] MouseOverHandler refactoring I hope it helps! Bye, Hernan.
_______________________________________________ Pharo-project mailing list [hidden email] 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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? > 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 :) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 :) > Marcus _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I agree with you Marcus, I think the driver should be the future, not the past, and more OO is definitely better. It is clear now that hardware is not the problem but the cost of maintaining software...
On Tue, Jun 30, 2009 at 6:54 AM, Marcus Denker <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Marcus Denker-3
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 :) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |