Rhino Script Compiler for Rhino5, second Beta

re: scriptcontext

Thanks @clement for pointing me to this post. This solved the issue I was having with the scripts failing when compiled.
I’m not sure how I missed this 2 years ago, but better late than never.

Thanks Steve for making this change.

Dan

Is this still the case for compiled python scripts?

Thanks Mark

When using the option “Generate source” of the script compiler, I get the following error:


Is this a known issue?

Not really. Are you compiling from a network drive or any other unusual configuration?

I’m compiling on my local disk, and can reproduce the problem on several workstations. My user account does have admin privileges.
Interestingly a similar error message (access denied) is reported when building plugins, in the cleanup step:

Compilation succeeds and the temporary folder created by the script compiler contains the plug-in, i.e. it’s not a big problem I’m experiencing. Still it would be nice to solve this.
On another note: Have you thought about open sourcing the script compiler? I would contribute to it.

Is the compiler compatible with the module ‘clr’?.
I would like to do something as this:

import clr
clr.AddReference("modules.dll")
import module_1

def run():
    module_1.runModule()
    
run()

… but not work. However when the dll is called from the Python Editor, the modules run without problem. Is a limitation of the compiler?

This is probably an internal bug in Rhino where the path to the module isn’t getting solved when the script is executed from a plug-in.

could I solve it somehow?

You could try setting the sys.path before calling clr.AddReference. That may fix the problem; just a guess

I tried this:

dir_actual = os.getcwd()
sys.path.append(dir_actual)

…but without success

The current working directory doesn’t really make much sense in this case. Try something like the following:

import sys
import System.IO
import Rhino
plugin_path = Rhino.PlugIns.PlugIn.PathFromName("JuanExpositoPlugIn")
path = System.IO.Path.GetDirectoryName(plugin_path)
print path
sys.path.append(path)

thanks @stevebaer,

I have tried it, but it doesn’t work.
I will search some solution this weekend. I still don’t have very clear where is the problem. I only know that the file ‘.dll’ works correctly when the plugin is called from the python-editor and not from the file ‘.rhp’.

Hi All,

I can’t find a way to define a version of the plugin. I thought I saw it before in the script compiler but not there; I also looked at RHI guidelines on WIKI: http://developer.rhino3d.com/guides/rhinocommon/plugin_installers_windows/

So after making the RHI out of zipped folder of the plugin I am testing I always get version 1.0.0.0 C:\Program Files\Common Files\McNeel\Rhinoceros\5.0\Plug-ins\MyPlugin\1.0.0.0

Where can I control the version number ?

thanks,

–jarek

Anyone ?

The version information needs to be compiled into the plug-in itself. The RHI system doesn’t have control over what version a plug-in is.

It doesn’t look like the compiler currently has support for setting a version. You would need to have the compiler generate the source files for you; add the version information and then compile with Visual Studio.

Thanks Steve. I’d add the version setting to the compiler wish pile.

–jarek

Done
https://mcneel.myjetbrains.com/youtrack/issue/RH-35623

@Jarek,

not sure if this helps, using the new compiler i put my plugin version information at the end of the start up message so i can at least check if updating the plugin worked or if the old version is still loading.

@stevebaer, i do miss the licensing and menu options which where available in the old compiler. Will something like this be considered in the future ?

c.

Thanks Clement, that’s a great suggestion. What I was trying to figure out and test is how the *.rhi installer recognizes and always installs the latest plugin version, (per wiki instructions). Now can’t do it unless manually compiling as Steve suggested.

Hi @stevebaer,

Since it is an anniversary of last activity on this bug report, I will try again and say that the current problem with compiled scripts not running inside transparent commands is quite a pain and makes a lot of compiled plugins over here much less useful…
https://mcneel.myjetbrains.com/youtrack/issue/RH-31820
Hope for some love for this one in 2017 !

–jarek