Grasshopper

algorithmic modeling for Rhino

Hi All,

I've been trying to get "unsafe" code to execute within the c# component, but it seems like it needs to be enabled in compiler settings? (which I don't have access to within GH)

I remember David mentioning here that unsafe could be used inside the component, but I'm consistently getting the error:

"Error: Unsafe code may only appear if compiling with /unsafe (line XXX)"

regardless of whether the unsafe bits are inside RunScript or in a separate unsafe function .

Greatly appreciate any pointers and help :)

Views: 819

Replies to This Discussion

Hi,

di you tried :

public unsafe static void Main()

{

' your code

}

Yup.. tried it as a separate function, and also tried putting my code in an unsafe{} within the RunScript.. Neither seems to work.

Also tried removing all my code and just putting the unsafe keyword in the function declaration and that's enough to throw the error..!

Have you had any luck with it?

Just wondering if I'm making a mistake or is it just not possible without some back-end tweaking from David..

You can use unsafe if you're making your own GHA and are in control of the compilation process. There's no way to use it in a script component. Out of curiosity, what do you need it for?

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Okay.. that explains it.

I was reading pixels on an image, but the code is to be used outside of Grasshopper/Rhino.. which is why I was not using the GH_MemoryBitmap.

Grasshopper sometimes also doubles as a great sketching/debug tool for pseudocode/.NET code considering the convenient Graphic pipeline/visualization it offers :)

Making do with Marshal.ReadByte/WriteByte for now.

Will use unsafe in the assembly.. Thanks for help!

Marshal.ReadByte is very slow. You might want to consider copying the entire bitmap data into an array of bytes. That's how GH_MemoryBitmap gets the speed. Unfortunately it doubles memory usage and involves a block copy, but GH_MemoryBitmap is a VB class and VB doesn't do unsafe.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Worked.. and indeed is a significant speed bump!

More memory usually seems to be the better trade-off as compared more CPU cycles.. atleast while its not multi-threaded. Though considering this is an image/read-write, it could easily be parallelized..

This looks like a good thing to do on a bad-weather-weekend :)

(too many of those around here in London!)

nice!

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service