Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Remaining burndown for full support in miniwdl check:

  • object literal syntax
  • new literal syntax
  • Value

  • parser: a type can now be essentially any CNAME. are we going to run into complications with recognition of keywords: command output runtime meta parameter_meta scatter if
  • Type: tree transformer needs to detect whether CNAME from parser is a builtin type or otherwise a presumed Struct, and initialize appropriate object. responsibility for checking that type parameters [] make sense will get pushed here as well
  • typechecking will need to refer to some document-level registry of declared & imported structs to go along with the type environment. Structs can contain other structs! (will need cycle detection…)
    • when we call an imported task/workflow which outputs a struct, we may have a different name for it than the callee. Then that struct might itself contain structs imported from some other document, which we may not have a name for at all, or there might be a name collision between one of those and one of ours.
    • so we better give each struct definition some globally unique id. it would be nice if this id were ‘reproducible’ across separate instantiations of the document from the same source…can use a counter assuming load/eval order is deterministic…or, Name<doc-crc32c>
  • Value.StructInstance (members dict) and JSON I/O
  • member access
    • when we have a struct instance s, we can reference s itself or a member s.m or s.m.n
    • does it need to be valid (if useless) to access a member of an immediate literal, Person(name="Calvin", age=6).age
    • how to use type environment vs code path in Expr.Ident
    • subsume pair .left/.right access into this?
    • Pair[Person,Person] p2p2.left.age
    • Array[Person] arar[42].age
    • some name collisions between values, calls, imports will become “hard”…possibly this is already a problem with pair left/right access
    • general issue: the syntactic structure name1.name2.name3 should be parsed differently depending on the type environment. name1 could refer to a value and .name2.name3 struct member accesses within. Or name1.name2 could be the namespaced value, and name3 a struct member.
    • typechecker possibly should transform AST after these are sorted out. otherwise all downstream AST users have to handle that
  • literal / coercion (pending revision:
  • import & aliasing
    • " If two structs are named the same it will be necessary to resolve the conflicting names. "
    • “Its important to note, that when importing from file 2, all structs from file 2’s global namespace will be imported. This Includes structs from another imported WDL within file 2, even if they are aliased. If a struct is aliased in file 2, it will be imported into file 1 under its aliased name.”
    • pay attention to what type name is used in type mismatch errors on imported structs (especially call inputs or ident references to call outputs)
    • diamond imports
    • UnusedImport update, you might import a doc just to use its structs
  • NameCollision lint

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:13

github_iconTop GitHub Comments

pshapiro4broadcommented, Apr 3, 2019

Thanks for the bug report, looks like they’re already on it.

dinvladcommented, Jun 28, 2019

Thanks for the discussion today! We currently pass an opaque Object? context through workflow inputs. This object holds important “context” for the workflow run that’s serialized (along with workflow outputs) into JSON at the very last step in the workflow, and triggers post-workflow activities.

Since there’re no plans for Object to be recognized by MiniWDL, what would be a reasonable substitute in this case? I tried defining struct Context {} and Context? context, but then MiniWDL validation fails silently with an AssertionError. We wouldn’t want to define the shape of Context {} inside WDL, because its shape is irrelevant for the purposes of the workflow (and would make it too coupled to the data model we use outside of the workflow).

EDIT: as a workaround, if I define struct Context { Boolean? test }, then MiniWDL validates successfully. So it looks like it has trouble validating empty structs (should I create a new issue for that?).

Read more comments on GitHub >

github_iconTop Results From Across the Web

Structure array - MATLAB - MathWorks
A structure array is a data type that groups related data using data containers called fields. Each field can contain any type of...
Read more >
Structural support - Wikipedia
A structural support is a part of a building or structure that provides the necessary stiffness and strength in order to resist the...
Read more >
Support Structure - an overview | ScienceDirect Topics
Support structures are a core AM design capability that can be used to offset some of the manufacturability constraints inherent to AM processes,...
Read more >
Get support with Struct PIM
Call our direct support line +45 4290 3600. We strongly advise you to use the help desk channels whenever you can, as it...
Read more >
Support Structures - Sternberg Press
Support Structures is a manual for what bears, sustains, and props, for those things that encourage, care for, and assist; for that which...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found