thanks very much Andrea for your response, I’ll watch out for your updates.
I already have some code that I was wanting to refactor and update using vscode and scriptsync together. I feel I’ve gone as far as I can with the inbuilt code editor and I think scriptsync will help me to have a more professional coding workflow
Hello @brian9 , thanks again for your report and feedback, that’s what makes script-sync better!
So I added compatibility for the ghpythonlib.treehelpers in the latest release 1_2_6 (you can update it and tell me if it works). On top of that now script-sync is parsing automatically nested lists into gh trees. So now, in the following example, both options work:
thanks a lot Andrea! I have updated script-sync, though I’ve also broken my code in the meantime so I will take a day or two to get back to where I was with the data trees.
Can I ask, how can I use vscode with script-sync to debug and inspect variables?
You are there is been an error in the publishing of the pacakges, let me fix this. Thanks for reporting!
In the meanwhile:
Just in case try to drop on the canvas a new script-sync component, do not use the old one. Script-sync is distributed as a .ghuser, hence old components won’t be updated automatically: you have to replace it with new ones after you have closed-reopend your Rhino.
You should thick the autoinstall box to automatically update your vscode extension everytime your close and reopen vscode:
The best for now would be to print your variables and inspect their values either directly in the “output” pane in vscode or by linking a text pannel to the stdout output of the script-sync component in your Grasshopper canvas.
The Script-sync plug-in is an excellent tool. However, it lacks the implementation of interactive geometry preview from VS Code to Rhino, similar to how Grasshopper interacts with Rhino when working on an algorithm. Having to delete the created geometry and press F4 after each code change to see if anything has changed is a very unproductive way to work on an algorithm. Replacing geometry transfer to Rhino with an interactive Display Pipeline preview would make your module invaluable!
Hello @Aleksandr_Oleynik ! Thanks for nice feedback. It would be very nice indeed. Right now I might have a couple of hacks to put this in place but it will require some thought for sure. I marked it as an issue on the repo, I’ll open a PR to tackle it asap. Feel free to add details/ideas on this implementation! Cheers
Good afternoon, Andrea.
Thank you very much for your response.
I am really looking forward to this solution.
Rhino has its native RhinoCode Extension for VSCode, which works in a similar way, though slightly less effectively than your component — it requires viewport updates in Rhino and also creates objects without showing a preview (like in Grasshopper).
It’s unclear why such an essential feature — graphical preview output from VS or VS Code — is still missing in Rhino itself…
This isn’t about whether Rhino’s built-in code editor is good or not — it is good! The point is that for working on even moderately complex projects, you need more than just a code editor. You need a full-fledged workspace with the ability to eventually convert the code into a component for Rhino or Grasshopper.
Moreover, many people now rely heavily on AI for their work, and VS Code is perfectly integrated with Copilot, whose assistance cannot be overstated.
By the way, I’m not a programmer at all, yet with the help of AI, I can create fairly complex modules for Grasshopper without writing a single line of code myself. My role is to set the task, formulate the verbal algorithm for generating graphics, provide feedback and error control for the AI, and verify the results in the Rhino viewport. All the code is written by AI!