On Wed, Dec 2, 2015 at 1:31 PM, Andrei Chis &lt;chisvasileandrei(a)gmail.com > wrote: > > > On Wed, Dec 2, 2015 at 5:24 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com&gt; wrote: > >> >> >> On Wed, Dec 2, 2015 at 1:02 PM, Andrei Chis < >> chisvasileandrei(a)gmail.com&gt; 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&gt; wrote: >>> >>>> >>>> >>>> On Wed, Dec 2, 2015 at 11:53 AM, Andrei Chis < >>>> chisvasileandrei(a)gmail.com&gt; 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&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka < >>>>>> juraj.kubelka(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Dec 1, 2015, at 17:47, Andrei Chis < >>>>>>> chisvasileandrei(a)gmail.com&gt; wrote: >>>>>>> >>>>>>> Hi Mariano >>>>>>> >>>>>>> On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck < >>>>>>> marianopeck(a)gmail.com&gt; wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis < >>>>>>>> chisvasileandrei(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck < >>>>>>>>> marianopeck(a)gmail.com&gt; 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