{"action":"created","issue":{"url":"https://api.github.com/repos/DynamoDS/Dynamo/issues/9005","repository_url":"https://api.github.com/repos/DynamoDS/Dynamo","labels_url":"https://api.github.com/repos/DynamoDS/Dynamo/issues/9005/labels{/name}","comments_url":"https://api.github.com/repos/DynamoDS/Dynamo/issues/9005/comments","events_url":"https://api.github.com/repos/DynamoDS/Dynamo/issues/9005/events","html_url":"https://github.com/DynamoDS/Dynamo/pull/9005","id":343225355,"node_id":"MDExOlB1bGxSZXF1ZXN0MjAyOTM4OTkx","number":9005,"title":"Feature/bringing pack unpack to dynamo","user":{"login":"Mabiro","id":8363101,"node_id":"MDQ6VXNlcjgzNjMxMDE=","avatar_url":"https://avatars0.githubusercontent.com/u/8363101?v=4","gravatar_id":"","url":"https://api.github.com/users/Mabiro","html_url":"https://github.com/Mabiro","followers_url":"https://api.github.com/users/Mabiro/followers","following_url":"https://api.github.com/users/Mabiro/following{/other_user}","gists_url":"https://api.github.com/users/Mabiro/gists{/gist_id}","starred_url":"https://api.github.com/users/Mabiro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Mabiro/subscriptions","organizations_url":"https://api.github.com/users/Mabiro/orgs","repos_url":"https://api.github.com/users/Mabiro/repos","events_url":"https://api.github.com/users/Mabiro/events{/privacy}","received_events_url":"https://api.github.com/users/Mabiro/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-07-20T19:40:22Z","updated_at":"2018-07-30T17:36:22Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/DynamoDS/Dynamo/pulls/9005","html_url":"https://github.com/DynamoDS/Dynamo/pull/9005","diff_url":"https://github.com/DynamoDS/Dynamo/pull/9005.diff","patch_url":"https://github.com/DynamoDS/Dynamo/pull/9005.patch"},"body":"### Purpose\r\n\r\nThe purpose of this PR is to bring a new concept of Pack and UnPack nodes inside Dynamo.\r\nThe idea behind Packing nodes is to bring in type definitions (partially) inside Dynamo and have a way of building multi-level custom types with basic validations. \r\n\r\n#### TypeDefinition\r\nThis feature was initially started with a specific type definition format (pset as JSON). While integrating PackUnPack inside Dynamo Core, it was quite obvious that this needed to be generalized. Without being able to find a dynamo-wide solution that made sense regarding global types, I decided to propose a TypeScript-like syntax to define types on Packing nodes. It uses a simple Parser made using [Sprache](https://github.com/sprache/Sprache/). Packing nodes will expect a string that fits the Typescript-like syntax.\r\n\r\n##### Syntax\r\nThe syntax is quite simple. The initial keyword is `Type`, which must be followed by a word representing the type name and then a pair of `{ }` containing one or more properties defined as `name`, `:`, `Type` and seperated by a `,`. Like in Typescript, `[]` can be added to a property Type to indicate a collection.\r\n\r\ni.e:\r\n![image](https://user-images.githubusercontent.com/8363101/43020386-db431244-8c2d-11e8-8370-f9cf4dc96d54.png)\r\n\r\n##### Faulty Syntax\r\nAn error made in the syntax will be outlined by Sprache\r\n![image](https://user-images.githubusercontent.com/8363101/43020636-ab735e74-8c2e-11e8-999d-f74c9e6f4936.png)\r\n\r\n##### Builder nodes\r\nI've thought about adding builder nodes for TypeDefinitions, that is, a node with an UI that would allow to define properties and assign known or unknown types to them. I didn't jump in that yet and kept it as a \"power-user\" tool with the string definition, as I wasn't sure this TypeDefinition proposition would be accepted to begin with. Would be glad to get suggestions regarding this!\r\n\r\n#### Pack\r\nThe purpose of the Pack node is to take in a TypeDefinition (currently from a string) and redefining its InPorts to fit with the given type. When running, some basic validation of types occurs.\r\nAssuming no validation errors, it then outputs a dictionary (or list of dictionaries, as it does some lacing) corresponding to the input values. \r\n\r\ni.e.: \r\n![image](https://user-images.githubusercontent.com/8363101/43021025-31c0603e-8c30-11e8-9b77-9720509b47bf.png)\r\n\r\n##### UnPack\r\nThe purpose of the UnPack node is to complete the Pack node in a symmetric way. It takes in a TypeDefinition (currently from a string) and redefine its outports to show every property of that type definition. It then expects a dictionary (or list of dictionary) as an additional input and unpacks its content by mapping them to the different OutPorts. \r\n\r\ni.e.:\r\n![image](https://user-images.githubusercontent.com/8363101/43021334-4b45a9be-8c31-11e8-8704-c9b3b88a1013.png)\r\n\r\n##### Nested Types\r\nIt's possible to define types and re-use them in other Pack/UnPack nodes.\r\n![image](https://user-images.githubusercontent.com/8363101/43021538-f756215c-8c31-11e8-97f4-a0130ccf50e4.png)\r\n\r\n#### Notes\r\n\r\n- There are 1 TODO and 2 FIXME which I would like some input on\r\n- The DataBridge callbacks were used to handle the \"dynamic\" redefinition of ports + validation. It means that you must be running in Automatic mode or manually run the graph for the packing nodes to update and for type validations to be made. If anyone can bring a solution to that, I'd be glad to hear it!\r\n- Primitive Geo types were mapped by name, I am sure there will be better suggestions on this. Also, maybe some builtin types are missing and should be added?\r\n- TypeDefinition is a vague concept, hoping for suggestions/comments.\r\n- I am sorry for the huge initial commit. I actually implemented this in another repository, which explains why everything was squished into a single commit.\r\n- Lacing on the pack node was made manually. Due to the dynamic input aspect of the Pack node, I wasn't able to use the out of the box replication/lacing. The UnPack node, on the other hand, uses the out of the box feature.\r\n- Some tests were failing on my environment, but they weren't related to any of my changes. Can anyone double check that those aren't regressions, but maybe issues with my environment?\r\n\r\n### Declarations\r\n\r\nCheck these if you believe they are true\r\n\r\n- [ ] The code base is in a better state after this PR\r\n- [x] Is documented according to the [standards](https://github.com/DynamoDS/Dynamo/wiki/Coding-Standards)\r\n- [x] The level of testing this PR includes is appropriate\r\n- [x] User facing strings, if any, are extracted into `*.resx` files\r\n- [ ] All tests pass using the self-service CI.\r\n- [x] Snapshot of UI changes, if any.\r\n- [ ] Changes to the API follow [Semantic Versioning](https://github.com/DynamoDS/Dynamo/wiki/Dynamo-Versions), and are documented in the [API Changes](https://github.com/DynamoDS/Dynamo/wiki/API-Changes) document.\r\n\r\n### Reviewers\r\n\r\n@saintentropy \r\n@mjkkirschner \r\n"},"comment":{"url":"https://api.github.com/repos/DynamoDS/Dynamo/issues/comments/408947329","html_url":"https://github.com/DynamoDS/Dynamo/pull/9005#issuecomment-408947329","issue_url":"https://api.github.com/repos/DynamoDS/Dynamo/issues/9005","id":408947329,"node_id":"MDEyOklzc3VlQ29tbWVudDQwODk0NzMyOQ==","user":{"login":"kronz","id":3456818,"node_id":"MDQ6VXNlcjM0NTY4MTg=","avatar_url":"https://avatars3.githubusercontent.com/u/3456818?v=4","gravatar_id":"","url":"https://api.github.com/users/kronz","html_url":"https://github.com/kronz","followers_url":"https://api.github.com/users/kronz/followers","following_url":"https://api.github.com/users/kronz/following{/other_user}","gists_url":"https://api.github.com/users/kronz/gists{/gist_id}","starred_url":"https://api.github.com/users/kronz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kronz/subscriptions","organizations_url":"https://api.github.com/users/kronz/orgs","repos_url":"https://api.github.com/users/kronz/repos","events_url":"https://api.github.com/users/kronz/events{/privacy}","received_events_url":"https://api.github.com/users/kronz/received_events","type":"User","site_admin":false},"created_at":"2018-07-30T17:36:22Z","updated_at":"2018-07-30T17:36:22Z","author_association":"CONTRIBUTOR","body":"The Pack/Unpack model seems to be pretty speculative at the moment, and needs user validation.  This is even before we start talking about whether it is appropriate to be introduced as a general implementation in core (as opposed to a package).  Before I close this request, is there any discussion that I am missing to say why this should be part of core?\r\ncc @mccrone , @saintentropy "}}
{"actor":{"display_login":"kronz"}}