(previous message had image attachment that was too large for apache...
reposting)

> If I have the ethernetIP jar on the daffodil debug classpath, only, then
> when I try to step into the ethernetIP schema I get a failure:
> "debugger daffodil.error.scopenotfound", and the parse ends, no infoset is
> created. I have to put the ethernetIP/src/main/resources directory there
as
> well.
> I think it should not fail, and it should complain about not finding the
> source (though it IS in the jar and eventually we need it to find it
> there), but it should allow you to *step out of *that back to the PCAP
> schema file.

I get a different experience, but I may be performing slightly different
actions:
- I set a breakpoint in pcap.dfdl.xsd on line 168 (first use of the
Ethernet element).
- I start the debug session. This pauses at the beginning of the parse, and
I hit "Continue" which then breaks on line 168 (Ethernet element).
- I open the ethernetIP.dfdl.xsd file via normal VSCode File->Open
commands. I add a breakpoint to line 68 (declaration of MACDest element).
- I press "Continue" and the ethernet breakpoint is hit.
- If I click on the Call Stack where MACDest is at the top of the stack, a
different view of MACDest is shown: it is from within the ethernetIP jar
file. I suspect this is from a plugin I have installed locally (
https://marketplace.visualstudio.com/items?itemName=wmanth.jar-viewer ?),
but I'm not sure and would need external validation for.

I am surprised that the separately-opened xsd breakpoint is correctly
mapped, but it seems to work for me.

Can you include some of the logs from when you get a "scopenotfound", along
with the breakpoints you set?

My successful breakpoint hit:
https://gist.github.com/arosien/7383b5aba1f15aeba847b8db8b44cdad

On Tue, Aug 29, 2023 at 8:36 AM Adam Rosien <[email protected]> wrote:

> Hi Mike, those sound like bugs that do need to be addressed: debug levels,
> json output, etc. I'll look into them to reproduce and handle issues, etc.
>
> .. Adam
>
> On Tue, Aug 29, 2023 at 7:59 AM Mike Beckerle <[email protected]>
> wrote:
>
>> My vote +1 (However, I see already there is a binding -1, so oh well)
>>
>> I want to try some even harder schemas, but already this is more robust
>> and
>> usable than 1.3.0 because it makes the error outputs more visible.
>>
>> A few notes:
>>
>> I like the Debug Console tab. The error messages that mention files, the
>> file names are clickable to take you to the file at least.
>>
>> In the launch.json, changing the debug level to INFO didn't reduce the
>> huge
>> debug output to the terminal.
>>
>> If I have the ethernetIP jar on the daffodil debug classpath, only, then
>> when I try to step into the ethernetIP schema I get a failure:
>> "debugger daffodil.error.scopenotfound", and the parse ends, no infoset is
>> created. I have to put the ethernetIP/src/main/resources directory there
>> as
>> well.
>> I think it should not fail, and it should complain about not finding the
>> source (though it IS in the jar and eventually we need it to find it
>> there), but it should allow you to *step out of *that back to the PCAP
>> schema file.
>>
>> Even if you choose output type JSON, the output infoset file is named
>> infoset.xml. Should be infoset.json.
>>
>> The layout of the launch wizard is confusing. You have to scroll past much
>> less relevant stuff to find the "Program" which is the path to the top
>> level schema file - shouldn't be called "program" it should be "Main
>> Schema
>> File", and should be near the top of the dialog.
>>
>> If you stop a debug, or it ends with a parse error, you still get a pop up
>> in the corner saying it wrote an infoset file, even though that is empty.
>>
>> It will let you put a breakpoint on a line that is not an element, but it
>> doesn't stop there. Could it somehow indicate that no breakpoint there is
>> possible?
>>
>

Reply via email to