You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "arosien (via GitHub)" <gi...@apache.org> on 2023/03/08 20:31:22 UTC
[GitHub] [daffodil-vscode] arosien opened a new issue, #471: Debugging extension in dev environment doesn't unpack current backend build
arosien opened a new issue, #471:
URL: https://github.com/apache/daffodil-vscode/issues/471
Debugging the extension launches `yarn watch` which does a `sbt universal:packageBin` which builds the backend, but the newly built backend isn't installed into the local XDG directory, so whatever release was previously installed there (from an official release, etc.) will be used. This causes confusion if you are expecting the existing backend code to be run.
Workaround: delete your `daffodil-dap` XDG directory and the extension will look in the current directory to install the local backend. (FYI, the tests unpack the current backend build into a custom directory and point the extension to there.)
Fix: do this install during the extension build.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] Shanedell commented on issue #471: Debugging extension in dev environment doesn't unpack current backend build
Posted by "Shanedell (via GitHub)" <gi...@apache.org>.
Shanedell commented on issue #471:
URL: https://github.com/apache/daffodil-vscode/issues/471#issuecomment-1473982366
Yeah so all of the jars would still be jars and not be extracted. So what I am referring to is we currently bundle zip file created from running `sbt universal:packageBin`. I think we should actually extract that zip and bundle the folder, which has a name like `daffodil-debugger-${daffodil_version}-${extension_version}`. Inside of that folder it has a `bin` and `lib` folder for running the debugger and all of the jars needed, those would stay untouched.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] shanedell commented on issue #471: Debugging extension in dev environment doesn't unpack current backend build
Posted by "shanedell (via GitHub)" <gi...@apache.org>.
shanedell commented on issue #471:
URL: https://github.com/apache/daffodil-vscode/issues/471#issuecomment-1592063877
Possibly add a flag to `.vscode/launch.json` something like `devMode: (true/false)`. This will make it so in the future if we need to be able to do one thing during development and not in production. This would make it so we use one variable instead of a bunch of different one for each item that comes out.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] mbeckerle commented on issue #471: Debugging extension in dev environment doesn't unpack current backend build
Posted by "mbeckerle (via GitHub)" <gi...@apache.org>.
mbeckerle commented on issue #471:
URL: https://github.com/apache/daffodil-vscode/issues/471#issuecomment-1473931130
I don't understand what you mean by "unzipped debugger". You mean the Daffodil DAP server and all the Daffodil library jars it uses?
If the main daffodil library jars are being redistributed as part of the VSCode Extension, then those should still be jars, and not further unzipped from that form. I.e., jars stay jars. One should be able to verify they are the exact right jars also corresponding to an official distribution (for official distributions of the VSCode Extension that is. Development snapshot versions can contain snapshot jars.)
Do we also bundle in all the dependent library jars? I assume so. Same rule applies - jars stay jars. But higher levels of packaging surrounding those, I'm not sure it matters how that's organized.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] Shanedell commented on issue #471: Debugging extension in dev environment doesn't unpack current backend build
Posted by "Shanedell (via GitHub)" <gi...@apache.org>.
Shanedell commented on issue #471:
URL: https://github.com/apache/daffodil-vscode/issues/471#issuecomment-1473725967
I believe when initially setting things up, we made it so that if the folder for the specific version of the debugger and daffodil being used already exists we wouldn't recreate it. I agree that when doing updates to the debugger this would cause issues.
We can either:
- 1. Always extract the debugger.
- 2. Create a setting that lets the extension know it should re-extract the debugger.
- 3. Have logic in the code that tries to figure out when the debugger is running through a VSIX or locally and based upon decides if should extract/re-extract or not. Basically if VSIX -> don't extract if folder present, if locally -> always extract.
There is also a conversation to be had that we could bundle the extracted debugger package instead of the zip. This should allow us to have any newly updated debugger unzipped at the same location of the zip and the extension will know where to grab it, this should also work when dealing with running from an VSIX file. This would also simplify code so that we don't need to be doing extracts, copies, etc of the debugger to different locations. Another benefit is when running a new version of the debugger either locally or through VSIX or in tests, the first launch will happen much quicker since you would no longer be waiting for checks if the folder already exists as well as the extraction of the zip to happen.
I personally think we should move away from bundling and having the cod extract the zipped up debugger, and instead bundle the extracted debugger package.
@mbeckerle @stevedlawrence would bundling the unzipped debugger go against any Apache workflow norms or standards?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] shanedell closed issue #471: Debugging extension in dev environment doesn't unpack current backend build
Posted by "shanedell (via GitHub)" <gi...@apache.org>.
shanedell closed issue #471: Debugging extension in dev environment doesn't unpack current backend build
URL: https://github.com/apache/daffodil-vscode/issues/471
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] scholarsmate commented on issue #471: Debugging extension in dev environment doesn't unpack current backend build
Posted by "scholarsmate (via GitHub)" <gi...@apache.org>.
scholarsmate commented on issue #471:
URL: https://github.com/apache/daffodil-vscode/issues/471#issuecomment-1481313781
@Shanedell extract the zip and bundle the folder. We did this for the Ωedit server and it's much simpler to use without having to fuss with unzipping it somewhere, fixing permissions, etc., and we are using _more_ storage for no benefit whatsoever. Also when upgrading, you're not leaving the old orphaned artifacts littering the storage which is bad for the user. The compressed archives aren't gaining us anything but problems and complexity.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org