[Ironpython-users] Fwd: pyzmq can be used with ironpython

[Pawel Jasinski]

On Fri, Dec 20, 2013 at 7:12 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> On Wed, Dec 18, 2013 at 4:49 AM, Pawel Jasinski
> <pawel.jasinski at gmail.com> wrote:
>> hi,
>>
>> I have managed to get pyzmq to work under Ironpython.
>> Anybody interested can take it from:
>> https://github.com/paweljasinski/pyzmq/tree/iron
>> https://github.com/paweljasinski/clrzmq/tree/iron
>
> That's fantastic. I'm assuming this is for IPython Notebook?

actually I have tested it with ptvs and ipython. I was able to enable
"ipython w/o pylab" and get a session going.
It is not a touch-down. The guilty is ip unicode/byte/char system.
The ipython types are python 3 compatible, but entire standard lib is
typed in 2.x terms. This is a strong argument to move to 3.
For the ipython itself, modifications are ugly (I will push it to my
github repo today).
Not all usage scenarios of ipython/zmq work. There are unittest in
ipython/zmq which I simply gave up.

>
>> It is usable, but not in the "push request" quality.
>>
>> I would appreciate feedback about a way clrzmq is integrated with ironpython.
>> In order to keep structure of the pyzmq, native C# modules must
>> reference things from python.
>
> I doubt adding IP-specific stuff to clrzmq will be acceptable
> upstream, so they'll have to be broken apart.
Yes, particularly dependency on ironpython assembly is a no-go.
I am using only very bottom of clrzmq (P/Invoke), so it will be
trivial to separate it.

zmq devels adviced me to check out pure .net zmq provided (NetMQ). I
have to find out how it fits with pyzmq.

> Why can't ZeroMQ.Iron be a separate assembly?
it can be a separate assembly referencing platform/architecture specific libzmq

> In particular, it would be nice if that assembly
> was not platform specific and could reference the various
> platform-specific clrzmq DLLs. It appears that clrzmq uses different
> DLLs for .NET and Mono, so choosing the right DLL to load
> automatically could be interesting. It may make sense to maintain a
> fork of pyzmq, but that depends on what upstream would be interested
> in supporting.

I am in touch with zmq folks.

>
> This is a common problem (I would love to do the same for SQLite and
> expat) so it would be nice to have an idea of what works and what
> doesn't.
>
> - Jeff

--pawel