Develop Reference

Pythonnet stackoverflow exception in Python.Runtime.dll when calling Py.Import

I'm using python 3.5 installed in a virtual conda environment. The stackoverflow happens during a call to Py.Import:
dynamic np = Py.Import("numpy");
This was once working on my machine, but I decided to reinstall my Python environment. I set PythonEngine.PythonPath to the location of my virtual environment. My root Python install is also version 3.5. If I uninstall numpy, Py.Import fails expectedly due to the module not being found. If I reinstall numpy, I get a stackoverflow:
An unhandled exception of type 'System.StackOverflowException'
occurred in Python.Runtime.dll
Worker Thread Python.Runtime.dll!Python.Runtime.ImportHook.import Normal
[External Code]
The maximum number of stack frames supported by Visual Studio has been exceeded.
Importing built-in python modules works. I tried importing one of my own modules with a print statement at the first line, and the print statement gets called twice, so something is fishy. Any ideas why the stackoverflow exception is occurring?
Python 3.5.3
64-bit
numpy 1.13.1
VS2015
Pythonnet 2.30-py35-dotnet

SonarException: Unknown metric: temp-method-lines

I was searching for answer many hours but I haven't found any solution.
I'm running sonar for C# project, I using Sonar 3.4 and sonar-runner 2.0 and C# plugins:
sonar-csharp-core-plugin-1.4
sonar-csharp-fxcop-plugin-1.4
sonar-csharp-gallio-plugin-1.4
sonar-csharp-gendarme-plugin-1.4
sonar-csharp-ndeps-plugin-1.4
sonar-csharp-squid-plugin-1.4
sonar-csharp-stylecop-plugin-1.4
and after running the analysis by sonar-runner I getting that exception
Exception in thread "main" org.sonar.runner.RunnerException: org.sonar.api.utils.SonarException: Fail to decorate 'org.sonar.api.resources.File#243e2c21[key=ApplicationName.cs,dir=,filename=ApplicationName.cs,language=C#]'
at org.sonar.runner.Runner.delegateExecution(Runner.java:288)
at org.sonar.runner.Runner.execute(Runner.java:151)
at org.sonar.runner.Main.execute(Main.java:84)
at org.sonar.runner.Main.main(Main.java:56)
Caused by: org.sonar.api.utils.SonarException: Fail to decorate'org.sonar.api.resources.File#243e2c21[key=ApplicationName.cs,dir=,filename=ApplicationName.cs,language=C#]'
at org.sonar.batch.phases.DecoratorsExecutor.executeDecorator(DecoratorsExecutor.java:84)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:70)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:63)
at org.sonar.batch.phases.DecoratorsExecutor.decorateResource(DecoratorsExecutor.java:63)
at org.sonar.batch.phases.DecoratorsExecutor.execute(DecoratorsExecutor.java:55)
at org.sonar.batch.phases.Phases.execute(Phases.java:92)
at org.sonar.batch.bootstrap.ProjectModule.doStart(ProjectModule.java:129)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.bootstrap.BatchModule.analyze(BatchModule.java:147)
at org.sonar.batch.bootstrap.BatchModule.analyze(BatchModule.java:141)
at org.sonar.batch.bootstrap.BatchModule.doStart(BatchModule.java:136)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.bootstrap.BootstrapModule.doStart(BootstrapModule.java:83)
at org.sonar.batch.bootstrap.Module.start(Module.java:68)
at org.sonar.batch.Batch.execute(Batch.java:106)
at org.sonar.runner.internal.batch.Launcher.executeBatch(Launcher.java:6
at org.sonar.runner.internal.batch.Launcher.execute(Launcher.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.sonar.runner.Runner.delegateExecution(Runner.java:285)
... 3 more
Caused by: org.sonar.api.utils.SonarException: Unknown metric: temp-method-lines
at org.sonar.batch.index.DefaultIndex.addMeasure(DefaultIndex.java:184)
at org.sonar.batch.DefaultDecoratorContext.saveMeasure(DefaultDecoratorContext.java:111)
at org.sonar.plugins.uselesscodetracker.decorator.TempMethodLinesDecorator.computeDistributionFromChildren(TempMethodLinesDecorator.java:58)
at org.sonar.plugins.uselesscodetracker.decorator.TempMethodLinesDecorator.decorate(TempMethodLinesDecorator.java:49)
at org.sonar.batch.phases.DecoratorsExecutor.executeDecorator(DecoratorsExecutor.java:79)
... 24 more

I don't know what this "temp-method-lines" metric can be, never heard of it...
Please install the latest version of the .NET & C# Plugins Ecosystem: version 2.0. Also, make sure you uninstall any other plugin that could have brought this unknown metric (maybe a custom plugin that you wrote??).
And please upgrade to Sonar 3.4.1 as version 3.4 suffers from a critical bug.

CUDAfy.NET giving Win32Exception: The system cannot find the file specified

I've added a reference to the CUDAfy.NET library via NuGet.
<package id="CUDAfy.NET" version="1.12.4695.21111" targetFramework="net45" />
When I run my program, I hit a Win32Exception:
The system cannot find the file specified
This happens on the first actual line of the program:
CudafyModule km = CudafyTranslator.Cudafy();
There's no indication from the exception object as to what file they're attempting to load.
How can I get past this problem?
EDIT
I see the same exception when running the bundled examples from the Codeplex download in VS2010 using .NET 4.0.
The strack trace is:
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at Cudafy.CudafyModule.Compile(eGPUCompiler mode, Boolean deleteGeneratedCode)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Version cudaVersion, Boolean compile, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy()

Setting VS to break on thrown exceptions shows the ProcessStartInfo object at the top of the stack in the locals pane of the debugger.
The relevant properties are:
FileName = nvcc
Arguments = -m64 -arch=sm_12 "c:\<path>\CUDAFYSOURCETEMP.cu" -o "c:\<path>\CUDAFYSOURCETEMP.ptx" --ptx
Some information from this article explains that the CUDA Toolkit must be installed. Fair enough.
Ensure that the C++ compiler (cl.exe) is on the search path. This set-up of NVCC is actually the toughest stage of the whole process, so please persevere. Read any errors you get carefully - most likely they are related to not finding cl.exe or not having either 32-bit or 64-bit CUDA Toolkit.
That article discusses version 4 of the toolkit, but version 5 is available now and supported since CUDAfy v1.1.
Download from https://developer.nvidia.com/cuda-downloads
Note that the 64-bit version of the CUDA Toolkit 5.0 is a 942 MB download. If you install everything you'll need an additional 2815 MB. The toolkit alone requires 928 MB.
EDIT After installing the CUDA Toolkit 5.0, the program failed with a CudafyCompileException at the same source line:
Compilation error: nvcc : fatal error : Cannot find compiler 'cl.exe' in PATH
Searching my system drive:
C:\>dir /s cl.exe
This shows many different versions of the compiler/linker, both from VS 10.0 and 11.0. Apparently only cl.exe versions 9 and 10 are supported, so I opted for the VS10.0 amd64 version, I included the following in my PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
Your path may be different, depending upon your CPU. I recommend running the search to see your options.
Note that you will have to restart VS after changing the PATH environment variable if you already have it open.
After taking these steps, my basic program ran successfully.

This may also happen if you had at some point installed CUDA Toolkit v7.5, but realized that the most recent version of CUDAfy supports CUDA 7.0.
On uninstalling CUDA 7.5 from the control panel, some files/folders may still remain. You should delete these manually. You may use CUDAfyViewer to see which version of CUDA Toolkit is being accessed.

Compiling mono-2.6 (or later) on Ubuntu?

I am having to building mono from sources, since the Ubuntu package from badgerports is outdated (does not support .Net 4.0)
This is what I have done so far (mostly following instructions here):
cloned mono git repository
switched to branch tagged 2.6 (git checkout mono-2-6)
installed minimal mono on my machine so mono and mcs are available on machine
run ./autogen.sh --prefix=/usr/local
run make
After a few modules compile correctly, I get this error:
make[4]: Entering directory `/home/oompah/work/dev/mono/mono/mini'
CC mini.lo
CC liveness.lo
liveness.c: In function ‘mono_liveness_handle_exception_clauses’:
liveness.c:137: error: ‘MonoCompile’ has no member named ‘header’
make[4]: *** [liveness.lo] Error 1
make[4]: Leaving directory `/home/oompah/work/dev/mono/mono/mini'
make[3]: *** [all] Error 2
I have looked at the offending code, and indeed a header member is being accessed ...
void
mono_liveness_handle_exception_clauses (MonoCompile *cfg)
{
MonoBasicBlock *bb;
GSList *visited = NULL;
MonoMethodHeader *header = cfg->header;
...
}
Has anyone managed to build mono-2.6 (or later) on Ubuntu?

I've used the scripts provided at integratedwebsystems successfully to compile a recent version of mono on my system and run .net 4.0 applications.
an improved version of the script can be found on firegrass' github account

Joe Shields is packaging Mono 2.10 and is patching everything to default to .NET 4.0 for Ubuntu, you might want to poke him on twitter #directhex.

C# Mono+Winforms MessageBox problem

I have a file called hellowf.cs
class MyFirstApp {
static void Main() {
System.Windows.Forms.MessageBox.Show("Hello, Mono+WinForms!");
}
}
On Ubuntu 8.10, I do the following
gmcs hellowf.cs -r:System.Drawing.dll -r:System.Windows.Forms.dll
mono hellowf.exe
... and it looks like this:
alt text http://img136.imageshack.us/img136/4674/helloproblemuk5.png
The second part of the message is missing. Why is this happening? The same binary - hellowf.exe - works fine on Windows.
Update:
This is really annoying. Here are the mono versions I have had and tried to make this work on so far:
1.9.1 (from official ubuntu repo)
2.0.1 (from some some 3rd party repo)
2.2 (wiped every mono pkg and compiled myself)
My Current mono version:
mono --version
Mono JIT compiler version 2.2 (tarball Wed Jan 14 22:58:21 CET 2009)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notifications: epoll
Architecture: x86
Disabled: none
gmcs --version
Mono C# compiler version 2.2.0.0
... any clues?

Finally I have found a workaround. This seems to be a bug in Mono related to font rendering. It happens when "Full" hinting is turned on. I usually have it that way. Changing it to "Slight" or "Medium" in System->Preferences->Appearance->Fonts->Details fixes the problem. Thanks for the help!

Works OK on opensuse 11.0, mono 2.0.1.
Please, edit your question and put the mono version you are using.

stick an # in front of the "Hello, Mono+WinForms!" and see if it still happens.

Standard debugging advice:
Start making small, controlled changes, and see what happens.
This will help narrow down what the problem is.
Try removing the symbols: , + !
Try removing the space.
Try a variety of shorter strings, and possibly some longer strings.
Once you have a better idea of what the MessageBox will and will not print, you can start to debug that specific problem, instead of trying to debug, "It doesn't work!"

When you updated your packages and source code, did you update/compile libgdiplus? We have seen some funky graphical problems if the System.Drawing and libgdiplus versions get out of sync.