How can i detect the errors in a code block script?

DesignScript
#1

hi guys,

I am facing a problem in the coding in the code block that is taking a lot of time. The problem is that I am spending ages to detect where is the error in the code block script and it seems that dynamo does not specify where is the code line that is making these errors.

dd.JPG841×805 110 KB

This is a small example!

Any suggestions ?

#2

It could be a silly idea, but maybe dividing the block into smaller blocks would help you to find the problem…

#3

Short answer no. Ive requested a badly needed debugger which appeads to be in development so for the time being your only option is to cut chunks of you script into separate code blocks as this will help you to isolate your problem. Also avoid over use of node to code. Its worthwhile if you’re scripting (I.e. doing more than clicking node to code and renaming a few variables) or using it to write def’s, otherwise your abstracting your graph and making your life unnecessarily difficult.

Latest on the debugger:

#4

Thank you guys for replying

So the only way is to divide my code block, but the reason I didn’t do that is to call parameters directly

Thank you

#5

Yes. Use that method to solve the problem then put it all back together again if it’s important, Also consider switching back to visual programming in places for the reasons previously mentioned.

#6

Recently I found that using design script is faster than the dynamo nodes while running or am I wrong?

#7

Depends, it all boils down to tessellation (what gets drawn/output onto the graph). If you are coding defs or anonymous functions with a number of intermediate steps in the body of the code, then it’s going to be faster than the visual equivalent (as the visual one has to tessellate every step). For node to code or ordinary code blocks, every line has an output, but I don’t think tesselation occurs until you wire one of the outputs to something else. If that is the case then you will see a slight performance increase, but then it’s more difficult to read (referring to over use of node to code) and troubleshooot

#8

Thank you man good to know that,In my case am using def

#9

@ali.safiaddine if you are working on programs that are this large perhaps looking into c# and zero touch import will work better for you since you can debug with visual studio at this current time before there is a debugger for DS in Dynamo.