I am not going to implement this since the current architecture is not suitable for this unless ugly hacks are done which I don't want to do.
A subsequent iteration of the debugger client will require another thought to separate the DBGP format (currently implemented in the client's command line) and a possible simplified command line interface. For example: instead of the current: (xqdb) breakpoint-set -f module.xq -l 1 the following should be enough: (xqdb) b module.xq:1 and this should be converted internally to the previous long command. In the same direction, the commands should make some guesses if some arguments are missing as the first example David gave: (xqdb) b 9 This should already guess that a breakpoint is needed either in the current file (if during execution) or the main module (if before execution) ** Changed in: zorba Assignee: Gabriel Petrovay (gabipetrovay) => (unassigned) -- You received this bug notification because you are a member of Zorba Coders, which is the registrant for Zorba. https://bugs.launchpad.net/bugs/901160 Title: Debugger: gdb way of adding breakpoints Status in Zorba - The XQuery Processor: New Bug description: Setting breakpoints in zorba debugger client works very well already. But the way the breakpoints need to be set is a little bit circuitous. Would it be possible to do it the gdb way? For example setting breakpoints in the current file: (gdb) b 9 Breakpoint 2 at 0x400a2b: file test.cpp, line 9. (gdb) b test.cpp:10 Breakpoint 2 at 0x400a2d: file test.cpp, line 10. That would be awesome! To manage notifications about this bug go to: https://bugs.launchpad.net/zorba/+bug/901160/+subscriptions -- Mailing list: https://launchpad.net/~zorba-coders Post to : email@example.com Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp