editconfig
I concur with Steve; we're going to need both a scalafmt configuration file and
an .editorconfig file to cover all source code files unless the day comes when
scalafmt understands .editorconfig and we're happy with scalafmt's default
formatting options.
Daffodil's existing code style is supposed to be very close to scalariform's
default formatting options. Does anyone know how different scalafmt's default
formatting options are from scalariform's? If they're not that different,
eventually we might end up with just .editorconfig.
-Original Message-
From: Adam Rosien
Sent: Monday, April 19, 2021 12:16 PM
To: dev@daffodil.apache.org
Subject: EXT: Re: editconfig
Ah, thanks for the extra context. I'll check out the JIRA issue.
FYI there's an editorconfig integration issue open for scalafmt:
https://github.com/scalameta/scalafmt/issues/1458.
.. Adam
On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence wrote:
> As long as scalafmt covers everything editconfig supports and the
> popular IDE's support it, we'd probably get better results for our
> scala files. But I assume scalafmt won't cover other files like
> XML/schema/tdml/text files. We might need a combination of the two to
> cover all files?
>
> See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related issue.
>
> - Steve
>
> On 4/19/21 11:37 AM, Adam Rosien wrote:
> > As a Scala project, however, how about using Scalafmt? [1] It's
> > become standard in all the projects I've been involved with; it's
> > supported by
> the
> > language creators and matches the previously mentioned features.
> >
> > .. Adam
> >
> > [1] https://scalameta.org/scalafmt/
> >
> > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US)
> > < john.interra...@ge.com> wrote:
> >
> >> I agree, an .editorconfig file at the root of daffodil coupled with
> >> IDE plugins (some IDEs such as IDEA already support .editorconfig
> >> without
> any
> >> plugin needed) could autoconfigure the following IDE settings
> automatically
> >> (if we felt we needed to specify all of these settings):
> >>
> >> root = true
> >> # All files (risky - could change bin/dat files inadvertently) [*]
> >> end_of_line = lf charset = utf-8 trim_trailing_whitespace = true
> >> insert_final_newline = true indent_style = space indent_size = 2 #
> >> Can narrow scope to only source code files [*.{java,scala,xml}]
> >> indent_style = space indent_size = 2
> >>
> >> EditorConfig plugins format only newly typed lines with these
> >> settings; they do not reformat existing files, meaning only files
> >> actually
> changed by
> >> one's commit will be affected by these settings. There are
> >> separate command-line tools that can check, infer, or fix
> >> EditorConfig rules
> across
> >> one or more directories/files in a repository manually. I think
> >> using
> one
> >> of these tools such as eclint would be essential for writing a
> >> proper .editorconfig that narrows its scope as much as possible
> >> (e.g., we don't want to change existing bin or dat or tdml files
> >> inadvertently when
> editing
> >> a single character within them in Emacs or IDEA because many of
> >> them use other charsets and are not source code).
> >>
> >> There's a nice long list of projects already using EditorConfig
> >> with
> links
> >> to their .editorconfig files. We also can look for similar
> >> projects to Daffodil to see how they scope their .editorconfig
> >> rules for their own files, but again, using "eclint infer" and
> >> "eclint check" seems the
> safest
> >> way to me.
> >>
> >> John
> >>
> >> -Original Message-
> >> From: Beckerle, Mike
> >> Sent: Monday, April 19, 2021 9:56 AM
> >> To: dev@daffodil.apache.org
> >> Subject: EXT: editconfig
> >>
> >> https://editorconfig.org/
> >>
> >> This is interesting and we should consider adding these files to
> >> the
> root
> >> of daffodil both as a declaration of the code-style, and a way that
> >> auto-configures many IDEs and tools (like github).
> >>
> >> This does not appear to be sophisticated enough to really cover
> code-style
> >> issues at all, but at least basic whitespace stuff like spaces not
> >> tabs, 2-space indenting, etc. would be covered.
> >>
> >>
> >>
> >
>
>
Re: editconfig
Ah, thanks for the extra context. I'll check out the JIRA issue.
FYI there's an editorconfig integration issue open for scalafmt:
https://github.com/scalameta/scalafmt/issues/1458.
.. Adam
On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence wrote:
> As long as scalafmt covers everything editconfig supports and the
> popular IDE's support it, we'd probably get better results for our scala
> files. But I assume scalafmt won't cover other files like
> XML/schema/tdml/text files. We might need a combination of the two to
> cover all files?
>
> See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related issue.
>
> - Steve
>
> On 4/19/21 11:37 AM, Adam Rosien wrote:
> > As a Scala project, however, how about using Scalafmt? [1] It's become
> > standard in all the projects I've been involved with; it's supported by
> the
> > language creators and matches the previously mentioned features.
> >
> > .. Adam
> >
> > [1] https://scalameta.org/scalafmt/
> >
> > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US) <
> > john.interra...@ge.com> wrote:
> >
> >> I agree, an .editorconfig file at the root of daffodil coupled with IDE
> >> plugins (some IDEs such as IDEA already support .editorconfig without
> any
> >> plugin needed) could autoconfigure the following IDE settings
> automatically
> >> (if we felt we needed to specify all of these settings):
> >>
> >> root = true
> >> # All files (risky - could change bin/dat files inadvertently)
> >> [*]
> >> end_of_line = lf
> >> charset = utf-8
> >> trim_trailing_whitespace = true
> >> insert_final_newline = true
> >> indent_style = space
> >> indent_size = 2
> >> # Can narrow scope to only source code files
> >> [*.{java,scala,xml}]
> >> indent_style = space
> >> indent_size = 2
> >>
> >> EditorConfig plugins format only newly typed lines with these settings;
> >> they do not reformat existing files, meaning only files actually
> changed by
> >> one's commit will be affected by these settings. There are separate
> >> command-line tools that can check, infer, or fix EditorConfig rules
> across
> >> one or more directories/files in a repository manually. I think using
> one
> >> of these tools such as eclint would be essential for writing a proper
> >> .editorconfig that narrows its scope as much as possible (e.g., we don't
> >> want to change existing bin or dat or tdml files inadvertently when
> editing
> >> a single character within them in Emacs or IDEA because many of them use
> >> other charsets and are not source code).
> >>
> >> There's a nice long list of projects already using EditorConfig with
> links
> >> to their .editorconfig files. We also can look for similar projects to
> >> Daffodil to see how they scope their .editorconfig rules for their own
> >> files, but again, using "eclint infer" and "eclint check" seems the
> safest
> >> way to me.
> >>
> >> John
> >>
> >> -Original Message-
> >> From: Beckerle, Mike
> >> Sent: Monday, April 19, 2021 9:56 AM
> >> To: dev@daffodil.apache.org
> >> Subject: EXT: editconfig
> >>
> >> https://editorconfig.org/
> >>
> >> This is interesting and we should consider adding these files to the
> root
> >> of daffodil both as a declaration of the code-style, and a way that
> >> auto-configures many IDEs and tools (like github).
> >>
> >> This does not appear to be sophisticated enough to really cover
> code-style
> >> issues at all, but at least basic whitespace stuff like spaces not tabs,
> >> 2-space indenting, etc. would be covered.
> >>
> >>
> >>
> >
>
>
Re: editconfig
As long as scalafmt covers everything editconfig supports and the
popular IDE's support it, we'd probably get better results for our scala
files. But I assume scalafmt won't cover other files like
XML/schema/tdml/text files. We might need a combination of the two to
cover all files?
See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related issue.
- Steve
On 4/19/21 11:37 AM, Adam Rosien wrote:
> As a Scala project, however, how about using Scalafmt? [1] It's become
> standard in all the projects I've been involved with; it's supported by the
> language creators and matches the previously mentioned features.
>
> .. Adam
>
> [1] https://scalameta.org/scalafmt/
>
> On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US) <
> john.interra...@ge.com> wrote:
>
>> I agree, an .editorconfig file at the root of daffodil coupled with IDE
>> plugins (some IDEs such as IDEA already support .editorconfig without any
>> plugin needed) could autoconfigure the following IDE settings automatically
>> (if we felt we needed to specify all of these settings):
>>
>> root = true
>> # All files (risky - could change bin/dat files inadvertently)
>> [*]
>> end_of_line = lf
>> charset = utf-8
>> trim_trailing_whitespace = true
>> insert_final_newline = true
>> indent_style = space
>> indent_size = 2
>> # Can narrow scope to only source code files
>> [*.{java,scala,xml}]
>> indent_style = space
>> indent_size = 2
>>
>> EditorConfig plugins format only newly typed lines with these settings;
>> they do not reformat existing files, meaning only files actually changed by
>> one's commit will be affected by these settings. There are separate
>> command-line tools that can check, infer, or fix EditorConfig rules across
>> one or more directories/files in a repository manually. I think using one
>> of these tools such as eclint would be essential for writing a proper
>> .editorconfig that narrows its scope as much as possible (e.g., we don't
>> want to change existing bin or dat or tdml files inadvertently when editing
>> a single character within them in Emacs or IDEA because many of them use
>> other charsets and are not source code).
>>
>> There's a nice long list of projects already using EditorConfig with links
>> to their .editorconfig files. We also can look for similar projects to
>> Daffodil to see how they scope their .editorconfig rules for their own
>> files, but again, using "eclint infer" and "eclint check" seems the safest
>> way to me.
>>
>> John
>>
>> -Original Message-
>> From: Beckerle, Mike
>> Sent: Monday, April 19, 2021 9:56 AM
>> To: dev@daffodil.apache.org
>> Subject: EXT: editconfig
>>
>> https://editorconfig.org/
>>
>> This is interesting and we should consider adding these files to the root
>> of daffodil both as a declaration of the code-style, and a way that
>> auto-configures many IDEs and tools (like github).
>>
>> This does not appear to be sophisticated enough to really cover code-style
>> issues at all, but at least basic whitespace stuff like spaces not tabs,
>> 2-space indenting, etc. would be covered.
>>
>>
>>
>
Re: editconfig
As a Scala project, however, how about using Scalafmt? [1] It's become
standard in all the projects I've been involved with; it's supported by the
language creators and matches the previously mentioned features.
.. Adam
[1] https://scalameta.org/scalafmt/
On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US) <
john.interra...@ge.com> wrote:
> I agree, an .editorconfig file at the root of daffodil coupled with IDE
> plugins (some IDEs such as IDEA already support .editorconfig without any
> plugin needed) could autoconfigure the following IDE settings automatically
> (if we felt we needed to specify all of these settings):
>
> root = true
> # All files (risky - could change bin/dat files inadvertently)
> [*]
> end_of_line = lf
> charset = utf-8
> trim_trailing_whitespace = true
> insert_final_newline = true
> indent_style = space
> indent_size = 2
> # Can narrow scope to only source code files
> [*.{java,scala,xml}]
> indent_style = space
> indent_size = 2
>
> EditorConfig plugins format only newly typed lines with these settings;
> they do not reformat existing files, meaning only files actually changed by
> one's commit will be affected by these settings. There are separate
> command-line tools that can check, infer, or fix EditorConfig rules across
> one or more directories/files in a repository manually. I think using one
> of these tools such as eclint would be essential for writing a proper
> .editorconfig that narrows its scope as much as possible (e.g., we don't
> want to change existing bin or dat or tdml files inadvertently when editing
> a single character within them in Emacs or IDEA because many of them use
> other charsets and are not source code).
>
> There's a nice long list of projects already using EditorConfig with links
> to their .editorconfig files. We also can look for similar projects to
> Daffodil to see how they scope their .editorconfig rules for their own
> files, but again, using "eclint infer" and "eclint check" seems the safest
> way to me.
>
> John
>
> -Original Message-
> From: Beckerle, Mike
> Sent: Monday, April 19, 2021 9:56 AM
> To: dev@daffodil.apache.org
> Subject: EXT: editconfig
>
> https://editorconfig.org/
>
> This is interesting and we should consider adding these files to the root
> of daffodil both as a declaration of the code-style, and a way that
> auto-configures many IDEs and tools (like github).
>
> This does not appear to be sophisticated enough to really cover code-style
> issues at all, but at least basic whitespace stuff like spaces not tabs,
> 2-space indenting, etc. would be covered.
>
>
>
Re: The future of the daffodil DFDL schema debugger?
Hi everybody, I've recently started working on Daffodil with some other folks and will be helping where I can with the debugger. I've been writing Scala since ~2011 and recently wrote a book about Cats Effect, which has a similar scope to ZIO (effects, concurrency, etc.). If anybody has any questions about the approach and techniques, I'm happy to help. .. Adam On Fri, Apr 16, 2021 at 2:49 PM Beckerle, Mike < mbecke...@owlcyberdefense.com> wrote: > This is actually very cool using ZIO for this. I have to learn more about > ZIO. > > > > From: John Wass > Sent: Monday, April 12, 2021 9:58 AM > To: dev@daffodil.apache.org > Subject: Re: The future of the daffodil DFDL schema debugger? > > > the code is here https://github.com/jw3/example-daffodil-debug > > There is now a complete console based example for Zio that demonstrates > controlling the debug flow while distributing the current state to three > "displays". > 1. infoset at current step > 2. diff of infoset against previous step > 3. bit position and value of data. > > These displays are very rudimentary but demonstrate the ability to > asynchronously populate multiple views while synchronously controlling the > debug loop. > > > - The new protocol being informed by existing debugger and DAPis key > > Going to look deeper into how DAP might fit with Daffodil, and depending on > how it shakes out will update the example to show integration. > > Some interesting links to start with > - https://github.com/scalacenter/scala-debug-adapter > - > https://scalameta.org/metals/docs/integrations/debug-adapter-protocol.html > - https://github.com/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 > > 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 "Daffodil Debug > Protocol". > > I imagine it would be loosely based on DAP (which is essentially JSON > > message based) but could be targeted to the things that a DFDL schema > > debugger would really need. An added benefit with some sort of protocol > > is the debugger interface can be uncoupled from Daffodil itself, so we > > could implement a TUI/GUI/whatever in any language/GUI framework and > just > > have it communicate the protocol over some form of IPC. Another benefit > > is that any future backends could implement this protocol and so a single > > debugger could hook into different backends without much issue. > > Unfortunately, defining such a protocol might be a large task, but we do > > have our existing debug infrastructure and things like DAP to guide its > > development/design. > > > > Some thoughts on this > > - Defining the protocol will be a large task, but a minimal version > should > > get up and round tripping quickly with a minimal subset of the protocol. > > - The new protocol being informed by existing debugger and DAPis key > > - Uncoupling from Daffodil is key > > - Adapt the Daffodil protocol to produce DAP after the fact so as not to > > constrain Daffodil debugging capability > > - We dont need to tie the protocol or adapters to a single framework, > > implementations of the IO layer should be simple enough to support > multiple > > things (eg Akka, Zio, "basic" ...) > > - The current debugger lives in runtime1, but can we make an abstract API > > that any runtime would implement? > > > > Maybe a solution is structured like this > > - daffodil-debug-api: > > - protocol model > > - interfaces: debugger / IO adapter / etc > > - lives in daffodil repo (new subproject?) > > - daffodil-debug-io-NAME > > - provides implementation of a specific IO adapter > > - multiple projects possible (daffodil-debugger-akka, > > daffodil-debugger-zio, etc) > > - supported ones live in their own subprojects, but other can be > plugged > > in from external sources > > - ability to support multiple implementations reduces risk of lock-in > > - debugger applications > > - maintained in external repositories > > - depending on the IO implementation these could execute be in separate > > process or on separate machine > > - like Steve said, could be any language / framework > > > > Three types of reference implementations / sample applications could also > > guide the development of the API > > 1. a replacement for the existing TUI debugger, expected to end up with > > at minimum the same functionality as the current one. > > 2. a standalone GUI (JavaFX, Scala.js, ..) debugger > > 3. an IDE integration > > > > Thoughts? > > > > Also I'm working on some reference implementations of these concepts > using > > Akka and Zio. Not quite ready to talk through it yet, but the code is >
RE: editconfig
I agree, an .editorconfig file at the root of daffodil coupled with IDE plugins
(some IDEs such as IDEA already support .editorconfig without any plugin
needed) could autoconfigure the following IDE settings automatically (if we
felt we needed to specify all of these settings):
root = true
# All files (risky - could change bin/dat files inadvertently)
[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 2
# Can narrow scope to only source code files
[*.{java,scala,xml}]
indent_style = space
indent_size = 2
EditorConfig plugins format only newly typed lines with these settings; they do
not reformat existing files, meaning only files actually changed by one's
commit will be affected by these settings. There are separate command-line
tools that can check, infer, or fix EditorConfig rules across one or more
directories/files in a repository manually. I think using one of these tools
such as eclint would be essential for writing a proper .editorconfig that
narrows its scope as much as possible (e.g., we don't want to change existing
bin or dat or tdml files inadvertently when editing a single character within
them in Emacs or IDEA because many of them use other charsets and are not
source code).
There's a nice long list of projects already using EditorConfig with links to
their .editorconfig files. We also can look for similar projects to Daffodil
to see how they scope their .editorconfig rules for their own files, but again,
using "eclint infer" and "eclint check" seems the safest way to me.
John
-Original Message-
From: Beckerle, Mike
Sent: Monday, April 19, 2021 9:56 AM
To: dev@daffodil.apache.org
Subject: EXT: editconfig
https://editorconfig.org/
This is interesting and we should consider adding these files to the root of
daffodil both as a declaration of the code-style, and a way that
auto-configures many IDEs and tools (like github).
This does not appear to be sophisticated enough to really cover code-style
issues at all, but at least basic whitespace stuff like spaces not tabs,
2-space indenting, etc. would be covered.
editconfig
https://editorconfig.org/ This is interesting and we should consider adding these files to the root of daffodil both as a declaration of the code-style, and a way that auto-configures many IDEs and tools (like github). This does not appear to be sophisticated enough to really cover code-style issues at all, but at least basic whitespace stuff like spaces not tabs, 2-space indenting, etc. would be covered.
