[Pharo-project] Using software engineering practices and tools
Hi guys I had this draft in my drafts for some weeks now and I would like to share that with you. I'm really convinced that we could do a better job to build better tools and process to bring our software to the next level. I would like to have share with you some thoughts and analysis and also request for ideas and code of course :) - Bug tracking we are doing that but can we dream - would be nice to have the stack/image and that we could get back in the bug - scripting code.google.com would be nice too - to publish code - to manipulate script bug entries (any taker of that) - Integration server: we are getting there and I thank all the hudson experimentations. - we should get more of that. - Package Management: Metacello - I would like to have Pharo1.0 certified metacello configs. the ideas is that people can publish in a repositories the configs that they know are working for 1.0, then in another for 1.1.... -> once we have configurations + integration server we should burn servers running and testing -> what/how do we manage results - I would like to manage pharo (core + maintained packages with metacello) as well as pharo-dev - Profiling We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned Now it would be good to have better way to profile applications something like .... :) http://www.bootchart.org/images/bootchart.png - Documentation I hope to get some students to produce a way to script UMLish class diagrams that could be displayed at the level of a package. Package level doc Package class comments overview browser. I think that this is really important to get nice comments, nice instance variables, nice temporary variables. Now we should find a way to make sure that comments are well in sight. Any idea / code? - SmallLint Better UI and process using SmallLint Would be nice to have a sanity package checking process. Will probably come one of these days - Better Unit Test support We should look at Adrian fixes and enhancements Better reporting of tests - Better merging tools Seeing the impact of a delta between two versions on the image for example on that topic From VW mailing-list "1. Please make the engine highly configurable and disjoint from the UI. 2. Please make the UI itself pluggable, extensible, augmentable, etc. 3. To support automated merges, please allow rules for handling unresolved conflicts." I'm sure that there is more. We should get to the next level ;)
nice list! Adrian On Feb 16, 2010, at 14:16 , Stéphane Ducasse wrote:
Hi guys
I had this draft in my drafts for some weeks now and I would like to share that with you.
I'm really convinced that we could do a better job to build better tools and process to bring our software to the next level. I would like to have share with you some thoughts and analysis and also request for ideas and code of course :)
- Bug tracking we are doing that but can we dream - would be nice to have the stack/image and that we could get back in the bug - scripting code.google.com would be nice too - to publish code - to manipulate script bug entries (any taker of that)
- Integration server: we are getting there and I thank all the hudson experimentations. - we should get more of that.
- Package Management: Metacello - I would like to have Pharo1.0 certified metacello configs. the ideas is that people can publish in a repositories the configs that they know are working for 1.0, then in another for 1.1.... -> once we have configurations + integration server we should burn servers running and testing -> what/how do we manage results
- I would like to manage pharo (core + maintained packages with metacello) as well as pharo-dev
- Profiling We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned Now it would be good to have better way to profile applications something like .... :) http://www.bootchart.org/images/bootchart.png
- Documentation I hope to get some students to produce a way to script UMLish class diagrams that could be displayed at the level of a package.
Package level doc Package class comments overview browser. I think that this is really important to get nice comments, nice instance variables, nice temporary variables. Now we should find a way to make sure that comments are well in sight. Any idea / code?
- SmallLint Better UI and process using SmallLint Would be nice to have a sanity package checking process. Will probably come one of these days
- Better Unit Test support We should look at Adrian fixes and enhancements Better reporting of tests
- Better merging tools Seeing the impact of a delta between two versions on the image for example on that topic From VW mailing-list "1. Please make the engine highly configurable and disjoint from the UI. 2. Please make the UI itself pluggable, extensible, augmentable, etc. 3. To support automated merges, please allow rules for handling unresolved conflicts."
I'm sure that there is more. We should get to the next level ;)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I would have preferred to send code with it too. But at least this is a vision :) On Feb 16, 2010, at 3:09 PM, Adrian Lienhard wrote:
nice list! Adrian
On Feb 16, 2010, at 14:16 , Stéphane Ducasse wrote:
Hi guys
I had this draft in my drafts for some weeks now and I would like to share that with you.
I'm really convinced that we could do a better job to build better tools and process to bring our software to the next level. I would like to have share with you some thoughts and analysis and also request for ideas and code of course :)
- Bug tracking we are doing that but can we dream - would be nice to have the stack/image and that we could get back in the bug - scripting code.google.com would be nice too - to publish code - to manipulate script bug entries (any taker of that)
- Integration server: we are getting there and I thank all the hudson experimentations. - we should get more of that.
- Package Management: Metacello - I would like to have Pharo1.0 certified metacello configs. the ideas is that people can publish in a repositories the configs that they know are working for 1.0, then in another for 1.1.... -> once we have configurations + integration server we should burn servers running and testing -> what/how do we manage results
- I would like to manage pharo (core + maintained packages with metacello) as well as pharo-dev
- Profiling We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned Now it would be good to have better way to profile applications something like .... :) http://www.bootchart.org/images/bootchart.png
- Documentation I hope to get some students to produce a way to script UMLish class diagrams that could be displayed at the level of a package.
Package level doc Package class comments overview browser. I think that this is really important to get nice comments, nice instance variables, nice temporary variables. Now we should find a way to make sure that comments are well in sight. Any idea / code?
- SmallLint Better UI and process using SmallLint Would be nice to have a sanity package checking process. Will probably come one of these days
- Better Unit Test support We should look at Adrian fixes and enhancements Better reporting of tests
- Better merging tools Seeing the impact of a delta between two versions on the image for example on that topic From VW mailing-list "1. Please make the engine highly configurable and disjoint from the UI. 2. Please make the UI itself pluggable, extensible, augmentable, etc. 3. To support automated merges, please allow rules for handling unresolved conflicts."
I'm sure that there is more. We should get to the next level ;)
_______________________________________________ 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
- Integration server any more thoughts on hardware ? -Bug tracking i'm pretty sure we can edit the issues via SVN. I think we would need https support for the svn client that was written for squeak, or do it via cmd line / OSProcess. -to publish code on code.google.com what is your vision? we could push out 'Metacello definitions' (whatever that would look like) via SVN but we would have a dependency on the SVN client. we could also push the update stream out in SVN as well. whilst we are on the subject of visions a comment Lukas made about git style forking of repositories / pushing changes upstream was really interesting. what would happen if we had a tree of maintainers who each are responsible for parts of the system with their own MC repos, and change works its way up the tree in a controlled manner. I wondered if that would scale over the longer term rather than the single inbox model we have at the moment? especially as we want to break the image into more & more packages... what do you think? it is just an idle thought at the moment. cheers, Mike
- Integration server any more thoughts on hardware ?
I do not know. I will check with Moose people to know their hudson setup.
-Bug tracking i'm pretty sure we can edit the issues via SVN. I think we would need https support for the svn client that was written for squeak, or do it via cmd line / OSProcess.
I do not know if the google api require svn to script it.
-to publish code on code.google.com what is your vision? we could push out 'Metacello definitions' (whatever that would look like) via SVN but we would have a dependency on the SVN client. we could also push the update stream out in SVN as well.
Why on code.google.com? For me metacello on squeaksource or something like that is ok.
whilst we are on the subject of visions a comment Lukas made about git style forking of repositories / pushing changes upstream was really interesting. what would happen if we had a tree of maintainers who each are responsible for parts of the system with their own MC repos, and change works its way up the tree in a controlled manner. I wondered if that would scale over the longer term rather than the single inbox model we have at the moment? especially as we want to break the image into more & more packages... what do you think? it is just an idle thought at the moment.
the problem is with crosscutting changes and their synchronisation. It can only work if the maintainer are pulling merging actively.
I do not know if the google api require svn to script it.
i don't really understand what you want to do. can you outline an example?
Why on code.google.com? only because you mentioned it....
For me metacello on squeaksource or something like that is ok.
sure, i would say it was better to be honest. code.google souce-code mgmt appears very file based.
the problem is with crosscutting changes and their synchronisation. It can only work if the maintainer are pulling merging actively.
yes, agreed. cheers, Mike
I do not know if the google api require svn to script it.
i don't really understand what you want to do. can you outline an example?
Ok I was unclear. the code.google.... web site can be scripted so we could close bug from pharo instead of manually doing it.
Why on code.google.com? only because you mentioned it....
For me metacello on squeaksource or something like that is ok.
sure, i would say it was better to be honest. code.google souce-code mgmt appears very file based.
the problem is with crosscutting changes and their synchronisation. It can only work if the maintainer are pulling merging actively.
yes, agreed.
cheers, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- Integration server any more thoughts on hardware ?
I do not know. I will check with Moose people to know their hudson setup.
They use the setup described here: http://github.com/renggli/builder
-Bug tracking i'm pretty sure we can edit the issues via SVN. I think we would need https support for the svn client that was written for squeak, or do it via cmd line / OSProcess.
I do not know if the google api require svn to script it.
http://code.google.com/p/support/wiki/IssueTrackerAPI Lukas -- Lukas Renggli http://www.lukas-renggli.ch
They use the setup described here:
yes, it was a question about community hardware though.
thanks, i had not seen that... Mike
Hi, On 16 Feb 2010, at 19:43, Michael Roberts wrote:
They use the setup described here:
yes, it was a question about community hardware though.
For Moose, we are using my remote virtual server rented from www.hosteurope.de with a Ubuntu installation on it. In my case, the configuration is listed here: http://www.hosteurope.de/produkt/Virtual-Server-Linux-XL I think that Lukas uses a Debian on a home machine. Cheers, Doru
thanks, i had not seen that...
Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Sometimes the best solution is not the best solution."
- Profiling We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned Now it would be good to have better way to profile applications something like .... :) http://www.bootchart.org/images/bootchart.png
I am currently working on a new profiler for Pharo. I am looking for beta tester (http://article.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/20638/match=s... ) Now that I am back from holidays, I will put more work on this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
So does this use the microsecond clock? On 2010-02-16, at 11:49 AM, Alexandre Bergel wrote:
- Profiling We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned Now it would be good to have better way to profile applications something like .... :) http://www.bootchart.org/images/bootchart.png
I am currently working on a new profiler for Pharo. I am looking for beta tester (http://article.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/20638/match=s... )
Now that I am back from holidays, I will put more work on this.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Hi John, Maybe I did not follow closely, but in an email dated "21 January 2010 02:25:58 GMT-03:00" you asked me whether I want the primitive for both 32 and 64 bits. I replied ("21 January 2010 07:20:23 GMT-03:00") that I tried with the image 64bitImage*64bitVM. Did I miss something? Is the primitive now part of the VM? I gained some experience with MessageTally, writing some Unit test is on my todo list. I could also give a try to enhance it to have a finer sampling grain. Cheers, Alexandre On 16 Feb 2010, at 17:07, John M McIntosh wrote:
So does this use the microsecond clock?
On 2010-02-16, at 11:49 AM, Alexandre Bergel wrote:
- Profiling We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned Now it would be good to have better way to profile applications something like .... :) http://www.bootchart.org/images/ bootchart.png
I am currently working on a new profiler for Pharo. I am looking for beta tester (http://article.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/20638/match=s... )
Now that I am back from holidays, I will put more work on this.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (8)
-
Adrian Lienhard -
Alexandre Bergel -
John M McIntosh -
Lukas Renggli -
Michael Roberts -
Stéphane Ducasse -
Stéphane Ducasse
-
Tudor Girba