Additional Rhino 6 GhPython feedback

[AndersDeleuran]

Hi @piac, @brian + all,

It’s been a while, but we finally upgraded to Rhino 6 and I’ve now had a few months of GHPythoning within it. Overall this has been a very positive experience, but I’ve also experienced issues that I would consider a (sometimes highly severe) step backwards compared to the Rhino 5 GHPython editor. These include, in order of severity:

Functional Issues (that break development):

1: Printing to Output is MUCH slower and leads to unresponsive editor/crashing Rhino

Printing large data chunks in Rhino 6 will make it unresponsive and crash Rhino (and I keep falling into this hole):

Printing the same list in Rhino 5 is more or less instant and one can easily scroll up/down the data in the console window (which is super duper useful):

Edit 1: This print lag is made more apparent when printing multiple/many times. Where the cost of printing isn’t actually captured by the component profiler, but is clearly noticeable and can be seen below the canvas on the Solution completed in ~N seconds bar (many times over):

As also apparent from this example, dragging the scroll bar to the right of the Output window is also much more laggy/choppy in Rhino 6.

Edit 2: Had this crash report on my desktop afterwards, looks like some casting business with the DataGridView that was implemented for the Output window:

[ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidCastException: Specified cast is not valid.
   at GhPython.Forms.PythonScriptForm.outputGridView_SortCompare(Object sender, DataGridViewSortCompareEventArgs e)
   at System.Windows.Forms.DataGridView.OnSortCompare(DataGridViewSortCompareEventArgs e)
   at System.Windows.Forms.DataGridView.OnSortCompare(DataGridViewColumn dataGridViewSortedColumn, Object value1, Object value2, Int32 rowIndex1, Int32 rowIndex2, Int32& sortResult)
   at System.Windows.Forms.DataGridViewRowCollection.RowComparer.CompareObjects(Object value1, Object value2, Int32 rowIndex1, Int32 rowIndex2)
   at System.Windows.Forms.DataGridViewRowCollection.RowArrayList.Pivot(Int32 left, Int32 center, Int32 right)
   at System.Windows.Forms.DataGridViewRowCollection.RowArrayList.CustomQuickSort(Int32 left, Int32 right)
   at System.Windows.Forms.DataGridViewRowCollection.Sort(IComparer customComparer, Boolean ascending)
   at System.Windows.Forms.DataGridView.SortInternal(IComparer comparer, DataGridViewColumn dataGridViewColumn, ListSortDirection direction)
   at System.Windows.Forms.DataGridView.OnColumnHeaderMouseClick(DataGridViewCellMouseEventArgs e)
   at System.Windows.Forms.DataGridView.OnMouseClick(MouseEventArgs e)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
[END ERROR]

2: Output window does not allow for sub-highlighting and copying

One cannot sub-select strings in the Output window, everything in one print is selected by default:

In Rhino 5 this was possible (and I use it all the time):

3: Output window cannot scroll within one print call

There is no scroll handle on large prints in the Output window. See image reference in previous point.

Functional Issues

4: Output window blue highlight is always on some output

The blue background/white font highlighting is always on one print call. Meaning that if one only has one print call, this is automatically highlighted. I find this confusing (and quite visually distracting and displeasing). A print should only be highlighted when selected. And as per point 3, should really only be highlighted when using the sub-selecting left-click and drag known from other text/code editors.

5: Test button disappears when making the editor small

The right-arrow/Test button goes away when making the editor too narrow:

6: Double-clicking component enters Grasshopper search mode

When you double-click the component to enter the editor, the Grasshopper canvas search kicks in:

7: Double-clicking a new component opens editor in upper left corner

While this was also the case in Rhino 5. It would be great if it opened at the component.

8: Instantiating tuples highlights equals sign as if making a function

This is a very minor issue, but in Rhino 5 syntax highlighting seems to work okay:

9: What is the functionality of the arrow over the Output window?

More of question really, but what does this do:

Aesthetic Issues

10: Output window grey background is too dark

I find the dark grey background to stick out like a sore thumb within the (or at least my) Rhino/Grasshopper context, and would much prefer it has the same color as the Help window background:

11: Test/OK buttons should be either icon or text

Having both is unlike the other editors in Rhino (i.e. C#/VB components and the EditPythonScript editor), but also takes up space (see point 5). If they are to be icons, perhaps a similar aesthetic as the other editors should be used.

12: Test/OK buttons should have hover over help

Explaining what they do.

13: The new snake icon is (subjectively) ugly and (objectively) poorly cropped

This is probably one for @DavidRutten, and is certainly still a minor issue, but hey:

[piac (Giulio Piacentino)]

I moved this discussion to a new topic, in order to start with this fresh.
Also, I’ve added a pin in our bugtracker to remember this: RH-54146.

For now, I can mention that many of the functional issues you report are derived from the usage of the DataGridView in the window, which has been otherwise very well adopted – I think because it’s making it clearer to understand which print echoed which part. In general, printing 10’000 items is probably a bad decision (you are also a developer, so it might be a bug), because prints are meant only to report particular cases. GhPython can have results extracted via normal outputs and that’s far more efficient. Probably there could be a low-quality print with the inferior window in case the print is too large.

I agree that subselecting would be nice. I’ll see if I can tweak it.

Many of the minor things can be tweaked, like: opening location centered on component, and the icons of component (@DavidRutten) and menu. The gray background is the unedited Windows color for empty controls: you can change the Windows Theme and it will change, if the theme changes that.

Number 8 will probably need a little more explaining. Could you elaborate, @AndersDeleuran? This area is being researched by @Alain, who is leading the charge on the future text editor.

[AndersDeleuran]

@piac

For now, I can mention that many of the functional issues you report are derived from the usage of the DataGridView in the window, which has been otherwise very well adopted

I understand that the DataGridView is the culprit, based on the reports that land on my desktop (see Edit 2 above) when the GHPython editor causes Rhino to crash. So the bug here (referring to your quote below) is explicitly and objectively known.

@piac

In general, printing 10’000 items is probably a bad decision (you are also a developer, so it might be a bug), because prints are meant only to report particular cases.

This again feels very prescriptive. When I develop in Python I rely heavily on print calls, not just for constantly checking the logic of what I’m doing. But also for things like introspection, type-checking, assembly exploration etc. that one would otherwise rely on the functionality of an IDE, or access to API documentation for. All these use cases can and will lead to large print calls. Which in the environments I prefer to use (such as Sublime Text etc.) aren’t a problem. They are designed to be lightweight, performant, and agile. Which was also the case with the old GHPython editor.

It’s great that DataGridView has been otherwise well adopted, it really is. But for the workflow I describe here, it just doesn’t add any useful features. But instead kills performance, crashes Rhino, and generally feels shiny/bloaty (I understand that visualising compute cycles can be useful/neat, but I have zero usage for this). I’m sorry to be so negative here, but this is really a super bummer!

Edit: For reference, here’s how the Sublime Text output window looks/behaves/performs:

In terms of future text editors in Rhino/Grasshopper, I’d personally much prefer this direction.

@piac

GhPython can have results extracted via normal outputs and that’s far more efficient.

I think we know that’s not super true. Having to pipe development/debugging information to an output would also put it on the same level of the C# component (or the Dynamo Python editor ) in terms of the development experience. Which would be a pretty large leap backwards IMO.

@piac

Many of the minor things can be tweaked, like: opening location centered on component, and the icons of component (@DavidRutten) and menu.

That’d be awesome. One thing I forgot here: Opening the search/find menu (Ctrl + F) should also preferably occur closer to the editor (it opens in the far left/upper corner currently if I recall).

@piac

The gray background is the unedited Windows color for empty controls: you can change the Windows Theme and it will change, if the theme changes that.

I’m away from my system right now, but I’m pretty sure the GHPython Help window background has the lighter grey color. So I assume it could be edited in the source.

Afraid I’ve had no luck finding the Windows theme controls that allows one to fiddle it with. It seems that Microsoft have removed a lot of this customisation. As per this old thread, I’d vote for explicit control within the app (or hard coding it to fit within the context aesthetic).

@piac

Number 8 will probably need a little more explaining. Could you elaborate, @AndersDeleuran? This area is being researched by @Alain, who is leading the charge on the future text editor.

Ah yes, that one was a bit cryptic. As far as I can tell, the syntax highlighter will assume that anything (or at least in some cases) in front an ( is the name of a function/class, and as such should be in bold. Instantiating a tuple is a basic case of this.

[ivelin.peychev]

For 6. It is a regression, in my opinion, reported numerous times. @DavidRutten, explained it is changed like this to allow search to appear when double clicking groups. I certainly don’t like it.

[AndersDeleuran]

@ivelin.peychev

… it is changed like this to allow search to appear when double clicking groups.

Ah, I was not aware of this. Thanks for the information.

[TomTom (Tom)]

@AndersDeleuran

Printing to Output is MUCH slower and leads to unresponsive editor/crashing Rhino

Have you ever tried using a windows console to output?:

Execute this once from the Rhino Python console:

import System
import System.IO as io
from System import Console
import Microsoft.Win32.SafeHandles as sh
import ctypes as ct

stdOutputHandle = ct.c_int(-11)
ct.windll.kernel32.AllocConsole()
intPt = ct.windll.kernel32.GetStdHandle(stdOutputHandle)
stdHandle = System.IntPtr(intPt)
safeFileHandle = sh.SafeFileHandle(stdHandle, True)
fileStream = io.FileStream(safeFileHandle, io.FileAccess.Write)
encoding = System.Text.Encoding.GetEncoding(437)
standardOutput = io.StreamWriter(fileStream, encoding)
standardOutput.AutoFlush = True
Console.SetOut(standardOutput)
Console.WriteLine(“This is a console window”)


and this from a GH Python or Rhino Python script:

from System import Console

Console.WriteLine(“Hi from Grasshopper”)


[AndersDeleuran]

@TomTom

Have you ever tried using a windows console to output?

I have indeed, when executing .py files through the python.exe (as a rudimentary input/output UI) and for C++ development.

Edit: Not that I would consider the Windows console as a valid solution/workaround in any way, it is also not close to the performance of e.g. Sublime and GHPython in Rhino 5:

[piac (Giulio Piacentino)]

@AndersDeleuran

I think we know that’s not super true.

Sorry, please allow me to repeat.

GhPython can have results extracted via normal outputs and that’s far more efficient.

It’s very true. In Sublime, we are in a console application where the only direct output is text. Here, printing is the worst way to output data for Grasshopper. When printing, data needs to be converted to text, flushed into a stream, gathered from the stream, its location within the cycle system needs to be recorded, and finally we can process it as a normal Grasshopper text output. This means that all the steps prior to “process as a normal text output” are extra costly. It’s even surprising all this does not take even longer.

I understand that this particular editor tweak (the DataGridView) might not be required for someone like you, who understand the cycles system, has developed for year, and knows what he’s doing. But for many, it’s very very useful. I hope I can develop a way to switch here. We will need to see how important and time-consuming this would be to implement.

@AndersDeleuran

Which in the environments I prefer to use (such as Sublime Text etc.) aren’t a problem.

This is understandable! Generally, I’d really recommend you explore developing with a professional IDE, rather than expecting to make the GhPython editor a professional IDE in its own right. The GhPython IDE will never be completely on-par with a professional Python IDE, simply because it’s part of a 3D modeling program and it has a more-circumscribed purpose*.

Do you know about the new option to debug within GhPython with an external IDE? This really makes using another IDE a solid option, even better than GhPython itself. This should get you excited**.

@AndersDeleuran

It seems that Microsoft have removed a lot of this customisation.

Feel free to pin Microsoft about this. I suspect the setting is still there, buried under many layers. It was certainly there in Windows 8, the last time I checked.

* This does not mean that we will not improve it. In fact, some improvements are being developed.
** With this, please do not tell me that we only develop for new users! It’s already in Rhino WIP.

[AndersDeleuran]

@piac

I hope I can develop a way to switch here.

That would be an ideal solution.

@piac

… rather than expecting to make the GhPython editor a professional IDE in its own right.

I’ve continuously been stating (and am expecting) the exact opposite of GHPython:

@AndersDeleuran

… designed to be lightweight, performant, and agile. Which was also the case with the old GHPython editor.

My point was that adding the type of bloat (as I see it) that has crept into the new editor, is a move towards the bloat and sluggishness I would expect from a full IDE. I wouldn’t consider adding the DataGridView a tweak, but a major modification (in that direction).

@piac

It was certainly there in Windows 8, the last time I checked.

Yeah

I feel like I’m not really getting through here. So I think I’ll just Homer into the bushes at this point.

Best,

Anders

[TomTom (Tom)]

I have read more about that Console issue, and its known that the default microsoft console is pretty slow. I think it might be an option to elaborate using Bash (like Git), which is supposed to work much faster. But in the end the point remains, why printing 10000+ of lines? Please don’t get me wrong, because I really think you are a great develloper, but what about writing unit and integration tests instead of outputing that many data and check per eye? I just recently established an full continous integration for the software I currently develop. And its astonishing how many bugs are prevented, just by writing tests, line covering nearly up to 100% of (testable) code. I believe chances are way higher to miss an error by eye-scanning then by asserting it from a test routine. Test Driven Devolopement, is slow and sometimes annoying, but the benefit is really great.

[stevebaer]

@AndersDeleuran

I’ve continuously been stating (and am expecting) the exact opposite of GHPython

I think you’re right to expect this. I doubt we’ll make any drastic changes in V6 for the code editing experience, but it is something that we are trying to improve in V7.

---

I’ll need to read through the rest of this post as I just became aware of it.

[AndersDeleuran]

@TomTom

Please don’t get me wrong, because I really think you are a great develloper, but what about writing unit and integration tests instead of outputing that many data and check per eye?

No worries, and likewise. I don’t consider myself a developer as such. I’m a designer that employs computation as my primary medium, with the intention of solving “design problems as fast and agile as I can. If my intention was to write “real” components I’d be in Visual Studio” (douchely quoting myself from the type hint topic). GHPython has been absolutely terrific in supporting this type of development:

@AndersDeleuran

When I develop in Python I rely heavily on print calls, not just for constantly checking the logic of what I’m doing. But also for things like introspection, type-checking, assembly exploration etc. that one would otherwise rely on the functionality of an IDE, or access to API documentation for. All these use cases can and will lead to large print calls.

Using an external IDE, writing unit tests etc. quite simply adds unnecessary complexity and layers of dependencies to this (i.e. mine) development environment. Which occurs across several machines, several teams, dealing with an IT department etc. In what can only described as being a very high pace.

One of the things I’ve neglected to mention here actually (apologies), is that upgrading GHPython be a standard component in Rhino 6 (along with Kangaroo!) has really helped tremendously

[ivelin.peychev]

@piac

I understand that this particular editor tweak (the DataGridView ) might not be required for someone like you, who understand the cycles system, has developed for year, and knows what he’s doing. But for many, it’s very very useful. I hope I can develop a way to switch here. We will need to see how important and time-consuming this would be to implement.

I’d love to see a toggle for this. I am not sure I understand what cycles system mean putting myself in the latter group. Still I don’t think DataGridView has a place as an output console. More like for example the Hydrostatics command results that best fits being tabular.
Simply put, since I don’t always know what I’m doing with GhPython I use a lot of printing checking for types and results. Sometimes I need to select a piece of what’s in the console in order to search for it in the API and currently that’s difficult, or requires additional steps (copy to notepad and selecting just a piece of the string).

[TomTom (Tom)]

@ivelin.peychev

Simply put, since I don’t always know what I’m doing with GhPython I use a lot of printing checking for types and results. Sometimes I need to select a piece of what’s in the console in order to search for it in the API and currently that’s difficult, or requires additional steps (copy to notepad and selecting just a piece of the string).

This is the drawback of a dynamic typed language. The time you save when not writing the type of an variable, just begins to add up in the end, by checking whats actually in there. Especially if you mix that with a framework developed for a rather strongly typed language - just as IronPython does with the .Net-Framework. Confusion just becomes perfect (f.e. Interfaces such as IEnumerable, access modifier …).
I guess that is also one of the reasons, Ironpython is actually a legacy system… I would have had a much harder time with IronPython, if I not knew C# (or .VB.Net alternativly). I can guess that its lots of work, but rewriting the Rhinocommon wrapper, to support CPython, would probably solve many of these problems at the end, because having the need for a good console log is probaly just the result of this confusion…

[ivelin.peychev]

@TomTom

This is the drawback of a dynamic typed language.

Oh no, I don’t think so, I spent even more time printing stuff when I work in pure C#. At least in Python I can easily figure out my errors by simple printing.

[Alexander_Jacobson (Alexander Matthias Jacobson)]

Perhaps this is a problem between the chair and the keyboard, but I find the printing output in this editor difficult to use. I use this all day and regularly work on meshes that have anywhere from 10,000 - 300,000 faces. I have issues when printing only a few hundred items in this editor, which means I am constantly dancing around to be careful of printing the wrong thing, for fear of the canvas freezing up.

Also… it is very difficult to explore python modules with dir() because there is no line numbering or line breaks on the printed output. This makes it especially difficult to navigate ghenv, which so far as I know has no other form of documentation.

[AndersDeleuran]

I’ve been quietly crossing my fingers. But as far as I can tell, none of these issues (nor the default type hint one) have been addressed in the Rhino 7 Beta. While I gather that effort is being put into developing a better scripting experience/editor across Rhino in general. It’s quite disappointing to (potentially) have to deal with a broken GHPython editor till Rhino 8 (or later)

As a refresher on issue number 1, try going print range(1000000) in Rhino 5, then Rhino 7 Beta.

[TomTom (Tom)]

I currently develop software on a daily base and I almost never print anything to a console anymore. If you want a log, you write a log file. If you want to validate, you write a unit test. If you want to check the logic you set a (conditional) breakpoint and step through the code. If you want to spot memory leaks or performance issues you use a profiler. Scriping has limitations and even the best script editor does not replace an advanced code editor or even IDE.
On the other hand, writing code without that, really helps in memorizing an api. And once you can write fluent Rhinocommon, developing is really fun.

[AndersDeleuran]

None of that addresses the fact that the new GHPython (console) is broken. Please refrain from diverging attention away from that (especially if you do not use the GHPython component). We just want to print to the console while we write Python code in Grasshopper. Why is that so hard to accept?

[TomTom (Tom)]

@AndersDeleuran

Why is that so hard to accept?

Its not hard to accept that at all. Besides this I use the GHPython Component from time to time. I just doubt that printing thousands of lines to a pseudo console is a good way of debugging. Logging to a file persist the information, even if the app crashes. It also makes it possible to compare results later.
Stepping through code and writing test routines, makes sure the logic works without going through the whole script. And a profiler tells you if you do things efficently without any leaks.