Re: [Pharo-project] Inclusion of OB-Tools inside Pharo
Stef, One nice thing about the new browser is the RB integration. Given my general aversion to having it rewrite my code (showing no respect at all for the dated comments therein), I'm an unlikely advocate. Still, I use the RB for up/down refactorings (no rewrites needed), and will sometimes turn it loose on new code that has not had time to accumulate comments of value. Others would consider its absence a showstopper. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 12/22/08 7:05 AM >>> I think that we should pay attention of the ratio of effort and number of people participating.
My take would be to not include tools if they are not complete and at the same time may be create a group of people working on an specific issue for the next milestone. In the long run I would like to have less little bug fixes vs main improvements even if the little fixes are important. one of the question is how can we make significant progress as an open source project. Stef On Dec 22, 2008, at 11:30 AM, Michael Roberts wrote:
I'm interested at least in a discussion on the OB debugger. This is because
1) there are definitely some bugs in the core debugger. Is it worth trying to fix them? I think yes, but I'm not sure I have the skills to identify and fix them. I just know from using the core debugger it sure does some strange things. 2) The core debugger is missing features: stack variables, arguments, breakpoints. How hard is it to modify the core one? 3) do we have enough volunteer effort to maintain two debuggers? I'm not sure we do.
I have only briefly used the ob debugger and I got a bit confused with part of the UI so i'll need to look at it some more. What are folks thoughts on this key part of functionality?
Then more generally i'm not sure it makes sense to have different tools in the core vs the dev image. I have to admit to not fully understanding the 1.0 release plan but looking fwds to say 2.0, 3.0 there would be benefit from pushing OB + tools into the core and just maintaining a single high quality set of tools across all variant images?
cheers,
Mike
On Mon, Dec 22, 2008 at 10:00 AM, Damien Cassou <damien.cassou@gmail.com
wrote: On Sun, Dec 21, 2008 at 11:44 PM, Bill Schwab <BSchwab@anest.ufl.edu> wrote:
Sounds good. And in that case (OB Tools at the end of the list), I urge serious attention to having a notifier. Learning from history, and all that.
Hi Bill,
I decided to load OB-Tools (a reimplementation of some tools using the ob framework) inside the pharo-dev images. I put OB-Tools inside the list of packages that will be part of the official Pharo distribution. This was a mistake because no discussion happened about this package at all on this mailing list. I've just moved OB-Tools to the list of pending packages. Now, we have to discuss (in this new thread):
- Do we want an OB-based version of the tools inside Pharo? - Do we want all tools implemented by Lukas or just some of them? - What features are missing? - What are the bugs? - Who maintains this package?
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ 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
Bill, Can you give an example of the kind of comments that RB doesn't respect for you? I've used RB extensively on VW, but not much at all on Squeak yet. It had problems with end of line comments, but didn't do badly with comments on there own line. I adopted to its limitations rather than try to fix it because the benefits were so large and I was too busy/lazy/etc. -david On Mon, Dec 22, 2008 at 8:34 AM, Bill Schwab <BSchwab@anest.ufl.edu> wrote:
Stef,
One nice thing about the new browser is the RB integration. Given my general aversion to having it rewrite my code (showing no respect at all for the dated comments therein), I'm an unlikely advocate. Still, I use the RB for up/down refactorings (no rewrites needed), and will sometimes turn it loose on new code that has not had time to accumulate comments of value. Others would consider its absence a showstopper.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 12/22/08 7:05 AM >>> I think that we should pay attention of the ratio of effort and number of people participating.
My take would be to not include tools if they are not complete and at the same time may be create a group of people working on an specific issue for the next milestone. In the long run I would like to have less little bug fixes vs main improvements even if the little fixes are important. one of the question is how can we make significant progress as an open source project.
Stef
On Dec 22, 2008, at 11:30 AM, Michael Roberts wrote:
I'm interested at least in a discussion on the OB debugger. This is because
1) there are definitely some bugs in the core debugger. Is it worth trying to fix them? I think yes, but I'm not sure I have the skills to identify and fix them. I just know from using the core debugger it sure does some strange things. 2) The core debugger is missing features: stack variables, arguments, breakpoints. How hard is it to modify the core one? 3) do we have enough volunteer effort to maintain two debuggers? I'm not sure we do.
I have only briefly used the ob debugger and I got a bit confused with part of the UI so i'll need to look at it some more. What are folks thoughts on this key part of functionality?
Then more generally i'm not sure it makes sense to have different tools in the core vs the dev image. I have to admit to not fully understanding the 1.0 release plan but looking fwds to say 2.0, 3.0 there would be benefit from pushing OB + tools into the core and just maintaining a single high quality set of tools across all variant images?
cheers,
Mike
On Mon, Dec 22, 2008 at 10:00 AM, Damien Cassou <damien.cassou@gmail.com
wrote: On Sun, Dec 21, 2008 at 11:44 PM, Bill Schwab <BSchwab@anest.ufl.edu> wrote:
Sounds good. And in that case (OB Tools at the end of the list), I urge serious attention to having a notifier. Learning from history, and all that.
Hi Bill,
I decided to load OB-Tools (a reimplementation of some tools using the ob framework) inside the pharo-dev images. I put OB-Tools inside the list of packages that will be part of the official Pharo distribution. This was a mistake because no discussion happened about this package at all on this mailing list. I've just moved OB-Tools to the list of pending packages. Now, we have to discuss (in this new thread):
- Do we want an OB-based version of the tools inside Pharo? - Do we want all tools implemented by Lukas or just some of them? - What features are missing? - What are the bugs? - Who maintains this package?
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ 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
I was not questioning the presence of RB engine Now people can join to help improving. Gwenael is cleaning the parser and scanner for example
Stef,
One nice thing about the new browser is the RB integration. Given my general aversion to having it rewrite my code (showing no respect at all for the dated comments therein), I'm an unlikely advocate. Still, I use the RB for up/down refactorings (no rewrites needed), and will sometimes turn it loose on new code that has not had time to accumulate comments of value. Others would consider its absence a showstopper.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 12/22/08 7:05 AM >>> I think that we should pay attention of the ratio of effort and number of people participating.
My take would be to not include tools if they are not complete and at the same time may be create a group of people working on an specific issue for the next milestone. In the long run I would like to have less little bug fixes vs main improvements even if the little fixes are important. one of the question is how can we make significant progress as an open source project.
Stef
On Dec 22, 2008, at 11:30 AM, Michael Roberts wrote:
I'm interested at least in a discussion on the OB debugger. This is because
1) there are definitely some bugs in the core debugger. Is it worth trying to fix them? I think yes, but I'm not sure I have the skills to identify and fix them. I just know from using the core debugger it sure does some strange things. 2) The core debugger is missing features: stack variables, arguments, breakpoints. How hard is it to modify the core one? 3) do we have enough volunteer effort to maintain two debuggers? I'm not sure we do.
I have only briefly used the ob debugger and I got a bit confused with part of the UI so i'll need to look at it some more. What are folks thoughts on this key part of functionality?
Then more generally i'm not sure it makes sense to have different tools in the core vs the dev image. I have to admit to not fully understanding the 1.0 release plan but looking fwds to say 2.0, 3.0 there would be benefit from pushing OB + tools into the core and just maintaining a single high quality set of tools across all variant images?
cheers,
Mike
On Mon, Dec 22, 2008 at 10:00 AM, Damien Cassou <damien.cassou@gmail.com
wrote: On Sun, Dec 21, 2008 at 11:44 PM, Bill Schwab <BSchwab@anest.ufl.edu> wrote:
Sounds good. And in that case (OB Tools at the end of the list), I urge serious attention to having a notifier. Learning from history, and all that.
Hi Bill,
I decided to load OB-Tools (a reimplementation of some tools using the ob framework) inside the pharo-dev images. I put OB-Tools inside the list of packages that will be part of the official Pharo distribution. This was a mistake because no discussion happened about this package at all on this mailing list. I've just moved OB-Tools to the list of pending packages. Now, we have to discuss (in this new thread):
- Do we want an OB-based version of the tools inside Pharo? - Do we want all tools implemented by Lukas or just some of them? - What features are missing? - What are the bugs? - Who maintains this package?
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ 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
participants (3)
-
Bill Schwab -
David Pennell -
Stéphane Ducasse