Can you show exactly what CSArray is and how you create it? If I initialise CSArray = System.Array.CreateInstance(System.Byte, 1000) this works fine for me.
@aPere3 this used to work before, because overloading did not really check for types, which was giving wrong results like Math.Abs(5.3)=5 due to wrong selection of overloaded method.
In your case what happens is that .NET enum GCHandleType.Pinned is converted to Python int before it is passed to GCHandle.Alloc() method, which is not what C# and IronPython do.
So the temporary fix would be one of the following:
special case enums in overloading method selection to allow inter-operability with integer types.
implement context manager with clr.ignore_overloading_types, where method overloading logic is ignored only within this context
special case conversion logic to prevent conversion of c# enums to python integers in .ToPython() method
if only one overloaded signature matches by number of arguments, then ignore types and try to return results with warning
But the bigger problem is that why .ToPython() has to be called on .NET types and deviate from IronPython?!
@denfromufa was your last post dedicated to me or developers of pythonNet? Because I'm quite new to python and I didn't get the details of your temporary fix recipe.
Anyway, is a downgrading to another version of python likely to help me with this bug ?
@denfromufa Sorry for the late reply...
I cloned the last develop branch and still no changes, I have the same error...
But I found that when I compile your code with:
$ python setup.py bdist_wheel
an error occurs. I didn't notice it because the files are built anyway but I have:
C:\Users\alex\Downloads\pythonnet\packages\UnmanagedExports.1.2.6\tools\RGiesecke.DllExport.targets(42,5): err
or : Microsoft.Build.Utilities.ToolLocationHelper could not find ildasm.exe.
Is it important? Why are the files built anyway?
Still the import of clr and my first import work without particular issues...
Not sure about ildasm.exe, which .net versions do you have installed?
Anyway you can also try to build from visual studio, just select proper
configuration and set python version symbol in Python.Runtime and clrmodule
projects.
On Friday, March 11, 2016, Alex, Péré <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
@denfromufa https://github.com/denfromufa Sorry for the late reply...
I cloned the last develop branch and still no changes, I have the same
error...
But I found that when I compile your code with:
$ python setup.py bdist_wheel
an error occurs. I didn't notice it because the files are built anyway but
I have:
C:\Users\alex\Downloads\pythonnet\packages\UnmanagedExports.1.2.6\tools\RGiesecke.DllExport.targets(42,5): err
or : Microsoft.Build.Utilities.ToolLocationHelper could not find ildasm.exe.
Is it important? Why are the files built anyway?
Still the import of clr and my first import work without particular
issues...
—
Reply to this email directly or view it on GitHub #174 (comment)
.
@denfromufa re your question about IronPython, PythonNet has nothing to do with IronPython - they are no way related. Any similarity is purely because they are both related to Python, not with each other. IronPython is a Python language implementation for the CLR, whereas PythonNet is a set of libraries built using the CPython API. Questions about why one has diverged from the other are irrelevant as neither is derived from the other.
@denfromufa Sorry for (very) late reply. I tried with your patch branch, and no error occurred on the line. This seems to have worked! Thank you very much!
Anyway my code still do not work, but it is not related to this bug anymore, haha!
@tonyroberts I thought ironpython compatibility is one of goals in pythonnet, because some people switch from ironpython due to obvious reasons, unless pythonnet breaks their existing ironpython code without migration path.
@aPere3 glad to know that this works, open another issue if your new issue is related to pythonnet.
Activity
filmor commented on Mar 3, 2016
Can you show exactly what CSArray is and how you create it? If I initialise CSArray = System.Array.CreateInstance(System.Byte, 1000) this works fine for me.
And yes, C# enums are integers.
aPere3 commented on Mar 3, 2016
I have the following:
Using your definition gives the same error on my computer.
On my side, for test purpose, I create CSArray using a static C# method:
filmor commented on Mar 3, 2016
What versions of Python, Python.NET and .NET are you using?
aPere3 commented on Mar 3, 2016
Sorry I forgot:
Python 3.5
Python.Net 2.1 cloned yesterday from here
Windows 8.1 .NET4.5
den-run-ai commented on Mar 3, 2016
@aPere3 @filmor this problem is exactly the same as described here by @mahibra:
#170
the type int reported for GCHandleType.Pinned is 32-bit in c# because it is enum, but int in python 3 is pointing to int64.
so try explicitly passing GCHandleType(GCHandleType.Pinned) - not sure if it works though.
aPere3 commented on Mar 3, 2016
Gives me the same error as before.... What a pity!
den-run-ai commented on Mar 3, 2016
@aPere3 try this branch, although Travis CI and appveyor tests not done yet: #175
den-run-ai commented on Mar 3, 2016
@aPere3 all tests have been passed, so please try this updated version!
aPere3 commented on Mar 3, 2016
@denfromufa , I cloned an build from the master branch since you merged it a few hours ago...
Anyway, no changes, still that same error....
den-run-ai commented on Mar 6, 2016
@aPere3 this used to work before, because overloading did not really check for types, which was giving wrong results like Math.Abs(5.3)=5 due to wrong selection of overloaded method.
In your case what happens is that .NET enum GCHandleType.Pinned is converted to Python int before it is passed to GCHandle.Alloc() method, which is not what C# and IronPython do.
So the temporary fix would be one of the following:
But the bigger problem is that why .ToPython() has to be called on .NET types and deviate from IronPython?!
Let me know what you think @tonyroberts @filmor ?
aPere3 commented on Mar 7, 2016
@denfromufa was your last post dedicated to me or developers of pythonNet? Because I'm quite new to python and I didn't get the details of your temporary fix recipe.
Anyway, is a downgrading to another version of python likely to help me with this bug ?
den-run-ai commented on Mar 7, 2016
@aPere3 I fixed in this branch and tested it on my machine:
#176
den-run-ai commented on Mar 11, 2016
@aPere3 did my patch work for you? if yes, then can you close this issue?
aPere3 commented on Mar 11, 2016
@denfromufa Sorry for the late reply...
I cloned the last develop branch and still no changes, I have the same error...
But I found that when I compile your code with:
an error occurs. I didn't notice it because the files are built anyway but I have:
Is it important? Why are the files built anyway?
Still the import of clr and my first import work without particular issues...
den-run-ai commented on Mar 12, 2016
@aPere3
As you can see from pull request #176 it has not been merged yet, so you need to
try my branch pointing at this pull request:
https://github.com/denfromufa/pythonnet/tree/patch-8
Not sure about ildasm.exe, which .net versions do you have installed?
Anyway you can also try to build from visual studio, just select proper
configuration and set python version symbol in Python.Runtime and clrmodule
projects.
On Friday, March 11, 2016, Alex, Péré <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
tonyroberts commented on Mar 15, 2016
@denfromufa re your question about IronPython, PythonNet has nothing to do with IronPython - they are no way related. Any similarity is purely because they are both related to Python, not with each other. IronPython is a Python language implementation for the CLR, whereas PythonNet is a set of libraries built using the CPython API. Questions about why one has diverged from the other are irrelevant as neither is derived from the other.
aPere3 commented on Mar 16, 2016
@denfromufa Sorry for (very) late reply. I tried with your patch branch, and no error occurred on the line. This seems to have worked! Thank you very much!
Anyway my code still do not work, but it is not related to this bug anymore, haha!
den-run-ai commented on Mar 16, 2016
@tonyroberts I thought ironpython compatibility is one of goals in pythonnet, because some people switch from ironpython due to obvious reasons, unless pythonnet breaks their existing ironpython code without migration path.
@aPere3 glad to know that this works, open another issue if your new issue is related to pythonnet.
aPere3 commented on Mar 17, 2016
Thank you I close!