Continued developer absence

Apologies for my long periods of absence and poor attendance over the past few months, I've been reasonably busy with travelling, workshops and client visits.

I'll be at Siggraph in early August (New Orleans) and I'm throwing every available inch of development at this deadline. It's clear now that I won't be able to solve all reported bugs before then, but I would nevertheless like to release a new version in the upcoming week.

So I'd like to ask for a list of the most pertinent bugs/lacking features which need to be solved asap.

Goodwill,
David

--
David Rutten
david@mcneel.com
Robert McNeel & Associates

Replies to This Discussion

Permalink Reply by David Rutten on July 29, 2009 at 3:48am

Hi Frank,

yes, that's how it's supposed to work. It will copy the ENTIRE data tree into a single output. It is thus an 'atomic' operation that can only run once.

I see your point however. It would be useful to be able to separate branches into individual lists.

Permalink Reply by Paul N Jeffries on July 29, 2009 at 5:00am

Hi David,

From what you've said in the past this may be a little bit outside your control, but the main thing I'd like to see improved is the scripting components, particularly debugging - just being able to tell which line is throwing an exception would save huge amounts of time (not that I ever make mistakes, of course...). But maybe a nice SDK for writing your own components as already mentioned would make this unnecessary...

Also looking forward to seeing the new tree-manipulation tools; particularly ones which would make it easier to set up tree structures in the first place. Has there been any progress on the 'latch on' component modifiers that you mentioned a while ago? Those sounded pretty cool.

Paul

Permalink Reply by David Rutten on July 29, 2009 at 7:57am

"Has there been any progress on the 'latch on' component modifiers that you mentioned a while ago? Those sounded pretty cool."

No progress at all in this area. I've focused mainly on DataTree tools and cleaning up the core.

I'll see what I can do about the compiler-errors, but I won't have time to do it now.

Permalink Reply by David Rutten on July 29, 2009 at 11:06am

"...but I won't have time to do it now."

Scratch that. I managed to add line numbers to the error report. But it only works if the code editor has been used at least once (the code you write is not the code that actually gets compiled, so the line numbers don't match by default).

Permalink Reply by Dimitrie Stefanescu @idid on July 29, 2009 at 5:03pm

whoa! that's really really great news! hours of working out where the bloody bugs are hidden are over.

PS: maybe you can reference the latest version of the system.dll in the c# scripting component? you had to manually add that correct reference... sorry if this has been mentioned before here (and you always got an orange component because of a double reference, which might be confusing for some).

Permalink Reply by David Rutten on July 29, 2009 at 5:07pm

Note that line numbers are only given when there is a compiler error. If the script compiles but crashes during runtime, I can't get at the line numbers very well...

Permalink Reply by Dimitrie Stefanescu @idid on July 29, 2009 at 5:15pm

still, some 80% of errors are caused by bad syntax (missing semicolons, bad formatted vb, blah blah.) so it sure is something to be happy about :)

Permalink Reply by Paul N Jeffries on July 30, 2009 at 2:43am

Brilliant, thanks David! Lots of my colleagues have been put off learning to script in .NET by how awkward the debugging in grasshopper is - hopefully this change will bring over a few more converts!

Permalink Reply by Paul N Jeffries on July 30, 2009 at 5:30am

I just thought of another (hopefully easy) one; some form of autosaving. I keep closing Rhino but forgetting to save my grasshopper definition - some kind of automatic backup save every ten minutes, or even just a 'hey dummy, you forgot to save' dialog in a OnRhinoClose event would prevent a lot of accidental-work-loss-profanity.

Permalink Reply by David Rutten on July 30, 2009 at 6:37am

Paul,

I completely agree. However, this is something I want to get right the first time and that's going to take a bit too long.

Permalink Reply by Daniel Xiong on July 30, 2009 at 5:34am

Hi David,
In a VB.NET box I just put the following code:
If y Is Nothing Then
a = x
Else
a = y
End If

I am sure y is not empty but it turns out that the output is not the same with y.
I have uploaded the files.

Attachments:

bugDanielXiong.jpg, 59 KB
bugDanielXiong.zip, 43 KB

Permalink Reply by David Rutten on July 30, 2009 at 6:41am

Hi Daniel,

I've ran this file in the new version and it seems to be running fine.

Do note that your data isn't matched up. If you flatten the inputs of the VB Script component you'll see the missing curves as well.