Skip to content

Conversation

@sm6srw
Copy link
Contributor

@sm6srw sm6srw commented May 24, 2018

Purpose

This PR changes the graphics format used by the /g option in DynamoWPFCLI to use the same format as CoGs is using.

Declarations

Check these if you believe they are true

  • The code base is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning, and are documented in the API Changes document.

Reviewers

@mjkkirschner

FYIs

@QilongTang @saintentropy

@sm6srw sm6srw added WIP and removed WIP labels May 24, 2018
@sm6srw
Copy link
Contributor Author

sm6srw commented May 24, 2018

This is now ready for review. @mjkkirschner: When you have a moment. No rush...

/// The class that represents data for drawing a graphic primitive
/// </summary>

internal class GraphicPrimitives
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sm6srw what is the difference between this and

public interface IRenderPackage

Copy link
Contributor Author

@sm6srw sm6srw May 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a version of the data in the IRenderPackage but the types and property names are different. I borrowed this class from Reach and then updated it to follow the naming Convention used by CoGs for easy serialization to JSON. Do you think it is worth doing this differently? Add a ToJson method to iRenderPackage?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it would work, but you could inherit from renderPackage and then use JsonProperty attributes to serialize into the format.

Or could add a new interface backing this object which is the same as the format.

I think keeping it internal for now is fine but we would want to expose creation methods for it eventually, and not just through the CLI but as part of some kind of export from dynamoCore or as part of DynamoServices I think using the render package for this keeps it simpler, but not sure if that works for you or if you think it's better to have some indirection between the output and render packages. Just curious on your approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I will take a look at both options.

@sm6srw
Copy link
Contributor Author

sm6srw commented May 30, 2018

@mjkkirschner This is a starting point that I think is in the right direction. Everything is internal for now and should not break the API as I understands it. I think the create function in the end should be a get method on the IRenderPackage interface but it could also live on a utility interface (if we have one suitable). The latter is more flexible I think as it doesn't ties it to the IRenderPackage implementation. Take a look when you have a moment. No rush...

<HintPath>..\packages\Unofficial.Ionic.Zip.1.9.1.8\lib\Ionic.Zip.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Microsoft.CSharp" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any memory of why this is required?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed when 'dynamic' is used.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sm6srw hmm, can you verify this does not break the mono build?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the Mono build is fine but I will check again.

if (typeof(T) == typeof(double))
{
foreach (T value in coordinates)
writer.Write(Convert.ToSingle(value));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats this about? CoGS format doesn't support doubles?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 'Cogs' format is storing doubles as floats as I read it. I think that is fine and not something that can be changed without breaking the format, right? This method is borrowed from reach.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CoGS is fine with double precision.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

float in Swagger just means floating point, doesn't imply single precision.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for the arrays that are encoded as base64 strings. So they are strings in swagger. Is Cogs encoding these as double? Or as float the same way reach is doing it? I have been assuming the latter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, those are 32 bit.

return;
}

var renderPackages = packages.ToList();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it necessary to do this iteration?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not, thanks...

}

/// <summary>
/// The class that represents json data for drawing a graphic primitive
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the interface

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks...

@mjkkirschner
Copy link
Member

@sm6srw looks good to me, only a few comments then LGTM.

@mjkkirschner
Copy link
Member

mjkkirschner commented Jun 6, 2018

@sm6srw thinking a bit more about this I'm curious if the dynamo core dep on dynamic keyword breaks the mono build?

Some more thoughts - if it is not supported in 3.8 I think thats fine, as we should be okay to move on to a newer version of mono if need a cross platform dynamo core, so I think as long as it's supported in newer mono versions we should be okay.

@mjkkirschner
Copy link
Member

LGTM not withstanding some testing on mono solution - looks like travis and appVeyor checks have stopped running :(.

@sm6srw
Copy link
Contributor Author

sm6srw commented Jun 7, 2018

Bummer, I was hoping the mono build would happen. Anyway, I checked manually: dynamic is supported by 3.8 and we are using it already in for example ProtoCore that is part of the mono solution. So I think we are good. I am running all the tests one final time and will go ahead and merge this as soon as they are done. Thanks!

else
{
foreach (T value in coordinates)
writer.Write(value as dynamic);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sm6srw just a bit curious - is casting to dynamic actually required here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would not compile without it: error CS1503: Argument 1: cannot convert from 'T' to 'bool'

@sm6srw
Copy link
Contributor Author

sm6srw commented Jun 7, 2018

All tests are passing. I will merge this now.

@sm6srw sm6srw merged commit 8471315 into DynamoDS:master Jun 7, 2018
@sm6srw sm6srw deleted the QNTM-4278 branch June 7, 2018 18:11
saintentropy pushed a commit to saintentropy/Dynamo that referenced this pull request Oct 22, 2018
* POC

* Cleanup code.

* Add command line option -g for generating geometry json file.

* Remove filtering

* Fix node state flags at load time.

* Use UpdateValue for setting isVisible on node model. Revert set to private.

* Remove filtering.

* Clean up holder code.

* Cleanup converter code. Use node model defaults as starting point.

* Preload the same libraries for CLI as for Sandbox.

* Add color support

* Simplify json

* Update file format.

* Remove property expressions.

* Restore comment.

* Restore Cef Settings

* Add unit test for CLI geometry option.

* Remove comment.

* Don't extend CommandLineRunner.

* Use var when possible.

* Remove commented out code.

* Use DynamoViewModel in CLI.

* Use DefaultWatch3DViewModel for CLI.

* Add new project DynamoWPFCLI.

* Let CommandLineRunnerWPF inherit from CommandLineRunner.

* Fix review comments.

* Fix unstable unit tests.

* Remove Dispose method.

* Add comments

* First pass

* Formatting fixes.

* Remove XML stuff.

* Some final adjustments.

* Add more comments.

* Move comment.

* Only store the geometry array.

* Refactor.

* Add interface

* Make interface internal

* Rename implmentation.

* Allow internal access for CLI

* Move default implementation to core.

* Make setters private

* Address review comments.
saintentropy added a commit that referenced this pull request Oct 24, 2018
* Add RegisterFroTrace attribute as a trigger in Json serialization of trace

* PR comment

* [ 2.0 Release Cut ] Bump Up Master Patch Version (#8647)

* Bump Up Patch Version

* Add version

* Update comments and version baseline

* Address Comments

* CubicMillimeterToCubicMeter conversion

* Revert "CubicMillimeter To CubicMeter conversion"

* Fix the units bug

* Remove thread sleep

* missed the test

* Fix static property compilation and crash (#8649)

* fix crash, compilation of static property

* code cleanup

* add test

* add test graph

* QNTM-3646: Fix creation of unwanted input port for list index-assignment (#8648)

* fix for additional input port

* fixes for output ports

* update tests

* added test, code cleanup

* address review comments

* QNTM-3279: Fix for crash when trying to directly call properties on class name (#8661)


* fix for compiling property method as function pointer

* code cleanup

* add tests

* Cherry-pick #8663  (#8664)

* Update failing tests (#8663)

* update tests

* Merge LibG binaries with Geometry.Approximate API (#8666)

* merge LibG binaries with Geometry.Approximate()

* Update license

* scroll bar fix in incanvas search

* QNTM-3641: Prevent ColorRange node from crashing with old style List syntax (#8670) (#8674)

* fix crash with ColorRange1D node

* add test

* add test
set unsaved changes false when initializing json custom node

* Update changes from librarie.js to fix QNTM-3710 (#8678)

After investigating the errors in the EngOps check it was thought that these changes could not have caused the current failures. Other PRs have also shown the same issues. Given all of that, this PR is being merged.

* address comments

* Update LibG binaries for ASM224 branch (#8681)

* update LibG binaries for ASM224 branch

* PR comment

* QNTM-3841 Add geometry creation option to Dynamo CLI (#8775)

* POC

* Cleanup code.

* Add command line option -g for generating geometry json file.

* Remove filtering

* Fix node state flags at load time.

* Use UpdateValue for setting isVisible on node model. Revert set to private.

* Remove filtering.

* Clean up holder code.

* Cleanup converter code. Use node model defaults as starting point.

* Preload the same libraries for CLI as for Sandbox.

* Add color support

* Simplify json

* Update file format.

* Remove property expressions.

* Restore comment.

* Restore Cef Settings

* Add unit test for CLI geometry option.

* Remove comment.

* Don't extend CommandLineRunner.

* Use var when possible.

* Remove commented out code.

* Use DynamoViewModel in CLI.

* Use DefaultWatch3DViewModel for CLI.

* Add new project DynamoWPFCLI.

* Let CommandLineRunnerWPF inherit from CommandLineRunner.

* Fix review comments.

* Fix unstable unit tests.

* Remove Dispose method.

* Add comments

* Fix type check

* Apply same fix to NodeInputData

* Add serialization tests

* Fix typo in Extansion.

* QNTM-4278 DynamoWPFCLI should use CoGs geometry format (#8887)

* POC

* Cleanup code.

* Add command line option -g for generating geometry json file.

* Remove filtering

* Fix node state flags at load time.

* Use UpdateValue for setting isVisible on node model. Revert set to private.

* Remove filtering.

* Clean up holder code.

* Cleanup converter code. Use node model defaults as starting point.

* Preload the same libraries for CLI as for Sandbox.

* Add color support

* Simplify json

* Update file format.

* Remove property expressions.

* Restore comment.

* Restore Cef Settings

* Add unit test for CLI geometry option.

* Remove comment.

* Don't extend CommandLineRunner.

* Use var when possible.

* Remove commented out code.

* Use DynamoViewModel in CLI.

* Use DefaultWatch3DViewModel for CLI.

* Add new project DynamoWPFCLI.

* Let CommandLineRunnerWPF inherit from CommandLineRunner.

* Fix review comments.

* Fix unstable unit tests.

* Remove Dispose method.

* Add comments

* First pass

* Formatting fixes.

* Remove XML stuff.

* Some final adjustments.

* Add more comments.

* Move comment.

* Only store the geometry array.

* Refactor.

* Add interface

* Make interface internal

* Rename implmentation.

* Allow internal access for CLI

* Move default implementation to core.

* Make setters private

* Address review comments.

* match Revit CEF intitializtion settings

* match Revit CEF intitializtion settings

* match Revit CEF intitializtion settings

* QNTM-5580 - Correct Typo in the Dynamo json serialization to match CoGS API (#9170)

* Fix typo

* Obsolete the existing property

* Update test

* remove expression body syntax

* Add serialization test with typo

* AVP NumberInputNode deserialization

* add testing

* QNTM-5568 Refinery needs to support culture invariance for number fmt, part Deux (#9178)

* Don't culture format value strings.

* Assume value strings are formated with `InvariantCulture`

* Add tests

* More work on tests

* Clarify switching of cultures
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants