Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-debug-dev] Re: [dsdp-dd-dev] Multicontext debugging proposal

Cross-posting to ptp-dev so we can get input from the parallel debugging
community as well.


Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto

             Pawel Piech                                                   
   >                                                 To 
             Sent by:                  "Eclipse Platform Debug component   
             platform-debug-de         developers list."                   
             v-bounces@eclipse         <platform-debug-dev@xxxxxxxxxxx>    
             .org                                                       cc 
             23/10/2007 10:54          Re: [platform-debug-dev] Re:        
             PM                        [dsdp-dd-dev] Multicontext          
                                       debugging     proposal              
             Please respond to                                             
             "Eclipse Platform                                             
              Debug component                                              
             developers list."                                             

Samantha Chan wrote:

      I have also reviewed the proposal again and have consulted my team on
      of the issues.
      I have added more comments in the proposal as well.

      Re: Select Debug Context Dialog from View or Editor

      The dialog is to show different available context that is available
      for the
      user to switch between. The dialog will have a drop down to show
      context root. A context root contains available context. (e.g I
      assume the
      context root is the root in the Debug View where it is the Launch
      Having a dialog to display available context is not scalable,
      especially in
      parallel computing environment where we can have thousands of
      processes and
      threads. We need a way disable this feature all together to avoid the
      scalability problems. Or, we need a way to override the control used
      displayed the context to allow us to plug in fancier UIs to show
      context in
      a scalable manner.

A pluggable UI in the selection dialog seems like an excellent idea.  I was
planning to simply use a TreeModelViewer which would make the dialog as
scalable as the Launch view, but I imagine that for parallel computing the
Launch view itself is probably not all that useful.

      Re: De-centralization of the Launch View

      The proposal suggested that a default context provider is created for
      window. The default context provider is not tied to any view. The
      View is simply a listener to the default context provider. This
      allows the
      Debug Perspective to operate without the presence of the Launch View.
      concern here is that without having a view tied to the default
      provider, it is extremely confusing to figure out what the current
      context is. I agree that having another "kind" of view to drive the
      debug context is a good idea, but not having a view at all can cause
      usability problems. For example, if the user is debugging a
      application, and the user is suspended at Thread A, and debugging.
      Meanwhile, another thread, Thread B, is suspended. Without a view to
      indicate that something else is suspended, how does the user know
      another context has become available? What are some of the reasons
      why we
      do not want a view to drive the active debug context? Why is having a
      opened to drive the current context problematic?

The launch view takes up a lot of screen real estate: it needs to be wide
enough to fit the long labels of stack frames, and it needs to be at least
high enough to show all the levels in the tree (since a stack frame is 4
levels deep).  As a user I try to configure my view layout to have as much
screen dedicated for the editor as I can, even on a 1900x1200 screen...
maybe it's a bit of an obsession but I'm probably not alone :-)  What's
frustrating to me about the Launch view is that most of the time I actually
don't care about the data that's in it, because as a plugin developer I
usually run one program at a time, I can figure out what thread I'm in
based on the code that is executing and I mostly look at the top stack
I completely agree with you that without the Launch view present there
needs to be an obvious indicator of the current debug context.  I was
planning to try to use the status bar for this purpose, but I really don't
know how well that's going to work out.

      Re: Global Debug Actions Toolbar

      Since the Launch View does not need to be present all the time,
      from the Launch View's toolbar need to become global. This causes a
      problems for us:

      - Real-estate on the global toolbar - this makes the global toolbar

      - When invoking action on the toolbar, how does the user know what
      the action is invoked on. e.g. if I press resume, which thread am I
      resuming, without having the Launch View tells me which thread is in

      We also believe that this is a side effect to not having a view to
      debug context. If a view is always present, then there will be no
      need for
      global debug actions toolbar.

True, having a global toolbar is primarily intended to allow Launch
view-less debugging.  Ironically enough though, in our product we have the
opposite toolbar real-estate problem. We have too many buttons in the
Launch view itself.

      Re: Changes in the workflow

      As indicated in the proposal, this means that debugging workflow can
      changed significantly. Do we have enough time to get this right in
      the 3.4
      timeframe since the changes are so drastic. We have many debuggers
      built on
      top of the platform. We are concerned that the changes in workflow
      cause a lot of confusion with our existing users. One of our
      is that this work item should not break existing debug adapters.
      debug adapters should just work without much migration work involved.

I absolutely agree, these are major changes in the UI and I think there is
a lot of risk in getting it "right".  If I had the opportunity I would have
prototyped this back in July, but I know that at this point already it's
getting late for these kinds of changes.  In any case, my intention is not
to change the exiting default workflow for users, I only want to give the
opportunity for advanced users to optimize their workflow.

      Re: Changes in behavior with
      listener, String partId)

      If the client has registered with a partID that does not exist, the
      proposal is to change the behavior to have the listener get a context
      events from the default context provider. In my opinion, when the
      has specified a part id with the listener registration, the client
      to filter out events from views that it does not care about.
      Otherwise, the
      client could have registered without the part id. Changing this
      could break existing clients and introduce compatibility issues.

This could be an ugly problem for implementing these changes.. the
alternative would be to add a whole bunch of duplicate methods to

Thank you for all the feedback.


                   Pawel Piech


                   Sent by:                  Device Debugging developer

                   platform-debug-de         discussions

                   v-bounces@eclipse         <dsdp-dd-dev@xxxxxxxxxxx>


                   23/10/2007 07:14          [platform-debug-dev] Re:

                   PM                        [dsdp-dd-dev] Multicontext

                                             debugging proposal

                   Please respond to

                   "Eclipse Platform

                    Debug component

                   developers list."



      Good timing!  I was just about to start prototyping this proposal.

      Darin Wright wrote:

            Hi Pawel,

            I added more comments to the multicontext debugging proposal:

            Since the comments section is getting large I've also included
            them in
            this posting:

      I'm having serious doubts about using a wiki for raw comments.  For
      future reference, I think it'd be better to hold the discussion in
      email thread and use wiki to summarize them.

            Reviewing this proposal again, I think what's missing is the
            higher level

            goal. I believe the higher level goal is to be able to have
            sets of debug

            views linked to a specific context, and to be able to have


            contexts (e.g. cores within a session) have different sets of
            views that
            can be placed side by side.

            I think a problem with this proposal is that it places a heavy
            burder on
            the user to manage views. For example, they must manually
            unlink and pin
            views to a specific context. Then, once a context is stale it's
            not clear

            how to cleanup the view (i.e. is it left floating?), and how to
            capture/reuse a "view configuration" in a later debug session
            now that
            time has been spent setting it up. Can the user set up a view
            configuration before launching (i.e. in a launch

      I agree that on its own these changes would add complexity to the UI
      without giving the user any new tools to manage this complexity.  I
      planning to follow up these changes with a second proposal which
      add some form of "debug working sets" to manage this added
      I thought it would be a lot easier to think about that proposal with
      working prototype in hand though.
      However, I also hope that adding these features to the UI could stand
      its own, to avoid having to accept or reject a huge set of UI changes
      all at once.

            Note that the debug platform already has a mechanism for
            grouping views
            for a particular kind of debug session. For example, a Java
            debug session

            has a certain set of views assocaited with it, and when the
            user selects


            Java stack frame, the relevant views are brought to the
            There are extension points to support this: contextViewBindings
            debugModelContextBindings. Basically, we tie a "context" to a
            set of


            and bind a debug model to a "context".

            I wonder if it would be simpler to enhance the existing support
            to allow
            for a "new set" (more instances) of the same views to be opened
            for a
            debug session. This would leverage the existing support any may
            achieve the higher level goal (a dedicated group of related
            views for a
            debug session) with less steps/burden placed on the user. I
            could also


            this sort of support appearing in a launch config - i.e. as a
            check box


            use a new set of views, and perhaps which views they'd like to

      I think leveraging the existing view to context bindings is a good
      but IMO just relying on this mechanism alone would be too
      As far as the launch configuration UI, I have to admit I'm somewhat
      prejudiced against configuring view layout through a modal dialog, it
      seems distant and detached from the actual problem.  I would rather
      able to open and lay out my views, and then have the debugger
      remember this information for me.  Part of that magic may be to
      serialize layout information using the launch configuration (among
      parameters) as the key.

      I'm glad you are still thinking about this problem and I hope you
      time to keep this discussion going.  I would like to go for it and
      implement the prototype over the next couple of weeks, and then
      hopefully we'll be able to talk about these changes in a less
      theoretical context :-)


            Darin Wright
            Eclipse Debug Lead,
            Rational Team,
            IBM Canada
            dsdp-dd-dev mailing list

      platform-debug-dev mailing list

      platform-debug-dev mailing list

platform-debug-dev mailing list

Back to the top