Awesome work, everyone!
On Wed, May 18, 2016 at 9:52 AM, Yurii Rashkovskii wrote:
> Pieter,
>
> That was a great PR! The site is available at
> https://zeromq.gitbooks.io/rfc/content/ — I can see we're still missing a
> few things, but they are fairly cosmetic and will be easy to fix, like RFCs
Greg Young,
As a shameless, somewhat off-topic plug, I've been working to write a
ZeroMQ implementation in Pony, which happens to be an actor language where
each actor is not a system thread, but a more "green" representation as you
describe.
I've found that the CZMQ actor paradigm have been very
Congratulations on the stable release, Patrik!
I know you've put in a lot of diligent work into this effort, and I'll be
recommending it to others as the "go-to" library to use for any
ZeroMQ-related Ruby projects.
On Mon, Jan 18, 2016 at 12:49 PM, Pieter Hintjens wrote:
> Heh, neat... I think
What Utsav says sounds right, but from what little I remember, it was
called `dlopen`. You need to separately `dlopen` each library yourself
(libsodium, libzmq, czmq, zyre). I remember having to coax Qt into doing
this correctly.
On Wed, Jan 6, 2016 at 7:07 AM, Utsav Drolia wrote:
> I think yo
This is one example that I think demonstrates that we actually do encode
more information in the zproject API models than is found in the C
headers. This extra information is necessary for the API to understood to
generate well-behaved bindings, but is, as you've found, merely an
understood conven
The "polymorphic" attribute was added recently. There was some debate
about it, and I'm still not convinced that it's useful. Basically,
polymorphic implies "singleton" with a first argument of type "anything"
(which translates to a void pointer).
I'd be in favor of removing the concept of "poly
As you say, providing a fully idiomatic user experience is not always
possible in generated bindings - this was also the case with Ruby when I
was writing those bindings.
In cases where there is a conflict between idiomatic user experience and
predictability, I would argue that we *must* make the
The reason that method is static/singleton (which in this case, we use
interchangably) is because the "self" argument does not have to be an
instance of `zsock_t` (it could also be a libzmq socket pointer already).
Essentially, the "self" argument can be any arbitrary object as far as the
bindings
Solution: Add new libzmq API for sending and receiving multi-part messages
atomically/statelessly.
---
With this commit, the REQ, REP, DEALER, and ROUTER types are marked as
soon-to-be deprecated in favor of the CLIENT and SERVER types on libzmq
master:
https://github.com/hintjens/libzmq/commit/f
ke recv() work.
> >
> >
> >
> > Best regards
> >
> > Adam Wynne
> > CR/RTC3.1-NA
> >
> > Tel. +1(412)390-3211
> >
> > From: zeromq-dev-boun...@lists.zeromq.org
> > [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behal
Pieter,
When you say you're stuck on the internal model, do you mean on the
zproject representation of the API model, or on JNI-specific internals (in
need of a Java/JNI guru)?
On Wed, Sep 9, 2015 at 2:11 PM, Pieter Hintjens wrote:
> Hi guys,
>
> We've started a small effort to make a JNI bind
Could be that Travis updated its software packages so that a different set
of warning/error settings are active for the compiler.
On Sun, Aug 16, 2015 at 5:02 AM, Brian Knox wrote:
> CZMQ is currently failing to build on travis-ci for GoCZMQ, just wanted to
> see if anyone else has run into this
Michael,
I just responded to another user about this - I'm copying my response here
in case it is useful to you
I did much of the work on the qt-android build system. I apologize that
there is little guiding documentation on this point, but I did it mainly to
allow using the zeromq family of li
Arthur,
I did much of the work on the qt-android build system. I apologize that
there is little guiding documentation on this point, but I did it mainly to
allow using the zeromq family of libraries on android in Qt/QML
applications. In order to use the `dlopen` style import Qt uses, there are
c
Lucas,
It may well be that code generation is a good choice for solving your
problem but zproto (one specific set of code generators) is not. You can
always use GSL to write your own code generator scripts that are verbose
and descriptive. Codecs generated by zproto are not all verbose or
descri
Michel,
Much of the work for what you're talking about is already done by others in
zproject (see
https://github.com/zeromq/zproject/blob/master/zproject_bindings_python.gsl).
The zproject code generators do two major things:
1) generate the build systems and project skeleton for a C library.
2)
Utsav,
Try running the builds/qt-android/build.sh script in the repository.
On Wed, Mar 25, 2015 at 2:00 PM, Utsav Drolia wrote:
> Is compiling zyre for Android documented anywhere?
> Also are the python bindings for zyre stable now? I was thinking of using
> python on Android (e.g. SL4A) and a
Kenneth,
I've spent quite a bit of time working on the android cross-compile process
(see the builds/qt-android subdir in libzmq, czmq, zyre, etc..) and QML
bindings for writing cross-platform Qt applications that use these
libraries on platforms including android (see the bindings/qml subdir).
Bo
nd it helped me verifying that I did not
> miss a flag, a step or something i was not considering yet.
> Generally it doesn't matter if I compile a static or a shared library -
> The NDK uses its own linker to link the prebuilt libraries.
>
> Am 06.03.2015 um 18:17 schrieb Joe McIlvai
to link the prebuilt libraries.
>
> Am 06.03.2015 um 18:17 schrieb Joe McIlvain:
>
> Matthias,
>
> I don't usually compile them as static, but you may be able to get some
> ideas/help from using or looking at the scripts I added under
> `builds/qt-android`of the zeromq
Matthias,
I don't usually compile them as static, but you may be able to get some
ideas/help from using or looking at the scripts I added under
`builds/qt-android`of the zeromq repository. I use these to compile for
use with Qt on android, but there's nothing really Qt-specific about them.
I only
I thought one of the major motivations for sharing a socket among threads
was to avoid the (anti-)pattern of creating a socket for each request in a
multithreaded environment and worrying about running out of file
descriptors. It sounds like this new strategy would avoid allocations of
more zmq so
> Thanks,
>
> Santosh
>
>
>
> *From:* zeromq-dev-boun...@lists.zeromq.org [mailto:
> zeromq-dev-boun...@lists.zeromq.org] *On Behalf Of *Joe McIlvain
> *Sent:* Wednesday, February 11, 2015 3:37 PM
>
> *To:* ZeroMQ development list
> *Subject:* Re: [zeromq-dev]
Santosh,
Sounds like a good change to me. I can't imagine anyone relying on the
current behavior, because they wouldn't be able to communicate over that
socket anyway.
Care to submit a patch on Github?
On Wed, Feb 11, 2015 at 1:19 PM, wrote:
> Hi Pieter and Jim,
>
> I got the trace of the cl
Pieter,
Integer routing ids sounds nice to me, quite honestly.
I wouldn't mind having the routing ids being semantically separated
from the content frames by more than just the empty "delimiter", so
representing them with separate accessors as integers is a possibly
appealing id. Arguably, it add
FWIW, we are currently using a patched version of zproto message codec
to support multi-hop messages by tracking routing info as an envelope
of zero or more frames instead of as zero or one frames. I'm not
afraid of change, but I'm still trying to work out how we are going to
change our architectu
b 2, 2015 at 8:55 AM, Doron Somech wrote:
> Joe the problem with the api of zmsg for single frame is that you cannot
> calculate the frame size in advance causing a lot of re allocation and
> copying data around (it's ok for receiving, the problem is sending).
>
>
>
> On Mon,
In my opinion, maintaining some kind of multi-frame abstraction at the API
level is in fact very useful to applications, even if they are sent
atomically on the implementation level as you describe.
For example, in CZMQ It's quite useful in program flow to be able to push
or pop a single zframe on
28 matches
Mail list logo
