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://github.com/OpenDFDL/examples) 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://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/1.4.0-rc1 > > 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.4.0-rc1. > > For reference, here is a list of all closed GitHub issues tagged with 1.4.0: > https://github.com/apache/daffodil-vscode/milestone/5?closed=1 > > 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
