You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@daffodil.apache.org by Davin Shearer <da...@apache.org> on 2023/07/07 15:00:00 UTC
Planning Apache Daffodil Extension for VS Code v1.3.1
Greetings Daffodil developers and users!
As v1.3.0 of the Apache Daffodil Extension for VS Code has been officially
released, it’s time to plan the next release.
Since v1.3.0 was a huge feature release compared to v1.2.0, I propose that
we do a smaller (e.g., v1.3.1) release *before *we jump into v1.4.0. This
allows for some recovery and implementation of some short-term, but
important improvements, to set the stage for a larger release to follow. Since
1.3.1 can be smaller in scope, let’s try to target a release for August
2023, then a larger one (e.g., v1.4.0) targeted for the fall
(October/November).
Some features that I think would be appropriate for the smaller v1.3.1
release targeted for this summer would include:
Data Editor:
• Merge single and multi-byte modes so they don’t need to be
manually selected, for example, if one byte is selected, then the Data
Editor should be automatically in single byte mode, and if more than one
byte is selected, the Data Editor should automatically switch into
muti-byte editing mode.
• Add support for large file editing in the Data Editor (e.g.,
being able to scroll and search around in large files -
https://github.com/ctc-oss/daffodil-vscode/discussions/95).
• Being able to persist selections *after *the viewport loses focus.
• Implement “Save As” in addition to “Save”.
• Incremental Search and Replace (currently Replace All is
implemented).
• Ability to have multiple simultaneous Data Editors opened sharing
the same backend server (currently only one Data Editor can be opened at
one time).
• Ability to view and edit bytes represented in binary where the
most significant bit can be the first bit of the byte, or the last bit of
the byte.
• Content-type discovery using Apache Tika.
• Initial implementation of a data profiler.
• Allow the values in the data inspector to be editable.
• Have an “overwrite only” mode that will keep the file size the
same, even when performing operations like Search and Replace where the
token sizes aren’t the same.
IntelliSense:
• Add additional/missing attribute completion snippets.
• Refine snippet suggestions for specific element tags.
• Refine the handling of auto-complete closing tags for multi-line
attributes (attribute split on multiple lines).
• Setup IntelliSense unit *test *infrastructure.
• Add semantic highlighting for XPath expressions.
Reply to this thread if there are any other reasonably-small features that
you would like to see implemented in v1.3.1 and/or thoughts about the
release scheduling proposed here.
Work on many of these items is already underway since the release cycle for
v1.3.0 took 4 candidates before it was approved. The development team is
tracking progress on the next release here:
https://github.com/orgs/apache/projects/258/views/1.
Thank you!
Re: Planning Apache Daffodil Extension for VS Code v1.3.1
Posted by Mike Beckerle <mb...@apache.org>.
This looks like a fairly long list for a 1.3.1
Getting rid of the excess debug/info output to the terminal, so that you
can find errors in it more easily is my priority 1 feature need, and feels
like a 1.3.1 kind of change.
Next would be avoiding the jumping back and forth between enclosing
elements and child elements is pretty important. Right now every other step
jumps back to the enclosing parent element.
Longer term I think one thing we should try to plan is for the editor or
(hex/bits display) highlighting of bytes/bits to track the infoset when
debugging. I.e., when parsing, placing cursor on a specific infoset element
should display the bits corresponding to it in the editor (or hex/bits
display), and vice versa. This will require a richer infoset
representation that exposes this information for use by the GUI, as opposed
to just dumping out XML that is then displayed.
This will require a daffodil enhancement to have state maintain the start
position and length (in bits) of every element in the infoset.
Another important thing is refactoring the delimiter scanning logic in
Daffodil such that it is exposed for the debugger to display - users should
be able to step through every nuance of scanning for a delimiter -
displaying the set of delimiters it is looking for, whether it found one
and which or not, highlighting the data that was isolated by this, etc.
In general, each lengthKind in DFDL could use specific GUI support - e.g.,
lengthKind prefixed should display the length that has been discovered,
highlight that part of the data for you, then use it to extract the value.
Each lengthKind has its own support needs to make it clear for the user
what is happening (or going wrong)
But we should start with delimiter scanning.
On Fri, Jul 7, 2023 at 11:01 AM Davin Shearer <da...@apache.org> wrote:
> Greetings Daffodil developers and users!
>
>
>
> As v1.3.0 of the Apache Daffodil Extension for VS Code has been officially
> released, it’s time to plan the next release.
>
>
>
> Since v1.3.0 was a huge feature release compared to v1.2.0, I propose that
> we do a smaller (e.g., v1.3.1) release *before *we jump into v1.4.0. This
> allows for some recovery and implementation of some short-term, but
> important improvements, to set the stage for a larger release to follow. Since
> 1.3.1 can be smaller in scope, let’s try to target a release for August
> 2023, then a larger one (e.g., v1.4.0) targeted for the fall
> (October/November).
>
>
>
> Some features that I think would be appropriate for the smaller v1.3.1
> release targeted for this summer would include:
>
>
>
> Data Editor:
>
> • Merge single and multi-byte modes so they don’t need to be
> manually selected, for example, if one byte is selected, then the Data
> Editor should be automatically in single byte mode, and if more than one
> byte is selected, the Data Editor should automatically switch into
> muti-byte editing mode.
>
> • Add support for large file editing in the Data Editor (e.g.,
> being able to scroll and search around in large files -
> https://github.com/ctc-oss/daffodil-vscode/discussions/95).
>
> • Being able to persist selections *after *the viewport loses
> focus.
>
> • Implement “Save As” in addition to “Save”.
>
> • Incremental Search and Replace (currently Replace All is
> implemented).
>
> • Ability to have multiple simultaneous Data Editors opened
> sharing the same backend server (currently only one Data Editor can be
> opened at one time).
>
> • Ability to view and edit bytes represented in binary where the
> most significant bit can be the first bit of the byte, or the last bit of
> the byte.
>
> • Content-type discovery using Apache Tika.
>
> • Initial implementation of a data profiler.
>
> • Allow the values in the data inspector to be editable.
>
> • Have an “overwrite only” mode that will keep the file size the
> same, even when performing operations like Search and Replace where the
> token sizes aren’t the same.
>
>
>
> IntelliSense:
>
> • Add additional/missing attribute completion snippets.
>
> • Refine snippet suggestions for specific element tags.
>
> • Refine the handling of auto-complete closing tags for
> multi-line attributes (attribute split on multiple lines).
>
> • Setup IntelliSense unit *test *infrastructure.
>
> • Add semantic highlighting for XPath expressions.
>
>
>
> Reply to this thread if there are any other reasonably-small features that
> you would like to see implemented in v1.3.1 and/or thoughts about the
> release scheduling proposed here.
>
>
>
> Work on many of these items is already underway since the release cycle
> for v1.3.0 took 4 candidates before it was approved. The development
> team is tracking progress on the next release here:
> https://github.com/orgs/apache/projects/258/views/1.
>
>
> Thank you!
>
Re: Planning Apache Daffodil Extension for VS Code v1.3.1
Posted by Mike Beckerle <mb...@apache.org>.
This looks like a fairly long list for a 1.3.1
Getting rid of the excess debug/info output to the terminal, so that you
can find errors in it more easily is my priority 1 feature need, and feels
like a 1.3.1 kind of change.
Next would be avoiding the jumping back and forth between enclosing
elements and child elements is pretty important. Right now every other step
jumps back to the enclosing parent element.
Longer term I think one thing we should try to plan is for the editor or
(hex/bits display) highlighting of bytes/bits to track the infoset when
debugging. I.e., when parsing, placing cursor on a specific infoset element
should display the bits corresponding to it in the editor (or hex/bits
display), and vice versa. This will require a richer infoset
representation that exposes this information for use by the GUI, as opposed
to just dumping out XML that is then displayed.
This will require a daffodil enhancement to have state maintain the start
position and length (in bits) of every element in the infoset.
Another important thing is refactoring the delimiter scanning logic in
Daffodil such that it is exposed for the debugger to display - users should
be able to step through every nuance of scanning for a delimiter -
displaying the set of delimiters it is looking for, whether it found one
and which or not, highlighting the data that was isolated by this, etc.
In general, each lengthKind in DFDL could use specific GUI support - e.g.,
lengthKind prefixed should display the length that has been discovered,
highlight that part of the data for you, then use it to extract the value.
Each lengthKind has its own support needs to make it clear for the user
what is happening (or going wrong)
But we should start with delimiter scanning.
On Fri, Jul 7, 2023 at 11:01 AM Davin Shearer <da...@apache.org> wrote:
> Greetings Daffodil developers and users!
>
>
>
> As v1.3.0 of the Apache Daffodil Extension for VS Code has been officially
> released, it’s time to plan the next release.
>
>
>
> Since v1.3.0 was a huge feature release compared to v1.2.0, I propose that
> we do a smaller (e.g., v1.3.1) release *before *we jump into v1.4.0. This
> allows for some recovery and implementation of some short-term, but
> important improvements, to set the stage for a larger release to follow. Since
> 1.3.1 can be smaller in scope, let’s try to target a release for August
> 2023, then a larger one (e.g., v1.4.0) targeted for the fall
> (October/November).
>
>
>
> Some features that I think would be appropriate for the smaller v1.3.1
> release targeted for this summer would include:
>
>
>
> Data Editor:
>
> • Merge single and multi-byte modes so they don’t need to be
> manually selected, for example, if one byte is selected, then the Data
> Editor should be automatically in single byte mode, and if more than one
> byte is selected, the Data Editor should automatically switch into
> muti-byte editing mode.
>
> • Add support for large file editing in the Data Editor (e.g.,
> being able to scroll and search around in large files -
> https://github.com/ctc-oss/daffodil-vscode/discussions/95).
>
> • Being able to persist selections *after *the viewport loses
> focus.
>
> • Implement “Save As” in addition to “Save”.
>
> • Incremental Search and Replace (currently Replace All is
> implemented).
>
> • Ability to have multiple simultaneous Data Editors opened
> sharing the same backend server (currently only one Data Editor can be
> opened at one time).
>
> • Ability to view and edit bytes represented in binary where the
> most significant bit can be the first bit of the byte, or the last bit of
> the byte.
>
> • Content-type discovery using Apache Tika.
>
> • Initial implementation of a data profiler.
>
> • Allow the values in the data inspector to be editable.
>
> • Have an “overwrite only” mode that will keep the file size the
> same, even when performing operations like Search and Replace where the
> token sizes aren’t the same.
>
>
>
> IntelliSense:
>
> • Add additional/missing attribute completion snippets.
>
> • Refine snippet suggestions for specific element tags.
>
> • Refine the handling of auto-complete closing tags for
> multi-line attributes (attribute split on multiple lines).
>
> • Setup IntelliSense unit *test *infrastructure.
>
> • Add semantic highlighting for XPath expressions.
>
>
>
> Reply to this thread if there are any other reasonably-small features that
> you would like to see implemented in v1.3.1 and/or thoughts about the
> release scheduling proposed here.
>
>
>
> Work on many of these items is already underway since the release cycle
> for v1.3.0 took 4 candidates before it was approved. The development
> team is tracking progress on the next release here:
> https://github.com/orgs/apache/projects/258/views/1.
>
>
> Thank you!
>