Jump to: navigation, search

Difference between revisions of "EDT:Debug"

Line 16: Line 16:
 
| bgcolor="#cccccc" align="center" valign="middle" | '''1.0<br>'''  
 
| bgcolor="#cccccc" align="center" valign="middle" | '''1.0<br>'''  
 
| bgcolor="#cccccc" align="center" valign="middle" | '''Future<br>'''  
 
| bgcolor="#cccccc" align="center" valign="middle" | '''Future<br>'''  
| bgcolor="#cccccc" align="center" valign="middle" | '''Sizing'''<br>  
+
| bgcolor="#cccccc" align="center" valign="middle" | '''Sizing'''<sup>'''[4]'''</sup><br>  
 
| bgcolor="#cccccc" align="center" valign="middle" | '''0.7<br>'''  
 
| bgcolor="#cccccc" align="center" valign="middle" | '''0.7<br>'''  
 
| bgcolor="#cccccc" align="center" valign="middle" | '''1.0<br>'''  
 
| bgcolor="#cccccc" align="center" valign="middle" | '''1.0<br>'''  
Line 80: Line 80:
 
*Conditional breakpoints<br>
 
*Conditional breakpoints<br>
  
| 15d<sup>[1]</sup><br>  
+
| 5d<sup>[1]</sup><br>  
 
| <br>  
 
| <br>  
 
| <br>  
 
| <br>  
Line 224: Line 224:
 
|-
 
|-
 
| bgcolor="#cccccc" |  
 
| bgcolor="#cccccc" |  
*Complex value modification of variables (supporting expressions)<br>
+
*Complex value modification of variables<br>
  
| 15d<sup>[1]</sup><br>  
+
| 5d<sup>[1]</sup><br>  
 
| <br>  
 
| <br>  
 
| <br>  
 
| <br>  
Line 256: Line 256:
 
| <br>  
 
| <br>  
 
| {{bug|351238}}
 
| {{bug|351238}}
 +
|-
 +
| bgcolor="#cccccc" | Compile &amp; generate contextual expressions
 +
| 10d
 +
|
 +
|
 +
| {{bug|352666}}
 +
|
 +
|
 +
|
 +
| {{bug|352666}}
 
|-
 
|-
 
| bgcolor="#cccccc" | Watch expressions<br>  
 
| bgcolor="#cccccc" | Watch expressions<br>  
| 15d<sup>[1]</sup><br>  
+
| 5d<sup>[1]</sup><br>  
 
| <br>  
 
| <br>  
 
| <br>  
 
| <br>  
Line 300: Line 310:
 
<br>  
 
<br>  
  
[1] First one of these to be implement will have the most work, and much of the code to create a conditional generated snippet can be reused.
+
[1] Depends on {{bug|352666}} which is sized at 10 days<br>
 +
 
 +
[2] Might make sense to create an object formatting framework where plug-ins can contribute variable value adapters. The EDT Java Generator might use one type to display, for example, an array, so it needs to use the object in a certain way to obtain its kids (e.g. edtObject.getChildren()). But a completely different generator will have a different class for arrays which will need a separate adapter for getting the kids (fooArray._children()). The first adapter that supports the given object wins - if no adapters then we fall back on JDT's display of the variable. '''Note:''' If a type generates a class then no adapter is needed - you can just generate the SMAP file with the class.  
  
[2] Might make sense to create an object formatting framework where plug-ins can contribute variable value adapters. The EDT Java Generator might use one type to display, for example, an array, so it needs to use the object in a certain way to obtain its kids (e.g. edtObject.getChildren()). But a completely different generator will have a different class for arrays which will need a separate adapter for getting the kids (fooArray._children()). The first adapter that supports the given object wins - if no adapters then we fall back on JDT's display of the variable. '''Note:''' If a type generates a class then no adapter is needed - you can just generate the SMAP file with the class.
+
[3] Not currently supported in EDT JavaGen so it can't be worked on. Requires the generator provide a variable adapter as described in #2 above, in which case the work for this becomes writing an adapter for the runtime ArrayDictionary object - which again, can't be worked on until the base generator supports the type. If someone else extends our generator to support ArrayDictionary, they'll have to write their own adapter.  
  
[3] Not currently supported in EDT JavaGen so it can't be worked on. Requires the generator provide a variable adapter as described in #2 above, in which case the work for this becomes writing an adapter for the runtime ArrayDictionary object - which again, can't be worked on until the base generator supports the type. If someone else extends our generator to support ArrayDictionary, they'll have to write their own adapter.
+
[4] Sizings for JavaScript debug assume a direct port of the RBD RUI Debugger

Revision as of 14:53, 20 July 2011

The Java-based debugger is implemented via JSR-45, plus some of our own extensions (such as support for a customized Variables view).

The JavaScript-based debugger has not been started yet.


Function Java
JavaScript

Sizing
0.7
1.0
Future
Sizing[4]
0.7
1.0
Future
Core framework

done





bug 351854
Stepping through statements
  • Most basic of function

done (free)





Will be covered by bug 351854
  • Step between EGL and Java

done (free)


N/A
  • Decide how to filter runtimes that users won't want to step into
5d
bug 346265


N/A
Breakpoints
  • Line breakpoints

done




bug 352582
  • Conditional breakpoints
5d[1]


bug 351236

bug 351237
  • Hit count on breakpoints

done (free)




bug 352586
  • Watchpoints
15d


bug 351873

bug 351874
Variables view
  • Primitives and records

done




Will be covered by bug 351854
  • User and system libraries

done (bug 346252)




Will be covered by bug 351854
  • Data tables, forms, & program parameters

done (bug 346254)




Will be covered by bug 351854
  • Arrays
2d[2]
bug 352021




Will be covered by bug 351854
  • Handler fields

done



Will be covered by bug 351854
  • Dictionaries
1d


bug 352600

Will be covered by bug 351854
  • ArrayDictionaries
1d[3]


bug 352602

Will be covered by bug 351854
  • Format display of certain variables
3d
bug 346247



Will be covered by bug 351854
  • Simple value modification of primitives
3d
bug 346249




bug 352598
  • Complex value modification of variables
5d[1]


bug 352595

bug 352597
  • Build watch expressions from variable context menu
3d


bug 351858

bug 351859
Hot code replace (aka hotswapping)

done (free)




bug 351238
Compile & generate contextual expressions 10d bug 352666 bug 352666
Watch expressions
5d[1]


bug 351240

bug 351241
Run to line

done (bug 346256)




bug 352593
Drop to frame

done (free)




bug 351239
Hover value in source editor
4d

bug 351872


bug 351872


[1] Depends on bug 352666 which is sized at 10 days

[2] Might make sense to create an object formatting framework where plug-ins can contribute variable value adapters. The EDT Java Generator might use one type to display, for example, an array, so it needs to use the object in a certain way to obtain its kids (e.g. edtObject.getChildren()). But a completely different generator will have a different class for arrays which will need a separate adapter for getting the kids (fooArray._children()). The first adapter that supports the given object wins - if no adapters then we fall back on JDT's display of the variable. Note: If a type generates a class then no adapter is needed - you can just generate the SMAP file with the class.

[3] Not currently supported in EDT JavaGen so it can't be worked on. Requires the generator provide a variable adapter as described in #2 above, in which case the work for this becomes writing an adapter for the runtime ArrayDictionary object - which again, can't be worked on until the base generator supports the type. If someone else extends our generator to support ArrayDictionary, they'll have to write their own adapter.

[4] Sizings for JavaScript debug assume a direct port of the RBD RUI Debugger