On Wed, Mar 19, 2014 at 7:43 PM, MinRK benjami...@gmail.com wrote:
Amending the rules is fine, I just wanted to point out that you can't
backport new features without updating the minor version number within the
current definitions of libzmq minor and patch versions.
As an author and user of
If this fix is backported without incrementing the minor version number,
then it presents the challenge of how to identify whether the functionality
is present on a particular system when wrapping it in a language binding,
because version 4.0.4 could refer both to the prior version without the
This patch would go into the next stable, which is 4.0.5.
On Mar 21, 2014 3:06 AM, Cosmo Harrigan cosmo.harri...@singularityu.org
wrote:
If this fix is backported without incrementing the minor version number,
then it presents the challenge of how to identify whether the functionality
is
Ah, that makes sense. There will be no issue then.
Thanks,
Cosmo
On Thu, Mar 20, 2014 at 9:02 PM, Pieter Hintjens piet...@gmail.com wrote:
This patch would go into the next stable, which is 4.0.5.
On Mar 21, 2014 3:06 AM, Cosmo Harrigan cosmo.harri...@singularityu.org
wrote:
If this fix
Hmm... this would be more confusing than helpful IMO. 4.1.x should
normally go through the usual 'release candidate' - 'stable' process.
This would suggest we can randomly backport new functionality so long
as we update the version number. That isn't our process at all...
If adding
On Wed, Mar 19, 2014 at 12:56 AM, Pieter Hintjens p...@imatix.com wrote:
Hmm... this would be more confusing than helpful IMO. 4.1.x should
normally go through the usual 'release candidate' - 'stable' process.
This would suggest we can randomly backport new functionality so long
as we update
I think backporting the function is okay, but that would mean that
zeromq4-x should become 4.1.x, and libzmq should be bumped to 4.2.
On Mon, Mar 17, 2014 at 1:04 AM, Pieter Hintjens p...@imatix.com wrote:
We don't usually backport new functionality to existing stable
releases, because it's
We don't usually backport new functionality to existing stable
releases, because it's been troublesome in the past (i.e. breaking
things in bad ways).
However, this is fairly safe and if you want to make a pull request to
zeromq4-x with the new zmq_proxy code, I'll merge it.
I've made an issue
Thanks. Is it acceptable to backport zmq_proxy_steerable to libzmq 4.0.4?
Or if not, when do you estimate the next stable release that would contain
it?
Best,
Cosmo
On Tue, Mar 11, 2014 at 11:18 PM, Pieter Hintjens p...@imatix.com wrote:
CZMQ has its own steerable proxy so that it can run on
CZMQ has its own steerable proxy so that it can run on older versions
of libzmq. Also, some optimizations, but that's secondary. Also,
wrapping libzmq's method is extra work, it turns out.
The zmq_steerable_proxy method is quite recent so hasn't been wrapped
by other bindings yet.
On Tue, Mar
Hi,
What is the best practice when you are creating a loop that functions like
the zmq_proxy device, to bind a PULL socket that is fed by a backend
ventilator with a frontend PUB socket, in order to properly handle a clean
shutdown?
Most of the examples on the zguide just show while (1) with a
You can look at the CZMQ zproxy class to see one way to do this.
On Tue, Mar 11, 2014 at 9:35 PM, Cosmo Harrigan
cosmo.harri...@singularityu.org wrote:
Hi,
What is the best practice when you are creating a loop that functions like
the zmq_proxy device, to bind a PULL socket that is fed by a
Thanks for the reply. I took a look, and my understanding is that the CZMQ
zproxy class waits for messages from both a backend and a pipe (which is a
PAIR socket to expose the API) and updates a local variable 'stopped' which
ends the loop when the pipe receives the 'STOP' command.
And it refers
Long term, I would think it best to extend one of the C++ wrappers,
probably zmqpp, with czmq functionality. (This could even be a wrapper to
the wrapper.)
Short term, it isn't that hard to replicate the design by creating your own
inproc socket in zmqpp or whatever that is used together with a
14 matches
Mail list logo
