[Pharo-project] Pharo Harvesting Infrastructure
Hi. I found a bug in Pharo, and I started wondering how to determine where it came from. I checked a few methods in the debugger to see if they had recently been modified, but that was no help. I checked the change sorter to see if it had any idea what had been recently installed, but it was choked by Monticello updates. Then I opened a new Pharo Image in order to try each update one by one (whatever Monticello you guys use to load your changes is *really* slow. I gotta fix you guys up with MC1.6). But before I did that, I noticed on the right of the screen is something that looks like a change log. And at the bottom, it said: (full list of changes: print "ScriptLoader new logContents") So I tried it in my 10091 image, and sure enough, it printed up a changelog. So I went to see what this mysterious class ScriptLoader is. I found a whole lot of methods. Some looked auto-generated. Some seemed to be convenience methods for loading MC packages from Pharo and PharoInbox. It looks kind of like Installer, which I am more familiar with. I'm rather curious now about how you manage Pharo. I took a look at http://code.google.com/p/pharo/wiki/HowToContribute and wondered what happens after that. I now imagine it involves ScriptBuilder building the update, and then something uploading it. What is the mechanism? How is Pharo tested? is it regularly tested by someone using TestRunner, or something fancier? What are all the auto-generated methods in ScriptLoader for? How do you typically trace a bug from image to problem package to update to issue? I'm interested because keith and I are building a build server that is able to build images, build packages, load packages, run tests, build VM's and such, all automated and with an easy interface. So far, we have the easy interface (Installer), but are still working on making it do more. So I'm interested in learning how it works here, so that we can at least end up with something as good as this -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
I will take the time to reply. RIght now I'm busy with friends for my birthday :) Stef On Oct 11, 2008, at 10:52 AM, Matthew Fulmer wrote:
Hi. I found a bug in Pharo, and I started wondering how to determine where it came from. I checked a few methods in the debugger to see if they had recently been modified, but that was no help. I checked the change sorter to see if it had any idea what had been recently installed, but it was choked by Monticello updates.
Then I opened a new Pharo Image in order to try each update one by one (whatever Monticello you guys use to load your changes is *really* slow. I gotta fix you guys up with MC1.6). But before I did that, I noticed on the right of the screen is something that looks like a change log. And at the bottom, it said:
(full list of changes: print "ScriptLoader new logContents")
So I tried it in my 10091 image, and sure enough, it printed up a changelog. So I went to see what this mysterious class ScriptLoader is. I found a whole lot of methods. Some looked auto-generated. Some seemed to be convenience methods for loading MC packages from Pharo and PharoInbox. It looks kind of like Installer, which I am more familiar with.
I'm rather curious now about how you manage Pharo. I took a look at http://code.google.com/p/pharo/wiki/HowToContribute and wondered what happens after that. I now imagine it involves ScriptBuilder building the update, and then something uploading it. What is the mechanism?
How is Pharo tested? is it regularly tested by someone using TestRunner, or something fancier?
What are all the auto-generated methods in ScriptLoader for?
How do you typically trace a bug from image to problem package to update to issue?
I'm interested because keith and I are building a build server that is able to build images, build packages, load packages, run tests, build VM's and such, all automated and with an easy interface. So far, we have the easy interface (Installer), but are still working on making it do more.
So I'm interested in learning how it works here, so that we can at least end up with something as good as this
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Oct 11, 2008 at 04:55:52PM +0200, St?phane Ducasse wrote:
I will take the time to reply. RIght now I'm busy with friends for my birthday :)
hehe. I'll be celebrating my birthday later today too. Have fun! -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
On Sat, 2008-10-11 at 08:37 -0700, Matthew Fulmer wrote:
On Sat, Oct 11, 2008 at 04:55:52PM +0200, St?phane Ducasse wrote:
I will take the time to reply. RIght now I'm busy with friends for my birthday :)
hehe. I'll be celebrating my birthday later today too. Have fun!
No way. It's my birthday, too. :)) Norbert
I'm rather curious now about how you manage Pharo. I took a look at http://code.google.com/p/pharo/wiki/HowToContribute and wondered what happens after that. I now imagine it involves ScriptBuilder building the update, and then something uploading it. What is the mechanism?
ok so the scriptloader is our friend since early days of 3.9. It is basically a set of functionality which can load a description of packages. two methods are generated - scriptXXX contains the list of packages - update100XX contains now a description code to load the list cleanups We did not use mcm because it did not work for us at that time. We have sometimes the need to load sequentially packages and not all at the same time.
How is Pharo tested? is it regularly tested by someone using TestRunner, or something fancier?
For now there is not automated regression mechahnism Laurent Laffont and Alexandre Bergel are working on a test server.
What are all the auto-generated methods in ScriptLoader for?
to be able to go back in the past. we can always know all the packages of a given image. Even if sometimes we cannot take 3.9readyForPharo and simply press the button to reproduce the image. This is due that some changes should be done via cs and produces dirty packages that in the past could not be reloaded. Like MVC having broken initialize method and also due to the fact that atomic loading was not working (we will get there when we will finally use MC1.6 - but you know that we will not do it at the price of bringing code we do not like, but we are making progress on that :).
How do you typically trace a bug from image to problem package to update to issue?
Manually. It sucks!
I'm interested because keith and I are building a build server that is able to build images, build packages, load packages, run tests, build VM's and such, all automated and with an easy interface. So far, we have the easy interface (Installer), but are still working on making it do more.
I know, I discussed about with keith long time ago and I like what he is doing. Now again we will review and give feedback. Bob is important, Installer too.
So I'm interested in learning how it works here, so that we can at least end up with something as good as this
Scriptloader is not good, it is what we made for making progress. As soon as we have something better we throw it away. Believe me this mainly my code :)
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Oct 11, 2008 at 07:24:16PM +0200, St?phane Ducasse wrote:
for me this is the 15th but I'm cheating :) I want the gifts before :))
Nice. me too. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
participants (3)
-
Matthew Fulmer -
Norbert Hartl -
Stéphane Ducasse