Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
[image: Inline image 1]
Let me know if you run into any issues.
Cheers, Andrei
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
On Mon, Nov 30, 2015 at 8:58 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
[image: Inline image 1]
Let me know if you run into any issues.
Cheers, Andrei
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Excellent!
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
On Mon, Nov 30, 2015 at 8:58 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
[image: Inline image 1]
Let me know if you run into any issues.
Cheers, Andrei
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff. Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Cheers, Andrei
On Mon, Nov 30, 2015 at 8:58 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
[image: Inline image 1]
Let me know if you run into any issues.
Cheers, Andrei
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff.
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Cheers,
Cheers, Andrei
On Mon, Nov 30, 2015 at 8:58 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
[image: Inline image 1]
Let me know if you run into any issues.
Cheers, Andrei
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff.
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
[image: Inline image 1]
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
Cheers, Andrei
Cheers,
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck <marianopeck@gmail.com mailto:marianopeck@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis <chisvasileandrei@gmail.com mailto:chisvasileandrei@gmail.com> wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck <marianopeck@gmail.com mailto:marianopeck@gmail.com> wrote: Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff.
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
<debugger.png>
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever we browse a test case object in debugger? Or it could be part of the inspector the same way you did ‘Diff’ tab.
Cheers, Juraj
Cheers, Andrei
Cheers,
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka juraj.kubelka@gmail.com wrote:
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff.
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
<debugger.png>
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever we browse a test case object in debugger? Or it could be part of the inspector the same way you did ‘Diff’ tab.
I think the MAIN point for me is to be able to see the setUp AT THE SAME time with the code of the failing error. If I have to click another tab to see the setup and then another click to go back to see my test, then I gain nothing. Maybe splitting (either vertically or horizontally) the area where now you see the method source (of the selected stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in the below (expected vs current, etc) called "setUp". That way, at least I can see the method and the setUp all together (Ok, I cannot see the expected vs current, but ok)
Cheers, Juraj
Cheers, Andrei
Cheers,
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
I splitted the code pane into two to also show the setUp/tearDown code. A button/checkbox to hide/show this pane could be next.
Cheers, Andrei
On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka juraj.kubelka@gmail.com wrote:
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff.
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
<debugger.png>
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever we browse a test case object in debugger? Or it could be part of the inspector the same way you did ‘Diff’ tab.
I think the MAIN point for me is to be able to see the setUp AT THE SAME time with the code of the failing error. If I have to click another tab to see the setup and then another click to go back to see my test, then I gain nothing. Maybe splitting (either vertically or horizontally) the area where now you see the method source (of the selected stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in the below (expected vs current, etc) called "setUp". That way, at least I can see the method and the setUp all together (Ok, I cannot see the expected vs current, but ok)
Cheers, Juraj
Cheers, Andrei
Cheers,
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
I splitted the code pane into two to also show the setUp/tearDown code. A button/checkbox to hide/show this pane could be next.
Coool!!! Andrei, let me ask, would this work in Pharo 4.0? If true, then I should only load gt debugger or a new version of the whole GT suite ?
Cheers, Andrei
On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka juraj.kubelka@gmail.com wrote:
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis <chisvasileandrei@gmail.com
wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Uhhh that's very cool. Quick question, what happens if the textual representation of the actual vs expected is the same yet the objects are not #= ? It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff.
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
<debugger.png>
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever we browse a test case object in debugger? Or it could be part of the inspector the same way you did ‘Diff’ tab.
I think the MAIN point for me is to be able to see the setUp AT THE SAME time with the code of the failing error. If I have to click another tab to see the setup and then another click to go back to see my test, then I gain nothing. Maybe splitting (either vertically or horizontally) the area where now you see the method source (of the selected stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in the below (expected vs current, etc) called "setUp". That way, at least I can see the method and the setUp all together (Ok, I cannot see the expected vs current, but ok)
Cheers, Juraj
Cheers, Andrei
Cheers,
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
I think it's not straightforward to get it to work in Pharo 4. I'm not sure you can load the latest version of GTools into Pharo 4.
You can load just the packages for GT-Debugger, GT-SUnitDebugger and DebuggerExtensions, however, it would not work by default as there were some changes to the API of the debugger. You'll also need to backport those changes, but that might be more work. If you really want to use it I could make a version that uses the old API.
On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
I splitted the code pane into two to also show the setUp/tearDown code. A button/checkbox to hide/show this pane could be next.
Coool!!! Andrei, let me ask, would this work in Pharo 4.0? If true, then I should only load gt debugger or a new version of the whole GT suite ?
Cheers, Andrei
On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka juraj.kubelka@gmail.com wrote:
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
> Uhhh that's very cool. Quick question, what happens if the textual > representation of the actual vs expected is the same yet the objects are > not #= ? > It shows no diff and then I must go to see the inspector? >
These textual representations can be customized per each object type, however if they are the same now it just shows the diff pane with no differences. Another idea would be to also show two inspectors side-by-side apart from the diff.
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
Then even if you see or not a difference in the textual diff, you could use the inspector to look at differences between the state. Also right now the diff is textual. Adding better diff widgets for specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
<debugger.png>
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever we browse a test case object in debugger? Or it could be part of the inspector the same way you did ‘Diff’ tab.
I think the MAIN point for me is to be able to see the setUp AT THE SAME time with the code of the failing error. If I have to click another tab to see the setup and then another click to go back to see my test, then I gain nothing. Maybe splitting (either vertically or horizontally) the area where now you see the method source (of the selected stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in the below (expected vs current, etc) called "setUp". That way, at least I can see the method and the setUp all together (Ok, I cannot see the expected vs current, but ok)
Cheers, Juraj
Cheers, Andrei
Cheers,
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
I think it's not straightforward to get it to work in Pharo 4. I'm not sure you can load the latest version of GTools into Pharo 4.
That's what I was thinking :(
You can load just the packages for GT-Debugger, GT-SUnitDebugger and DebuggerExtensions, however, it would not work by default as there were some changes to the API of the debugger. You'll also need to backport those changes, but that might be more work. If you really want to use it I could make a version that uses the old API.
I don't want you loose much time if I am the only one wanting this. Personally, for my real client-paying job I won't be able to move to 5.0 until it's released. But then I can wait.
However, I would like to at least give it a quick try to the dirty solution. As you said, maybe loading those 3 packages and bringing some slices (the ones of the debugger api might work). mmmmm but I guess this will break the Spec Debugger right? Unless the slides also updates that.. Do you remember which were the debugger changes?
On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
I splitted the code pane into two to also show the setUp/tearDown code. A button/checkbox to hide/show this pane could be next.
Coool!!! Andrei, let me ask, would this work in Pharo 4.0? If true, then I should only load gt debugger or a new version of the whole GT suite ?
Cheers, Andrei
On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka juraj.kubelka@gmail.com wrote:
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
> > > On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < > marianopeck@gmail.com> wrote: > >> Uhhh that's very cool. Quick question, what happens if the textual >> representation of the actual vs expected is the same yet the objects are >> not #= ? >> It shows no diff and then I must go to see the inspector? >> > > These textual representations can be customized per each object > type, however if they are the same now it just shows the diff pane with no > differences. > Another idea would be to also show two inspectors side-by-side apart > from the diff. >
A side-by-side inspector would be another really cool addition for when the string comparison won't work.
> Then even if you see or not a difference in the textual diff, you > could use the inspector to look at differences between the state. > Also right now the diff is textual. Adding better diff widgets for > specific data types would help. > > Oh yes. But I think that adding a side-by-side inspector would be a great second step in which you know you can always fall back no matter which kind of object.
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
<debugger.png>
BTW...since we are near Christmas... it would be terrific to have a button somewhere to show/hide the #setUp method besides the code representing the piece of stack you clicked. Sometimes when I am debugging test failures that had a setup I always have to open another window with the setup because I don't remember everything I did there and that's useful information to understand what a test could have failed. There was a Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever we browse a test case object in debugger? Or it could be part of the inspector the same way you did ‘Diff’ tab.
I think the MAIN point for me is to be able to see the setUp AT THE SAME time with the code of the failing error. If I have to click another tab to see the setup and then another click to go back to see my test, then I gain nothing. Maybe splitting (either vertically or horizontally) the area where now you see the method source (of the selected stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in the below (expected vs current, etc) called "setUp". That way, at least I can see the method and the setUp all together (Ok, I cannot see the expected vs current, but ok)
Cheers, Juraj
Cheers, Andrei
Cheers,
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
I think it's not straightforward to get it to work in Pharo 4. I'm not sure you can load the latest version of GTools into Pharo 4.
That's what I was thinking :(
You can load just the packages for GT-Debugger, GT-SUnitDebugger and DebuggerExtensions, however, it would not work by default as there were some changes to the API of the debugger. You'll also need to backport those changes, but that might be more work. If you really want to use it I could make a version that uses the old API.
I don't want you loose much time if I am the only one wanting this. Personally, for my real client-paying job I won't be able to move to 5.0 until it's released. But then I can wait.
However, I would like to at least give it a quick try to the dirty solution. As you said, maybe loading those 3 packages and bringing some slices (the ones of the debugger api might work). mmmmm but I guess this will break the Spec Debugger right? Unless the slides also updates that.. Do you remember which were the debugger changes?
There are 4 slices that you need to load I tried loading the first one (https://pharo.fogbugz.com/f/cases/17069) and my image hangs...
I'll see tomorrow if I can make a quick and dirty refactoring to get it to work just for Pharo 4.
On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis <chisvasileandrei@gmail.com
wrote:
I splitted the code pane into two to also show the setUp/tearDown code. A button/checkbox to hide/show this pane could be next.
Coool!!! Andrei, let me ask, would this work in Pharo 4.0? If true, then I should only load gt debugger or a new version of the whole GT suite ?
Cheers, Andrei
On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka <juraj.kubelka@gmail.com
wrote:
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
> > > On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < > chisvasileandrei@gmail.com> wrote: > >> >> >> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < >> marianopeck@gmail.com> wrote: >> >>> Uhhh that's very cool. Quick question, what happens if the textual >>> representation of the actual vs expected is the same yet the objects are >>> not #= ? >>> It shows no diff and then I must go to see the inspector? >>> >> >> These textual representations can be customized per each object >> type, however if they are the same now it just shows the diff pane with no >> differences. >> Another idea would be to also show two inspectors side-by-side >> apart from the diff. >> > > A side-by-side inspector would be another really cool addition for > when the string comparison won't work. > > >> Then even if you see or not a difference in the textual diff, you >> could use the inspector to look at differences between the state. >> Also right now the diff is textual. Adding better diff widgets for >> specific data types would help. >> >> > Oh yes. But I think that adding a side-by-side inspector would be a > great second step in which you know you can always fall back no matter > which kind of object. >
I added two side by side inspectors. I still need to improve/disable navigation in these embedded inspectors
<debugger.png>
> > BTW...since we are near Christmas... it would be terrific to have a > button somewhere to show/hide the #setUp method besides the code > representing the piece of stack you clicked. Sometimes when I am debugging > test failures that had a setup I always have to open another window with > the setup because I don't remember everything I did there and that's useful > information to understand what a test could have failed. There was a > Nautilus plugin for that some time ago. >
Sounds like an useful feature. I'll give a try implementing it. Or if you are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever we browse a test case object in debugger? Or it could be part of the inspector the same way you did ‘Diff’ tab.
I think the MAIN point for me is to be able to see the setUp AT THE SAME time with the code of the failing error. If I have to click another tab to see the setup and then another click to go back to see my test, then I gain nothing. Maybe splitting (either vertically or horizontally) the area where now you see the method source (of the selected stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in the below (expected vs current, etc) called "setUp". That way, at least I can see the method and the setUp all together (Ok, I cannot see the expected vs current, but ok)
Cheers, Juraj
Cheers, Andrei
> > Cheers, > > _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Wed, Dec 2, 2015 at 1:31 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
I think it's not straightforward to get it to work in Pharo 4. I'm not sure you can load the latest version of GTools into Pharo 4.
That's what I was thinking :(
You can load just the packages for GT-Debugger, GT-SUnitDebugger and DebuggerExtensions, however, it would not work by default as there were some changes to the API of the debugger. You'll also need to backport those changes, but that might be more work. If you really want to use it I could make a version that uses the old API.
I don't want you loose much time if I am the only one wanting this. Personally, for my real client-paying job I won't be able to move to 5.0 until it's released. But then I can wait.
However, I would like to at least give it a quick try to the dirty solution. As you said, maybe loading those 3 packages and bringing some slices (the ones of the debugger api might work). mmmmm but I guess this will break the Spec Debugger right? Unless the slides also updates that.. Do you remember which were the debugger changes?
There are 4 slices that you need to load I tried loading the first one (https://pharo.fogbugz.com/f/cases/17069) and my image hangs...
I'll see tomorrow if I can make a quick and dirty refactoring to get it to work just for Pharo 4.
Super !!! Let us know!
On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
I splitted the code pane into two to also show the setUp/tearDown code. A button/checkbox to hide/show this pane could be next.
Coool!!! Andrei, let me ask, would this work in Pharo 4.0? If true, then I should only load gt debugger or a new version of the whole GT suite ?
Cheers, Andrei
On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka < juraj.kubelka@gmail.com> wrote:
> Hi, > > On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com > wrote: > > Hi Mariano > > On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < > marianopeck@gmail.com> wrote: > >> >> >> On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < >> chisvasileandrei@gmail.com> wrote: >> >>> >>> >>> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < >>> marianopeck@gmail.com> wrote: >>> >>>> Uhhh that's very cool. Quick question, what happens if the >>>> textual representation of the actual vs expected is the same yet the >>>> objects are not #= ? >>>> It shows no diff and then I must go to see the inspector? >>>> >>> >>> These textual representations can be customized per each object >>> type, however if they are the same now it just shows the diff pane with no >>> differences. >>> Another idea would be to also show two inspectors side-by-side >>> apart from the diff. >>> >> >> A side-by-side inspector would be another really cool addition for >> when the string comparison won't work. >> >> >>> Then even if you see or not a difference in the textual diff, you >>> could use the inspector to look at differences between the state. >>> Also right now the diff is textual. Adding better diff widgets for >>> specific data types would help. >>> >>> >> Oh yes. But I think that adding a side-by-side inspector would be a >> great second step in which you know you can always fall back no matter >> which kind of object. >> > > I added two side by side inspectors. I still need to improve/disable > navigation in these embedded inspectors > > <debugger.png> > > > >> >> BTW...since we are near Christmas... it would be terrific to have a >> button somewhere to show/hide the #setUp method besides the code >> representing the piece of stack you clicked. Sometimes when I am debugging >> test failures that had a setup I always have to open another window with >> the setup because I don't remember everything I did there and that's useful >> information to understand what a test could have failed. There was a >> Nautilus plugin for that some time ago. >> > > Sounds like an useful feature. I'll give a try implementing it. Or > if you are faster you can give it a try :) > > > I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab > whenever we browse a test case object in debugger? Or it could be part of > the inspector the same way you did ‘Diff’ tab. > > I think the MAIN point for me is to be able to see the setUp AT THE SAME time with the code of the failing error. If I have to click another tab to see the setup and then another click to go back to see my test, then I gain nothing. Maybe splitting (either vertically or horizontally) the area where now you see the method source (of the selected stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in the below (expected vs current, etc) called "setUp". That way, at least I can see the method and the setUp all together (Ok, I cannot see the expected vs current, but ok)
> Cheers, > Juraj > > > Cheers, > Andrei > > >> >> Cheers, >> >> _______________________________________________ > Moose-dev mailing list > Moose-dev@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Mariano,
To get it working in Pharo 4 you should:
- load GT-Debugger-AndreiChis.249 from AndreiChis/GTDebuggerPharo4 - load GT-SUnitDebugger-AndreiChis.18 from AndreiChis/GTDebuggerPharo4 - load DebuggerExtensions-AndreiChis.9 from Pharo/Debugger - register the debuggers: - GTGenericStackDebugger registerExtraToolsOn: Smalltalk tools. - GTSUnitDebugger registerExtraToolsOn: Smalltalk tools
Like this the spec debugger is still the default one and you still have to start GTDebugger from the pre debug window. You can register GTDebugger as the default one (GTGenericStackDebugger registerToolsOn: Smalltalk tools) but it will not switch to the SUnit extension automatically (that only works in Pharo 5). You'll need to switch to it from the context menu of the stack.
Let me know how it goes.
Cheers, Andrei
On Wed, Dec 2, 2015 at 5:37 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Wed, Dec 2, 2015 at 1:31 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
I think it's not straightforward to get it to work in Pharo 4. I'm not sure you can load the latest version of GTools into Pharo 4.
That's what I was thinking :(
You can load just the packages for GT-Debugger, GT-SUnitDebugger and DebuggerExtensions, however, it would not work by default as there were some changes to the API of the debugger. You'll also need to backport those changes, but that might be more work. If you really want to use it I could make a version that uses the old API.
I don't want you loose much time if I am the only one wanting this. Personally, for my real client-paying job I won't be able to move to 5.0 until it's released. But then I can wait.
However, I would like to at least give it a quick try to the dirty solution. As you said, maybe loading those 3 packages and bringing some slices (the ones of the debugger api might work). mmmmm but I guess this will break the Spec Debugger right? Unless the slides also updates that.. Do you remember which were the debugger changes?
There are 4 slices that you need to load I tried loading the first one (https://pharo.fogbugz.com/f/cases/17069) and my image hangs...
I'll see tomorrow if I can make a quick and dirty refactoring to get it to work just for Pharo 4.
Super !!! Let us know!
On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
I splitted the code pane into two to also show the setUp/tearDown code. A button/checkbox to hide/show this pane could be next.
Coool!!! Andrei, let me ask, would this work in Pharo 4.0? If true, then I should only load gt debugger or a new version of the whole GT suite ?
Cheers, Andrei
On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
> > > On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka < > juraj.kubelka@gmail.com> wrote: > >> Hi, >> >> On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com >> wrote: >> >> Hi Mariano >> >> On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < >> marianopeck@gmail.com> wrote: >> >>> >>> >>> On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < >>> chisvasileandrei@gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < >>>> marianopeck@gmail.com> wrote: >>>> >>>>> Uhhh that's very cool. Quick question, what happens if the >>>>> textual representation of the actual vs expected is the same yet the >>>>> objects are not #= ? >>>>> It shows no diff and then I must go to see the inspector? >>>>> >>>> >>>> These textual representations can be customized per each object >>>> type, however if they are the same now it just shows the diff pane with no >>>> differences. >>>> Another idea would be to also show two inspectors side-by-side >>>> apart from the diff. >>>> >>> >>> A side-by-side inspector would be another really cool addition for >>> when the string comparison won't work. >>> >>> >>>> Then even if you see or not a difference in the textual diff, you >>>> could use the inspector to look at differences between the state. >>>> Also right now the diff is textual. Adding better diff widgets >>>> for specific data types would help. >>>> >>>> >>> Oh yes. But I think that adding a side-by-side inspector would be >>> a great second step in which you know you can always fall back no matter >>> which kind of object. >>> >> >> I added two side by side inspectors. I still need to >> improve/disable navigation in these embedded inspectors >> >> <debugger.png> >> >> >> >>> >>> BTW...since we are near Christmas... it would be terrific to have >>> a button somewhere to show/hide the #setUp method besides the code >>> representing the piece of stack you clicked. Sometimes when I am debugging >>> test failures that had a setup I always have to open another window with >>> the setup because I don't remember everything I did there and that's useful >>> information to understand what a test could have failed. There was a >>> Nautilus plugin for that some time ago. >>> >> >> Sounds like an useful feature. I'll give a try implementing it. Or >> if you are faster you can give it a try :) >> >> >> I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab >> whenever we browse a test case object in debugger? Or it could be part of >> the inspector the same way you did ‘Diff’ tab. >> >> > I think the MAIN point for me is to be able to see the setUp AT THE > SAME time with the code of the failing error. If I have to click another > tab to see the setup and then another click to go back to see my test, then > I gain nothing. Maybe splitting (either vertically or horizontally) the > area where now you see the method source (of the selected stack) in order > to also see (fixed) the setUp ? Or .. maybe a new tab in the below > (expected vs current, etc) called "setUp". That way, at least I can see > the method and the setUp all together (Ok, I cannot see the expected vs > current, but ok) > > > >> Cheers, >> Juraj >> >> >> Cheers, >> Andrei >> >> >>> >>> Cheers, >>> >>> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Moose-dev mailing list > Moose-dev@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Thu, Dec 3, 2015 at 1:15 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano,
To get it working in Pharo 4 you should:
- load GT-Debugger-AndreiChis.249 from AndreiChis/GTDebuggerPharo4
- load GT-SUnitDebugger-AndreiChis.18 from AndreiChis/GTDebuggerPharo4
- load DebuggerExtensions-AndreiChis.9 from Pharo/Debugger
- register the debuggers:
- GTGenericStackDebugger registerExtraToolsOn: Smalltalk tools.
- GTSUnitDebugger registerExtraToolsOn: Smalltalk tools
Like this the spec debugger is still the default one and you still have to start GTDebugger from the pre debug window. You can register GTDebugger as the default one (GTGenericStackDebugger registerToolsOn: Smalltalk tools) but it will not switch to the SUnit extension automatically (that only works in Pharo 5). You'll need to switch to it from the context menu of the stack.
Let me know how it goes.
Hi Andrei,
I tried what you said with the following script in a virgin 4.0:
Gofer it smalltalkhubUser: 'AndreiChis' project: 'GTDebuggerPharo4'; version: 'GT-Debugger-AndreiChis.250'; version: 'GT-SUnitDebugger-AndreiChis.19'; load. Gofer it smalltalkhubUser: 'Pharo' project: 'Debugger'; version: 'DebuggerExtensions-AndreiChis.9'; load. (Smalltalk at: #GTGenericStackDebugger) registerExtraToolsOn: Smalltalk tools. (Smalltalk at: #GTSUnitDebugger) registerExtraToolsOn: Smalltalk tools.
However, as soon as I try to debug something I get the following error. It seems I am missing the class GTSUnitActivationPredicate.
UndefinedObject(Object)>>doesNotUnderstand: #new GTSUnitDebugSession class>>activationPredicate GTSUnitDebugger class>>handlesContext: [ :aPair | aPair key handlesContext: aContext ] in PharoCommonTools(ToolRegistry)>>debuggersWithRanksForContext: in Block: [ :aPair | aPair key handlesContext: aContext ] OrderedCollection>>select: PharoCommonTools(ToolRegistry)>>debuggersWithRanksForContext: PharoCommonTools(ToolRegistry)>>debuggerDispatcherFor: GTTemporaryPreDebugChangeDebuggerAction>>executeAction GTTemporaryPreDebugChangeDebuggerAction(DebugAction)>>execute ....
Any idea?
Weird thing is that I am NOT opening a debugger of a SUnit.. but a regular debugger. Maybe the registration part of your script is wrong?
Thanks in advance,
Cheers, Andrei
On Wed, Dec 2, 2015 at 5:37 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 1:31 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis <chisvasileandrei@gmail.com
wrote:
I think it's not straightforward to get it to work in Pharo 4. I'm not sure you can load the latest version of GTools into Pharo 4.
That's what I was thinking :(
You can load just the packages for GT-Debugger, GT-SUnitDebugger and DebuggerExtensions, however, it would not work by default as there were some changes to the API of the debugger. You'll also need to backport those changes, but that might be more work. If you really want to use it I could make a version that uses the old API.
I don't want you loose much time if I am the only one wanting this. Personally, for my real client-paying job I won't be able to move to 5.0 until it's released. But then I can wait.
However, I would like to at least give it a quick try to the dirty solution. As you said, maybe loading those 3 packages and bringing some slices (the ones of the debugger api might work). mmmmm but I guess this will break the Spec Debugger right? Unless the slides also updates that.. Do you remember which were the debugger changes?
There are 4 slices that you need to load I tried loading the first one (https://pharo.fogbugz.com/f/cases/17069) and my image hangs...
I'll see tomorrow if I can make a quick and dirty refactoring to get it to work just for Pharo 4.
Super !!! Let us know!
On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
> I splitted the code pane into two to also show the setUp/tearDown > code. > A button/checkbox to hide/show this pane could be next. > > Coool!!! Andrei, let me ask, would this work in Pharo 4.0? If true, then I should only load gt debugger or a new version of the whole GT suite ?
> Cheers, > Andrei > > On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < > marianopeck@gmail.com> wrote: > >> >> >> On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka < >> juraj.kubelka@gmail.com> wrote: >> >>> Hi, >>> >>> On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com >>> wrote: >>> >>> Hi Mariano >>> >>> On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < >>> marianopeck@gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < >>>> chisvasileandrei@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < >>>>> marianopeck@gmail.com> wrote: >>>>> >>>>>> Uhhh that's very cool. Quick question, what happens if the >>>>>> textual representation of the actual vs expected is the same yet the >>>>>> objects are not #= ? >>>>>> It shows no diff and then I must go to see the inspector? >>>>>> >>>>> >>>>> These textual representations can be customized per each object >>>>> type, however if they are the same now it just shows the diff pane with no >>>>> differences. >>>>> Another idea would be to also show two inspectors side-by-side >>>>> apart from the diff. >>>>> >>>> >>>> A side-by-side inspector would be another really cool addition >>>> for when the string comparison won't work. >>>> >>>> >>>>> Then even if you see or not a difference in the textual diff, >>>>> you could use the inspector to look at differences between the state. >>>>> Also right now the diff is textual. Adding better diff widgets >>>>> for specific data types would help. >>>>> >>>>> >>>> Oh yes. But I think that adding a side-by-side inspector would be >>>> a great second step in which you know you can always fall back no matter >>>> which kind of object. >>>> >>> >>> I added two side by side inspectors. I still need to >>> improve/disable navigation in these embedded inspectors >>> >>> <debugger.png> >>> >>> >>> >>>> >>>> BTW...since we are near Christmas... it would be terrific to have >>>> a button somewhere to show/hide the #setUp method besides the code >>>> representing the piece of stack you clicked. Sometimes when I am debugging >>>> test failures that had a setup I always have to open another window with >>>> the setup because I don't remember everything I did there and that's useful >>>> information to understand what a test could have failed. There was a >>>> Nautilus plugin for that some time ago. >>>> >>> >>> Sounds like an useful feature. I'll give a try implementing it. Or >>> if you are faster you can give it a try :) >>> >>> >>> I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab >>> whenever we browse a test case object in debugger? Or it could be part of >>> the inspector the same way you did ‘Diff’ tab. >>> >>> >> I think the MAIN point for me is to be able to see the setUp AT THE >> SAME time with the code of the failing error. If I have to click another >> tab to see the setup and then another click to go back to see my test, then >> I gain nothing. Maybe splitting (either vertically or horizontally) the >> area where now you see the method source (of the selected stack) in order >> to also see (fixed) the setUp ? Or .. maybe a new tab in the below >> (expected vs current, etc) called "setUp". That way, at least I can see >> the method and the setUp all together (Ok, I cannot see the expected vs >> current, but ok) >> >> >> >>> Cheers, >>> Juraj >>> >>> >>> Cheers, >>> Andrei >>> >>> >>>> >>>> Cheers, >>>> >>>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Ahh. Wrong order for loading packages in my previous instructions. You should load first DebuggerExtensions and then the debuggers.
Cheers, Andrei
On Thu, Dec 3, 2015 at 7:39 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Thu, Dec 3, 2015 at 1:15 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Mariano,
To get it working in Pharo 4 you should:
- load GT-Debugger-AndreiChis.249 from AndreiChis/GTDebuggerPharo4
- load GT-SUnitDebugger-AndreiChis.18 from AndreiChis/GTDebuggerPharo4
- load DebuggerExtensions-AndreiChis.9 from Pharo/Debugger
- register the debuggers:
- GTGenericStackDebugger registerExtraToolsOn: Smalltalk tools.
- GTSUnitDebugger registerExtraToolsOn: Smalltalk tools
Like this the spec debugger is still the default one and you still have to start GTDebugger from the pre debug window. You can register GTDebugger as the default one (GTGenericStackDebugger registerToolsOn: Smalltalk tools) but it will not switch to the SUnit extension automatically (that only works in Pharo 5). You'll need to switch to it from the context menu of the stack.
Let me know how it goes.
Hi Andrei,
I tried what you said with the following script in a virgin 4.0:
Gofer it smalltalkhubUser: 'AndreiChis' project: 'GTDebuggerPharo4'; version: 'GT-Debugger-AndreiChis.250'; version: 'GT-SUnitDebugger-AndreiChis.19'; load. Gofer it smalltalkhubUser: 'Pharo' project: 'Debugger'; version: 'DebuggerExtensions-AndreiChis.9'; load. (Smalltalk at: #GTGenericStackDebugger) registerExtraToolsOn: Smalltalk tools. (Smalltalk at: #GTSUnitDebugger) registerExtraToolsOn: Smalltalk tools.
However, as soon as I try to debug something I get the following error. It seems I am missing the class GTSUnitActivationPredicate.
UndefinedObject(Object)>>doesNotUnderstand: #new GTSUnitDebugSession class>>activationPredicate GTSUnitDebugger class>>handlesContext: [ :aPair | aPair key handlesContext: aContext ] in PharoCommonTools(ToolRegistry)>>debuggersWithRanksForContext: in Block: [ :aPair | aPair key handlesContext: aContext ] OrderedCollection>>select: PharoCommonTools(ToolRegistry)>>debuggersWithRanksForContext: PharoCommonTools(ToolRegistry)>>debuggerDispatcherFor: GTTemporaryPreDebugChangeDebuggerAction>>executeAction GTTemporaryPreDebugChangeDebuggerAction(DebugAction)>>execute ....
Any idea?
Weird thing is that I am NOT opening a debugger of a SUnit.. but a regular debugger. Maybe the registration part of your script is wrong?
Thanks in advance,
Cheers, Andrei
On Wed, Dec 2, 2015 at 5:37 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 1:31 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
I think it's not straightforward to get it to work in Pharo 4. I'm not sure you can load the latest version of GTools into Pharo 4.
That's what I was thinking :(
You can load just the packages for GT-Debugger, GT-SUnitDebugger and DebuggerExtensions, however, it would not work by default as there were some changes to the API of the debugger. You'll also need to backport those changes, but that might be more work. If you really want to use it I could make a version that uses the old API.
I don't want you loose much time if I am the only one wanting this. Personally, for my real client-paying job I won't be able to move to 5.0 until it's released. But then I can wait.
However, I would like to at least give it a quick try to the dirty solution. As you said, maybe loading those 3 packages and bringing some slices (the ones of the debugger api might work). mmmmm but I guess this will break the Spec Debugger right? Unless the slides also updates that.. Do you remember which were the debugger changes?
There are 4 slices that you need to load I tried loading the first one (https://pharo.fogbugz.com/f/cases/17069) and my image hangs...
I'll see tomorrow if I can make a quick and dirty refactoring to get it to work just for Pharo 4.
Super !!! Let us know!
On Wed, Dec 2, 2015 at 4:07 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
> > > On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis < > chisvasileandrei@gmail.com> wrote: > >> I splitted the code pane into two to also show the setUp/tearDown >> code. >> A button/checkbox to hide/show this pane could be next. >> >> > Coool!!! > Andrei, let me ask, would this work in Pharo 4.0? If true, then I > should only load gt debugger or a new version of the whole GT suite ? > > > > >> Cheers, >> Andrei >> >> On Wed, Dec 2, 2015 at 1:09 PM, Mariano Martinez Peck < >> marianopeck@gmail.com> wrote: >> >>> >>> >>> On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka < >>> juraj.kubelka@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> On Dec 1, 2015, at 17:47, Andrei Chis chisvasileandrei@gmail.com >>>> wrote: >>>> >>>> Hi Mariano >>>> >>>> On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < >>>> marianopeck@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < >>>>> chisvasileandrei@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < >>>>>> marianopeck@gmail.com> wrote: >>>>>> >>>>>>> Uhhh that's very cool. Quick question, what happens if the >>>>>>> textual representation of the actual vs expected is the same yet the >>>>>>> objects are not #= ? >>>>>>> It shows no diff and then I must go to see the inspector? >>>>>>> >>>>>> >>>>>> These textual representations can be customized per each object >>>>>> type, however if they are the same now it just shows the diff pane with no >>>>>> differences. >>>>>> Another idea would be to also show two inspectors side-by-side >>>>>> apart from the diff. >>>>>> >>>>> >>>>> A side-by-side inspector would be another really cool addition >>>>> for when the string comparison won't work. >>>>> >>>>> >>>>>> Then even if you see or not a difference in the textual diff, >>>>>> you could use the inspector to look at differences between the state. >>>>>> Also right now the diff is textual. Adding better diff widgets >>>>>> for specific data types would help. >>>>>> >>>>>> >>>>> Oh yes. But I think that adding a side-by-side inspector would >>>>> be a great second step in which you know you can always fall back no matter >>>>> which kind of object. >>>>> >>>> >>>> I added two side by side inspectors. I still need to >>>> improve/disable navigation in these embedded inspectors >>>> >>>> <debugger.png> >>>> >>>> >>>> >>>>> >>>>> BTW...since we are near Christmas... it would be terrific to >>>>> have a button somewhere to show/hide the #setUp method besides the code >>>>> representing the piece of stack you clicked. Sometimes when I am debugging >>>>> test failures that had a setup I always have to open another window with >>>>> the setup because I don't remember everything I did there and that's useful >>>>> information to understand what a test could have failed. There was a >>>>> Nautilus plugin for that some time ago. >>>>> >>>> >>>> Sounds like an useful feature. I'll give a try implementing it. >>>> Or if you are faster you can give it a try :) >>>> >>>> >>>> I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab >>>> whenever we browse a test case object in debugger? Or it could be part of >>>> the inspector the same way you did ‘Diff’ tab. >>>> >>>> >>> I think the MAIN point for me is to be able to see the setUp AT >>> THE SAME time with the code of the failing error. If I have to click >>> another tab to see the setup and then another click to go back to see my >>> test, then I gain nothing. Maybe splitting (either vertically or >>> horizontally) the area where now you see the method source (of the selected >>> stack) in order to also see (fixed) the setUp ? Or .. maybe a new tab in >>> the below (expected vs current, etc) called "setUp". That way, at least I >>> can see the method and the setUp all together (Ok, I cannot see the >>> expected vs current, but ok) >>> >>> >>> >>>> Cheers, >>>> Juraj >>>> >>>> >>>> Cheers, >>>> Andrei >>>> >>>> >>>>> >>>>> Cheers, >>>>> >>>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Moose-dev mailing list > Moose-dev@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Beautiful !
On 01 Dec 2015, at 00:58, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
<Diff.png>
Let me know if you run into any issues.
Cheers, Andrei _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Great. You just ruined my demo :))
The demo was to first show people how it does not work with a default debugger, and then switch to the SUnit one :).
Doru
On Dec 1, 2015, at 12:58 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
<Diff.png>
Let me know if you run into any issues.
Cheers, Andrei _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
On Tue, Dec 1, 2015 at 9:43 AM, Tudor Girba tudor@tudorgirba.com wrote:
Great. You just ruined my demo :))
:)) For a demo you can easily disable this behaviour. Make GTSUnitDebugger class>>#availableAutomatically return false.
The demo was to first show people how it does not work with a default debugger, and then switch to the SUnit one :).
The issue is few people are aware this extension exists. This way it's a bit more easy to discover and get feedback :)
Cheers, Andrei
Doru
On Dec 1, 2015, at 12:58 AM, Andrei Chis chisvasileandrei@gmail.com
wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when
an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector:
#testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner.
The context from where #assert:equals: was called is also automatically
selected.
<Diff.png>
Let me know if you run into any issues.
Cheers, Andrei _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
On Dec 1, 2015, at 10:12 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Dec 1, 2015 at 9:43 AM, Tudor Girba tudor@tudorgirba.com wrote: Great. You just ruined my demo :))
:)) For a demo you can easily disable this behaviour. Make GTSUnitDebugger class>>#availableAutomatically return false.
Yes, I know :)
The demo was to first show people how it does not work with a default debugger, and then switch to the SUnit one :).
The issue is few people are aware this extension exists. This way it's a bit more easy to discover and get feedback :)
Sure! This is a great addition and we should get more aggressive with these extensions.
Cheers, Doru
Cheers, Andrei
Doru
On Dec 1, 2015, at 12:58 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi,
I updated GTDebugger to automatically show a diff in the debugger when an #assert:equals: fails.
For example if you execute '(GTSUnitExampleFailingTest selector: #testMultiValuedStreaming) debug.' you get the debugger below. Also works when running tests from Nautilus/TestRunner. The context from where #assert:equals: was called is also automatically selected.
<Diff.png>
Let me know if you run into any issues.
Cheers, Andrei _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
This is really cool!!!
good job!
Alexandre
-
Alexandre Bergel -
Andrei Chis -
Juraj Kubelka -
Mariano Martinez Peck -
Peter Uhnák -
Sven Van Caekenberghe -
Tudor Girba