Cheers,
Andrei
On Wed, Dec 2, 2015 at 5:37 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
On Wed, Dec 2, 2015 at 1:31 PM, Andrei Chis <chisvasileandrei(a)gmail.com
> wrote:
>
>
> On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck <
> marianopeck(a)gmail.com> wrote:
>
>>
>>
>> On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis <
>> chisvasileandrei(a)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(a)gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis <
>>>> chisvasileandrei(a)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(a)gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka <
>>>>>> juraj.kubelka(a)gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Dec 1, 2015, at 17:47, Andrei Chis <
>>>>>>> chisvasileandrei(a)gmail.com> wrote:
>>>>>>>
>>>>>>> Hi Mariano
>>>>>>>
>>>>>>> On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck <
>>>>>>> marianopeck(a)gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis <
>>>>>>>> chisvasileandrei(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck
<
>>>>>>>>> marianopeck(a)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(a)list.inf.unibe.ch
>>>>>>>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mariano
>>>>>>
http://marianopeck.wordpress.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mariano
>>>>
http://marianopeck.wordpress.com
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)list.inf.unibe.ch
>>>>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)list.inf.unibe.ch
>>>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>>
>>
>>
>> --
>> Mariano
>>
http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)list.inf.unibe.ch
>>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
>
https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch