• Page
• Discussion
• View source
• History

From Eclipsepedia

You do not have permission to do that, for the following reason:

You can view and copy the source of this page:

== Location and Dates == * Location: IBM Software Lab – Toronto (see logistics below) * Tues 9-Jan-07: 0900 – 1700 * Wed 10-Jan-07: 0900 – 1500 (approx) == Agenda == * Update on Flex hierarchy changes in M4. * Update on DSF architecture and GDB/mi implementation. * Update on Memory group. * Update on pin/clone. * DSDP/Debug Roadmap * Introduction to IP-XACT editor: ** Demonstration ** Architectural overview * Coding camp for DSF. == Attendees == Open to all. Please add your name to the list. * John Cortell, Freescale * Steve Furr, Freescale * Ted Williams, Wind River * Doug Gaff, Wind River * Randy Rohrbach, Wind River * Fran Litterio, Wind River (remotely) * Pawel Piech, Wind River * Darin Wright, IBM * Doug Schaefer, QNX * Chris Recoskie, IBM * Dominique Toupin, Ericsson / R&D PM&T * Veenu Verma, Ericsson / TSP * Francois Chouinard, Ericsson / TSP * Martin Gunnesson, Ericsson / CPP DTE * Alf Larsson, Ericsson / CPP DTE * Magnus Ohlin, Ericsson / EMP * Rune Hylsberg Jacobsen, Ericsson / IS * Mark Melvin, AMI Semiconductor * Todd Lee, AMI Semiconductor * Ken Dyck, AMI Semiconductor * Vivian Kong, IBM * Jason Montojo, IBM * Mike Kucera, IBM * Samantha Chan, IBM * Alan Boxall, IBM * Pete Nicholls, IBM * Mikhail Khodjaiants, ARM (remotely) * Anthony Berent, ARM * Ewa Matejska, PalmSource * Paul Gingrich, TI * Martin Swiezawski, TI * Patrick Chuong, TI * Dobrin Alexiev, TI * Baltasar Belyavsky, TI == Logistics == * Area hotels: (the Hilton is about a 2 minute walk) ** Hilton Suites Hotel & Conference Centre Toronto/Markham (formerly Embassy Suites)<br>8500 Warden Avenue<br>Markham, Ontario<br>Phone: 905 470-8500<br>http://www.hilton.com/en/hi/hotels/index.jhtml;jsessionid=4KXATC2AU1HHJJ31AOQMISQ?ctyhocn=YYZAPHF<br>Distance to 8200 Warden: 0.5 km ** Radisson Hotel Toronto-Markham<br>50 East Valhalla Drive<br>Markham, Ontario<br>Phone: 905 477-2010<br>Distance to 8200 Warden: 3 km ** Holiday Inn Hotel & Suites Markham<br>7095 Woodbine Ave.<br>Markham, Ontario<br>Phone: 905 474-0444<br>Distance to 8200 Warden: 5 km<br> <br> * Face-to-Face Location **IBM Software Lab<br>8200 Warden Ave, Markham, ON L6G 1A1<br>CANADA<br>http://maps.google.ca/maps?f=q&hl=en&q=8200+Warden+Avenue,+Markham,+Canada&ie=UTF8&z=14&ll=43.856997,-79.321032&spn=0.022528,0.08214&om=1&iwloc=addr <br> * Driving Directions from Airport: ** The lab is just off Warden Ave between Highway 407 and Highway 7 in Markham. ** To 8200 using the 407 Express Toll Route*:<br>When exiting the airport follow the signs for Highway 427 North. Drive north on Highway 427 and exit on to Highway 407 ETR East. Follow Highway 407 ETR east for 28 km to the Warden Ave exit. Turn left (north) at the Warden Ave exit stop light. Go north on Warden Ave and prepare to exit right on to the IBM overpass which will take you into the Lab.<br>*Please advise the auto rental agency before taking the 407 ETR . The toll (approx. $6.00 CDN one way + possible auto rental agency administration fees) will be billed to your credit card. ** To 8200 using Highway 401:<br> When exiting the airport follow the signs for Highway 401 East. Drive east on Highway 401 for 27 Kilometres to the Don Valley Parkway/404 exit. Go north (towards Newmarket) on the 404 and exit at Hwy 7. Proceed east on Hwy 7 to South Town Centre Blvd (South Town Centre Blvd is east of Rodick Rd and west of Warden Ave). Turn right (south) on South Town Centre Blvd Follow this road straight into the Lab. == Opening Statement (Doug Gaff, Wind River Systems) == * 32 participants present, 2(?) dialed in * Doug Gaff introduced himself and thanked the group for attending. * The group went around the room introducing ourselves. * First face to face in about one year. * Technical topics first day, project status second day. * Aaron Spear is working on an parser contributions, but was unable to make the meeting. Doug G anticipates an update soon. == Flexible Hierarchy update (Darin Wright, IBM Rational Software) == * [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2007-1-9_Toronto_DD_FlexHierarchyUpdate.ppt Darin's presentation] * Views ** APIs were provisional in 3.2. There was a plan to make these APIs "public" in 3.3. There has been progress, but many are still marked as experimental. *** How many have been using the new APIs? Two hands. ** Question: Coalescing delay? Darin thinks the user will see blank, empty space as the user scrolls faster than the data can populate. * JFace viewers don't support filtering/sorting when in virtual mode. *** To continue existing filter support, elements will be requested to fill the viewport. If some of these elements are filtered out, additional requests will load more data until the viewport is filled. This will cause the scroll bar to recalculate the maximum as the user scrolls. *** If you want a stable UI, put the filter in the model. * Debug Commands & Handlers ** new to 3.3, events are fired for context selection ** interfaces moved from debug ui to core plugin * Other Enhancements ** Mixed mode launching (profile & debug at same time, for example) ** Multiple launches for the same configuration type & mode ** contribute tabs to existing launch configuration tab groups ** context sensitive launching (run as, debug as selection sensitive) ** pluggable detail panes, was just text, now extension point allows for any SWT control, thin, lightweight. support for more than one detail pane for a given selection. * Darin will talk about these topics in more detail at his eclipsecon tutorial. == View Model (Pawel Piech, Wind River Systems) == * [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2007-1-9_Toronto_DSF_ViewModel.ppt Pawel's presentation] * common pattern identified as a potentially useful contribution * Pawel demonstrated the "Timers" DSF view model example == Pin & Clone (Pawel Piech, Wind River Systems) == * Prototype implementation has been posted to bugzilla. [ TODO link ] * Pawel gave a demo using JDT. These changes do not require DSF. The enhancement is to the platform. * One can pin to a specific context OR provider. Historically, the debug view has been the only provider. In the future, the user might pin a variables view to the Target Manager instead of the debug view. * Persistence is not yet stated saved between sessions * Tooltip indication of pin status requires hovering. Pete, Doug G and others believe colored indication is necessary. Darin believes there should be stability of the toolbar. Changing the text could cause the toolbar to reshuffle. He believes a more standard workbench metaphor would include changing of the tab color. * Do people feel that this is valuable enough as is? ** Chris R: Even if it has issues, it's better than what we have now, which is nothing. ** Pawel: The command service APIs are set to become public/final in this release. This patch requires changes. There is some urgency. * Open issue: different use cases. Hopefully there aren't any more API changes required, but until we are firm on workflow, it's hard to know. * Can this be committed in 3.3? == Debugger Services Framework (Pawel Piech, Wind River Systems) == * [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2007-1-9_Toronto_DSF_Architecture_Update.ppt Pawel's presentation] * Repeat of presentation given at the CDT conference. * Why create another debug model, compare/constrast with CDI, features of the framework, migration options, future plans. * Doug S: A lot of companies have embedded debuggers based on CDT. What do people in this category want to get out of DSF? ** Multi-core ** True OCD/hardware debugging ** Ability to plug in additional components in a supported and standard way. ** Explicit goal should be to get people using DSF. It's critical for the survival of the project. ** Ability to access the data model for non-UI purposes. * Discussion about CDI vs DSF. DSF is more complicated for the simple cases. CDI has had more iterations and testing and benefits from greater maturity. For embedded, remote and other high latency debug use cases, the complexity associated with asynchronous models (DSF) is justified by the performance gains. * 0.9 release with complete and stable service interfaces. ** Continued development on the GDB-MI implementation. ** Wind River plans to use DSF for their next commercial release, but without feedback from the community, the interfaces and model might not fit the needs of the community. == State of the Project (Doug Gaff) == * [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2007-1-9_Toronto_DD_Roadmap.ppt Doug's presentation] * Good things: memory view, DSF, spirit working group, terminal (went into TM project) * Some progress: Registers, Breakpoints, Editor/Disassembly, Console, Pin/Clone * Stagnant: Debug view, Source lookup, Launch * Attendance has been very exciting. We had hoped that there would be similar interest over development participation. * When we started off, we believed there would be more early collaboration. We've heard from many that commercial work not left sufficient time for DD open source development. * Wind plans to adopt DSF commercially in 2007. We might not be able to staff continued development on the GDB-MI DSF reference implementation. * Open discussion ** Darin: Does DD have any backward compatibility requirement? Doug G: No, because it is experimental. ** TI: We don't know if we need DSF, yet. Same feature set, no benefit to switch other than testing new framework. Backend is synchronous. We would like fast stepping and performance is an issue. Multicore as well. Testing the waters at this point. Wait and see. SPIRIT is a large decision requiring the agreement of multiple groups. No interest in GDB implementation. CDI not required, but it would be a plus (less code to rewrite). TI does get value out of the debug discussions. After product is release, there might be resources available. ** Freescale: Us, too. We need DSF. We need multicore. CDT is weak for multicore. Same issues with SPIRIT. GDB implementation not required. CDI compatibility not required. Will use CDI/CDT until a migration is complete. These discussions are useful. ** AMI: No resources to investigate the use of DSF. Faces same issues as Wind. It would be a big architectural change, not a minor API change. Beyond an eclipse.org style "hello world", not enough resources to try it out. Based on the current state, where can one begin? Unsure of plans for SPIRIT. GDB-MI and CDI/CDT not used. Good at filing bugs against platform. Has used flexible hierarchy. Discussions useful. Interested in Terminal/Console. Company is huge, but software team feels small. Would probably use DSF if starting today. Difficult to evaluate without reference design. ** IBM (Pete): DSF no, SPIRIT no, GDB-MI no, CDI/CDT maybe, values discussions. Some IDEs may use CDT in the future. Has not really looked into flexible hierarchy, but expects to use it heavily within the next six months. How many interested in launch proposal? If not, we'll end up with an IBM design. ** IBM (Chris): DSF might possible become more interesting depending what happens with Doug S's windows debugger. Discussions always useful, even if not directly working on discussed topics at the moment. ** PalmSource (Ewa): Using CDT and whatever CDT decides to use. Performance is important. Driving CDT toward improvements in performance is useful. Discussions are useful. Not planning to use SPIRIT. ** Ericson: Multicore useful, SPIRIT not really, GDB yes, CDI compatibility not important. Good debugging based on DSF would be fine. First meeting. ** QNX (Doug S): CDI/CDT already meets needs. It'll be hard to get resources to work on DSF. GDB-MI based, would be important if there were a move to DSF. Windows debugger will be MI based. DSF could be tested/evaluated for this task. ** CDT (Doug S): CDT would like to see an GDB-MI implementation. DSF could definitely useful to CDT in the future. ** ARM (Anthony): DSF is a good fit for architectures used in debuggers, but unfortunately the whole debugger is written in C++. If and when product moves to java/eclipse, DSF will be a good fit. SPIRIT already used in products. No interest in GDB-MI or CDI. Discussions valuable. ** ARM (Mikhail): Not going to use DSF, will improve CDI. Liked DSF from the whitepaper, but found code difficult. Hasn't looked at it in a long time. Will be using SPIRIT. GDB-MI used today. ** Nokia (Ken): Needs DSF, DSF features, would like to have looked at it more seriously six months ago, started picking it up again last week. Would like to see DSF integrated into CDT. The rest of their product will continue to use CDT features. Will likely use SPIRIT eventually. Would like to see GDB-MI reference implementation for the purpose of better understanding how things work (not to actually use as a base, no commercial purposes). CDI compatibility is confusing and not required. Accepts that connecting backend to DSF will require writing code. Finds a lot of value in debug discussions. Would like to export work done on CDT breakpoints to DSF. * Darin: Has anyone evaluated Netbeans as a platform for building tools? ** No hands. * Forum, format and frequency of DD discussion? ** Doug S: CDT dev mailing list as an example. Ask questions in the open forum. The barrier to even looking at DSF is very high today. Not confident that anyone will look at DSF in the short term. Has looked at the code. Interfaces look very abstract. You have to do a lot in order to get the simple examples working. Believes there are missing pieces of the framework. Looks scary. Might not be true. Might be easy to get the examples going. ** AMI: API is there, whitepaper is there, but it's not clear what needs to be implemented in order to get going. Doug S: CDT/CDI didn't have this either, but there was a reference implementation. ** Freescale: GDB-MI was a tremendous help. Acted as a guide. Proved the technology. If that piece of the puzzle is missing, the barrier to adoption is much larger. ** Wind River (Doug G): Agree, but we may not have the resources to work on the reference implementation. Not sure at this point. Making a request for help. If we do find one interested resource (maybe Ericson), what will the rest of the group do? Wait to look? ** Nokia: Give it a couple of months to evolve. Might have to think about available resources. It might be possible, if it helps solve the multicore requirement. Might be more interested in working on a parallel effort such as the debug view. ** Wind River (Doug G): We will help others get up to speed if others are interested. This would be preferred over investing in better documentation. If there isn't interest, DSF will continue based on Wind's commercial development, but there will not likely be work on the MI reference. ** Doug S: For all those who say you need DSF, how badly do you need it if you aren't willing to contribute to it? Blunt. Needed DSF, but needed it two years ago? If you have a slow connection, your debugger will run slow -- customers have adjusted to this. Is performance something you really need? It won't happen, unless the community pulls together. ** QNX (Doug S): Would really like to see MI reference. Would like to evaluate it. ** Mikhail: Why do you want to replace one model with another. Both models could live in parallel. ** Wind River (Doug G): BOF at eclipsecon. Continue monthly phone meetings. Interested parties should join our DSF conference calls to come up to speed. Not sure how to capture calls. Maybe electronic discussions later. Hearing that most want something more to look at than just a framework. * Commit rights (no longer required for wiki, bugzilla login now works) ** Voluntarily remove yourself from the list? Ok to leave list alone for now. *** IBM Pete: "You can take my name off the list. You don't want any code I wrote. :)" *** Chris R: Any work will likely be done on CDT. *** Paul Gingrich: won't be writing any code for DD. *** Kirk (not at meeting): Doug will follow up. ** Individuals will be added soon. Those who do have rights should vote. == Memory subgroup (Samantha Chan) == * Samantha has updated the wiki to show the latest status. * Flexible hierarchy can be used in the memory view. * Migrating the table renderings to use the Tree Model viewer. * Viewer will be refactored to use JFace in the next release (after 3.3). * User preference for buffer size before/after viewport. * GotoAddress API * Darin: Async tree viewer is gone. Will break CDT on the next milestone. The table viewer is still there, because the memory view uses it. Only planning to have a tree viewer in the future. It should look the same. * Import/Export deferred (after 3.3), Freescale had the task, but solved it commercially another way. It's back on the table for volunteers. === Day 2 === == DSF Command Queuing and Coalescing (Randy Rohrbach, Wind River) == [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2007-1-9_Toronto_DD_Command_Queueing.ppt Randy's presentation ] * common command boundary for caching * view model should perform as little caching as possible * higher level DSF services utilize lower level cache * first cut algorithm assumes it is safe to reorder requests * individual managed caches, MICommandCache (symbols, registers, ...) * command monitoring can happen by watching queue * When a command request is added to the queue, the existing queued commands are queried for coalescing compatibility. If the command cannot be coalesced, it is added to the queue. == Doug G on DSF status == * In case the status was not clear, the DSF reference implementation (sans disassembly and expression evaluation) does exist. We don't consider it complete, but it is usable. One can launch a debug session and try it out. == An Eclipse Editor for IP-XACT (Anthony Berent, ARM) == [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2007-1-9_Toronto_DD_IP-XACT_Editor_for_Eclipse.ppt Anthony's presentation] * The name has been split. IP-XACT from the SPIRIT Consortium. * enhanced XML editor ** context sensitive knowledge ** understands the IP-XACT schema ** reduces need for expensive EDA tools ** wizards for creating IP-XACT documents ** using webtools XML editor == Usability testing feedback (Ken Ryall) == [http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2007-1-9_Toronto_DD_Launching_and_Usability.ppt Ken's presentation] * debug platforms ** windows, simulated environment ** several flavors of ARM * assembled several groups ** 1) novice developers, just out of school, c++ experience ** 2) experienced and professional c++ developers, MS dev studio users ** 3) java & c++ developers, more experience with eclipse from java work * sat the group members in front of the tools and asked them to do a number of things ** most significant difficulty area: launching *** major obstacle for everyone in test *** even those who found the launch dialog weren't sure what to do with it *** some were interested in the available options, but at early stages of project, they just wanted to get going. *** wanted a debug button that would "just do the right thing" * experimented with workarounds in their commercial product ** replaced platform launch actions (recluctantly, but only viable option) ** the execution of run/debug is dynamically changed based on selection changes ** new wizard-dialog more gently guides users to building launch configurations ** users still have access to the standard launch dialog ** when launched, a launch configuration is created automatically, with as little user interaction as possible. the details depend on the type of launch. ** the launch dialog introduces the launch configuration at the end to increase familiarity. * feedback from changes has been positive ** people like it ** planning to release changes as part of CDT 4.0 ** bug 74480 will possibly eliminate the need to replace platform launch commands? cleaner integration * Darin Wright demonstrated recent changes to launch ** code was attached to a bug last night ** properties on navigator node allows launches to be added. only launches applicable to the resource are provided in the list. ** clicking run uses the default applicable launch shortcut. ** project creation wizards may want to create a default launch configuration. ** launch configurations can be shared. project preference settings are used so that the default setting can be shared as part of the workspace. ** changes are not written until apply/ok. if the user cancels, the changes are not committed to the workspace. ** there are multiple stories about how these platform enhancements can coexist with Ken's developments. ** Ken: what if the selection is text in an editor? *** Darin: we can derive the resource adapter from the editor and work up the hierarchy. Not yet sure if nesting should be supported (default for file, project, ...)? Leaning towards just having a default at the project level. ** Doug G: When creating a project using a project template, can a default launch configuration be provided? *** Darin: Programmatically you could do it. ** Doug G: Launch history? *** Darin: There will still be a launch history, but when you press a launch button, the system is going to try to determine the correct launch configuration. Maybe we need to also work down the hierarchy. If there is not a default for the project, should we look down the tree? If multiple resources are found with defaults, we'd prompt the user. Chris R gave the example of "debug" and "release" builds of the same code within a project. *** 74480 contains an attachment with this patch. An extra page displays "default launch configurations". The "Launch Manager" is the API to set the default. *** Doug G: A team at Wind River will try out these changes and provide feedback. == Pin & Clone use cases (Wind River) == * Reviewed Wind River prototype again: pull down toolbar pin item (in variables view, for example) ** displays and allows pinning to any element in hierarchy of current selection or any selection provider (debug view, maybe target manager in the future). *** Ken: Why not just have a pin button? Why would a user want to select something other than what the view is currently displaying? *** Darin: Prototype currently populates from the treepath hierarchy. Would it be possible to allow the model to control the pinnable list? *** group sentiment: Population of the combo box list from the tree path is too complicated for the user. *** Alan (IBM): The prototype requires the user to clone a view and then pin to the desired context. How about providing a "Open Register View pinned to selected context" in debug view context menu? It would require fewer steps. Darin: There is some technical difficulty in this approach. *** Anthony (ARM): For multicore, it would be useful to allow a user to open a complete set of debug views for a given core/context. * Looking at Wind River's prototype, the group discussed outstanding issues influencing workflow: ** 1) decorations (beyond tooltip) *** color has been used in Wind River products. an outline (box) displays the association to view pinned context. *** adding decoration would require changes to individual views. existing prototype does not require changes. *** Darin: If we can agree on a system that meets the visual requirements, it would be acceptable to update the views. *** group: Modify the label provider of the tab? *** group: Not much room. The names will be too long. *** Pawel: It would be nice to know which context a view is pinned to without having to bring it forward. *** Darin: The platform does not allow for coloring the tab. The client area could be colored. *** TI: Debug View coloring is not a requirement. The first step could be to just color the views. The color would be a reminder of the meaning, since the view would also provide text. This would allow CDT to pick up the functionality without model/debug view changes. The debug view color should happen long term. *** Conclusion... Generically: toolbar, label provider, colorized status bar (colored pinned icon?). Non-Generically: Color the content area to correspond with the color of the context/selection. ** 2) how should global actions (run control) *** Strong community voice: Don't change the debug view selection. *** Strong community voice: Don't change the meaning of global actions (run control) based on the pinning of the currently focused view. ** 3) layout and persistence between sessions *** Solvable, just work. *** Darin: Could be added later in a plugin. *** Doesn't impact the design. We want to get pin & clone in to M5. Persistence could come later. == Meeting concluded at 14:40 Toronto with cookies ==

Return to DSDP/DD/Face-to-face Toronto 9-10-Jan-2007.