Hi Mike-
Take a look at
https://github.com/jni-rs/jni-rs
There is a good example in the repo.
I'd compare that against jnr-ffi, which is nice in general for jni work.
https://github.com/jnr/jnr-ffi
-john
On Tue, Jan 16, 2024, 08:42 Mike Beckerle wrote:
> John, what do you (or anyone?) kno
All issues are resolved. If we are good to proceed I would nominate Shane
Dell to be the release manager.
On Thu, Feb 17, 2022, 10:38 John Wass wrote:
> > #81 yarn disallows SVG's in the README
> > #82 yarn build fails with missing icon
> > #83 Rename vsix convenience b
> #83 Rename vsix convenience binary?
>
> https://github.com/apache/daffodil-vscode/issues/83
>
>
>
> On 2/17/22 10:06 AM, John Wass wrote:
> > I'd like to discuss starting the first official release of the Daffodil
> VS
> > Code extension.
> >
I'd like to discuss starting the first official release of the Daffodil VS
Code extension.
All items in the 1.0.0 GitHub milestone have been closed (aside from one
about performing the release). Are there any issues remaining on the
tracker that should be considered required, or any other blocker
yte, and it shows the
> bits off to the side/corner along with other potentially useful stuff: the
> position of the byte in bytes and in bits, it's value as decimal, its value
> as an ascii char, etc. This would take very little screen space.
>
> On Wed, Nov 3, 2021 at 8:01 AM
cus on a bit and flip it.
> >
> > I would add to the "parse until this byte", or "start from this byte" to
> enable narrowing at both the start and end - parse just these bytes (in an
> identified region by start and end). The use case I have in mind for th
at both the start and end - parse just these bytes (in an
> identified region by start and end). The use case I have in mind for this
> is sort of like unit testing. You narrow the data to just one part, then
> you specify to parse it not with the root element of the DFDL schema, but
>
re changes and improvements to the Daffodil C code generator
> myself but the changes can go into 3.3.0 since I already build Daffodil
> from source anyway. Is Steve Lawrence or John Wass working on something
> that should make it into 3.2.0? Anyone else?
>
> John
>
> -
Some thoughts on ways the hex editor would interact with an input stream
and the debugger. I visualize this using a context sensitive menu in the
hex editor as an entrypoint, where these are some of the operations that
could be offered.
1. Add/Delete/Mask/Set
* Individual bytes
* Blocks of by
Another concept considered is the ability to display regions of a file in
formatting that is different from another region. For example in the case
where endianness varies across the file, if we could apply different
renderings to these different regions it could assist schema developers in
reason
I moved #39 into the milestone based on discussion from GitHub.
https://github.com/apache/daffodil-vscode/milestone/1
On Mon, Oct 18, 2021 at 9:55 AM Mike Beckerle wrote:
> I just wanted to try to get the team to mark the tickets that are critical
> to fix for v1.0.0 release with the 1.0.0 mile
Milestone to track 1.0.0 -
https://github.com/apache/daffodil-vscode/milestone/1
On Thu, Oct 14, 2021 at 7:48 AM John Wass wrote:
> > You mention a VSIX + ZIP? What is the zip you reference? Is that the
> source, or are there two convenience binaries that make up an extension?
>
&
in this .vsix convenience binary.
>
>
> On 10/13/21 12:22 PM, Adam Rosien wrote:
> > My understanding is the Typescript code gets "compiled" into Javascript
> > when built and packaged.
> >
> > On Wed, Oct 13, 2021 at 9:07 AM Mike Beckerle
> wro
wrote:
>
> > +1 sounds good to me
> >
> > On 10/7/21 10:14 AM, John Wass wrote:
> > > Sounds good. I will do that and start to move issues over.
> > >
> > > Some of these issues have multiple posts by multiple authors and it
> will
> &
there?
On Wed, Oct 6, 2021 at 5:01 PM Mike Beckerle wrote:
> No problem. Go ahead. That's a sensible last commit on that repo.
>
> On Wed, Oct 6, 2021 at 5:00 PM John Wass wrote:
>
> > Will there be any problem with updating the readme in the old repo to
> note
> >
Will there be any problem with updating the readme in the old repo to note
that it is relocated?
On Wed, Oct 6, 2021 at 4:20 PM John Wass wrote:
> Steps 1-7 sound good to me. Some thoughts
>
> > 1) push to https://github.com/apache/daffodil-vscode repository.
>
> Who is goin
Steps 1-7 sound good to me. Some thoughts
> 1) push to https://github.com/apache/daffodil-vscode repository.
Who is going to push the code?
> 2) move over github issues to the new repo issues
It doesn't look like the "transfer issue" function works across orgs. So a
manual move it shall be.
> Are there even convenience binaries? What is actually published to the
market place?
We will send a VS Code extension package (.vsix) to the marketplace.
We will also need to make the daffodil debugger zip file from the build
available from the GitHub release.
> Perhaps we don't need to solve
+1 for GitHub Issues
- gain conveniences by staying within GitHub
- avoid complexity involved with separating things
- better experience for new contributors
On Thu, Sep 23, 2021 at 10:29 AM Beckerle, Mike <
mbecke...@owlcyberdefense.com> wrote:
> So, I inquired about whether we need to use JIR
JS dependencies here, should be all transitives too
https://github.com/jw3/example-daffodil-vscode/wiki/js-dependencies
On Mon, Sep 20, 2021 at 7:42 AM Steve Lawrence wrote:
> These all look compatible with the Apache license and shouldn't be a
> problem. The EPL 1.0 dependencies will require s
> I know of one file in the repo which will have to be removed which is the
jpeg.dfdl.xsd file, which is there just as an example workspace.
I assume this issue remains, and needs to be addressed prior to giving this
the done stamp.
We could just remove that sample workspace, the setup is trivial
t; the incubator-pmc that blended files are ok because they originally had the
> MIT license.
>
> I definitely don't want to bother with that unless the refactoring
> exercise here is hard.
>
> From: John Wass
> Sent: Friday, September 10
Mike - Those were renames from the original versions that had "mock" in
their names.
commit 383fd4882a8fe51adf21b5ae31fe252056800447
On Fri, Sep 10, 2021 at 12:54 PM Beckerle, Mike <
mbecke...@owlcyberdefense.com> wrote:
>
> John Wass said:
>
> I had a few more
y an ASF committer.
>
> I suppose that submitting it as a PR does follow some of that process,
> but there is maybe less assurance of ownership. Because it was not
> developed in an ASF repository, that code is presumed to be owned by
> you, multiple developers, or a company, and s
mited understanding
> of the process).
>
> - Steve
>
>
> On 9/9/21 3:34 PM, John Wass wrote:
> > Couldn't we (the vscode contributors) submit a series of PRs against the
> > new repo to move the code, and just archive the example repo as-is?
> >
> > I not
Couldn't we (the vscode contributors) submit a series of PRs against the
new repo to move the code, and just archive the example repo as-is?
I noted some thoughts on that a while back
https://github.com/jw3/example-daffodil-vscode/issues/77
On Thu, Sep 9, 2021 at 2:11 PM Beckerle, Mike
wrote:
>
> I think experimentation to see what works well for the debugger/IDE is
> very sensible.
>
>
> From: John Wass
> Sent: Wednesday, June 9, 2021 2:35 PM
> To: dev@daffodil.apache.org
> Subject: Re: Use GitHub Releases
>
> >
il
>
> That has some basic version and release date information. And as I
> mentioned before, it requires that projects keep it up to date. I'm not
> sure how many do if you're interested about other projects.
>
>
> On 6/9/21 12:36 PM, John Wass wrote:
> >> the
21 at 12:13 PM John Wass wrote:
> We have been using the GitHub API to collect (representative) releases of
> Daffodil during some prototype work. However when looking at the main
> Daffodil repo I see there are no releases published there.
>
> There are probably some other ways t
We have been using the GitHub API to collect (representative) releases of
Daffodil during some prototype work. However when looking at the main
Daffodil repo I see there are no releases published there.
There are probably some other ways to work around this, but the simplest is
to ask if publishi
m/scalameta/metals-vscode (provides a debugger and
> > non-debugger custom UI)
> > [4] https://github.com/microsoft/vscode-cpptools (debugger + memory
> view)
> > [5]
> https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug
> > (debugger + memory view,
&
+1
I checked
[OK] RPM install in centos 8 and fedora 32
[OK] spot check schematron validation and svrl output
[OK] misc CLI operations
[OK] hash of each download matches
[OK] rat check passes
[OK] use of staged artifacts in existing applications
On Fri, May 14, 2021 at 3:26 PM Steve Lawrence
> dig a bit to see if the DAP-only hooks can be reused without JDI coming
along for the ride
Cool, that would be good to dig at. Big win if we can reuse it.
ry view,
>
> https://github.com/Marus/cortex-debug/blob/master/src/frontend/memory_content_provider.ts
> )
> [6]
>
> https://marketplace.visualstudio.com/items?itemName=slevesque.vscode-hexdump
> (extension for hexdumps that could be controlled by other extensions)
> [7] https://github.
e on top, and conflict
> detection should still do the right thing. I checked a couple PRs and they
> still show no-conflicts with the base.
>
>
> From: John Wass
> Sent: Wednesday, April 21, 2021 4:26 PM
> To: dev@daffodil.apache.org
> Subject
I'd let them be.
On Wed, Apr 21, 2021 at 4:13 PM Beckerle, Mike <
mbecke...@owlcyberdefense.com> wrote:
> I ended up committing 3 tiny commits to master, forgot to squash them.
>
> Should I fix this by force push?
>
> Mike Beckerle | Principal Engineer
>
> mbecke...@owlcyberdefense.com
> P +1-78
> As a Scala project, however, how about using Scalafmt?
I'm in favor of scalafmt also.
> But I assume scalafmt won't cover other files like XML/schema/tdml/text
files.
Take a look at https://github.com/diffplug/spotless
Spotless says it could support all of those, and a quick search says the
S
The trick is being able to modify the CI workflow in the PR to inject new
behavior. If there was a limit of some type on that it would decrease the
usefulness of this.
On Wed, Apr 21, 2021 at 9:33 AM Beckerle, Mike <
mbecke...@owlcyberdefense.com> wrote:
> This has to do with crypto mining? Gaa
> Next step is to refine these thoughts with a prototype.
Another next step is to collect feedback on this research and proposed
approach. Any discussion is appreciated.
On Tue, Apr 20, 2021 at 10:00 AM John Wass wrote:
> > Going to look deeper into how DAP might fit with Daffodil
Microsoft/java-debug
[3] https://github.com/scalacenter/scala-debug-adapter
[4] https://github.com/jw3/example-daffodil-debug
On Mon, Apr 12, 2021 at 9:58 AM John Wass wrote:
> > the code is here https://github.com/jw3/example-daffodil-debug
>
> There is now a complete console based
> I believe we need to do a release very soon regardless of these 96 issues
I would like DAFFODIL- 2482 to get into it;
https://github.com/apache/daffodil/pull/520
Will increase priority on wrapping this up.
On Mon, Apr 12, 2021 at 12:43 PM Beckerle, Mike <
mbecke...@owlcyberdefense.com> wrote
m/microsoft/java-debug
Also looking into the Java Debug Interface (JDI) for comparison.
On Thu, Apr 8, 2021 at 12:36 PM John Wass wrote:
> Revisiting this post after doing some debugger related work and thinking
> about debug protocol/adapters to connect external tooling to the debug
>
PM John Wass wrote:
> Revisiting this post after doing some debugger related work and thinking
> about debug protocol/adapters to connect external tooling to the debug
> process.
>
> This comment is good
>
> > This allo makes me wonder if an approach worth taking for the
Revisiting this post after doing some debugger related work and thinking
about debug protocol/adapters to connect external tooling to the debug
process.
This comment is good
> This allo makes me wonder if an approach worth taking for the future of
Daffodil schema debugging is developing a sort of
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 7faeb04 Allow custom debuggers through SAPI and JAPI
> 7faeb04 is described below
>
> commit 7faeb04aa17337487848f5f61141a74d7d82484b
> Author: John Wass
> AuthorDate: Wed Mar
ite it to, and API-wise, if we decide we
> have to expose this, then a parseResult.validationResult.raw member, or
> like that, is fine with me.
>
> Do we need API-level access to this? E.g. in SAPI/JAPI? I would imagine so.
> ____
> From: John Wass
>
was used. But a similar issue exists if this is
> just an InputStream--you still need to know how to interpret that
> InputStream data. But with this approach, it lets a Validator return
> complex structures that can provide richer information than an
> InputStream could.
>
>
Reference implementation here
https://github.com/jw3/daffodil/tree/validator_outputstream
Currently has changes sketched in from the parse result on down. Need to
wire things in through DP and CLI yet.
Haven't thought of an alternative that works yet.
On Tue, Mar 23, 2021 at 12:59 PM
Looking at DAFFODIL-2482 that came up due to a gap that's blocking
integration of the schematron validation functionality into some workflows
that require the full SVRL output, not just the pass/fail status.
So what needs to happen here is the SVRL that we currently just parse for
errors and disca
d recipient, you are hereby notified that any
> review, dissemination, or copying of this communication is strictly
> prohibited. If you have received this transmission in error, please notify
> the sender immediately
>
> --
> *From:* John Wass
> *Se
Is the gui envisioned to be an ide plugin or a standalone application (ie
swing, fx, ...)?
On Sun, Jan 24, 2021 at 2:08 PM Sloane, Brandon
wrote:
> Following up on the recent discussion about the Daffodil debugger, I would
> like to propose a roadmap for creating graphical debugger.
> Organiza
+1
On Fri, Jan 29, 2021 at 10:35 AM Thompson, Dave <
dthomp...@owlcyberdefense.com> wrote:
> +1
>
> -Original Message-
> From: Mike Beckerle
> Sent: Thursday, January 28, 2021 6:09 PM
> To: dev@daffodil.apache.org
> Subject: [VOTE] Contributors - Graduate Apache Daffodil (Incubating) to a
Implemented that and added a test for it in
section02.schema_definition_errors.TestSDE. The cli tests are in there as
well.
On Mon, Jan 18, 2021 at 9:57 AM John Wass wrote:
> > I think this warning (or something like it) is actually somewhat useful
> and we shouldn't get rid of
mespace but that does not have the dfdl source
> attribute. This catches both the case where the source is left off, but
> also catches the case where someone just typos the source. This way we
> still allow appinfo's without sources, but we only silently ignore them
> if they do
/AnnotatedSchemaComponent.scala#L403
).
`this.SDW(WarnID.AppinfoNoSource, """xs:appinfo without source attribute.
Is source="http://www.ogf.org/dfdl/"; missing?""")`
Thoughts on siliencing or lessening significance of this (eg. log instead
of diagnostic)?
On Wed,
different Daffodil dependency? Does this override that? Or does this
> just expect that Daffodil is already a dependency and uses that version?
> And hopefully our TDMLRUnner API is stable enough that things just work?
> We definitely have cases where we need to run tests with different
&g
What other features could find a nice home in an IDE integration? Having
single convenient entrypoint (the IDE) for such things would be nice, imo.
Things like...
- Rich set of actions for TDML
- Run a single test from a TDML file
- Debug/Run TDML
- Run/Debug a data file with a schema from t
https://github.com/jw3/sbt-tdml
I needed to get smarter on SBT plugins for a task and tinkered with
something in Daffodil to do it.
The goal here was to remove the TDML test boilerplate. I threw this at the
daffodil-test project with surpsisingly sane results on the first try. See
the bottom of t
would be a good context to continue and resolve the "best practices
in the schematron" discussions.
On Tue, Dec 22, 2020 at 9:53 AM John Wass wrote:
> > The second one is similar to examples in the GIF schema
> <https://github.com/DFDLSchemas/GIF/blob/master/src/main/resou
king good. Specifically looked at
rule `count(/GIF/Global_Color_Table/RGB) eq math:pow(2,
../number(Size_of_Global_Color_Table) + 1)`.
Working on embedding the bmp schema now as the final integration test.
On Mon, Dec 21, 2020 at 7:49 AM John Wass wrote:
> > Does the process create SVR
gt; With IntelliJ I've been able to avoid the need I guess
>
>
> From: John Wass
> Sent: Friday, December 18, 2020 12:37 PM
> To: dev@daffodil.apache.org
> Subject: Re: Daffodil schema file extension
>
> > If you have edited tdml in
icious
> SQL reference between segemnts
>
>
> I've also done test to see if the count of bytes in one field matched the
> size of the field value from another field:
>
> GIF: RED: LSG_GCL: GCL-RGB-CNT: There must be
> Size_
> If you have edited tdml in an XML aware editor, you know that the support
for embedded dfdl schemas is better than it is in xsd editors for a dfdl
schema file.
Better in what way? They looked pretty similar to me, in intellij.
On Fri, Dec 18, 2020 at 12:35 PM John Wass wrote:
> Than
out DFDL schemas can
> have a special case to treat files with .dfdl.xsd extensions differently.
>
> Also, I think I have seen .xml and plain .xsd (without .dfdl) extensions
> used for DFDL schemas, likely for the IDE support. But .dfdl.xsd gets
> you the possibility of that extra c
The Embedded Schematron PR is moving along, hoping to get it out of WIP
soon. https://github.com/apache/incubator-daffodil/pull/463
The JPEG and BMP schema repos are being used for testing now, and the PNG
looks like it would provide some great coverage.. maybe too great :/ Any
other noteworthy
Doing a little work with software that cares about file extensions,
resulting in a couple questions about the history and future of the dfdl
file extension.
1, Why was the extension of .dfdl.xsd used?
2. What issues would arise by dropping the xsd part?
3. Are there any other extensions being used
I had dead code about 95% complete and some work on another round of unused
(maybe locals) back in June, but the branch will be stale now.
Scalafix helps greatly with these tasks but it is still a bit of work.
Will take a look and see where that was once this validators stuff is
wrapped up.
On
PR is in at https://github.com/apache/incubator-daffodil/pull/431
On Wed, Oct 7, 2020 at 9:43 AM john wass wrote:
> Based on the feedback it sounds like the approach is sane enough to put
> together a PR.
>
> Thanks all for the reviews and feedback.
>
>
> On Thu, O
Based on the feedback it sounds like the approach is sane enough to put
together a PR.
Thanks all for the reviews and feedback.
On Thu, Oct 1, 2020 at 6:11 PM Beckerle, Mike
wrote:
> FYI: John Wass - I am also going to surf your code a bit so may have more
> comments. I've fetche
infrastructure). So
> "daf-" is a decent middle ground.
>
> I think the "daf-" was suggested for me, and I don't feel strong about
> it, so I'm not against dropping the daf- prefix entirely if others don't
> like it.
>
> On 10/7/20 9:16 AM, john
What was the reasoning on the daf- prefix again?
I looked back through but didnt see what the value add of the prefix was.
On Wed, Oct 7, 2020 at 9:09 AM Interrante, John A (GE Research, US) <
inter...@research.ge.com> wrote:
> I've created an issue (https://issues.apache.org/jira/browse/DAFFOD
71 matches
Mail list logo
