I have been able to continue evaluating RC2.
My vote is -1
My testing steps listed below. I am trying to debug PCAP. I have a broken
icmp packet (bad magic number), and also just step through a correct icmp
packet.
I am trying to debug icmp.badMagicNum.cap data file.
I should get a failure of an assert because the magic number is not one of
the expected values.
I'm just trying to single-step through it until it hits the error.
Once we get to the MagicNumber element, it doesn't position on the assert
while evaluating that expression or even on the element carrying the assert.
It jumps back to the top-level xs:schema position.
I continue to click single step. Watching for the error to be displayed in
the upper left under Variables > Parse > Diagnostics > Errors which is
where I think it ought to go.
At some point the failure is somehow detected as the debug session ends. A
dialog offers to open /tmp/infoset.xml for me, which I open and it is empty
of course.
Nothing displayed the error message from the assert, or even indicated what
went wrong at all. Not the state display in the upper left, not the
terminal, nor debug console nor output.
The upper left box with "Variables" is cleared at the end. It should
certainly not be cleared at the end of a run when final state may be of
interest. At the start of a run, or manually, but not at the end of a run.
Second attempt to use it:
I create a second launch config this time for what should be a successful
parse of icmp1.cap
As I single step, the position of the cursor on the schema is jumping
around all over the place back and forth between a containing element and
the child elements it contains.
The infoset display does not get updated until long after the display has
moved on and is positioned on the next element.
This jumping around gets completely out of hand once you step into the
complexType "Ethernet" which is in the ethernetIP jar file.
At that point, after each child of Ethernet, it jumps back to the Ethernet
element in the pcap.dfdl.xsd file, and then back into the
ethernetIP.dfdl.xsd for the next child, then back to the pcap.dfdl.xsd
file, etc.
All this jumping around basically makes stepping useless. So I decide to
put a breakpoint on the Version element inside the IPv4Header element
inside ethernetIP.dfdl.xsd.
Just adding the breakpoint causes the debug session to end with an NPE in
the dap setBreakpoint.
ERROR o.a.d.d.d.DAPodil - unhandled error
java.lang.NullPointerException: null
at java.base/sun.nio.fs.UnixPath.normalizeAndCheck(UnixPath.java:75)
at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
at
java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
at java.base/java.nio.file.Path.of(Path.java:147)
at java.base/java.nio.file.Paths.get(Paths.java:69)
at
org.apache.daffodil.debugger.dap.DAPodil.$anonfun$setBreakpoints$1(DAPodil.scala:267)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @
org.apache.daffodil.debugger.dap.DAPodil.setBreakpoints(DAPodil.scala:263)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at handleErrorWith @
fs2.Compiler$Target.handleErrorWith(Compiler.scala:161)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Pull$.goEval$1(Pull.scala:1057)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Pull$.fs2$Pull$$interruptGuard$1(Pull.scala:929)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
2023-05-24 11:09:10,717 [io-compute-1] DEBUG o.a.d.d.d.DAPodil - whenDone:
completed
java.lang.NullPointerException
at java.base/sun.nio.fs.UnixPath.normalizeAndCheck(UnixPath.java:75)
at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
at
java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
at java.base/java.nio.file.Path.of(Path.java:147)
at java.base/java.nio.file.Paths.get(Paths.java:69)
at
org.apache.daffodil.debugger.dap.DAPodil.$anonfun$setBreakpoints$1(DAPodil.scala:267)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @
org.apache.daffodil.debugger.dap.DAPodil.setBreakpoints(DAPodil.scala:263)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at handleErrorWith @
fs2.Compiler$Target.handleErrorWith(Compiler.scala:161)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Pull$.goEval$1(Pull.scala:1057)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
at flatMap @ fs2.Pull$.fs2$Pull$$interruptGuard$1(Pull.scala:929)
at get @ fs2.internal.Scope.openScope(Scope.scala:281)
at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
On Tue, May 23, 2023 at 5:19 PM Mike Beckerle <mbecke...@apache.org> wrote:
> I really am trying to eval the RC2.
>
> Right now my VMWare Linux system has been broken by recent updates to the
> MS Windows host environment.
>
> I don't exactly understand this, but the VSCode front end can no longer
> connect to the server at localhost:4711. I get ECONNREFUSED. This started
> when a bunch of MS-Windows updates were done on the host OS. I run VSCode
> on the linux client machine, which lives behind a NAT firewall created by
> VMWare workstation - so I really don't get how these could be interacting
> this way, but... there it is.
>
> I will switch back to my standalone linux PC if this isn't resolved today.
>
>
> On Tue, May 16, 2023 at 1:24 PM Shane Dell <shaned...@apache.org> wrote:
>
>> Hello all,I'd like to call a vote to release Apache Daffodil VS Code
>> 1.3.0-rc2.
>>
>> All distribution packages, including signatures, digests, etc. can be
>> found at:
>> https://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/1.3.0-rc2
>>
>> This release has been signed with PGP key
>> 86DDE7B41291E380237934F007570D3ADC76D51B, corresponding
>> to shaned...@apache.org, which is included in the KEYS file here:
>> https://downloads.apache.org/daffodil/KEYS
>>
>> The release candidate has been tagged in git with 1.3.0-rc2. The binaries
>>
>> For reference, here is a list of all closed GitHub issues tagged with
>> 1.3.0:
>> https://github.com/apache/daffodil-vscode/milestone/4?closed=1
>>
>> Please review and vote. The vote will be open for at least 72 hours
>> (Friday, 19 May 2023, 1:30pm EST).
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Documentation for 1.3.0 can be found here
>> Apache Daffodil Extension for Visual Studio Code v1.3.0 Wiki
>> <
>> https://github.com/apache/daffodil-vscode/wiki/Apache-Daffodil%E2%84%A2-Extension-for-Visual-Studio-Code:-v1.3.0
>> >.
>>
>> Please note one of the large features that was focused on in 1.3.0 was
>> improving the data editor. To open the data editor you will need to open
>> the
>> command palette using:
>>
>> - Ctrl + Shift + P (windows/linux)
>> - Command + Shift + P (mac)
>>
>> Then typing "data.edit", make sure "Daffodil Debug: Data Editor" is
>> selected
>> and then hitting enter. By default the data editor will run on port 9000
>> of
>> your machine. However, if you want to use a different port follow steps
>> here
>> Data Editor Launch Settings
>> <
>> https://github.com/apache/daffodil-vscode/wiki/Apache-Daffodil%E2%84%A2-Extension-for-Visual-Studio-Code:-v1.3.0#data-editor-launch-settings
>> >
>>
>> Thank you,
>>
>> - Shane Dell
>>
>
