I don't think we necessarily need to support "daffodil dap". I think
this is just a nice side effect of bundling everything in the main repo.
But if it poses technical challenges I don't think it's worth it.
I would like us to at least have an idea about how release/publish/VS
Code integration will work if we do separate repos. It doesn't sound
trivial to me.
On 7/20/22 9:39 AM, Interrante, John A (GE Research, US) wrote:
The motivation for putting dap into the main daffodil repo is that bundling dap into the
daffodil cli (allowing "daffodil dap" to start dap) will simplify configuring
the VS Code debugger extension to work with different daffodil and dap versions.
I suggest that there is almost certainly a way to put dap into its own repo while still allowing
"daffodil dap" to start a compatible dap version. I will let others figure out the most
optimal method, but I don't see any technical obstacle that would prevent "daffodil dap"
from starting a compatible dap version and therefore simplifying configuring the VS Code debugger
extension.
-----Original Message-----
From: Mike Beckerle <mbecke...@apache.org>
Sent: Wednesday, July 20, 2022 9:05 AM
To: dev@daffodil.apache.org
Subject: EXT: Re: Daffodil Debugger Scala Source Code
WARNING: This email originated from outside of GE. Please validate the sender's
email address before clicking on links or attachments as they may not be safe.
I think putting dap into the main daffodil repo is a false economy.
Consider:
1) more sbt hacks to exclude the tests of the dap from 'sbt test' and to add an
alternative 'sbt dap:test' which runs those tests.
2) that won't work with IDEs automatically, so they will be unable to run the
dap tests without renaming directories or such.
(CLI has this same problem today. I do not yet have a convenient workaround for
this, and it is a pain in the neck routinely)
3) another module inside daffodil to compile when 'sbt compile' is issued.
So more delay in the routine edit-compile-debug cycle.
4) more IDE customizations to save that extra compilation time when doing IDE
builds.
The above is a huge hassle to maintain compared with one more repo that is
completely ordinary with respect to build configuration, IDE support, etc.
Creating a separate repo has none of these drawbacks. 'sbt test' can work
normally to test it. Tests live in src/test as normal. No need for special
exclusions or sbt hackery.
IDEs will do the right thing by default.
On Tue, Jul 19, 2022 at 4:51 PM Steve Lawrence <slawre...@apache.org> wrote:
DAP stands for Debug Adapter Protocol:
https://microsoft.github.io/debug-adapter-protocol/
If the goal is to simplify development, then including the dap stuff
in the main repo with the CLI would probably make things the simplest.
Just
run:
sbt daffodil-cli/stage
in the daffodil repo, and then point VS Code to execute "daffodil dap
.." using the staged files (i.e.
daffodil-cli/target/universal/stage/bin/daffodil). We may need changes
in the VS Code to support alternative locations of the daffodil
binary, but I think that's something we want to support anyways to
allow testing different versions of Daffodil without having to install
a different extension.
On 7/19/22 4:10 PM, Mike Beckerle wrote:
I am leaning toward a separate repo (called daffodil-dap-server)
which
uses
(depends on) daffodil.
(btw: what does DAP stand for again? Daffodil Access Protocol ?)
This is for separation of concerns. I'd like daffodil proper
libraries to be about DFDL mostly, though it does contain the basic
CLI. Things having to do with client/server and testing of the
server side in isolation,
etc.
all that belongs only in the daffodil-dap-server which people fixing
ordinary DFDL/Daffodil bugs don't test when they run 'sbt test'.
I do think the server is going to be quite coupled to Daffodil internals.
For example, to provide better visual animation of delimiter
scanning we will need new debug hooks providing visibility or
callbacks from those parse operations, and DAP will then want to
make this available to the vscode front end for proper
visualization. Similar story is needed around animating what goes on
with unparsing and suspend/resume of expressions, etc. I expect we
will create internal-only versions of these features before we try to firm up
any published APIs for them.
It is pretty important for me to be able to easily and quickly point
VSCode
at a new DAP server that is depending on a locally updated daffodil.
But I think something like this is sufficiently easy:
... fix a bug in daffodil then
cd daffodil
sbt test
sbt publishLocal // creates a snapshot such as 4.2.1-SNAPSHOT
cd dap-server
sbt test // runs test rig to check out DAP server in isolation
from front end // has dependency on daffodil 4.2.1-SNAPSHOT
sbt package // or publishLocal or... // has dependency on
daffodil 4.2.1-SNAPSHOT
... then start VSCode using updated configuration file giving
dap-server
package location
On Tue, Jul 19, 2022 at 3:13 PM Steve Lawrence
<slawre...@apache.org>
wrote:
Some other positives if DAP were combined it into the existing CLI:
There was once talk of making it so the the VS Code debugger could
switch between different Daffodil versions. If it were part of the
CLI, this just means downloading a new version of the Daffodil CLI
and pointing VS Code to it--that process could either be manual or
automated in the VS Code settings.
I think this would also make it easier to test Daffodil snapshots
with the VSCode extension? I believe the current process requires
you to publishLocal a Daffodil snapshot, then update the
daffodil-vscode repo (or if we split it, the daffodil-debugger
repo) to have the snapshot version, and the build that. If it was
all part of the CLI, you could just run "sbt stage" in the Daffodil
repo and point VSCode to those staged files. It only avoids a
couple extra steps, but if you do it frequently it would be nice.
On 7/19/22 2:15 PM, Steve Lawrence wrote:
+1 to this
I was thinking the same thing as I read this. My only thought is
using "daffodil dap" since the debug server is just a thing that
implements the DAP protocol, and theoretically it could be used
any any IDE that supports DAP (I think?). But the name is the easy part.
My only other (minor) concern is that this pulls in a number of
dependencies. It's not an issue from a licensing perspective since
we know they are fine, but it does make the CLI release a bit
bigger and more to manage, e.g. lots of Cats jars. I suspect it's
not enough to really matter (and most of the size is probably
daffodil jars), but if we do go this route, during or prior to
migration it might be worth looking to see if anything can be
replaced. For example, one thing that jumps out is VSCode debugger
currently depends on logback for logging, but daffodil use log4j.
The other concern is that currently the VS Code stuff can sort of
develop at its own pace. If we integrate the DAP portion into the
CLI, it means VSCode can't get DAP updates without a Daffodil
release. But
it
seems DAP is fairly stable, and as long as we keep a quick release
cycle
and plan accordingly, that shouldn't be too much of an issue.
I would perfer this approach over creating a new repo. It's a bit
less to keep track of, and makes it easier to ensure we don't have
any breaking changes with changes to Daffodil.
On 7/19/22 1:52 PM, Mike Beckerle wrote:
I think of this as a daffodil server mode, for the front end
VSCode
stuff
to use.
So, is it plausable to add the code to daffodil proper. Make it a
CLI command mode to start up this server, so that
daffodil vscodeServer
starts it, optionally with connection options like what ports to
use, etc.
On Tue, Jul 19, 2022 at 1:45 PM Shane Dell <shaned...@apache.org>
wrote:
All,
This thread is to discuss splitting out the code for the Apache
Daffodil
Scala Debugger from the apache/daffodil-vscode repository. The
two options would be:
- 1.) Move the debugger source code into the apache/daffodil repo.
However,
will this work because the debugger code depends on certain
daffodil Scala libraries to be published? This is mostly an
option since both are mostly/fully Scala based.
- 2.) Create a new repo (apache/daffodil-debugger?,
apache/daffodil-debugger-scala?) where the Scala code will live.
This would be helpful as the apache/daffodil-vscode repo is
heavily based on creating the VS Code extension for Daffodil.
With this the
debugger
source code is rarely updated, when it is they are pretty minor
fixes
or
dependency updates. Currently it is a bit of a cluster having a
mix
of
node/JavaScript/TypeScript and Scala which causes an issue with
dependency bots checking as these are checking for both npm and
sbt/Scala dependencies, causing many PRs to be made. The
extension code also runs a sbt universal:packageBin command in
multiple occurences, being able
to
remove this and downloading the debugger package would simplify
a
couple
different processes for the extension.
My personal vote is for creating a new repo called something
like
either
apache/daffodil-debugger or apache/daffodil-debugger-scala.
Sincerely,
Shane Dell
