I don’t find it so bizarre, sorry… if I move a plant in my house from the kitchen to the bathroom, I don’t usually expect it to move back to the kitchen on it own.
After modifying the target document, you will just need to set back its original value. A variable named ghdoc is provided to make the task easier, but you may also just store the original value in scriptcontext.doc, like so…
Python is a great language, since its syntax is very easy and clear. The more i do Python, the more I like it. Regarding “easiness” its better as c# and even much more better as c/c++.
However there is a reason why most tech universities begin teaching computer science/informatics in c and why I’m trying to get good at pure c programming. You actually have a hard time understanding whats really going on if you don’t care about the lower mechanics. All the comfort a “higher” languages offers you; you wont understand anything right if you didn’t do it on a lower Level (at least once). Same analogy for modelling, algorithms and library usage.
Usually a mix of understanding debugging, reading error messages inbetween their lines and error checking (at least at the critical parts) helps you in solving these problems by your own.
It is really hard to study a unknown library, sometimes harder as learning the language. However using IronPython to learn a c# wrapper library is rather hardcore. Therefore , if you guys want to do things beyond rhinscriptsyntax believe me, its much easier if you understand concepts of C#. Understanding C# is for Rhino/Grasshopper much more benefical. If you know both you can do Rhinocommon in Python.
Hi Giulio, i think i forgot to reset it since ghdoc was not there without importing it. Imho for a more seamless integration of rhinoscript syntax things like rs.ObjectLayer should work out of the box.
well, excluding this problem and using rhinoscriptsyntax only, it is actually quite easy. However rs doesn’t fully wrap around rhinocommon.dll, and also not around grasshopper.dll. So the moment you need to do more as provided you will get into bigger trouble as learning c#. And C# is actually not that complicated as c.
So for example doing datatrees with python is kind of weird for beginners, because you mix c# style with python and if wouldn’t have started with c# in first place,you wouldn’t understand this weird construct at all.
Didn’t know that you have such a strong programming background, but then you excactly understand my point. Its the hatelove I share with python -> Python emphasis so much on clean syntax that it gets inconsistent. This is esspecially true for the dotnet port of IronPython, and even more for GHPython.
In the end your increased productivity through simpler syntax gets pointless when you running into weird behaviour through inconsisty and not being strongly typed…
Guys, let me be quite frank. Layers and Grasshopper is definitely not a strong point, because Grasshopper does NOT include layer information in its default logic. No matter what you do, it will be awkward because attributes are not what Grasshopper is specialized in dealing with. It specializes in geometry. It discards attributes immediately after the first calculation.
They will, once Grasshopper will have object attributes (like layer, color, etc) held together with geometry items. Right now, we added Guids, as you could see, for Rhino 6, but attributes are part of the discussion for GH2. I remember also a specific discussion on the topic with David. No promises, yet, though.
Thanks. This is exactly what we hope for.
Yes I agree. The DataTree type is extremely hard in Python. I’d go so far as to argue that DataTrees are hard and a little inconsistent in any language. I much prefer nested lists when possible, and ghpythonlib.treehelpers allows to translate seamlessly from one to the other. This stuff.
I was thinking about this and I agree that GhPython should set back the “normal Grasshopper document” even if you do not do it yourself. If you happen to have modified it by accident like this without resetting it, it’s puzzling (like when you try to pick a point at random and you have OSnap ON). All “modes” have this peculiarity, and, in this case, I should have thought about that. Bash me.
Please use this:
import scriptcontext as sc
import rhinoscriptsyntax as rs
sc.doc = Rhino.RhinoDoc.ActiveDoc
a = rs.ObjectLayer(x)
sc.doc = ghdoc #important, set it back to default
I agree. We need to hook up the debugger for GhPython, at least the same type that is in the _EditPythonScript editor. In general, GhPython is there to offer people that like Python the possibility to script with it, not to take it away from people who like C#.
I also think rhinoscriptsyntax with GhPython for geometry is at least in 3 aspects simpler for beginners than RhinoCommon with C#, because it does not have objects, because it requires no understanding of methods (only functions), and because it’s procedural with examples. Personally, I like C# for other things, like UI, customizations, where there is a need for fast calculations, etc.
WARNING!! Do not use the ActiveDoc if you don’t have to. Under Mac Rhino the ActiveDoc can change while a command is running. Use the doc that is passed to you in your RunCommand function or continue to use the same doc after the first call to ActiveDoc.
VB, a wannabe Pascal. So it wouldn’t be a big step for you. I’m a Pascal/Delphi oldtimer myself, started out with VB.NET for RhinoCommon, but people here strongly encouraged me to do C# instead. So I did (~6 month ago).
No problem, once I broke my neck trying to view type declarations which are on the wrong side. I got over it in a few weeks.
And some degree of duck typing is there as well. No need to repeat types over and over again. This works better (and an optimization tool in VS suggest I drop all the types and go for war, i mean, var declarations instead, like so):
var i = 0; // int
var d = 0.0; // double
var pt = new Point3d(0,0,0); // crystal clear type.
var vec = new Vector3d(pt1 - pt0); // that's all it takes
var lst = new List<double>(); // guess
// The list above can be repeated for no good reason;
List<double> lst = new List<double>(); // guess
for (var j = 0; j < lst.Count; j++)
var item = lst[j]; // item gets it right,
In short, C# is pretty straightforward for anyone having used object oriented languages. I miss pointers though, GC makes you lazy.
That’s an insult to Pascal. I spent 14 years working in UCSD Pascal, a highly advanced platform for its day. It was long in the tooth by the end of that period and C could always run rings around it for pure speed, but it had some advantages including extraordinary cleverness at running large, complex applications in very little memory and being object code portable. Just a few small, stable pieces optimized for Intel vs. Motorola CPUs or dealing with file locking, which differed depending on which of the many host operating systems we ran on (DOS, Windows, DESQview, Unix, Commodore 64…). Good discipline for learning the performance benefits of superior algorithms vs. brute force. Fun times.