Fwd: On the OTDebugger...

> From: Dale Henrichs <[hidden email]>
> Date: March 3, 2009 6:57:36 PM CEST
> To: [hidden email]
> Subject: On the OTDebugger...
> Reply-To: [hidden email]
>
> Steph,
>
> This note isn't about your 'disable OB-debugger for now message',  
> but it is a response, of sorts to the ensuing discussion.
>
> If you want a '120% debugger' then folks working on Pharo need to  
> use the debugger and eat their own dogfood. It's the only way to  
> ensure that a tool like the debugger gets enough coverage to ensure  
> that it is stable. With that said, I wouldn't want to commit to  
> using a tool that was broken or that I couldn't depend upon.
>
> With that in mind, I am willing to commit to the following things:
>
> 1. fix any bugs or implement any features that are deemed as show  
> stoppers with the current OTDebugger - i.e., the things that are  
> preventing folks from getting work done today.
>
> 2. I also promise a quick response to any show stopper bugs that  
> folks come across while doing development with the OTDebugger (or  
> any other of the OB-Tools).
>
> I came to maintain the OB-Tools through the 'back door'. I use a  
> branch the OB-Tools in GLASS and have decided to maintain the OB-
> Tools for the Squeak/Pharo community as a way to contribute back to  
> the community. What that means specifically is that next to Lukas, I  
> probably know more about the OB-Tools than anyone else, however, I  
> don't have a laundry list of features that need to be added to the  
> debugger.
>
> I could go through the Squeak debugger and duplicate all of the  
> 'missing features', but my personal sense is that some of those  
> features aren't useful - I know that I have not even read all of the  
> menu items in the old Squeak debugger, let alone tried to figure out  
> what they do...
>
> Getting a list of important/missing features from a small group is  
> important to me (at least at the start). I don't have a personal  
> sense of "what's missing" from the current OTDebugger, since I have  
> not used the old Squeak debugger extensively. So getting feedback  
> from "old hands" is important, but I also know that I won't be able  
> to respond correctly to a general query for "what's missing from the  
> debugger?"
>
> For direction towards the "120% debugger", I think it makes sense  
> that you and rest of the Pharo leadership team make a list of  
> "debugger franchise features" - i.e., a list of features that are a  
> must have for the Pharo debugger and the other OB-Tools as well  
> (BTW, if that list is to "duplicate all of the 'missing features'"  
> then that's fine and I'm willing to do it).
>
> The debugger along with browsers are the face of the development  
> environment and I don't want to bloat the debugger without at least  
> a second opinion and I trust the opinions of you and the rest of the  
> Pharo leadership team.
>
> Thanks,
>
> Dale
>

> So we should proceed that way:
> - Put a big warning + the expression to switch debugger in the pharo-
> dev
> - then we follow what dale is saying
> - I will produce a list of important features we need to have
> -- copy stack
> -- chase pointer
> ... in OT
>
> Is is ok for your community?
>
> Stef
>
>
> Begin forwarded message:
>
>> From: Dale Henrichs <[hidden email]>
>> Date: March 3, 2009 6:57:36 PM CEST
>> To: [hidden email]
>> Subject: On the OTDebugger...
>> Reply-To: [hidden email]
>>
>> Steph,
>>
>> This note isn't about your 'disable OB-debugger for now message',
>> but it is a response, of sorts to the ensuing discussion.
>>
>> If you want a '120% debugger' then folks working on Pharo need to
>> use the debugger and eat their own dogfood. It's the only way to
>> ensure that a tool like the debugger gets enough coverage to ensure
>> that it is stable. With that said, I wouldn't want to commit to
>> using a tool that was broken or that I couldn't depend upon.
>>
>> With that in mind, I am willing to commit to the following things:
>>
>> 1. fix any bugs or implement any features that are deemed as show
>> stoppers with the current OTDebugger - i.e., the things that are
>> preventing folks from getting work done today.
>>
>> 2. I also promise a quick response to any show stopper bugs that
>> folks come across while doing development with the OTDebugger (or
>> any other of the OB-Tools).
>>
>> I came to maintain the OB-Tools through the 'back door'. I use a
>> branch the OB-Tools in GLASS and have decided to maintain the OB-
>> Tools for the Squeak/Pharo community as a way to contribute back to
>> the community. What that means specifically is that next to Lukas, I
>> probably know more about the OB-Tools than anyone else, however, I
>> don't have a laundry list of features that need to be added to the
>> debugger.
>>
>> I could go through the Squeak debugger and duplicate all of the
>> 'missing features', but my personal sense is that some of those
>> features aren't useful - I know that I have not even read all of the
>> menu items in the old Squeak debugger, let alone tried to figure out
>> what they do...
>>
>> Getting a list of important/missing features from a small group is
>> important to me (at least at the start). I don't have a personal
>> sense of "what's missing" from the current OTDebugger, since I have
>> not used the old Squeak debugger extensively. So getting feedback
>> from "old hands" is important, but I also know that I won't be able
>> to respond correctly to a general query for "what's missing from the
>> debugger?"
>>
>> For direction towards the "120% debugger", I think it makes sense
>> that you and rest of the Pharo leadership team make a list of
>> "debugger franchise features" - i.e., a list of features that are a
>> must have for the Pharo debugger and the other OB-Tools as well
>> (BTW, if that list is to "duplicate all of the 'missing features'"
>> then that's fine and I'm willing to do it).
>>
>> The debugger along with browsers are the face of the development
>> environment and I don't want to bloat the debugger without at least
>> a second opinion and I trust the opinions of you and the rest of the
>> Pharo leadership team.
>>
>> Thanks,
>>
>> Dale
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Ok for me.
>
> Cheers,
> Alexandre
>
>
> On 4 Mar 2009, at 10:30, Stéphane Ducasse wrote:
>
>> So we should proceed that way:
>>       - Put a big warning + the expression to switch debugger in the pharo-
>> dev
>>       - then we follow what dale is saying
>>               - I will produce a list of important features we need to have
>>                       -- copy stack
>>                       -- chase pointer
>>                       ... in OT
>>
>> Is is ok for your community?
>>
>> Stef
>>
>>
>> Begin forwarded message:
>>
>>> From: Dale Henrichs <[hidden email]>
>>> Date: March 3, 2009 6:57:36 PM CEST
>>> To: [hidden email]
>>> Subject: On the OTDebugger...
>>> Reply-To: [hidden email]
>>>
>>> Steph,
>>>
>>> This note isn't about your 'disable OB-debugger for now message',
>>> but it is a response, of sorts to the ensuing discussion.
>>>
>>> If you want a '120% debugger' then folks working on Pharo need to
>>> use the debugger and eat their own dogfood. It's the only way to
>>> ensure that a tool like the debugger gets enough coverage to ensure
>>> that it is stable. With that said, I wouldn't want to commit to
>>> using a tool that was broken or that I couldn't depend upon.
>>>
>>> With that in mind, I am willing to commit to the following things:
>>>
>>> 1. fix any bugs or implement any features that are deemed as show
>>> stoppers with the current OTDebugger - i.e., the things that are
>>> preventing folks from getting work done today.
>>>
>>> 2. I also promise a quick response to any show stopper bugs that
>>> folks come across while doing development with the OTDebugger (or
>>> any other of the OB-Tools).
>>>
>>> I came to maintain the OB-Tools through the 'back door'. I use a
>>> branch the OB-Tools in GLASS and have decided to maintain the OB-
>>> Tools for the Squeak/Pharo community as a way to contribute back to
>>> the community. What that means specifically is that next to Lukas, I
>>> probably know more about the OB-Tools than anyone else, however, I
>>> don't have a laundry list of features that need to be added to the
>>> debugger.
>>>
>>> I could go through the Squeak debugger and duplicate all of the
>>> 'missing features', but my personal sense is that some of those
>>> features aren't useful - I know that I have not even read all of the
>>> menu items in the old Squeak debugger, let alone tried to figure out
>>> what they do...
>>>
>>> Getting a list of important/missing features from a small group is
>>> important to me (at least at the start). I don't have a personal
>>> sense of "what's missing" from the current OTDebugger, since I have
>>> not used the old Squeak debugger extensively. So getting feedback
>>> from "old hands" is important, but I also know that I won't be able
>>> to respond correctly to a general query for "what's missing from the
>>> debugger?"
>>>
>>> For direction towards the "120% debugger", I think it makes sense
>>> that you and rest of the Pharo leadership team make a list of
>>> "debugger franchise features" - i.e., a list of features that are a
>>> must have for the Pharo debugger and the other OB-Tools as well
>>> (BTW, if that list is to "duplicate all of the 'missing features'"
>>> then that's fine and I'm willing to do it).
>>>
>>> The debugger along with browsers are the face of the development
>>> environment and I don't want to bloat the debugger without at least
>>> a second opinion and I trust the opinions of you and the rest of the
>>> Pharo leadership team.
>>>
>>> Thanks,
>>>
>>> Dale
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Is is ok for your community?
>
> Stef
>
>
> Begin forwarded message:
>
>> From: Dale Henrichs <[hidden email]>
>> Date: March 3, 2009 6:57:36 PM CEST
>> To: [hidden email]
>> Subject: On the OTDebugger...
>> Reply-To: [hidden email]
>>
>> Steph,
>>
>> This note isn't about your 'disable OB-debugger for now message',
>> but it is a response, of sorts to the ensuing discussion.
>>
>> If you want a '120% debugger' then folks working on Pharo need to
>> use the debugger and eat their own dogfood. It's the only way to
>> ensure that a tool like the debugger gets enough coverage to ensure
>> that it is stable. With that said, I wouldn't want to commit to
>> using a tool that was broken or that I couldn't depend upon.
>>
>> With that in mind, I am willing to commit to the following things:
>>
>> 1. fix any bugs or implement any features that are deemed as show
>> stoppers with the current OTDebugger - i.e., the things that are
>> preventing folks from getting work done today.
>>
>> 2. I also promise a quick response to any show stopper bugs that
>> folks come across while doing development with the OTDebugger (or
>> any other of the OB-Tools).
>>
>> I came to maintain the OB-Tools through the 'back door'. I use a
>> branch the OB-Tools in GLASS and have decided to maintain the OB-
>> Tools for the Squeak/Pharo community as a way to contribute back to
>> the community. What that means specifically is that next to Lukas, I
>> probably know more about the OB-Tools than anyone else, however, I
>> don't have a laundry list of features that need to be added to the
>> debugger.
>>
>> I could go through the Squeak debugger and duplicate all of the
>> 'missing features', but my personal sense is that some of those
>> features aren't useful - I know that I have not even read all of the
>> menu items in the old Squeak debugger, let alone tried to figure out
>> what they do...
>>
>> Getting a list of important/missing features from a small group is
>> important to me (at least at the start). I don't have a personal
>> sense of "what's missing" from the current OTDebugger, since I have
>> not used the old Squeak debugger extensively. So getting feedback
>> from "old hands" is important, but I also know that I won't be able
>> to respond correctly to a general query for "what's missing from the
>> debugger?"
>>
>> For direction towards the "120% debugger", I think it makes sense
>> that you and rest of the Pharo leadership team make a list of
>> "debugger franchise features" - i.e., a list of features that are a
>> must have for the Pharo debugger and the other OB-Tools as well
>> (BTW, if that list is to "duplicate all of the 'missing features'"
>> then that's fine and I'm willing to do it).
>>
>> The debugger along with browsers are the face of the development
>> environment and I don't want to bloat the debugger without at least
>> a second opinion and I trust the opinions of you and the rest of the
>> Pharo leadership team.
>>
>> Thanks,
>>
>> Dale
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> ----- "Stéphane Ducasse" <[hidden email]> wrote:
>
> | So we should proceed that way:
> | - Put a big warning + the expression to switch debugger in the  
> pharo-
> |
> | dev
> | - then we follow what dale is saying
> | - I will produce a list of important features we need to have
> | -- copy stack
> | -- chase pointer
> | ... in OT
>
> For 'copy stack', check out 'error report' in OB-Tools-dkh.65. Part  
> of the error report is a stack dump ... I could change the name and/
> or produce only a stack.
>
> Dale
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>