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 > >>> > >> > > > >
