Dynamo DesignScript graphs become unresponsive due to class clash with Archi-lab package

[ThomasMahon]

Dynamo version

1.2.1

Operating system

Win 10

What did you do?

Ran a script with approx 2k lines of Imperative DesignScript.

What did you expect to see?

The script to execute (its been in use successfully for months)

What did you see instead?

The graph is completely unresponsive and the cause is a clash with Archi-labs List class. This is what I narrowed it down to, and so I added DSCore.List to all List objects in my DS. It still doesn't solve the problem. My only option is to completely uninstall Arch-lab package, but its distributed across my clients office and relied upon by a number of their users so I can't use this as my solution.

Considering these clashes cripple Dynamo graphs, the purpose of reporting this issue is to suggest a more robust approach to DesignScript libraries and third-party libraries to prevent this from happening.

If you need the example DYN to run tests, I can provide one.

[johnpierson]

Definitely not exclusive to ArchiLAB. I've seen similar things with other zero touch libraries as well. I won't name them here as to not call anyone out. That being said, I agree that this is something that needs remedied because I have seen it be an issue in a Dynamo workshop at AU2015.

[aparajit-pratap]

@ThomasMahon is this the archi-lab.net package?

[aparajit-pratap]

For associative language (i.e. code outside the [Imperative] language block), we have a solution to automatically resolve namespaces whenever there is a namespace/class name conflict on installing a new package. This way existing CBN's automatically work. However this solution doesn't work for imperative code and is a known issue.

More importantly I just realized that adding the fully resolved name for the class doesn't work AT ALL inside imperative language blocks and has been an issue all along!

DSCore.List.Count(1..10); // Works
[Imperative]
{
return = DSCore.List.Count(1..10);
}; // returns null!!!

Unfortunately I can't think of a workaround right now. @riteshchandawar @kronz this is MAJOR and must be addressed.

[aparajit-pratap]

@monikaprabhu could you log this?

[ThomasMahon]

@aparajit-pratap yes, archi-lab.net package. I couldn't find a workaround either, so thanks for confirming this problem is a bug in DS.

@sixtysecondrevit this is an issue with classes conflicting (ambiguous references) with DS, not a package issue (package was only mentioned to describe the problem). The same thing happens in certain cases when writing Python nodes that call methods from the Autodesk.Revit.DB and Revit.Elements namespaces. A simple solution is to add the namespace and class before the method. I was reporting that this approach had no effect in DS, which, as it now transpires, is indeed a serious bug!

[kronz]

There's 2 issues here, each of which we are addressing in Dynamo 2.0.
The first is the somewhat second class citizen status of Imperative code, which is currently under development and refinement (thanks @aparajit-pratap !) and will be both awesome and documented for 2.0.
The second is the issue is a little tricker, the idea of privileged namespaces. We had originally made it so that "out of the box" functionality was not treated separately from loaded libraries, but we need to revisit this decision in Dynamo 2.0. When we first made this decision there were relatively few conflicts, but we are seeing more and more. Giving out of the box functions their own privileged status will not solve all the problems (packages will still be able to conflict with each other) and would inject some internal philosophical contradictions.

[aparajit-pratap]

@kronz are you suggesting we should incorporate this idea of having privileged namespaces? As you mentioned, right now we do not, and there were certain reasons why we decided not to go ahead with the idea of giving privileged status to out of the box namespaces.

Other than currently lacking the support for automatic namespace resolution inside imperative blocks, I do not see any other issues we have with conflicting namespaces; do we have any? In other words I feel confident of the robustness of the current namespace resolution strategy we have in place so would be interested to learn of cases where it fails. I'll understand if it is a little confusing or hidden for users since the only way to recognize if there are namespace conflicts right now are using autocomplete in CBN's. This is only to raise more points for our discussion next week.

[aparajit-pratap]

Tracked: https://jira.autodesk.com/browse/DYN-704

[coderPE]

I was facing the same issue.
For now you could make a dummy function in another code block.
This function, say - Dummy1 contains, for example, a DSCore.List.Chop(), (which is not working inside Imperative loops).
Call Dummy1(variables1..n) from inside the imperative loop, and you should get the desired outcome.
But please fix this asap, Imperative loops are of not much use if you can not call functions within it.

Another thing I noticed is that the autocomplete feature is buggy and a few functions don't show up while typing, but they do work when you completely type them out.

• Thanks

[johnpierson]

Tracked internally as QNTM-5647.

[aparajit-pratap]

Fixed in #9252. Please verify and close.

[coderPE]

Does this mean this issue has been fixed?
If yes, which version of Dynamo should I install?
If no, is there an ETA on this?

-Thanks

[johnpierson]

Next release. Keep an eye out on http://dynamobuilds.com/