Hi folks, while working on the new debugger, I've come up with some questions... *is there any other implementation for dynamic widgets other that the current one? *right now the toolbar is a static widget, and I would like to have a dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider? Thanks in advance! Cheers, Clari
On Jul 9, 2013, at 11:35 PM, Clara Allende <clari.allende@gmail.com> wrote:
Hi folks, while working on the new debugger, I've come up with some questions...
*is there any other implementation for dynamic widgets other that the current one?
I do not get your question ...
*right now the toolbar is a static widget, and I would like to have a dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider?
It may make sense to dynamically regenerate the toolbar (or at least remove only what needs to be removed, add only what needs to be added). Then you should also think in term of user experience. Having things changing may be disturbing and counter productive :) Ben
Thanks in advance! Cheers, Clari
Hi folks, while working on the new debugger, I've come up with some questions...
*is there any other implementation for dynamic widgets other that the current one?
I do not get your question ...
This is related to my previous question about dynamic spec, if it's possible to define the layout of a widget on the object side.
*right now the toolbar is a static widget, and I would like to have a
dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider?
It may make sense to dynamically regenerate the toolbar (or at least remove only what needs to be removed, add only what needs to be added). Then you should also think in term of user experience. Having things changing may be disturbing and counter productive :)
Right now our use case are post mortem contexts (that do not have a process attached). In there case only few actions make sense. The current debugger sets the toolbar at the creation of the debugger. If the context turns post mortem during debugging the actions should also change. Now the question would be if this is actually possible?
Hello, So in the current spec debugger, the receiver's inspector widget is changed dynamically. Even if it looks like the same because it is always an inspector, it is not the same widget (could be any subclass of EyeInspector depending on receiver's type). So it is possible to change the main debugger spec dynamically object side. To change dynamically you have to do something like: MyClass class>>myDynamicLayout <spec> ^ SpecLayout composed add: #aModel; yourself MyClass>>changeLayoutDynamically self buildWithSpec: #myDynamicLayout. Then you can add: aComposableModel needRebuild: false on some widgets not to rebuild them and to speed up the spec generation. However, as this was too slow to do it for the full debugger (in the case of the receiver inspector), an inspectorWrapper class was made so the debugger has fixed spec and only the inspector wrapper spec changed. Depending on how often you change the toolbar, you may need to do something similar, even if it's a bit overly complex. You can have a look at inspectorWrapper, in Pharo 3.0. (InspectorWrapper>>updateInspectorFrom:) Hope it helped you, 2013/7/10 Andrei Vasile Chis <chisvasileandrei@gmail.com>
Hi folks, while working on the new debugger, I've come up with some questions...
*is there any other implementation for dynamic widgets other that the
current one?
I do not get your question ...
This is related to my previous question about dynamic spec, if it's possible to define the layout of a widget on the object side.
*right now the toolbar is a static widget, and I would like to have a
dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider?
It may make sense to dynamically regenerate the toolbar (or at least remove only what needs to be removed, add only what needs to be added). Then you should also think in term of user experience. Having things changing may be disturbing and counter productive :)
Right now our use case are post mortem contexts (that do not have a process attached). In there case only few actions make sense. The current debugger sets the toolbar at the creation of the debugger. If the context turns post mortem during debugging the actions should also change. Now the question would be if this is actually possible?
2013/7/10 Clément Bera <bera.clement@gmail.com>
Hello,
So in the current spec debugger, the receiver's inspector widget is changed dynamically. Even if it looks like the same because it is always an inspector, it is not the same widget (could be any subclass of EyeInspector depending on receiver's type). So it is possible to change the main debugger spec dynamically object side.
To change dynamically you have to do something like: MyClass class>>myDynamicLayout <spec> ^ SpecLayout composed add: #aModel; yourself MyClass>>changeLayoutDynamically self buildWithSpec: #myDynamicLayout.
Then you can add: aComposableModel needRebuild: false on some widgets not to rebuild them and to speed up the spec generation.
However, as this was too slow to do it for the full debugger (in the case of the receiver inspector), an inspectorWrapper class was made so the debugger has fixed spec and only the inspector wrapper spec changed. Depending on how often you change the toolbar, you may need to do something similar, even if it's a bit overly complex.
Actually Erwan Douaille is doing WidgetAbstractWrapper to solve this problem (I've just learnt that a few minutes ago). You may discuss with him about that.
You can have a look at inspectorWrapper, in Pharo 3.0. (InspectorWrapper>>updateInspectorFrom:)
Hope it helped you,
2013/7/10 Andrei Vasile Chis <chisvasileandrei@gmail.com>
Hi folks, while working on the new debugger, I've come up with some questions...
*is there any other implementation for dynamic widgets other that the
current one?
I do not get your question ...
This is related to my previous question about dynamic spec, if it's possible to define the layout of a widget on the object side.
*right now the toolbar is a static widget, and I would like to have a
dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider?
It may make sense to dynamically regenerate the toolbar (or at least remove only what needs to be removed, add only what needs to be added). Then you should also think in term of user experience. Having things changing may be disturbing and counter productive :)
Right now our use case are post mortem contexts (that do not have a process attached). In there case only few actions make sense. The current debugger sets the toolbar at the creation of the debugger. If the context turns post mortem during debugging the actions should also change. Now the question would be if this is actually possible?
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Great! Thank you guys :) On 11 July 2013 05:17, Andrei Vasile Chis <chisvasileandrei@gmail.com>wrote:
Actually Erwan Douaille is doing WidgetAbstractWrapper to solve this
problem (I've just learnt that a few minutes ago). You may discuss with him about that.
Super. Thanks for all the help and the info
Andrei
Andrei, Clara, What about integrating the new debugger by default now ? I mean the new debugger is now in Pharo 3.0 alpha but the old debugger is still triggered by default, for example when you do Cmd+Maj+d or when you set the setting 'Always open full debugger'. We (Marcus and I) would like to integrate it now by default in Pharo 3.0 alpha, so we have enough time to stabilize it (in case of problems) and we can then remove the old debugger and old inspectors from Pharo. Now I want your point of view: - What do you think about integrating the spec debugger by default next week ? - Is it currently stable enough ? - Should I wait a little more so you can add extra features ? Having Andrei's debugger by default requires that it has the full stack menu ready before the Pharo 3.0 release (next spring), because if not people will blame all the Pharo team. - Are you working on it ? - Will it be ready before the next Pharo release ? If you think you need to improve the debugger before we integrate it by default, for example with Clara's GSoC work, please tell me when it will be ready so we can add it into the Pharo 3.0 integration planning. Then I guess you can add a slice with your improvements in the Pharo bug tracker, and I will add an extra slice with smalltalk tools change so the new debugger will be triggered by default. It would be nice if we can integrate it before the end of september. If you think it is ready, I will set the current version by default next week. It is also possible that I integrate the current version by default next week and then later you do a slice with improvements. :) 2013/7/11 Clara Allende <clari.allende@gmail.com>
Great! Thank you guys :)
On 11 July 2013 05:17, Andrei Vasile Chis <chisvasileandrei@gmail.com>wrote:
Actually Erwan Douaille is doing WidgetAbstractWrapper to solve this
problem (I've just learnt that a few minutes ago). You may discuss with him about that.
Super. Thanks for all the help and the info
Andrei
Hi Clément, On 12 July 2013 13:09, Clément Bera <bera.clement@gmail.com> wrote:
Andrei, Clara,
What about integrating the new debugger by default now ? I mean the new debugger is now in Pharo 3.0 alpha but the old debugger is still triggered by default, for example when you do Cmd+Maj+d or when you set the setting 'Always open full debugger'. We (Marcus and I) would like to integrate it now by default in Pharo 3.0 alpha, so we have enough time to stabilize it (in case of problems) and we can then remove the old debugger and old inspectors from Pharo.
Now I want your point of view: - What do you think about integrating the spec debugger by default next week ? - Is it currently stable enough ? - Should I wait a little more so you can add extra features ?
I've talked with Andrei and we've set a "milestone". By next week, we would like to have done issues 10956 10952 10954 10953 10955 By next week I will have more time, since the semester will be finished.
Having Andrei's debugger by default requires that it has the full stack
menu ready before the Pharo 3.0 release (next spring), because if not people will blame all the Pharo team. - Are you working on it ?
That's what I plan to do next week :) I'm working on it, but not full time.
- Will it be ready before the next Pharo release ?
If you think you need to improve the debugger before we integrate it by default, for example with Clara's GSoC work, please tell me when it will be ready so we can add it into the Pharo 3.0 integration planning. Then I guess you can add a slice with your improvements in the Pharo bug tracker, and I will add an extra slice with smalltalk tools change so the new debugger will be triggered by default. It would be nice if we can integrate it before the end of september.
In any case I will be in case with both Andrei and you (if you don't mind) to get this done... Cheers! Clari
If you think it is ready, I will set the current version by default next week.
It is also possible that I integrate the current version by default next week and then later you do a slice with improvements.
:)
2013/7/11 Clara Allende <clari.allende@gmail.com>
Great! Thank you guys :)
On 11 July 2013 05:17, Andrei Vasile Chis <chisvasileandrei@gmail.com>wrote:
Actually Erwan Douaille is doing WidgetAbstractWrapper to solve this
problem (I've just learnt that a few minutes ago). You may discuss with him about that.
Super. Thanks for all the help and the info
Andrei
Hi Clément, Hi Clara, What about integrating the new debugger by default now ? I mean the new
debugger is now in Pharo 3.0 alpha but the old debugger is still triggered by default, for example when you do Cmd+Maj+d or when you set the setting 'Always open full debugger'. We (Marcus and I) would like to integrate it now by default in Pharo 3.0 alpha, so we have enough time to stabilize it (in case of problems) and we can then remove the old debugger and old inspectors from Pharo.
Now I want your point of view: - What do you think about integrating the spec debugger by default next week ?
In two weeks (22 July) I would visit you in Lille. That would be a good time to integrate.
- Is it currently stable enough ?
All the features that are present at the moment are quite stable.
- Should I wait a little more so you can add extra features ?
I've talked with Andrei and we've set a "milestone". By next week, we would like to have done issues 10956 10952 10954 10953 10955
If at least the first three issues are done, then the new debugger will have most of the necessary features. I'd also help with these and I hope we'll be done by the end of this month.
By next week I will have more time, since the semester will be finished.
Having Andrei's debugger by default requires that it has the full stack
menu ready before the Pharo 3.0 release (next spring), because if not people will blame all the Pharo team. - Are you working on it ?
That's what I plan to do next week :) I'm working on it, but not full time.
- Will it be ready before the next Pharo release ?
If you think you need to improve the debugger before we integrate it by default, for example with Clara's GSoC work, please tell me when it will be ready so we can add it into the Pharo 3.0 integration planning. Then I guess you can add a slice with your improvements in the Pharo bug tracker, and I will add an extra slice with smalltalk tools change so the new debugger will be triggered by default. It would be nice if we can integrate it before the end of september.
We'll surely be able to have all the missing features by the end of September. They do not require so much work.
In any case I will be in case with both Andrei and you (if you don't mind) to get this done...
Please do :)
Cheers, Andrei
Ok, then we will integrate it together when you come to Lille in 2 weeks. Good news. Cheers, 2013/7/12 Andrei Vasile Chis <chisvasileandrei@gmail.com>
Hi Clément, Hi Clara,
What about integrating the new debugger by default now ? I mean the new
debugger is now in Pharo 3.0 alpha but the old debugger is still triggered by default, for example when you do Cmd+Maj+d or when you set the setting 'Always open full debugger'. We (Marcus and I) would like to integrate it now by default in Pharo 3.0 alpha, so we have enough time to stabilize it (in case of problems) and we can then remove the old debugger and old inspectors from Pharo.
Now I want your point of view: - What do you think about integrating the spec debugger by default next week ?
In two weeks (22 July) I would visit you in Lille. That would be a good time to integrate.
- Is it currently stable enough ?
All the features that are present at the moment are quite stable.
- Should I wait a little more so you can add extra features ?
I've talked with Andrei and we've set a "milestone". By next week, we would like to have done issues 10956 10952 10954 10953 10955
If at least the first three issues are done, then the new debugger will have most of the necessary features. I'd also help with these and I hope we'll be done by the end of this month.
By next week I will have more time, since the semester will be finished.
Having Andrei's debugger by default requires that it has the full stack
menu ready before the Pharo 3.0 release (next spring), because if not people will blame all the Pharo team. - Are you working on it ?
That's what I plan to do next week :) I'm working on it, but not full time.
- Will it be ready before the next Pharo release ?
If you think you need to improve the debugger before we integrate it by default, for example with Clara's GSoC work, please tell me when it will be ready so we can add it into the Pharo 3.0 integration planning. Then I guess you can add a slice with your improvements in the Pharo bug tracker, and I will add an extra slice with smalltalk tools change so the new debugger will be triggered by default. It would be nice if we can integrate it before the end of september.
We'll surely be able to have all the missing features by the end of September. They do not require so much work.
In any case I will be in case with both Andrei and you (if you don't mind) to get this done...
Please do :)
Cheers, Andrei
Exciting times :) Doru On Jul 13, 2013, at 8:08 AM, Clément Bera <bera.clement@gmail.com> wrote:
Ok, then we will integrate it together when you come to Lille in 2 weeks.
Good news.
Cheers,
2013/7/12 Andrei Vasile Chis <chisvasileandrei@gmail.com> Hi Clément, Hi Clara,
What about integrating the new debugger by default now ? I mean the new debugger is now in Pharo 3.0 alpha but the old debugger is still triggered by default, for example when you do Cmd+Maj+d or when you set the setting 'Always open full debugger'. We (Marcus and I) would like to integrate it now by default in Pharo 3.0 alpha, so we have enough time to stabilize it (in case of problems) and we can then remove the old debugger and old inspectors from Pharo.
Now I want your point of view: - What do you think about integrating the spec debugger by default next week ?
In two weeks (22 July) I would visit you in Lille. That would be a good time to integrate.
- Is it currently stable enough ?
All the features that are present at the moment are quite stable.
- Should I wait a little more so you can add extra features ?
I've talked with Andrei and we've set a "milestone". By next week, we would like to have done issues 10956 10952 10954 10953 10955
If at least the first three issues are done, then the new debugger will have most of the necessary features. I'd also help with these and I hope we'll be done by the end of this month.
By next week I will have more time, since the semester will be finished.
Having Andrei's debugger by default requires that it has the full stack menu ready before the Pharo 3.0 release (next spring), because if not people will blame all the Pharo team. - Are you working on it ? That's what I plan to do next week :) I'm working on it, but not full time.
- Will it be ready before the next Pharo release ?
If you think you need to improve the debugger before we integrate it by default, for example with Clara's GSoC work, please tell me when it will be ready so we can add it into the Pharo 3.0 integration planning. Then I guess you can add a slice with your improvements in the Pharo bug tracker, and I will add an extra slice with smalltalk tools change so the new debugger will be triggered by default. It would be nice if we can integrate it before the end of september.
We'll surely be able to have all the missing features by the end of September. They do not require so much work.
In any case I will be in case with both Andrei and you (if you don't mind) to get this done...
Please do :)
Cheers, Andrei
-- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."
participants (6)
-
Andrei Vasile Chis -
Benjamin -
Clara Allende -
Clément Bera -
Clément Bera -
Tudor Girba