Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] any objections to changing the "toString" of the CollectionType?


  i'm not sure why the eval occurs - the scriptDetailFormatter goes over to the debugging engine to inspect the value - i guess this is to cause the same behavior as if you were using a command line debugger and you wanted to have the debugger evaluate the value. in perl land, this would be the equivalent of doing a 'x $variable or p $variable' (i think - i don't like the command line debugger and don't use it that often but it's one of those commands :)).

  since we don't have any scriptDetailFormatters currently defined, the details pane falls back to using the value that is displayed inside the table.

  i will add a toggle preference that will allow people to choose if they want to see the 'preview' outside of the details view that way you and your customers will still get the same behavior. i take it you're building something on top of the _javascript_ core b/c i don't think we'd want to override this there (the preference negates this either way, i'm just curious).

  it would be nice if we could figure out what causes that to occur in the java debugger - do you have some 3rd party plugin that could causing that?

On Wed, Jul 2, 2008 at 9:31 AM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:
But greating that string should result in an eval (i think)
Because all those childs are already send to the debugger anyway (as far as i know)
I just loop through them building the string.

But as i said we can have a simple default.
Then i will only show that in _javascript_ part by overriding the formatValue method . Because i and our customers are really used to that representation.
I like to see as much as possible in 1 look without clicking or expanding. Gives me a much better overview of what is happening.

I currently dont have the ruby checked out. But why an eval if the variables are already on this side?

johan



On Wed, Jul 2, 2008 at 3:05 PM, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:

  sorry for the multiple messages....

  if you temporaly revert the format of the ArraySciptType back and fire off a ruby debug session using the fast debugger (use the attached script) you'll what i'm talking about. ruby has a detailFormater setup that goes back to the engine to do an 'eval' which produces the contents of the array, but the same thing can still be accomplished if no detailFormatter is available and/or the engine doesn't support evals.


On Wed, Jul 2, 2008 at 8:59 AM, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:

  i'd also be fine w/ just displaying the collection type, ie : array[8] or hash[10] instead of looking at the first element since those objects don't have to be homogeneous.


On Wed, Jul 2, 2008 at 8:56 AM, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:

  wait - i'm still not a fan of this solution. take a look at the attached screen shot of a java session.

  the collapsed List and char array don't show any 'preview' of what is inside in the table view, but the details view shows the actual contents of of the char array (although you do have to click on the entry in the table for the details pane to be popiulated). that's the same behavior i'd like to see happen here. (i'm not sure why collections in your view display something else, maybe there some option to turn that on?).

  right now, the details pane and the entry in the variables table are the same b/c the underlying code calls the same method to get that value. my next step was going to be to refactor that to add a separate call to get the detail pane text.


On Wed, Jul 2, 2008 at 8:34 AM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:
thats why i did take getRawValue() so that the Value itself would output the type (and for what i am testing it was "Array" for _javascript_ and so on)

But i could just create _javascript_ subclasses in the _javascript_TypeFactory to override the public String formatValue(IScriptValue value)  method now
so we could move all the formatting the script implementations


johan


On Wed, Jul 2, 2008 at 2:29 PM, Alex Panchenko <alex@xxxxxxxxx> wrote:
The word "Array" should depend on the type of collection - the code is now in CollectionScriptType and there are some descendants.

Another option to customize is braces around array elements
{1,2,3} vs [1,2,3] vs (1,2,3)
and that is languages specific, AFAIK

Alex

Johan Compagner wrote:
yeah for ruby the [size] is a bit strange looking if you have first [...] in front of it.
Maybe sb.append(value.getRawValue()); is not a good idea to have default?
I can live with just
sb.append("Array");
?
johan

On Wed, Jul 2, 2008 at 2:19 PM, Alex Panchenko <alex@xxxxxxxxx <mailto:alex@xxxxxxxxx>> wrote:

   I like the idea to display some of the array elements, but the
   basic implementation should have some options how to display values.
   e.g. now in ruby array is displayed as

   [...][3]{1,2,3} (id = 23638800)

   Strange, isn't it?

   So my intention is that basic implementation should be generally
   usable and language specifics should be added via inheritance or
   parameters passed in the constructor.

   Alex

   Jae Gangemi wrote:


        that 'number[8]' is supposed to work like the java debugger
       where if you have an aray you see something like char[5] which
       tells you that it's a character array and it has a size of 5.

        so in this case, you have an array of numbers w/ a size of 8.

        looking at the type of the first element for a script array
       may not make sense b/c they can be heterogenous.

        i'd like the behavior to remain consistent w/ how the java
       debugger works (if possible), where the details pane shows the
       'expanded' values, while the collapsed array (and/or hash)
       continues to show at 'somthing[size]'. i was going to work on
       a way to override what gets displayed in the details pane if
       you don't have a detail formatter setup next or the debugger
       engine doesn't support evaluations.

        the implemenation below would end up in a method like
       'formatDetailView' or something along those lines.

       On Wed, Jul 2, 2008 at 6:10 AM, Johan Compagner
       <jcompagner@xxxxxxxxx <mailto:jcompagner@xxxxxxxxx>
       <mailto:jcompagner@xxxxxxxxx <mailto:jcompagner@xxxxxxxxx>>>

       wrote:

          Now we get something like this in the debugger:

          "number[8]"

          What does that say? Nobody can see whats really in it without
          really expanding it and so on
          The Rhino debugger (the old one) did this:

          "Array(10.0,200.0,30.0,40.0,5006.0,700.0,200.0,"johan")"

          Of course not the complete array values limit it (currently 100
          values)

          This is the code:

          public String formatValue(IScriptValue value) {
                  StringBuffer sb = new StringBuffer();
                  sb.append(value.getRawValue()); // == Array
                  sb.append("("); // == Array

                  try {
                      IVariable[] variables2 = value.getVariables();
                      if (variables2.length > 0) {
                          int length = variables2.length;
                          length = length > 100 ? 100 : length;
                          for (int i = 0; i < variables2.length; i++) {
                                      sb.append(variables2[i].getValue().getValueString());
                              sb.append(",");
                          }
                          sb.setLength(sb.length() - 1);
                      }
                  } catch (DebugException ex) {
                      ex.printStackTrace();
                  }
                  sb.append(")"); // == Array

                  addInstanceId(value, sb);

                  return sb.toString();
              }

          Should i commit this? Or are you guys liking the current
       behavior
          better?

          johan


          _______________________________________________
          dltk-dev mailing list
          dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
       <mailto:dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>>


          https://dev.eclipse.org/mailman/listinfo/dltk-dev




       --        -jae
       ------------------------------------------------------------------------



       _______________________________________________
       dltk-dev mailing list
       dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
       https://dev.eclipse.org/mailman/listinfo/dltk-dev
       
   _______________________________________________
   dltk-dev mailing list
   dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
   https://dev.eclipse.org/mailman/listinfo/dltk-dev


------------------------------------------------------------------------

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
 
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev


_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev




--
-jae



--
-jae



--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev



_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev




--
-jae

Back to the top