I noticed the duality of the __overloads__ and Overloads. But I decided to
follow the readme (http://pythonnet.sourceforge.net/readme.html). It is
possible it should be updated. Also the array example is not so good... it
led me done the right road for Array[Byte](...).
Jeff
On Thu, Jan 17, 2013 at 10:15 PM, Barton <bar...@bcdesignswell.com> wrote:
> __overloads__ has been deprecated for some time now.
> I prefer the IP compatible Overloads.
>
> >>> import clr
> >>> from System import Int32
> >>> help(Int32)
>
> | ----------------------------------------------------------------------
> | Data and other attributes defined here:
> |
> | __new__ = <built-in method __new__ of CLR Metatype object>
> | T.__new__(S, ...) -> a new object with type S, a subtype of T
> |
> | ----------------------------------------------------------------------
> | Data descriptors inherited from Object:
> |
> | Finalize
> | Void Finalize()
> |
> | GetType
> | System.Type GetType()
> |
> | MemberwiseClone
> | System.Object MemberwiseClone()
> |
> | Overloads
> |
> | ReferenceEquals
> | Boolean ReferenceEquals(System.Object, System.Object)
> |
> | __overloads__
>
> As for the smarts behind it, it'll be fun to get back into the guts and
> see if some improvements can be made.
>
> Oh boy; I just love those System.NotSupportedException(s)!
> Thanks for the feedback.
>
> On 01/15/2013 12:38 AM, Jeffrey Bush wrote:
>
> Thanks for all your input! With your help I have been able to get
> everything working as expected. Getting the address of a string
> with ctypes was a bit trickier than I expected, but I the end the following
> works (if anyone would like to know):
>
> import ctypes
> from System import IntPtr
> addr = ctypes.cast(ctypes.c_char_p(s), ctypes.c_void_p).value
> ptr = IntPtr.[long](addr)
>
> That is for "str" objects. As a side note these should be treated as
> read-only due to Python optimizations with strings. For things that come
> from ctypes.create_string_bufffer() the ctypes.c_char_p(s) should be just
> s. These are not read-only.
>
> The last thing I would like to suggest to make things more "wrist
> friendly" as you put it is to make the need for __overloads__ less by
> making it smarter. Two examples come to mind. First is the example above.
> If I try IntPtr(5) or IntPtr(5L) it complains that "'int/long' value
> cannot be converted to System.IntPtr". It seems like it is trying to cast
> or something instead of call the constructor. Or maybe since ints and longs
> are both ValueTypes it can't choose which to use. Or maybe even just the
> fact they use the same number of arguments.
>
> Another example is later on when I am using Memory objects from my code.
> The Memory class is abstract and has two concrete implementations:
> ManagedMemory and UnmanagedMemory. I was trying to call a method that takes
> either one of these three along with any type of array of value-types. In
> this case all of Python crashes when it tries to convert the
> UnmanagedMemory object to an array (exception text is at the end of this
> message). This is something that should be determinable by the .NET bridge.
>
> For now I won't be needing to write much more than I have using Python
> for .NET, however it would be nice to make the system a little smarter with
> overloads.
>
> Thanks for the great work so far!
> Jeff
>
>
>
> Exception that crashes Python:
>
> Unhandled Exception: System.NotSupportedException: Cannot create arrays
> of TypedReference, ArgIterator, ByRef, or RuntimeArgumentHandle Objects.
> at System.Array.InternalCreate(Void* elementType, Int32 rank, Int32*
> pLengths, Int32* pLowerBounds)
> at System.Array.CreateInstance(Type elementType, Int32 length)
> at Python.Runtime.Converter.ToArray(IntPtr value, Type obType, Object&
> result, Boolean setError) in D:\Users\Barton\Documents\Visual Studio
> 2010\Projects\PySharp\trunk\pythonnet\src\runtime\converter.cs:line 648
> at Python.Runtime.Converter.ToManagedValue(IntPtr value, Type obType,
> Object& result, Boolean set Error) in D:\Users\Barton\Documents\Visual
> Studio 2010\Projects\PySharp\trunk\pythonnet\src\runtime\converter.cs:line
> 263
> at Python.Runtime.Converter.ToManaged(IntPtr value, Type type, Object&
> result, Boolean setError) in D:\Users\Barton\Documents\Visual Studio
> 2010\Projects\PySharp\trunk\pythonnet\src\runtime\converter.cs:line 201
> at Python.Runtime.MethodBinder.Bind(IntPtr inst, IntPtr args, IntPtr
> kw, MethodBase info, MethodInfo[] methodinfo) in
> D:\Users\Barton\Documents\Visual Studio
> 2010\Projects\PySharp\trunk\pythonnet\src\runtime\methodbinder.cs:line 278
> at Python.Runtime.MethodBinder.Invoke(IntPtr inst, IntPtr args, IntPtr
> kw, MethodBase info, MethodInfo[] methodinfo) in
> D:\Users\Barton\Documents\Visual Studio
> 2010\Projects\PySharp\trunk\pythonnet\src\runtime\methodbinder.cs:line 340
> at Python.Runtime.MethodObject.Invoke(IntPtr target, IntPtr args,
> IntPtr kw, MethodBase info) in D:\Users\Barton\Documents\Visual Studio
> 2010\Projects\PySharp\trunk\pythonnet\src\runtime\methodobject.cs:line 63
> at Python.Runtime.MethodBinding.tp_call(IntPtr ob, IntPtr args, IntPtr
> kw) in D:\Users\Barton\Documents\Visual Studio
> 2010\Projects\PySharp\trunk\pythonnet\src\runtime\methodbinding.cs:line 135
>
>
>
> On Tue, Jan 8, 2013 at 7:19 AM, Bradley Friedman <b...@fie.us> wrote:
>
>> You can construct .net intptr objects from ints. So you need the
>> address. You already provided the solution to that. In python, you get
>> memory addresses by using ctypes. Be careful to handle it in a way that
>> will support both 32 and 64 bit binaries.
>>
>> Sent from my iPad
>>
>> On Jan 8, 2013, at 4:51 AM, Barton <bar...@bcdesignswell.com> wrote:
>>
>> 1) Not being much of a C guy myself, I'm not sure what to make of all
>> this pointer business.
>> Especially since the object reference is capable of being indexed
>> (and SO much more [>>> help(a)])
>> - Just don't try a.Address(0) like I just did - got a core dump
>> on Mono -
>>
>> 2) C# type rules apply (except that python lets you try things like "a ==
>> input"); underneath Array.Equals(System.Array) is called.
>> hence Int32(7) == 7 is false.
>> - I tend to think of this package as a "wrist-friendly" (see
>> Boo) wrapper over the Mono/.NET components more than a trying to be a type
>> compatibility layer.
>>
>> 3) Slicing seems like something that is worth implementing. That would
>> take a lot of typing out of
>> Array.Copy(a1, srcIndx, a2, dstIndx, len)
>>
>> Great fun,
>> Barton
>>
>> On 01/08/2013 12:31 AM, Jeffrey Bush wrote:
>>
>> How about my other questions? Pass as a pointer (like ctypes would do)?
>> Convert that pointer back? And I don't seem to be able to get the slices
>> (":") to work with byte arrays.
>>
>> Thanks for the help getting the byte arrays started though. I am able
>> to take the output from reading a file and send it right to the array
>> constructor:
>>
>> import clr
>> from System import Array, Byte
>> with open("file.txt", 'rb') as f: input = f.read()
>> a = Array[Byte](input)
>>
>> One problem though is that equality doesn't work (a==input is False).
>> But maybe this is because one is a list of (unsigned) bytes and one is a
>> list of (signed) characters. a[0] and input[0] display differently.
>>
>> Jeff
>>
>>
>> On Sat, Jan 5, 2013 at 2:07 PM, Barton <bar...@bcdesignswell.com> wrote:
>>
>>> Definitely more useful:
>>> >>> import clr
>>> >>> from System import Array, Byte
>>> >>> g = (0 for i in range(10))
>>> >>> a = Array[Byte](list(i for i in g))
>>>
>>> >>> a[5]
>>> 0
>>>
>>> On 01/04/2013 06:33 PM, Jeffrey Bush wrote:
>>>
>>> Hi,
>>>
>>> I have a library in C for compression. I made Python script for
>>> testing it, called using ctypes.
>>>
>>> Now, I am working on a .NET library for something very similar and
>>> would like to test it in the same way. However, I am getting lost in how to
>>> do some of the things with your library.
>>>
>>> The function I need to call looks like:
>>>
>>> public static long Compress(Memory input, Memory output)
>>>
>>> The Memory class is a wrapper around either managed byte arrays, void*
>>> (for efficiency), or memory mapped files. This allows a unified system for
>>> accessing general chunks of memory regardless if they are managed, native,
>>> or on the filesystem. They are created through static functions:
>>>
>>> public static Memory From(MemoryStream s, bool all = true)public static
>>> Memory From(byte[] b, bool readOnly = false)public static Memory
>>> From(byte[] b, long offset, long size, bool readOnly = false)public unsafe
>>> static Memory From(UnmanagedMemoryStream s, bool all = true)public unsafe
>>> static Memory From(void* b, long size, bool readOnly = false)public unsafe
>>> static Memory From(IntPtr b, long size, bool readOnly = false)public static
>>> Memory FromFile(string file, bool readOnly = false)public static Memory
>>> OfSize(long size)
>>>
>>> The only ones I can easily use are the last two (OfSize and FromFile).
>>> I have not yet figured out how to call the other ones properly. I don't
>>> seem to be able to allocate byte arrays with Array[Byte](10), it complains
>>> that 10 cannot be converted to System.Byte[] so it seems that it believes I
>>> am casting instead of creating a new array. No overloads seem to exist.
>>>
>>> So now here are my questions and the ctypes answer:
>>>
>>> - How do I construct a byte array? (ctypes.create_string_buffer)
>>> - How do I take a Python list/array and pass it as a pointer?
>>> (ctypes has this conversion happen automatically)
>>> - How do I turn a byte array into a useful Python list/array? As-is
>>> I can't use the Python-style indexers (except negative numbers). (The
>>> ctypes buffer works directly as a list, but also supports ".raw" and
>>> ".value")
>>> - How do I convert a pointer into a useful Python list/array?
>>> (ctypes casting allows this to work)
>>>
>>> Last point, although this is probably a limitation of .NET, but just
>>> to make sure. The default argument values can't be used, but it is possible
>>> that this isn't even in the assembly information and only works for source
>>> in the same module.
>>>
>>> Thanks,
>>> Jeff
>>>
>>>
>>> _________________________________________________Python.NET mailing list
>>> -
>>> PythonDotNet@python.orghttp://mail.python.org/mailman/listinfo/pythondotnet
>>>
>>>
>>>
>>
>> _________________________________________________
>> Python.NET mailing list - PythonDotNet@python.org
>> http://mail.python.org/mailman/listinfo/pythondotnet
>>
>>
>
>
> _________________________________________________
> Python.NET mailing list -
> PythonDotNet@python.orghttp://mail.python.org/mailman/listinfo/pythondotnet
>
>
>
_________________________________________________
Python.NET mailing list - PythonDotNet@python.org
http://mail.python.org/mailman/listinfo/pythondotnet
