Generate C# output files on the fly about firely-cql-sdk HOT 2 CLOSED

bugs are discovered on new input sets and fixed, however, as part of fixing one bug in one file, another one pops up in another file.

Can you clarify what you mean here? I have spent a lot of time debugging codegen over the past couple of years and I have not had an issue with the way PackagerCLI currently works.

The packager CLI does three things:

1. Translates ELM to Expressions using the ExpressionBuilder
2. Translates Expressions to C# source code and compiles it using Roslyn
3. Assembles FHIR resources from the source files.

Step 1 can be tested independently for single files and errors can be observed immediately. If you don't want to compile them to Roslyn you can compile the lambda expressions generated by the ExpressionBuilder - there is a CompileAll extension method that does this - and you will see any translation errors there.

You can also opt to write the C# files to a directory that contains a .csproj and then include that .csproj in a solution. That is how we develop measures. We compile CQL to ELM => ELM to C# => then use Visual Studio to compile the C#. It makes errors very easy to see and debug, since we can see all of the source code. If you haven't set this up for the CQL files you are trying to test, I would recommend doing so. It will make your life a lot easier.

Step 2 cannot be tested independently because dependencies matter. If library B depends on library A, library A's C# will have a reference (as a member) to library B, and will obviously not compile unless library B's class will resolve.

Step 3 is already independent in the code (createLibraryResource in LibraryPackager.cs) but is private. You could make it internal to test it independently if you like.

If you want to enhance the concept of packaging, then we should explore the ability for the tool to import existing packages that have already been compiled and depend on those. For example, every library relies on FHIRHelpers. If I package FHIRHelpers into a FHIR resource, that resource will contain a compiled DLL that contains the FHIRHelpers C# class. I should be able to compile a library that depends on FHIRHelpers in our toolchain by importing the FHIRHelpers Library resource, and not necessarily need an ELM file (because the FHIRHelpers library contains the ELM as an attachment.

It is also worth nothing that I have an outstanding branch called support-contexts that will require the ExpressionBuilder have access to every ELM file on which it depends, instead of being able to translate only a single ELM file at a time. This is because context information is only present on the ExpressionDef, not the ExpressionRef, so making a cross-context query across libraries requires that I have access to the library to resolve its ExpressionDef and check what its context is.

from firely-cql-sdk.

bugs are discovered on new input sets and fixed, however, as part of fixing one bug in one file, another one pops up in another file.

Can you clarify what you mean here? I have spent a lot of time debugging codegen over the past couple of years and I have not had an issue with the way PackagerCLI currently works.

The packager CLI does three things:

1. Translates ELM to Expressions using the ExpressionBuilder
2. Translates Expressions to C# source code and compiles it using Roslyn
3. Assembles FHIR resources from the source files.

Step 1 can be tested independently for single files and errors can be observed immediately. If you don't want to compile them to Roslyn you can compile the lambda expressions generated by the ExpressionBuilder - there is a CompileAll extension method that does this - and you will see any translation errors there.

You can also opt to write the C# files to a directory that contains a .csproj and then include that .csproj in a solution. That is how we develop measures. We compile CQL to ELM => ELM to C# => then use Visual Studio to compile the C#. It makes errors very easy to see and debug, since we can see all of the source code. If you haven't set this up for the CQL files you are trying to test, I would recommend doing so. It will make your life a lot easier.

Step 2 cannot be tested independently because dependencies matter. If library B depends on library A, library A's C# will have a reference (as a member) to library B, and will obviously not compile unless library B's class will resolve.

Step 3 is already independent in the code (createLibraryResource in LibraryPackager.cs) but is private. You could make it internal to test it independently if you like.

If you want to enhance the concept of packaging, then we should explore the ability for the tool to import existing packages that have already been compiled and depend on those. For example, every library relies on FHIRHelpers. If I package FHIRHelpers into a FHIR resource, that resource will contain a compiled DLL that contains the FHIRHelpers C# class. I should be able to compile a library that depends on FHIRHelpers in our toolchain by importing the FHIRHelpers Library resource, and not necessarily need an ELM file (because the FHIRHelpers library contains the ELM as an attachment.

It is also worth nothing that I have an outstanding branch called support-contexts that will require the ExpressionBuilder have access to every ELM file on which it depends, instead of being able to translate only a single ELM file at a time. This is because context information is only present on the ExpressionDef, not the ExpressionRef, so making a cross-context query across libraries requires that I have access to the library to resolve its ExpressionDef and check what its context is.

This issue only targets the first step "Translate ELM to Expressions". We get exceptions processing the CMS measures (about 60) files. As we go through each file, it would be useful to have all the successful ELM to Expressions written out sooner to C# files, so that we can evaluate fixes done up to that point.

from firely-cql-sdk.