Good afternoon Mike,

I had our System Administrators set up an Ubuntu 20.04.6 LTS VM. I did an apt 
update/upgrade to bring all the packages up to date. I installed Gnome desktop, 
Java 11 runtime, and VS Code version 1.91.1.  I downloaded the 
daffodil-vscode-1.4.0 vsix file and installed that in VS Code. I also 
downloaded the helloWorld schema and data file. I opened VS Code and set the 
workspace folder to the directory where I had the helloWorld files. Then I 
created a launch.json file with CTRL+SHIFT+P and set "use existing server" to 
false (and saved the file). I ran the debugger (clicked the debug/start icon on 
the vertical toolbar panel on the left, then selected the green start triangle 
next to the name I gave the configuration in the launch.json file). Once the 
schema and data files opened I tried to create some of the problems you were 
having with the '/' slash, but everything I tried worked correctly.  I didn't 
have any problems with space triggering intellisense suggestions outside of 
element tags.  I also didn't have any problems stepping through the code, or 
with the infoset building in the temporary file. My version of VS Code is 
slightly newer than your version, and I'm not sure if you are running Java 11 
or another version of Java.  But the intellisense code is all 
typescript/javascript so the version of Java shouldn't make any difference.  Is 
it possible your vsix file was corrupted in the download?

Rege

-----Original Message-----
From: Regis Thomas <regis.tho...@nteligen.com>
Sent: Thursday, July 11, 2024 7:36 AM
To: dev@daffodil.apache.org
Cc: 'Johnson, Kirk' (john...@ctc.com) <john...@ctc.com>; Dave Schloss 
<david.schl...@nteligen.com>; Nicholas Lewis <nicholas.le...@nteligen.com>
Subject: RE: [VOTE] Apache Daffodil™ Extension for Visual Studio Code 1.4.0-rc1

Good  morning Mike,

Thanks for the information. I'll setup a VM to run Ubuntu 20.04 and install VS 
Code and the extension.  One thing different regarding the environments I've 
tested on is they are all setup to develop the extension, meaning Java, Scala, 
Node.js, npm, and yarn are all installed.  Presumable they aren't needed to run 
the extension, but it will be a good test to run the extension in an 
environment that doesn't include them.

Rege

-----Original Message-----
From: Mike Beckerle <mbecke...@apache.org>
Sent: Wednesday, July 10, 2024 3:02 PM
To: dev@daffodil.apache.org
Cc: 'Johnson, Kirk' (john...@ctc.com) <john...@ctc.com>; Dave Schloss 
<david.schl...@nteligen.com>; Nicholas Lewis <nicholas.le...@nteligen.com>
Subject: Re: [VOTE] Apache Daffodil™ Extension for Visual Studio Code 1.4.0-rc1

Ok, this is good news Regis.

I seem to have a seriously lead thumb for this system, and that's good, albeit 
frustrating, I guess.

I do have faith that you guys wouldn't have made an RC with this level of 
breakage. So clearly there is some uncontrolled environmental factor at work.

My system is Ubuntu Linux 20.04, with most recent patches.

I had a fairly pristine environment where VSCode had never been installed. I 
did a brand new download of the latest VSCode with nothing installed in it 
except what comes with the basic install.

VSCode "about box" info:

Version: 1.91.0
Commit: ea1445cc7016315d0f5728f8e8b12a45dc0a7286
Date: 2024-07-01T18:52:41.959Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Linux x64 6.5.0-41-generic

I just fired this up, and I can reproduce the "/" clobbering stuff still. So 
it's not a transient anomaly.

There are 2 other extensions installed only. They are "Highlight Matching Tag" 
and "Jar Viewer".  I disabled both. It refuses to disable them as the Apache 
Daffodil plugin depends on them.

What else can I try to help isolate this?

On Tue, Jul 9, 2024 at 3:19 PM Regis Thomas <regis.tho...@nteligen.com> wrote:
>
> Good Afternoon Mike,
>
> Thanks for testing the Daffodil VS Code extension.  I read over the issues 
> you were having with the extension, and tested several of them, but so far I 
> haven't been able to reproduce most of what you are seeing.  I installed the 
> VSIX from the release page in a Windows environment.  I create a new launch 
> json file by opening the palette with CTRL+SHIFT+P then typing config. Then 
> choosing Daffodil Debug:Configure Launch Json.  In order to get the extension 
> to work I had to change the value for "use existing server" to false in the 
> launch.json file.  After creating/editing the file I scrolled down to click 
> the save button.
>
> I downloaded the helloWorld.dfdl.xsd schema and the helloWord.dat file.  When 
> I put a '/' after the first double quote in  <xs:include 
> schemaLocation="org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd" />, it 
> was accepted without a problem.  I can't reproduce any of the problems you 
> reported having with typing a '/'.  I also haven't been able to reproduce the 
> problem where placing a cursor over a space causes an auto-suggestion to 
> display.  Maybe I'm not understanding the steps you took to produce this 
> result.
>
> I don't have dfdl:ref setup as a separate option for format.  It is available 
> for element and group, I can add it for format.  While testing I noticed I 
> also don't have xs:include as a intellisense choice.  I can add that also.
>
> For me typing a space only triggers intellisense (in the helloWord.dfdl.xsd) 
> if I type a space in an element tag, a format tag, or a sequence tag. When I 
> am outside of a tag, CTRL+Space will trigger intellisense, but a typing a 
> space does not.
>
> I also stepped through the schema file to completion.  I watched the infoset 
> build as I stepped through the schema and received a prompt after the 
> stepping process completed to open the infoset.  The infoset that built 
> during the debug stepping process was still visible, but it was named with a 
> temporary name instead of the name defined in the launch.json file.  When I 
> clicked the open button, the infoset opened in a new window with the name 
> from the launch json file, and the temporary infoset was still visible in its 
> own window.
>
> I did not see any intellisense popups while I was stepping through the file.
>
> Can you provide the operating system you used when you had these problems?  I 
> tested with Windows 10, Rocky8 , Rocky9, Rhel9, and Ubuntu 22.04, but I have 
> not seen most of the intellisense issues you describe.
>
> Regis Thomas
> Nteligen, LLC
> 6716 Alexander Bell Drive,
> Suite 120
> Columbia, MD 20146
> (240) 864-5042 x126
> regis.tho...@nteligen.com
>
>
>
> -----Original Message-----
> From: Mike Beckerle <mbecke...@apache.org>
> Sent: Tuesday, July 9, 2024 11:03 AM
> To: dev@daffodil.apache.org
> Subject: Re: [VOTE] Apache Daffodil™ Extension for Visual Studio Code
> 1.4.0-rc1
>
> My vote is -1.
> '
> There are two issues I labeled below as (blocking). There are various other 
> minor and major ones.
>
> Some of the rest is awkwardness that has been there for a while, but in 
> aggregate I think there are numerous things that make this tool still 
> unusable for teaching DFDL to beginners. There are just too many traps one 
> can fall into, and too many unexpected behaviors, places where functionality 
> is hidden but you have to just know where it is hiding, etc. Some of this is 
> due to the server interface to daffodil providing wrong line numbers that the 
> GUI highlights, i.e., not purely GUI/VSCode problems.
>
> Below are notes of my experience trying to use the 1.4.0-rc1. I've tried to 
> label things as (minor), (major), or (blocking) for severity.
> Two are blocking.
>
> I have a brand new computer, never installed VSCode on it. So I started by 
> installing the latest VSCode.
> Then I installed the 1.4.0 visx for the daffodil code extension.
>
> Using the example helloWorld from the OpenDFDL/examples repository
> (https://gi/
> thub.com%2FOpenDFDL%2Fexamples&data=05%7C02%7Cregis.thomas%40nteligen.
> com%7C4abe179411844435a86d08dca112c9d4%7C379c214c5c944e86a6062d047675f
> 02a%7C0%7C0%7C638562349270789544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda
> ta=3Nbj8rCZ0VwBGmxxrqQDY5XRr%2FnXsSX%2Bc60dtPCbqCE%3D&reserved=0)
>
> Open the helloWorld.dfdl.xsd file - it detected it as a DFDL file
> automatically
> (minor): instructions say this must be set manually, it seems that's not the 
> case any longer.
>
> (medium) Hover over attributes of the dfdl:format element, and  "No 
> definition available", even in contexts where if you put your cursor on a 
> space between two attributes it immediately pops up a menu of your choices. 
> This is misleading.
>
> (minor) The choices show as "dfdl:nameOfProperty" even though inside a 
> dfdl:format annotation, the properties are not qualified with that prefix.
>
> (major) No choice is available for dfdl:ref quasi-property (which is present 
> in nearly 100% of DFDL schemas) The vast majority of schemas begin like this:
>
>   <xs:include 
> schemaLocation="/org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd"
> />
>   <xs:annotation>
>     <xs:appinfo source="http://www.ogf.org/dfdl/";>
>       <dfdl:format ref="GeneralFormat"
>          representation="text" encoding="utf-8" lengthKind="delimited"/>
>      </xs:appinfo>
>   </xs:annotation>
>
> Note the xs:include of the daffodil built-in format 
> DFDLGneralFormat.dfdl.xsd, and then the dfdl:format ref="GeneralFormat". This 
> puts the definitions from that include file into use in bulk and then the 
> remaining properties in the dfdl:format just override the ones included via 
> the ref.
>
> (blocking) There is a real problem with "/" being typed. I know it is trying 
> to detect closing the element, but it has to be context sensitive since "/" 
> is such a common character to appear inside strings.
> To reproduce, at the top level of the schema, try typing <xs:include 
> schemaLocation="/ I.e., a string that begins with a "/" character. The GUI 
> refuses to let you do this. It removes the quotation marks and anything 
> you've typed inside them.
> So I tried typing <xs:include schemaLocation="" /> then going back and 
> putting a "/" inside the quotes. Again the editor refuses, removes the 
> quotes, remotes the "/" just typed.
> I tried using single quotes, no improvement.
> I tried typing some characters e.g., 'abc/ It still immediately reacts to the 
> "/" character being typed, and deletes the string and quotation mark.
>
> I re-opened the file from scratch. There is a line like this:
>
> <xs:include 
> schemaLocation="org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd"
> />
>
> I position the cursor before the "org" and type "/", and it removes the 
> entire path.
>
> Interestingly, if I hit ctrl-Z to undo, it puts the text back, including the 
> new leading "/" character. But this is not a workaround.
>
> I looked for a way to turn off or configure the intellisense feature, but did 
> not find anything. This is an option I would like to have regardless of 
> fixing the specific bugs mentioned here. I would always choose to have 
> intellisense require me to hit tab or F1 or some character to invoke it. This 
> hover and it pops up, or type a space and it pops up, that needs to be 
> something one can shut off, and this "No definition available" pop up is 
> utterly annoying.
>
> Moving on to run and debug:
>
> Click right on the helloworld.dfdl.xsd text and choose command palette, and 
> then choose Daffodil debug: run file. If you are going to have icons on the 
> upper right of the DFDL schema editor then why isn't one of them a Run/Debug 
> button? This business of digging through the command palette which is so big 
> it has scroll bars for all the commands, ... is just silly. There is a pull 
> down menu there, but the pre-selected default is "Copy TDML File". The 
> default should be Run File or Debug File.
>
> Anyway... now a dialog pops up requesting a data file. I navigate to
> src/main/resources/helloWorld.dat
>
> (ok) Then a bunch of output on the terminal window. Noise, but at least it 
> tells you something happened.
>
> A line in the schema is highlighted. The debug menu bar shows up.
> (minor) This is very little change on the screen. I was looking around for an 
> error message because I thought it had somehow failed.
> Eventually I saw the highlighted line and the debug tool bar, but honestly at 
> first I didn't realize it had done anything.
> (minor) Can't this debug tool bar default to being docked somewhere, e.g., on 
> the left side, or under the menu bar. I could not figure out how to dock it.
> (major) The menu that says "Copy TDML File", If I use run or debug there, it 
> does not see my most recent launch.json file. Instead it is prompting me for 
> a file like it is still using the originally created launch.json file. Or, 
> maybe it is using the last configuration but overriding the data file 
> selection? I am not sure what this does, but it feels like to me it should 
> just be "Debug" (reusing same schema and same data, and same launch.json 
> settings", or "Run" (ditto on the configuration).
>
> (major) Click on the "step into" choice - fails, dialog in lower right says 
> to show logs. "Unhandled request #12 stepIn ...".
> This is not acceptable. You should not have buttons which if pressed exit the 
> debugger with an error. At minmum have them pop up an "unimplemnted dialog", 
> but then ignore them.
> Or remove the buttons (or grey them) until they are implemented.
>
> In fact the single step behavior of the debugger is closer in meaning
> to step-into than step-over, but only the step-over button does
> anything. I know there are plans to eventually have step over, step
> into, and step out of, as all of those also make sense for DFDL
> debugging. But in the mean time we can't have them causing the
> debugger to fail if the user picks an incorrect one. -
>
> So, I restart the debug. Note that (minor) the output tab at the
> bottom is not cleared. It's easy to think you got a failure again,
> particularly since
> (minor) the first click on the "step over" button does nothing (yellow
> bar does not move, for example down to the root element)
>
> A few messages do print out on the terminal window, but nothing useful.
>
> Click "step over" again, and it steps into the first child element of
> the root element. It never was positioned on the root element (named
> 'helloWorld') really it should be positioned on the root at some point
> so as to make it clear that's what we're parsing. Starting on the
> <xs:schema... > element is not particularly helpful. (This could be a
> daffodil bug. The debugger support should not be reporting the
> xs:schema element as the line-number for anything. The root element's
> line number should be the one provided from the first step.)
>
> (minor)On the left is a collapsible view named "VARIABLES". THis name is 
> misleading. It does not show DFDL variables.
>
> (major) Single stepping doesn't seem to single step.
> A second step-over click. Then on the left the call-stack shows helloWorld 
> twice now. But the yellow bar has not moved. (It should move to line 22, the 
> "helloWorld" element.
>
> Third click: yellow line moves to the "word" element. At this point the 
> infoset should be populated with an empty <word> element, but the infoset is 
> not displayed. Nor is the input data. It's unclear to me what to do in order 
> to display them. GUIs are supposed to have menus to choose from. THe debugger 
> tool bar has nothing on it to address this. The View menu has nothing on it.
>
> (major) I eventually start looking at the small icons on the upper right. I 
> right click. It shows me a number of checked options.  All are checked 
> including the one for displaying the infoset diff. But the infoset diff isn't 
> being displayed. So I unchecked it. And now a diff window appears showing the 
> infoset. But now whatever icon I found that list of checked options on, that 
> icon is now gone. Replaced by icons for the diff panel that is now displayed. 
> I have no idea where to find the menu I just had.
>
> (minor) So I closed the diff and now I have back the button where if I right 
> click I get choices one of which is "Display Infoset View". This is 
> unchecked. So I check it. Nothing happens. I right click again and uncheck 
> it. Again nothing happens.  I eventually figured out that I can right-click 
> anywhere in these icons, and the action is not dependent on which icon. The 
> whole set of icons right-click provides a menu of check-boxes for turning on 
> and off icons appearing in the list there on the upper right. Honestly, all 
> this magic is unnecessary. A single menu with all the options on it would be 
> sufficient and preferable. At minimum all these buttons should be present and 
> you do not need any way to remove any of them. To me they are misplaced here.
> They belong on the debug toolbar and the View menu.
>
> In looking at the launch.json file, I found that the dataEditor log and 
> dfdlDebugger log default to writing into the workspace directory.
> I think they should not default to there, but to a target directory or a 
> tempdir location. Writing files into the project directory feels unwise. 
> Those files will accidently end up committed as part of a schema.
>
> (minor) I continue to get this error
> error parsing launch args: data file at doesn't exist error parsing launch 
> args: data file at doesn't exist But I know the data file DOES exist, and 
> once I found it, I used the launch.json config dialog and selected the file 
> that way. Still this error.
>
> (minor) I modified launch.json to tell it to take the schema and data file 
> from locations inside e.g., 
> ${workspaceFolder}/src/main/resources/helloWorld.dfdl.xsd and 
> "${workspaceFolder}/src/main/resources/helloWorld.dat", and I changed the 
> name of the config to "helloWorld.dat".  But when I run, it still prompts me 
> with a dialog to pick the data file.
>
> (minor) I'm not sure how to tell it to re-read the launch.json file,
> but it seems to have not read it, yet other  places it has.   For
> example the Run icon on the upper left side bar. Click that and it shows the 
> RUN AND DEBUG, and a box with the config names as a pulldown. The name is my 
> new name "helloWorld.dat". When I run from there it correctly uses the new 
> launch.json changes.
>
> (minor) I was looking for the dialog for editing the launch.json using the 
> GUI dialog. It took a long time to find it on the icons on the upper right of 
> the DFDL schema editor panel. Really these icons do not belong here. Their 
> location jumps around too much. They belong on the main View menu.
>
> This launch.json GUI editor really should be the editor for these 
> configurations, not a "wizard" used once when creating them. The 
> add-configuration button should start this dialog, but in addition editing 
> launch.json should run this dialog on a config you select from a list, and a 
> tab should offer the ability to text edit the configuration as an alternative.
>
> (blocking) When I single step and the yellow cursor line moves down the the 
> "word" element at line 25, the intellisense menu pulls down, as if I was 
> typing in the editor at that location. This is more than just distracting. We 
> need a way to tell the difference between the user editing and placing the 
> cursor in a location in order to edit, versus the debugger moving the 
> position. The intellisense should not respond to the debugger moving the 
> current focus, only to the user taking edit actions.
>
> At this point I stopped my evaluation. I'm looking for a tool where when I do 
> DFDL training I can start new users off immediately using this instead of 
> command lines and sbt stuff.
>
> I will do more evaluation once the blocking issues are fixed.
>
>
> On Thu, Jun 20, 2024 at 11:34 AM Shane Dell <shaned...@apache.org> wrote:
> >
> > Hello all,
> >
> > I'd like to call a vote to release Apache Daffodil™ Extension for
> > Visual Studio Code 1.4.0-rc1.
> >
> > All distribution packages, including signatures, digests, etc. can
> > be found at:
> > https://dis/
> > t.apache.org%2Frepos%2Fdist%2Fdev%2Fdaffodil%2Fdaffodil-vscode%2F1.4
> > .0
> > -rc1&data=05%7C02%7Cregis.thomas%40nteligen.com%7C4cfcce7aa04246ee2f
> > 8c
> > 08dca0283d0b%7C379c214c5c944e86a6062d047675f02a%7C0%7C0%7C6385613428
> > 58
> > 519411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > CJ
> > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=ZsNe%2B%2FzHlNqCT
> > 47
> > rrAvp8aeLCnxivU7xUxq%2BVKCqEoo%3D&reserved=0
> >
> > This release has been signed with PGP key
> > 86DDE7B41291E380237934F007570D3ADC76D51B, corresponding to
> > shaned...@apache.org, which is included in the KEYS file here:
> > https://dow/
> > nloads.apache.org%2Fdaffodil%2FKEYS&data=05%7C02%7Cregis.thomas%40nt
> > el
> > igen.com%7C4cfcce7aa04246ee2f8c08dca0283d0b%7C379c214c5c944e86a6062d
> > 04
> > 7675f02a%7C0%7C0%7C638561342858522628%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > oi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7
> > C%
> > 7C%7C&sdata=9FvXzCtCt8jHvVXIUR7muDJya%2ByShVWlWx135Xn8qYY%3D&reserve
> > d=
> > 0
> >
> > The release candidate has been tagged in git with 1.4.0-rc1.
> >
> > For reference, here is a list of all closed GitHub issues tagged with 1.4.0:
> > https://git/
> > hub.com%2Fapache%2Fdaffodil-vscode%2Fmilestone%2F5%3Fclosed%3D1&data
> > =0
> > 5%7C02%7Cregis.thomas%40nteligen.com%7C4cfcce7aa04246ee2f8c08dca0283
> > d0
> > b%7C379c214c5c944e86a6062d047675f02a%7C0%7C0%7C638561342858525493%7C
> > Un
> > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> > aW
> > wiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=eQNbDwMu1UzGNQApEO0qAjuIs4gC
> > X4
> > PEeU2ggm9mIzU%3D&reserved=0
> >
> > Please review and vote. The vote will be open for at least 72 hours
> > (Tuesday, 25 June 2024, 12:00pm EST).
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Documentation for 1.4.0 can be found here
> > https://github.com/apache/daffodil-vscode/wiki/Apache-Daffodil%E2%84%A2-Extension-for-Visual-Studio-Code:-v1.4.0.
> >
> > Thank you,
> >
> > - Shane Dell

Reply via email to