[slime-devel] Inspector features regressed
The default slime inspector used to support a variable called SWANK::*SLIME-INSPECT-CONTENTS-LIMIT* which was useful if you had to inspect large objects for certain programs with some characterestics. This customization has been removed[1] by Helmut's patches of 2008-02-09, replaced with hardcoded behaviour which is a pain in the ass for a few use cases [that I commonly use I can elaborate on these, if someone is interested] Is there some way to get the earlier functionality before, specifically where the limit can be specified and used in the "dynamic extent" of an inspector session? -- Madhu [1] Around July 2007, some [clueless] changes to the inspector broke this functionality, and I had reported these to the mailing list, and submitted my local patches, which were ignored until the functionality was removed. As in the case of slime history behaviour, the concern here is that existing useful functionality has again been removed in the [false name] of simplifying things, and replaced with something significantly worse.
As in the case of slime history behaviour, the concern here is that existing useful functionality has again been removed in the [false name] of simplifying things, and replaced with something significantly worse.
i have a feeling that soon you'll get your utlimatum, too... :) oops, i just broke my promise, sorry! off i am... -- attila
* Attila Lendvai [2008-04-28 10:57+0200] writes:
As in the case of slime history behaviour, the concern here is that existing useful functionality has again been removed in the [false name] of simplifying things, and replaced with something significantly worse.
i have a feeling that soon you'll get your utlimatum, too... :)
oops, i just broke my promise, sorry! off i am...
If you don't like the rules, don't join the club. Helmut.
* Madhu [2008-04-28 03:51+0200] writes:
The default slime inspector used to support a variable called SWANK::*SLIME-INSPECT-CONTENTS-LIMIT*
which was useful if you had to inspect large objects for certain programs with some characterestics. This customization has been removed[1] by Helmut's patches of 2008-02-09, replaced with hardcoded behaviour which is a pain in the ass for a few use cases [that I commonly use I can elaborate on these, if someone is interested]
I would be interested.
Is there some way to get the earlier functionality before, specifically where the limit can be specified and used in the "dynamic extent" of an inspector session?
Using the old version or writing your own inspector are possible ways.
[1] Around July 2007, some [clueless] changes to the inspector broke this functionality, and I had reported these to the mailing list, and submitted my local patches, which were ignored until the functionality was removed.
As in the case of slime history behaviour, the concern here is that existing useful functionality has again been removed in the [false name] of simplifying things, and replaced with something significantly worse.
Not every feature is it worth have, but simplicity is not optional. Feel free to disagree. Helmut.
* Helmut Eller <m2tzhlvo1z.fsf@common-lisp.net> : Wrote on Mon, 28 Apr 2008 20:20:40 +0200: |> The default slime inspector used to support a variable called |> SWANK::*SLIME-INSPECT-CONTENTS-LIMIT* |> |> which was useful if you had to inspect large objects for certain |> programs with some characterestics. This customization has been |> removed[1] by Helmut's patches of 2008-02-09, replaced with hardcoded |> behaviour which is a pain in the ass for a few use cases [that I |> commonly use I can elaborate on these, if someone is interested] | | I would be interested. Working with a large array (say 510 elements) is the most simple example which springs to mind. Imagine you want to inspect the last 10 objects, by going forwards and backwards in the inspector buffer.. If you cannot customize the variable you are forced to hit MORE for every element > 500. Again, large datasets pose a problem with SLIME. Here mechanism to deal with it was in place. |> As in the case of slime history behaviour, the concern here is that |> existing useful functionality has again been removed in the [false name] |> of simplifying things, and replaced with something significantly worse. | | Not every feature is it worth have, but simplicity is not optional. | Feel free to disagree. No, I don't disagree, the principle is admirable. My claim is its application is wrong. I'll take this case as a point. The feature was removed based on the assumption that "most people don't work with large datasets", so it was not worth having. and by removing the feature we are able to simplify things. Now if the assumption turns out to be wrong, and some people actually need to work with large datasets, and they require that funcionality, Now to get the functionality back, MORE COMPLEXITY has to be added against the simplified codebase. This is usually an indicator that the simplification is misguided and it because it does not judge the value of feature or the tradeoff accurately. -- Madhu
Madhu wrote:
* Helmut Eller <m2tzhlvo1z.fsf@common-lisp.net> : Wrote on Mon, 28 Apr 2008 20:20:40 +0200:
|> The default slime inspector used to support a variable called |> SWANK::*SLIME-INSPECT-CONTENTS-LIMIT* |> |> which was useful if you had to inspect large objects for certain |> programs with some characterestics. This customization has been |> removed[1] by Helmut's patches of 2008-02-09, replaced with hardcoded |> behaviour which is a pain in the ass for a few use cases [that I |> commonly use I can elaborate on these, if someone is interested] | | I would be interested.
Working with a large array (say 510 elements) is the most simple example which springs to mind. Imagine you want to inspect the last 10 objects, by going forwards and backwards in the inspector buffer.. If you cannot customize the variable you are forced to hit MORE for every element > 500.
Again, large datasets pose a problem with SLIME. Here mechanism to deal with it was in place.
I consider a 510 element array to be a SMALL array. Often I deal with arrays containing many million elements, and yes, the SLIME inspector has serious problems with large arrays. There really needs to be a serious effort to implement some sort of inspection window into large arrays.
* Madhu [2008-05-04 02:30+0200] writes:
Working with a large array (say 510 elements) is the most simple example which springs to mind. Imagine you want to inspect the last 10 objects, by going forwards and backwards in the inspector buffer.. If you cannot customize the variable you are forced to hit MORE for every element > 500.
Again, large datasets pose a problem with SLIME. Here mechanism to deal with it was in place.
Are you saying that a customizable variable solves the problems with large datasets? Alan Ruttenberg's code truncated the content after a certain length (if the limit was set and only for some data-structures, like arrays and hash-tables [and only if the backend didn't provide it's own specialized methods for those data-structures]). Currently, the content is always truncated after a limit (the limit is hard-coded but works for all data-structures). To me, this looks like the same mechanism.
|> As in the case of slime history behaviour, the concern here is that |> existing useful functionality has again been removed in the [false name] |> of simplifying things, and replaced with something significantly worse. | | Not every feature is it worth have, but simplicity is not optional. | Feel free to disagree.
No, I don't disagree, the principle is admirable. My claim is its application is wrong. I'll take this case as a point. The feature was removed based on the assumption that "most people don't work with large datasets", so it was not worth having. and by removing the feature we are able to simplify things.
You assume that that was my assumption, but your assumption is wrong. My primary goal was to make the mechanism work for objects of all types and not only for some with special inspect methods. This should make inspect methods simpler (and it did). I removed the customizable variable because a) I think the limit should be customizable on the Emacs side and not on the Lisp side b) what I wanted was a mechanism that only fetches the parts around point when moving backward/forward. b) was essentially not possible with Alan's code, it's possible now, but not (yet) implemented.
Now if the assumption turns out to be wrong, and some people actually need to work with large datasets, and they require that funcionality, Now to get the functionality back, MORE COMPLEXITY has to be added against the simplified codebase.
The old code had bugs and Alan, who originally wrote the code, or those people who introduced the bugs, didn't fix them for a long time. Little is lost if we implement it from scratch.
This is usually an indicator that the simplification is misguided and it because it does not judge the value of feature or the tradeoff accurately.
Well, it's hard to make accurate judgements without making wrong judgements from time to time. Helmut.
* Helmut Eller <m2skwhcirx.fsf@common-lisp.net> : Wrote on Sat, 17 May 2008 12:44:02 +0200: | * Madhu [2008-05-04 02:30+0200] writes: | |> Working with a large array (say 510 elements) is the most simple example |> which springs to mind. Imagine you want to inspect the last 10 objects, |> by going forwards and backwards in the inspector buffer.. If you cannot |> customize the variable you are forced to hit MORE for every element > |> 500. |> |> Again, large datasets pose a problem with SLIME. Here mechanism to deal |> with it was in place. | | Are you saying that a customizable variable solves the problems with | large datasets? That customized variable solves the specific problem instance I mentioned above in context. [Please check the description again as I'll only be repeating it again by way of explanation] | Alan Ruttenberg's code truncated the content after a certain length (if | the limit was set and only for some data-structures, like arrays and | hash-tables [and only if the backend didn't provide it's own specialized | methods for those data-structures]). Currently, the content is always | truncated after a limit (the limit is hard-coded but works for all | data-structures). To me, this looks like the same mechanism. [The problems I faced were with only with large hash-tables and arrays, I had extended the old implementation locally in a very simple adhoc manner with another global variable to specify the "start" of the window to inspect. This helped me inspect data whose `shape' I knew and whose indices I could specify. But Regardless of this local extension ...] The customization variable PLUS the old mechanism would permit me to `M-x rename-uniquely' the SLIME inspector buffer, after getting the range I was interested in, and inspect different values inspected aggregatte structure I am interested in without losing context (when going forward or backward). This ability is lost in the new implementation and new framework. [I admit I have not studied the code yet to see where it breaks.] |> No, I don't disagree, the principle is admirable. My claim is its |> application is wrong. I'll take this case as a point. The feature was |> removed based on the assumption that "most people don't work with large |> datasets", so it was not worth having. and by removing the feature we |> are able to simplify things. | | You assume that that was my assumption, but your assumption is wrong. | My primary goal was to make the mechanism work for objects of all types | and not only for some with special inspect methods. This should make | inspect methods simpler (and it did). Sorry I projected that assumption on you. My view had been that the problematic cases (hash tables and arrays) had warranted special treatment and so had been factored out for that special treatment, and that their inspect behaviour could be improved or tweaked independently was good. | I removed the customizable variable because a) I think the limit should | be customizable on the Emacs side and not on the Lisp side b) what I | wanted was a mechanism that only fetches the parts around point when | moving backward/forward. b) was essentially not possible with Alan's | code, it's possible now, but not (yet) implemented. Lynn is asking for this. I'd like to see it too. [Also, as said above I was able to hack it simply with another global which is set explicitly, in the specialized inspector method. which when combined with rename-uniquely and the contents limit variable could cut the surface of problematic data] | The old code had bugs and Alan, who originally wrote the code, or those | people who introduced the bugs, didn't fix them for a long time. Little | is lost if we implement it from scratch. [I have a vested interest here as I was using the old implementation after fixing the bugs I'd spotted, and extending it so it was useful to me. It seemed sound if somewhat clunky. Having to see the same issues again is disappointing, thats all] -- Madhu
participants (4)
-
Attila Lendvai -
Helmut Eller -
Lynn Quam -
Madhu