You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by "Interrante, John A (GE Research, US)" <Jo...@ge.com> on 2023/02/03 22:31:43 UTC
Rename daffodil-runtime2 to daffodil-generator-c
Eventually Daffodil will support multiple code generators. I have already sent a pull request to generalize Daffodil's CLI so we can call "daffodil generate <lang>" for additional languages. Now I want to discuss renaming daffodil-runtime2's module, package, and class names to new names that are more similar to and yet distinguishable from other code generators' modules, packages, and classes.
Daffodil's developers envisioned that Daffodil would have multiple backends/runtimes so they used "runtime2" as a placeholder name for whatever the next backend would be. That turned out to be a C code generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2" in many places within it. However, the use of "runtime2" as a name has to stop if we want Daffodil to generate code for additional languages. We can't have "runtime2", "runtime3", etc., since users will have no idea which runtimes correspond to which languages.
As I see it, there are two choices for the C code generator's new module name. We can say 1) daffodil-c-generator or we can say 2) daffodil-generator-c, that is, "daffodil-<language>-generator" or "daffodil-generator-<language>". I originally was going to say daffodil-c-generator like how I say "Daffodil's C code generator" in English but I've rethought that and realized that daffodil-generator-<language> will group multiple code generators together, encouraging developers to update them together and eventually move any common code/TDML tests to "daffodil-generator". If developers agree, I'll start work on the necessary module/package/class/wiki changes and send a pull request (after the OSGi refactoring if it's going to be merged very soon).
John
Rename daffodil-runtime2 to daffodil-generator-c
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
+1 to daffodil-codegen-c (and daffodil-codegen for any common classes/schemas/TDML used by multiple codegens).
I agree there's no need to discuss renaming anything else except daffodil-runtime2 at this time, although I agree with Steve about 1) finding some other way to separate code and infrastructure directories if we drop "daffodil-", and 2) keeping the jar names the same through sbt configuration (yay for backward compatibility). I've added these good points to https://issues.apache.org/jira/browse/DAFFODIL-2406.
Davin, we have only one CLI and it's called "daffodil". We use "daffodil generate c -s <schema>" to invoke the C code generator which creates a "c" subdirectory in the current directory. Once you run "make" in that subdirectory, you do get a "c/daffodil" executable with its own parse and unparse subcommands similar to Daffodil's CLI.
John
-----Original Message-----
From: Steve Lawrence <sl...@apache.org>
Sent: Monday, February 6, 2023 5:37 AM
To: dev@daffodil.apache.org
Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c
+1 to rename daffodil-codegen-c.
My one concern about dropping the "daffodil-" prefix in general is that it becomes hard to differentiate between directories containing code and those containing infrastructure stuff (e.g. containers, scripts, sbt dirs). This is especially the case if we renamed daffodil-lib to just "lib/" and "lib_managed/" (sbt jar storage) stayed the same.
Maybe we do something like add a new root dir that all the subprojects go in (eg. src/codegen-c, src/lib, src/cli). I would prefer something like this over shortening the prefix to "daf-", feels like it organizes things a bit better.
Though, whatever the change, and I don't think we need have to figure it now, I suggest we hold of and do all projects at the same time. So for now just rename to daffodil-codegen-c, keeping the daffodil- prefix.
Note that we also can change the names of the directories and add subdirectories without changing the jar names. The jar names probably do always want to have the daffodil- prefix. For example, a jar named just "lib-XYZ.jar" instead of "daffodil-lib-XYZ.jar" could cause a lot of confusion otherwise.
On 2023-02-03 08:11 PM, Interrante, John A (GE Research, US) wrote:
> We only discussed shortening the daffodil- prefix to daf-, not eliminating it. We wrote up that discussion in https://issues.apache.org/jira/browse/DAFFODIL-2406. We put off changing any daffodil- module names until Daffodil's 4.0.0 release, however, because changing the module names would be quite disruptive. All schemas' and users' build.sbt that pull in daffodil for testing would need to change not only version numbers, but also jar names. Arguably, longer names that say "daffodil" is good for the jars since we can see a list of jar files in a directory and know which jars come from Apache Daffodil modules and which jars come from external libraries. The "daffodil" in names is only clumsy for developers who have to type those names fairly often.
>
> We also have a wishlist for a sbt plugin to simplify all schemas' and users' build.sbt. I think it's either https://issues.apache.org/jira/browse/DAFFODIL-1679 or another issue. Having the plugin would make changing module names less disruptive even after 4.0.0 comes out.
>
> Changing daffodil-runtime2's module name won't affect any schemas or users, however, so it's fine to rename it now. I'm fine with "daffodil-codegen-c" or even "codegen-c" if anyone else thinks we should drop the daffodil- prefix completely. Let's hear more opinions.
>
> John
>
> -----Original Message-----
> From: Mike Beckerle <mb...@apache.org>
> Sent: Friday, February 3, 2023 3:03 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c
>
> I suggest "codegen-c" as the name and convention.
>
> I don't think the daffodil- prefix helps really and just makes all the names long.
> (Somewhere we had a discussion of eliminating all the daffodil- prefixes.
> Can't recall why we didn't. )
>
> On Fri, Feb 3, 2023 at 5:31 PM Interrante, John A (GE Research, US) < John.Interrante@ge.com> wrote:
>
>> Eventually Daffodil will support multiple code generators. I have
>> already sent a pull request to generalize Daffodil's CLI so we can
>> call "daffodil generate <lang>" for additional languages. Now I want
>> to discuss renaming daffodil-runtime2's module, package, and class
>> names to new names that are more similar to and yet distinguishable from other code generators'
>> modules, packages, and classes.
>>
>> Daffodil's developers envisioned that Daffodil would have multiple
>> backends/runtimes so they used "runtime2" as a placeholder name for
>> whatever the next backend would be. That turned out to be a C code
>> generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2"
>> in many places within it. However, the use of "runtime2" as a name
>> has to stop if we want Daffodil to generate code for additional
>> languages. We can't have "runtime2", "runtime3", etc., since users
>> will have no idea which runtimes correspond to which languages.
>>
>> As I see it, there are two choices for the C code generator's new
>> module name. We can say 1) daffodil-c-generator or we can say 2)
>> daffodil-generator-c, that is, "daffodil-<language>-generator" or
>> "daffodil-generator-<language>". I originally was going to say
>> daffodil-c-generator like how I say "Daffodil's C code generator" in
>> English but I've rethought that and realized that
>> daffodil-generator-<language> will group multiple code generators
>> together, encouraging developers to update them together and
>> eventually move any common code/TDML tests to "daffodil-generator".
>> If developers agree, I'll start work on the necessary
>> module/package/class/wiki changes and send a pull request (after the
>> OSGi refactoring if it's going to be merged very soon).
>>
>> John
Re: Rename daffodil-runtime2 to daffodil-generator-c
Posted by Steve Lawrence <sl...@apache.org>.
+1 to rename daffodil-codegen-c.
My one concern about dropping the "daffodil-" prefix in general is that
it becomes hard to differentiate between directories containing code and
those containing infrastructure stuff (e.g. containers, scripts, sbt
dirs). This is especially the case if we renamed daffodil-lib to just
"lib/" and "lib_managed/" (sbt jar storage) stayed the same.
Maybe we do something like add a new root dir that all the subprojects
go in (eg. src/codegen-c, src/lib, src/cli). I would prefer something
like this over shortening the prefix to "daf-", feels like it organizes
things a bit better.
Though, whatever the change, and I don't think we need have to figure it
now, I suggest we hold of and do all projects at the same time. So for
now just rename to daffodil-codegen-c, keeping the daffodil- prefix.
Note that we also can change the names of the directories and add
subdirectories without changing the jar names. The jar names probably do
always want to have the daffodil- prefix. For example, a jar named just
"lib-XYZ.jar" instead of "daffodil-lib-XYZ.jar" could cause a lot of
confusion otherwise.
On 2023-02-03 08:11 PM, Interrante, John A (GE Research, US) wrote:
> We only discussed shortening the daffodil- prefix to daf-, not eliminating it. We wrote up that discussion in https://issues.apache.org/jira/browse/DAFFODIL-2406. We put off changing any daffodil- module names until Daffodil's 4.0.0 release, however, because changing the module names would be quite disruptive. All schemas' and users' build.sbt that pull in daffodil for testing would need to change not only version numbers, but also jar names. Arguably, longer names that say "daffodil" is good for the jars since we can see a list of jar files in a directory and know which jars come from Apache Daffodil modules and which jars come from external libraries. The "daffodil" in names is only clumsy for developers who have to type those names fairly often.
>
> We also have a wishlist for a sbt plugin to simplify all schemas' and users' build.sbt. I think it's either https://issues.apache.org/jira/browse/DAFFODIL-1679 or another issue. Having the plugin would make changing module names less disruptive even after 4.0.0 comes out.
>
> Changing daffodil-runtime2's module name won't affect any schemas or users, however, so it's fine to rename it now. I'm fine with "daffodil-codegen-c" or even "codegen-c" if anyone else thinks we should drop the daffodil- prefix completely. Let's hear more opinions.
>
> John
>
> -----Original Message-----
> From: Mike Beckerle <mb...@apache.org>
> Sent: Friday, February 3, 2023 3:03 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c
>
> I suggest "codegen-c" as the name and convention.
>
> I don't think the daffodil- prefix helps really and just makes all the names long.
> (Somewhere we had a discussion of eliminating all the daffodil- prefixes.
> Can't recall why we didn't. )
>
> On Fri, Feb 3, 2023 at 5:31 PM Interrante, John A (GE Research, US) < John.Interrante@ge.com> wrote:
>
>> Eventually Daffodil will support multiple code generators. I have
>> already sent a pull request to generalize Daffodil's CLI so we can
>> call "daffodil generate <lang>" for additional languages. Now I want
>> to discuss renaming daffodil-runtime2's module, package, and class
>> names to new names that are more similar to and yet distinguishable from other code generators'
>> modules, packages, and classes.
>>
>> Daffodil's developers envisioned that Daffodil would have multiple
>> backends/runtimes so they used "runtime2" as a placeholder name for
>> whatever the next backend would be. That turned out to be a C code
>> generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2"
>> in many places within it. However, the use of "runtime2" as a name
>> has to stop if we want Daffodil to generate code for additional
>> languages. We can't have "runtime2", "runtime3", etc., since users
>> will have no idea which runtimes correspond to which languages.
>>
>> As I see it, there are two choices for the C code generator's new
>> module name. We can say 1) daffodil-c-generator or we can say 2)
>> daffodil-generator-c, that is, "daffodil-<language>-generator" or
>> "daffodil-generator-<language>". I originally was going to say
>> daffodil-c-generator like how I say "Daffodil's C code generator" in
>> English but I've rethought that and realized that
>> daffodil-generator-<language> will group multiple code generators
>> together, encouraging developers to update them together and
>> eventually move any common code/TDML tests to "daffodil-generator".
>> If developers agree, I'll start work on the necessary
>> module/package/class/wiki changes and send a pull request (after the
>> OSGi refactoring if it's going to be merged very soon).
>>
>> John
Re: Rename daffodil-runtime2 to daffodil-generator-c
Posted by "Shearer, Davin" <sh...@ctc.com>.
All things being equal, I prefer "daffodil-codegen-c" and the scheme `daffodil-codegen-<lang>`. I prefer the longer, descriptive name and if it annoys me on the CLI, I'll just create an alias for it (developers do this all the time, so this is not a stretch or hardship). The longer name allows it to be installed into say `/usr/bin` without fears of colliding with other executables in the same directory or in the same `PATH`. I also like it when the suite of tools "group together" in a directory listing (e.g., `daffodil-*`). It helps when I haven't used a tool in a while, I have a better chance of finding it if they are prefixed in this manner.
Another option would be to have a single code generation tool called "daffodil-codegen" and the language is provided as an argument (e.g., daffodil-codegen <lang>, or -l <lang>). I imagine the interface for these various generators to use similar kinds of options and consolidating the argument parsing can be helpful for the user and the developer. It also eases the installation as the installation code doesn't need to change as new languages are added. Could also make the testing code more concise. The down side is that it is slightly more difficult to determine the languages that are supported as they are not embedded in the filename as they would be with the daffodil-codegen-<lang>` scheme, so the user would need to either query the tool for the languages supported or look it up in the manual for the version installed.
Hope it helps,
Davin
On 2/3/23, 8:12 PM, "Interrante, John A (GE Research, US)" <Jo...@ge.com> wrote:
We only discussed shortening the daffodil- prefix to daf-, not eliminating it. We wrote up that discussion in https://issues.apache.org/jira/browse/DAFFODIL-2406. We put off changing any daffodil- module names until Daffodil's 4.0.0 release, however, because changing the module names would be quite disruptive. All schemas' and users' build.sbt that pull in daffodil for testing would need to change not only version numbers, but also jar names. Arguably, longer names that say "daffodil" is good for the jars since we can see a list of jar files in a directory and know which jars come from Apache Daffodil modules and which jars come from external libraries. The "daffodil" in names is only clumsy for developers who have to type those names fairly often.
We also have a wishlist for a sbt plugin to simplify all schemas' and users' build.sbt. I think it's either https://issues.apache.org/jira/browse/DAFFODIL-1679 or another issue. Having the plugin would make changing module names less disruptive even after 4.0.0 comes out.
Changing daffodil-runtime2's module name won't affect any schemas or users, however, so it's fine to rename it now. I'm fine with "daffodil-codegen-c" or even "codegen-c" if anyone else thinks we should drop the daffodil- prefix completely. Let's hear more opinions.
John
-----Original Message-----
From: Mike Beckerle <mb...@apache.org>
Sent: Friday, February 3, 2023 3:03 PM
To: dev@daffodil.apache.org
Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c
I suggest "codegen-c" as the name and convention.
I don't think the daffodil- prefix helps really and just makes all the names long.
(Somewhere we had a discussion of eliminating all the daffodil- prefixes.
Can't recall why we didn't. )
On Fri, Feb 3, 2023 at 5:31 PM Interrante, John A (GE Research, US) < John.Interrante@ge.com> wrote:
> Eventually Daffodil will support multiple code generators. I have
> already sent a pull request to generalize Daffodil's CLI so we can
> call "daffodil generate <lang>" for additional languages. Now I want
> to discuss renaming daffodil-runtime2's module, package, and class
> names to new names that are more similar to and yet distinguishable from other code generators'
> modules, packages, and classes.
>
> Daffodil's developers envisioned that Daffodil would have multiple
> backends/runtimes so they used "runtime2" as a placeholder name for
> whatever the next backend would be. That turned out to be a C code
> generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2"
> in many places within it. However, the use of "runtime2" as a name
> has to stop if we want Daffodil to generate code for additional
> languages. We can't have "runtime2", "runtime3", etc., since users
> will have no idea which runtimes correspond to which languages.
>
> As I see it, there are two choices for the C code generator's new
> module name. We can say 1) daffodil-c-generator or we can say 2)
> daffodil-generator-c, that is, "daffodil-<language>-generator" or
> "daffodil-generator-<language>". I originally was going to say
> daffodil-c-generator like how I say "Daffodil's C code generator" in
> English but I've rethought that and realized that
> daffodil-generator-<language> will group multiple code generators
> together, encouraging developers to update them together and
> eventually move any common code/TDML tests to "daffodil-generator".
> If developers agree, I'll start work on the necessary
> module/package/class/wiki changes and send a pull request (after the
> OSGi refactoring if it's going to be merged very soon).
>
> John
-----------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may contain
company proprietary information. If you are not the intended
recipient, notify the sender immediately and delete this
message. Publication, reproduction, forwarding, or content
disclosure is prohibited without the consent of the original
sender and may be unlawful.
Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
-----------------------------------------------------------------
Rename daffodil-runtime2 to daffodil-generator-c
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
We only discussed shortening the daffodil- prefix to daf-, not eliminating it. We wrote up that discussion in https://issues.apache.org/jira/browse/DAFFODIL-2406. We put off changing any daffodil- module names until Daffodil's 4.0.0 release, however, because changing the module names would be quite disruptive. All schemas' and users' build.sbt that pull in daffodil for testing would need to change not only version numbers, but also jar names. Arguably, longer names that say "daffodil" is good for the jars since we can see a list of jar files in a directory and know which jars come from Apache Daffodil modules and which jars come from external libraries. The "daffodil" in names is only clumsy for developers who have to type those names fairly often.
We also have a wishlist for a sbt plugin to simplify all schemas' and users' build.sbt. I think it's either https://issues.apache.org/jira/browse/DAFFODIL-1679 or another issue. Having the plugin would make changing module names less disruptive even after 4.0.0 comes out.
Changing daffodil-runtime2's module name won't affect any schemas or users, however, so it's fine to rename it now. I'm fine with "daffodil-codegen-c" or even "codegen-c" if anyone else thinks we should drop the daffodil- prefix completely. Let's hear more opinions.
John
-----Original Message-----
From: Mike Beckerle <mb...@apache.org>
Sent: Friday, February 3, 2023 3:03 PM
To: dev@daffodil.apache.org
Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c
I suggest "codegen-c" as the name and convention.
I don't think the daffodil- prefix helps really and just makes all the names long.
(Somewhere we had a discussion of eliminating all the daffodil- prefixes.
Can't recall why we didn't. )
On Fri, Feb 3, 2023 at 5:31 PM Interrante, John A (GE Research, US) < John.Interrante@ge.com> wrote:
> Eventually Daffodil will support multiple code generators. I have
> already sent a pull request to generalize Daffodil's CLI so we can
> call "daffodil generate <lang>" for additional languages. Now I want
> to discuss renaming daffodil-runtime2's module, package, and class
> names to new names that are more similar to and yet distinguishable from other code generators'
> modules, packages, and classes.
>
> Daffodil's developers envisioned that Daffodil would have multiple
> backends/runtimes so they used "runtime2" as a placeholder name for
> whatever the next backend would be. That turned out to be a C code
> generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2"
> in many places within it. However, the use of "runtime2" as a name
> has to stop if we want Daffodil to generate code for additional
> languages. We can't have "runtime2", "runtime3", etc., since users
> will have no idea which runtimes correspond to which languages.
>
> As I see it, there are two choices for the C code generator's new
> module name. We can say 1) daffodil-c-generator or we can say 2)
> daffodil-generator-c, that is, "daffodil-<language>-generator" or
> "daffodil-generator-<language>". I originally was going to say
> daffodil-c-generator like how I say "Daffodil's C code generator" in
> English but I've rethought that and realized that
> daffodil-generator-<language> will group multiple code generators
> together, encouraging developers to update them together and
> eventually move any common code/TDML tests to "daffodil-generator".
> If developers agree, I'll start work on the necessary
> module/package/class/wiki changes and send a pull request (after the
> OSGi refactoring if it's going to be merged very soon).
>
> John
Re: Rename daffodil-runtime2 to daffodil-generator-c
Posted by Mike Beckerle <mb...@apache.org>.
I suggest "codegen-c" as the name and convention.
I don't think the daffodil- prefix helps really and just makes all the
names long.
(Somewhere we had a discussion of eliminating all the daffodil- prefixes.
Can't recall why we didn't. )
On Fri, Feb 3, 2023 at 5:31 PM Interrante, John A (GE Research, US) <
John.Interrante@ge.com> wrote:
> Eventually Daffodil will support multiple code generators. I have already
> sent a pull request to generalize Daffodil's CLI so we can call "daffodil
> generate <lang>" for additional languages. Now I want to discuss renaming
> daffodil-runtime2's module, package, and class names to new names that are
> more similar to and yet distinguishable from other code generators'
> modules, packages, and classes.
>
> Daffodil's developers envisioned that Daffodil would have multiple
> backends/runtimes so they used "runtime2" as a placeholder name for
> whatever the next backend would be. That turned out to be a C code
> generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2"
> in many places within it. However, the use of "runtime2" as a name has to
> stop if we want Daffodil to generate code for additional languages. We
> can't have "runtime2", "runtime3", etc., since users will have no idea
> which runtimes correspond to which languages.
>
> As I see it, there are two choices for the C code generator's new module
> name. We can say 1) daffodil-c-generator or we can say 2)
> daffodil-generator-c, that is, "daffodil-<language>-generator" or
> "daffodil-generator-<language>". I originally was going to say
> daffodil-c-generator like how I say "Daffodil's C code generator" in
> English but I've rethought that and realized that
> daffodil-generator-<language> will group multiple code generators together,
> encouraging developers to update them together and eventually move any
> common code/TDML tests to "daffodil-generator". If developers agree, I'll
> start work on the necessary module/package/class/wiki changes and send a
> pull request (after the OSGi refactoring if it's going to be merged very
> soon).
>
> John
>
>
>