Excellent, I'm glad it's not a JRE version problem since we're on Java 8 to
maximize compatibility across our supported platforms. Also agree with
dropping the JRE bundling for 1.3.0 at least.
Environment isolation and configuration validation updates ought to be
straightforward PRs to review and test. Certainly much simpler than
bundling a JRE!
On Mon, Jun 5, 2023 at 5:20 PM Shane Dell <shaned...@apache.org> wrote:
> Yeah I was wondering if it was documented for that before we back ported
> to support Java 8,
> will try find that and get it updated if so. But thats awesome that isn't
> a Java version issue. I
> agree with dropping the bundle a JVM for now, I think its a cool idea and
> would be interesting. I
> appreciate you jumping on that so quick. I plan on closing this vote here
> today since you -1ed
> with pretty good reasons I think we should do an rc3.
>
>
> On 2023/06/05 21:13:56 Mike Beckerle wrote:
> > I re-tested, and changing to Java 17 in my launch script (with very
> limited
> > set of env vars) works.
> >
> > So the environment interactions I was having are NOT due to the JVM being
> > Java 17.
> >
> > I suspect we can drop the issue of bundling Java with it. I doubt we can
> do
> > that realistically given the license of Java.
> >
> > Really the behavior needs to be that which JVM doesn't affect the
> behavior,
> > even when you have an erroneous configuration of launch.json.
> >
> > The configurations were faulty - daffodilDebugClasspath was incorrect at
> > various points, making it get a NPE when setting breakpoints, etc.
> Getting
> > that right, and realizing that I needed to have BOTH regular files and
> Jar
> > files on the daffodilDebugClasspath was hard-won knowledge.
> >
> > I do recall reading doc that said it requires Java 11, and that's part of
> > why I started creating this isolation environment for it, because it
> wasn't
> > working, and seemed at the time like it might have been a Java 11 vs. 17
> > incompatibility. Clearly it ended up NOT being that.
> >
> > -mikeb
> >
> > On Mon, Jun 5, 2023 at 4:53 PM Mike Beckerle <mbecke...@apache.org>
> wrote:
> >
> > > Well I had sufficient problems with it that I should re-verify if it
> works
> > > with Java 17. It may be that the java version thing was a non-issue
> that
> > > other things were interacting with it.
> > >
> > >
> > > On Mon, Jun 5, 2023 at 4:45 PM Shane Dell <shaned...@apache.org>
> wrote:
> > >
> > >> The extension does not depend on Java 11 it should work fine with Java
> > >> 17. I remember back
> > >> porting to make sure we supported Java 8 also. Other than relying on
> the
> > >> system Java, I am not
> > >> sure how on else we can really on Java. I know Davin mentioned
> packaging
> > >> a JVM or JDK or
> > >> something like that but is that very common practice to do? The only
> time
> > >> I ever heard of doing
> > >> that was for a language server so was wondering if its necessary or
> might
> > >> be overkill. I agree
> > >> with the needing to fix the issue with the environment when it comes
> to
> > >> shell and think what you
> > >> posted will help us do that. However, when it comes to Java I think if
> > >> there is an issue with Java
> > >> 17 we should figure that out first. Then maybe put it out for a vote
> or
> > >> something about bundling
> > >> a Java version with the extension and then letting the user specify a
> > >> different path to Java or
> > >> something like that?
> > >>
> > >>
> > >> On 2023/05/31 23:02:03 Mike Beckerle wrote:
> > >> > So, I have the 1.3.0 RC2 vscode extension debugger working now for
> PCAP
> > >> w/
> > >> > ethernetIP and I can set a breakpoint in ethernetIP.dfdl.xsd and I
> no
> > >> > longer get an NPE.
> > >> >
> > >> > Configuring this is really far too difficult, and I have to have the
> > >> schema
> > >> > working first with sbt in order to even hope to configure it.
> > >> >
> > >> > But I'll get back to that later.
> > >> >
> > >> > More basic issue is that I am unable to debug even dead-simple
> errors
> > >> with
> > >> > it. I clobbered the magic number in the first bytes of an icmp1.cap
> > >> file.
> > >> > This fails an assert at line 97 of pcap.dfdl.xsd, which is the first
> > >> > element of simple type.
> > >> >
> > >> > I step through with the debugger, and nothing displays *anything*
> about
> > >> the
> > >> > assert failure. Execution ends. A little pop-up dialog says it
> wrote my
> > >> > infoset out, which it didn't. There's nothing showing that anything
> went
> > >> > wrong. All panels on the left are blank.
> > >> >
> > >> > If I modify the schema and make any mistake, then I get a blocking
> > >> dialog
> > >> > showing the SDEs. This is basically intolerable, and is why I have
> to go
> > >> > back to sbt to debug this. You can't even go through the SDEs as you
> > >> move
> > >> > the editor. It's a blocking dialog.
> > >> >
> > >> > So both for schema compilation, and runtime errors there simply has
> to
> > >> be a
> > >> > non-modal display of errors, probably on the left with variables,
> watch,
> > >> > call-stack, and breakpoints. But a quasi-edit-buffer containing them
> > >> would
> > >> > also be fine, or even just output them to the terminal window.
> > >> >
> > >> > The rest of this email is about the hoops I had to jump through to
> get
> > >> this
> > >> > to work at all. Arguably, these issues are about working with a
> > >> > multi-component schema, and we could define our objectives to
> simpler
> > >> > schemas than this, but that puts it in the realm of toy-only
> schemas.
> > >> The
> > >> > example is just PCAP + ethernetIP, which is not an extreme example.
> > >> >
> > >> > The existing shell environment of the terminal definitely causes
> > >> problems.
> > >> > But just exiting that so that the debugger starts a new terminal
> doesn't
> > >> > fix it, as that inherits the environment from where vscode was
> started.
> > >> It
> > >> > starts a new login shell unless you take steps to prevent that.
> > >> >
> > >> > A big trip-up in usability is that the wizard that creates the
> > >> launch.json,
> > >> > doesn't actually let you populate the daffodilDebugClaspath. You
> have to
> > >> > edit that by hand, and nothing verifies it, so any typo and you get
> > >> tedious
> > >> > failures that are hard to figure out. You just get an SDE - if you
> are
> > >> > lucky - via a blocking dialog.
> > >> >
> > >> > The wizard should help you put directories and corresponding jars
> on the
> > >> > daffodilDebugClasspath, and it should not let you put a non-existing
> > >> > directory or jar file on it. Ideally, at launch time the
> > >> > daffodilDebugClasspath should be checked, just in case something on
> it
> > >> no
> > >> > longer exists.
> > >> >
> > >> > If the debugger happens to find a file on the
> daffodilDebugClasspath in
> > >> a
> > >> > jar, vs. in a regular directory (maybe you have a typo in the
> regular
> > >> > directory path), so it passes that and hits the jar, then setting a
> > >> > breakpoint causes a NPE. Something requires a "hierarchical URL"
> which a
> > >> > jar-file URL is not. This is the bug that really has to be fixed so
> that
> > >> > you can set breakpoints regardless of whether the source DFDL schema
> > >> file
> > >> > was in a jar or not.
> > >> >
> > >> > Note: at Owl we have DFDL schemas where the starting root element
> of the
> > >> > schema isn't even part of the schema, it's part of a component
> schema
> > >> that
> > >> > is in a jar on the classpath. This happens when you have an
> > >> > envelope-payload idiom. The schema that combines the envelope and
> > >> payload
> > >> > together contains only the glue part that connects the two
> together. The
> > >> > root element is the envelope's root element, and that schema is in
> a jar
> > >> > file.
> > >> >
> > >> > I did not see any feature in launch.json for specifying the
> > >> name/namespace
> > >> > of the root element. There is just the "program" element, which
> must be
> > >> to
> > >> > a file in the current schema. That needs to be able to be specified
> > >> just as
> > >> > element name + namespace.
> > >> >
> > >> > The jars have to be on the daffodilDebugClasspath because of the
> plugins
> > >> > that daffodil must find in them. That's understandable, the problem
> is
> > >> > having to also have a regular file location for any schema you want
> to
> > >> be
> > >> > able to put a breakpoint in and it must be before the corresponding
> jar.
> > >> >
> > >> > That all said, here are the scripts and settings I used to get it to
> > >> work:
> > >> >
> > >> > First, I have this script I use to launch vscode in a minimal/empty
> > >> > environment. This technique is useful to
> > >> > determine if you are depending on the environment in any way:
> > >> >
> > >> > #! /bin/bash
> > >> > if [ "$1" = "emptyEnv" ] # is it the special first arg
> > >> > then
> > >> > shift # discard special first arg, and continue with the rest of
> the
> > >> > script
> > >> > else
> > >> > CMD=$0
> > >> > exec -c $CMD "emptyEnv" $* # exec with an empty environment,
> special
> > >> > first arg
> > >> > fi
> > >> > # the environment is empty when we get here
> > >> > # just add env vars we need to get vscode to work
> > >> > export LANG=en_US.UTF-8
> > >> > export HOME=/home/mbeckerle
> > >> > export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 # java 11
> required
> > >> > export PATH=$JAVA_HOME/bin:$PATH
> > >> > export DISPLAY=:0
> > >> > export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus #
> vscode
> > >> spits
> > >> > lots of errors without this
> > >> > exec /usr/bin/code
> > >> > # end
> > >> >
> > >> > Then, within ~/.config/Code/User/settings.json, I had to create
> these
> > >> > settings for terminal:
> > >> >
> > >> > "terminal.integrated.inheritEnv": false,
> > >> > "terminal.integrated.profiles.linux": {
> > >> > "Custom Init": {
> > >> > "path": "/bin/bash",
> > >> > "args": [
> > >> > "--norc"
> > >> > ]
> > >> > }
> > >> > },
> > >> > "terminal.integrated.defaultProfile.linux": "Custom Init"
> > >> >
> > >> > That instructs vscode not to create a login shell for the terminal.
> The
> > >> > --norc option means it does not run the .bashrc file so that the
> java
> > >> > version specified in the launch script sticks.
> > >> >
> > >> > I am not sure the inheritEnv setting actually does anything. That
> alone
> > >> > sounds like the right thing, but that alone didn't solve the
> problem.
> > >> > You still have everything in the login shell environment where
> vscode
> > >> was
> > >> > launched. Hence the need for the environment-emptying launch script.
> > >> >
> > >> > With those two things, a terminal created by vscode does not inherit
> > >> > everything my typical shell has. For example there is no daffodil
> on the
> > >> > path, no DAFFODIL_CLASSPATH env var, etc.
> > >> >
> > >> > Given the above if I just create a terminal with Terminal > new
> > >> Terminal:
> > >> > The environment is relatively simple:
> > >> >
> > >> > bash-5.0$ env
> > >> > COLORTERM=truecolor
> > >> > TERM_PROGRAM_VERSION=1.78.2
> > >> > JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
> > >> > NO_AT_BRIDGE=1
> > >> > PWD=/home/mbeckerle/dataiti/opensource/DFDLSchemas/PCAP
> > >> > VSCODE_GIT_ASKPASS_NODE=/usr/share/code/code
> > >> > HOME=/home/mbeckerle
> > >> > LANG=en_US.UTF-8
> > >> >
> GIT_ASKPASS=/usr/share/code/resources/app/extensions/git/dist/askpass.sh
> > >> > CHROME_DESKTOP=code-url-handler.desktop
> > >> > VSCODE_GIT_ASKPASS_EXTRA_ARGS=--ms-enable-electron-run-as-node
> > >> > TERM=xterm-256color
> > >> > VSCODE_GIT_IPC_HANDLE=/tmp/vscode-git-56a269c0f5.sock
> > >> > DISPLAY=:0
> > >> > SHLVL=1
> > >> >
> > >>
> VSCODE_GIT_ASKPASS_MAIN=/usr/share/code/resources/app/extensions/git/dist/askpass-main.js
> > >> > GDK_BACKEND=x11
> > >> >
> > >>
> PATH=/usr/lib/jvm/java-11-openjdk-amd64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> > >> > ORIGINAL_XDG_CURRENT_DESKTOP=undefined
> > >> > DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
> > >> > TERM_PROGRAM=vscode
> > >> > _=/usr/bin/env
> > >> >
> > >> > If I run daffodil, then c-C in the terminal it creates, then the
> > >> > environment has this added environment variable only.
> > >> >
> > >> >
> > >>
> DAFFODIL_DEBUG_CLASSPATH=/home/mbeckerle/dataiti/opensource/DFDLSchemas/PCAP/../ethernetIP/src/main/resources:/home/mbeckerle/dataiti/opensource/DFDLSchemas/PCAP/lib_managed/jars/com.owlcyberdefense/dfdl-ethernetip/dfdl-ethernetip-1.2.0.jar
> > >> >
> > >> > This works. My launch.json is attached.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, May 26, 2023 at 2:06 PM Shane Dell <shaned...@apache.org>
> > >> wrote:
> > >> >
> > >> > > Mike,
> > >> > >
> > >> > > The VSCode Extension should be using the daffodil command that is
> > >> bundled
> > >> > > with the
> > >> > > extension. The issue might still be with that shell env variable
> you
> > >> have
> > >> > > for
> > >> > > DAFFODIL_CLASSPATH, but this might only be an issue with a
> terminal
> > >> that
> > >> > > is already opened
> > >> > > with the name "daffodil-debugger". If you close that terminal, the
> > >> next
> > >> > > you time you run it should
> > >> > > create a new terminal with the env set properly. If you could try
> > >> this and
> > >> > > see if it works how you
> > >> > > expect, that would help us single out this issue out to an already
> > >> active
> > >> > > terminal.
> > >> > >
> > >> > > Thank you,
> > >> > >
> > >> > > Shane Dell
> > >> > >
> > >> > >
> > >> > > On 2023/05/25 23:59:53 Mike Beckerle wrote:
> > >> > > > There are so many environment interactions....
> > >> > > >
> > >> > > > So I have discovered that the VSCode extension just seems to run
> > >> whatever
> > >> > > > daffodil command is on the path. It's not isolated at all from
> the
> > >> shell
> > >> > > > environment.
> > >> > > >
> > >> > > > I found this out because I have a customized daffodil shell
> script
> > >> that
> > >> > > > setups a bunch of DAFFODIL_CLASSPATH contents, and I couldn't
> > >> figure out
> > >> > > > why those were part of the VSCode environment.
> > >> > > >
> > >> > > > Shouldn't vscode run exactly the daffodil bundled with it,
> unless
> > >> you
> > >> > > > explicitly configure it not to?
> > >> > > >
> > >> > > > That's why it is finding the ethernetIP.dfdl.xsd file in the
> jar,
> > >> not in
> > >> > > > the file system. Because my daffodil command sets up lots of
> jars
> > >> on the
> > >> > > > DAFFODIL_CLASSPATH.
> > >> > > >
> > >> > > > It also depends on Java 11, breaks with Java 17. I also don't
> think
> > >> this
> > >> > > > should be inherited from the environment.
> > >> > > >
> > >> > > > I really have a hard time using, or even testing the VSCode
> > >> extension if
> > >> > > I
> > >> > > > have to scrub my shell environment of everything in it in order
> to
> > >> make
> > >> > > the
> > >> > > > vscode extension work.
> > >> > > >
> > >> > > > But it is this kind of problem that caused people to invent
> docker
> > >> > > > containers.
> > >> > > >
> > >> > > > I am going to make a launcher script for VSCode that empties the
> > >> > > > environment, then supplies only what is absolutely necessary,
> with
> > >> no
> > >> > > > outside environment assumptions.
> > >> > > >
> > >> > > > I will try to do this Friday if possible.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Wed, May 24, 2023 at 2:50 PM Shane Dell <
> shaned...@apache.org>
> > >> wrote:
> > >> > > >
> > >> > > > > Mike,
> > >> > > > >
> > >> > > > > I am not sure why you would be seeing this. I am able to set
> the
> > >> > > > > breakpoint where you
> > >> > > > > mentioned without any issues. Can you try removing the
> > >> daffodil-dap
> > >> > > > > folder? This should be
> > >> > > > > somewhere like:
> > >> > > > > /home/$USER/.local/share/daffodil-dap
> > >> > > > > The issue I am thinking is possibly a bug with the rc1
> debugger
> > >> that
> > >> > > may
> > >> > > > > not be present on rc2.
> > >> > > > > But if the folder daffodil-dap/daffodil-debugger-3.4.0-1.3.0/
> > >> already
> > >> > > > > exists from rc1 then rc2 will
> > >> > > > > not remake it. So in order to remake it you have to manually
> > >> remove
> > >> > > this
> > >> > > > > folder. Let me know if
> > >> > > > > this helps.
> > >> > > > >
> > >> > > > > Thank you,
> > >> > > > >
> > >> > > > > Shane Dell
> > >> > > > >
> > >> > > > > On 2023/05/24 15:15:33 Mike Beckerle wrote:
> > >> > > > > > 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
> > >> > > > > > >>
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
