Anyone know how to display the XML Node/Element object as a string in the Debug Frame or Watches window? In Eclipse, it was pretty easy, as I could just specify a code fragment to convert to a String. In Idea, it seems you can only specify a single line....
Anyone know how to display the XML Node/Element object as a string in the Debug Frame or Watches window? In Eclipse, it was pretty easy, as I could just specify a code fragment to convert to a String. In Idea, it seems you can only specify a single line....
Not quite. I don't know of a way how to transform an org.w3c.dom.Node into a String using a single expression without any custom utility function. The request to allow arbitrary code fragments seems reasonable.
Yep, indeed this sounds reasonable while I still suggest using utility code from the application being debugged. This is just far more effective since we only will be forced to evaluated single method call on target machine while in case of large code fragments it will behaive like interpretator passing required parameters and evaluation results back and forth from debugee to debugger. -
Not quite. I don't know of a way how to transform an org.w3c.dom.Node into a String using a single expression without any custom utility function. The request to allow arbitrary code fragments seems reasonable.
Yep, indeed this sounds reasonable while I still suggest using utility code from the application being debugged. This is just far more effective since we only will be forced to evaluated single method call on target machine while in case of large code fragments it will behaive like interpretator passing required parameters and evaluation results back and forth from debugee to debugger.
No doubt about the bad performance, but I wonder if such fragments could be pre-compiled and hot-swapped into the target VM? This might also make complex conditional breakpoint conditions a bit faster.
>> Yep, indeed this sounds reasonable while I still suggest using >> utility code from the application being debugged. This is just far >> more effective since we only will be forced to evaluated single >> method call on target machine while in case of large code fragments >> it will behaive like interpretator passing required parameters and >> evaluation results back and forth from debugee to debugger. >>
No doubt about the bad performance, but I wonder if such fragments could be pre-compiled and hot-swapped into the target VM? This might also make complex conditional breakpoint conditions a bit faster.
]]>
Anyone know how to display the XML Node/Element object as a string in the Debug Frame or Watches window? In Eclipse, it was pretty easy, as I could just specify a code fragment to convert to a String. In Idea, it seems you can only specify a single line....
Settings|Debugger|Type Renderers
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
Maxim Shafirov (JetBrains) wrote:
Not quite. I don't know of a way how to transform an org.w3c.dom.Node into a String using
a single expression without any custom utility function. The request to allow arbitrary
code fragments seems reasonable.
Sascha
Yep, indeed this sounds reasonable while I still suggest using utility code
from the application being debugged. This is just far more effective since
we only will be forced to evaluated single method call on target machine
while in case of large code fragments it will behaive like interpretator
passing required parameters and evaluation results back and forth from debugee
to debugger.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
>> Settings|Debugger|Type Renderers
>>
Maxim Shafirov (JetBrains) wrote:
No doubt about the bad performance, but I wonder if such fragments could be pre-compiled
and hot-swapped into the target VM? This might also make complex conditional breakpoint
conditions a bit faster.
Sascha
Yes and no. Technically possible for local debugs and not possible for remote
debugs and stuffs like appservers and cell-phone emulators.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
>> Yep, indeed this sounds reasonable while I still suggest using
>> utility code from the application being debugged. This is just far
>> more effective since we only will be forced to evaluated single
>> method call on target machine while in case of large code fragments
>> it will behaive like interpretator passing required parameters and
>> evaluation results back and forth from debugee to debugger.
>>