Comments (2)
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:
- Translates ELM to Expressions using the ExpressionBuilder
- Translates Expressions to C# source code and compiles it using Roslyn
- 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:
- Translates ELM to Expressions using the ExpressionBuilder
- Translates Expressions to C# source code and compiles it using Roslyn
- 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 theExpressionDef
, not theExpressionRef
, so making a cross-context query across libraries requires that I have access to the library to resolve itsExpressionDef
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.
Related Issues (20)
- Tuple types with different element ordres being treated as distinct types HOT 1
- Retrieves in context unfiltered are being generated with empty, non-null ExpressionRefs HOT 1
- Add Submodule `Demo` into CQL repo
- Add Submodule `CqlToElmTests` into CQL repo
- Fix rebuild of demo projects HOT 2
- Types with dot-deliminted names in models are not resolving
- Fluent function collisions throw exceptions
- Upgrade Java tooling if possible
- Fix build targets for cql -> elm and elm -> c#
- Functions and expressions with the same name in the same library cannot be resolved
- Coalesce does not support intervals
- Update Firely SDK version and release new alpha package
- Update CQL Conversion Mapping (Id / FhirString)
- CqlContext needs a TimeProvider property HOT 1
- Solve to fix ExpressionBuilder when definitions are not in-order #2
- Missing cqlOptions extension in the generated Library resource
- Release v2.0.2-alpha
- Concept equivalence fix + unit test HOT 1
- Delete the solution filter files *.slnf
- CQL true is compiling to capitalized True in CSharp
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from firely-cql-sdk.