[zeromq-dev] CZMQ now available in Debian

2015-08-16 Thread Luca Boccassi
Dear maintainers and users,

FYI, CZMQ packages are now available in Debian unstable (Sid) [1].

To install, simply run:

sudo apt-get install libczmq3 libczmq-dev

In a few days they should be automatically migrated to Debian testing
(Stretch) and to Ubuntu 15.10 (Wily), just in time for the import
freeze, scheduled for the 20th of August [2].

Many thanks to Alessandro Ghedini for agreeing to sponsor the upload,
and to László Böszörményi who is currently maintaining libzmq packages!

Kind regards,
Luca Boccassi
Brocade Communications Systems

[1] https://packages.debian.org/source/sid/czmq
[2] https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Setting privileges on a UNIX socket

2016-05-25 Thread Luca Boccassi
Hi Ale,

If you have systemd managing your socket with a socket unit, it will
create and bind it for you, so that's why it's saying it's already in
use.

Are you using the ZMQ_USE_FD API? I added that exactly for
systemd-managed sockets.

If you use CZMQ, you just have to set either the env var
ZSYS_AUTO_USE_FD=1 or the runtime var via the zsys_set_auto_use_fd(1)
function call, and then if the ZMQ endpoint matches a socket managed by
systemd, it will all work out automagically and ZMQ will use the file
descriptor passed by systemd.

If you are using just libzmq, you'll have to get the file descriptor
yourself from the systemd APIs, and then use the ZMQ_USE_FD
zmq_setsockopt call to pass it down after creating a socket and before
binding it.

Note that this is available only on the master branches of libzmq and
czmq, not in any released version yet.

Kind regards,
Luca Boccassi

On Wed, 2016-05-25 at 17:30 +0200, Ale Strooisma wrote:
> the previous update might be incorrect. Now it seems that I can't bind to a
> socket created by systemd (I got something like "address already in use").
> If I connect to it instead with my 'server' program, which uses a REP
> socket, it does receive messages, but can't seem to reply...
> 
> Anyway, all in all it would be highly preferable to be able to set with
> which permissions the socket is created. Currently I am working around this
> issue by calling chmod after binding to the socket.
> 
> On 25 May 2016 at 14:50, Ale Strooisma <a.strooi...@student.utwente.nl>
> wrote:
> 
> > Okay, a bit of an update: I tried ensuring the socket was available using
> > systemd, but when the program that binds to the port runs, it resets the
> > privileges.
> >
> > On 25 May 2016 at 12:32, Ale Strooisma <a.strooi...@student.utwente.nl>
> > wrote:
> >
> >> Hi all,
> >>
> >> For my program, I am using the ipc protocol. The unix socket used needs
> >> to be accessible to various programs run by different users, so I want to
> >> set group write privileges. How can I do this? Can I set this using ZeroMQ
> >> from within the program that binds the socket, or do I need to make sure
> >> the socket is in place with the right privileges before running any of my
> >> programs? The latter option would be rather unpractical of course.
> >>
> >> Kind regards,
> >> Ale Strooisma
> >>
> >
> >
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Sporadic failures in unit tests

2016-05-30 Thread Luca Boccassi
On Mon, 2016-05-30 at 13:00 +0200, Adam Majer wrote:
> Hello,
> 
> There appears to be a sporadic but consistent failure in unit tests
> with ZeroMQ 4.1.4 on SUSE's Open Build Service [1]
> 
> [   98s] FAIL: test_monitor
> [   98s] ==
> [   98s] 
> [   98s] test_monitor: tests/test_monitor.cpp:130: int main():
> Assertion `event == ZMQ_EVENT_MONITOR_STOPPED' failed.
> 
> This appears to be a sporadic failure.
> 
> 
> I'm also assuming that these tests are not to be run concurrently? That
> is, with `make check -j`?
> 
> - Adam
> 
> 
> [1] -
> https://build.opensuse.org/package/live_build_log/home:adamm:branches:devel:libraries:c_c++/zeromq/openSUSE_Factory/x86_64

Hi,

Yes the tests should not be ran concurrently as they might try to bind
to the same port. We should really try to fix that :-)

Also a couple of tests are known to be a bit flacky on slower
machines/environments unfortunately.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] [RFC] systemd socket activation for libzmq

2016-05-31 Thread Luca Boccassi
On Tue, 2016-05-31 at 08:52 -0700, Jim Garlick wrote:
> On Mon, May 30, 2016 at 09:57:00PM +0200, Michal Vyskocil wrote:
> > Hi,
> > 
> > Awesome, the fact czmq handles that is good enough for me. Closed the
> > request.
> > On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote:
> > > Hi,
> > >
> > > Ale's thread about Setting privileges on a UNIX socket inspired me to
> > > create small patch to libzmq adding automatic systemd socket
> > > activation support.
> > > https://github.com/zeromq/libzmq/pull/2015
> > >
> > > Right now the feature is fairly minimal - limited to ipc transport -
> > > and tested manually using malamute broker. I would like to hear any
> > > feedback. If you consider it as useful (or want to avoid dependency on
> > > the most hated OSS software on the planet ;-)), please say so.
> > 
> > Hi,
> > 
> > That functionality is already implemented for both IPC and TCP sockets.
> > 
> > The low level library has the ZMQ_USE_FD socket option to pass a file
> > descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or
> > zsys_set_auto_use_fd(1) function to let zmq automatically match
> > endpoints to the corresponding sockets managed by systemd. As long as
> > the metadata matches (eg: file path for IPC, address + port for TCP), it
> > will just work out of the box.
> > 
> > Kind regards,
> > Luca Boccassi
> 
> Somehow I missed that - sounds useful!
> 
> Is the usual reconnect behavior disabled when this option is present,
> or is that what the aforementioned metadata is used for?  I couldn't
> find the answer in
>   http://api.zeromq.org/4-2:zmq-setsockopt
> 
> or in the note about reconnect exceptions in
>   http://api.zeromq.org/4-2:zmq-connect
> 
> Thanks,
> 
> Jim Garlick

Hi,

This is used only for server-ish sockets - ie, all those that do any
sort of bind and you would use with zmq_bind, so it does not affect
zmq_connect (or re-connect).

I thought about adding it for the connect side too, but IMHO it wouldn't
make much sense. The purpose of systemd-managed sockets is to let
servers be started only when a client attempts to connect, and to
disentangle dependencies between services and allow them to start in
parallel at boot, while having systemd manage the FD buffer so that no
messages are lost in either scenario.
Neither of these would apply for client-ish sockets.

But we can of course look into it, do you have a use case where it would
be useful to have?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] [RFC] systemd socket activation for libzmq

2016-05-31 Thread Luca Boccassi
On Tue, 2016-05-31 at 11:06 -0700, Jim Garlick wrote:
> On Tue, May 31, 2016 at 05:47:24PM +0100, Luca Boccassi wrote:
> > On Tue, 2016-05-31 at 08:52 -0700, Jim Garlick wrote:
> > > On Mon, May 30, 2016 at 09:57:00PM +0200, Michal Vyskocil wrote:
> > > > Hi,
> > > > 
> > > > Awesome, the fact czmq handles that is good enough for me. Closed the
> > > > request.
> > > > On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote:
> > > > > Hi,
> > > > >
> > > > > Ale's thread about Setting privileges on a UNIX socket inspired me to
> > > > > create small patch to libzmq adding automatic systemd socket
> > > > > activation support.
> > > > > https://github.com/zeromq/libzmq/pull/2015
> > > > >
> > > > > Right now the feature is fairly minimal - limited to ipc transport -
> > > > > and tested manually using malamute broker. I would like to hear any
> > > > > feedback. If you consider it as useful (or want to avoid dependency on
> > > > > the most hated OSS software on the planet ;-)), please say so.
> > > > 
> > > > Hi,
> > > > 
> > > > That functionality is already implemented for both IPC and TCP sockets.
> > > > 
> > > > The low level library has the ZMQ_USE_FD socket option to pass a file
> > > > descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or
> > > > zsys_set_auto_use_fd(1) function to let zmq automatically match
> > > > endpoints to the corresponding sockets managed by systemd. As long as
> > > > the metadata matches (eg: file path for IPC, address + port for TCP), it
> > > > will just work out of the box.
> > > > 
> > > > Kind regards,
> > > > Luca Boccassi
> > > 
> > > Somehow I missed that - sounds useful!
> > > 
> > > Is the usual reconnect behavior disabled when this option is present,
> > > or is that what the aforementioned metadata is used for?  I couldn't
> > > find the answer in
> > >   http://api.zeromq.org/4-2:zmq-setsockopt
> > > 
> > > or in the note about reconnect exceptions in
> > >   http://api.zeromq.org/4-2:zmq-connect
> > > 
> > > Thanks,
> > > 
> > > Jim Garlick
> > 
> > Hi,
> > 
> > This is used only for server-ish sockets - ie, all those that do any
> > sort of bind and you would use with zmq_bind, so it does not affect
> > zmq_connect (or re-connect).
> > 
> > I thought about adding it for the connect side too, but IMHO it wouldn't
> > make much sense. The purpose of systemd-managed sockets is to let
> > servers be started only when a client attempts to connect, and to
> > disentangle dependencies between services and allow them to start in
> > parallel at boot, while having systemd manage the FD buffer so that no
> > messages are lost in either scenario.
> > Neither of these would apply for client-ish sockets.
> > 
> > But we can of course look into it, do you have a use case where it would
> > be useful to have?
> > 
> > Kind regards,
> > Luca Boccassi
> 
> Ah, thanks for the clarification.
> 
> Well, there are probably other ways to accomplish my use case.
> We have a broker that loads "plugins" as threads communicating with
> the broker over a per-plugin ZMQ_PAIR inproc:// socket.
> We'd like to be able to launch plugins as processes with fork/exec.
> What I had in mind when I heard about ZMQ_USE_FD was something like
> ZMQ_PAIR over file descriptors obtained with socketpair(), one end
> passed to plugin, one end retained by broker.
> 
> Having an endpoint that doesn't appear in any namespace simplifies
> life a bit compared to ipc:// or tcp:// - it wouldn't need to be
> protected against unauthorized access for example.
> 
> Jim

The use case sounds interesting, but as you correctly flagged it before,
the issue with the connect is that by design the actual socket might be
closed and reopened by the library, so I'm not sure how it could be made
to work.

Maybe it's time for a new intraproc:// transport, perhaps using sealed
pipes that were posted on this ML a while ago?
https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Meetup in Brussels, June 4th

2016-06-02 Thread Luca Boccassi
On Thu, 2016-05-19 at 16:55 +0200, Pieter Hintjens wrote:
> Hi All,
> 
> I'd like to invite anyone who's in the neighborhood to join an all-day
> meetup/patch party on June 4th in Brussels. The address is Rue des
> Ateliers 15. No registration necessary. There will be wifi, seating,
> coffee, drinks, snacks.
> 
> -Pieter

Hi Pieter,

Are we going to hack things during the day? Wondering whether to bring
my laptop or not :-)

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] [RFC] systemd socket activation for libzmq

2016-05-30 Thread Luca Boccassi
On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote:
> Hi,
> 
> Ale's thread about Setting privileges on a UNIX socket inspired me to
> create small patch to libzmq adding automatic systemd socket
> activation support.
> https://github.com/zeromq/libzmq/pull/2015
> 
> Right now the feature is fairly minimal - limited to ipc transport -
> and tested manually using malamute broker. I would like to hear any
> feedback. If you consider it as useful (or want to avoid dependency on
> the most hated OSS software on the planet ;-)), please say so.

Hi,

That functionality is already implemented for both IPC and TCP sockets.

The low level library has the ZMQ_USE_FD socket option to pass a file
descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or
zsys_set_auto_use_fd(1) function to let zmq automatically match
endpoints to the corresponding sockets managed by systemd. As long as
the metadata matches (eg: file path for IPC, address + port for TCP), it
will just work out of the box.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] [RFC] systemd socket activation for libzmq

2016-05-30 Thread Luca Boccassi
On Mon, 2016-05-30 at 21:57 +0200, Michal Vyskocil wrote:
> Hi,
> 
> Awesome, the fact czmq handles that is good enough for me. Closed the
> request.

I've been using it for a while and it works ok for my use cases, but of
course feedback and improvements are more than welcome! Please do let me
know if there are any issues or if you have ideas for improvements :-)

Kind regards,
Luca Boccassi

> On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote:
> > Hi,
> >
> > Ale's thread about Setting privileges on a UNIX socket inspired me
> to
> > create small patch to libzmq adding automatic systemd socket
> > activation support.
> > https://github.com/zeromq/libzmq/pull/2015
> >
> > Right now the feature is fairly minimal - limited to ipc transport -
> > and tested manually using malamute broker. I would like to hear any
> > feedback. If you consider it as useful (or want to avoid dependency
> on
> > the most hated OSS software on the planet ;-)), please say so.
> 
> Hi,
> 
> That functionality is already implemented for both IPC and TCP
> sockets.
> 
> The low level library has the ZMQ_USE_FD socket option to pass a file
> descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or
> zsys_set_auto_use_fd(1) function to let zmq automatically match
> endpoints to the corresponding sockets managed by systemd. As long as
> the metadata matches (eg: file path for IPC, address + port for TCP),
> it
> will just work out of the box.
> 
> Kind regards,
> Luca Boccassi
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-16 Thread Luca Boccassi
Hi,

During the Brussels meetup/hackaday I backported Kevin's Github+Travis
release to zerom4-1 and zeromq4-x.

We have quite a few bug fixes queued up there since the last stable
releases a year ago - shall we do a bugfix release for both? Those would
be 4.1.5 and 4.0.8.

Just to be sure, I've verified with abi-compliance-checker [1] that
there was no ABI breakage with the respective stable versions.

Kind regards,
Luca Boccassi

[1] https://github.com/lvc/abi-compliance-checker

On Mon, 2016-05-09 at 13:36 +0200, Kevin Sapper wrote:
> The deployment has a couple of constraints (see .travis.yml -> deploy: on:
> ).
> One constraint is the repo MUST be "zeromq/libzmq". If we port this to
> zeromq4-x and zeromq4-1
> we need to adjust this or remove this constraint altogether.
> 
> 2016-05-09 13:04 GMT+02:00 Luca Boccassi <luca.bocca...@gmail.com>:
> 
> > Awesome, thanks!
> >
> > So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
> > push the tags corresponding to the last commit of each previous release,
> > right? It might make moving all downloadable to Github a much easier
> > process.
> >
> > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> > > On libzmq master it's now possible to let travis automatically deploy
> > > artifacts. The deployment is triggered if a new tag is created. I've
> > > created a test release and tag[1] to see if it is working properly. The
> > > files that are available under this release have been deploy by travis.
> > >
> > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> > >
> > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi <luca.bocca...@gmail.com>:
> > >
> > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> > > > > Hi,
> > > > >
> > > > > Just for a curiosity - the content of packaging/debian collide with
> > > > > standard Debian packaging? It is intentionally there to not clash, so
> > > > maybe
> > > > > solve this problem. Either by not generating them, either by defying
> > > > safer
> > > > > location.
> > > >
> > > > It's not a problem with the location, it's just that the Debian source
> > > > package will end up having packaging stuff duplicated and with
> > different
> > > > content: 2 changelogs, 2 control files, etc.
> > > >
> > > > But again this is exactly why make dist exists - having that generated
> > > > packaging code in the repository is useful, no need to remove it.
> > > >
> > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > > > > > One note, 'make dist' always fails the first few times because
> > files
> > > > > > are missing. Keep this in mind. The git tarball has the great
> > > > > > advantage of never failing. (And since it makes tarballs look like
> > git
> > > > > > clones it gives the same experience to all developers.)
> > > > > >
> > > > > > I'd vote for killing 'make dist'. It also makes us dependent on
> > > > autotools.
> > > > >
> > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> > > > > and ./autogen.sh; ./configure; make dist works just fine.
> > > > > It was broken a while ago, but I fixed it, and now the CI tests that
> > it
> > > > > works.
> > > > >
> > > > > Besides, IMHO there are 2 big problems with just tarring up the git
> > > > > repo.
> > > > >
> > > > > First of all, it doesn't remove the dependency, it just moves it
> > down to
> > > > > the user. Which means we'll start getting bug reports that are due to
> > > > > the different versions of autotools or cmake used (and there are a
> > lot!
> > > > > ).
> > > > >
> > > > > But most importantly, the tarball will ship stuff that shouldn't be
> > > > > shipped, which is a huge problem for distribution packagers. For
> > > > > example, in CZMQ, the packaging bit would be shipped. That would
> > break
> > > > > many things in the package build process, and the distro maintainer
> > (ie:
> > > > > me :-) ) would have to take the shipped tarball and sanitize it,
> > nuking
> > > > > all extraneous bits. This should not be necessary! That's exactly the
> > > > > reason "make dist" exi

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-17 Thread Luca Boccassi
Sounds like a plan :-)

On Fri, 2016-06-17 at 16:04 +0300, Doron Somech wrote:
> Leave to someone else who use libzmq on widows and would like to
> contribute?
> On Jun 17, 2016 15:56, "Luca Boccassi" <luca.bocca...@gmail.com> wrote:
> 
> > Thanks!
> >
> > That page mentions Windows exes. What do we do about those?
> >
> > On Fri, 2016-06-17 at 13:59 +0200, Pieter Hintjens wrote:
> > > Never mind, found it. You should be able to edit all pages in intro:
> > > in a few minutes...
> > >
> > > On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens <p...@imatix.com> wrote:
> > > > Luca, what's your Wikidot login? I'll give you edit rights to that
> > page/site.
> > > >
> > > > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi <
> > luca.bocca...@gmail.com> wrote:
> > > >> The messages to the announce list have been sent, and are awaiting
> > > >> moderator approval.
> > > >>
> > > >> Pieter, Doron, how do we update the get-the-software page?
> > > >>
> > > >> http://zeromq.org/intro:get-the-software
> > > >>
> > > >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> > > >>> Second try went better :-) And on the 4.1 branch it was all right the
> > > >>> first time around. So it was probably just a CI hiccup.
> > > >>>
> > > >>> I'll send two separate messages to the announce list.
> > > >>>
> > > >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> > > >>> > Something has short-circuited on Travis, and while the upload of
> > the
> > > >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page
> > just
> > > >>> > shows a error mark, and says to delete the zip file and upload it
> > again
> > > >>> > (but the zip is in the MD5 and SHA sums files).
> > > >>> >
> > > >>> > I've removed the generated files and I'm trying to run the job
> > again.
> > > >>> >
> > > >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > > >>> > > If you run into any trouble with the automatic travis release
> > feel free to
> > > >>> > > ping me via twitter or mail.
> > > >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <
> > luca.bocca...@gmail.com>:
> > > >>> > >
> > > >>> > > > Yep! It should be pretty smooth.
> > > >>> > > >
> > > >>> > > > Is there anything windows-specific to do when we do a release?
> > > >>> > > >
> > > >>> > > > If not, if it's ok for you and Doron, I'm fine with taking
> > care of
> > > >>> > > > bumping the ABI revision (only, since there were no
> > incompatible
> > > >>> > > > changes), finalizing the NEWS and pushing the tag in both
> > repos.
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> ___
> > > >> zeromq-dev mailing list
> > > >> zeromq-dev@lists.zeromq.org
> > > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > > ___
> > > zeromq-dev mailing list
> > > zeromq-dev@lists.zeromq.org
> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> >
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-17 Thread Luca Boccassi
Thanks!

On Fri, 2016-06-17 at 15:22 +0300, Doron Somech wrote:
> Luca,  mails approved.
> On Jun 17, 2016 15:00, "Pieter Hintjens" <p...@imatix.com> wrote:
> 
> > Never mind, found it. You should be able to edit all pages in intro:
> > in a few minutes...
> >
> > On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens <p...@imatix.com> wrote:
> > > Luca, what's your Wikidot login? I'll give you edit rights to that
> > page/site.
> > >
> > > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi <luca.bocca...@gmail.com>
> > wrote:
> > >> The messages to the announce list have been sent, and are awaiting
> > >> moderator approval.
> > >>
> > >> Pieter, Doron, how do we update the get-the-software page?
> > >>
> > >> http://zeromq.org/intro:get-the-software
> > >>
> > >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> > >>> Second try went better :-) And on the 4.1 branch it was all right the
> > >>> first time around. So it was probably just a CI hiccup.
> > >>>
> > >>> I'll send two separate messages to the announce list.
> > >>>
> > >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> > >>> > Something has short-circuited on Travis, and while the upload of the
> > >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page
> > just
> > >>> > shows a error mark, and says to delete the zip file and upload it
> > again
> > >>> > (but the zip is in the MD5 and SHA sums files).
> > >>> >
> > >>> > I've removed the generated files and I'm trying to run the job again.
> > >>> >
> > >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > >>> > > If you run into any trouble with the automatic travis release feel
> > free to
> > >>> > > ping me via twitter or mail.
> > >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <
> > luca.bocca...@gmail.com>:
> > >>> > >
> > >>> > > > Yep! It should be pretty smooth.
> > >>> > > >
> > >>> > > > Is there anything windows-specific to do when we do a release?
> > >>> > > >
> > >>> > > > If not, if it's ok for you and Doron, I'm fine with taking care
> > of
> > >>> > > > bumping the ABI revision (only, since there were no incompatible
> > >>> > > > changes), finalizing the NEWS and pushing the tag in both repos.
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> ___
> > >> zeromq-dev mailing list
> > >> zeromq-dev@lists.zeromq.org
> > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-16 Thread Luca Boccassi
Yep! It should be pretty smooth.

Is there anything windows-specific to do when we do a release?

If not, if it's ok for you and Doron, I'm fine with taking care of
bumping the ABI revision (only, since there were no incompatible
changes), finalizing the NEWS and pushing the tag in both repos.

On Thu, 2016-06-16 at 18:55 +0200, Pieter Hintjens wrote:
> Sounds good. Shall we make these pilots for the new release process?
> 
> On Thu, Jun 16, 2016 at 1:10 PM, Luca Boccassi <luca.bocca...@gmail.com> 
> wrote:
> > Hi,
> >
> > During the Brussels meetup/hackaday I backported Kevin's Github+Travis
> > release to zerom4-1 and zeromq4-x.
> >
> > We have quite a few bug fixes queued up there since the last stable
> > releases a year ago - shall we do a bugfix release for both? Those would
> > be 4.1.5 and 4.0.8.
> >
> > Just to be sure, I've verified with abi-compliance-checker [1] that
> > there was no ABI breakage with the respective stable versions.
> >
> > Kind regards,
> > Luca Boccassi
> >
> > [1] https://github.com/lvc/abi-compliance-checker
> >
> > On Mon, 2016-05-09 at 13:36 +0200, Kevin Sapper wrote:
> >> The deployment has a couple of constraints (see .travis.yml -> deploy: on:
> >> ).
> >> One constraint is the repo MUST be "zeromq/libzmq". If we port this to
> >> zeromq4-x and zeromq4-1
> >> we need to adjust this or remove this constraint altogether.
> >>
> >> 2016-05-09 13:04 GMT+02:00 Luca Boccassi <luca.bocca...@gmail.com>:
> >>
> >> > Awesome, thanks!
> >> >
> >> > So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
> >> > push the tags corresponding to the last commit of each previous release,
> >> > right? It might make moving all downloadable to Github a much easier
> >> > process.
> >> >
> >> > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> >> > > On libzmq master it's now possible to let travis automatically deploy
> >> > > artifacts. The deployment is triggered if a new tag is created. I've
> >> > > created a test release and tag[1] to see if it is working properly. The
> >> > > files that are available under this release have been deploy by travis.
> >> > >
> >> > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> >> > >
> >> > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi <luca.bocca...@gmail.com>:
> >> > >
> >> > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > Just for a curiosity - the content of packaging/debian collide with
> >> > > > > standard Debian packaging? It is intentionally there to not clash, 
> >> > > > > so
> >> > > > maybe
> >> > > > > solve this problem. Either by not generating them, either by 
> >> > > > > defying
> >> > > > safer
> >> > > > > location.
> >> > > >
> >> > > > It's not a problem with the location, it's just that the Debian 
> >> > > > source
> >> > > > package will end up having packaging stuff duplicated and with
> >> > different
> >> > > > content: 2 changelogs, 2 control files, etc.
> >> > > >
> >> > > > But again this is exactly why make dist exists - having that 
> >> > > > generated
> >> > > > packaging code in the repository is useful, no need to remove it.
> >> > > >
> >> > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> >> > > > > > One note, 'make dist' always fails the first few times because
> >> > files
> >> > > > > > are missing. Keep this in mind. The git tarball has the great
> >> > > > > > advantage of never failing. (And since it makes tarballs look 
> >> > > > > > like
> >> > git
> >> > > > > > clones it gives the same experience to all developers.)
> >> > > > > >
> >> > > > > > I'd vote for killing 'make dist'. It also makes us dependent on
> >> > > > autotools.
> >> > > > >
> >> > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> >> > > > > and ./autogen.sh; ./c

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-17 Thread Luca Boccassi
Thanks!

That page mentions Windows exes. What do we do about those?

On Fri, 2016-06-17 at 13:59 +0200, Pieter Hintjens wrote:
> Never mind, found it. You should be able to edit all pages in intro:
> in a few minutes...
> 
> On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens <p...@imatix.com> wrote:
> > Luca, what's your Wikidot login? I'll give you edit rights to that 
> > page/site.
> >
> > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi <luca.bocca...@gmail.com> 
> > wrote:
> >> The messages to the announce list have been sent, and are awaiting
> >> moderator approval.
> >>
> >> Pieter, Doron, how do we update the get-the-software page?
> >>
> >> http://zeromq.org/intro:get-the-software
> >>
> >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> >>> Second try went better :-) And on the 4.1 branch it was all right the
> >>> first time around. So it was probably just a CI hiccup.
> >>>
> >>> I'll send two separate messages to the announce list.
> >>>
> >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> >>> > Something has short-circuited on Travis, and while the upload of the
> >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page just
> >>> > shows a error mark, and says to delete the zip file and upload it again
> >>> > (but the zip is in the MD5 and SHA sums files).
> >>> >
> >>> > I've removed the generated files and I'm trying to run the job again.
> >>> >
> >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> >>> > > If you run into any trouble with the automatic travis release feel 
> >>> > > free to
> >>> > > ping me via twitter or mail.
> >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" 
> >>> > > <luca.bocca...@gmail.com>:
> >>> > >
> >>> > > > Yep! It should be pretty smooth.
> >>> > > >
> >>> > > > Is there anything windows-specific to do when we do a release?
> >>> > > >
> >>> > > > If not, if it's ok for you and Doron, I'm fine with taking care of
> >>> > > > bumping the ABI revision (only, since there were no incompatible
> >>> > > > changes), finalizing the NEWS and pushing the tag in both repos.
> >>>
> >>>
> >>
> >>
> >>
> >> ___
> >> zeromq-dev mailing list
> >> zeromq-dev@lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] [zeromq-announce] ZeroMQ 4.0.8 stable is now available

2016-06-17 Thread Luca Boccassi
On Fri, 2016-06-17 at 16:36 +0200, Peter Kleiweg wrote:
> Luca Boccassi schreef op de 17e dag van de zomermaand van het jaar 2016:
> 
> > Hello,
> > 
> > We just uploaded a new release on the 4.0.x branch.
> > 
> > As a reminder, we are now publishing on Github. You can download all
> > distributable tarball/zip archives at:
> > 
> > https://github.com/zeromq/zeromq4-x/releases
> > 
> > Changes:
> 
> In the manpage for version 4.0.8 for zmq_ctx_set there are now 
> ZMQ_THREAD_SCHED_POLICY and ZMQ_THREAD_PRIORITY that were not 
> there for version 4.0.7, but there are no changes in zmq.h
> 
> Are these now document, while they were there before, but not 
> documenten? What is exactly going on? What version of ZeroMQ 
> introduced these things?
> 
> It would be useful if, when there is a new version of ZeroMQ, 
> there would be a complete list of API changes, both actual in 
> zmq.h and zmq_utils.h, as well as in the manual pages. That 
> would make the life of maintainers of bindings in other 
> programming languages a bit easier.

There were no changes in the API/ABI between 4.0.7 and 4.0.8 (and
between 4.1.4 and 4.1.5 too), I made sure to check.

However it is true that there are those manpages changes - thanks for
spotting that. Those 2 options are not present in the 4.0.x branch, only
in 4.1.x onward.

It is likely a mistake in backporting documentation from libzmq to
zeromq4-1, which ended up in zeromq4-x too even if it shouldn't have.
I'll correct that.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-17 Thread Luca Boccassi
Something has short-circuited on Travis, and while the upload of the
tar.gz was successful, the zip upload was not. The "edit-tag" page just
shows a error mark, and says to delete the zip file and upload it again
(but the zip is in the MD5 and SHA sums files).

I've removed the generated files and I'm trying to run the job again.

On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> If you run into any trouble with the automatic travis release feel free to
> ping me via twitter or mail.
> Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <luca.bocca...@gmail.com>:
> 
> > Yep! It should be pretty smooth.
> >
> > Is there anything windows-specific to do when we do a release?
> >
> > If not, if it's ok for you and Doron, I'm fine with taking care of
> > bumping the ABI revision (only, since there were no incompatible
> > changes), finalizing the NEWS and pushing the tag in both repos.


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-17 Thread Luca Boccassi
Second try went better :-) And on the 4.1 branch it was all right the
first time around. So it was probably just a CI hiccup.

I'll send two separate messages to the announce list.

On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> Something has short-circuited on Travis, and while the upload of the
> tar.gz was successful, the zip upload was not. The "edit-tag" page just
> shows a error mark, and says to delete the zip file and upload it again
> (but the zip is in the MD5 and SHA sums files).
> 
> I've removed the generated files and I'm trying to run the job again.
> 
> On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > If you run into any trouble with the automatic travis release feel free to
> > ping me via twitter or mail.
> > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <luca.bocca...@gmail.com>:
> > 
> > > Yep! It should be pretty smooth.
> > >
> > > Is there anything windows-specific to do when we do a release?
> > >
> > > If not, if it's ok for you and Doron, I'm fine with taking care of
> > > bumping the ABI revision (only, since there were no incompatible
> > > changes), finalizing the NEWS and pushing the tag in both repos.




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-06-17 Thread Luca Boccassi
The messages to the announce list have been sent, and are awaiting
moderator approval.

Pieter, Doron, how do we update the get-the-software page?

http://zeromq.org/intro:get-the-software

On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> Second try went better :-) And on the 4.1 branch it was all right the
> first time around. So it was probably just a CI hiccup.
> 
> I'll send two separate messages to the announce list.
> 
> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> > Something has short-circuited on Travis, and while the upload of the
> > tar.gz was successful, the zip upload was not. The "edit-tag" page just
> > shows a error mark, and says to delete the zip file and upload it again
> > (but the zip is in the MD5 and SHA sums files).
> > 
> > I've removed the generated files and I'm trying to run the job again.
> > 
> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > > If you run into any trouble with the automatic travis release feel free to
> > > ping me via twitter or mail.
> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" 
> > > <luca.bocca...@gmail.com>:
> > > 
> > > > Yep! It should be pretty smooth.
> > > >
> > > > Is there anything windows-specific to do when we do a release?
> > > >
> > > > If not, if it's ok for you and Doron, I'm fine with taking care of
> > > > bumping the ABI revision (only, since there were no incompatible
> > > > changes), finalizing the NEWS and pushing the tag in both repos.
> 
> 




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Defaulting to tweetnacl?

2016-02-11 Thread Luca Boccassi
Hi,

I'm looking at it.

Kind regards,
Luca Boccassi

On 11 February 2016 at 17:30, Pieter Hintjens <p...@imatix.com> wrote:
> BTW I've also broken Travis builds, as --with-tweetnacl is no longer valid.
>
> The correct model should be:
>
> - default build (uses tweetnacl)
> - libsodium bulld (separate)
>
> If no-one takes this on I'll give it a shot asap.
>
> -Pieter
>
> On Thu, Feb 11, 2016 at 6:22 PM, Pieter Hintjens <p...@imatix.com> wrote:
>> Just a follow up, I've cleaned up the tweetnacl code, which was a bit
>> of a disaster.
>>
>> It's now in the src directory as tweetnacl.c and .h and conforms to
>> expectations of the rest of the codebase.
>>
>> -Pieter
>>
>> On Thu, Feb 11, 2016 at 9:40 AM, Benjamin Henrion <zoo...@gmail.com> wrote:
>>> On Thu, Feb 11, 2016 at 9:36 AM, MinRK <benjami...@gmail.com> wrote:
>>>> I think tweetnacl by default makes sense.
>>>
>>> +1
>>>
>>> --
>>> Benjamin Henrion 
>>> FFII Brussels - +32-484-566109 - +32-2-3500762
>>> "In July 2005, after several failed attempts to legalise software
>>> patents in Europe, the patent establishment changed its strategy.
>>> Instead of explicitly seeking to sanction the patentability of
>>> software, they are now seeking to create a central European patent
>>> court, which would establish and enforce patentability rules in their
>>> favor, without any possibility of correction by competing courts or
>>> democratically elected legislators."
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Access to underlying Linux socket?

2016-02-11 Thread Luca Boccassi
On 11 February 2016 at 09:32, Mark Gillott <mgill...@brocade.com> wrote:
> On Wed, 2016-02-10 at 23:33 +0000, Luca Boccassi wrote:
>> On Feb 10, 2016 20:39, "Mark Gillott" <mgill...@brocade.com> wrote:
>> >
>> > On Wed, 2016-02-10 at 20:45 +0100, Pieter Hintjens wrote:
>> > > You can't do this really, since one ZeroMQ socket can map to 0..n
>> > > system sockets.
>> > >
>> >
>> > Had a feeling that was going to be the case.
>> >
>> > > There is a new option on libzmq master that lets you pre-configure
>> a
>> > > FD and give it to ZeroMQ to use for its first pipe. (ZMQ_USE_FD).
>> > >
>> >
>> > Care to expand a bit more? Is there something (test code? source
>> module)
>> > you can point me at?
>>
>> I can point you to the guy who developed that option. He sits a few
>> meters from you in the same office and he has an awesome beard. :-)
>>
>
> Is that the Italian guy who likes to add chicken to his pizza? :-).

Still better than deep fried mars bars!

>> > > A custom hook to configure new sockets is a nice idea.
>> > >
>> >
>> > So you register a hook with a newly created socket and you would get
>> a
>> > callback just prior to any bind/connect. Is that the idea? In czmq
>> > terms, something like:
>> >
>> > s = zsock_new(ZMQ_REP)
>> > zsock_configure(s, myfunc, myarg)
>> > zsock_bind(s)
>> >
>> > The callback would be provided with the base socket?
>>
>> Nice. That could work because all actual system sockets are created
>> after bind/connect. And in CZMQ we could add a global zys switch that
>> applies it automatically to all sockets to make it more convenient.
>>
>> But the problem is that such callback should be executed for all
>> sockets, be they TCP or IPC or inproc. So, there needs to be a way to
>> discriminate somehow, as what you can do with the FD varies wildly.
>>
>> It could be left to the application developer to be careful, but I
>> think that's confusing and likely to cause troubles.
>>
>
> Rather than a global callback, couldn't you attach the callback to
> individual sockets?
>
> Catch you later (if you're still talking to me!),

I propose both: the low-level library could have the basic feature of
per-socket callback, and the higher level binding in addition could
provide a global setting for convenience.

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] FYI: GCC 6 package breaks in Fedora

2016-02-22 Thread Luca Boccassi
On 22 February 2016 at 15:13, Steven McCoy <steven.mc...@miru.hk> wrote:
> Just saw this with ZeroMQ 3.2.5 and 4.1.4 listed:
>
> zeromq3-3.2.5-3.fc23.src.rpm
>
> zeromq-4.1.4-1.fc24.src.rpm
>
> -Wstrict-aliasing
>
> since http://gcc.gnu.org/PR66110 fix char/unsigned char/signed char
>
> fields in structs are no longer considered to alias everything
>
>
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/DH7M2ADHM6XCRFTRRSKZD6MWFUJKHBZK/

Hi,

I backported the fix for that error in the 4.0 and 4.1 stable repos:

https://github.com/zeromq/zeromq4-x/pull/149
https://github.com/zeromq/zeromq4-1/pull/101

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] State of libzmq versioning

2016-02-18 Thread Luca Boccassi
Cool stuff!

I was having a look at the changes in the public headers between 4.1
and master, and there _might_ be a backward-incompatible ABI change
between 4.1 and 4.2:

-typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
+/* union here ensures correct alignment on architectures that require it, e.g.
+ * SPARC
+ */
+typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;

Given zmq_msg_t is very often allocated on the calling application's
stack, having a different alignment between the application and the
library might break stuff if the library is making assumptions based
on it. Haven't delved deeper into it, does anyone have a better
insight in how zmq_msg_t is handled internally?

Kind regards,
Luca Boccassi

On 18 February 2016 at 09:12, Pieter Hintjens <p...@imatix.com> wrote:
> libzmq versioning is unchanged for years. There's a 4.1 stable fork
> that we apply fixes to, and will make one or two more releases of.
> There's 4.2 arriving on master, with a mix of stable API and new draft
> API. One thing we will do in 4.2 is clearly mark the draft API as
> such, and perhaps not build it by default, from source packages. We're
> using the same approach in CZMQ and other projects now.
>
> The goal with this is to allow shipment of the current master without
> having 100% stability on the API. There are things we know we'll need
> to refine and improve.
>
> -Pieter
>
> On Thu, Feb 18, 2016 at 12:04 AM, Mario Steinhoff
> <steinhoff.ma...@gmail.com> wrote:
>> So my question about the state of zmq versioning drifted in some kind
>> of we-need-more-automation-for-the-docs initiative. Awesome :)
>>
>> I'd love to help with it but I am already busy with the jzmq stuff for now.
>>
>> But the first question is still unanswered:
>>
>>> With all this, whats the current status on libzmq versioning?
>>
>> Or does no answer mean that all my assumptions were correct?
>>
>> 2016-02-17 18:48 GMT+01:00 Pieter Hintjens <p...@imatix.com>:
>>> We could use this, yes.
>>>
>>> Volunteers? :)
>>>
>>> On Wed, Feb 17, 2016 at 3:45 PM, Michel Pelletier
>>> <pelletier.mic...@gmail.com> wrote:
>>>> Read the docs is fantastic, I used it for pyczmq and it works great.  Also
>>>> it's not just software or a hosting service, the author (a local here in my
>>>> neck of the woods) hosts "write the docs" conferences focusing on writing
>>>> and producing good documentation:
>>>>
>>>> http://www.writethedocs.org/
>>>>
>>>> All together it's a powerful documentation ecosystem.
>>>>
>>>> -Michel
>>>>
>>>> On Wed, Feb 17, 2016 at 6:17 AM, Pieter Hintjens <p...@imatix.com> wrote:
>>>>>
>>>>> We have generators of various kinds: gitdown, mkman, which zproject
>>>>> uses/plugs into. The commonality is text files that turn into man
>>>>> pages and then various other formats that can be sent anywhere. I
>>>>> don't think we need to *standardise* so much as decide on a format, a
>>>>> host, and a safe way to upload after successful CI builds. We can have
>>>>> many of these.
>>>>>
>>>>> On Wed, Feb 17, 2016 at 12:05 PM, Arnaud Loonstra <arn...@sphaero.org>
>>>>> wrote:
>>>>> > Perhaps we can standardise on this? Perhaps even include some
>>>>> > generators for it in zproject?
>>>>> > I was starting to use Sphinx for Pyre as well. Now using it for
>>>>> > multiple projects. I'm not familiar with how it works with other
>>>>> > languages but for Python it's great.
>>>>> >
>>>>> > On 2016-02-17 10:39, Doron Somech wrote:
>>>>> >> Take a look at readthedocs.org [9], it is what NetMQ is using and
>>>>> >> completely automated. You manage the docs in the git repository.
>>>>> >>
>>>>> >> On Wed, Feb 17, 2016 at 10:41 AM, Pieter Hintjens <p...@imatix.com
>>>>> >> [10]>
>>>>> >> wrote:
>>>>> >>
>>>>> >>> Hmm, the tools we use to build the online docs are old and creaky,
>>>>> >>> and
>>>>> >>> date from long before we had neat CI automation. Meaning, we update
>>>>> >>> the api site manually.
>>>>> >>>
>>>>> >>> Im doing that now. I think its time we look at pushing this
>>>>> >>> direc

Re: [zeromq-dev] State of libzmq versioning

2016-02-18 Thread Luca Boccassi
Yes, the size is the same, but if the alignment changes then it's not
binary compatible I'm afraid. It is common for zmq_msg_t to be
allocated on the application's stack and then passed by reference to
the library to be manipulated. Given the new version imposes stricter
constraints on the compiler, I'm told that on x86 it will (probably)
work fine. But on other architectures it might not, as the old library
(and applications) and the new library will have been built under
different assumptions and constraints.

I'm not in any way familiar with SPARC, so I can only desume from the
inline comment that having a pointer will force the compiler to make
different (and stricter) choices regarding alignment.

Kind regards,
Luca Boccassi

On 18 February 2016 at 13:40, Doron Somech <somdo...@gmail.com> wrote:
> So this doesn't change the size of the zmq_msg_t (at it is a union), so
> internally there is no difference.
> Anyway I'm not sure what is the reason for this extra pointer.
>
> On Thu, Feb 18, 2016 at 2:06 PM, Luca Boccassi <luca.bocca...@gmail.com>
> wrote:
>>
>> Cool stuff!
>>
>> I was having a look at the changes in the public headers between 4.1
>> and master, and there _might_ be a backward-incompatible ABI change
>> between 4.1 and 4.2:
>>
>> -typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
>> +/* union here ensures correct alignment on architectures that require it,
>> e.g.
>> + * SPARC
>> + */
>> +typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;
>>
>> Given zmq_msg_t is very often allocated on the calling application's
>> stack, having a different alignment between the application and the
>> library might break stuff if the library is making assumptions based
>> on it. Haven't delved deeper into it, does anyone have a better
>> insight in how zmq_msg_t is handled internally?
>>
>> Kind regards,
>> Luca Boccassi
>>
>> On 18 February 2016 at 09:12, Pieter Hintjens <p...@imatix.com> wrote:
>> > libzmq versioning is unchanged for years. There's a 4.1 stable fork
>> > that we apply fixes to, and will make one or two more releases of.
>> > There's 4.2 arriving on master, with a mix of stable API and new draft
>> > API. One thing we will do in 4.2 is clearly mark the draft API as
>> > such, and perhaps not build it by default, from source packages. We're
>> > using the same approach in CZMQ and other projects now.
>> >
>> > The goal with this is to allow shipment of the current master without
>> > having 100% stability on the API. There are things we know we'll need
>> > to refine and improve.
>> >
>> > -Pieter
>> >
>> > On Thu, Feb 18, 2016 at 12:04 AM, Mario Steinhoff
>> > <steinhoff.ma...@gmail.com> wrote:
>> >> So my question about the state of zmq versioning drifted in some kind
>> >> of we-need-more-automation-for-the-docs initiative. Awesome :)
>> >>
>> >> I'd love to help with it but I am already busy with the jzmq stuff for
>> >> now.
>> >>
>> >> But the first question is still unanswered:
>> >>
>> >>> With all this, whats the current status on libzmq versioning?
>> >>
>> >> Or does no answer mean that all my assumptions were correct?
>> >>
>> >> 2016-02-17 18:48 GMT+01:00 Pieter Hintjens <p...@imatix.com>:
>> >>> We could use this, yes.
>> >>>
>> >>> Volunteers? :)
>> >>>
>> >>> On Wed, Feb 17, 2016 at 3:45 PM, Michel Pelletier
>> >>> <pelletier.mic...@gmail.com> wrote:
>> >>>> Read the docs is fantastic, I used it for pyczmq and it works great.
>> >>>> Also
>> >>>> it's not just software or a hosting service, the author (a local here
>> >>>> in my
>> >>>> neck of the woods) hosts "write the docs" conferences focusing on
>> >>>> writing
>> >>>> and producing good documentation:
>> >>>>
>> >>>> http://www.writethedocs.org/
>> >>>>
>> >>>> All together it's a powerful documentation ecosystem.
>> >>>>
>> >>>> -Michel
>> >>>>
>> >>>> On Wed, Feb 17, 2016 at 6:17 AM, Pieter Hintjens <p...@imatix.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> We have generators of various kinds: gitdown, mkman, which zproject
>> >>>>> uses/plugs into. The commo

Re: [zeromq-dev] Latest libzmq tests fail

2016-02-19 Thread Luca Boccassi
On 19 February 2016 at 12:29, Osiris Pedroso <opedr...@gmail.com> wrote:
> I work in Windows mostly, so when I see something that happens in Windows, I
> don't assume same is happening in Linux.
>
> I making some changes to compilation of libzmq in Windows and I wanted to
> make sure my changes do not break the Linux builds.
>
> So I got an Ubuntu 14.04 LTS VM and after 20+ years of Windows only
> development had a fun time figuring it out how to make things happen there.
>
> Anyways, I got the latest libzmq and see that the same tests that fail in
> Windows also fails in Linux (before any of my changes).
>
> The failing tests are:
> FAIL: tests/test_large_msg
> XFAIL: tests/test_req_correlate
> XFAIL: tests/test_req_relaxed
>
> All these failures generate core dumps.
>
> PS: Can anybody tell me what is the difference between a FAIL and a XFAIL?

XFAIL in autoconf/automake is an expected failure (it's marked as such
in the Makefile.am). It will not make the whole "make check" fail.

The other test works fine on my machine and on Travis at the moment so
I wouldn't worry about it, might be an intermittant failure:
https://travis-ci.org/zeromq/libzmq

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Access to underlying Linux socket?

2016-02-11 Thread Luca Boccassi
On 11 February 2016 at 15:27, Doron Somech <somdo...@gmail.com> wrote:
> What is the specific option you need? Just make a socket option and apply
> before connect. Like tcp keep alive and ipv6.

Hi Doron,

The problem is that, for the use case we have, we use it with an
internal build of the Linux kernel, with additional options that are
not merged upstream yet.

We could simply maintain an internal patch, but we are thinking that
if we can find a nice, general solution that could be useful for
everyone, it would be better :-)

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Access to underlying Linux socket?

2016-02-10 Thread Luca Boccassi
On Feb 10, 2016 20:39, "Mark Gillott" <mgill...@brocade.com> wrote:
>
> On Wed, 2016-02-10 at 20:45 +0100, Pieter Hintjens wrote:
> > You can't do this really, since one ZeroMQ socket can map to 0..n
> > system sockets.
> >
>
> Had a feeling that was going to be the case.
>
> > There is a new option on libzmq master that lets you pre-configure a
> > FD and give it to ZeroMQ to use for its first pipe. (ZMQ_USE_FD).
> >
>
> Care to expand a bit more? Is there something (test code? source module)
> you can point me at?

I can point you to the guy who developed that option. He sits a few meters
from you in the same office and he has an awesome beard. :-)

> > A custom hook to configure new sockets is a nice idea.
> >
>
> So you register a hook with a newly created socket and you would get a
> callback just prior to any bind/connect. Is that the idea? In czmq
> terms, something like:
>
> s = zsock_new(ZMQ_REP)
> zsock_configure(s, myfunc, myarg)
> zsock_bind(s)
>
> The callback would be provided with the base socket?

Nice. That could work because all actual system sockets are created after
bind/connect. And in CZMQ we could add a global zys switch that applies it
automatically to all sockets to make it more convenient.

But the problem is that such callback should be executed for all sockets,
be they TCP or IPC or inproc. So, there needs to be a way to discriminate
somehow, as what you can do with the FD varies wildly.

It could be left to the application developer to be careful, but I think
that's confusing and likely to cause troubles.

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Defaulting to tweetnacl?

2016-02-10 Thread Luca Boccassi
On Feb 10, 2016 22:41, "Pieter Hintjens" <p...@imatix.com> wrote:
>
> Hi all,
>
> I'd like to start moving to tweetnacl as the default when building
> libzmq. This means, no separate install of libsodium, and encryption
> built in by default. We can still have a --with-libsodium and
> --without-curve at configure time.
>
> Does anyone have a problem with this? It will not change anything
> significant in terms of performance nor interoperability. Just easier
> builds.

Hi,

As long as libsodium remains supported I don't think it is a problem. Bear
in mind that distributions like Debian will most likely use libsodium,
because even though it is allowed, it is strongly discouraged to ship
statically linked binaries, and it makes the mainteiners life harder. See:
https://wiki.debian.org/StaticLinking

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Defaulting to tweetnacl?

2016-03-01 Thread Luca Boccassi
On 1 March 2016 at 18:45, Roland Fehrenbacher <r...@q-leap.de> wrote:
>>>>>> "F" == frank  <sound...@gmx.net> writes:
>
> F> On 03/01/2016 02:51 PM, Roland Fehrenbacher wrote:
> >>>>>>> "P" == Pieter Hintjens <p...@imatix.com> writes:
> P> Frank, Thanks for your opinion. You hit it spot on, I think. It
> P> is really a relief to have security by default without any
> P> external packages.
> >>
> P> Roland, would this work? Package for Debian using libsodium?
> >>
> >> I'm a bit confused now. I thought the point of your original mail
> >> was that tweetnacl will be the default from now on and kind of
> >> substituting libsodium. If that is so, the suggested path for
> >> Debian would be to drop libsodium in favor of tweetnacl as well,
> >> with tweetnacl linked in as an external lib, just like libsodium
> >> currently is.
>
> F> Hi,
>
> F> sorry for causing confusion.
>
> F> I think the old default while building from source was "no
> F> cryptolib".
>
> F> If you want crypto you have now two options:
>
> F> - libsodium
> F> - tweetnacl
>
> F> Which you can enable with flags to the build system of choice. (I
> F> used cmake on linux/debian, but there are others too in libzmq)
>
> F> Libsodium is probably the better solution, except for these two
> F> points:
> F> - it does not support cmake for building :)
> F> - it requires you to install/compile it somehow seperately and
> F>   make it
> F> available to the libzmq build
>
> F> I have tried getting cmake support into libsodium but the pull
> F> request was rejected.  The second point is too complex for many
> F> developers who work on systems not having apt-get.
>
> F> libzmq3 on debian stable depends already on libsodium so has
> F> already deviated from the upstream default configuration
> F> (thanks!)  and enabled crypto. This (== using libsodium) is still
> F> the right thing to do in my opinion.
>
> Thanks for this clarification. So does everybody agree on the following:
>
> - Use the included tweetnacl for build/compile convenience
> - Use libsodium for clean distribution type of builds
> - Technically, both variants are roughly equivalent in terms of
>   performance, stability and test exposure etc.

Thumbs up!

Not sure if my previous mail made it through, got a bounce back from
the mailer. But we have test coverage in the CI for both, and the API
is the same, so we can be reasonably sure we can support both.

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Newbie questions re HWM and Async/Sync io

2016-03-21 Thread Luca Boccassi
On 21 March 2016 at 08:15, Aaron Koolen-Bourke <aaronkoo...@gmail.com> wrote:
> Hi all.

> Thing is, from what I can tell I then need to move to polling and not
> blocking receives, which not only keeps the thread busy looping, but seems
> to be quite expensive (There seems to be a sleep timer in there or some
> such). This just kills performance. Is there any support for a completely
> event driven system in ZMQ/CZMQ?

Hi Aaron,

CZMQ uses libzmq's poll APIs, which depending on your system will pick
out the best option to poll on file descriptors. On Linux for example
it will use epoll, on Windows it will use select and so on. So there's
no busy looping, so don't worry about performances.

Sorry but I'm not sure about the HWM issue, hopefully someone else can
give their 2c on that.

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] LIBZMQ license

2016-03-04 Thread Luca Boccassi
On Fri, 2016-03-04 at 12:37 +, Osiris Pedroso wrote:
> The file COPYING in libzmq indicates that liqzmq is licensed under
> GPLv3. There is no mention to a statically linked exception.
> 
> 
> The ZeroMQ site licensing page indicates that it is "GPLv3 plus
> a statically linking exception". But this is not stated anywhere in
> the code itself.
> 
> 
> Also most source files also in their headers reference GPLv3 but there
> is no mention to statically linked exception.
> 
> 
> Pieter, should you create a LICENSING file or edit the COPYING file to
> state that the Statically linked exception is in place?
> 
> 
> Also, the licensing page proposes to move it to MPL v2 license.
> 
> 
> I second that motion.
> 
> 
> Can this also be taken care and update the COPYING file to indicate
> this change has taken place?
> 
> 
> My company is starting to dot the i's and this poped up.

Hi,

As far as I understand, I think it's LGPL3 (linking exception at the
bottom): https://github.com/zeromq/libzmq/blob/master/COPYING.LESSER

Kind regards,
Luca Boccassi




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Defaulting to tweetnacl?

2016-03-01 Thread Luca Boccassi
On Mar 1, 2016 13:51, "Roland Fehrenbacher" <r...@q-leap.de> wrote:
>
> >>>>> "P" == Pieter Hintjens <p...@imatix.com> writes:
>
> P> Frank, Thanks for your opinion. You hit it spot on, I think. It
> P> is really a relief to have security by default without any
> P> external packages.
>
> P> Roland, would this work? Package for Debian using libsodium?
>
> I'm a bit confused now. I thought the point of your original mail was
> that tweetnacl will be the default from now on and kind of substituting
> libsodium. If that is so, the suggested path for Debian would be to drop
> libsodium in favor of tweetnacl as well, with tweetnacl linked in as an
> external lib, just like libsodium currently is.
>
> If on the other hand you decided to keep tweetnacl in the zmq code, for
> Debian, one would have to drop that part (DFSG modified source as
> mentioned before) and create patches that make zmq build fine with an
> external tweetnacl.
>
> Alternatively, you could probably say "What the heck
> with tweetnacl: We fully integrate it into zmq, respect the copyright
> and otherwise treat it, as if it was an original part of zmq from the
> beginning". I don't see why Debian couldn't live with this. So the only
> hurdle for this approach would probably be, to get the consent of the
> original authors.
>
> Please enlighten me, if I'm on a completely wrong track.

Hi,

I'm CC'ing Laszlo, the Debian maintainer, as I think this discussion will
be of interest to him.

Roland, being a DM, I shared your same concerns.

First of all, when the switch happened, I made sure that our CI still does
a test run using libsodium instead of tweetnacl, so that support for it
never suffers from bitrot and silently breaks. You can switch between the 2
with a compile time option, and again this is exercised by the CI. The API
being compatible, we can support both as long as the build system doesn't
break. No need for additional patches.

Then, tweetnacl code already became part of the libzmq source tree, so it's
not simply a library statically linked in. As part of this, it was slightly
changed and relicensed under the same license as the libzmq library. I am
not an expert on this subject, but Pieter was kind enough to explain to me
that this is allowed, since the original work is in the public domain, so
changing and re licensing can be done.

Given this, I don't believe packaging for distributions will be a problem.
Mainteiners can choose to either DFSG the source tree and take out the
tweetnacl modules and use libsodium instead, or to use the default
configuration with tweetnacl.

Please correct my assumptions and conclusions if I am wrong :-)

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] CZMQ "stable" release versioning

2016-04-24 Thread Luca Boccassi
On Sun, 2016-04-24 at 00:09 +0200, Pieter Hintjens wrote:
> we can mark individual methods and classes as draft, even within a
> stable release. 
> 
> On 23 Apr 2016 21:10, "Brian Knox" <bk...@digitalocean.com> wrote:
> When we cut another "stable" release of CZMQ to keep packagers
> happy, I'm wondering what version we'll use - specifically
> around a stable release that include radar/dish,
> scatter/gather and client/server.
> 
> 
> I want to start a new version of the rsyslog input and output
> plugins that only support the new thread safe sockets.  To
> avoid ifdef hell in the current plugins I'll probably just
> make new instances - so if the next release is 4, I'll name
> them omczmq4 / imczmq4 etc.
> 
> 
> Cheers,
> 
> Brian

Hi,



Given since the last release some public APIs have changed in an
incompatible way (eg: zmsg_encode/decode signatures), there should be a
major version bump (besides an ABI bump), and I'll have to upload a new
source/-dev package.

A while ago we also talked about the possibility of retiring the
deprecated APIs. Is that still on the plate?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Building CZMQ with disable-drafts

2016-04-22 Thread Luca Boccassi
On 22 April 2016 at 21:44, Osiris Pedroso <opedr...@gmail.com> wrote:
> How can I build CZMQ with disable-drafts in Ubuntu?
>
> In Windows, I run czmq/builds/msvc/configure.bat --disable-drafts to
> accomplish that.

Hi,

With automake: ./configure --enable-drafts=no
With CMake: cmake -DENABLE_DRAFTS=OFF

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Meetup in Brussels, June 4th

2016-05-19 Thread Luca Boccassi
On Thu, 2016-05-19 at 16:55 +0200, Pieter Hintjens wrote:
> Hi All,
> 
> I'd like to invite anyone who's in the neighborhood to join an all-day
> meetup/patch party on June 4th in Brussels. The address is Rue des
> Ateliers 15. No registration necessary. There will be wifi, seating,
> coffee, drinks, snacks.
> 
> -Pieter

Just booked the train! What's your favourite scotch whisky? :-)

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-05-09 Thread Luca Boccassi
Awesome, thanks!

So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
push the tags corresponding to the last commit of each previous release,
right? It might make moving all downloadable to Github a much easier
process.

On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> On libzmq master it's now possible to let travis automatically deploy
> artifacts. The deployment is triggered if a new tag is created. I've
> created a test release and tag[1] to see if it is working properly. The
> files that are available under this release have been deploy by travis.
> 
> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> 
> 2016-05-04 11:34 GMT+02:00 Luca Boccassi <luca.bocca...@gmail.com>:
> 
> > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> > > Hi,
> > >
> > > Just for a curiosity - the content of packaging/debian collide with
> > > standard Debian packaging? It is intentionally there to not clash, so
> > maybe
> > > solve this problem. Either by not generating them, either by defying
> > safer
> > > location.
> >
> > It's not a problem with the location, it's just that the Debian source
> > package will end up having packaging stuff duplicated and with different
> > content: 2 changelogs, 2 control files, etc.
> >
> > But again this is exactly why make dist exists - having that generated
> > packaging code in the repository is useful, no need to remove it.
> >
> > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > > > One note, 'make dist' always fails the first few times because files
> > > > are missing. Keep this in mind. The git tarball has the great
> > > > advantage of never failing. (And since it makes tarballs look like git
> > > > clones it gives the same experience to all developers.)
> > > >
> > > > I'd vote for killing 'make dist'. It also makes us dependent on
> > autotools.
> > >
> > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> > > and ./autogen.sh; ./configure; make dist works just fine.
> > > It was broken a while ago, but I fixed it, and now the CI tests that it
> > > works.
> > >
> > > Besides, IMHO there are 2 big problems with just tarring up the git
> > > repo.
> > >
> > > First of all, it doesn't remove the dependency, it just moves it down to
> > > the user. Which means we'll start getting bug reports that are due to
> > > the different versions of autotools or cmake used (and there are a lot!
> > > ).
> > >
> > > But most importantly, the tarball will ship stuff that shouldn't be
> > > shipped, which is a huge problem for distribution packagers. For
> > > example, in CZMQ, the packaging bit would be shipped. That would break
> > > many things in the package build process, and the distro maintainer (ie:
> > > me :-) ) would have to take the shipped tarball and sanitize it, nuking
> > > all extraneous bits. This should not be necessary! That's exactly the
> > > reason "make dist" exists.
> > >
> > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens <p...@imatix.com> wrote:
> > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <
> > luca.bocca...@gmail.com>
> > > wrote:
> > > > >
> > > > >> Is any of the API I marked as draft actually ready for release?
> > > > >
> > > > > Even so, leave it 'draft' until it's actually being used. Changing
> > > > > minds is expensive otherwise.
> > > > >
> > > > >> So should we use branches instead for bugfix releases?
> > > > >
> > > > > All fixes to master. In the extraordinary case where a bugfix release
> > > > > cannot be made from master, a branch could work. We never needed this
> > > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > > > > against branches unless it's the only option. (And I think we've
> > > > > designed ourselves space to never need that option.)
> > > > >
> > > > >> Isn't it possible to do the github release thing with the result of
> > > > >> "make dist"? I think I've read somewhere that you can use the
> > result of
> > > > >> CI builds.
> > > > >
> > > > > Seems Kevin has solved this, almost :)
> > > > >
> > > > > -Pieter
> > > > _

Re: [zeromq-dev] ABI reports for ZeroMQ

2016-05-11 Thread Luca Boccassi
On Wed, 2016-05-11 at 15:59 +0300, Ponomarenko Andrey wrote:
> Hello,
> 
> The reports for libzmq have been added to the ABI tracker project: 
> http://abi-laboratory.pro/tracker/timeline/zeromq/
> 
> So one can look at the recent changes in the library API/ABI and navigate 
> over the history of API/ABI changes. The reports are generated daily by 
> abi-dumper, abi-compliance-checker and abi-tracker tools: 
> https://github.com/lvc/abi-tracker
> 
> Hope this will help maintainers and developers of the library to maintain 
> backward binary compatibility.
> 
> Thanks for your feedback.

That's very useful, thank you!

It's flagging what I flagged a few months back, about the change in
zmq_msg_t:

http://lists.zeromq.org/pipermail/zeromq-dev/2016-February/029935.html

I think the resolution for that was that given it's not used internally,
but only in the applications, it shouldn't make a difference.

I'm still not convinced it will be fine on architectures other than x86,
but unfortunately I don't have a SPARC handy to test it :-)

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-05-10 Thread Luca Boccassi
On Tue, 2016-05-10 at 13:05 +0200, Kevin Sapper wrote:
> I just pushed changes to zproject and czmq to enable
> automatic travis github releases as well. There is a
> czmq test release that shows that it's working:
> 
> https://github.com/zeromq/czmq/releases/tag/v3.0.3-testing

Awesome, thanks!

One fix we need to do (I can send a PR tomorrow if no one else beats me
to it) is that the CMake stuff is not included in EXTRA_DIST, so it's
missing from the release tarball.

> 2016-05-10 5:16 GMT+02:00 Pieter Hintjens :
> 
> > Kevin, this is really neat. :)
> >
> > On Mon, May 9, 2016 at 11:26 PM, Ewen McNeill
> >  wrote:
> > > On 9/05/16 21:45, Kevin Sapper wrote:
> > >>
> > >> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> > >
> > >
> > > Thanks for automating this.  It looks great.
> > >
> > > This gives us two downloads per release (each in .tar.gz and .zip):
> > >
> > >
> > https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz
> > > -- the Travis generated tarball (which I assume is prepared ready for
> > > "./configure, make, make install")
> > >
> > > https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz
> > > -- the GitHub auto-generated tarball from that release tag (which I
> > assume
> > > is what a git clone would give you, so a few extra steps required).
> > >
> > > So downloaders can choose the one they want.  (Including .zip file
> > > variations of both.)
> > >
> > > Also of note, both URLs include a filename at the end, so "wget"
> > > automatically does the right thing with the downloaded files (I just
> > > tested).
> > >
> > > Ewen
> > >
> > > ___
> > > zeromq-dev mailing list
> > > zeromq-dev@lists.zeromq.org
> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-05-03 Thread Luca Boccassi
On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> One note, 'make dist' always fails the first few times because files
> are missing. Keep this in mind. The git tarball has the great
> advantage of never failing. (And since it makes tarballs look like git
> clones it gives the same experience to all developers.)
> 
> I'd vote for killing 'make dist'. It also makes us dependent on autotools.

Uhm I just tried fresh clones of both libzmq and zeromq4-1,
and ./autogen.sh; ./configure; make dist works just fine.
It was broken a while ago, but I fixed it, and now the CI tests that it
works.

Besides, IMHO there are 2 big problems with just tarring up the git
repo.

First of all, it doesn't remove the dependency, it just moves it down to
the user. Which means we'll start getting bug reports that are due to
the different versions of autotools or cmake used (and there are a lot!
).

But most importantly, the tarball will ship stuff that shouldn't be
shipped, which is a huge problem for distribution packagers. For
example, in CZMQ, the packaging bit would be shipped. That would break
many things in the package build process, and the distro maintainer (ie:
me :-) ) would have to take the shipped tarball and sanitize it, nuking
all extraneous bits. This should not be necessary! That's exactly the
reason "make dist" exists.

> On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens <p...@imatix.com> wrote:
> > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <luca.bocca...@gmail.com> 
> > wrote:
> >
> >> Is any of the API I marked as draft actually ready for release?
> >
> > Even so, leave it 'draft' until it's actually being used. Changing
> > minds is expensive otherwise.
> >
> >> So should we use branches instead for bugfix releases?
> >
> > All fixes to master. In the extraordinary case where a bugfix release
> > cannot be made from master, a branch could work. We never needed this
> > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > against branches unless it's the only option. (And I think we've
> > designed ourselves space to never need that option.)
> >
> >> Isn't it possible to do the github release thing with the result of
> >> "make dist"? I think I've read somewhere that you can use the result of
> >> CI builds.
> >
> > Seems Kevin has solved this, almost :)
> >
> > -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-05-03 Thread Luca Boccassi
On Tue, 2016-05-03 at 10:39 +0200, Pieter Hintjens wrote:
> Hi all,
> 
> I'm just throwing some ideas on the table. We have a good package of
> work on master and it's probably time to make a 4.2 release.
> 
> Luca has already back-ported the enable/disable draft design from
> zproject (CZMQ et al). Yay! So we can now release stable master
> safely, while continuing to refine and extend the draft API sections.

:-)

Is any of the API I marked as draft actually ready for release?

> I propose:
> 
> - to end with the stable fork policy; this was needed years ago when
> we had massively unstable masters. It's no longer a problem.

I like not using forks anymore, as having a separate git history is a
pain for backporting fixes.
So should we use branches instead for bugfix releases?

> - to use the github release function for libzmq releases and deprecate
> the separate delivery of tarballs.
> - we aim to make a 4.2.0 rc asap, then fix any issues we get, with
> patch releases as usual.
> - we backport the release function to older maintained releases (4.1,
> 3.2) so that their tarballs are provided by github instead of
> downloads.zeromq.org.
> 
> Problems:
> 
> - this will break a few things that depend on downloads.zeromq.org. To
> be fixed as we go.
> - github tarballs are not identical to source tarballs, particularly
> they lack `configure`. I propose changing our autotools build
> instructions so they always start with `./autogen,sh` no matter where
> the sources come from.

The problem is that will add all the autotools chain as a
build-dependency. And given that the end result varies massively
depending on version and platform, this might create more issues for
users.

Isn't it possible to do the github release thing with the result of
"make dist"? I think I've read somewhere that you can use the result of
CI builds. If that's the case, we can still use the make dist release
tarballs IMHO.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-05-03 Thread Luca Boccassi
On Tue, 2016-05-03 at 13:26 +0200, Kevin Sapper wrote:
> I'm currently experimenting with travis automated github releases and
> finally gotten to the point where things add up.
> 
> I could try to set this up for libzmq but I need to know how to build the
> release tarballs, checksums, changelog, debs, rpms, etc. Then I can make
> travis upload those artifacts to github releases and even override the
> github generated tarballs.

The release tarball can be built with "make dist".

I don't think we should start releasing debs/rpms. Remember that
debs/rpms are binary releases, which means they MUST be built in the
same environment (libc, etc) as where they are targeted for
installation. This means you can't have one rpm and one deb, you must
have one for each version of each distribution you want to support.

It's a pain, and it's the wrong way to do it. The right way is to make
things easy for the distro maintainers and work with them, so that the
libraries get packaged and distributed from the repositories by the
maintainers.

If someone wants to build and install locally a newer version that it's
available in a distro, make install of the source tarball to /usr/local
tree is safer IMHO.

> 2016-05-03 12:37 GMT+02:00 Pieter Hintjens :
> 
> > The ztools/zmqapi tool generates the 4.2 docs from libzmq master (see
> > apiall script below). The generation tool checks out specific
> > repos/tags for each release, so you can easily set it to generate
> > 4.2.0 from a tagged release.
> >
> > Relevant piece from apiall:
> >
> > #   DirectoryTag  Category
> > $TOOLDIR/apione ../../zeromq3-x  master   3-2
> > $TOOLDIR/apione ../../zeromq4-x  master   4-0
> > $TOOLDIR/apione ../../zeromq4-1  master   4-1
> > $TOOLDIR/apione ../../libzmq master   4-2
> >
> > On Tue, May 3, 2016 at 10:52 AM, Doron Somech  wrote:
> > > Question about the API documentation, now at api.zeromq.org we have
> > docs for
> > > each version coming from the stable branches.
> > >
> > > Should we still have docs for v4.2 separate from master docs? if so where
> > > the v4.2 docs are coming from?
> > >
> > > We can drop the docs per separate versions as we now only have master.
> > >
> > >
> > >
> > > On Tue, May 3, 2016 at 11:39 AM, Pieter Hintjens  wrote:
> > >>
> > >> Hi all,
> > >>
> > >> I'm just throwing some ideas on the table. We have a good package of
> > >> work on master and it's probably time to make a 4.2 release.
> > >>
> > >> Luca has already back-ported the enable/disable draft design from
> > >> zproject (CZMQ et al). Yay! So we can now release stable master
> > >> safely, while continuing to refine and extend the draft API sections.
> > >>
> > >> I propose:
> > >>
> > >> - to end with the stable fork policy; this was needed years ago when
> > >> we had massively unstable masters. It's no longer a problem.
> > >> - to use the github release function for libzmq releases and deprecate
> > >> the separate delivery of tarballs.
> > >> - we aim to make a 4.2.0 rc asap, then fix any issues we get, with
> > >> patch releases as usual.
> > >> - we backport the release function to older maintained releases (4.1,
> > >> 3.2) so that their tarballs are provided by github instead of
> > >> downloads.zeromq.org.
> > >>
> > >> Problems:
> > >>
> > >> - this will break a few things that depend on downloads.zeromq.org. To
> > >> be fixed as we go.
> > >> - github tarballs are not identical to source tarballs, particularly
> > >> they lack `configure`. I propose changing our autotools build
> > >> instructions so they always start with `./autogen,sh` no matter where
> > >> the sources come from.
> > >>
> > >> I think this will work and also let us gracefully deprecate/switch off
> > >> the downloads box.
> > >>
> > >> -Pieter
> > >> ___
> > >> zeromq-dev mailing list
> > >> zeromq-dev@lists.zeromq.org
> > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > >
> > >
> > >
> > > ___
> > > zeromq-dev mailing list
> > > zeromq-dev@lists.zeromq.org
> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-05-04 Thread Luca Boccassi
On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> Hi,
> 
> Just for a curiosity - the content of packaging/debian collide with
> standard Debian packaging? It is intentionally there to not clash, so maybe
> solve this problem. Either by not generating them, either by defying safer
> location.

It's not a problem with the location, it's just that the Debian source
package will end up having packaging stuff duplicated and with different
content: 2 changelogs, 2 control files, etc.

But again this is exactly why make dist exists - having that generated
packaging code in the repository is useful, no need to remove it.

> On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > One note, 'make dist' always fails the first few times because files
> > are missing. Keep this in mind. The git tarball has the great
> > advantage of never failing. (And since it makes tarballs look like git
> > clones it gives the same experience to all developers.)
> >
> > I'd vote for killing 'make dist'. It also makes us dependent on autotools.
> 
> Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> and ./autogen.sh; ./configure; make dist works just fine.
> It was broken a while ago, but I fixed it, and now the CI tests that it
> works.
> 
> Besides, IMHO there are 2 big problems with just tarring up the git
> repo.
> 
> First of all, it doesn't remove the dependency, it just moves it down to
> the user. Which means we'll start getting bug reports that are due to
> the different versions of autotools or cmake used (and there are a lot!
> ).
> 
> But most importantly, the tarball will ship stuff that shouldn't be
> shipped, which is a huge problem for distribution packagers. For
> example, in CZMQ, the packaging bit would be shipped. That would break
> many things in the package build process, and the distro maintainer (ie:
> me :-) ) would have to take the shipped tarball and sanitize it, nuking
> all extraneous bits. This should not be necessary! That's exactly the
> reason "make dist" exists.
> 
> > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens <p...@imatix.com> wrote:
> > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <luca.bocca...@gmail.com>
> wrote:
> > >
> > >> Is any of the API I marked as draft actually ready for release?
> > >
> > > Even so, leave it 'draft' until it's actually being used. Changing
> > > minds is expensive otherwise.
> > >
> > >> So should we use branches instead for bugfix releases?
> > >
> > > All fixes to master. In the extraordinary case where a bugfix release
> > > cannot be made from master, a branch could work. We never needed this
> > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > > against branches unless it's the only option. (And I think we've
> > > designed ourselves space to never need that option.)
> > >
> > >> Isn't it possible to do the github release thing with the result of
> > >> "make dist"? I think I've read somewhere that you can use the result of
> > >> CI builds.
> > >
> > > Seems Kevin has solved this, almost :)
> > >
> > > -Pieter
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Moving list to Google groups?

2016-04-15 Thread Luca Boccassi
On Fri, 2016-04-15 at 14:53 +0800, Jim Idle wrote:
> > On 14.04.2016 09:41, Pieter Hintjens wrote:
> > >> So an added criteria for any new platform is ability to import our
> > archives.
> > >>
> > >> Free is a plus iff the hosting business is long term reliable.
> > >>
> > >> Conventional email interface is a plus.
> > >>
> >
> 
> https://developers.google.com/admin-sdk/groups-migration/v1/guides/manage-email-migrations#group_migrate_media_upload
> 
> Seems to be mixed emotions on adopting Google groups, but it does have a
> conventional email interface, you do not have to create a google account to
> use the email, and it supports imports.

Given it can be used with emails and the archive can be imported, +1 for
Google Groups from me too.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Role of iMatix in ZeroMQ community

2016-04-19 Thread Luca Boccassi
On 18 April 2016 at 20:39, Pieter Hintjens <p...@imatix.com> wrote:
> Hi folks,
>
> I learned today that I'm terminally ill with lung cancer. Metastasis from an
> incident five years ago. iMatix has run for 20 years and today consists of
> myself as only active resource. This means we need to remove my firm as a
> dependency.

This is most horrible news, I am so sorry Pieter.

> Suggestions for a safe long term home for the domain names, if you would.
>
> Pieter

Personally I also like the Linux Foundation idea. I'm happy to help in
any way I can.

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Resource temporarily unavailable") at src/err.cpp:83

2016-08-12 Thread Luca Boccassi
Or raise the number of file descriptors in the system.
Note that the setting is per-user, and you might have to raise the
hard limit. You can google for more details as it depends on your
system and distribution:
ulimit -n 
sysctl fs.file-max

On 12 August 2016 at 18:31, Marcin Romaszewicz  wrote:
> You are running out of file descriptors, most likely. Each outgoing
> connection requires a file descriptor, and 100k is a lot of sockets. Are you
> trying to make 100k ZMQ sockets? If  you are, just limit the number of
> outgoing sockets, and it should work. Only send 1000 at a time, for example.
>
> On Fri, Aug 12, 2016 at 5:26 AM, Ranjeet Kumar  wrote:
>>
>> Hi,
>>
>> I am using Zeromq 4.1.5 and czmq 3.0.2 version.
>> I am getting below exception every time when i am sending message to 100k
>> zmq dealer clients.
>> In my zmq server application I am having 2 threads. In main thread I am
>> listening via zmq router socket using poll, getting HB. And from other
>> thread I am getting
>> message that i need to send 100k zmq dealer clients. But as soon as count
>> reach near to 4-5k clients to send app get crashed. Please suggest I am in
>> deep trouble.
>>
>> #0  0x768f15f7 in raise () from /lib64/libc.so.6
>> #1  0x768f2ce8 in abort () from /lib64/libc.so.6
>> #2  0x77b8f769 in zmq::zmq_abort
>> (errmsg_=errmsg_@entry=0x76a3af60 "Resource temporarily unavailable") at
>> src/err.cpp:83
>> #3  0x77ba72f9 in zmq::signaler_t::recv (this=this@entry=0x60b8a0)
>> at src/signaler.cpp:282
>> #4  0x77b92f30 in zmq::mailbox_t::recv (this=this@entry=0x60b840,
>> cmd_=cmd_@entry=0x7490cbc0, timeout_=timeout_@entry=0) at
>> src/mailbox.cpp:87
>> #5  0x77ba8249 in zmq::socket_base_t::process_commands
>> (this=this@entry=0x60b480, timeout_=timeout_@entry=0,
>> throttle_=throttle_@entry=true)
>> at src/socket_base.cpp:1044
>> #6  0x77ba856b in zmq::socket_base_t::send
>> (this=this@entry=0x60b480, msg_=msg_@entry=0x7fffe800d714,
>> flags_=flags_@entry=2) at src/socket_base.cpp:829
>> #7  0x77bbe09c in s_sendmsg (s_=s_@entry=0x60b480,
>> msg_=msg_@entry=0x7fffe800d714, flags_=flags_@entry=2) at src/zmq.cpp:346
>> #8  0x77bbe41a in zmq_msg_send (msg_=msg_@entry=0x7fffe800d714,
>> s_=s_@entry=0x60b480, flags_=flags_@entry=2) at src/zmq.cpp:590
>> #9  0x77bbe42e in zmq_sendmsg (s_=s_@entry=0x60b480,
>> msg_=msg_@entry=0x7fffe800d714, flags_=flags_@entry=2) at src/zmq.cpp:355
>> #10 0x778ee693 in zframe_send (self_p=self_p@entry=0x7490cce8,
>> dest=dest@entry=0x60b480, flags=) at src/zframe.c:158
>> #11 0x778f7e1f in zmsg_send (self_p=0x7490cdc0,
>> dest=) at src/zmsg.c:140
>>
>>
>> Thanks
>> Ranjeet
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-08-13 Thread Luca Boccassi
Hello,

Trying to give some thoughts again on the libzmq 4.2 release. It's
really long overdue!

The main issue from my point of view is this change:

https://github.com/zeromq/libzmq/commit/d9fb1d36ff2008966af538f722a1f4ab158dbf64

-typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
 +/* union here ensures correct alignment on architectures that require
it, e.g.
 + * SPARC
 + */
 +typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;


This is flagged by the common ABI checkers tools as an ABI breakage
(see: http://abi-laboratory.pro/tracker/timeline/zeromq/ ). And it makes
sense from this point of view: if some applications on some
architectures are broken due to wrong alignment, they would need to be
rebuilt, and the way to ensure that is to bump the ABI "current" digit
to make sure maintainers do a rebuild.

On the other hand, signaling an ABI breakage is a pain, and a cause of
major churn for packagers and maintainers. It means for example a new
package has to be created (eg: libzmq5 -> libzmq6), and a transition has
to be started and all reverse dependencies need to be rebuilt. And if
this is pointless for all save a few corner cases (eg SPARC64 as for
above) it's all quite frustrating.

So we have a choice to make before we release 4.2, four possibilities as
far as I can see:

1) Ignore the ABI checkers and get yelled at by maintainers and
packagers. Also the SPARC64 users will most likely NOT get their bug
fixed
2) Bump ABI revision to 6 and get yelled at by maintainers and packagers
3) Revert the above change and postpone it to when we have a more
generally useful reason to break ABI (bump zmq_msg_t from 64 to 128
bytes for example, Doron?)
4) Try to be clever and revert the above change and use something like
#pragma pack(8). This will fool the ABI checkers (I tried it), and given
that typedef is only used externally to allocate the right size it
shouldn't actually affect anything, apart from the users of SPARC64
which should get the bugfix with this too. This is very sneaky :-)

CC'ing Lazslo, the Debian maintainer, given what we choose to do might
result in a lot of work for him :-)

Opinions?

Kind regards,
Luca Boccassi

On Tue, 2016-05-03 at 10:39 +0200, Pieter Hintjens wrote:
> Hi all,
> 
> I'm just throwing some ideas on the table. We have a good package of
> work on master and it's probably time to make a 4.2 release.
> 
> Luca has already back-ported the enable/disable draft design from
> zproject (CZMQ et al). Yay! So we can now release stable master
> safely, while continuing to refine and extend the draft API sections.
> 
> I propose:
> 
> - to end with the stable fork policy; this was needed years ago when
> we had massively unstable masters. It's no longer a problem.
> - to use the github release function for libzmq releases and deprecate
> the separate delivery of tarballs.
> - we aim to make a 4.2.0 rc asap, then fix any issues we get, with
> patch releases as usual.
> - we backport the release function to older maintained releases (4.1,
> 3.2) so that their tarballs are provided by github instead of
> downloads.zeromq.org.
> 
> Problems:
> 
> - this will break a few things that depend on downloads.zeromq.org. To
> be fixed as we go.
> - github tarballs are not identical to source tarballs, particularly
> they lack `configure`. I propose changing our autotools build
> instructions so they always start with `./autogen,sh` no matter where
> the sources come from.
> 
> I think this will work and also let us gracefully deprecate/switch off
> the downloads box.
> 
> -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Erlang implementation of ZMTP 3.1

2016-08-13 Thread Luca Boccassi
Hi,

It means that the upstream repository would become
github.com/zeromq/erlangzmq together with all the other implementations,
and of course you'll become a member of the org and have full admin rights
on that repository

On Aug 13, 2016 18:59, "Andriy Drozdyuk"  wrote:

> Hi, Peter.
> What did you mean by "bring the project into the ZeroMQ organization on
> github"?
>
> Would I still be able to oversee the development process? In particular,
> accepting patches, nominating contributors etc...
> How does that work?
>
> Thank you.
>
> On Thu, 30 Jun 2016 at 12:39 Andriy Drozdyuk  wrote:
>
>> Thanks Pieter. I've read all those things when I learned zmq :) I agree
>> with what you're suggesting, but that model doesn't really work for me at
>> this time. I was thinking of trying it this way for a year to see what
>> happens in the future.
>>
>> Elliot, thanks for that distinction. I've never thought about that but it
>> makes perfect sense.
>> Regarding curve, that would be amazing. This was going to be my next
>> goal. You can contact me at dro...@choven.ca so we can discuss it
>> further.
>>
>> On Thu, 30 Jun 2016, 5:10 a.m. Elliot Crosby-McCullough, <
>> elliot...@gmail.com> wrote:
>>
>>> Hi Andriy,
>>>
>>> Glad to see a full BEAM implementation.
>>>
>>> I've been working on something similar in Elixir (https://github.com/
>>> SmartCasual/elixir-zeromq) but since you've gotten further in Erlang
>>> I'll take a look at contributing Curve support to yours instead, since all
>>> I really wanted was native BEAM instead of a binding to the C library given
>>> the dangers and/or inefficiencies of doing so.
>>>
>>> I'll have to look more closely into the licensing you've gone for to see
>>> whether it's compatible with my needs.
>>>
>>> Small note, but what you've got there is an implementation not a binding
>>> (which is a good thing).  It would be a binding if it used e.g. the C
>>> library to do the work.
>>>
>>> Regards,
>>> Elliot
>>>
>>> On 28 June 2016 at 18:09, Andriy Drozdyuk  wrote:
>>>
 At Pieter's suggestion, I am putting this here:
 https://github.com/chovencorp/erlangzmq

 Native erlang 18 implementation of ZMTP 3.1 (including resource
 property), but without any security.

 Hopefully it will be useful to people. I know I'll use it myself -
 since all (native) erlang bindings are out of date.

 This is a six month young project, so this is NOT performance or
 otherwise tested at all, and I would appreciate any feedback (just take a
 second to file an issue).

 Thank you,
 --Andriy Drozdyuk

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?

2017-01-31 Thread Luca Boccassi
On Mon, 2017-01-30 at 14:18 +, simon.giese...@btc-ag.com wrote:
> Hi again,
> 
> I was now able to do a local test with the current HEAD of libzmq, which 
> seems to fix the problem again.
> 
> To do complete tests in our integration environment, I would require a 
> release version. When is 4.2.2 going to be released? Is it possible to do 
> this in the next days?
> 
> Best regards
> Simon

4.2.1 was released not too long ago, so we could probably do one
sometimes before mid February when there should be enough bug fixes
queued up

> -Ursprüngliche Nachricht-
> Von: Luca Boccassi [mailto:luca.bocca...@gmail.com] 
> Gesendet: Montag, 16. Januar 2017 12:26
> An: ZeroMQ development list
> Betreff: Re: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?
> 
> On Mon, 2017-01-16 at 10:32 +, simon.giese...@btc-ag.com wrote:
> > Hi,
> > 
> > we have migrated from ZeroMQ 4.1.5 to 4.2.1 recently and I notice some 
> > behaviour change in some of our test cases. These cases are related to 
> > enforcing that some queues run full resp. the HWM is exceeded. Sorry I 
> > cannot be more precise at the moment; I tried to reproduce the behavioural 
> > differences with some reduced code example, but have not been successful so 
> > far. To enable me to facilitate a more focused reproduction of the issue, I 
> > have a general question in advance. Have there been any deliberate changes 
> > in behaviour between 4.1.5 and 4.2.1 that might be related to this? From 
> > reading the release notes, I did not find something that raised my 
> > attention.
> > 
> > Best regards
> > Simon
> 
> One major change is that setting HWM works also after connecting/binding, is 
> that what you are doing?
> 
> There were many other bug fixes that can be seen in the git log, can't 
> remember all of them off the top of my head
> 
> Also what transport mode are you using?
> 
> Kind regards,
> Luca Boccassi




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] One socket per thread or per call?

2017-01-31 Thread Luca Boccassi
On Mon, 2017-01-30 at 23:22 +0100, Patrick Boettcher wrote:
> Hi all,
> 
> I'm new to zmq and still discovering things and I'd like your feedback
> on a design decision.
> 
> (I asked the same question on StackOverflow, before seeing that there
> is a zmq-mailing list. 
> http://stackoverflow.com/questions/41941702/one-zeromq-socket-per-thread-or-per-call)
> 
> As we all know, a ZeroMQ socket shall not be shared between application
> threads. Contexts however can.
> 
> I have a multi-threaded-application and I'd like to have each thread
> exchange messages from time to time with a REP-socket (event, exceptions
> and the like) depending what they are doing (they are doing
> non-ZeroMQ-stuff).
> 
> To send messages to my REP-socket I use the following function
> (half-C++ half-pseudo-code):
> 
>   bool sendMessage(std::string s)
>   {
>   zmq::socket_t socket(globalContext(), ZMQ_REQ);
>   socket.connect(ETT::IPC::httpV1ConcentratorEndpoint);
> 
>   zmq::message_t message(s.size());
>   memcpy(message.data(), s.data(), s.size());
>   if (!socket.send(message))
>   return false;
> 
>   // poll on socket for POLLIN with timeout
> 
>   socket.recv();
>   // do something with message
> 
>   return true;
>   }
> 
> This function is called from every thread when needed. It creates a
> local socket, connects, sends the message, and receives a response.
> At exit, the socket is disconnected and removed (at least I'm
> assuming that it is closed).

That's the C++ bindings so not sure, but libzmq does not close anything
for you, you have to do it explicitly

> This way, I don't need to bother to maintain a socket in each of my
> threads. This comes at the cost of creating and connecting each time I
> call this function.
> 
> I stressed this code and I don't see much difference between reusing
> one socket and this reconnect-implementation. (I have 20k REP-REQ per
> second, including json-decode/encode, in both cases)
> 
> Is there a more correct ZeroMQ-way of doing this?
> 
> best regards,
> --
> Patrick.

Closing and reopening sockets continuosly is an anti-pattern, I would
recommend opening a socket when the thread starts and closing it when
it's torn down

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Glar on onioncat in TAP mode

2017-02-07 Thread Luca Boccassi
On Mon, 2017-02-06 at 17:30 +0100, Benjamin Henrion wrote:
> Hi,
> 
> At the hackaton, I tried and failed to make Glar working on Onioncat
> in TAP mode.
> 
> I needed to create a br0 bridge and add the tap0 to it, add an IP
> address to the br0, I could ping both endpoints, but glar would not
> see the other one over an IPv6 address. Onioncat supports IPv4, but in
> TAP mode I could not make it work.
> 
> I will make a docker image with the whole stuff so that you can try it
> out in one command...
> 
> I think there is a bug in the IPv6 version.
> 
> Best,

This is quite cool!

The IPv6 over link-local addresses has a few issues yes (see Zyre
ticket), I'll try to fix it the next weekend. With global addresses it
should work though.

Kind regards,
Luca Boccassi



signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Big thank you for the Hackaton and the rest

2017-02-06 Thread Luca Boccassi
On Mon, 2017-02-06 at 10:57 +0100, Benjamin Henrion wrote:
> Hi,
> 
> Just wanted to thank you all for the Hackaton and your interventions
> at the PH's inmemoriam talk, it was a great week-end. Videos will be
> online soon.
> 
> About Glar, we should rename it at some point, make a proper github
> release, and transform the tool in a more generic cluster management
> (ala clusterssh). Or if you have other ideas.
> 
> Thanks again,

Thank you for organising both!

It was great seeing you all again (or for the first time).

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ Pre-Fosdem Hackaton (Thu 2 + Fri 3 Feb 2017) at HSBXL

2017-01-31 Thread Luca Boccassi
On Tue, 2016-12-13 at 14:50 +0100, Benjamin Henrion wrote:
> Hi,
> 
> I am pleased to announce the next ZeroMQ Pre-Fosdem Hackaton (Thu 2 +
> Fri 3 Feb 2017).
> 
> ++ When?
> 
> Thu 2 and Fri 3 February 2016, from 9am to late in the night :-)
> 
> ++ Where?
> 
> Hackerspace Brussels (HSBXL)
> Rue de manchester 21 / Manchesterstraat 21
> 1080 Molenbeek
> Brussels
> Belgium
> Web: http://www.hsbxl.be
> GSM: +32 484 566109 (zoobab)
> 
> ++ Drinks and food
> 
> HSBXL has a decent bar (beers, tea, soft drinks, etc…).
> 
> For the food, bring your own, and we will order suchis, pizzas, etc…
> when needed.
> 
> ++ Agenda
> 
> libzmq on ESP8266
> malamute on openwrt and memory limitations tests
> phsh openssh replacement
> your topic here
> 
> ++ Attendees
> 
> Please do add your name to ensure a seat:
> 
> NAME surname
> HENRION Benjamin (zoobab)
> 
> ++ Links
> 
> http://zeromq.org/event:zeromq-pre-fosdem-hackaton-thu-2-fri-3-feb-2017
> 
> Best,

Hello all,

I'll be in Brussels tomorrow evening and Benjamin as well, we'll check
the venue to see how's the heating and everything else, and then we
could go for a beer!

Is anyone already there tomorrow evening that wants to join us?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] zyre + zbeacon + ipv6

2017-01-30 Thread Luca Boccassi
Hello all,

I've implemented IPv6 support in zbeacon using multicast:

https://github.com/zeromq/czmq/pull/1616
https://github.com/zeromq/czmq/pull/1615

Help testing these changes would be greatly appreciated!
I've verified it works with zpinger and ztest_beacon between a Linux
desktop, a Debian Raspberry PI 2 and a Fedora Raspberry PI 3. It would
be great if someone on OSX could give it a run as well!

Also there is a TODO for Windows in ziflist before it can work there
too, again help needed.

Please let me know what you think and if this can be useful!

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] pyzmq and curve, as server

2017-01-26 Thread Luca Boccassi
On Mon, 2016-06-13 at 08:57 -0400, Julien Kauffmann wrote:
> Hi,
> 
> I'm trying to use the CURVE mechanism with PYZMQ, following the code 
> example at 
> https://github.com/zeromq/pyzmq/blob/master/examples/security/stonehouse.py.
> 
> I created an authenticator, I generated key pairs (which work as a CURVE 
> client), set the `curve_server` flag to `True`, and finally bound the 
> socket.
> 
> However, when the REP socket tries to contact the REQ socket, a network 
> dump shows that it actually sends the `as_server` flag as `False` and 
> I'm lost as to understand why. For all intents and purpose, I'm 
> following the exact sequence done in the ironhouse sample.
> 
> Any clue what I could be missing here ? Is there any facility that could 
> help me debug this (additional logs for instance) ?
> 
> Thanks,
> 
> Julien.

I've just noticed the same, and it seems that contrary to what the RFC
says "as-server" is never used, and always set to 00:

https://github.com/zeromq/libzmq/blob/master/src/stream_engine.cpp#L562

It has been like that since the first time the RFC was implemented. The
ZMQ_CURVE_SERVER option is used to decide if a peer will be client or
server (by instantiating the corresponding curve class).

Does anyone know what was the intention there?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Updated Infiniband Benchmarks with ZMQ 2.0.6

2017-02-22 Thread Luca Boccassi
On Wed, 2017-02-22 at 17:51 +0800, zhoushan wrote:
> Hello,
> 
> 
> Is there any performance data on Intel OPA, which is a new arch of infinband?
> If not, is there any test case about zmq usage on Infinband in the github, 
> just like this
> "http://zeromq.org/results:perf-howto;?
> Thanks.
> Best Regards,
> Shan

Hi,

I'm not aware of any. But if you would like to contribute some please
send us a PR on Github and we'll merge it.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?

2017-02-19 Thread Luca Boccassi
On Sun, 2017-02-19 at 08:48 +0100, brunobodin . wrote:
> Hi Luca
> 
> Do you also plan to release a CZMQ version ?
> 
> Regards
> 
> Bruno

Could do, but there's still a couple of issues with zbeacon + ipv6
linklocal that I'd like to iron out before that. Don't want to tag the
repo with a half-working implementation, even if it's draft.

I'll have time to look at this shortly, so perhaps next week or the one
after.

> On Sat, Feb 18, 2017 at 7:15 PM, Luca Boccassi
> <luca.bocca...@gmail.com>
> wrote:
> 
> > On Fri, 2017-02-17 at 13:26 +, Luca Boccassi wrote:
> > > On Fri, 2017-02-17 at 10:32 +, simon.giese...@btc-ag.com
> > > wrote:
> > > > Hi,
> > > > 
> > > > is it possible to do publish the bugfix release 4.2.2 now? We
> > > > need
> > > > one quite urgently now.
> > > > 
> > > > Thanks a lot
> > > > Simon
> > > 
> > > Hi,
> > > 
> > > There's a few fixes queued so sounds like a good time, I'll put
> > > together
> > > a changelog and push it over the weekend.
> > > 
> > > Kind regards,
> > > Luca Boccassi
> > 
> > 4.2.2 is out: https://github.com/zeromq/libzmq/releases/tag/v4.2.2
> > 
> > > > -Ursprüngliche Nachricht-
> > > > Von: Luca Boccassi [mailto:luca.bocca...@gmail.com]
> > > > Gesendet: Dienstag, 31. Januar 2017 12:41
> > > > An: Giesecke, Simon
> > > > Cc: zeromq-dev@lists.zeromq.org
> > > > Betreff: Re: AW: [zeromq-dev] Behaviour change between 4.1.5
> > > > and
> > > > 4.2.1?
> > > > 
> > > > On Mon, 2017-01-30 at 14:18 +, simon.giese...@btc-ag.com
> > > > wrote:
> > > > > Hi again,
> > > > > 
> > > > > I was now able to do a local test with the current HEAD of
> > > > > libzmq, which seems to fix the problem again.
> > > > > 
> > > > > To do complete tests in our integration environment, I would
> > > > > require a release version. When is 4.2.2 going to be
> > > > > released? Is
> > > > > it possible to do this in the next days?
> > > > > 
> > > > > Best regards
> > > > > Simon
> > > > 
> > > > 4.2.1 was released not too long ago, so we could probably do
> > > > one
> > > > sometimes before mid February when there should be enough bug
> > > > fixes
> > > > queued up
> > > > 
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Luca Boccassi [mailto:luca.bocca...@gmail.com]
> > > > > Gesendet: Montag, 16. Januar 2017 12:26
> > > > > An: ZeroMQ development list
> > > > > Betreff: Re: [zeromq-dev] Behaviour change between 4.1.5 and
> > > > > 4.2.1?
> > > > > 
> > > > > On Mon, 2017-01-16 at 10:32 +, simon.giese...@btc-ag.com
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > we have migrated from ZeroMQ 4.1.5 to 4.2.1 recently and I
> > > > > > notice some behaviour change in some of our test cases.
> > > > > > These
> > > > > > cases are related to enforcing that some queues run full
> > > > > > resp.
> > > > > > the HWM is exceeded. Sorry I cannot be more precise at the
> > > > > > moment; I tried to reproduce the behavioural differences
> > > > > > with
> > > > > > some reduced code example, but have not been successful so
> > > > > > far.
> > > > > > To enable me to facilitate a more focused reproduction of
> > > > > > the
> > > > > > issue, I have a general question in advance. Have there
> > > > > > been
> > > > > > any deliberate changes in behaviour between 4.1.5 and 4.2.1
> > > > > > that might be related to this? From reading the release
> > > > > > notes,
> > > > > > I did not find something that raised my attention.
> > > > > > 
> > > > > > Best regards
> > > > > > Simon
> > > > > 
> > > > > One major change is that setting HWM works also after
> > > > > connecting/binding, is that what you are doing?
> > > > > 
> > > > > There were many other bug fixes that can be seen in the git
> > > > > log,
> > > > > can't
> > > > > remember all of them off the top of my head
> > > > > 
> > > > > Also what transport mode are you using?
> > > > > 
> > > > > Kind regards,
> > > > > Luca Boccassi
> > > > 
> > > > 
> > > 
> > > 
> > 
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > 
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] router socket hangs on write (was detecting dead MDP workers)

2017-02-18 Thread Luca Boccassi
On Fri, 2017-02-17 at 10:53 +0100, Gyorgy Szekely wrote:
> Hi,
> Sorry for spamming the list :( I will rate limit myself.
> 
> I reviewed the docs for ZMQ_ROUTER_MANDATORY and it's clear now that
> the
> router socket may block if the message can be routed but HWM is
> reached and
> ZMQ_DONTWAIT is not specified. This is the exact code path my
> application
> blocks in.
> 
> The problem is that HWM is not reached in my case.
> zmq::router_t::xsend()
> checks HWM with zmq::pipe_t::check_write(), which returns false, but
> not
> because HWM is reached, but beacuse pipe state is
> zmq::pipe_t::waiting_for_delimiter.
> 
> Summary:
> I don't think it's reasonable for zmq::router_t::xsend() to return -1
> EAGAIN, when the corresponding pipe is being terminated. It's obvious
> that
> the message can't be sent in the future, there's no point in
> retrying.
> 
> (For the time being, as a workaround I specify ZMQ_DONTWAIT on the
> send,
> and I consider the worker dead with either EHOTUNREACH or EAGAIN.)
> 
> What's your opinion on this?
> 
> 
> Regards,
>   Gyorgy

Is the pipe terminated when the underlying socket is disconnected? I
can't remember and I'd have to double check, but if that's the case
then it could come back, so EAGAIN would be appropriate, right?

Also the check_write just returns true/false, and given it's in the hot
path I'd be wary of overloading it to cater for a single corner case.

> On Thu, Feb 16, 2017 at 10:44 PM, Gyorgy Szekely  >
> wrote:
> 
> > Hi,
> > I dug a bit deeper, here are my findings:
> > - removing the on/off switching for the ZMQ_ROUTER_MANDATORY flag,
> > and
> > enabling it before the router socket bind: makes no difference
> > - removing the monitor trigger and heartbeating the workers
> > periodically
> > (2.5 sec) drastically reduces the occurrence rate, the program
> > hangs after
> > 3-4 hours, instead of seconds. (in the background a worker
> > connects/disconnects with 4 second period time)
> > 
> > From this I suspect the issue appears in a small timeframe which is
> > close
> > to the monitor event, but otherwise hard to hit.
> > 
> > With GDB is see the following:
> > - in zmq::socket_base_t::send() the call to xsend() returns EAGAIN.
> > This
> > should not happen since the ZMQ_DONTWAIT is not specified.
> > - ZMQ_DONTWAIT is not specified, so the function won't return -1,
> > but
> > block (see trace in prev mail).
> > 
> > - inside zmq::router_t::xsend() the pipe is found in the outpipes
> > map, but
> > the check_write() on it returns false
> > - the if(mandatory) check in this block (router.cpp:218) returns
> > with -1,
> > EAGAIN
> > - a similar block 10 lines below returns with -1, EHOSTUNREACH
> > 
> > Should both if(mandatory) checks return EHOSTUNREACH? There's also
> > a
> > comment in the header for bool mandatory, that it will report
> > EAGAIN, but
> > this contradicts with the documentation.
> > 
> > Can you help to clarify?
> > 
> > 
> > Regards,
> >   Gyorgy
> > 
> > 
> > It
> > 
> > On Thu, Feb 16, 2017 at 12:22 PM, Gyorgy Szekely  > om>
> > wrote:
> > 
> > > Hi,
> > > Continuing my journey on detecting dead workers I reduced the
> > > design to
> > > the minimal, and eliminated the messy file descriptors.
> > > I only have:
> > > - a router socket, with some number of peers
> > > - a monitor socket attached to the router socket
> > > 
> > > When the monitor detects a disconnect on the router socket:
> > > - do setsockopt(ZMQ_ROUTER_MANDATORY, 1);
> > > - send heartbeat message to every known peer
> > > - if EHOSTUNREACH returned: remove the peer
> > > - do setsockopt(ZMQ_ROUTER_MANDATORY, 0);
> > > 
> > > What happens: _my app regularly hangs_ in zmq_msg_send(). Roughly
> > > 20% of
> > > the invocations. The call never returns, I have to kill the
> > > application.
> > > 
> > > What am I doing wrong??? According to the RFC's router sockets
> > > should
> > > never block.
> > > I attached a full stacktrace with info locals and args for each
> > > relevant
> > > frame (sorry for the machine readable format).
> > > 
> > > Env:
> > > libzmq 4.2.1 stable, debug build
> > > Ubuntu 16.04 64bit (the same happens with ubuntu packaged lib)
> > > 
> > > Regards,
> > >   Gyorgy
> > > 
> > > 
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Recommended reading for writing a binding

2017-02-18 Thread Luca Boccassi
On Sat, 2017-02-18 at 19:27 +0100, Lars Wikman wrote:
> Ah, thanks, I think I bounced off of it in confusion last time I
> checked, but I'll give another look whenever I can wrench out the
> time
> for it. It might not have helped that I was neck-deep in other
> people's implementation details.
> 
> Best regards
> Lars Wikman

Also note that there are a few Erlang/Elixir implementations already:

https://github.com/chovencorp/chumak
https://github.com/zeromq/exzmq
https://github.com/zeromq/ezmq

AFAIK the first one is the most complete, and only lacks CURVE support

> On 18 February 2017 at 19:20, Luca Boccassi <luca.bocca...@gmail.com>
> wrote:
> > On Fri, 2017-02-17 at 17:04 +0100, Lars Wikman wrote:
> > > Hi
> > > 
> > > I was looking at Elixir bindings for ZeroMQ and found one or two
> > > that
> > > do
> > > not quite work. Diving into the code one seems to implement zmq
> > > as I
> > > recognize from working with pyzmq and NetMQ. Another implements
> > > things I
> > > can read about in the ZMTP RFC.
> > > 
> > > What is the sane place to start reading today if attempting to
> > > write
> > > a
> > > native implementation?
> > > 
> > > Best regards
> > > Lars Wikman
> > 
> > For a native implementation I'd say the RFCs should have everything
> > you
> > need:
> > 
> > https://rfc.zeromq.org/spec:23/ZMTP/
> > 
> > and others on the same website.
> > 
> > Also libzmtp could be a good reference since it's a minimal C
> > reference
> > implementation (not complete, lacks CURVE for example):
> > 
> > https://github.com/zeromq/libzmtp
> > 
> > Kind regards,
> > Luca Boccassi
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?

2017-02-18 Thread Luca Boccassi
On Fri, 2017-02-17 at 13:26 +, Luca Boccassi wrote:
> On Fri, 2017-02-17 at 10:32 +, simon.giese...@btc-ag.com wrote:
> > Hi,
> > 
> > is it possible to do publish the bugfix release 4.2.2 now? We need
> > one quite urgently now.
> > 
> > Thanks a lot
> > Simon
> 
> Hi,
> 
> There's a few fixes queued so sounds like a good time, I'll put
> together
> a changelog and push it over the weekend.
> 
> Kind regards,
> Luca Boccassi

4.2.2 is out: https://github.com/zeromq/libzmq/releases/tag/v4.2.2

> > -Ursprüngliche Nachricht-
> > Von: Luca Boccassi [mailto:luca.bocca...@gmail.com] 
> > Gesendet: Dienstag, 31. Januar 2017 12:41
> > An: Giesecke, Simon
> > Cc: zeromq-dev@lists.zeromq.org
> > Betreff: Re: AW: [zeromq-dev] Behaviour change between 4.1.5 and
> > 4.2.1?
> > 
> > On Mon, 2017-01-30 at 14:18 +, simon.giese...@btc-ag.com wrote:
> > > Hi again,
> > > 
> > > I was now able to do a local test with the current HEAD of
> > > libzmq, which seems to fix the problem again.
> > > 
> > > To do complete tests in our integration environment, I would
> > > require a release version. When is 4.2.2 going to be released? Is
> > > it possible to do this in the next days?
> > > 
> > > Best regards
> > > Simon
> > 
> > 4.2.1 was released not too long ago, so we could probably do one
> > sometimes before mid February when there should be enough bug fixes
> > queued up
> > 
> > > -Ursprüngliche Nachricht-
> > > Von: Luca Boccassi [mailto:luca.bocca...@gmail.com]
> > > Gesendet: Montag, 16. Januar 2017 12:26
> > > An: ZeroMQ development list
> > > Betreff: Re: [zeromq-dev] Behaviour change between 4.1.5 and
> > > 4.2.1?
> > > 
> > > On Mon, 2017-01-16 at 10:32 +, simon.giese...@btc-ag.com
> > > wrote:
> > > > Hi,
> > > > 
> > > > we have migrated from ZeroMQ 4.1.5 to 4.2.1 recently and I
> > > > notice some behaviour change in some of our test cases. These
> > > > cases are related to enforcing that some queues run full resp.
> > > > the HWM is exceeded. Sorry I cannot be more precise at the
> > > > moment; I tried to reproduce the behavioural differences with
> > > > some reduced code example, but have not been successful so far.
> > > > To enable me to facilitate a more focused reproduction of the
> > > > issue, I have a general question in advance. Have there been
> > > > any deliberate changes in behaviour between 4.1.5 and 4.2.1
> > > > that might be related to this? From reading the release notes,
> > > > I did not find something that raised my attention.
> > > > 
> > > > Best regards
> > > > Simon
> > > 
> > > One major change is that setting HWM works also after
> > > connecting/binding, is that what you are doing?
> > > 
> > > There were many other bug fixes that can be seen in the git log,
> > > can't 
> > > remember all of them off the top of my head
> > > 
> > > Also what transport mode are you using?
> > > 
> > > Kind regards,
> > > Luca Boccassi
> > 
> > 
> 
> 

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Recommended reading for writing a binding

2017-02-18 Thread Luca Boccassi
On Fri, 2017-02-17 at 17:04 +0100, Lars Wikman wrote:
> Hi
> 
> I was looking at Elixir bindings for ZeroMQ and found one or two that
> do
> not quite work. Diving into the code one seems to implement zmq as I
> recognize from working with pyzmq and NetMQ. Another implements
> things I
> can read about in the ZMTP RFC.
> 
> What is the sane place to start reading today if attempting to write
> a
> native implementation?
> 
> Best regards
> Lars Wikman

For a native implementation I'd say the RFCs should have everything you
need:

https://rfc.zeromq.org/spec:23/ZMTP/

and others on the same website.

Also libzmtp could be a good reference since it's a minimal C reference
implementation (not complete, lacks CURVE for example):

https://github.com/zeromq/libzmtp

Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Updating zguide

2017-02-14 Thread Luca Boccassi
Accepted. Thanks!

On Feb 14, 2017 09:49, "Doron Somech" <somdo...@gmail.com> wrote:

> Luca, Kevin you were invited to the api wiki. Let me know once you joined
> and I will make you admins.
>
> On Feb 14, 2017 11:03, "Doron Somech" <somdo...@gmail.com> wrote:
>
>> It is another wikidot project.
>>
>> Will try to get access to it.
>>
>> On Mon, Feb 13, 2017 at 11:40 PM, Kevin Sapper <kevinsappe...@gmail.com>
>> wrote:
>>
>>> I was able to generate and upload the latest version of the czmq api
>>> using Pieters secret Perl tools (github.com/zeromq/ztools). I can do
>>> the same for libzmq. But I'm not sure to which wiki as I don't have access
>>> to the original one? The same as czmq? I that case we need to adjust the
>>> DNS.
>>>
>>> Am 04.01.2017 08:11 schrieb "Doron Somech" <somdo...@gmail.com>:
>>>
>>>> I'm not the admin of those websites, both zguide and czmq. So we might
>>>> need to create new ones.
>>>> Because it is all generated it not much loss and I do control the DNS.
>>>>
>>>> Do you want to try and generate the docs into new wikidot site and then
>>>> I will redirect the DNS?
>>>>
>>>> On Tue, Jan 3, 2017 at 10:34 PM, Luca Boccassi <luca.bocca...@gmail.com
>>>> > wrote:
>>>>
>>>>> While on the subject of Wikidot access, could you please give myself
>>>>> (luca.boccassi) and sappo access to the CZMQ page?
>>>>>
>>>>> https://github.com/zeromq/czmq/issues/1563
>>>>> http://czmq.zeromq.org/
>>>>>
>>>>> When I try to edit I get a permission denied error
>>>>>
>>>>> On Tue, 2017-01-03 at 21:51 +0200, Doron Somech wrote:
>>>>> > Done
>>>>> >
>>>>> > On Tue, Jan 3, 2017 at 7:11 PM, Kyle Kelley <rgb...@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > > I'm rgbkrk on wikidot and my email is rgb...@gmail.com
>>>>> > >
>>>>> > > On Mon, Jan 2, 2017 at 11:26 PM, Doron Somech <somdo...@gmail.com>
>>>>> wrote:
>>>>> > > > Kevin what is your wikidot username and email?
>>>>> > > >
>>>>> > > > On Tue, Jan 3, 2017 at 12:24 AM, Kyle Kelley <rgb...@gmail.com>
>>>>> wrote:
>>>>> > > >>
>>>>> > > >> Just as an aside, in case my message went through twice -
>>>>> somehow my
>>>>> > > >> emails were getting bounced and my account was disabled. Sorry
>>>>> about
>>>>> > > >> that!
>>>>> > > >>
>>>>> > > >> On Mon, Jan 2, 2017 at 2:18 PM, Benjamin Henrion <
>>>>> zoo...@gmail.com>
>>>>> > > wrote:
>>>>> > > >> > On Mon, Jan 2, 2017 at 8:16 PM, Kevin Sapper <
>>>>> kevinsappe...@gmail.com
>>>>> > > >
>>>>> > > >> > wrote:
>>>>> > > >> >> Hi Kyle,
>>>>> > > >> >>
>>>>> > > >> >> it is a semi manual process. There a build and upload script
>>>>> in the
>>>>> > > >> >> repository that has be invoked by someone with permissions
>>>>> to the
>>>>> > > >> >> wikidot
>>>>> > > >> >> page.
>>>>> > > >> >>
>>>>> > > >> >> Who has access to the zguide wikidot? @zoobab, @bluca,
>>>>> @somdoron?
>>>>> > > >> >
>>>>> > > >> > I don't have access to it.
>>>>> > > >> >
>>>>> > > >> > Last edit is from 2013.
>>>>> > > >> >
>>>>> > > >> > --
>>>>> > > >> > Benjamin Henrion 
>>>>> > > >> > FFII Brussels - +32-484-566109 - +32-2-3500762
>>>>> > > >> > "In July 2005, after several failed attempts to legalise
>>>>> software
>>>>> > > >> > patents in Europe, the patent establishment changed its
>>>>> strategy.
>>>>> > > >> > Instead of expl

Re: [zeromq-dev] need advice! hitting assertion in epoll.cpp:131 (zmq 4.2.1) when going from RHEL6 to RHEL7?!

2017-02-16 Thread Luca Boccassi
On Thu, 2017-02-16 at 14:59 +0100, zmqdev wrote:
> Hello,
> 
> I could use some advice to diagnose the following issue.
> 
> I have a program that has been running without problems for a couple of 
> years on Red Hat Enterprise Linux 6 at various sites.
> 
> On RHEL7, the program triggers the assertion
> 
>   Bad file descriptor (src/epoll.cpp:131)
> 
> in about 1/3 of executions, during startup (sometimes during shutdown).
> 
> Less often, I see
> 
>   Bad file descriptor (src/epoll.cpp:100)
> 
> The problem persists after upgrading to ZeroMQ 4.2.1 from 4.1.6.
> 
> I don't get it!
> 
> Programming errors aside, I do check all return codes and log errors as 
> they occur in the main thread, and there is nothing until libzmq commits 
> suicide from one of its threads.
> 
> Any idea/advice on how I could track down this problem?
> 
> What makes RHEL7 different enough from RHEL6 to emerge this kind of errors?
> 
> Cheers :-(
> 
> 
> GDB BACKTRACE FROM CORE FILE:
> 
> Thread 3 (Thread 0xf736b900 (LWP 5039)):
> #0  0xf7751430 in __kernel_vsyscall ()
> #1  0xf745694b in poll () from /lib/libc.so.6
> #2  0xf6ff5457 in 
> zmq::socket_poller_t::wait(zmq::socket_poller_t::event_t*, int, long) () 
> from $TOP/lib/platform/libzmq.so.5
> #3  0xf6ff325f in zmq_poller_wait_all(void*, zmq_poller_event_t*, int, 
> long) () from $TOP/lib/platform/libzmq.so.5
> #4  0xf6ff3aa5 in zmq_poller_poll(zmq_pollitem_t*, int, long) () from 
> $TOP/lib/platform/libzmq.so.5
> #5  0xf6ff2bb1 in zmq_poll () from $TOP/lib/platform/libzmq.so.5
> #6  0xf702cec1 in zt_reactor_loop (r=) at 
> $TOP/src/reactor.c:268
> (...)
> #17 0x080487da in main ()
> 
> Thread 2 (Thread 0xf6e6db40 (LWP 5066)):
> #0  0xf7751430 in __kernel_vsyscall ()
> #1  0xf7463a16 in epoll_wait () from /lib/libc.so.6
> #2  0xf6fa17d0 in zmq::epoll_t::loop() () from $TOP/lib/platform/libzmq.so.5
> #3  0xf6fa1a35 in zmq::epoll_t::worker_routine(void*) () from 
> $TOP/lib/platform/libzmq.so.5
> #4  0xf6fe36f2 in thread_routine () from $TOP/lib/platform/libzmq.so.5
> #5  0xf7574b2c in start_thread () from /lib/libpthread.so.0
> #6  0xf746308e in clone () from /lib/libc.so.6
> 
> Thread 1 (Thread 0xf666cb40 (LWP 5067)):
> #0  0xf7751430 in __kernel_vsyscall ()
> #1  0xf739a1f7 in raise () from /lib/libc.so.6
> #2  0xf739ba33 in abort () from /lib/libc.so.6
> #3  0xf6fa2726 in zmq::zmq_abort(char const*) () from 
> $TOP/lib/platform/libzmq.so.5
> #4  0xf6fa164b in zmq::epoll_t::set_pollout(void*) () from 
> $TOP/lib/platform/libzmq.so.5
> #5  0xf6fa3951 in zmq::io_object_t::set_pollout(void*) () from 
> $TOP/lib/platform/libzmq.so.5
> #6  0xf6fdafe1 in zmq::stream_engine_t::restart_output() () from 
> $TOP/lib/platform/libzmq.so.5
> #7  0xf6fcae20 in zmq::session_base_t::read_activated(zmq::pipe_t*) () 
> from $TOP/lib/platform/libzmq.so.5
> #8  0xf6fb9dd3 in zmq::pipe_t::process_activate_read() () from 
> $TOP/lib/platform/libzmq.so.5
> #9  0xf6fb2a9e in zmq::object_t::process_command(zmq::command_t&) () 
> from $TOP/lib/platform/libzmq.so.5
> #10 0xf6fa3f77 in zmq::io_thread_t::in_event() () from 
> $TOP/lib/platform/libzmq.so.5
> #11 0xf6fa1948 in zmq::epoll_t::loop() () from $TOP/lib/platform/libzmq.so.5
> #12 0xf6fa1a35 in zmq::epoll_t::worker_routine(void*) () from 
> $TOP/lib/platform/libzmq.so.5
> #13 0xf6fe36f2 in thread_routine () from $TOP/lib/platform/libzmq.so.5
> #14 0xf7574b2c in start_thread () from /lib/libpthread.so.0
> #15 0xf746308e in clone () from /lib/libc.so.6

Are you building your own binaries in both cases?

What polling mechanism was RHEL 6 using? You can see it in
the ./configure output: "Using 'epoll' polling system"

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] need advice! hitting assertion in epoll.cpp:131 (zmq 4.2.1) when going from RHEL6 to RHEL7?!

2017-02-16 Thread Luca Boccassi
On Thu, 2017-02-16 at 15:54 +0100, zmqdev wrote:
> >
> > Are you building your own binaries in both cases?
> >
> 
> yes
> 
> > What polling mechanism was RHEL 6 using? You can see it in
> > the ./configure output: "Using 'epoll' polling system"
> 
> from config.log:
> 
>   Using 'epoll' polling system with CLOEXEC

What's the file limit on the 2 systems? (With the user that runs the
program)

ulimit -n

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?

2017-02-17 Thread Luca Boccassi
On Fri, 2017-02-17 at 10:32 +, simon.giese...@btc-ag.com wrote:
> Hi,
> 
> is it possible to do publish the bugfix release 4.2.2 now? We need one quite 
> urgently now.
> 
> Thanks a lot
> Simon

Hi,

There's a few fixes queued so sounds like a good time, I'll put together
a changelog and push it over the weekend.

Kind regards,
Luca Boccassi

> -Ursprüngliche Nachricht-----
> Von: Luca Boccassi [mailto:luca.bocca...@gmail.com] 
> Gesendet: Dienstag, 31. Januar 2017 12:41
> An: Giesecke, Simon
> Cc: zeromq-dev@lists.zeromq.org
> Betreff: Re: AW: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?
> 
> On Mon, 2017-01-30 at 14:18 +, simon.giese...@btc-ag.com wrote:
> > Hi again,
> > 
> > I was now able to do a local test with the current HEAD of libzmq, which 
> > seems to fix the problem again.
> > 
> > To do complete tests in our integration environment, I would require a 
> > release version. When is 4.2.2 going to be released? Is it possible to do 
> > this in the next days?
> > 
> > Best regards
> > Simon
> 
> 4.2.1 was released not too long ago, so we could probably do one sometimes 
> before mid February when there should be enough bug fixes queued up
> 
> > -Ursprüngliche Nachricht-
> > Von: Luca Boccassi [mailto:luca.bocca...@gmail.com]
> > Gesendet: Montag, 16. Januar 2017 12:26
> > An: ZeroMQ development list
> > Betreff: Re: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?
> > 
> > On Mon, 2017-01-16 at 10:32 +, simon.giese...@btc-ag.com wrote:
> > > Hi,
> > > 
> > > we have migrated from ZeroMQ 4.1.5 to 4.2.1 recently and I notice some 
> > > behaviour change in some of our test cases. These cases are related to 
> > > enforcing that some queues run full resp. the HWM is exceeded. Sorry I 
> > > cannot be more precise at the moment; I tried to reproduce the 
> > > behavioural differences with some reduced code example, but have not been 
> > > successful so far. To enable me to facilitate a more focused reproduction 
> > > of the issue, I have a general question in advance. Have there been any 
> > > deliberate changes in behaviour between 4.1.5 and 4.2.1 that might be 
> > > related to this? From reading the release notes, I did not find something 
> > > that raised my attention.
> > > 
> > > Best regards
> > > Simon
> > 
> > One major change is that setting HWM works also after connecting/binding, 
> > is that what you are doing?
> > 
> > There were many other bug fixes that can be seen in the git log, can't 
> > remember all of them off the top of my head
> > 
> > Also what transport mode are you using?
> > 
> > Kind regards,
> > Luca Boccassi
> 
> 


-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Behaviour change between 4.1.5 and 4.2.1?

2017-01-16 Thread Luca Boccassi
On Mon, 2017-01-16 at 10:32 +, simon.giese...@btc-ag.com wrote:
> Hi,
> 
> we have migrated from ZeroMQ 4.1.5 to 4.2.1 recently and I notice some 
> behaviour change in some of our test cases. These cases are related to 
> enforcing that some queues run full resp. the HWM is exceeded. Sorry I cannot 
> be more precise at the moment; I tried to reproduce the behavioural 
> differences with some reduced code example, but have not been successful so 
> far. To enable me to facilitate a more focused reproduction of the issue, I 
> have a general question in advance. Have there been any deliberate changes in 
> behaviour between 4.1.5 and 4.2.1 that might be related to this? From reading 
> the release notes, I did not find something that raised my attention.
> 
> Best regards
> Simon

One major change is that setting HWM works also after
connecting/binding, is that what you are doing?

There were many other bug fixes that can be seen in the git log, can't
remember all of them off the top of my head

Also what transport mode are you using?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] CZMQ: zloop_poller terminates the function handler

2017-01-17 Thread Luca Boccassi
On Tue, 2017-01-17 at 00:42 +0100, Shrikanth M.D. wrote:
> Hello All,
> 
> I have a zloop_poller invoked as below:
> zloop_poller (loop, , s_netconf_socket_event,inter_thread_pair);
> 
> 
> I see that while executing the function handles, s_netconf_socket_event, my
> program terminates.
> I have added debugs and see no obvious issues with my program.
> 
> Is there any explicit cause due to which czmq would end the handler by
> itself?
> 
> Regards,
> Shrikanth

Can you provide a code snippet that reproduces the case?


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Chumak 1.2.0 released (Erlang + Curve)

2017-02-26 Thread Luca Boccassi
On Sun, 2017-02-26 at 07:54 +, Andriy Drozdyuk wrote:
> For anyone that is interested, we added support for Curve security to
> Chumak library:
> https://github.com/chovencorp/chumak
> 
> By default it is disabled. To enable, compile with env variable set:
> CHUMAK_CURVE_LIB=nacerl ./rebar3 compile
> 
> The support is very new, and if anyone is willing to help test it, it
> would
> be a great. Contributions are, as always, welcome.
> 
> Hex package here:
> https://hex.pm/packages/chumak
> 
> Hopefully someone finds this useful.
> All  the best!


Hello Andriy,

Great news! I believe Chumak is the first Erlang implementation to
support Curve. Nice!

Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] pollset in AIX

2016-09-12 Thread Luca Boccassi
You can already choose to use it, build with "--with-poller=poll" as a
configure option

On 12 September 2016 at 15:20, 王运来  wrote:
> I have found pollset is not used in AIX 7.1 platform and I test the ZMQ with
> pollset poller. The exciting is that my program can benifit from pollset
> with about 7% performance enhencement.
> Would you like push the pollset poller in ZMQ?
>
>
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Question about zero-copying, local and remote clients

2016-09-13 Thread Luca Boccassi
If you ask for TCP, you are going to get TCP.

But you can however bind the same socket to multiple endpoints, one
IPC, one TCP, etc.

Note that "true" zero copy happens with ZMQ_PAIR sockets over
inproc:// transport. IPC uses unix file sockets, so there is at least
a write syscall and thus a copy.

On 13 September 2016 at 20:37, Mateusz Jemielity
 wrote:
> Hi,
>
>
>
> I have a question about 0MQ’s internal use of zero-copy.
>
>
>
> Suppose that I have a client-server setup using req/rep sockets that are
> sending large messages between themselves. There are multiple clients, some
> may run on the same host as the server, others are on remote hosts. All
> endpoints use tcp, so I’d have:
>
> Server: zmq_bind(server_socket, “tcp://*:5000”);
>
> Client 1 (on same host): zmq_connect(client1_socket,
> “tcp://127.0.0.1:5000”);
>
> Client 2 (on remote host): zmq_connect(client2_socket,
> “tcp://192.168.1.2:5000”);
>
>
>
> Does 0MQ somehow know that server and client 1 are on the same machine? If
> it knew, then it could, for example, use shared memory to transfer the
> messages, without actually using tcp stack.
>
> I guess I could explicitly use ipc transport for processes on same host and
> do another bind in the server, but can I do it in such kinda-generic,
> single-bind way?
>
>
>
> If 0MQ doesn’t do this internally, can I get requester’s endpoint string in
> the server? Or at least some indication of endpoint being local or remote?
> If I had the endpoint, then I could parse it for “127.0.0.1” or “localhost”,
> etc. and then set up a scheme for sending some shared memory parameters
> instead of a giant message.
>
>
>
> Finally, whetever’s the answer for req/rep, does it apply for pub/sub, etc?
>
>
>
> Regards,
>
> Mateusz
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] pollset in AIX

2016-09-13 Thread Luca Boccassi
Oh sorry, I thought poll used pollset. Please do send a PR on Github if you
have an alternative implementation and we'll merge it.

It should be straightforward to add another alternative with autotools
(look in acinclude.m4) and cmake, but if you have any doubts don't hesitate
to ask here or on IRC.

Thanks!

On Sep 13, 2016 02:48, "Laughing" <hnwyl...@126.com> wrote:

>
> Yes, of course.
> The default poller is poll in AIX and there is no pollset poller in ZMQ
> now.
> After I test ZMQ with pollset, I found it can benifit to performance. Then
> I have a suggestion pushing the code with pollset poller to ZMQ.
> It can make ZMQ become more attractive.
>
>
> At 2016-09-12 23:22:55, "Luca Boccassi" <luca.bocca...@gmail.com> wrote:
> >You can already choose to use it, build with "--with-poller=poll" as a
> >configure option
> >
> >On 12 September 2016 at 15:20, 王运来 <hnwyl...@126.com> wrote:
> >> I have found pollset is not used in AIX 7.1 platform and I test the ZMQ 
> >> with
> >> pollset poller. The exciting is that my program can benifit from pollset
> >> with about 7% performance enhencement.
> >> Would you like push the pollset poller in ZMQ?
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> zeromq-dev mailing list
> >> zeromq-dev@lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >___
> >zeromq-dev mailing list
> >zeromq-dev@lists.zeromq.org
> >http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] RPC in ZeroMQ

2016-09-24 Thread Luca Boccassi
Yes, zproto is a zeromq project, and it's on the community's github
org. I have no experience with thrift so I'm afraid I can't help with
that.

On 24 September 2016 at 18:05, Dimos Stamatakis <dimsta...@gmail.com> wrote:
> Thanks! Protobuffer is another option, indeed.
> How about zproto? Is it official by ZeroMQ?
> I would prefer Thrift with ZeroMQ since our system already uses Thrift and
> we are happy with the performance. We just want to extend it and support
> pub-sub (that's why we looked at ZeroMQ ).
>
> Thanks,
> Dimos
>
>
> On Sep 24, 2016 12:48 PM, "Luca Boccassi" <luca.bocca...@gmail.com> wrote:
>>
>> Look at zproto - it can do that and much, much more
>> https://github.com/zeromq/zproto
>>
>> On 24 September 2016 at 08:31, Dimos Stamatakis <dimsta...@gmail.com>
>> wrote:
>> > Thanks for your response. I saw zerorpc, but it seems like it does not
>> > support C++. For now I am looking at combining Thrift with zeroMQ as its
>> > communication layer.
>> >
>> > Thanks,
>> > Dimos
>> >
>> >
>> > On Sep 24, 2016 2:17 AM, "Indradhanush Gupta"
>> > <indradhanush.gu...@gmail.com>
>> > wrote:
>> >
>> >
>> >
>> > On Fri, Sep 23, 2016 at 9:25 PM, Dimos Stamatakis <dimsta...@gmail.com>
>> > wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> I was wondering if ZeroMQ supports RPC. I noticed it does not natively
>> >> support, but is there a plugin for ZeroMQ made for RPCs? Or we have to
>> >> build
>> >> our own?
>> >
>> >
>> > You can check out http://www.zerorpc.io/ although I cant vouch for it as
>> > I've never used it myself.
>> >
>> >>
>> >>
>> >> Thanks a lot,
>> >> Dimos
>> >>
>> >> ___
>> >> zeromq-dev mailing list
>> >> zeromq-dev@lists.zeromq.org
>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> >
>> >
>> > --
>> > Indradhanush Gupta
>> >
>> >
>> > ___
>> > zeromq-dev mailing list
>> > zeromq-dev@lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> >
>> > ___
>> > zeromq-dev mailing list
>> > zeromq-dev@lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] RPC in ZeroMQ

2016-09-24 Thread Luca Boccassi
Look at zproto - it can do that and much, much more
https://github.com/zeromq/zproto

On 24 September 2016 at 08:31, Dimos Stamatakis  wrote:
> Thanks for your response. I saw zerorpc, but it seems like it does not
> support C++. For now I am looking at combining Thrift with zeroMQ as its
> communication layer.
>
> Thanks,
> Dimos
>
>
> On Sep 24, 2016 2:17 AM, "Indradhanush Gupta" 
> wrote:
>
>
>
> On Fri, Sep 23, 2016 at 9:25 PM, Dimos Stamatakis 
> wrote:
>>
>> Hello everyone,
>>
>> I was wondering if ZeroMQ supports RPC. I noticed it does not natively
>> support, but is there a plugin for ZeroMQ made for RPCs? Or we have to build
>> our own?
>
>
> You can check out http://www.zerorpc.io/ although I cant vouch for it as
> I've never used it myself.
>
>>
>>
>> Thanks a lot,
>> Dimos
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
> --
> Indradhanush Gupta
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Question about context and/or socket creation

2016-09-30 Thread Luca Boccassi
You can (and probably should as best practise) reuse the context,
which is thread safe.

Do not use the same socket from multiple threads. There is a new
category of thread-safe sockets in libzmq master but the API is not
yet finalised.

On 30 September 2016 at 10:50, James Chapman  wrote:
> [apologies if you've received this twice, first send was not from my
> subscribed email address and I'm not sure it actually went to the list]
>
> Hi all,
>
> Quick question regarding the creation of contexts and sockets. Some quick
> insight:
> I have a function that gets called from a thread pool that creates a
> context, a socket, sends a REQ message and waits for a REP, after which the
> socket is closed and then deleted. If the program runs for long enough, it
> eventually crashes, the last call being in zmq.hpp (line 657)
>
> zmq::socket_t::init(zmq::context_t & context_, int type_)
> {
> ...
> ptr = zmq_socket (context_.ptr, type_ );   <--- Crash here
>
>
>
> So my question is basically, am I using contexts and sockets correctly by
> creating new instances each time I want to send a message or should I be
> re-using these as much as possible?
>
> Thanks
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Using CurveZMQ to secure multiple sockets?

2016-10-05 Thread Luca Boccassi
zauth and zcert can work with any socket and are the correct choice.
Curvezmq was a proof of concept (and made to bring auth for the legacy
libraries) and should not be used with libzmq/czmq as there's built in
support.

On 5 October 2016 at 09:27, Mark Gillott  wrote:
> Suppose we have a server and one or more client applications that
> communicate using a number of 0MQ sockets; a ROUTER-DEALER, a PUB-SUB
> and a REP-REQ.
>
> Is it possible to use CurveZMQ to secure all of these connections? Using
> the various zactor, zcert & zsock_set_curve functions I can secure the
> ROUTER-DEALER connections. But what about the other two?
>
> What I really want is to be able to do is secure the lower layer
> transport such that *any* 0MQ socket between client & server is always
> secure. From the curvezmq.org page:
>
> To secure a single hop between client and server, which is the
> CurveCP use case. For this use case we would embed CurveZMQ in
> the transport layer so that it can work for all patterns
> (publish-subscribe, pipeline, and so on).
>
> Yet I can't find any example. The examples I've seen secure a single
> socket. Have I misunderstood? Can I build a CurveZMQ-based "pipe" over
> which other 0MQ sockets can operate?
>
> Thanks,
>
> Mark
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Using CurveZMQ to secure multiple sockets?

2016-10-05 Thread Luca Boccassi
On 5 October 2016 at 16:15, Mark Gillott <mgill...@brocade.com> wrote:
> On Wed, 2016-10-05 at 14:56 +0100, Luca Boccassi wrote:
>> zauth and zcert can work with any socket and are the correct choice.
>> Curvezmq was a proof of concept (and made to bring auth for the legacy
>> libraries) and should not be used with libzmq/czmq as there's built in
>> support.
>>
>
> OK so authentication/encryption needs to be (separately) applied to
> every socket. And if some other part of the system springs up a socket
> between client & server for its own use, it has to remember to build in
> the zauth/zcert calls.
>
> Mark

Yes, it's a socket option, see the zauth self test for an example:

https://github.com/zeromq/czmq/blob/master/src/zauth.c#L661

zauth is set up first and then it can be used to (optionally) set up
domain white/black listing with zap, and the socket options are set on
each socket

>> On 5 October 2016 at 09:27, Mark Gillott <mgill...@brocade.com> wrote:
>> > Suppose we have a server and one or more client applications that
>> > communicate using a number of 0MQ sockets; a ROUTER-DEALER, a PUB-SUB
>> > and a REP-REQ.
>> >
>> > Is it possible to use CurveZMQ to secure all of these connections? Using
>> > the various zactor, zcert & zsock_set_curve functions I can secure the
>> > ROUTER-DEALER connections. But what about the other two?
>> >
>> > What I really want is to be able to do is secure the lower layer
>> > transport such that *any* 0MQ socket between client & server is always
>> > secure. From the curvezmq.org page:
>> >
>> > To secure a single hop between client and server, which is the
>> > CurveCP use case. For this use case we would embed CurveZMQ in
>> > the transport layer so that it can work for all patterns
>> > (publish-subscribe, pipeline, and so on).
>> >
>> > Yet I can't find any example. The examples I've seen secure a single
>> > socket. Have I misunderstood? Can I build a CurveZMQ-based "pipe" over
>> > which other 0MQ sockets can operate?
>> >
>> > Thanks,
>> >
>> > Mark
>> > ___
>> > zeromq-dev mailing list
>> > zeromq-dev@lists.zeromq.org
>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.zeromq.org_mailman_listinfo_zeromq-2Ddev=DQIGaQ=IL_XqQWOjubgfqINi2jTzg=jvQi-CKjLvh8eMz9WSgpXPemqlgP9vG7H0zwS3acfHk=gOqAiEHvYlTrTLGnWRWdFSR9dHwNTwB_wmYvb_WDKxM=oBgMsrha1azZ7qDvJEl-ki-0QCyO_C1hOC4Q-tDf5Q0=
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.zeromq.org_mailman_listinfo_zeromq-2Ddev=DQIGaQ=IL_XqQWOjubgfqINi2jTzg=jvQi-CKjLvh8eMz9WSgpXPemqlgP9vG7H0zwS3acfHk=gOqAiEHvYlTrTLGnWRWdFSR9dHwNTwB_wmYvb_WDKxM=oBgMsrha1azZ7qDvJEl-ki-0QCyO_C1hOC4Q-tDf5Q0=
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Simple PUB / SUB test does not work

2016-09-23 Thread Luca Boccassi
Not that strange, the connect is asynchronous, so there is absolutely
no guarantee on when it actually happens, by design.

In production, if you need synch, either use an out-of-band control
channel (eg: req-rep) or switch to XPUB, which gives you notifications
of subscribe/unsubscribe.

On 23 September 2016 at 13:16, Aurélien  <kinj...@gmail.com> wrote:
> Hi,
>
> I had to increase the "sleep" to 5 seconds and it worked.
>
> Strange !
>
> On Fri, Sep 23, 2016 at 10:00 AM, Aurélien  <kinj...@gmail.com> wrote:
>>
>> I tried with 127.0.0.1 on bind and connect functions, it didn't worked.
>>
>> I also tried on Linux (Ubuntu 16.04), same result.
>>
>> Very strange !
>>
>> On Thu, Sep 22, 2016 at 7:12 PM, Luca Boccassi <luca.bocca...@gmail.com>
>> wrote:
>>>
>>> Windows has some weirdness on the localhost I think, try to avoid the
>>> wildcard and bind and connect to 127.0.0.1
>>>
>>> On 22 September 2016 at 17:57, Aurélien  <kinj...@gmail.com> wrote:
>>> > Thank you for your replies.
>>> >
>>> > I tried with that :
>>> >
>>> > zmq::socket_t subscriber(context, ZMQ_SUB);
>>> > subscriber.connect("tcp://localhost:5563");
>>> > Sleep(1000);
>>> > subscriber.setsockopt(ZMQ_SUBSCRIBE, "A");
>>> > Sleep(1000);
>>> >
>>> > And it stiil does not work.
>>> >
>>> > I also tried with the ZMQ version 4.2.0, same result.
>>> >
>>> > I forgot to tell that I'm using the static version of ZMQ (with the
>>> > ZMQ_STATIC preprocessor variable), maybe it has something to do ?
>>> >
>>> > Thank you,
>>> >
>>> > Kin
>>> >
>>> > On Thu, Sep 22, 2016 at 6:28 PM, Dimos Stamatakis <dimsta...@gmail.com>
>>> > wrote:
>>> >>
>>> >> That's right. I remember reading this on the instructions on how to
>>> >> build
>>> >> a pub-sub system in ZeroMQ. There is limited availability, since as
>>> >> Ian said
>>> >> they wanted to build something fast and make it reliable, rather than
>>> >> building something reliable and make it fast.
>>> >>
>>> >> Dimos
>>> >>
>>> >> On Thu, Sep 22, 2016 at 12:21 PM, Colin Ingarfield
>>> >> <co...@ingarfield.com>
>>> >> wrote:
>>> >>>
>>> >>> The subscriber connect() call is asynchronous.  It's possible the
>>> >>> publish
>>> >>> messages are sent before the subscribe socket connects and
>>> >>> establishes its
>>> >>> subscription.
>>> >>>
>>> >>> Try sleeping for 100ms or so after the connect call, before the loop.
>>> >>>
>>> >>>
>>> >>> On 9/22/16 11:10 AM, Aurélien  wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> I'm trying to make a simple PUB / SUB test.
>>> >>>
>>> >>> First, I created the publisher, then the subscriber with a message to
>>> >>> subscribe.
>>> >>>
>>> >>> Second, I send some messages from the publisher and I try to retreive
>>> >>> them from the subscriber.
>>> >>>
>>> >>> The code compiles but the subscriber does not receive any data.
>>> >>>
>>> >>> My config is :
>>> >>> - Windows 7 / Visual Studio 2015
>>> >>> - Compile in /MTd (debug)
>>> >>> - ZMQ Version : 4.1.4
>>> >>>
>>> >>> Here is the code :
>>> >>>
>>> >>> #include "zhelpers.hpp"
>>> >>>
>>> >>> void TestPubSub()
>>> >>> {
>>> >>> zmq::context_t context;
>>> >>> zmq::socket_t publisher(context, ZMQ_PUB);
>>> >>> zmq_bind(publisher, "tcp://*:5563");
>>> >>>
>>> >>> zmq::socket_t subscriber(context, ZMQ_SUB);
>>> >>> subscriber.connect("tcp://localhost:5563");
>>> >>> subscriber.setsockopt(ZMQ_SUBSCRIBE, "A");
>>> >>>
>>> >>> while (1) {
>>> >>> //  Write two messages, each with an envelope and content
>>> >>> s_sen

Re: [zeromq-dev] Simple PUB / SUB test does not work

2016-09-22 Thread Luca Boccassi
Windows has some weirdness on the localhost I think, try to avoid the
wildcard and bind and connect to 127.0.0.1

On 22 September 2016 at 17:57, Aurélien   wrote:
> Thank you for your replies.
>
> I tried with that :
>
> zmq::socket_t subscriber(context, ZMQ_SUB);
> subscriber.connect("tcp://localhost:5563");
> Sleep(1000);
> subscriber.setsockopt(ZMQ_SUBSCRIBE, "A");
> Sleep(1000);
>
> And it stiil does not work.
>
> I also tried with the ZMQ version 4.2.0, same result.
>
> I forgot to tell that I'm using the static version of ZMQ (with the
> ZMQ_STATIC preprocessor variable), maybe it has something to do ?
>
> Thank you,
>
> Kin
>
> On Thu, Sep 22, 2016 at 6:28 PM, Dimos Stamatakis 
> wrote:
>>
>> That's right. I remember reading this on the instructions on how to build
>> a pub-sub system in ZeroMQ. There is limited availability, since as Ian said
>> they wanted to build something fast and make it reliable, rather than
>> building something reliable and make it fast.
>>
>> Dimos
>>
>> On Thu, Sep 22, 2016 at 12:21 PM, Colin Ingarfield 
>> wrote:
>>>
>>> The subscriber connect() call is asynchronous.  It's possible the publish
>>> messages are sent before the subscribe socket connects and establishes its
>>> subscription.
>>>
>>> Try sleeping for 100ms or so after the connect call, before the loop.
>>>
>>>
>>> On 9/22/16 11:10 AM, Aurélien  wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to make a simple PUB / SUB test.
>>>
>>> First, I created the publisher, then the subscriber with a message to
>>> subscribe.
>>>
>>> Second, I send some messages from the publisher and I try to retreive
>>> them from the subscriber.
>>>
>>> The code compiles but the subscriber does not receive any data.
>>>
>>> My config is :
>>> - Windows 7 / Visual Studio 2015
>>> - Compile in /MTd (debug)
>>> - ZMQ Version : 4.1.4
>>>
>>> Here is the code :
>>>
>>> #include "zhelpers.hpp"
>>>
>>> void TestPubSub()
>>> {
>>> zmq::context_t context;
>>> zmq::socket_t publisher(context, ZMQ_PUB);
>>> zmq_bind(publisher, "tcp://*:5563");
>>>
>>> zmq::socket_t subscriber(context, ZMQ_SUB);
>>> subscriber.connect("tcp://localhost:5563");
>>> subscriber.setsockopt(ZMQ_SUBSCRIBE, "A");
>>>
>>> while (1) {
>>> //  Write two messages, each with an envelope and content
>>> s_sendmore(publisher, "A");
>>> s_send(publisher, "We don't want to see this");
>>> s_sendmore(publisher, "B");
>>> s_send(publisher, "We would like to see this");
>>>
>>> //  Read envelope with address
>>> std::string addr = s_recv(subscriber); // block here, waiting for
>>> messages which does not come
>>> //  Read message contents
>>> std::string contents = s_recv(subscriber);
>>> }
>>> }
>>>
>>> int main(int argc, char** argv)
>>> {
>>> TestPubSub();
>>> return 0;
>>> }
>>>
>>> Can you tel me where I'm wrong ?
>>>
>>> Thank you very much,
>>>
>>> Kin
>>>
>>>
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-08-26 Thread Luca Boccassi
I've given some more thoughts and testing to the alignment issue. I can
reproduce the problem by enabling alignment checks on x86 too.

But most importantly, I think we cannot get away from bumping the ABI
with this fix, however we rearrange it, simply because applications need
to be rebuilt against the new header to be fixed. A simple rebuild of
the libzmq.so is not enough. And the way to do this is to bump the ABI
so that distros can schedule transitions and rebuilds and so on.

So the choice list is now restricted to:

1) Bump ABI
2) Revert the fix and leave everything broken on sparc64 and some
aarch64 (rpi3 seems not to be affected, must depend on the SoC flavour)

If we go with 2, we might as well get 2 birds with one stone and bump
the zmq_msg_t size to 128 as we have talked about in the past.

Doron, this would help with the new UDP based socket types right?

Pros of bumping msg size:

- we can get rid of the malloc() in the lmsg type case as all the data
will fit

Cons:

- for the vsm/cmsg type cases (for most architectures anyway) it won't
fit anymore into a single cacheline

Given all this, I'd say we should go for it.

Opinions?

On Sat, 2016-08-13 at 16:59 +0100, Luca Boccassi wrote:
> Hello,
> 
> Trying to give some thoughts again on the libzmq 4.2 release. It's
> really long overdue!
> 
> The main issue from my point of view is this change:
> 
> https://github.com/zeromq/libzmq/commit/d9fb1d36ff2008966af538f722a1f4ab158dbf64
> 
> -typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
>  +/* union here ensures correct alignment on architectures that require
> it, e.g.
>  + * SPARC
>  + */
>  +typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;
> 
> 
> This is flagged by the common ABI checkers tools as an ABI breakage
> (see: http://abi-laboratory.pro/tracker/timeline/zeromq/ ). And it makes
> sense from this point of view: if some applications on some
> architectures are broken due to wrong alignment, they would need to be
> rebuilt, and the way to ensure that is to bump the ABI "current" digit
> to make sure maintainers do a rebuild.
> 
> On the other hand, signaling an ABI breakage is a pain, and a cause of
> major churn for packagers and maintainers. It means for example a new
> package has to be created (eg: libzmq5 -> libzmq6), and a transition has
> to be started and all reverse dependencies need to be rebuilt. And if
> this is pointless for all save a few corner cases (eg SPARC64 as for
> above) it's all quite frustrating.
> 
> So we have a choice to make before we release 4.2, four possibilities as
> far as I can see:
> 
> 1) Ignore the ABI checkers and get yelled at by maintainers and
> packagers. Also the SPARC64 users will most likely NOT get their bug
> fixed
> 2) Bump ABI revision to 6 and get yelled at by maintainers and packagers
> 3) Revert the above change and postpone it to when we have a more
> generally useful reason to break ABI (bump zmq_msg_t from 64 to 128
> bytes for example, Doron?)
> 4) Try to be clever and revert the above change and use something like
> #pragma pack(8). This will fool the ABI checkers (I tried it), and given
> that typedef is only used externally to allocate the right size it
> shouldn't actually affect anything, apart from the users of SPARC64
> which should get the bugfix with this too. This is very sneaky :-)
> 
> CC'ing Lazslo, the Debian maintainer, given what we choose to do might
> result in a lot of work for him :-)
> 
> Opinions?
> 
> Kind regards,
> Luca Boccassi
> 
> On Tue, 2016-05-03 at 10:39 +0200, Pieter Hintjens wrote:
> > Hi all,
> > 
> > I'm just throwing some ideas on the table. We have a good package of
> > work on master and it's probably time to make a 4.2 release.
> > 
> > Luca has already back-ported the enable/disable draft design from
> > zproject (CZMQ et al). Yay! So we can now release stable master
> > safely, while continuing to refine and extend the draft API sections.
> > 
> > I propose:
> > 
> > - to end with the stable fork policy; this was needed years ago when
> > we had massively unstable masters. It's no longer a problem.
> > - to use the github release function for libzmq releases and deprecate
> > the separate delivery of tarballs.
> > - we aim to make a 4.2.0 rc asap, then fix any issues we get, with
> > patch releases as usual.
> > - we backport the release function to older maintained releases (4.1,
> > 3.2) so that their tarballs are provided by github instead of
> > downloads.zeromq.org.
> > 
> > Problems:
> > 
> > - this will break a few things that depend on downloads.zeromq.org. To
> > be fixed as we go.
> > - github tarballs 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-08-29 Thread Luca Boccassi
Sorry, I meant if we go with (1), not (2), we might bump the size as
well, since we are already doing another ABI-breaking change.

I agree on the solution as well.

On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens wrote:
> I'm confused between the (1) and (2) choices, and can't see where
> bumping the message size fits.
> 
> Nonetheless, I think bumping the size, fixing the alignment issues,
> and bumping the ABI version is the best solution here.
> 
> On Fri, Aug 26, 2016 at 12:33 PM, Luca Boccassi <luca.bocca...@gmail.com> 
> wrote:
> > I've given some more thoughts and testing to the alignment issue. I can
> > reproduce the problem by enabling alignment checks on x86 too.
> >
> > But most importantly, I think we cannot get away from bumping the ABI
> > with this fix, however we rearrange it, simply because applications need
> > to be rebuilt against the new header to be fixed. A simple rebuild of
> > the libzmq.so is not enough. And the way to do this is to bump the ABI
> > so that distros can schedule transitions and rebuilds and so on.
> >
> > So the choice list is now restricted to:
> >
> > 1) Bump ABI
> > 2) Revert the fix and leave everything broken on sparc64 and some
> > aarch64 (rpi3 seems not to be affected, must depend on the SoC flavour)
> >
> > If we go with 2, we might as well get 2 birds with one stone and bump
> > the zmq_msg_t size to 128 as we have talked about in the past.
> >
> > Doron, this would help with the new UDP based socket types right?
> >
> > Pros of bumping msg size:
> >
> > - we can get rid of the malloc() in the lmsg type case as all the data
> > will fit
> >
> > Cons:
> >
> > - for the vsm/cmsg type cases (for most architectures anyway) it won't
> > fit anymore into a single cacheline
> >
> > Given all this, I'd say we should go for it.
> >
> > Opinions?
> >
> > On Sat, 2016-08-13 at 16:59 +0100, Luca Boccassi wrote:
> >> Hello,
> >>
> >> Trying to give some thoughts again on the libzmq 4.2 release. It's
> >> really long overdue!
> >>
> >> The main issue from my point of view is this change:
> >>
> >> https://github.com/zeromq/libzmq/commit/d9fb1d36ff2008966af538f722a1f4ab158dbf64
> >>
> >> -typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
> >>  +/* union here ensures correct alignment on architectures that require
> >> it, e.g.
> >>  + * SPARC
> >>  + */
> >>  +typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;
> >>
> >>
> >> This is flagged by the common ABI checkers tools as an ABI breakage
> >> (see: http://abi-laboratory.pro/tracker/timeline/zeromq/ ). And it makes
> >> sense from this point of view: if some applications on some
> >> architectures are broken due to wrong alignment, they would need to be
> >> rebuilt, and the way to ensure that is to bump the ABI "current" digit
> >> to make sure maintainers do a rebuild.
> >>
> >> On the other hand, signaling an ABI breakage is a pain, and a cause of
> >> major churn for packagers and maintainers. It means for example a new
> >> package has to be created (eg: libzmq5 -> libzmq6), and a transition has
> >> to be started and all reverse dependencies need to be rebuilt. And if
> >> this is pointless for all save a few corner cases (eg SPARC64 as for
> >> above) it's all quite frustrating.
> >>
> >> So we have a choice to make before we release 4.2, four possibilities as
> >> far as I can see:
> >>
> >> 1) Ignore the ABI checkers and get yelled at by maintainers and
> >> packagers. Also the SPARC64 users will most likely NOT get their bug
> >> fixed
> >> 2) Bump ABI revision to 6 and get yelled at by maintainers and packagers
> >> 3) Revert the above change and postpone it to when we have a more
> >> generally useful reason to break ABI (bump zmq_msg_t from 64 to 128
> >> bytes for example, Doron?)
> >> 4) Try to be clever and revert the above change and use something like
> >> #pragma pack(8). This will fool the ABI checkers (I tried it), and given
> >> that typedef is only used externally to allocate the right size it
> >> shouldn't actually affect anything, apart from the users of SPARC64
> >> which should get the bugfix with this too. This is very sneaky :-)
> >>
> >> CC'ing Lazslo, the Debian maintainer, given what we choose to do might
> >> result in a lot of work for him :-)
> >>
> >

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-10-01 Thread Luca Boccassi
On Tue, 2016-09-27 at 09:41 +0300, Doron Somech wrote:
> Sorry for the late response, increasing the msg_t structure will be
> great, however this will require changing a lot of binding.

I think I remember we need it for the new socket types, is that correct?

There is a large performance penalty (intuitively due to not fitting
into a single cache line anymore, but haven't ran perf/cachegrind), and
the throughput with vsm type messages goes down by 4% (min) and 20%
(max) for TCP, and 36% (min) 38 (max) for inproc, which is quite a lot,
so we need to be sure it's worth it.

Regarding the bindings, after a quick search on the Github org, I could
only see:

https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/ffi/api.lua#L144
https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28
https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L177

Other bindings just import zmq.h. Did I miss any?

> Sorry for disappearing, baby and full time job is a lot :-), hopefully
> I'm back...

No worries, perfectly understandable :-)

> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi <luca.bocca...@gmail.com> 
> wrote:
> > Sorry, I meant if we go with (1), not (2), we might bump the size as
> > well, since we are already doing another ABI-breaking change.
> >
> > I agree on the solution as well.
> >
> > On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens wrote:
> >> I'm confused between the (1) and (2) choices, and can't see where
> >> bumping the message size fits.
> >>
> >> Nonetheless, I think bumping the size, fixing the alignment issues,
> >> and bumping the ABI version is the best solution here.
> >>
> >> On Fri, Aug 26, 2016 at 12:33 PM, Luca Boccassi <luca.bocca...@gmail.com> 
> >> wrote:
> >> > I've given some more thoughts and testing to the alignment issue. I can
> >> > reproduce the problem by enabling alignment checks on x86 too.
> >> >
> >> > But most importantly, I think we cannot get away from bumping the ABI
> >> > with this fix, however we rearrange it, simply because applications need
> >> > to be rebuilt against the new header to be fixed. A simple rebuild of
> >> > the libzmq.so is not enough. And the way to do this is to bump the ABI
> >> > so that distros can schedule transitions and rebuilds and so on.
> >> >
> >> > So the choice list is now restricted to:
> >> >
> >> > 1) Bump ABI
> >> > 2) Revert the fix and leave everything broken on sparc64 and some
> >> > aarch64 (rpi3 seems not to be affected, must depend on the SoC flavour)
> >> >
> >> > If we go with 2, we might as well get 2 birds with one stone and bump
> >> > the zmq_msg_t size to 128 as we have talked about in the past.
> >> >
> >> > Doron, this would help with the new UDP based socket types right?
> >> >
> >> > Pros of bumping msg size:
> >> >
> >> > - we can get rid of the malloc() in the lmsg type case as all the data
> >> > will fit
> >> >
> >> > Cons:
> >> >
> >> > - for the vsm/cmsg type cases (for most architectures anyway) it won't
> >> > fit anymore into a single cacheline
> >> >
> >> > Given all this, I'd say we should go for it.
> >> >
> >> > Opinions?
> >> >
> >> > On Sat, 2016-08-13 at 16:59 +0100, Luca Boccassi wrote:
> >> >> Hello,
> >> >>
> >> >> Trying to give some thoughts again on the libzmq 4.2 release. It's
> >> >> really long overdue!
> >> >>
> >> >> The main issue from my point of view is this change:
> >> >>
> >> >> https://github.com/zeromq/libzmq/commit/d9fb1d36ff2008966af538f722a1f4ab158dbf64
> >> >>
> >> >> -typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
> >> >>  +/* union here ensures correct alignment on architectures that require
> >> >> it, e.g.
> >> >>  + * SPARC
> >> >>  + */
> >> >>  +typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;
> >> >>
> >> >>
> >> >> This is flagged by the common ABI checkers tools as an ABI breakage
> >> >> (see: http://abi-laboratory.pro/tracker/timeline/zeromq/ ). And it makes
> >> >> sense from this point of view: if some applications on some
> >> >> architectures are broken due to wrong alignment, they would need to be
> >> >> rebuilt, and the way to en

[zeromq-dev] CZMQ old v2 API proposal: deprecated -> retired

2016-10-28 Thread Luca Boccassi
Hello all,

Since we are hopefully close to release libzmq 4.2, I checked what's the
API/ABI status in CZMQ master vs 3.0.2. There are a _lot_ of ABI
breakages, and a couple of API too.

Given it's been now 2 years and 2 weeks since 3.0.0 was released and the
v2 APIs were declared DEPRECATED
( https://github.com/zeromq/czmq#toc3-8224 ), I hereby propose to
declare them RETIRED as per C4.1 process and remove them from the
repository.

I thought it would have been nice to do a bugfix release first, but
API/ABI is already broken and it would be too much pain to revert all
those changes and then put them back on.

This way we bump to major version 4.0.0 and break ABI all in one fell
swoop, and minimise disruption.

Comments, objections?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-10-28 Thread Luca Boccassi
I have sent a solution for the alignment problem that solves the sigbus
problem without breaking ABI compat (plus follow-up for VC++ - sorry
Windows guys https://github.com/zeromq/libzmq/pull/2179 ).

I tested the alignment and sigbus problem on x86_64 by enabling
alignment check with:

__asm__("pushf\norl $0x4,(%rsp)\npopf");

All was fine.

I ran tests built from the zeromq4-1 repository against a shared lib
from the head of libzmq repo, and they all run fine minus the
ZMQ_REQ_CORRELATE one but that option was borken anyway.

This allows us to do a release now, and then when we are ready we can do
the ABI breakage, without blocking 4.2. Which is nice since it means it
might make it for Debian 9!

So, Doron et al, shall we do the bump this weekend?

On Thu, 2016-10-20 at 17:12 -0500, Thomas Rodgers wrote:
> I will have some time most likely the week of Nov6 (off for a week of C++
> Committee 'fun') to test different message size alternatives. I'll follow
> up with my results here for consideration the next time we are inclined to
> break the ABI compatibility :)
> 
> On Sunday, October 16, 2016, Brian Knox <bk...@digitalocean.com> wrote:
> 
> > A new stable version would definitely help me in my quest to get ZeroMQ
> > support enabled by default in rsyslog in distros.
> >
> > On Sun, Oct 16, 2016 at 2:40 PM Doron Somech <somdo...@gmail.com> wrote:
> >
> >> I say lets bump.
> >>
> >> On Oct 15, 2016 20:32, "Luca Boccassi" <luca.bocca...@gmail.com> wrote:
> >>
> >>> As Thomas said, false sharing would be a real issue with 96.
> >>>
> >>> So given a release is long due, at this point I'd say to drop this for
> >>> the moment.
> >>>
> >>> What do we do for the change to union for zmq_msg_t? Bump ABI version or
> >>> not?
> >>>
> >>> On Thu, 2016-10-06 at 09:53 +0300, Doron Somech wrote:
> >>> > No new socket type, I worked at the time on binary message type, might
> >>> > complete it sometime, but it is not urgent.
> >>> >
> >>> > If there is a lot of performance penalty we can give it up, I will
> >>> > find another solution for the Radio-Dish.
> >>> >
> >>> > What about 96 bytes? same penalty?
> >>> >
> >>> > Regarding the binding, I'm not sure.
> >>> >
> >>> > On Sat, Oct 1, 2016 at 9:14 PM, Luca Boccassi <luca.bocca...@gmail.com>
> >>> wrote:
> >>> > > On Tue, 2016-09-27 at 09:41 +0300, Doron Somech wrote:
> >>> > >> Sorry for the late response, increasing the msg_t structure will be
> >>> > >> great, however this will require changing a lot of binding.
> >>> > >
> >>> > > I think I remember we need it for the new socket types, is that
> >>> correct?
> >>> > >
> >>> > > There is a large performance penalty (intuitively due to not fitting
> >>> > > into a single cache line anymore, but haven't ran perf/cachegrind),
> >>> and
> >>> > > the throughput with vsm type messages goes down by 4% (min) and 20%
> >>> > > (max) for TCP, and 36% (min) 38 (max) for inproc, which is quite a
> >>> lot,
> >>> > > so we need to be sure it's worth it.
> >>> > >
> >>> > > Regarding the bindings, after a quick search on the Github org, I
> >>> could
> >>> > > only see:
> >>> > >
> >>> > > https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/
> >>> ffi/api.lua#L144
> >>> > > https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28
> >>> > > https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L177
> >>> > >
> >>> > > Other bindings just import zmq.h. Did I miss any?
> >>> > >
> >>> > >> Sorry for disappearing, baby and full time job is a lot :-),
> >>> hopefully
> >>> > >> I'm back...
> >>> > >
> >>> > > No worries, perfectly understandable :-)
> >>> > >
> >>> > >> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi <
> >>> luca.bocca...@gmail.com> wrote:
> >>> > >> > Sorry, I meant if we go with (1), not (2), we might bump the size
> >>> as
> >>> > >> > well, since we are already doing another ABI-breaking change.
> >>> > >> >
> >&g

Re: [zeromq-dev] zmq prebuilt for node

2016-10-29 Thread Luca Boccassi
On 29 October 2016 at 16:01, Kyle Kelley  wrote:
>> What happens if you do an npm install on debian armv7? Will it try to
>> build it?
>
> It should build it. We would create prebuilds for other architectures if we
> have access to them in CI. There was a request for 32-bit Linux builds,
> which we'd prefer to do in automation for accountability and verification,
> yet there are no available services for us to use (that we know of).

I'm really not familiar with the node ecosystem, but if debian/rpm
package builds can be useful we set up build on Suse's Open Build
Service and we have x86_32, x86_64 package builds for all distros plus
ppc64 for RHEL and arm7/arm64 for Suse:

https://build.opensuse.org/project/show/home:zeromq:git-stable

Not sure if this can be useful for you guys, if it is let me know and
I can help set it up

> On Sat, Oct 29, 2016 at 1:48 AM, Benjamin Henrion  wrote:
>>
>> On Oct 28, 2016 22:28, "Kyle Kelley"  wrote:
>> >
>> > Resurrecting an old thread to talk about node and something Pieter said:
>> >
>> > >> I'd probably aim at making this the official zmq package eventually,
>> > >> and bring it into the zeromq organization.
>> >
>> > We now have zmq-prebuilt in good shape, even to the point of being a
>> > really great project for building from source on platforms (there are
>> > binaries available for node, you can build from source). Now that it
>> > generally solves our problems for electron + zmq, we've acquired the zeromq
>> > name on npm: https://github.com/nteract/zmq-prebuilt/issues/65
>> >
>> > We generally believe in the zeromq community and ecosystem so we'd be
>> > happy to move it into the main org.
>>
>> What happens if you do an npm install on debian armv7? Will it try to
>> build it?
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
> --
> Kyle Kelley (@rgbkrk; lambdaops.com)
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq prebuilt for node

2016-10-29 Thread Luca Boccassi
Ah as Doron said, Github has a native "transfer ownership"
functionality. I was thinking of forking, but this way all the history
and existing issues and PR gets transferred too, which is nice! So I
like more Doron's suggestion.

Perhaps an easy solution is if you make myself or Doron admin on
https://github.com/nteract/zmq-prebuilt and then we transfer it to the
org and add all those users as admin on the repo.

As admin then you can rename it as you see fit. Does this sound like a
plan?

My Github handle is "bluca": https://github.com/bluca
And Doron's is "somdoron": https://github.com/somdoron

On Fri, 2016-10-28 at 19:15 -0700, Kyle Kelley wrote:
> Excellent!
> 
> We may want to make the repo name be node-zeromq. I'll leave that up to you
> -- we'll be calling it zeromq on npm (node package manager).
> 
> Will we be able to set up AppVeyor, Codecov, and Travis on the repo? It
> will likely be Lukas Geiger or myself setting that up/administrating it to
> get us started.
> 
> GitHub users:
> 
> * captainsafia
> * lgeiger
> * minrk
> * rgbkrk
> 
> 
> 
> 
> 
> On Fri, Oct 28, 2016 at 3:47 PM, Luca Boccassi <luca.bocca...@gmail.com>
> wrote:
> 
> > Great stuff!
> >
> > We'll be happy to add this to the org, unless there are any objections
> > tomorrow morning I'll create the repo with the same name. Let me know which
> > Github users should be added as admins.
> >
> > Thank you for the great work!
> >
> > On Oct 28, 2016 21:28, "Kyle Kelley" <rgb...@gmail.com> wrote:
> > >
> > > Resurrecting an old thread to talk about node and something Pieter said:
> > >
> > > >> I'd probably aim at making this the official zmq package eventually,
> > > >> and bring it into the zeromq organization.
> > >
> > > We now have zmq-prebuilt in good shape, even to the point of being a
> > really great project for building from source on platforms (there are
> > binaries available for node, you can build from source). Now that it
> > generally solves our problems for electron + zmq, we've acquired the zeromq
> > name on npm: https://github.com/nteract/zmq-prebuilt/issues/65
> > >
> > > We generally believe in the zeromq community and ecosystem so we'd be
> > happy to move it into the main org.
> > >
> > >
> > > On Thu, Feb 4, 2016 at 8:40 AM, Pieter Hintjens <p...@imatix.com> wrote:
> > >>
> > >> Neat, that's what we want.
> > >>
> > >> On Thu, Feb 4, 2016 at 5:12 PM, Kyle Kelley <rgb...@gmail.com> wrote:
> > >> >> How does prebuild differ from node-pre-gyp?
> > >> >
> > >> > prebuild lets you upload to GitHub for releases whereas node-pre-gyp
> > expects
> > >> > you to push releases to S3. It appears that the builds from prebuild
> > are
> > >> > compatible with node-pre-gyp
> > >> > (https://github.com/mafintosh/prebuild#building). I'm still learning
> > about
> > >> > how to work with native node packages, I'm no expert here.
> > >> >
> > >> >> How do you make an "official" package so that npm knows where to
> > find it?
> > >> >
> > >> > Once you have an npm account and have run `npm login`, from a base
> > package
> > >> > (where you've defined a package.json), you can run `npm publish` and
> > it will
> > >> > push it to the registry. That's a little light on details, this
> > article is a
> > >> > better intro: https://docs.npmjs.com/getting-started/publishing-
> > npm-packages
> > >> >
> > >> > Thus far I've only published dummies with zmq-prebuilt.
> > >> >
> > >> >
> > >> >
> > >> > On Thu, Feb 4, 2016 at 2:59 AM, Pieter Hintjens <p...@imatix.com>
> > wrote:
> > >> >>
> > >> >> I've two questions:
> > >> >>
> > >> >> - How does prebuild differ from node-pre-gyp?
> > >> >>
> > >> >> - How do you make an "official" package so that npm knows where to
> > find
> > >> >> it?
> > >> >>
> > >> >> I'd probably aim at making this the official zmq package eventually,
> > >> >> and bring it into the zeromq organization.
> > >> >>
> > >> >> On Thu, Feb 4, 2016 at 8:12 AM, Kyle Kelley <rgb...@gmail.com>
> > wrote:
> &g

Re: [zeromq-dev] zmq prebuilt for node

2016-10-29 Thread Luca Boccassi
Just seen that Doron beat me to it and added you to the org, that's
even easier probably! As I wrote on the issue on your repo you can
choose to either transfer the existing repo or fork it.

Let us know if there are any issues. Welcome to the org and thanks again!

On 29 October 2016 at 12:43, Luca Boccassi <luca.bocca...@gmail.com> wrote:
> Ah as Doron said, Github has a native "transfer ownership"
> functionality. I was thinking of forking, but this way all the history
> and existing issues and PR gets transferred too, which is nice! So I
> like more Doron's suggestion.
>
> Perhaps an easy solution is if you make myself or Doron admin on
> https://github.com/nteract/zmq-prebuilt and then we transfer it to the
> org and add all those users as admin on the repo.
>
> As admin then you can rename it as you see fit. Does this sound like a
> plan?
>
> My Github handle is "bluca": https://github.com/bluca
> And Doron's is "somdoron": https://github.com/somdoron
>
> On Fri, 2016-10-28 at 19:15 -0700, Kyle Kelley wrote:
>> Excellent!
>>
>> We may want to make the repo name be node-zeromq. I'll leave that up to you
>> -- we'll be calling it zeromq on npm (node package manager).
>>
>> Will we be able to set up AppVeyor, Codecov, and Travis on the repo? It
>> will likely be Lukas Geiger or myself setting that up/administrating it to
>> get us started.
>>
>> GitHub users:
>>
>> * captainsafia
>> * lgeiger
>> * minrk
>> * rgbkrk
>>
>>
>>
>>
>>
>> On Fri, Oct 28, 2016 at 3:47 PM, Luca Boccassi <luca.bocca...@gmail.com>
>> wrote:
>>
>> > Great stuff!
>> >
>> > We'll be happy to add this to the org, unless there are any objections
>> > tomorrow morning I'll create the repo with the same name. Let me know which
>> > Github users should be added as admins.
>> >
>> > Thank you for the great work!
>> >
>> > On Oct 28, 2016 21:28, "Kyle Kelley" <rgb...@gmail.com> wrote:
>> > >
>> > > Resurrecting an old thread to talk about node and something Pieter said:
>> > >
>> > > >> I'd probably aim at making this the official zmq package eventually,
>> > > >> and bring it into the zeromq organization.
>> > >
>> > > We now have zmq-prebuilt in good shape, even to the point of being a
>> > really great project for building from source on platforms (there are
>> > binaries available for node, you can build from source). Now that it
>> > generally solves our problems for electron + zmq, we've acquired the zeromq
>> > name on npm: https://github.com/nteract/zmq-prebuilt/issues/65
>> > >
>> > > We generally believe in the zeromq community and ecosystem so we'd be
>> > happy to move it into the main org.
>> > >
>> > >
>> > > On Thu, Feb 4, 2016 at 8:40 AM, Pieter Hintjens <p...@imatix.com> wrote:
>> > >>
>> > >> Neat, that's what we want.
>> > >>
>> > >> On Thu, Feb 4, 2016 at 5:12 PM, Kyle Kelley <rgb...@gmail.com> wrote:
>> > >> >> How does prebuild differ from node-pre-gyp?
>> > >> >
>> > >> > prebuild lets you upload to GitHub for releases whereas node-pre-gyp
>> > expects
>> > >> > you to push releases to S3. It appears that the builds from prebuild
>> > are
>> > >> > compatible with node-pre-gyp
>> > >> > (https://github.com/mafintosh/prebuild#building). I'm still learning
>> > about
>> > >> > how to work with native node packages, I'm no expert here.
>> > >> >
>> > >> >> How do you make an "official" package so that npm knows where to
>> > find it?
>> > >> >
>> > >> > Once you have an npm account and have run `npm login`, from a base
>> > package
>> > >> > (where you've defined a package.json), you can run `npm publish` and
>> > it will
>> > >> > push it to the registry. That's a little light on details, this
>> > article is a
>> > >> > better intro: https://docs.npmjs.com/getting-started/publishing-
>> > npm-packages
>> > >> >
>> > >> > Thus far I've only published dummies with zmq-prebuilt.
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Thu, Feb 4, 2016 at 2:59 AM, Pieter Hintjens <p...@imatix.com>
>

Re: [zeromq-dev] Recommended libsodium version for ZeroMQ

2016-10-30 Thread Luca Boccassi
Latest stable release of sodium will work fine with both, at Kevin says we
have CI for it.

Other than CZMQ bindings, pyzmq also supports 4.2 just fine

On Oct 30, 2016 11:03, "Ahmad Zawawi"  wrote:

> Hi Kevin,
>
> Thanks for your reply. I am working on https://github.com/azawawi/
> SwiftyZeroMQ and was wondering which of the scripting languages have the
> most complete and up-to-date implementation that depends on libzmq (i.e.
> 4.1 and 4.2). Since I am bundling at the moment libzmq 4.1 with libsodium,
> I was wondering whether to use the latest stable libsodium (i.e. 1.0.11) or
> another version for 4.1 and 4.2 respectively.
>
> Regards,
> Ahmad
>
> 2016-10-30 12:26 GMT+02:00 Kevin Sapper :
>
>> Hi Ahmad,
>> we CI test against latest master thus 4.2 should be fine. Regarding the
>> language binding I recommend libzmq+czmq. There are a couple of bindings
>> for czmq as well e.g. Java, Ruby, Python...
>>
>> //Kevin
>>
>> Am 30.10.2016 9:51 vorm. schrieb "Ahmad Zawawi" :
>>
>>> Hi,
>>>
>>> What is the recommended libsodium library version for 4.1 and 4.2? Also
>>> which language binding is the most updated and complete for 4.2 so far?
>>>
>>> Regards,
>>> Ahmad
>>>
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] No documentation for sockets options ZMQ_SOCKS_PROXY and ZMQ_BLOCKY

2016-11-07 Thread Luca Boccassi
On Mon, 2016-11-07 at 11:37 +0100, Peter Kleiweg wrote:
> Peter Kleiweg schreef op de 7e dag van de slachtmaand van het jaar 2016:
> 
> > 
> > Of the new socket options mentioned in the release notes for 
> > ZeroMQ 4.2, the options ZMQ_SOCKS_PROXY and ZMQ_BLOCKY are not 
> > documented in either zmq-getsockopt or zmq-setsockopt.
> > 
> > Should I ignore these?
> > 
> > (I'm updating Go bindings zmq4 for version 4.2)
> 
> But there is a context option ZMQ_BLOCKY, not a socket option. 

Yes good spot, that's a mistake from me when compiling the release
notes, sorry about that.

I've fixed it now.

I've also opened an issue for the lack of documentation of
ZMQ_SOCKS_PROXY.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] No manpage for zmq_curve_public

2016-11-07 Thread Luca Boccassi
On Mon, 2016-11-07 at 09:16 +0100, Peter Kleiweg wrote:
> The release notes for ZMQ 4.2 mentions the new function 
> zmq_curve_public. This function is undocumented. Is it save to 
> use it anyway?

Yes it should be added to the doc, fair point.

It is safe and the implementation uses, as everything else
crypto-related, libsodium or tweetnacl depending on the configure flags.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-11-08 Thread Luca Boccassi
I have updated the page for libzmq, but I do not have permissions to
edit the CZMQ one.

Doron, may I please get permissions so I can update:

http://czmq.zeromq.org/page:get-the-software

On Sat, 2016-11-05 at 10:14 +0100, Michal Vyskocil wrote:
> Hi,
> 
> No problem, I know this is a lot of work.
> 
> drafts sound even better than forks.
> 
> Btw I love first changelog entry
> 
> Michal
> 
> Dne 5. 11. 2016 10:02 napsal uživatel "Luca Boccassi" <
> luca.bocca...@gmail.com>:
> 
> > Hi,
> >
> > I will update the website later tonight or tomorrow, I've been
> > travelling so it's a bit hectic :-)
> >
> > Yes we discussed this a while ago, and thanks to the DRAFT APIs
> > mechanism we can now stay on the same repository. Any unstable API will
> > simply not be available unless enabled at build time. This way we get
> > all the bug fixes without having to backport and when a new API is ready
> > we mark it stable and enable it.
> >
> > On Sat, 2016-11-05 at 09:42 +0100, Michal Vyskocil wrote:
> > > Hi,
> > >
> > > great work!
> > >
> > > I noticed the zeromq.org download page
> > > http://zeromq.org/intro:get-the-software hasn't been updated yet.
> > >
> > > I also found out that the 4.2.0 release was tagged in libzmq
> > > repository instead of zeromq4-2 fork. Does it means that zeromq
> > > project is moving away from fork model for releases? Or it's just for
> > > a zero release?
> > >
> > > Bye
> > > Michal
> > >
> > > On Sat, Nov 5, 2016 at 8:44 AM, Luca Boccassi <luca.bocca...@gmail.com>
> > wrote:
> > > > Final status update:
> > > >
> > > > CZMQ 4.0.0 is out, announcement has been sent:
> > > >
> > > > https://github.com/zeromq/czmq/releases/tag/v4.0.0
> > > >
> > > > What a ride :-)
> > > >
> > > > libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the
> > > > very quick upload!), now I hope I can get CZMQ 4.0.0 up too by
> > tomorrow.
> > > >
> > > > On Fri, 2016-11-04 at 13:35 +, Luca Boccassi wrote:
> > > >> Status update:
> > > >>
> > > >> CZMQ release notes PR is open:
> > > >>
> > > >> https://github.com/zeromq/czmq/pull/1542
> > > >>
> > > >> I will be travelling now until the evening (might have some time at
> > > >> airport), so if you have anything to add please merge and send a new
> > > >> PR :-)
> > > >> I would like to release v4.0.0 tonight, so that I can (barely!) make
> > it
> > > >> for Debian 9 transition freeze. Phew!
> > > >>
> > > >> On Fri, 2016-11-04 at 10:46 +, Luca Boccassi wrote:
> > > >> > Status update:
> > > >> >
> > > >> > libzmq 4.2.0 is out! Email sent to the announce list.
> > > >> >
> > > >> > https://github.com/zeromq/libzmq/releases/tag/v4.2.0
> > > >> >
> > > >> > CZMQ is next!
> > > >> >
> > > >> > On Fri, 2016-11-04 at 09:52 +, Luca Boccassi wrote:
> > > >> > > Status update:
> > > >> > >
> > > >> > > Added missing CTX option to CZMQ, retired more deprecated methods
> > that
> > > >> > > are in STABLE classes.
> > > >> > >
> > > >> > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!),
> > still
> > > >> > > waiting for someone to merge:
> > > >> > >
> > > >> > > https://github.com/zeromq/libzmq/pull/2189
> > > >> > >
> > > >> > >
> > > >> > > On 3 November 2016 at 09:34, Luca Boccassi <
> > luca.bocca...@gmail.com> wrote:
> > > >> > > > Status update:
> > > >> > > >
> > > >> > > > I've added all the missing options to CZMQ (check please!), and
> > I prepared
> > > >> > > > the release notes for libzmq 4.2, waiting for a merge:
> > > >> > > >
> > > >> > > > https://github.com/zeromq/libzmq/pull/2189
> > > >> > > >
> > > >> > > > Anything else we should mention?
> > > >> > > >
> > > >> > > >
> > > >> > > &

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-11-10 Thread Luca Boccassi
Final status update (hopefully!), CZMQ 4.0.1 is now out:

https://github.com/zeromq/czmq/releases/tag/v4.0.1

Apologies for the troubles with the draft system, it should be now all
right.

On Tue, 2016-11-08 at 17:33 +, Luca Boccassi wrote:
> Further status update:
> 
> I found out that the implementation of the DRAFT APIs build mechanism in
> zproject/czmq had a bug, and the DRAFT symbols were leaked as global in
> the shared library even when DRAFT APIs are disabled (note that libzmq
> is fine due to the differences between C and C++).
> 
> I fixed this now for *nix (help from Windows MS VC++ experts would be
> appreciated!):
> 
> https://github.com/zeromq/czmq/pull/1549/files
> https://github.com/zeromq/czmq/pull/1550/files
> 
> I consider this bad enough to warrant a bugfix release, before it causes
> troubles for distributions. I patched it manually in Debian before
> kicking off the transition libczmq3 -> libczmq4.
> 
> If there are no objections I intend to push CZMQ 4.0.1 tomorrow. Then we
> can breath for a while :-)
> 
> On Sat, 2016-11-05 at 07:44 +, Luca Boccassi wrote:
> > Final status update:
> > 
> > CZMQ 4.0.0 is out, announcement has been sent:
> > 
> > https://github.com/zeromq/czmq/releases/tag/v4.0.0
> > 
> > What a ride :-)
> > 
> > libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the
> > very quick upload!), now I hope I can get CZMQ 4.0.0 up too by tomorrow.
> > 
> > On Fri, 2016-11-04 at 13:35 +, Luca Boccassi wrote:
> > > Status update:
> > > 
> > > CZMQ release notes PR is open:
> > > 
> > > https://github.com/zeromq/czmq/pull/1542
> > > 
> > > I will be travelling now until the evening (might have some time at
> > > airport), so if you have anything to add please merge and send a new
> > > PR :-)
> > > I would like to release v4.0.0 tonight, so that I can (barely!) make it
> > > for Debian 9 transition freeze. Phew!
> > > 
> > > On Fri, 2016-11-04 at 10:46 +, Luca Boccassi wrote:
> > > > Status update:
> > > > 
> > > > libzmq 4.2.0 is out! Email sent to the announce list.
> > > > 
> > > > https://github.com/zeromq/libzmq/releases/tag/v4.2.0
> > > > 
> > > > CZMQ is next!
> > > > 
> > > > On Fri, 2016-11-04 at 09:52 +, Luca Boccassi wrote:
> > > > > Status update:
> > > > > 
> > > > > Added missing CTX option to CZMQ, retired more deprecated methods that
> > > > > are in STABLE classes.
> > > > > 
> > > > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!), still
> > > > > waiting for someone to merge:
> > > > > 
> > > > > https://github.com/zeromq/libzmq/pull/2189
> > > > > 
> > > > > 
> > > > > On 3 November 2016 at 09:34, Luca Boccassi <luca.bocca...@gmail.com> 
> > > > > wrote:
> > > > > > Status update:
> > > > > >
> > > > > > I've added all the missing options to CZMQ (check please!), and I 
> > > > > > prepared
> > > > > > the release notes for libzmq 4.2, waiting for a merge:
> > > > > >
> > > > > > https://github.com/zeromq/libzmq/pull/2189
> > > > > >
> > > > > > Anything else we should mention?
> > > > > >
> > > > > >
> > > > > > On Nov 1, 2016 21:33, "Luca Boccassi" <luca.bocca...@gmail.com> 
> > > > > > wrote:
> > > > > >>
> > > > > >> Status update:
> > > > > >>
> > > > > >> libzmq 4.1.6, libzmq 4.2.0-rc1 and czmq 4.0.0-rc1 are out on 
> > > > > >> Github:
> > > > > >>
> > > > > >> https://github.com/zeromq/zeromq4-1/releases/tag/v4.1.6
> > > > > >> https://github.com/zeromq/libzmq/releases/tag/v4.2.0-rc1
> > > > > >> https://github.com/zeromq/czmq/releases/tag/v4.0.0-rc1
> > > > > >>
> > > > > >> I'll send an email to the announce list shortly. As I wrote earlier
> > > > > >> I'll work to have proper release notes for the stable releases.
> > > > > >>
> > > > > >> Unless there are any objections, I'm aiming to push libzmq 4.2.0
> > > > > >> stable tomorrow by the end of the day, and czmq th

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-11-05 Thread Luca Boccassi
Final status update:

CZMQ 4.0.0 is out, announcement has been sent:

https://github.com/zeromq/czmq/releases/tag/v4.0.0

What a ride :-)

libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the
very quick upload!), now I hope I can get CZMQ 4.0.0 up too by tomorrow.

On Fri, 2016-11-04 at 13:35 +, Luca Boccassi wrote:
> Status update:
> 
> CZMQ release notes PR is open:
> 
> https://github.com/zeromq/czmq/pull/1542
> 
> I will be travelling now until the evening (might have some time at
> airport), so if you have anything to add please merge and send a new
> PR :-)
> I would like to release v4.0.0 tonight, so that I can (barely!) make it
> for Debian 9 transition freeze. Phew!
> 
> On Fri, 2016-11-04 at 10:46 +, Luca Boccassi wrote:
> > Status update:
> > 
> > libzmq 4.2.0 is out! Email sent to the announce list.
> > 
> > https://github.com/zeromq/libzmq/releases/tag/v4.2.0
> > 
> > CZMQ is next!
> > 
> > On Fri, 2016-11-04 at 09:52 +, Luca Boccassi wrote:
> > > Status update:
> > > 
> > > Added missing CTX option to CZMQ, retired more deprecated methods that
> > > are in STABLE classes.
> > > 
> > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!), still
> > > waiting for someone to merge:
> > > 
> > > https://github.com/zeromq/libzmq/pull/2189
> > > 
> > > 
> > > On 3 November 2016 at 09:34, Luca Boccassi <luca.bocca...@gmail.com> 
> > > wrote:
> > > > Status update:
> > > >
> > > > I've added all the missing options to CZMQ (check please!), and I 
> > > > prepared
> > > > the release notes for libzmq 4.2, waiting for a merge:
> > > >
> > > > https://github.com/zeromq/libzmq/pull/2189
> > > >
> > > > Anything else we should mention?
> > > >
> > > >
> > > > On Nov 1, 2016 21:33, "Luca Boccassi" <luca.bocca...@gmail.com> wrote:
> > > >>
> > > >> Status update:
> > > >>
> > > >> libzmq 4.1.6, libzmq 4.2.0-rc1 and czmq 4.0.0-rc1 are out on Github:
> > > >>
> > > >> https://github.com/zeromq/zeromq4-1/releases/tag/v4.1.6
> > > >> https://github.com/zeromq/libzmq/releases/tag/v4.2.0-rc1
> > > >> https://github.com/zeromq/czmq/releases/tag/v4.0.0-rc1
> > > >>
> > > >> I'll send an email to the announce list shortly. As I wrote earlier
> > > >> I'll work to have proper release notes for the stable releases.
> > > >>
> > > >> Unless there are any objections, I'm aiming to push libzmq 4.2.0
> > > >> stable tomorrow by the end of the day, and czmq the day after.
> > > >>
> > > >> It's an aggressive schedule, but I would _really_ like to get CZMQ
> > > >> 4.0.0 in Debian and the transition freeze date is Saturday (ABI/API is
> > > >> borken so there needs to be a transition), and for that I need libzmq
> > > >> up before it.
> > > >>
> > > >> Any objections?
> > > >>
> > > >> I've also noticed that not all the libzmq socket options are available
> > > >> in CZMQ, so this gives me some time to fix that.
> > > >>
> > > >>
> > > >> On 1 November 2016 at 14:48, Doron Somech <somdo...@gmail.com> wrote:
> > > >> > Great news!
> > > >> >
> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> > > >> > <luca.bocca...@gmail.com>
> > > >> > wrote:
> > > >> >>
> > > >> >> Status update:
> > > >> >>
> > > >> >> - v2 APIs are gone from CZMQ:
> > > >> >>   https://github.com/zeromq/czmq/pull/1531
> > > >> >>   https://github.com/zeromq/czmq/pull/1532
> > > >> >> - PR is out to bump the libtool version and changelog for libzmq:
> > > >> >>   https://github.com/zeromq/libzmq/pull/2184
> > > >> >> - PR is out to backport the zmq_msg_t fix to 4.1:
> > > >> >>   https://github.com/zeromq/zeromq4-1/pull/155
> > > >> >>
> > > >> >> Once it's all merged I will tag 4.2.0~rc1 first, then release 4.1.6
> > > >> >> from
> > > >> >> zeromq4-1 since quite a few fixes have accumulated. Then I'll send 
> > > >> >>

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

2016-11-05 Thread Luca Boccassi
Hi,

I will update the website later tonight or tomorrow, I've been
travelling so it's a bit hectic :-)

Yes we discussed this a while ago, and thanks to the DRAFT APIs
mechanism we can now stay on the same repository. Any unstable API will
simply not be available unless enabled at build time. This way we get
all the bug fixes without having to backport and when a new API is ready
we mark it stable and enable it.

On Sat, 2016-11-05 at 09:42 +0100, Michal Vyskocil wrote:
> Hi,
> 
> great work!
> 
> I noticed the zeromq.org download page
> http://zeromq.org/intro:get-the-software hasn't been updated yet.
> 
> I also found out that the 4.2.0 release was tagged in libzmq
> repository instead of zeromq4-2 fork. Does it means that zeromq
> project is moving away from fork model for releases? Or it's just for
> a zero release?
> 
> Bye
> Michal
> 
> On Sat, Nov 5, 2016 at 8:44 AM, Luca Boccassi <luca.bocca...@gmail.com> wrote:
> > Final status update:
> >
> > CZMQ 4.0.0 is out, announcement has been sent:
> >
> > https://github.com/zeromq/czmq/releases/tag/v4.0.0
> >
> > What a ride :-)
> >
> > libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the
> > very quick upload!), now I hope I can get CZMQ 4.0.0 up too by tomorrow.
> >
> > On Fri, 2016-11-04 at 13:35 +, Luca Boccassi wrote:
> >> Status update:
> >>
> >> CZMQ release notes PR is open:
> >>
> >> https://github.com/zeromq/czmq/pull/1542
> >>
> >> I will be travelling now until the evening (might have some time at
> >> airport), so if you have anything to add please merge and send a new
> >> PR :-)
> >> I would like to release v4.0.0 tonight, so that I can (barely!) make it
> >> for Debian 9 transition freeze. Phew!
> >>
> >> On Fri, 2016-11-04 at 10:46 +, Luca Boccassi wrote:
> >> > Status update:
> >> >
> >> > libzmq 4.2.0 is out! Email sent to the announce list.
> >> >
> >> > https://github.com/zeromq/libzmq/releases/tag/v4.2.0
> >> >
> >> > CZMQ is next!
> >> >
> >> > On Fri, 2016-11-04 at 09:52 +, Luca Boccassi wrote:
> >> > > Status update:
> >> > >
> >> > > Added missing CTX option to CZMQ, retired more deprecated methods that
> >> > > are in STABLE classes.
> >> > >
> >> > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!), still
> >> > > waiting for someone to merge:
> >> > >
> >> > > https://github.com/zeromq/libzmq/pull/2189
> >> > >
> >> > >
> >> > > On 3 November 2016 at 09:34, Luca Boccassi <luca.bocca...@gmail.com> 
> >> > > wrote:
> >> > > > Status update:
> >> > > >
> >> > > > I've added all the missing options to CZMQ (check please!), and I 
> >> > > > prepared
> >> > > > the release notes for libzmq 4.2, waiting for a merge:
> >> > > >
> >> > > > https://github.com/zeromq/libzmq/pull/2189
> >> > > >
> >> > > > Anything else we should mention?
> >> > > >
> >> > > >
> >> > > > On Nov 1, 2016 21:33, "Luca Boccassi" <luca.bocca...@gmail.com> 
> >> > > > wrote:
> >> > > >>
> >> > > >> Status update:
> >> > > >>
> >> > > >> libzmq 4.1.6, libzmq 4.2.0-rc1 and czmq 4.0.0-rc1 are out on Github:
> >> > > >>
> >> > > >> https://github.com/zeromq/zeromq4-1/releases/tag/v4.1.6
> >> > > >> https://github.com/zeromq/libzmq/releases/tag/v4.2.0-rc1
> >> > > >> https://github.com/zeromq/czmq/releases/tag/v4.0.0-rc1
> >> > > >>
> >> > > >> I'll send an email to the announce list shortly. As I wrote earlier
> >> > > >> I'll work to have proper release notes for the stable releases.
> >> > > >>
> >> > > >> Unless there are any objections, I'm aiming to push libzmq 4.2.0
> >> > > >> stable tomorrow by the end of the day, and czmq the day after.
> >> > > >>
> >> > > >> It's an aggressive schedule, but I would _really_ like to get CZMQ
> >> > > >> 4.0.0 in Debian and the transition freeze date is Saturday (ABI/API 
> >> > > >> is
> >&g

Re: [zeromq-dev] ZeroMQ 4.1.5 runtime crash on iOS 10 SDK

2016-10-25 Thread Luca Boccassi
Hi,

I think the build system it's already doing the right thing, which is to
check if running on an apple system and if so, if the syscall is
available or not and define it if needed.

You said you built for IOS 10 and ran on IOS 9: if I understand
correctly and the syscalls support is different between those 2 version,
then that's your problem, you need to build against the right target as
they are not compatible.

On Tue, 2016-10-25 at 12:12 +0300, Ahmad Zawawi wrote:
> Thanks for your reply. It seems so. Please see the curl / iOS 10 discussion
> in the link that I sent earlier. Meanwhile, I made a workaround to patch
> src/platform.hpp after the configure stage (
> https://github.com/azawawi/libzmq-ios/blob/master/platform-patched.hpp#L11).
> Unit tests are now working after this change on iOS 8 and 9 simulators
> (Build log: https://travis-ci.org/azawawi/SwiftyZeroMQ/jobs/170303450).
> 
> Also I saw this commit to add an implementation for it in the 4.2 branch (
> https://github.com/zeromq/libzmq/commit/a8f11b3c3d719c1c248f64933862c913111dded8).
> The crash was occurring in the zmq::clock_t::now_us function.
> 
> Regards,
> Ahmad
> 
> 2016-10-25 6:26 GMT+03:00 Laughing :
> 
> > There is no clock_gettime API in the IOS platform?
> > Or some library should be linked?
> >
> >
> >
> >
> >
> > On 10/24/2016 16:34, Ahmad Zawawi  wrote:
> >
> > Hi,
> >
> > I encountered today a clock_gettime run time crash while testing on iOS
> > 9.0 and earlier using a libzmq.a that is compiled on an iOS 10.0 SDK. The
> > Swift language bindings for iOS (https://github.com/azawawi/SwiftyZeroMQ)
> > is currently using a bundled universal libzmq.a (https://github.com/
> > drewcrawford/libzmq-ios). When I enabled Travis CI tests on iOS 9 and
> > earlier, the tests started to fail with the error "dyld: lazy symbol
> > binding failed: Symbol not found: _clock_gettime" (libSystem.dylib). Tests
> > are working perfectly on iOS 10. The problem seems to be similar to
> > https://curl.haxx.se/mail/lib-2016-09/0043.html.
> >
> > Is there a way to disable clock_gettime detection via the configure shell
> > script?
> >
> > Regards,
> > Ahmad M. Zawawi
> >
> >
> >
> >
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Zmq 4.2.0 aligned memory

2016-11-14 Thread Luca Boccassi
On Mon, 2016-11-14 at 16:48 +0100, Emmanuel Taurel wrote:
> Hello all,
> 
> We are using zeromq since years now without troubles. We have recently
> tried our software using Zmq 4.2.0 (on linux hosts).
> For our application, we are using multipart messages with 4 parts in
> publish/subscribe mode.
> With Zmq 4.0.5, on the subscriber side, when we get the last message
> part, the received buffer was memory aligned
> (at least on 0x4 border). Unfortunately, with Zmq 4.2.0, the buffer is
> not aligned any more.
>  For instance with Zmq 4.0.5, the buffer was at address xxx08 while with
> Zmq 4.2.0, it is at address xxx23.
> 
> I don't know if it is relevant but our messages are relatively small
> messages (few tens of bytes)
> This is a problem for us in decoding the buffer content.
> 
> Is there something to be done to have memory aligned buffers?
> 
> Thank's in advance for your answers
> 
>  Emmanuel

Hi,

Since 4.0.5 a couple things have changed externally:

- zmq_msg_t has increased to 64 bytes from 32 bytes

- zmq_msg_t is now aligned to pointer size, to fix SIGBUS crashes on
some architectures

Exactly how large are your payloads?

It's possible that before they didn't fit in the inline buffer, since it
was really small, but they do now and that means they are not aligned
anymore since the inline buffer is not the first element of the struct:

struct {
   metadata_t *metadata;
   unsigned char data [max_vsm_size];
   unsigned char size;
   unsigned char type;
   unsigned char flags;
   char group [16];
   uint32_t routing_id;
} vsm;

Although an xxx23 address is a bit strange. In theory it should be
aligned to ptr size + 8.

If they are bigger than the very small size and they end up on the heap,
then the content_t is not aligned at all:

struct content_t
{
void *data;
size_t size;
msg_free_fn *ffn;
void *hint;
zmq::atomic_counter_t refcnt;
};

You could try to add the alignment attribute there in src/msg.hpp and
see if it makes a difference for you.


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What is the canonical handling of zeromq sockets when fork+exec?

2016-11-26 Thread Luca Boccassi
On Fri, 2016-11-25 at 12:22 +0100, zmqdev wrote:
> On 25.11.2016 11:50, Luca Boccassi wrote:
> > What I can say is that we have a unit test for this situation:
> >
> > https://github.com/zeromq/libzmq/blob/master/tests/test_fork.cpp
> >
> > And the child closes the (TCP) socket explicitly before the context.
> > Which is in fact what should happen in all cases.
> >
> > The parent then can receive messages on the sockets just fine.
> >
> > Maybe it's a linger issue? By default a socket has 30s of linger grace
> > period.
> >
> > Try setting ZMQ_LINGER to 0 in the socket in the child, close the socket
> > and then terminate the context perhaps.
> 
> thanks. Formatted differently:
> 
>   1. zmq_close sockets in child (perhaps setting ZMQ_LINGER to 0 
> beforehand)
>   2. zmq_term context in child
> 
> and only then
> 
>   3. close rest of file descriptors in child
> 
> The reason I went directly to point 3 is this line from the man page of 
> fork(2):
> 
>  The child process is created with a single thread—the one
>  that called fork().
> 
> (see http://man7.org/linux/man-pages/man2/fork.2.html)
> 
> Michael Kerrisk in "The Linux Programming Interface" insists:
> 
>  When a multithreaded process calls fork(), only the calling thread is
>  replicated in the child process. (The ID of the thread in the child 
> is the
>  same as the ID of the thread that called fork() in the parent.) All 
> of the
>  other threads vanish in the child; no thread-specific data 
> destructors or
>  cleanup handlers are executed for those threads.
>  (...)
> 
> Of course, that's where I run into the problem?!

Yes I suspect the background I/O thread suddenly going missing might
have caused issues.

Did setting the linger and closing the socket help?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Call for maintainers [JeroMQ, JZMQ]

2016-11-26 Thread Luca Boccassi
Hi Colin,

Being a ZeroMQ maintainer is easy and fun and I definitely recommend
it :-)

The actual maintainer role is well codified in the C4 process that
Trevor mentioned and it's very simple in the end.

And if you have used the library for a long time I'm sure you'll do a
great job developing it further.

So if you are interested let us know and we can add you as a maintainer
in the organization.

Thanks!

On Tue, 2016-11-22 at 11:20 -0400, Trevor Bernard wrote:
> Colin,
> 
> You can read about the responsibilities in the C4 contract:
> https://rfc.zeromq.org/spec:42/C4.
> 
> -Trev
> 
> On Mon, Nov 21, 2016 at 8:09 AM, Colin Ingarfield  
> wrote:
> > Hi Trevor,
> >
> > I've been a user of jeromq for several years.  I might be interested in
> > maintaining it, but can you describe some more what would be required?
> > I'm a professional java developer and feel I have a good understanding
> > of jeromq, but I don't know its internals that well.
> >
> > Thanks,
> > Colin
> >
> > On 11/20/16 2:53 PM, Trevor Bernard wrote:
> >> Hi all,
> >>
> >> I've been happily the steward for ZeroMQ on the JVM for many years now
> >> but unfortunately, I don't have the time or energy to give these
> >> projects the attention they needs. I'm looking for someone to step up
> >> and take over managing the releases to Maven Central. I will help
> >> ensure a smooth transition but I will unfortunately take an indefinite
> >> leave from jzmq/jeromq. It's been a blast but it's time to move on.
> >>
> >> Warmest regards,
> >> Trevor
> >> ___
> >> zeromq-dev mailing list
> >> zeromq-dev@lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-11-24 Thread Luca Boccassi
ation it contained, not the format, to no avail.
> At the time, (and even now) it felt to me like a betrayal of the C4 tenets, 
> but lets not get into religious wars here.
> 
> I can tell you that in my professional work, I have brought down my company's 
> main product from 10 crashes/DAY/user to 0.5 crashes/MONTH/user by iterating 
> on generating these minidumps, asking the users to send them in, analyzing 
> them and fixing the problems they brought to our attention, so this is proven 
> technology.
> 
> If the community feels that this is a good idea (add a Windows specific code 
> to generate minidumps when exceptions happen), I would love to invest the 
> time to this effort.
> 
> 
> On Mon, Nov 14, 2016 at 1:30 PM Aaron Friesen 
> <afrie...@spirae.com<mailto:afrie...@spirae.com>> wrote:
> All,
> 
> Getting an SEHException 0x80004005 from ZeroMQ (4.1.0.21) / libzmq (4.1.5.0)
> 
> Multiple processes went down with the same exception at the same time.
> 
> Was not able to get a dump but the application logs showed the following 
> stack trace:
> 
> System.Exception System.Runtime.InteropServices.SEHException (0x80004005): 
> External component has thrown an exception.
> at ZeroMQ.lib.zmq.zmq_msg_send(IntPtr msg, IntPtr socket, Int32 flags)
> at ZeroMQ.ZSocket.SendFrame(ZFrame frame, ZSocketFlags flags, ZError& error)
> at ZeroMQ.ZSocket.SendFrames(IEnumerable`1 frames, Int32& sent, ZSocketFlags 
> flags, ZError& error)
> at ZeroMQ.ZSocket.SendFrames(IEnumerable`1 frames, ZSocketFlags flags, 
> ZError& error)
> at ZeroMQ.ZSocket.SendMessage(ZMessage msg, ZSocketFlags flags, ZError& error)
> at ZeroMQ.ZSocket.SendMessage(ZMessage msg, ZSocketFlags flags)
> at ZeroMQ.ZSocket.SendMessage(ZMessage msg)
> at xx.SocketsThread(Object eventWaitHandle)
> 
> No line numbers available, but based on the logged message, it would have 
> occurred in the following code.  Because the stack trace does not include any 
> of the calls within the try block (PollIn, ProcessRequest, 
> ProcessSubscription), I am at a loss as to what exactly was executing at the 
> time of the exception that was calling SendMessage.
> 
> Does anyone have any ideas as to what I might be doing wrong, or what the 
> problem might be and how to avoid it?
> 
> 
> 
> ZSocket[] sockets = new ZSocket[] { _requestSocket, 
> _subscriberSocket };
> ZPollItem[] pollItems = new ZPollItem[] { 
> ZPollItem.CreateReceiver(), ZPollItem.CreateReceiver() };
> ZMessage[] messages = null;
> 
> try
> {
> TimeSpan timeout = TimeSpan.FromMilliseconds(100);
> 
> while (_run)
> {
> if (ZPollItems.PollIn(sockets, pollItems, out 
> messages, out error, timeout))
> {
> if (error == ZError.EAGAIN)
> continue;
> 
> if (error == ZError.ETERM)
> break;
> 
> if (messages == null)
> continue;
> 
> if (messages[0] != null)// Request
> ProcessRequest(messages[0]);
> 
> if (messages[1] != null)// Subscription
> ProcessSubscription(messages[1]);
> }
> else
> {
> if (error == ZError.EAGAIN)
> continue;
> 
> if (error != ZError.None)
> break;
> }
> }
> }
> catch (Exception ex)
> {
> if (!(ex is ThreadAbortException))
> {
> _logger.FatalException(string.Format("Exception 
> encountered while polling for messages on sockets. Thread '{0}' shutting 
> down.", threadName), ex);
> 
> Environment.Exit(-1);
> }
> }
> 
> Thank you in advance,
> 
> Aaron Friesen
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org<mailto:zeromq-dev@lists.zeromq.org>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What is the canonical handling of zeromq sockets when fork+exec?

2016-11-25 Thread Luca Boccassi
On Fri, 2016-11-25 at 10:37 +0100, zmqdev wrote:
> * Background
> 
> I have a service that starts workers on demand with fork+exec.
> The requests arrive over zeromq sockets.
> 
> After the fork, before the exec, I close all file descriptors > 2, 
> keeping only stdin/out/err. I then exec the requested program.
> 
> 
> * Problem
> 
> It works. Except that I get some rare core dumps (of the service) with 
> the following assertion failure:
> 
>   Bad file descriptor (src/epoll.cpp:90)
> 
> and the backtrace:
> 
>  #0  0xf77f5430 in __kernel_vsyscall ()
>  #1  0xf743f1f7 in raise () from /lib/libc.so.6
>  #2  0xf7440a33 in abort () from /lib/libc.so.6
>  #3  0xf7067134 in zmq::zmq_abort(char const*) () from $LIBS/libzmq.so.5
>  #4  0xf7065e6c in zmq::epoll_t::rm_fd(void*) () from $LIBS/libzmq.so.5
>  #5  0xf7068823 in zmq::io_object_t::rm_fd(void*) () from 
> $LIBS/libzmq.so.5
>  #6  0xf70958af in zmq::stream_engine_t::unplug() () from 
> $LIBS/libzmq.so.5
>  #7  0xf7098711 in 
> zmq::stream_engine_t::error(zmq::stream_engine_t::error_reason_t) () 
> from $LIBS/libzmq.so.5
>  #8  0xf7098867 in zmq::stream_engine_t::timer_event(int) () from 
> $LIBS/libzmq.so.5
>  #9  0xf707f972 in zmq::poller_base_t::execute_timers() () from 
> $LIBS/libzmq.so.5
>  #10 0xf7066209 in zmq::epoll_t::loop() () from $LIBS/libzmq.so.5
>  #11 0xf7066467 in zmq::epoll_t::worker_routine(void*) () from 
> $LIBS/libzmq.so.5
>  #12 0xf709d67e in thread_routine () from $LIBS/libzmq.so.5
>  #13 0xf7619b2c in start_thread () from /lib/libpthread.so.0
>  #14 0xf750808e in clone () from /lib/libc.so.6
> 
> This is with zeromq-4.1.4 on RHEL 7.3 x86_64.
> 
> So I wonder: is there some interaction between parent and child?
> 
> 
> * Documentation
> 
> The Guide and the FAQ do not address explicitly the fork+exec point.
> 
> The question has been asked several times on the mailing list in various 
> forms, without a definitive answer (for dummies like me at least).
> 
> 
> * Questions:
> 
> Do I need to zmq_close the sockets in the child?
> Or is zmq_term in the child enough?
> Does closing the file descriptors in the child cause problems in the parent?
> 
> What is the correct way to handle this?

Hi,

I have not dealt with this case personally, so perhaps other folks who
have can chip in.

What I can say is that we have a unit test for this situation:

https://github.com/zeromq/libzmq/blob/master/tests/test_fork.cpp

And the child closes the (TCP) socket explicitly before the context.
Which is in fact what should happen in all cases.

The parent then can receive messages on the sockets just fine.

Maybe it's a linger issue? By default a socket has 30s of linger grace
period.

Try setting ZMQ_LINGER to 0 in the socket in the child, close the socket
and then terminate the context perhaps.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] On hooking memory allocations

2016-11-28 Thread Luca Boccassi
That would work for an internal API, but given we expose a C API
unfortunately I don't think that would work as a public API :-( And I
think for this use case they would require a public API.

As an external API, a new zmq_ctx_set that takes a callback would have
been ideal, but it only takes int. So perhaps a new
zmq_ctx_set_allocator that takes a callback pointer would be the next
best.

An alternative would be to have a system similar to what we use for the
poll implementation (epoll kqueue select etc), but this would be a
build-time option, and the implementation would have to be checked in,
which I don't think is an option for this case, right?

On Mon, 2016-11-28 at 10:51 +, Auer, Jens wrote:
> Hi,
> 
> I am just a user, but I would love to see this change. I have thinking about 
> this and I would like to be able to pass a C++ allocator object to ZeroMQ, so 
> a simple function hook is not enough. My idea is to define a struct in the 
> interface
> 
> struct allocator_t
> {
> void* hint;
> void* (allocate)(size_t, void*);
> void (deallocate)(void*, size_t, void*);
> };
> 
> and store this in the context object. Since I don't think that this should be 
> changed during runtime, I would create a new zmq_ctx_new overload which takes 
> a parameter of type allocator_t. The default value would be to call 
> malloc/free.
> 
> Cheers,
> Jens
> 
> --
> Jens Auer | CGI | Software-Engineer
> CGI (Germany) GmbH & Co. KG
> Rheinstraße 95 | 64295 Darmstadt | Germany
> T: +49 6151 36860 154
> jens.a...@cgi.com
> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter 
> de.cgi.com/pflichtangaben.
> 
> CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI 
> Group Inc. and its affiliates may be contained in this message. If you are 
> not a recipient indicated or intended in this message (or responsible for 
> delivery of this message to such person), or you think for any reason that 
> this message may have been addressed to you in error, you may not use or copy 
> or deliver this message to anyone else. In such case, you should destroy this 
> message and are asked to notify the sender by reply e-mail.
> 
> Von: zeromq-dev [zeromq-dev-boun...@lists.zeromq.org]" im Auftrag von 
> "Petteri Salo [petteri.s...@gmail.com]
> Gesendet: Montag, 28. November 2016 09:40
> An: zeromq-dev@lists.zeromq.org
> Betreff: [zeromq-dev] On hooking memory allocations
> 
> Hello,
> 
> Let me first do a little introduction as I'm new to this list. I'm a software 
> engineer with 15+ years of experience working on games at a company called 
> Remedy Entertainment Ltd. We've done games for PC, and various games consoles 
> over the years. Most recently we did Quantum Break for Xbox One.
> 
> I've now been tasked with evaluating ZeroMQ. One important feature of any 
> library we use in games is the ability to hook all memory allocations - this 
> is to allow the use of custom memory allocators and/or for tracking when and 
> where memory is allocated.
> 
> I've searched the libzmq source code and there is about 150 uses of new, 
> malloc, realloc , etc.
> 
> If we were to adopt libzmq we'd like to put in allocation hooks and that work 
> would then be something that we'd like to contribute back to the project. 
> Having those hooks in the main repository would then make it easier for us to 
> adopt future changes to the library.
> 
> So, my question is would this kind of change be something that would be 
> accepted? Of course assuming that coding conventions, proper way of 
> submitting the patch etc. are followed. I do realize that one would want to 
> see the actual code before accepting. I'm interested in the principle of 
> accepting a change such as this, since it would introduce a new "rule" for 
> working ión libzmq source code : "All allocations shall go through an 
> allocation hook."
> 
> Best Regards,
> 
> Petteri Salo
> 
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] No UDP broadcast message received using CZMQ zbeacon on RaspberryPi3

2016-11-28 Thread Luca Boccassi
Hi,

There is a CZMQ 4.0.x series now, loads of changes have gone in since
3.0.2. I would recommend trying it as the first thing.

https://github.com/zeromq/czmq/releases

On Mon, 2016-11-28 at 12:42 -0200, Rodrigo Madruga wrote:
> Hello all,
> 
> I am developing a system that uses CZMQ's zbeacon (broadcast on UDP) for
> app discovery. Beacon sender is Windows box and receiver is RaspberryPi3.
> 
> As the subject says, no message is reaching the zbeacon actor.
> 
> Using czmq3.0.2 and zmq4.1.6 built directly on pi to rule out
> cross-compiling issues.
> 
> Calling just zbeacon_test() returns "OK" without assertions errors.
> 
> Broadcast messages are indeed reaching the pi, as shown by tcpdump:
> 
> pi@raspberrypi:~ $ sudo tcpdump udp port 5670
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 262144
> bytes
> 13:33:56.203230 IP [REDACTED].5670 > 192.168.1.255.5670: UDP, length 22
> 13:34:01.072476 IP [REDACTED].5670 > 192.168.1.255.5670: UDP, length 22
> 
> The code used to test is based on zbeacon_test function:
> 
> zactor_t *listener = zactor_new (zbeacon, NULL);
> assert (listener);
> zsock_send (listener, "si", "CONFIGURE", 5670);
> hostname = zstr_recv (listener);
> assert (*hostname);
> free (hostname);
> 
> zsock_send (listener, "sb", "SUBSCRIBE", "", 0);
> 
> zpoller_t *poller = zpoller_new (listener, NULL);
> assert (poller);
> int64_t stop_at = zclock_mono () + 1; // wait 10 seconds
> while (zclock_mono () < stop_at) {
> long timeout = (long) (stop_at - zclock_mono ());
> if (timeout < 0)
> timeout = 0;
> void *which = zpoller_wait (poller, timeout * ZMQ_POLL_MSEC);
> if (which) {
> char *ipaddress, *received;
> zstr_recvx (which, , , NULL);
> printf("From address %s:%s\n", ipaddress, received);
> zstr_free ();
> zstr_free ();
> }
> }
> zpoller_destroy ();
> 
> //  Stop listening
> zstr_sendx (listener, "UNSUBSCRIBE", NULL);
> 
> //  Destroy the test nodes
> zactor_destroy ();
> 
> I cross-compiled a simple Qt app with a QUdpSocket (below) and the messages
> were received without issues:
> 
> #include 
> 
> TestUDP::TestUDP(QObject *parent) :
> QObject(parent)
> {
> qDebug() << "Binding UDP Socket";
> socket = new QUdpSocket(this);
> socket->bind(QHostAddress::Any, 5670);
> connect(socket, ::readyRead,this, ::readyRead);
> qDebug() << "Ready Read signal connected0, waiting for broadcasts";
> }
> 
> void TestUDP::readyRead(){
> QByteArray buffer;
> buffer.resize(socket->pendingDatagramSize());
> //var to store headers from udp
> QHostAddress sender;
> quint16 sender_port;
> socket->readDatagram(buffer.data(),buffer.size(), ,
> _port);
> qDebug() << "Message from " << sender << " port " << sender_port;
> qDebug() << "Msg: " << buffer;
> }
> 
> Maybe the problem is at the way zbeacon is dealing with the UDP socket...
> 
> Has anyone successfully used a zbeacon on RPI3?
> 
> Thanks in advance!
> 
> Rodrigo Madruga.
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] On hooking memory allocations

2016-11-28 Thread Luca Boccassi
Hello,

First of all, welcome to the community! Sounds like you have a very
interesting use case :-)

So there is precedent for using some sort of a custom allocator,
although it does not go as far as your requirements:

https://github.com/zeromq/czmq/blob/master/include/czmq_prelude.h#L528

So no objections in principle I think.

Regarding what can get merged and what can't, we use the C4 process as
defined here:

https://rfc.zeromq.org/spec:42/C4/

Basically any correct patch that doesn't break (too much) stuff can be
accepted :-)

I would recommend, following C4, to start sending PRs as soon as you
can, with small changes. We have a DRAFT api process, where new stuff is
hidden behind a --enable-drafts configure call. I would recommend making
as much as possible of this new feature hidden behind the flag, as to
avoid disrupting existing users (we know many users build straight from
the master branch head).

For example, and it's up to you so it's just a suggestion of course, you
could start by changing all the mallocs to a common function sort of
like czmq does, which without --enable-drafts is just an inline static
that calls malloc. And then implement the logic, public and private as
draft (this way you can change the public interface as much as you want
until it's table). Then we can iterate from that.

Again it's entirely up to you. But we've used this model in the past
year to successfully introduce big changes without major disruption (eg:
new sockets, new poller, etc).

On Mon, 2016-11-28 at 10:40 +0200, Petteri Salo wrote:
> Hello,
> 
> Let me first do a little introduction as I'm new to this list. I'm a
> software engineer with 15+ years of experience working on games at a
> company called Remedy Entertainment Ltd. We've done games for PC, and
> various games consoles over the years. Most recently we did Quantum Break
> for Xbox One.
> 
> I've now been tasked with evaluating ZeroMQ. One important feature of any
> library we use in games is the ability to hook all memory allocations -
> this is to allow the use of custom memory allocators and/or for tracking
> when and where memory is allocated.
> 
> I've searched the libzmq source code and there is about 150 uses of new,
> malloc, realloc , etc.
> 
> If we were to adopt libzmq we'd like to put in allocation hooks and that
> work would then be something that we'd like to contribute back to the
> project. Having those hooks in the main repository would then make it
> easier for us to adopt future changes to the library.
> 
> So, my question is would this kind of change be something that would be
> accepted? Of course assuming that coding conventions, proper way of
> submitting the patch etc. are followed. I do realize that one would want to
> see the actual code before accepting. I'm interested in the principle of
> accepting a change such as this, since it would introduce a new "rule" for
> working ión libzmq source code : "All allocations shall go through an
> allocation hook."
> 
> Best Regards,
> 
> Petteri Salo
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Zmq 4.2.0 aligned memory

2016-11-17 Thread Luca Boccassi
Hi,

I agree, I am not aware of any promise in the documentation about
alignment of receive buffers (happy to be disproved of course). Proof of
this is the fact that there was no explicit alignment set, and it was
left to chance.

IMHO any application that relied on this internal undocumented side
effect should be fixed. I'm sorry if this causes troubles for the
involved developers/maintainers, but we had no way to know.

On Tue, 2016-11-15 at 09:32 +, Auer, Jens wrote:
> Hi,
> 
> I don’t think there was an explicit description or guarantee of alignment of 
> the message buffer. The implementation guaranteed this because every payload 
> was malloced for large messages and thus aligned. However, for me a void* 
> indicates that it is binary blob of n bytes with unknown alignment.
> 
> Cheers,
> Jens
> 
> --
> Dr. Jens Auer | CGI | Software Engineer
> CGI Deutschland Ltd. & Co. KG
> Rheinstraße 95 | 64295 Darmstadt | Germany
> T: +49 6151 36860 154
> jens.a...@cgi.com
> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter 
> de.cgi.com/pflichtangaben.
> 
> CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI 
> Group Inc. and its affiliates may be contained in this message. If you are 
> not a recipient indicated or intended in this message (or responsible for 
> delivery of this message to such person), or you think for any reason that 
> this message may have been addressed to you in error, you may not use or copy 
> or deliver this message to anyone else. In such case, you should destroy this 
> message and are asked to notify the sender by reply e-mail.
> 
> From: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of 
> KIU Shueng Chuan
> Sent: 15 November 2016 03:57
> To: ZeroMQ development list
> Subject: Re: [zeromq-dev] Zmq 4.2.0 aligned memory
> 
> 
> A common use case for me is sending an array of floats.
> 
> First message part is some small metadata. Second message part is the float 
> array.
> 
> On reception, zmq_msg_data is cast to float* and accessed directly.
> 
> This non-alignment would be problematic.
> Or perhaps there never was any alignment guarantee?
> 
> On 15 Nov 2016 3:34 a.m., "Jens Auer" 
> > wrote:
> Hi,
> 
> I think I have an idea why you are seeing unaligned messages, but this only 
> applies to messages where the payload is not stored in the msg_t object 
> itself. I think the threshold for this is 64 bytes. In ZeroMQ 4.1, receiving 
> messages was done by first receiving from the socket into a static 8kb 
> buffer, and then a new message object was created that allocated memory 
> externally by calling malloc.  The payload was then copied from the receive 
> buffer to the message buffer. The malloced message buffer was aligned 
> probably.
> 
> In ZeroMQ 4.2, this is changed to reduce the number of malloc calls and copy 
> operations. The receive buffer is now dynamically allocated as a 8kb block, 
> and messages are constructed as zero-copy messages using the part of the 
> receive buffer containing the payload. This saves malloc calls and copy 
> operations and increases performance. However, the payload may now start at 
> basically arbitrary addresses. As an example, let's assume that we receive a 
> small message of 10 bytes and a large message of 1kb, both received in a 
> single call to recv on the socket. The engine allocates a new buffer of 8kb, 
> calls recv(socket, buffer) and the data is written to the buffer. A small 
> message is then created which contains the data from byte 2-11 in the msg_t, 
> byte 1 contains the header. At byte 12 starts the header of the next message, 
> and at byte 22(?) starts the payload. The large message is created as a 
> zero-copy message using the pointer to byte 22 as storage. This is not 
> aligned to a 4-byte address.
> 
> Could you provide some more information about the sizes of the messages that 
> you receive? How do you decode the buffer content?
> 
> Best wishes,
> Jens
> 
> -Ursprüngliche Nachricht-
> Von: zeromq-dev 
> [mailto:zeromq-dev-boun...@lists.zeromq.org]
>  Im Auftrag von Emmanuel Taurel
> Gesendet: Montag, 14. November 2016 16:49
> An: zeromq-dev@lists.zeromq.org
> Betreff: [zeromq-dev] Zmq 4.2.0 aligned memory
> 
> Hello all,
> 
> We are using zeromq since years now without troubles. We have recently tried 
> our software using Zmq 4.2.0 (on linux hosts).
> For our application, we are using multipart messages with 4 parts in 
> publish/subscribe mode.
> With Zmq 4.0.5, on the subscriber side, when we get the last message part, 
> the received buffer was memory aligned (at least on 0x4 border). 
> Unfortunately, with Zmq 4.2.0, the buffer is not aligned any more.
>  For instance with Zmq 4.0.5, the buffer was at address xxx08 while with 

  1   2   3   4   >