Re: [zeromq-dev] New ZeroMQ website and help needed

[Brian Knox via zeromq-dev]

This is looking really great Doron! I'm cleaning up some things in
preparation for a new GoCZMQ release. Once I get in support for the new Go
modules dependency management, I'll set aside some time for add a section
for GoCZMQ on the site. I can commit to having it to you no later than next
Sunday if that works for you?

On Sun, Jun 16, 2019 at 8:06 AM Doron Somech  wrote:

> Hi All,
>
> I'm working on a new website for zeromq, you can check it out here:
>
> https://new.zeromq.org/
>
> The website Github repository:
>
> https://github.com/zeromq/zeromq.org
>
> The website is almost ready, help is needed with the language pages. If
> you are using one of the following languages (or any other) with zeromq and
> want to contribute please make a pull request:
> Java (jzmq or JeroMQ), Go, Python (pyzmq), Ruby, Scala, NodeJS, Rust,
> Haskell, Erlang, F#.
>
> Once the language pages will be ready I will make the switch, the current
> website will become wiki.zeromq.org.
>
> Doron
>
>
> ___
> 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

Re: [zeromq-dev] Unsubscribe

[Brian Knox via zeromq-dev]

Glad you're sticking around Osiris! I haven't contributed much myself in
the last while - goczmq has stabilized and doesn't need much work, and at
work I moved into a management position and that transition took all my
time and energy for awhile.

Now I'm learning Rust and working on a czmq binding for it (
https://gitlab.com/taotetek/czmq-rs) so I'll be around more. I'm glad
you're staying :)

Brian

On Thu, Sep 27, 2018 at 7:49 AM Osiris Pedroso  wrote:

> Ok, dirty laundry has been cleaned, I feel loved again. 😍
> Please keep me in the mail list
>
>  I'll set a goal to make another attempt.
> Hopefully I'll have something to show by the time February rolls by.
>
> PS: Luca, I no longer have that file. Thanks for the offer.
>
> On Thu, Sep 27, 2018, 12:48 Luca Boccassi  wrote:
>
>> On Thu, 2018-09-27 at 06:18 +0200, Osiris Pedroso wrote:
>> > Yes, I am sad to say so.
>> > The problem is that I never really contributed.
>>
>> Computer says yes :-)
>>
>> bluca@precision:~/git/libzmq (master)$ git log --author=Osiris --oneline
>> | wc -l
>> 13
>>
>> > I did attempt once in the very beginning when I naively wrote a
>> > Windows
>> > Office document detailing how to get and build the several ZeroMQ
>> > projects
>> > in the Windows environment, but my PR was rejected because it
>> > contained a
>> > file in a DOC format. I remember I spent a day working on it, making
>> > sure
>> > it was correct and looked good. I was very proud of my first
>> > submission...
>>
>> We talked about this last year - I'm truly sorry you felt that way, but
>> again the issue is purely technical and was simply about the file being
>> in binary format, which wreaks havoc in git (every time you change even
>> one character the file is duplicated in the history, so pretty soon the
>> repository size explodes). It's not just .doc - it's any non-text file
>> format that can't be accepted in a git repo. Once added, it's forever
>> +X MBs in size, and it can never go down.
>>
>> We talked about of adding a link in the README, and have the file
>> hosted elsewhere instead (cloud office 365 I think? Or the wiki? Can't
>> recall) to avoid this issue, and you seemed to appreciate the idea at
>> the time if I remember correctly?
>>
>> Would you like to send a PR to get this added?
>>
>> > Even though the C4 guidelines, which ZeroMQ projects are supposed to
>> > adhere, say nothing of restricting Windows related contributions,
>> > that in
>> > fact seems to me is what happens. Even though most questions on the
>> > mailing
>> > list seem to come from Windows users, the ZeroMQ developers as a
>> > group seem
>> > to be Windows bigots.
>> >
>> > I always wanted to work on Linux, but my career was such that I
>> > stayed in
>> > Windows for over 30 years (my first 4 years were using AT&T Unix
>> > System V,
>> > a precursor even to BSD, then Windows).
>> >
>> > The last couple of years I've watched the mailing list.
>> > Last Hackathon I wanted to do something significant. One of the
>> > projects
>> > Luca Bocassi said we're of interest was using AF sockets in Windows
>> > 10, now
>> > that this is available. I looked at it, and at the time it was only
>> > available on a Window Dev build (it is probably available in Windows
>> > 10
>> > mainstream now).
>> > Bottom line, I did not get anywhere. Plus I had the feeling that if I
>> > were
>> > to ask any questions it would not be well received by the group,.
>> > This
>> > discouraged me to pursue it any further.
>> >
>> > This year my life has changed quite a bit.
>> > I have moved to Nürnberg, Germany working for a database company. In
>> > addition to starting a new job in a new country, I am learning German
>> > which
>> > takes all of my free time. And since this company products are Linux
>> > based,
>> > I am re-learning how to develop in this environment.
>> >
>> > Funny that now when it would be much cheaper to attend the
>> > Hackathons, I
>> > have decided that my contributions are not worth it.
>> >
>> > Now that Microsoft embraced Open Source, making tools such as VSCode
>> > (the
>> > Windows Development IDE) available as Open Source in all platforms
>> > (Linux,
>> > MacOS, Windows), it would be a great thing if ZeroMQ could be
>> > built/developed in this integrated environment (from my Windowzy
>> > point of
>> > view), allowing for debugging in any of these platforms in a single
>> > way,
>> > but I can already hear the cringe of some members just from hearing
>> > the
>> > proposal.
>>
>> I think this is a bit too harsh :-) There's plenty of Windows devs
>> working on the project - lots of work has happened in the past year,
>> for example to make the CMake stuff better, and to have binaries
>> available for Windows too online (I think the platform is called
>> Conda?).
>> For example, you should be able to now use CMake seamlessly from VSCode
>> (or any other versions of VS) and get the exact same build results as
>> you'd get on *nix.
>>
>> Also a Windows version of epoll w

Re: [zeromq-dev] R.I.P. Pieter Hintjens

[Brian Knox via zeromq-dev]

Meeting Pieter for the first time in person, in London when I was there for
Strata ( I think it was 2012? ) resulted in an evening of drinks, walks,
and conversations with him and another friend of mine that stands out as
one of my favorite experiences I have had traveling for conferences...
followed by hanging out with him and some of you wonderful people in
Brussels at ZeroMQ workshops.  I still constantly see interesting things
happening in software or the world and reflexively think "I should show
this to Pieter!".

It was a gift to know him well enough to miss him. Cheers, friends.
Brian

On Sun, Dec 3, 2017 at 8:26 PM  wrote:

>
> On Dec 3, 2017, at 6:07 PM, Mark Botner  wrote:
>
> Hi Osiris,
>
> I first learned of ZeroMQ/Pieter when I listened to him on Floss Weekly in
> 2011. I had been working with CORBA based systems for several years at that
> point on knew there must be a better way - I just didn't know that way was
> with ZeroMQ!
> I then used ZeroMQ for several projects, and sent Pieter a note at one
> point thanking him for what he had done and he kindly replied. He even
> offered to buy me a beer if we were ever able to meet in person.
> Unfortunately, I never met him in person, but clearly, he was a visionary
> with the gift of seeing the future in messaging.
> Once again, I'm using ZeroMQ at my new job/company and often put in the
> comments "RIP Pieter Hintjens".  Maybe someone who reads the comments later
> on will bother to figure out who he was.
>
> Thanks,
>
> Mark
>
> On Sun, Dec 3, 2017 at 6:28 PM, Osiris Pedroso  wrote:
>
>> Today is Pieter's birthday.
>>
>> Thank you Pieter for all your guidance and knowledge over the years.
>>
>> I knew you for just a little bit, but you still are a great influence in
>> my professional life.
>>
>> Thanks for your contributions to ZeroMQ and to Open Source communities at
>> large.
>>
>
> I just toasted Pieter. He was a great man and father.
>
> cr
>
> ___
> 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

Re: [zeromq-dev] Call for testing for libzmq 4.2.3

[Brian Knox via zeromq-dev]

Hi Luca! I'll run some of my test suites against it later today and see if
anything breaks.

On Fri, Nov 17, 2017 at 11:05 AM Luca Boccassi 
wrote:

> Hi,
>
> With https://github.com/zeromq/libzmq/issues/2733 duct-taped the major
> blocker for releasing libzmq 4.2.3 is gone. I am currently compiling
> the changelog.
>
> It would be great if folks with applications using 4.2.2 could test
> 4.2.3 and report any regressions that they eventually find.
>
> --
> 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

Re: [zeromq-dev] Zyre demo at OpenWRT Summit in Prague, last Pieter's project

[Brian Knox via zeromq-dev]

It was great watching this while drinking my morning coffee today!

On Thu, Oct 26, 2017 at 7:12 AM Luca Boccassi 
wrote:

> On 26 October 2017 11:08:24 BST, Benjamin Henrion 
> wrote:
> >Zyre demo at OpenWRT Summit in Prague, last Pieter's project:
> >
> >https://www.youtube.com/watch?v=6UxQmvl4aaY
> >
> >--
> >Benjamin Henrion 
> >FFII Brussels - +32-484-566109 <+32%20484%2056%2061%2009> - +32-2-3500762
> <+32%202%20350%2007%2062>
> >"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
> >https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> Nice!___
> 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

Re: [zeromq-dev] Go binding support of zeromq

[Brian Knox via zeromq-dev]

Hello Jay! I'm the original author of zeromq/goczmq, and I've used
pebbe/zmq4 as well. I'll do my best to answer your questions!

1. Both pebbe/zmq4 and zeromq/goczmq support ZeroMQs security features.
2. The performance in my experience is reasonably the same.

The main difference in my mind is zeromq/goczmq wraps czmq, which is a C
library on top of libzmq which provides some higher level services than
straight libzmq provides. pebbe/zmq4 directly binds libzmq.

Which library you use probably depends most on which API you prefer and
whether you want some of the add-ons to libzmq that czmq provides.

Cheers,
Brian



On Wed, Sep 27, 2017 at 10:49 AM Jay Sharma  wrote:

> Hello All,
>
> I want to use go binding of zeromq.
> From official website I came to know about 2 available go bindings for
> zeromq:
>
> https://github.com/zeromq/goczmq
> http://github.com/pebbe/zmq4
>
> I am bit confused which one to use. I have some questions:
>
> 1. Which binding is supporting full "Security feature" ?
>
> 2. Which binding is having better performance. Is any profiling for these
> 2 binding?
>
> Any help will be appreciated.
> Thanks in advance.
>
> ___
> 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

Re: [zeromq-dev] Moving GSL into the ZeroMQ Github org

[Brian Knox via zeromq-dev]

Thanks for the heads up Luca!

On Sun, Sep 3, 2017 at 7:49 AM Luca Boccassi 
wrote:

> Hello all,
>
> After a proposal from Eric, the current maintainer of GSL in the iMatix
> Github organisation, we've forked GSL into the ZeroMQ org.
>
> This was done because there is now nobody left with admin permissions
> on the iMatix org, which means we can't do things like add CI
> integration and various other services. Talking with Ewen, it looks
> like Pieter's expectations was that it would be frozen for historical
> records, and development would continue elsewhere.
>
> Please update your local remotes settings, and send new pull request to
> the ZeroMQ repo. If you wish to update where your personal fork points
> to on the Github website itself (the "forked from foo/bar" note below
> the repo name on the page), I think you'll need to delete and re-fork.
>
> --
> 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

Re: [zeromq-dev] FOSDEM 2018 - ZeroMQ gathering/hackaton?

[Brian Knox]

I'm going to see if I can make this happen for FOSDEM 2018 :)

On Tue, Aug 29, 2017 at 6:11 PM Luca Boccassi 
wrote:

> On Tue, 2017-08-29 at 11:18 +0100, Luca Boccassi wrote:
> > On Tue, 2017-08-29 at 11:53 +0200, Benjamin Henrion wrote:
> > > On Tue, Aug 29, 2017 at 11:50 AM, Luca Boccassi  > > l.
> > > com> wrote:
> > > > On Tue, 2017-08-29 at 09:49 +0200, Benjamin Henrion wrote:
> > > > > On Sun, Aug 27, 2017 at 7:20 PM, Luca Boccassi  > > > > ma
> > > > > il.c
> > > > > om> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > FOSDEM 2018 dates have been announced, it will be on Saturday
> > > > > > 3rd
> > > > > > and
> > > > > > Sunday 4th of February. [1]
> > > > > >
> > > > > > Would people be interested in replicating last year's 2-days
> > > > > > ZMQ
> > > > > > gathering/hackaton before FOSDEM?
> > > > > >
> > > > > > Benjamin, would the hacker space we were at be available
> > > > > > again?
> > > > >
> > > > > Yes, same recipe as last year.
> > > > >
> > > > > --
> > > > > Benjamin Henrion 
> > > > > FFII Brussels - +32-484-566109 <+32%20484%2056%2061%2009> -
> +32-2-3500762 <+32%202%20350%2007%2062>
> > > > > "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."
> > > >
> > > > Great!
> > > >
> > > > Should we book the space or something like that?
> > > >
> > > > I'll create an event page on the wiki in a moment and then send
> > > > the
> > > > link
> > >
> > > Yes, it should appear on the frontpage in the list of events, you
> > > have
> > > to create a wikipage placeholder like last year with a link to the
> > > zeromq wiki.
> > >
> > > You would need ipv6 though to create and edit pages on hsbxl wiki.
> > >
> > > Best,
> > >
> > > --
> > > Benjamin Henrion 
> > > FFII Brussels - +32-484-566109 <+32%20484%2056%2061%2009> -
> +32-2-3500762 <+32%202%20350%2007%2062>
> > > "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."
> >
> > http://zeromq.org/event:zeromq-pre-fosdem-hackaton-thu-1-fri-2-feb-20
> > 18
> >
> > Later today I'll create the page on the hsbxl wiki - no IPv6 at work
> > (quite embarrassing for a networking company...)
>
> Benjamin,
>
> I've created the page on the wiki, could you please double check that I
> did it right when you have a moment?
>
> https://hsbxl.be/ZeroMQ_Pre-Fosdem_Hackaton_2018
>
> Thanks!
>
> --
> 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

Re: [zeromq-dev] ZeroMQ Github Org and 2-factor authentication

[Brian Knox]

Thanks Luca!

On Wed, Apr 12, 2017 at 7:56 AM Luca Boccassi 
wrote:

> 2 more admins have enabled 2FA (thanks!), that leaves 6 admins without.
>
> As discussed previously I've proceeded to demote those 6 admins to
> users, and contacted them again via email, asking to ping me when they
> enable 2FA to get promoted again. All ZeroMQ admins now have 2FA
> enabled.
>
> Now onto the remaining non-admin members. There are 50 users without
> 2FA who have an admin role in one or more individual repository
> (through teams) but not on the overall org.
>
> Later this weekend I'll compile the list and send the first individual
> emails asking to enable 2FA, and after that first wave we'll see how
> many are left and decide what to do.
>
> If you are a member of the Github ZeroMQ organisation and do not have
> 2FA enable and you are reading this, please enable it! Thank you!
>
> On Tue, 2017-04-04 at 16:44 +0300, Doron Somech wrote:
> > Sounds good
> >
> > On Apr 4, 2017 15:27, "Luca Boccassi" 
> > wrote:
> >
> > > 8 of the admins have now enabled 2FA (thanks!), but 7 still have
> > > not.
> > >
> > > I would like to propose the following:
> > >
> > > - sending a second reminder
> > > - if no answer is received or 2FA is not enabled by Monday evening
> > > GMT,
> > > _temporarily_ demote admins to members (and state this in the
> > > reminder)
> > > - once 2FA is enabled, promote again to admin
> > >
> > > Does this approach sound reasonable?
> > >
> > > If the admins have missed the email because they are offline or on
> > > holiday, then they will not need admin access anyway in the
> > > meanwhile,
> > > so it should not cause any major disruption I think.
> > >
> > > If there are no objections I will send the email later today.
> > >
> > > Unfortunately there is no way to send a communication to the
> > > organization via Github, so I had to rely on the email used by each
> > > user for their commits. I hope I haven't missed anybody.
> > >
> > > On Thu, 2017-03-30 at 13:26 +0100, Luca Boccassi wrote:
> > > > I've sent an email to all admins who do not have 2FA enabled.
> > > > Hopefully
> > > > we can get a good response rate, and in a week's time we can
> > > > decide
> > > > what to do if there are still some without 2FA.
> > > >
> > > > On Thu, 2017-03-30 at 14:41 +0300, Doron Somech wrote:
> > > > > Sounds good, can we start with admins only?
> > > > >
> > > > > On Thu, Mar 30, 2017 at 2:14 PM, Harald Achitz  > > > > mail
> > > > > .c
> > > > > om>
> > > > > wrote:
> > > > >
> > > > > > As a user: please make it an requirement for write access to
> > > > > > have
> > > > > > 2factor
> > > > > > auth.
> > > > > >
> > > > > > Thanks for having this idea and doing this initiative!
> > > > > >
> > > > > > Regards
> > > > > > Harald
> > > > > > send from my fairphone
> > > > > >
> > > > > > On Mar 30, 2017 12:37 PM, "Luca Boccassi"  > > > > > l.co
> > > > > > m>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello all,
> > > > > > >
> > > > > > > There have been news recently of attacks targeting
> > > > > > > developers
> > > > > > > using
> > > > > > > Github, and whose account is part of organizations [1].
> > > > > > >
> > > > > > > Github has been offering 2 factor authentication [2] for
> > > > > > > quite
> > > > > > > some
> > > > > > > time now, with options including a free TOTP phone app like
> > > > > > > the
> > > > > > > Google
> > > > > > > Authenticator or inexpensive U2F hardware tokens.
> > > > > > >
> > > > > > > It is well known that having 2FA enabled greatly reduced
> > > > > > > the
> > > > > > > chance of
> > > > > > > having an account compromised, and the damage in case it
> > > > > > > happens.
> > > > > > > Dragnet-style attacks become much less effective, and
> > > > > > > directly
> > > > > > > targeted
> > > > > > > attack to compromise both a machine and a token have to be
> > > > > > > deployed in
> > > > > > > order to be effective. It is simply put, a really good idea
> > > > > > > to
> > > > > > > use 2FA.
> > > > > > >
> > > > > > > In the Github ZeroMQ Org we have 114 members, of which 35
> > > > > > > have
> > > > > > > admin
> > > > > > > permissions.
> > > > > > > Of the 114 members, 59 do NOT have 2FA enabled. Of the 35
> > > > > > > owners,
> > > > > > > 15 do
> > > > > > > NOT have 2FA enabled.
> > > > > > >
> > > > > > > In case one of the members (especially an admin) had the
> > > > > > > account
> > > > > > > compromised, real damage could be caused.
> > > > > > >
> > > > > > > So I would like to propose to enforce the use of 2FA,
> > > > > > > starting
> > > > > > > with the
> > > > > > > admin accounts [3]. I can email the individual accounts
> > > > > > > asking
> > > > > > > to
> > > > > > > do
> > > > > > > so, in case they do not monitor the mailing list.
> > > > > > >
> > > > > > > What do you think? Any objections?
> > > > > > >
> > > > > > > Kind regards,
> > > > > > > Luca Boccassi
> > > > > > >
> > > > > > > [1] https://arstechnica.com/security/2017/03/someo

Re: [zeromq-dev] ZeroMQ Github Org and 2-factor authentication

[Brian Knox]

Thanks for bringing up this issue Luca! I am 100% in favor of enforcing 2
factor auth for the org.

On Thu, Mar 30, 2017 at 7:15 AM Harald Achitz 
wrote:

> As a user: please​ make it an requirement for write access to have 2factor
> auth.
>
> Thanks for having this idea and doing this initiative!
>
> Regards
> Harald
> send from my fairphone
>
> On Mar 30, 2017 12:37 PM, "Luca Boccassi"  wrote:
>
> Hello all,
>
> There have been news recently of attacks targeting developers using
> Github, and whose account is part of organizations [1].
>
> Github has been offering 2 factor authentication [2] for quite some
> time now, with options including a free TOTP phone app like the Google
> Authenticator or inexpensive U2F hardware tokens.
>
> It is well known that having 2FA enabled greatly reduced the chance of
> having an account compromised, and the damage in case it happens.
> Dragnet-style attacks become much less effective, and directly targeted
> attack to compromise both a machine and a token have to be deployed in
> order to be effective. It is simply put, a really good idea to use 2FA.
>
> In the Github ZeroMQ Org we have 114 members, of which 35 have admin
> permissions.
> Of the 114 members, 59 do NOT have 2FA enabled. Of the 35 owners, 15 do
> NOT have 2FA enabled.
>
> In case one of the members (especially an admin) had the account
> compromised, real damage could be caused.
>
> So I would like to propose to enforce the use of 2FA, starting with the
> admin accounts [3]. I can email the individual accounts asking to do
> so, in case they do not monitor the mailing list.
>
> What do you think? Any objections?
>
> Kind regards,
> Luca Boccassi
>
> [1]
> https://arstechnica.com/security/2017/03/someone-is-putting-lots-of-work-into-hacking-github-developers/
> [2] https://help.github.com/articles/about-two-factor-authentication/
> [3] Github has a setting to make it mandatory for an organization, but
> I'm not proposing to use that just now, as it will automatically kick
> anyone who does not have 2FA, which is too extreme and not necessary at
> the moment.
> ___
> 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
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] zdiscgo - new project

[Brian Knox]

I've been working on a new ZeroMQ project - "zdiscgo" - it is a CZMQ
service discovery zactor with support for Go plugins.  Link here:
https://github.com/taotetek/zdiscgo

After I fix up  the travis integration this weekend I was thinking about
moving it to the ZeroMQ org w/ a C4 contribution policy if people were ok
with that ( it is already MPLv2 licensed ).

Cheers,
Brian
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Releasing libzmq 4.2.1 and czmq 4.0.2 before end of year

[Brian Knox]

Sounds good Luca!

On Thu, Dec 29, 2016 at 2:35 PM Luca Boccassi 
wrote:

> Hello all,
>
> A few bug fixes have accumulated in the past couple of months, so I'd
> like to push out libzmq 4.2.1 and czmq 4.0.2 so that they can be picked
> up by the next Debian stable.
>
> Unless anyone has any reason to hold them up I'll prepare the changelogs
> soon.
>
> 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

Re: [zeromq-dev] ?==?utf-8?q? FOSDEM feb 4 & 5 Brussel?

[Brian Knox]

I arrive on Thursday morning and would love to see everyone.

On Mon, Dec 12, 2016 at 9:24 AM Arnaud Loonstra  wrote:

> I'm willing to participate however I arrive on Friday. I could try to
> arrive early though.
>
> Rg,
>
> Arnaud
>
>
> On Monday, December 12, 2016 15:08 CET, Benjamin Henrion 
> wrote:
>
> > On Mon, Dec 12, 2016 at 3:02 PM, Arnaud Loonstra 
> wrote:
> > > Is anybody going? Last years were very nice with Pieter hosting a
> hackathon. I'm hoping we can at least meet and have beer together?
> > > I'm staying at the Meininger.
> > >
> > > https://fosdem.org/2017/schedule/
> >
> > I think my message to this list did not get through:
> >
> > ==
> > Hi,
> >
> > I am looking to book a room (maybe the HSBXL hackerspace) 2 days
> > before fosdem (thu 2 feb+fri 3 feb), anyone willing to participate in a
> zmq
> > hackaton?
> >
> > Last year it was fun, and I would like to repeat it.
> >
> > Let me know,
> > ==
> >
> > Right now HSBXL looks the best, but I have to rent a heater, but that
> > should not be a problem.
> >
> > --
> > Benjamin Henrion 
> > FFII Brussels - +32-484-566109 <+32%20484%2056%2061%2009> -
> +32-2-3500762 <+32%202%20350%2007%2062>
> > "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
> > 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
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Happy Pieter Hintjens Day

[Brian Knox]

Cheers, Osiris! To Pieter.

On Sat, Dec 3, 2016 at 6:35 PM Osiris Pedroso  wrote:

> Today is the birthday of Pieter Hintjens
>  (3 December 1962 – 4
> October 2016). After Pieter's death earlier this year I decided I will
> commemorate his birthday every year going forward, keeping his memory alive.
>
> I just started reading today his unfinished Scalable-C
>  book and I am
> loving it. It answers so many of my questions on the first two months since
> I found ZeroMQ on how to participate in the process.
>
> In your conversations with Pieter, has anybody made notes of the scope
> that he intended for this book? It would be great for us as a community to
> complete his work. I am willing to help, but I would need some guidance on
> the scope, if that is known.
>
> Anyways, just wanted to wish you all a Happy Pieter Hintjens Day. I am
> drinking a Belgium beer in his honor today.
>
> To Pieter!
>
> PS: If there is internet access where he is, I am sure he got a smile on
> his face right now.
> ___
> 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

[Brian Knox]

No objections here - been using czmq off various commits off head for over
a year anyway ;)

On Tue, Nov 1, 2016 at 5:33 PM Luca Boccassi 
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  wrote:
> > Great news!
> >
> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> > 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 PRs
> >> to prepare for CZMQ 4.0.0~rc1.
> >>
> >> After the RCs are out, I'll work on the changelogs/NEWS files (help is
> >> appreciated!) as they have fallen dramatically behind.
> >>
> >> I'll also prepare more formal release notes for the stable rels, the RCs
> >> will have just a quick note since they are RCs.
> >>
> >> On Mon, 2016-10-31 at 23:47 +, Luca Boccassi wrote:
> >> > Cool!
> >> >
> >> > I can take care of it if you like. Tentative plan:
> >> >
> >> > Tomorrow push an RC1 for libzmq, then the pr to CZMQ to retire v2
> APIs,
> >> > then the RC1 for CZMQ.
> >> >
> >> > If it's all good then a couple days later the finals. I would really
> >> > like
> >> > to make it for the debian 9 transition freeze which is Saturday.
> >> >
> >> > On Oct 31, 2016 22:23, "Doron Somech"  wrote:
> >> >
> >> > > Sorry, yes, lets do it :)
> >> > >
> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
> >> > > wrote:
> >> > >
> >> > >> Ping :-)
> >> > >>
> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" 
> >> > >> wrote:
> >> > >>
> >> > >>> 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

Re: [zeromq-dev] zmq prebuilt for node

[Brian Knox]

Awesome Kyle!

On Fri, Oct 28, 2016 at 6:48 PM Luca Boccassi 
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"  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  wrote:
> >>
> >> Neat, that's what we want.
> >>
> >> On Thu, Feb 4, 2016 at 5:12 PM, Kyle Kelley  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 
> 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 
> wrote:
> >> >> > Ok, cool. Thanks for letting me know.
> >> >> >
> >> >> > In order to use this with prebuild
> >> >> > (https://github.com/mafintosh/prebuild),
> >> >> > I opted to do a GitHub fork of zmq.node here:
> >> >> >
> >> >> > https://github.com/nteract/zmq-prebuilt
> >> >> >
> >> >> > I've got initial builds working on Windows and Linux while rather
> amused
> >> >> > that I haven't been able to get OS X building (since that's what
> my dev
> >> >> > box
> >> >> > is)
> >> >> >
> >> >> >
> >> >> > On Wed, Feb 3, 2016 at 11:55 PM, Pieter Hintjens 
> wrote:
> >> >> >>
> >> >> >> The process is to start the project outside the ZeroMQ org and
> then
> >> >> >> bring it in as a kind of sacrificial offering, which gets you
> admin
> >> >> >> karma. This also avoids rashes of new projects that don't go
> anywhere.
> >> >> >>
> >> >> >> On Thu, Feb 4, 2016 at 5:01 AM, Kyle Kelley 
> wrote:
> >> >> >> > Hey all,
> >> >> >> >
> >> >> >> > I'm interested in creating prebuilt versions of zmq for node
> >> >> >> > available.
> >> >> >> > I
> >> >> >> > know that Pieter has started the more long term approach to
> >> >> >> > supporting
> >> >> >> > node.js well with support in zproject:
> >> >> >> >
> >> >> >> > https://github.com/zeromq/zproject/pull/484
> >> >> >> >
> >> >> >> > as well as in czmq:
> >> >> >> >
> >> >> >> > https://github.com/zeromq/czmq/pull/1319
> >> >> >> >
> >> >> >> > In the meantime, I'd like to plug away on some of the prebuilt
> setup
> >> >> >> > for
> >> >> >> > the
> >> >> >> > current node bindings (
> https://github.com/JustinTulloss/zeromq.node),
> >> >> >> > as
> >> >> >> > a
> >> >> >> > standalone project (called e.g. node-zmq-prebuilt, zmq-prebuilt
> on
> >> >> >> > npm).
> >> >> >> > This would mostly be dotting i's and crossing t's on appveyor +
> >> >> >> > Travis
> >> >> >> > configuration, as well as finishing off what I worked on in
> >> >> >> > https://github.com/JustinTulloss/zeromq.node/pull/486
> >> >> >> >
> >> >> >> > Would this be a good project to startup within zeromq, or
> should I
> >> >> >> > build
> >> >> >> > it
> >> >> >> > out on a different org for now?
> >> >> >> >
> >> >> >> > --
> >> >> >> > Kyle Kelley (@rgbkrk; lambdaops.com)
> >> >> >> >
> >> >> >> > ___
> >> >> >> > zeromq-dev mailing list
> >> >> >> > zeromq-dev@lists.zero

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

[Brian Knox]

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  wrote:

> I say lets bump.
>
> On Oct 15, 2016 20:32, "Luca Boccassi"  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 
> 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.
> > >> >
> > >> > 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 arc

Re: [zeromq-dev] BDFL literally

[Brian Knox]

That's great news Trevor

On Thu, Oct 6, 2016 at 3:18 AM Trevor Bernard 
wrote:

> Don't worry about sponsorship. My company will pay to renew them for
> the next while (within reason). Just send me the details and I'll pay
> the the bill.
>
> -Trev
>
> On Thu, Oct 6, 2016 at 12:35 AM, Osiris Pedroso 
> wrote:
> > Could you please list them?
> > I would like to sponsor a few, but would like to check them out first.
> >
> > Sent from my iPad. Regularly foiled by autocorrect. But duck it..
> >
> >> On Oct 5, 2016, at 17:49, Ewen McNeill 
> wrote:
> >>
> >>> On 20/04/16 6:16, Pieter Hintjens wrote:
> >>> So without further ado I'd like to hand the stage over to my dear
> >>> friend, Mr Did You Really Add UDP Support to Libzmq In One Day
> >>> Doron  dramatic pause... SOMECH!!
> >>
> >> For the record, Doron and I have now transferred the ZeroMQ domains
> that were previously owned by Pieter over to Doron (Doron already had
> administrative control over them; this just changes the Registrant field as
> well).
> >>
> >> Thanks to Doron for assisting with the transfer, and for paying the
> US$7.50/domain transfer fee.
> >>
> >> Pieter does have some other domains (mostly related to his books or
> non-ZeroMQ related projects) which will expire over the next 12 months. For
> some of these I am trying to finalise transfers of the domains to other
> people (who I have emailed directly).  A few of these (mostly iMatix
> related ones) will renew at least while there are still funds available in
> Pieter's registrar account.  For the others it is likely they will just be
> allowed to expire over the next 12 months.
> >>
> >> If there is a domain name that you know that Pieter holds for which you
> would like to see the project it is related to continue, feel free to get
> in touch.  Where there's a clear community supported successor to look
> after the domain/project I'm happy to help facilitate a transfer of the
> domain ownership.
> >>
> >> Alternatively the .org/.com/.net registry model does allow _anyone_ to
> pay the renewal fee on a domain, even one that they don't own.  So if you
> don't want to assume ownership of a domain, but do want to see it "stick
> round longer", then paying the renewal for another year could be a good
> option.  This is probably most relevant to the domains related to Pieter's
> books.  (All Pieter's domains are at Gandi, who definitely allow payment by
> anyone with a Gandi account for any domain at Gandi.)
> >>
> >> Finally, thanks to the people who paid to renew:
> >>
> >> restms.org
> >> imatix.com
> >>
> >> over the last month (imatix.com now expires in 2021; and restms.org
> now expires in 2020).
> >>
> >> 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
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Goodbye my friend

[Brian Knox]

I was just reading over the first PR I ever made to CZMQ and thinking about
the first time I met Pieter, in London in 2013. We had a wonderful evening
bar hopping and having  adventures, and a night long rambling conversation
about anything and everything except ZeroMQ.

I'm so glad to have known him, grateful for the impact he had on my life,
and grateful to be a member of this community with all of you.

Cheers,
Brian

On Tue, Oct 4, 2016 at 3:57 PM Kevin Sapper  wrote:

> I had been searching for a messaging library in 2013 for a "peer to peer
> file sync" student project. When I finally discovered the ZeroMQ guide I
> was stunned and excited. My first encounter with Pieter was on this mailing
> list, where he suggested to use zyre for the student project. After using
> it for a couple of days I suggested a few improvements. That's when I got
> challenged the first time to implement the improvements myself. I created a
> pull request and he merged it within seconds and fixed some minor bugs
> within minutes. Thereby he hooked me onto the C4 development process.
>
> @Wes zproject actually was when Pieter challenged us for about a month to
> create an own space for the code generation in czmq until I created the
> first prototype :)
>
> From thereon he taught me so much that it changed my mind on software
> development entirely.
>
> In June I finally met him on his wake together with a couple of you guys,
> which was a blast and I'm confident that through his lessons we will
> continue to be a great community.
>
> I'm sad that he's gone now - rest in peace
>
> //Kevin
> ___
> 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] Bye bye Pieter

[Brian Knox]

I'm so sad that he is gone, and so grateful to have this community and to
know you all a little bit because of him.


On Tue, Oct 4, 2016 at 1:41 PM Brian Adamson 
wrote:

> It was a great honor to have interacted with Pieter and his energy,
> willingness to help, awesome code, and leadership here were exemplary.  I
> offer my deepest sympathies to his family and those who knew him well.
>
> Brian Adamson
>
>
> > On Oct 4, 2016, at 10:29 AM, Benjamin Henrion  wrote:
> >
> > Dear Pieter,
> >
> > I wanted to say a last goodbye at noon at the hospital, but you told
> > me to come at 3pm.
> >
> > Now that you are gone, I can't stop crying.
> >
> > --
> > 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] A home for universal, cross-project protocols

[Brian Knox]

This is wonderful. I would happily help as a maintainer.

On Wed, May 18, 2016 at 5:19 AM Yurii Rashkovskii  wrote:

> Hi,
>
> I had a thought that some of the protocols designed by ZeroMQ and other
> communities have really outgrown their communities and would really benefit
> from a better exposure to the general public as protocols that can be
> universally applied across different projects.
>
> The two protocols that are most relevant to the work I am doing now are C4
> and COSS (from digistan.org), I extracted them and did a bit of
> reformatting to give them their deserved attention.
>
> Pieter has graciously contributed one of his domains, unprotocols.org, to
> the project.
>
> I've just launched the at http://rfc.unprotocols.org and published a
> corresponding github repo: https://github.com/unprotocols/rfc.
> Contributors and maintainers are welcomed!
>
> --
> Y.
>
> ___
> 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] czmq / zauth

[Brian Knox]

I was just reading over the code thinking "you know.. if this ZMQ_REP
socket was instead a ZMQ_SERVER socket..." ;)


On Fri, May 6, 2016 at 3:30 PM Pieter Hintjens  wrote:

> The current actor API is a bit simplistic. I'd have liked to redesign
> it using the new client/server sockets so that you could talk to
> actors from any thread. As it is, there's no explicit mechanism to
> check if actor X is running or not. You have to start the actor in
> your main thread. You might be able to detect zauth itself by trying a
> connect that needs it (as we do in the security selftests).
>
> On Fri, May 6, 2016 at 8:17 PM, Brian Knox  wrote:
> > Is there currently a way one can check if zauth is running for a process
> -
> > e.g.,  imagine a case where a zauth actor may be been started by another
> > thread - is there a way one can check (in a thread safe manner) if this
> was
> > the case?
> >
> > Brian
> >
> > ___
> > 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] czmq / zauth

[Brian Knox]

Is there currently a way one can check if zauth is running for a process -
e.g.,  imagine a case where a zauth actor may be been started by another
thread - is there a way one can check (in a thread safe manner) if this was
the case?

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

Re: [zeromq-dev] New version of C4 (C4.2?)

[Brian Knox]

This reminds me - I'm going to experiment with using go build tags for
controlling builds of draft contracts in goczmq.

I like the "used by real users" qualification on marking contracts as
stable.

On Thu, May 5, 2016 at 2:53 AM Pieter Hintjens  wrote:

> Hi all,
>
> I was writing a summary article on community building and revisited
> the C4 RFC. There were many small things that were out of date,
> speculative, or did not fit with our current best practice.
>
> So I've updated it here: https://github.com/zeromq/rfc/pull/83
>
> Please *do* read the diffs and let me know your opinions.
>
> I also would like advice on whether:
>
> * we make a new RFC (C4.2)
> * we accept to change the existing stable RFC unilaterally
>
> Option 1 is more correct but means we have to update a lot of
> projects. Option 2 is lazy and breaks our process.
>
> -Pieter
>
> -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

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

[Brian Knox]

Pieter - successfully sent syslog traffic over udp multicast via zeromq
this week, using RADIO / DISH ;)

On Tue, May 3, 2016 at 2:08 PM Pieter Hintjens  wrote:

> Wow... :)
>
> On Tue, May 3, 2016 at 7:36 PM, Brian Knox  wrote:
> > As a heads up I'm adding support for RADIO / DISH, SCATTER / GATHER and
> > CLIENT / SERVER to rsyslog for the 8.19 release later this  month. The
> code
> > will be wrapped with define checks so keep it safe to compile against
> CZMQ
> > stable.  If these are still considered draft and won't be built by
> default
> > that's fine, I manage our zeromq / czmq packages and have custom ones
> > anyway.
> >
> > Brian
> >
> > On Tue, May 3, 2016 at 8:13 AM Luca Boccassi 
> > wrote:
> >>
> >> 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
> >> ___
> >> 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

[Brian Knox]

As a heads up I'm adding support for RADIO / DISH, SCATTER / GATHER and
CLIENT / SERVER to rsyslog for the 8.19 release later this  month. The code
will be wrapped with define checks so keep it safe to compile against CZMQ
stable.  If these are still considered draft and won't be built by default
that's fine, I manage our zeromq / czmq packages and have custom ones
anyway.

Brian

On Tue, May 3, 2016 at 8:13 AM Luca Boccassi 
wrote:

> 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
> ___
> 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] CZMQ "stable" release versioning

[Brian Knox]

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
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] BDFL literally

[Brian Knox]

I for one welcome our new zeromq overlord!

With Love,
Brian


On Tue, Apr 19, 2016 at 2:16 PM Pieter Hintjens  wrote:

> Friends,
>
> You know I've always steered our community with a light touch, only
> intervening in case of the few disputes we get when bad actors think they
> can waltz in and impose their egos. We agree that our rules work and that
> those who understand and apply them with the right mix of tolerance for
> error, and brutality towards fraud, are the people I most closely cherish.
> It's not fair but neither is life.
>
> Sorry I've spent a while on this problem. A community needs someone to
> take the blame and some of the credit. An honest mix of pride and respect
> for others. A stubborn bastard who nods and lets you have lots of road just
> to hang you with if it's needed.
>
> And someone who can balance long term insane vision with pragmatic slow
> progress, because they have already been there and now wait with patience
> for the rest of us to catch up.
>
> So without further ado I'd like to hand the stage over to my dear friend,
> Mr Did You Really Add UDP Support to Libzmq In One Day Doron  dramatic
> pause... SOMECH!!
>
> Thank you for your votes, which I entirely ignored. :)
>
> 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

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

[Brian Knox]

Excellent. +1 for staying with mailman then.

On Tue, Apr 19, 2016 at 5:21 AM, Kevin Sapper 
wrote:

> Staying with Mailman is indeed the better choice. Even though I like
> Google groups they don't have an option the migrate away from it which is a
> deal breaker IMO.
> Regarding helping out Ewen I gladly volunteer.
>
> 2016-04-19 5:30 GMT+02:00 Indradhanush Gupta  >:
>
>>
>>
>> On Tue, Apr 19, 2016 at 8:44 AM, Pieter Hintjens 
>> wrote:
>>
>>> OK, we need a small set of admins, who can work with my friend Ewen
>>> McNeill, who has kept archives over the years, to migrate to mailmanlists
>>> and then manage the lists (zeromq-announce is #2). Justin, it's your baby.
>>> Thank you.
>>>
>> This is great. I'd like to volunteer if you need an extra hand.
>>
>>
>>
>>> On 19 Apr 2016 05:10, "Pieter Hintjens"  wrote:
>>>
>>> Justin, that is a great proposal, thank you for finding it. I'd prefer
>>> keeping mailman, for familiarity.
>>> On 19 Apr 2016 04:36, "Justin Karneges"  wrote:
>>>
 Hey folks,

 I spoke with MailmanLists and they are willing to host the ZeroMQ
 mailing list for free. All they ask for is a link on the mailing list
 page. If you'd prefer the list remain Mailman-based and simply don't
 want to host it, then I'd say this is the best the way to go. They'll
 import archives too.

 Re: MailmanLists vs. dotList (aka Mailmanhost), both appear to be
 Mailman hosting experts with a long lives (8 years and 11 years,
 respectively). Other than cost, it's hard to say on the outside which
 one is better, but as a customer of MailmanLists I can vouch for their
 helpful support. MailmanLists also claims to be a financial contributor
 to the FSF which is pretty cool.

 On Mon, Apr 18, 2016, at 05:21 PM, c wrote:
 > Jim Idle  writes:
 >
 > I'm a nay on Google Groups. As seen with SourceForge, sometimes the
 > priorities of companies change. This is especially true for a
 publically
 > traded company.
 >
 > The price points of https://www.mailmanhost.com/pricing/ seem better
 > than http://www.mailmanlists.net/ but I have no personal experience
 with
 > either.
 >
 > > You just add your email address to the google list - you don't
 > > actually need a Google account. Thre is really no difference to now.
 >
 > In my experience list maintainers end up needing to enable the Google
 > Account
 > requirement on their groups to combat spam.
 > ___
 > 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
>>>
>>>
>>
>>
>> --
>> 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] Moving list to Google groups?

[Brian Knox]

I'm not averse to google groups, in that it is low friction / low
maintenance - and I always hesitate to suggest self hosted / higher
friction / higher maintenance solutions unless I'm willing to implement and
maintain them myself.

Brian

On Wed, Apr 13, 2016 at 6:45 PM, Pieter Hintjens  wrote:

> Hi all,
>
> I'd like to raise this question for discussion. The problem is that
> zeromq-dev is running on an iMatix server, and I'd like to remove
> iMatix infrastructure from our community, over time. It's a matter of
> long term sustainability.
>
> (Apart from the list, iMatix also hosts downloads.zeromq.org which we
> can start to move to Github release attachments IMO.)
>
> Anyhow, re. lists, let's weigh pros and cons of Google groups versus
> other options. I'll make the decision based on this thread and other
> factors.
>
> Thanks
> 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

Re: [zeromq-dev] ZeroMQ hackathon, 27-28-29 January

[Brian Knox]

Getting some breakfast then on my way :)
On Jan 27, 2016 9:33 AM, "Pieter Hintjens"  wrote:

> :-)
>
> On Tue, Jan 26, 2016 at 11:10 PM, Arnaud Loonstra 
> wrote:
> > I will arrive in Brussels tomorrow. I expect to arrive at iMatix World
> > HQ somewhere in the afternoon!
> >
> > See you tomorrow!
> >
> > Rg,
> >
> > Arnaud
> >
> > On 2016-01-06 15:42, Pieter Hintjens wrote:
> >> The location is the dockside warehouse that serves as iMatix World
> >> HQ, in fact.
> >>
> >> Rue des Ateliers 15, Brussels.
> >>
> >> I'll arrange a spot to crash for those who need sleep.
> >>
> >> On Wed, Jan 6, 2016 at 12:37 PM, Brian Knox 
> >> wrote:
> >>> Can't wait!  I arrive in Brussels around 7:30 am on the 27th and
> >>> will make
> >>> my jet lagged way over to whatever the location turns out to be :)
> >>>
> >>> On Wed, Jan 6, 2016 at 2:33 AM, Pieter Hintjens 
> >>> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Just to remind anyone in the region of Brussels at the end of
> >>>> January,
> >>>> we are organizing a hackathon on the 3 days before FOSDEM. Access
> >>>> is
> >>>> free, and it's a unique opportunity to learn and share experiences.
> >>>>
> >>>> There are still places available. Register on http://zero.mq/bxl.
> >>>>
> >>>> -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
> ___
> 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 hackathon, 27-28-29 January

[Brian Knox]

Can't wait!  I arrive in Brussels around 7:30 am on the 27th and will make
my jet lagged way over to whatever the location turns out to be :)

On Wed, Jan 6, 2016 at 2:33 AM, Pieter Hintjens  wrote:

> Hi all,
>
> Just to remind anyone in the region of Brussels at the end of January,
> we are organizing a hackathon on the 3 days before FOSDEM. Access is
> free, and it's a unique opportunity to learn and share experiences.
>
> There are still places available. Register on http://zero.mq/bxl.
>
> -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

Re: [zeromq-dev] C4 and CI

[Brian Knox]

John - thanks for sharing your experiences with trying out the C4 process!
It's definitely an interesting situation when "the build system" that
determines if a PR has broken a build or not can't be simple or in one spot.

I think the key point to identify is "what is the criteria for a PR to be
accepted" in this situation. If you have multiple people using multiple
community run systems for performing automated tests, you'll probably want
to take into account the possibility that some subset of these systems may
be not functioning at any given point in time.  Since you don't want that
to halt all progress on your project, identifying the subset of things that
MUST happen (vs SHOULD happen) for a PR to be merged will be important.

Cheers,
Brian

On Mon, Nov 16, 2015 at 3:31 AM, Pieter Hintjens  wrote:

> On-topic, I think, as it relates to our own development practice.
>
> Though I'm not sure what your question actually is... :)
>
> What we've learned, over time, is that the less "official" pieces
> there are, the better. So we have no official bindings, no official
> implementations, and fewer and fewer official packages. Distributing
> power and freedom works better. The only real exception is the
> branding, which my company holds, to prevent rule-breaking projects
> calling themselves "ZeroMQ."
>
> Even the rules are chosen by each project and not all ZeroMQ projects
> follow C4.
>
> For CI, we use a growing mix of systems, and the success/failure
> information is fed into the pull request, yet it's not stressful. I
> often merge broken PRs simply because it keeps the flow of activity
> going, and is more fun for everyone than waiting.
>
> -Pieter
>
>
> On Mon, Nov 16, 2015 at 7:49 AM, Peter Krey  wrote:
> > this question is appropriate for stackoverflow, not the zeromq mailing
> list.
> >
> > On Sun, Nov 15, 2015 at 10:35 PM, John Morris  wrote:
> >>
> >> Hello list,
> >>
> >> We've been using parts of C4 to manage the Machinekit project,
> >> open-source machine control software.  I love the idea of C4, and really
> >> buy into its basic ideas of reducing friction of the development process
> >> in order to scale the developer and, following that, the user community,
> >> the size of which is a primary indicator of project success.
> >>
> >> However, it turns out C4 is a very challenging idea that most people
> >> seem to have trouble swallowing in its entirety, as I have.
> >> Accordingly, we really only follow parts of C4, which is a
> >> disappointment to me.
> >>
> >> Part of this is my own fault.  I run a Buildbot for the project that
> >> builds many different configurations, i.e. combinations of OS, hardware
> >> architecture and real-time thread environment.  It's especially because
> >> of the latter that using a CI system on public infrastructure, like
> >> Travis CI, isn't possible:  running regression tests under the several
> >> RT thread systems (RT_PREEMPT, Xenomai, RTAI) requires special kernel
> >> support unavailable in those environments, so it's necessary to run the
> >> CI system on bare metal or a VM with custom kernels.  In order to
> >> support many OS, arch and RT environments, my Buildbot is extremely
> >> complex and essentially unreproducible.  As a result, despite my clear
> >> communication that it's a system contributed by a third-party (my
> >> company), the community tends to see it as the project's "official" CI
> >> system, dictating "officially-supported" configurations and providing
> >> the "official" package stream.  I shouldn't have to tell this audience
> >> how this undermines C4, and besides this CI system is a SPOF for the
> >> project and is taking too much of my own energy to maintain.
> >>
> >> So, taking the last two years' lessons learned about what (IMO) a C4
> >> community needs in a CI infrastructure (esp. when public CI services
> >> don't make sense), I have a plan for a CI system that seems a better fit
> >> with the spirit of C4, and solves other practical issues at the same
> time.
> >>
> >> Key to the idea is scalability by distributing the burden across many
> >> members of the community.  A trivially-reproducible CI system, such as a
> >> Buildbot instance in a Docker container (either on private hardware or
> >> the cloud), may be set up by any community member to build/test/package
> >> one single particular favorite configuration, for example Debian Jessie
> >> on RPi2 with RT_PREEMPT kernel pointing at the official git repo master
> >> branch.  Set up instructions should be as short as "install Docker;
> >> clone this git repo; edit the configuration; run the Docker container".
> >>
> >> For each PR, the system builds the code for and tests it in the
> >> configured environment (these duties could be separated).  The
> >> build/test results are then aggregated (exactly how is TBD) with those
> >> of other contributed CI systems (with different configurations), and the
> >> PR is updated with a (or a list of) pass/fail status(es), which 

Re: [zeromq-dev] ZeroMQ hackathon/workshop (Brussels, 27/1-29/1 2016)

[Brian Knox]

I'll be a little late the first day - if all goes well I arrive in Brussels
at 7:30am that Wednesday morning.  Can't wait to see everyone who is going!

Brian

On Sun, Nov 15, 2015 at 1:57 AM, Trevor Bernard 
wrote:

> I'm very much looking forward to participating at FOSDEM and the
> hackathon before it. I hope to see you people there.
>
> On Sun, Nov 15, 2015 at 2:50 AM, Pieter Hintjens  wrote:
> > Hi all,
> >
> > On the days before FOSDEM (the largest free and open source
> > developers' meeting in Europe), we're running a 3-day hackathon and
> > workshop for the ZeroMQ community.
> >
> > This event is free and possibly the best ZeroMQ training you can get
> > anywhere on the planet. Space is limited to 20 participants. Please
> > register on http://zeromq.org/event:zeromq-meetup-brussels.
> >
> > -Pieter Hintjens
> > ___
> > 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] Internet of Things devroom - FOSDEM 2016

[Brian Knox]

I will be arriving in Brussels the morning of January 27th (Wednesday) and
staying through the morning of February 2nd.

On Sunday at FOSDEM I'll be helping Luna run the Golang dev room - will
definitely hang out in the IoT dev room on Saturday and I'm certainly up
for getting together with ZeroMQers pre-fosdem to hang out and work on
projects.


On Sat, Oct 24, 2015 at 7:14 AM, Doron Somech  wrote:

> Pieter are you going to have pre-FOSDEM zeromq hackathon as well?
>
> On Sat, Oct 24, 2015 at 1:58 PM, Pieter Hintjens  wrote:
>
>> Hi all,
>>
>> FYI I'm organizing the 3rd IoT devroom at FOSDEM on 30 January 2016.
>>
>> If you have a nice demo of using ZeroMQ/Zyre etc. in an IoT project,
>> why not come to Brussels to show it off?
>>
>> Full text is at: http://iot-devroom.wikidot.com/blog:3
>>
>> -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] zpoller_wait does not work with ZMQ_SERVER sockets

[Brian Knox]

I was doing some work to add support for ZMQ_CLIENT and ZMQ_SERVER sockets
to GoCZMQ and ran across this issue.

I've filed a problem report on czmq with a test case to reproduce it:

https://github.com/zeromq/czmq/issues/1123

I vaguely remember some previous discussions around poll and ZMQ_CLIENT
ZMQ_SERVER and if I can find them I'll add them to the report.

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

Re: [zeromq-dev] New ZeroMQ Organization Project

[Brian Knox]

Doron - I think we can get away with not supporting multi part.  We're
mainly interested in PUB / SUB and CLIENT / SERVER support.  With CLIENT /
SERVER being able to stand in for ROUTER / DEALER and not requiring multi
part messages - I think we can ignore multi part for what we're doing.

I've got the initial signature handshake working over TCP here today as
well as the version exchange but unfortunately I'm not going to have much
time to work on it for the rest of this week.  I'm going to go ahead and
submit a PR with that I have so far today.

Cheers,
Brian

On Sat, Oct 10, 2015 at 2:45 PM, Doron Somech  wrote:

> Brain I will love to help and improve my golang on the way.
>
> Small tip, if you don't need multi-parts it will make your implementation
> much easier.
> If you do need, using the "commit" solution of libzmq is very complicated,
> try to unified all the parts into one data structure and enqueue it into a
> channel (you will loose some performance but implementation will be much
> easier and thread safe).
>
> On Sat, Oct 10, 2015 at 7:40 PM, Pieter Hintjens  wrote:
>
>> The name is :)
>>
>> On Sat, Oct 10, 2015 at 4:31 PM, Brian Knox 
>> wrote:
>> > Pieter - yup!  I've looked at the libzmtp code before - it + the zmtp
>> rfc
>> > combined are a good reference.
>> >
>> > We're going to keep the name "gogozmq" for now mainly because we like
>> saying
>> > "go go zmq!" a lot.  It may not be the best name, but it has the
>> important
>> > property of making me smile whenever I say it. ;)
>> >
>> > Cheers,
>> > Brian
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Oct 9, 2015 at 7:35 PM, Pieter Hintjens  wrote:
>> >>
>> >> Go go zmq! :-)
>> >>
>> >> This is a great idea. I'm going to suggest modestly that "gomq" could
>> >> work better as a name. "gogozmq" looks like a binding name.
>> >>
>> >> FWIW we started on a small C library (libzmtp) and what we made was a
>> >> DEALER socket. This is immediately useful, and could be a good
>> >> starting point.
>> >>
>> >> -Pieter
>> >>
>> >>
>> >>
>> >> On Fri, Oct 9, 2015 at 2:25 PM, Brian Knox 
>> wrote:
>> >> > Luna and I have been talking about implementing a subset of ZeroMQ in
>> >> > pure
>> >> > go to complement goczmq for people who don't want C dependencies.  It
>> >> > would
>> >> > solve a great set of problems for both of us and we feel would be
>> useful
>> >> > to
>> >> > others as well.
>> >> >
>> >> > We wanted to give a heads up that we're going to create a "gogozmq"
>> >> > project
>> >> > in the ZeroMQ organization.  We plan to follow the C4.1 dev process.
>> >> > First
>> >> > PR will be submitted later today.
>> >> >
>> >> > Cheers!
>> >> > Brian & Luna
>> >> >
>> >> > ___
>> >> > 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
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] New ZeroMQ Organization Project

[Brian Knox]

Pieter - yup!  I've looked at the libzmtp code before - it + the zmtp rfc
combined are a good reference.

We're going to keep the name "gogozmq" for now mainly because we like
saying "go go zmq!" a lot.  It may not be the best name, but it has the
important property of making me smile whenever I say it. ;)

Cheers,
Brian





On Fri, Oct 9, 2015 at 7:35 PM, Pieter Hintjens  wrote:

> Go go zmq! :-)
>
> This is a great idea. I'm going to suggest modestly that "gomq" could
> work better as a name. "gogozmq" looks like a binding name.
>
> FWIW we started on a small C library (libzmtp) and what we made was a
> DEALER socket. This is immediately useful, and could be a good
> starting point.
>
> -Pieter
>
>
>
> On Fri, Oct 9, 2015 at 2:25 PM, Brian Knox  wrote:
> > Luna and I have been talking about implementing a subset of ZeroMQ in
> pure
> > go to complement goczmq for people who don't want C dependencies.  It
> would
> > solve a great set of problems for both of us and we feel would be useful
> to
> > others as well.
> >
> > We wanted to give a heads up that we're going to create a "gogozmq"
> project
> > in the ZeroMQ organization.  We plan to follow the C4.1 dev process.
> First
> > PR will be submitted later today.
> >
> > Cheers!
> > Brian & Luna
> >
> > ___
> > 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] New ZeroMQ Organization Project

[Brian Knox]

Luna and I have been talking about implementing a subset of ZeroMQ in pure
go to complement goczmq for people who don't want C dependencies.  It would
solve a great set of problems for both of us and we feel would be useful to
others as well.

We wanted to give a heads up that we're going to create a "gogozmq" project
in the ZeroMQ organization.  We plan to follow the C4.1 dev process.  First
PR will be submitted later today.

Cheers!
Brian & Luna
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Cookbook repository

[Brian Knox]

Aha!  That makes perfect sense.

On Tue, Sep 8, 2015 at 5:04 PM, Pieter Hintjens  wrote:

> For licensing, MPLv2 is an issue as many people want to reuse these
> recipes in closed apps... for the Guide we went for an MIT/X11 license
> instead.
>
> On Tue, Sep 8, 2015 at 9:47 AM, Johan Philips 
> wrote:
> >
> >> On 08 Sep 2015, at 14:19, Pieter Hintjens  wrote:
> >>
> >> First recipe can be Hello World :-) I suggest we make the whole repo
> >> with pull requests as always. So all we need to get started is a new
> >> repo, a link to RFC 22, a license for code.
> >>
> >> I think we can make a load of different Hello World recipes, for
> >> different socket types.
> >
> > Interesting initiative! We have been writing an (academic) publication
> with robotics use cases for many of the zeromq patterns, they might also
> fit in a more generic context / general domain.
> >
> > Johan
> >
> >
> >>
> >> On Tue, Sep 8, 2015 at 4:32 AM, Doron Somech 
> wrote:
> >>> Happy to hear the good responses. I have limited access to internet and
> >>> computer in the coming month so I won't be able to contribute much.
> But will
> >>> contribute afterwards. Looking forward to see the first recipe...
> >>>
> >>> This is a fantastic idea...
> >>>
> >>> The Guide is old, and the process predates C4. It's time to build a
> >>> new repository of examples IMO.
> >>>
> >>> We can write recipes clearly, as problem statements, and then show how
> >>> to make them in all our languages and bindings.
> >>>
> >>>
> >>>
> >>> On Mon, Sep 7, 2015 at 5:28 PM, Brian Knox 
> wrote:
> >>>> I think a ZeroMQ cookbook sounds like a neat idea.  I'd happily
> contribute
> >>>> some examples for the GoCZMQ bindings - it would be a fun project to
> >>>> implement some of the patterns using them.
> >>>>
> >>>> Tying each pattern to a problem statement would be very much in the
> spirit
> >>>> of ZeroMQ development methodology itself.
> >>>>
> >>>> On Mon, Sep 7, 2015 at 10:03 AM, Doron Somech 
> wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> Problem1: Find the right zeromq pattern is sometime complicated, not
> all
> >>>>> patterns are documented and searching through different blog posts or
> >>>>> mail
> >>>>> archives is hard.
> >>>>>
> >>>>> Problem2: I have a problem and I want to know if another user in the
> >>>>> community already had it and found a simple solution. Right now I
> have to
> >>>>> ask on the mailing list and wait for somebody to response.
> >>>>>
> >>>>> So zeromq guide have some patterns documented but I think we can do
> more.
> >>>>> My idea is to create cookbook repository, so each pattern has
> >>>>> documentation
> >>>>> (what is the problem this pattern is solving and how to use) and
> >>>>> implementation in at least one language.
> >>>>>
> >>>>> It will be easier to direct people to a specific pattern in the
> cookbook
> >>>>> repository and also share the different problems and solutions we all
> >>>>> use.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>>
> >>>>>
> >>>>> ___
> >>>>> 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
> >
> > ___
> > 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] Cookbook repository

[Brian Knox]

Everyone ok with the usual MPLv2 for the license?

On Tue, Sep 8, 2015 at 8:19 AM, Pieter Hintjens  wrote:

> First recipe can be Hello World :-) I suggest we make the whole repo
> with pull requests as always. So all we need to get started is a new
> repo, a link to RFC 22, a license for code.
>
> I think we can make a load of different Hello World recipes, for
> different socket types.
>
> On Tue, Sep 8, 2015 at 4:32 AM, Doron Somech  wrote:
> > Happy to hear the good responses. I have limited access to internet and
> > computer in the coming month so I won't be able to contribute much. But
> will
> > contribute afterwards. Looking forward to see the first recipe...
> >
> > This is a fantastic idea...
> >
> > The Guide is old, and the process predates C4. It's time to build a
> > new repository of examples IMO.
> >
> > We can write recipes clearly, as problem statements, and then show how
> > to make them in all our languages and bindings.
> >
> >
> >
> > On Mon, Sep 7, 2015 at 5:28 PM, Brian Knox 
> wrote:
> >> I think a ZeroMQ cookbook sounds like a neat idea.  I'd happily
> contribute
> >> some examples for the GoCZMQ bindings - it would be a fun project to
> >> implement some of the patterns using them.
> >>
> >> Tying each pattern to a problem statement would be very much in the
> spirit
> >> of ZeroMQ development methodology itself.
> >>
> >> On Mon, Sep 7, 2015 at 10:03 AM, Doron Somech 
> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> Problem1: Find the right zeromq pattern is sometime complicated, not
> all
> >>> patterns are documented and searching through different blog posts or
> >>> mail
> >>> archives is hard.
> >>>
> >>> Problem2: I have a problem and I want to know if another user in the
> >>> community already had it and found a simple solution. Right now I have
> to
> >>> ask on the mailing list and wait for somebody to response.
> >>>
> >>> So zeromq guide have some patterns documented but I think we can do
> more.
> >>> My idea is to create cookbook repository, so each pattern has
> >>> documentation
> >>> (what is the problem this pattern is solving and how to use) and
> >>> implementation in at least one language.
> >>>
> >>> It will be easier to direct people to a specific pattern in the
> cookbook
> >>> repository and also share the different problems and solutions we all
> >>> use.
> >>>
> >>> What do you think?
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Cookbook repository

[Brian Knox]

I think a ZeroMQ cookbook sounds like a neat idea.  I'd happily contribute
some examples for the GoCZMQ bindings - it would be a fun project to
implement some of the patterns using them.

Tying each pattern to a problem statement would be very much in the spirit
of ZeroMQ development methodology itself.

On Mon, Sep 7, 2015 at 10:03 AM, Doron Somech  wrote:

> Hi All,
>
> Problem1: Find the right zeromq pattern is sometime complicated, not all
> patterns are documented and searching through different blog posts or mail
> archives is hard.
>
> Problem2: I have a problem and I want to know if another user in the
> community already had it and found a simple solution. Right now I have to
> ask on the mailing list and wait for somebody to response.
>
> So zeromq guide have some patterns documented but I think we can do more.
> My idea is to create cookbook repository, so each pattern has documentation
> (what is the problem this pattern is solving and how to use) and
> implementation in at least one language.
>
> It will be easier to direct people to a specific pattern in the cookbook
> repository and also share the different problems and solutions we all use.
>
> What do you think?
>
>
>
> ___
> 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] Use case of migration from Kafka to ZeroMQ

[Brian Knox]

I loved this article.  I made similar decisions around the same trade-offs
for real time log subscription to back end logs at DigitalOcean.
Separating the concerns of "real time view of what is happening now" and
"historical view of what happened in the past" allowed me to solve these
two separate concerns as two different problems - which meant less
trade-offs for each.  Those two quotes are fantastic!


On Sat, Sep 5, 2015 at 6:54 AM, Pieter Hintjens  wrote:

> Folks,
>
> Here's a detailed and well-explained article on how Auth0 migrated
> from Apache Kafka to ZeroMQ for their real-time log file aggregation:
>
>
> http://tomasz.janczuk.org/2015/09/from-kafka-to-zeromq-for-log-aggregation.html
>
> I especially liked the notes:
>
> "Doing work always takes more effort than not doing it." and "Parts of
> the system that are not there never break."
>
> The conclusion of the article:
>
> "By focusing on the key requirements of our scenario we were able to
> significantly reduce the complexity of the solution. While improved
> stability and reliability was the key motivation for this transition,
> the added performance and reduced system complexity were a nice side
> effects."
>
> -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

Re: [zeromq-dev] CZMQ now available in Debian

[Brian Knox]

This is fantastic news!  Will make packaging rsyslog w/ the omczmq / imczmq
enabled quite a bit easier.

Cheers!
Brian

On Sun, Aug 16, 2015 at 3:56 PM, Luca Boccassi 
wrote:

> 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
>
> ___
> 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] CZMQ related travis failures

[Brian Knox]

Merged!  Thanks Doron!

On Sun, Aug 16, 2015 at 11:07 AM, Doron Somech  wrote:

> PR is pending, should be fixed once merged.
>
>
> On Sun, Aug 16, 2015 at 6:00 PM, Brian Knox 
> wrote:
>
>> Aha!  Mystery solved.  No problem Doron!
>>
>> On Sun, Aug 16, 2015 at 10:59 AM, Doron Somech 
>> wrote:
>>
>>> I think you are right, sorry for that.
>>> Sending a pull request now.
>>>
>>> On Sun, Aug 16, 2015 at 5:33 PM, KIU Shueng Chuan 
>>> wrote:
>>>
>>>> I think it's because zmq_pollitem_t has very recently gained a new
>>>> "poller" field. Perhaps that new field should be moved to the end?
>>>> On 16 Aug 2015 22:06, "Brian Knox"  wrote:
>>>>
>>>>> Joe - that's what I'm thinking too.
>>>>>
>>>>> On Sun, Aug 16, 2015 at 9:59 AM, Joe McIlvain 
>>>>> wrote:
>>>>>
>>>>>> Could be that Travis updated its software packages so that a
>>>>>> different set of warning/error settings are active for the compiler.
>>>>>>
>>>>>> On Sun, Aug 16, 2015 at 5:02 AM, Brian Knox 
>>>>>> wrote:
>>>>>>
>>>>>>> CZMQ is currently failing to build on travis-ci for GoCZMQ, just
>>>>>>> wanted to see if anyone else has run into this.  As far as I can tell 
>>>>>>> the
>>>>>>> code involved hasn't changed in over a year, so not sure why it's 
>>>>>>> causing
>>>>>>> travis issues now:
>>>>>>>
>>>>>>> src/zbeacon.c: In function ‘zbeacon’:
>>>>>>> src/zbeacon.c:281:13: error: initialization makes pointer from integer 
>>>>>>> without a cast [-Werror]
>>>>>>> src/zbeacon.c:281:13: error: (near initialization for 
>>>>>>> ‘pollitems[1].poller’) [-Werror]
>>>>>>> cc1: all warnings being treated as errors
>>>>>>> make[1]: *** [src/src_libczmq_la-zbeacon.lo] Error 1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> 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
>>>
>>>
>>
>> ___
>> 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] CZMQ related travis failures

[Brian Knox]

Aha!  Mystery solved.  No problem Doron!

On Sun, Aug 16, 2015 at 10:59 AM, Doron Somech  wrote:

> I think you are right, sorry for that.
> Sending a pull request now.
>
> On Sun, Aug 16, 2015 at 5:33 PM, KIU Shueng Chuan 
> wrote:
>
>> I think it's because zmq_pollitem_t has very recently gained a new
>> "poller" field. Perhaps that new field should be moved to the end?
>> On 16 Aug 2015 22:06, "Brian Knox"  wrote:
>>
>>> Joe - that's what I'm thinking too.
>>>
>>> On Sun, Aug 16, 2015 at 9:59 AM, Joe McIlvain 
>>> wrote:
>>>
>>>> Could be that Travis updated its software packages so that a different
>>>> set of warning/error settings are active for the compiler.
>>>>
>>>> On Sun, Aug 16, 2015 at 5:02 AM, Brian Knox 
>>>> wrote:
>>>>
>>>>> CZMQ is currently failing to build on travis-ci for GoCZMQ, just
>>>>> wanted to see if anyone else has run into this.  As far as I can tell the
>>>>> code involved hasn't changed in over a year, so not sure why it's causing
>>>>> travis issues now:
>>>>>
>>>>> src/zbeacon.c: In function ‘zbeacon’:
>>>>> src/zbeacon.c:281:13: error: initialization makes pointer from integer 
>>>>> without a cast [-Werror]
>>>>> src/zbeacon.c:281:13: error: (near initialization for 
>>>>> ‘pollitems[1].poller’) [-Werror]
>>>>> cc1: all warnings being treated as errors
>>>>> make[1]: *** [src/src_libczmq_la-zbeacon.lo] Error 1
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> 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
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] CZMQ related travis failures

[Brian Knox]

Joe - that's what I'm thinking too.

On Sun, Aug 16, 2015 at 9:59 AM, Joe McIlvain  wrote:

> Could be that Travis updated its software packages so that a different set
> of warning/error settings are active for the compiler.
>
> On Sun, Aug 16, 2015 at 5:02 AM, Brian Knox 
> wrote:
>
>> CZMQ is currently failing to build on travis-ci for GoCZMQ, just wanted
>> to see if anyone else has run into this.  As far as I can tell the code
>> involved hasn't changed in over a year, so not sure why it's causing travis
>> issues now:
>>
>> src/zbeacon.c: In function ‘zbeacon’:
>> src/zbeacon.c:281:13: error: initialization makes pointer from integer 
>> without a cast [-Werror]
>> src/zbeacon.c:281:13: error: (near initialization for 
>> ‘pollitems[1].poller’) [-Werror]
>> cc1: all warnings being treated as errors
>> make[1]: *** [src/src_libczmq_la-zbeacon.lo] Error 1
>>
>>
>>
>> ___
>> 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] CZMQ related travis failures

[Brian Knox]

CZMQ is currently failing to build on travis-ci for GoCZMQ, just wanted to
see if anyone else has run into this.  As far as I can tell the code
involved hasn't changed in over a year, so not sure why it's causing travis
issues now:

src/zbeacon.c: In function ‘zbeacon’:
src/zbeacon.c:281:13: error: initialization makes pointer from integer
without a cast [-Werror]
src/zbeacon.c:281:13: error: (near initialization for
‘pollitems[1].poller’) [-Werror]
cc1: all warnings being treated as errors
make[1]: *** [src/src_libczmq_la-zbeacon.lo] Error 1
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] CZMQ and Server and Client Sockets

[Brian Knox]

Makes sense to me!  The API is close enough to the other poller
implementations that there's no surprises.

Cheers!
Brian

On Sat, Aug 15, 2015 at 5:21 PM, Doron Somech  wrote:

> Polling on multiple thread safe socket is a little bit different, because
> thread safe doesn't have a FD, so we need to create one for all thread safe
> sockets for each thread before calling the zmq_poll.
>
> So I want to make it very close to the current API, this what I have so
> far:
>
> https://gist.github.com/somdoron/902169bf115d3534bd24
>
> zmq_poller_t is actually a FD, when added to the thread safe socket the
> socket will signal it once a command is ready, multiple sockets can use the
> same poller. When signalled the zmq_poll will check all sockets for events.
>
> What do you think?
>
>
>
> On Sat, Aug 15, 2015 at 5:54 PM, Brian Knox 
> wrote:
>
>> Doron - as a heads up, being able to poll multiple sockets from zpoller
>> would be of great interest to me (I use zpoller in goczmq quite a bit).
>>
>> Cheers,
>> Brian
>>
>> On Sat, Aug 15, 2015 at 3:48 AM, Doron Somech  wrote:
>>
>>> Andrew are you using CZMQ? which class do you use for multiple polling,
>>> zloop or zpoller?
>>>
>>> On Fri, Aug 14, 2015 at 10:36 PM, Andrew Simpson 
>>> wrote:
>>>
>>>> this sounds really excellent!  I am building an application that would
>>>> greatly benefit from this over a standard Router/Dealer setup.  The only
>>>> thing that will hold me back right now is the lack of polling on multiple
>>>> client/server sockets.  I definitely need that.
>>>>
>>>> Good stuff!
>>>>
>>>>
>>>>
>>>> On Friday, August 14, 2015 9:09 AM, Doron Somech 
>>>> wrote:
>>>>
>>>>
>>>>
>>>> Hi All,
>>>>
>>>> I added server and client sockets support to CZMQ, you can take a look
>>>> at the change at the following pull request:
>>>>
>>>> https://github.com/zeromq/czmq/pull/1059
>>>>
>>>> Server socket is like router socket except you don't have an identity
>>>> frame, each message also include routing id which is an int (vs byte
>>>> array). So each message coming from a server socket include a routing id
>>>> which can be retrieve by calling zframe_routing_id. When sending a message
>>>> you must set the routing id by calling zframe_set_routing_id. You can use
>>>> zframe_send_reply with both the destination frame and the source frame
>>>> (which include the routing id), the method copy the routing id from the
>>>> source frame to the destination frame and then send the message.
>>>>
>>>> Client socket is same as dealer socket. Client and Server can only talk
>>>> to each other.
>>>>
>>>> Following is a small example on how to use the new client and server
>>>> sockets:
>>>> https://gist.github.com/somdoron/542b74922f652d229566
>>>>
>>>> Client and server socket are thread safe (currently only support single
>>>> frame messages but that might change, I think) so if your protocol is
>>>> single frame you can use the server and client sockets from multiple
>>>> threads.
>>>>
>>>> Polling on multiple client or server sockets is not supported yet.
>>>>
>>>> In the coming week I plan to also add zproto support and complete the
>>>> polling on multiple sockets.
>>>>
>>>> Doron
>>>>
>>>>
>>>> ___
>>>> 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
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] CZMQ and Server and Client Sockets

[Brian Knox]

Doron - as a heads up, being able to poll multiple sockets from zpoller
would be of great interest to me (I use zpoller in goczmq quite a bit).

Cheers,
Brian

On Sat, Aug 15, 2015 at 3:48 AM, Doron Somech  wrote:

> Andrew are you using CZMQ? which class do you use for multiple polling,
> zloop or zpoller?
>
> On Fri, Aug 14, 2015 at 10:36 PM, Andrew Simpson 
> wrote:
>
>> this sounds really excellent!  I am building an application that would
>> greatly benefit from this over a standard Router/Dealer setup.  The only
>> thing that will hold me back right now is the lack of polling on multiple
>> client/server sockets.  I definitely need that.
>>
>> Good stuff!
>>
>>
>>
>> On Friday, August 14, 2015 9:09 AM, Doron Somech 
>> wrote:
>>
>>
>>
>> Hi All,
>>
>> I added server and client sockets support to CZMQ, you can take a look at
>> the change at the following pull request:
>>
>> https://github.com/zeromq/czmq/pull/1059
>>
>> Server socket is like router socket except you don't have an identity
>> frame, each message also include routing id which is an int (vs byte
>> array). So each message coming from a server socket include a routing id
>> which can be retrieve by calling zframe_routing_id. When sending a message
>> you must set the routing id by calling zframe_set_routing_id. You can use
>> zframe_send_reply with both the destination frame and the source frame
>> (which include the routing id), the method copy the routing id from the
>> source frame to the destination frame and then send the message.
>>
>> Client socket is same as dealer socket. Client and Server can only talk
>> to each other.
>>
>> Following is a small example on how to use the new client and server
>> sockets:
>> https://gist.github.com/somdoron/542b74922f652d229566
>>
>> Client and server socket are thread safe (currently only support single
>> frame messages but that might change, I think) so if your protocol is
>> single frame you can use the server and client sockets from multiple
>> threads.
>>
>> Polling on multiple client or server sockets is not supported yet.
>>
>> In the coming week I plan to also add zproto support and complete the
>> polling on multiple sockets.
>>
>> Doron
>>
>>
>> ___
>> 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] CZMQ and Server and Client Sockets

[Brian Knox]

This is great!  I need to make some time to experiment with GoCZMQ with
these - the thread safety opens up some possibilities.

On Fri, Aug 14, 2015 at 9:09 AM, Doron Somech  wrote:

> Hi All,
>
> I added server and client sockets support to CZMQ, you can take a look at
> the change at the following pull request:
>
> https://github.com/zeromq/czmq/pull/1059
>
> Server socket is like router socket except you don't have an identity
> frame, each message also include routing id which is an int (vs byte
> array). So each message coming from a server socket include a routing id
> which can be retrieve by calling zframe_routing_id. When sending a message
> you must set the routing id by calling zframe_set_routing_id. You can use
> zframe_send_reply with both the destination frame and the source frame
> (which include the routing id), the method copy the routing id from the
> source frame to the destination frame and then send the message.
>
> Client socket is same as dealer socket. Client and Server can only talk to
> each other.
>
> Following is a small example on how to use the new client and server
> sockets:
> https://gist.github.com/somdoron/542b74922f652d229566
>
> Client and server socket are thread safe (currently only support single
> frame messages but that might change, I think) so if your protocol is
> single frame you can use the server and client sockets from multiple
> threads.
>
> Polling on multiple client or server sockets is not supported yet.
>
> In the coming week I plan to also add zproto support and complete the
> polling on multiple sockets.
>
> Doron
>
>
> ___
> 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] Not receiving unsubscription messages in XPUB socket with ZMQ_XPUB_VERBOSE when using a proxy

[Brian Knox]

Ricardo - if you are lucky, there might be a loophole here for you to
exploit with a little lawyering.

"This is my preferred solution although it could break applications
that subscribe multiple times to the same topic and expect to stop
receiving messages only when they unsubscribe the same number of
times.  Although I'm not aware that this behavior is documented
which could mean it isn't really a problem."

Do you know if there is a specific test case for this behavior?  If your
change changes this behavior but does not break the test suite, I believe
it might be accepted.  One of the guiding principals for ZeroMQ development
is, paraphrased, "if you liked it should have put a test around it".  "A
breaking change" is usually interpreted to mean "it breaks the tests" (note
it's the wording Pieter used in his response).  If this behavior is not
documented and it is not tested you should be in good shape, as far as I
know.

Cheers,
Brian


On Tue, Jul 21, 2015 at 6:47 AM, Ricardo Catalinas Jiménez <
jimenezr...@gmail.com> wrote:

> Correction, I meant XSUB in point 1.
>
> On Tue, Jul 21, 2015 at 11:36:28AM +0100, Ricardo Catalinas Jiménez wrote:
> > [...]
> >
> > 1. Don't filter repeated unsubscribe messages in *XSUB*...
> >
> > [...]
>
>
> /Ricardo
> ___
> 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] Not receiving unsubscription messages in XPUB socket with ZMQ_XPUB_VERBOSE when using a proxy

[Brian Knox]

Do we have any other cases where a flag accepts more than one value?  As
far as I know, we don't, and in that case it would be my preference to use
a new flag than to have "modes" for a flag other than on and off.  I
certainly don't speak for everyone though, and according to our own
development method I shouldn't be a gate keeper if your PR solves a problem
unless your PR breaks compatibility / tests or doesn't follow the style
guidelines.

Sometimes the best way to find out what opinions are out there is to submit
the PR, which will either generate discussion or be accepted - after which
if people have issue with the implementation, they'll submit a follow up PR.

Cheers,
Brian

On Tue, Jul 21, 2015 at 9:11 AM, Ricardo Catalinas Jiménez <
jimenezr...@gmail.com> wrote:

> OK, this is my definitive proposed solution, which is a bit simpler and
> should keep everyone happy. If nobody sees an obstacle here, I'll
> prepare soon a pull request with this changes:
>
> 1. As I described before, don't filter repeated unsubscribe messages in
>XSUB. This shouldn't break any API contract.
>
> 2. Instead of adding a new flag, add a new accepted value by the already
>existing ZMQ_XPUB_VERBOSE, so from now on, apart from accepting 0 and
>1, this flag will also accept 2, making unsubscribe messages algo
>verbose (no filtering). This is a small incremental change to the API
>that doesn't break anything. This new value should be used always in
>proxies and optionally it can be use in applications that want this
>    behavior.
>
> Hope this sounds more sensible.
>
> On Tue, Jul 21, 2015 at 08:02:54AM -0400, Brian Knox wrote:
> > Ricardo - if you are lucky, there might be a loophole here for you to
> > exploit with a little lawyering.
> >
> > "This is my preferred solution although it could break applications
> > that subscribe multiple times to the same topic and expect to stop
> > receiving messages only when they unsubscribe the same number of
> > times.  Although I'm not aware that this behavior is documented
> > which could mean it isn't really a problem."
> >
> > Do you know if there is a specific test case for this behavior?  If your
> > change changes this behavior but does not break the test suite, I believe
> > it might be accepted.  One of the guiding principals for ZeroMQ
> development
> > is, paraphrased, "if you liked it should have put a test around it".  "A
> > breaking change" is usually interpreted to mean "it breaks the tests"
> (note
> > it's the wording Pieter used in his response).  If this behavior is not
> > documented and it is not tested you should be in good shape, as far as I
> > know.
> >
> > Cheers,
> > Brian
> >
> >
> > On Tue, Jul 21, 2015 at 6:47 AM, Ricardo Catalinas Jiménez <
> > jimenezr...@gmail.com> wrote:
> >
> > > Correction, I meant XSUB in point 1.
> > >
> > > On Tue, Jul 21, 2015 at 11:36:28AM +0100, Ricardo Catalinas Jiménez
> wrote:
> > > > [...]
> > > >
> > > > 1. Don't filter repeated unsubscribe messages in *XSUB*...
> > > >
> > > > [...]
> > >
> > >
> > > /Ricardo
> > > ___
> > > zeromq-dev mailing list
> > > zeromq-dev@lists.zeromq.org
> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > >
>
>
> /Ricardo
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Not receiving unsubscription messages in XPUB socket with ZMQ_XPUB_VERBOSE when using a proxy

[Brian Knox]

Aha! In that case, I think adding the extra flag is the right choice.  An
additive change is better than a breaking change.  I agree that off the top
of my head I'm not sure what this behavior is leveraged for, but that
certainly doesn't mean it's not being used in a way that's useful to
someone.

Cheers,
Brian

On Tue, Jul 21, 2015 at 8:13 AM, Ricardo Catalinas Jiménez <
jimenezr...@gmail.com> wrote:

> On Tue, Jul 21, 2015 at 08:02:54AM -0400, Brian Knox wrote:
> > Ricardo - if you are lucky, there might be a loophole here for you to
> > exploit with a little lawyering.
> >
> > "This is my preferred solution although it could break applications
> > that subscribe multiple times to the same topic and expect to stop
> > receiving messages only when they unsubscribe the same number of
> > times.  Although I'm not aware that this behavior is documented
> > which could mean it isn't really a problem."
>
> Well, unfortunately it's documented, so any change on this would break
> the contract fo the current API. Although I don't find much value in
> this behavior because it just add complexity, this is what the current
> doc says:
>
> ZMQ_UNSUBSCRIBE:
>
> "If the socket has several instances of the same filter attached the
> ZMQ_UNSUBSCRIBE option shall remove only one instance, leaving the rest
> in place and functional."
>
> Which implicitly is referring to the reference counting happening
> underneath. So, unless someone with authority says we should modify
> this, I guess it's something we shouldn't touch.
>
> > Do you know if there is a specific test case for this behavior?  If your
> > change changes this behavior but does not break the test suite, I believe
> > it might be accepted.  One of the guiding principals for ZeroMQ
> development
> > is, paraphrased, "if you liked it should have put a test around it".  "A
> > breaking change" is usually interpreted to mean "it breaks the tests"
> (note
> > it's the wording Pieter used in his response).  If this behavior is not
> > documented and it is not tested you should be in good shape, as far as I
> > know.
>
> /Ricardo
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zsock_new_

[Brian Knox]

Andrew - in my case, I git cloned it and built it from the repo - should
work fine from go get as well though.  I just deleted it from my pkg
directory and reinstalled with go get - no issues with that either.

Pieter - yeah - not having any issues against czmq 3.0.1, 3.0.2, or head
from git, it's working.  Thanks for the info!

Brian

On Mon, Jun 8, 2015 at 4:57 PM, Andrew Hume  wrote:

> “reckoned goczmq and built it”
> what does that mean?
> is that just the go get command, or is there more?
>
> On Jun 8, 2015, at 12:44 PM, Brian Knox  wrote:
>
> Andrew -
>
> I blew away my zeromq and czmq libs as well as my goczmq build.  Then I
> rebuilt zeromq-4.1.1 and czmq-3.0.1 from their stable release tarballs,
> recloned goczmq and built it.  All tests are passing.
>
> After that, I deleted the libczmq libs and rebuilt czmq from the 3.0.2
> release tarball, then rebuild goczmq against it - tests worked then too.
>
> Do you have a series of steps I can follow to try to reproduce the issue?
>
>
>
> On Mon, Jun 8, 2015 at 3:34 PM, Brian Knox  wrote:
>
>> Hi Andrew - it's working here last I checked, which was right after the
>> latest libzmq and czmq stable releases.  I'll clean up my environment and
>> reinstall from scratch after work today to double check and let you know.
>>
>> Brian
>>
>> On Mon, Jun 8, 2015 at 3:00 PM, Andrew Hume  wrote:
>>
>>> gack. i am having trouble with the tastes goczmq.
>>> it complains about an unsatisfied external zsock_new_ and zsock_destroy_
>>> is this related to the latest czmq changes? it fails with czm1 3.0.1 and
>>> 3.0.2
>>>
>>> ___
>>> 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] zsock_new_

[Brian Knox]

Andrew -

I blew away my zeromq and czmq libs as well as my goczmq build.  Then I
rebuilt zeromq-4.1.1 and czmq-3.0.1 from their stable release tarballs,
recloned goczmq and built it.  All tests are passing.

After that, I deleted the libczmq libs and rebuilt czmq from the 3.0.2
release tarball, then rebuild goczmq against it - tests worked then too.

Do you have a series of steps I can follow to try to reproduce the issue?



On Mon, Jun 8, 2015 at 3:34 PM, Brian Knox  wrote:

> Hi Andrew - it's working here last I checked, which was right after the
> latest libzmq and czmq stable releases.  I'll clean up my environment and
> reinstall from scratch after work today to double check and let you know.
>
> Brian
>
> On Mon, Jun 8, 2015 at 3:00 PM, Andrew Hume  wrote:
>
>> gack. i am having trouble with the tastes goczmq.
>> it complains about an unsatisfied external zsock_new_ and zsock_destroy_
>> is this related to the latest czmq changes? it fails with czm1 3.0.1 and
>> 3.0.2
>>
>> ___
>> 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] zsock_new_

[Brian Knox]

Hi Andrew - it's working here last I checked, which was right after the
latest libzmq and czmq stable releases.  I'll clean up my environment and
reinstall from scratch after work today to double check and let you know.

Brian

On Mon, Jun 8, 2015 at 3:00 PM, Andrew Hume  wrote:

> gack. i am having trouble with the tastes goczmq.
> it complains about an unsatisfied external zsock_new_ and zsock_destroy_
> is this related to the latest czmq changes? it fails with czm1 3.0.1 and
> 3.0.2
>
> ___
> 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] License statement in source headers

[Brian Knox]

No objections here.

On Tue, Jun 2, 2015 at 4:06 PM, Pieter Hintjens  wrote:

> Hi all,
>
> It's been pointed out to me that the libzmq sources all refer to the
> LGPLv3 and not the ZeroMQ COPYING.LESSER with its static link
> exception.
>
> Does anyone object if I change all the source headers to point to the
> COPYING.LESSER and to include the text of the special exception?
>
> -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

Re: [zeromq-dev] Adding CURVE support to JZMQ version 3.1.0

[Brian Knox]

I don't use jzmq myself but this is great!  Will be glad to test with
goczmq when you are ready!
On May 27, 2015 7:09 PM, "Arthur Low - Crack Semiconductor" <
a...@cracksemi.com> wrote:

> OK - Good news!
>
> I have the client-side CURVE support now working with my modified
> ZAuth.java
> and Socket.cpp, as described. The message was due to how I was configuring
> the CURVE server.
>
> I successfully CURVE - authenticated a JZMQ-based MDP client against a
> broker written in Python.
>
> I have not verified the server-side operations. When I get that, I will
> work
> out how to submit my changes back into the JZMQ project.
>
> If anyone wants to help, let me know/
>
> Art
>
>
> ___
> 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] zproject and zactors

[Brian Knox]

Kevin - thanks for the feedback!  Next time I get back to it, I'll keep
careful track of each step I make, and if I run into an issue again I'll
send all the information your way.

Cheers,
Brian

On Sun, May 17, 2015 at 3:56 PM, Kevin Sapper 
wrote:

> Hi Brian,
>
> the current actors in zproject are modeled after the implementation in
> zyre. I did find them quite useful when designing an application with many
> actors. The generated actors work fine for me and I'm probably the only who
> did use them so far. It would be nice to have someone else evaluate them.
>
> Regarding the project setup/installation it would be helpful to know where
> in the process you did fail and which steps succeed.
>
> //Kevin
>
> On Sa, 2015-05-16 at 14:55 -0400, Brian Knox wrote:
>
> Thanks for the feedback Pieter - will sit down with it again when I get a
> chance!
>
> Brian
>
> On Sat, May 16, 2015 at 12:58 PM, Pieter Hintjens  wrote:
>
> We're using zproject on CZMQ and several other projects, so it's live.
> It's built from a lot of different generators, the actor generator
> being one of them. Your milage may vary, as these are not all equally
> mature or widely used. I've not tried the actor generator myself.
>
> However you've got something more basic wrong IMO. The workflow is
> "gsl project.xml", which runs the various generators your project file
> requires. You start with a simple project.xml, then expand on it.
>
> I guess an empty project.xml looks like this:
>
>  name = "hello"
> description = "Hello World"
> script = "zproject.gsl"
> email = "he...@world.com"
> >
> 
> 
> 
>
> -Pieter
>
> On Sat, May 16, 2015 at 3:21 PM, Brian Knox 
> wrote:
> > I've got a project in mind where a set of zactors that provide various
> > services would be an excellent fit.  Digging through zproject, I see that
> > zactors appear to be supported.  So, I've decided this is a great use
> case
> > to finally dive into zproject.
> >
> > Following the guide here - https://github.com/zeromq/zproject- the first
> > bump I've run into is make (in my project, after installing zproject and
> > setting up my project directory) is returning:
> >
> > make[1]: *** No rule to make target `zproject.gsl', needed by `all-am'.
> > Stop.
> >
> > zproject.gsl is currently in /usr/local/bin and I have a current build of
> > gsl.  I know gsl is working as I also use it for generating files for
> > goczmq.
> >
> > So - I'm looking for a) what I'm missing and b) some info on whether
> > zproject is ready for a test victim such as myself to attempt to generate
> > some zactors with it and provide questions and feedback.
> >
> > Cheers,
> > Brian
> >
> >
> >
> >
> >
> > ___
> > 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 
> listzeromq-dev@lists.zeromq.orghttp://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] zproject and zactors

[Brian Knox]

Thanks for the feedback Pieter - will sit down with it again when I get a
chance!

Brian

On Sat, May 16, 2015 at 12:58 PM, Pieter Hintjens  wrote:

> We're using zproject on CZMQ and several other projects, so it's live.
> It's built from a lot of different generators, the actor generator
> being one of them. Your milage may vary, as these are not all equally
> mature or widely used. I've not tried the actor generator myself.
>
> However you've got something more basic wrong IMO. The workflow is
> "gsl project.xml", which runs the various generators your project file
> requires. You start with a simple project.xml, then expand on it.
>
> I guess an empty project.xml looks like this:
>
>  name = "hello"
> description = "Hello World"
> script = "zproject.gsl"
> email = "he...@world.com"
> >
> 
> 
> 
>
> -Pieter
>
> On Sat, May 16, 2015 at 3:21 PM, Brian Knox 
> wrote:
> > I've got a project in mind where a set of zactors that provide various
> > services would be an excellent fit.  Digging through zproject, I see that
> > zactors appear to be supported.  So, I've decided this is a great use
> case
> > to finally dive into zproject.
> >
> > Following the guide here - https://github.com/zeromq/zproject- the first
> > bump I've run into is make (in my project, after installing zproject and
> > setting up my project directory) is returning:
> >
> > make[1]: *** No rule to make target `zproject.gsl', needed by `all-am'.
> > Stop.
> >
> > zproject.gsl is currently in /usr/local/bin and I have a current build of
> > gsl.  I know gsl is working as I also use it for generating files for
> > goczmq.
> >
> > So - I'm looking for a) what I'm missing and b) some info on whether
> > zproject is ready for a test victim such as myself to attempt to generate
> > some zactors with it and provide questions and feedback.
> >
> > Cheers,
> > Brian
> >
> >
> >
> >
> >
> > ___
> > 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] zproject and zactors

[Brian Knox]

I've got a project in mind where a set of zactors that provide various
services would be an excellent fit.  Digging through zproject, I see that
zactors appear to be supported.  So, I've decided this is a great use case
to finally dive into zproject.

Following the guide here - https://github.com/zeromq/zproject- the first
bump I've run into is make (in my project, after installing zproject and
setting up my project directory) is returning:

make[1]: *** No rule to make target `zproject.gsl', needed by `all-am'.
Stop.

zproject.gsl is currently in /usr/local/bin and I have a current build of
gsl.  I know gsl is working as I also use it for generating files for
goczmq.

So - I'm looking for a) what I'm missing and b) some info on whether
zproject is ready for a test victim such as myself to attempt to generate
some zactors with it and provide questions and feedback.

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

[zeromq-dev] GoCZMQ "release" and breaking change

[Brian Knox]

I wanted to give a heads up that Luna and I are working on finalizing a few
things in GoCZMQ to declare a stable release (since CZMQ 3 is being cut
soon, and this is the API GoCZMQ targets).

We have one upcoming breaking change and then I believe that should be it.
We have some C-isms in the code (upper case constants, upper case function
names such as NewDEALER, etc) that break go style conventions.  These will
be cleaned up.

The good news is go has a nice refactoring tool, gorename (
https://godoc.org/golang.org/x/tools/cmd/gorename ) that should make it
pretty simple to fix any code that depends on GoCZMQ.

Commit 0485876f43de5e8fab40430be7cb49ad3ef97764 is a good commit to pin to
if you are using GoCZMQ and don't want to make the changes immediately.

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

[zeromq-dev] Malamute make check segfault

[Brian Knox]

Was building malamute today and noticed that make check is segfaulting when
trying to send
Running malamute selftests...
 * mlm_proto:OK
 * mlm_server: OK
 * mlm_client:
N: 15-05-06 15:39:15 server is using PLAIN security
connecting frontend to broker
connecting backend to broker
setting frontend service
setting backend service
sending frontend address SET message
sending backend address SET message
make[2]: *** [check-local] Segmentation fault (core dumped)
make[2]: Leaving directory `/home/bknox/git/malamute'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/bknox/git/malamute'
make: *** [check-recursive] Error 1

I'm using a pretty recent build of both libzmq and czmq (couple of weeks
old off of head at the most)

If I have time this evening to dig into it will do so, just wanted to give
a heads up!

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

Re: [zeromq-dev] libzmq and czmq releases

[Brian Knox]

That's great news Pieter.  It is not urgent - the next rsyslog release will
be in ~ 4 to 5 weeks.  If the next libzmq and czmq releases were in the
same time frame, that would be excellent.

Cheers,
Brian

On Tue, Apr 14, 2015 at 12:21 PM, Pieter Hintjens  wrote:

> I'm planning to cut stable releases of libzmq and czmq any time now.
> If you need these urgently, let me know. It's a matter of a few hours'
> work.
>
> -Pieter
>
> On Tue, Apr 14, 2015 at 4:30 PM, Brian Knox 
> wrote:
> > While I am happy living in the land of "build zeromq and czmq from head
> > every day" - I'd like to get zeromq enabled rsyslog packages as part of
> the
> > next rsyslog release (8.10).
> >
> > This will mean creating zeromq and czmq packages as part of the
> dependencies
> > for a few linux distros, because I build my latest plugins for rsyslog
> > against current libzmq and czmq head (and goczmq, which I'm using to
> write
> > some utilities for working with logs over zeromq, also is happiest
> against
> > czmq head).
> >
> > Is there anything much in the way of cutting a versioned release for
> libzmq
> > and czmq?  It makes getting packages built for non rolling release linux
> > distros simpler, since they like their version numbers.
> >
> > Brian
> >
> > ___
> > 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] libzmq and czmq releases

[Brian Knox]

While I am happy living in the land of "build zeromq and czmq from head
every day" - I'd like to get zeromq enabled rsyslog packages as part of the
next rsyslog release (8.10).

This will mean creating zeromq and czmq packages as part of the
dependencies for a few linux distros, because I build my latest plugins for
rsyslog against current libzmq and czmq head (and goczmq, which I'm using
to write some utilities for working with logs over zeromq, also is happiest
against czmq head).

Is there anything much in the way of cutting a versioned release for libzmq
and czmq?  It makes getting packages built for non rolling release linux
distros simpler, since they like their version numbers.

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

Re: [zeromq-dev] Canonical language for the Guide

[Brian Knox]

I think that C/CZMQ is a reasonable choice.

I'm intrigued by the idea of being able to generate examples in different
languages from a DSL - but concerned it might add confusion instead of
clarity.

Brian



On Tue, Apr 7, 2015 at 2:35 PM, Gregg Irwin  wrote:

> Hi Pieter,
>
> PH> What's the best canonical language?
>
> PH> My personal preference is C/CZMQ, which is high level and clean.
>
> PH> My second choice would be a high level modeling language.
>
> +1
>
> While my only daily C is the vitamin, I think C is the best choice. As
> you say, you will never please everyone. Of course, I'm also a huge
> fan of DSLs and code generators. The issue I see in this context is
> that the bindings, and 0MQ itself, are moving targets. The upside is
> that the old generators are still valid even as you create new
> templates when change comes.
>
> If you can keep the DSL/MOP simple enough, it could be a win even if
> only used for the C examples. The more general it needs to be, the
> more gratification may be delayed. Do you have thoughts or examples on
> the language or output side already gestating?
>
> -- Gregg
>
> ___
> 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 FOSDEM IoT videos online

[Brian Knox]

It was great seeing you at FOSDEM and learning about your project!

Brian

On Thu, Mar 19, 2015 at 10:28 AM, Arnaud Loonstra 
wrote:

> Hi all,
>
> I just received notice that the videos of the IoT devroom which Pieter
> organised at FOSDEM this year are online.
>
> I have given a talk about ZOCP. ZOCP is build on top of Zyre thus the
> presentation includes an introduction and explanation of the Zyre
> framework.
>
>
> http://mirror.as35701.net/video.fosdem.org//2015/devroom-internet_of_things/deviot02.mp4
>
> More info about the talk here:
> https://fosdem.org/2015/schedule/event/deviot02/
>
> Rg,
>
> Arnaud
> ___
> 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] Software versioning / contracts / SBOM

[Brian Knox]

I'd be glad to engage in this experiment with goczmq.

Brian


On Sat, Feb 7, 2015 at 7:27 AM, Pieter Hintjens  wrote:

> Hi all,
>
> After that fun and helpful thread on multipart et al, I'd like to open
> another discussion, on software versioning.
>
> I've written up a proposal at http://hintjens.com/blog:85.
>
> Mainly, I'd like to try to deliver a manifest of contracts (draft,
> stable, legacy, retired), rather than a stable version of any given
> project.
>
> This is meant to allow much more reliable packaging of github master,
> and long term interoperability.
>
> It depends on two non-trivial cultural shifts, already in process:
>
> 1. much more emphasis on documented contracts (RFCs, APIs, file formats)
> 2. contract-based testing, rather than product-based testing.
>
> For example, I'd like to make test cases for libzmq that are separate
> from the library and which can be run on all versions of the software,
> old and new and future. This is far more secure than having the tests
> part of the software. E.g., we broke some contracts in 4.x because
> people modified the test cases along with their code.
>
> I will start with either libzmq or czmq, with separate -sbom projects
> that test the contracts for arbitrary versions of these projects. I'll
> probably end up using GSL to generate the necessary code, as this has
> worked well in zproto and zproject.
>
> Thoughts and comments welcome, particularly from packagers and those
> who build on top of libzmq, czmq, etc.
>
> -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

Re: [zeromq-dev] Notes from a hackathon

[Brian Knox]

After catching up on this thread, I feel like at least three problems are
being conflated into one problem.  I'll state what I see being discussed
from my perspective:

1. "Using multi part messages as a way to route to clients from a router
socket is overly complicated and not how new users expect things to work"

2. "Using multi part messages for message serialization is costly, and
potentially confusing to others."

3. "ZeroMQ sockets are not thread safe."

While on an implementation level these three problems may be related, on a
conceptual level I don't see them as related.  I may agree with some of
these problem statements and not others.

For me, my first priority is to always have the ability to get back a nice
agnostic blob of bytes from ZeroMQ.   This makes it easy to make ZeroMQ
socket use compatible with standard io interfaces in Go.  Structure for
what is contained in those bytes is a concern of a different layer.
Sometimes I use zproto for this (which I like), and other times I don't.

As a demonstration that the problems are different problems, I solved #1
for myself in goczmq without addressing anything else.

I would assert some of the confusion in this discussion is that we're
talking about multiple problem statements at the same time.

Cheers - and it was great meeting people this week!

Brian




On Wed, Feb 4, 2015 at 12:50 AM, Pieter Hintjens  wrote:

> Ironically, in my testing of high message rate), allowing multipart
> creates significant costs. Multipart is just one way of getting
> zero-copy, and even then only works on writing, not reading.
>
> For high performance brokers like Malamute I'd *really* like to be
> moving blobs around instead of lists of blobs.
>
>
> On Wed, Feb 4, 2015 at 12:41 AM, Gregg Irwin 
> wrote:
> > M> Perhaps it is because I spend my days in a higher level language
> > M> like Python, but zproto is not an attractive option.
> >
> > Same here. I will read in detail about it shortly, but it may not make
> > it into my toolbox as a multipart replacement. Multipart looked very
> > cool when I found 0MQ, but I've ended up not using it much. I'm not
> > doing high performance stuff though. Simplicity and ease of use are
> > tops on my list.
> >
> > -- Gregg
> >
> > ___
> > 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] Notes from a hackathon

[Brian Knox]

Doron - yup, this was just an implementation for the current router
sockets  that makes them simpler to work with.

In the case of a single frame message containing the id, as long as the id
is a consistent length then I can slice the id and payload out of the
[]byte trivially.

My one ask on this is we do NOT have the ability to set their own socket id
on the SERVER and CLIENT sockets.  Right now the default id length a ROUTER
assigns is small, but a user can set an id of up to 255 bytes - having a
single consistent length for an id would be much simpler.

Cheers,
Brian

On Mon, Feb 2, 2015 at 8:06 PM, Doron Somech  wrote:

> Brian -
>
> The issue is that with the new api and to enable thread safety the routing
> id is part of the message. So czmq new api should somehow expose routing id
> on the message and/or part of the send message.
> On Feb 2, 2015 7:39 PM, "Brian Knox"  wrote:
>
>> Doron -
>>
>> I did a test implementation around this idea in goczmq today and I'm
>> liking the semantics.  I wrote an interface that conforms to io.Reader and
>> io.Writer where you pass a call a byte buffer and you get the message
>> placed into it.
>>
>> When the socket is a router socket, it silently drops the ID frame under
>> the hood, but sets a lastClientID in the socket struct, that if you need,
>> you can get with a GetLastClientID call.
>>
>> For reference:
>>
>> https://github.com/zeromq/goczmq/blob/master/sock.go#L35 (note "strings"
>> in go are just immutable byte arrays)
>>
>> https://github.com/zeromq/goczmq/blob/master/sock.go#L333
>>
>> https://github.com/zeromq/goczmq/blob/master/sock.go#L366
>>
>> So if the socket is a router, the Write call just transparently uses the
>> lastClientID value.  In a one to one request / reply, you then don't need
>> to think about it at all, and if you need to do async work, you can get and
>> set the id as needed.
>>
>> I'll just move this to use the new API later - just wanted to try it out
>> and see how I liked it, and I say thumbs up to dropping frames on the new
>> Server / Client sockets.
>>
>>
>>
>> On Mon, Feb 2, 2015 at 4:37 PM, Doron Somech  wrote:
>>
>>> So the new sockets are in the github master, you can take a loot at the
>>> test to see how to use the new routing id field:
>>>
>>> https://github.com/zeromq/libzmq/blob/master/tests/test_client_server.cpp
>>>
>>> Few of the reasons I didn't like multi frames:
>>> * I tried in the past to make both zeromq and NetMQ thread safe, think
>>> of sending from multiple threads or receiving from multiple threads. we
>>> cannot do that with Multipart.
>>> * There are a lot of good transport that already implement message
>>> framing (UDP, WebSockets, SCTP and even HTTP), but because zeromq required
>>> it is own framing it was not easy to add them.
>>> * Multipart, router usage (routing id frame) and not being thread safe
>>> make the learning curve of zeromq hard to beginners. Without three of them
>>> zeromq become much simpler.
>>> * At least with NetMQ single part message is much faster than multipart.
>>> * New stacks, multipart is complicated to implement, with the new API it
>>> will much more easier to implement new stacks (like JSMQ) or any native
>>> stack.
>>>
>>> Pieter I'm looking forward to see how you expose the routing id in the
>>> czmq API.
>>> I also like the czmq API for sending mutlipart messages (the picture
>>> feature) so maybe we can use that to generate single frame which is also
>>> compatible with zproto.
>>>
>>> About the implementation, none of new sockets support any option now.
>>> server behave like mandatory router, so when router is not reachable or
>>> highwater mark is reached an error will be returned.
>>>
>>> As ZMTP 3.1 is still in raw status, what do you think of removing the
>>> multipart from it? maybe the 3.1 will only support the new socket types.
>>>
>>> Anyway I really excited about this change.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Feb 2, 2015 at 4:17 PM, Thomas Rodgers 
>>> wrote:
>>>
>>>> What we really want IMO is per-peer metadata, and an API to get/set
>>>>> this. Using messages is a hack.
>>>>
>>>>
>>>> Currently working on that :)
>>>>
>>>> Having two layers that both
>>>>> carry per-message data is... wrong IMO.
>>>>
>&

Re: [zeromq-dev] Notes from a hackathon

[Brian Knox]

Doron -

I did a test implementation around this idea in goczmq today and I'm liking
the semantics.  I wrote an interface that conforms to io.Reader and
io.Writer where you pass a call a byte buffer and you get the message
placed into it.

When the socket is a router socket, it silently drops the ID frame under
the hood, but sets a lastClientID in the socket struct, that if you need,
you can get with a GetLastClientID call.

For reference:

https://github.com/zeromq/goczmq/blob/master/sock.go#L35 (note "strings" in
go are just immutable byte arrays)

https://github.com/zeromq/goczmq/blob/master/sock.go#L333

https://github.com/zeromq/goczmq/blob/master/sock.go#L366

So if the socket is a router, the Write call just transparently uses the
lastClientID value.  In a one to one request / reply, you then don't need
to think about it at all, and if you need to do async work, you can get and
set the id as needed.

I'll just move this to use the new API later - just wanted to try it out
and see how I liked it, and I say thumbs up to dropping frames on the new
Server / Client sockets.



On Mon, Feb 2, 2015 at 4:37 PM, Doron Somech  wrote:

> So the new sockets are in the github master, you can take a loot at the
> test to see how to use the new routing id field:
>
> https://github.com/zeromq/libzmq/blob/master/tests/test_client_server.cpp
>
> Few of the reasons I didn't like multi frames:
> * I tried in the past to make both zeromq and NetMQ thread safe, think of
> sending from multiple threads or receiving from multiple threads. we cannot
> do that with Multipart.
> * There are a lot of good transport that already implement message framing
> (UDP, WebSockets, SCTP and even HTTP), but because zeromq required it is
> own framing it was not easy to add them.
> * Multipart, router usage (routing id frame) and not being thread safe
> make the learning curve of zeromq hard to beginners. Without three of them
> zeromq become much simpler.
> * At least with NetMQ single part message is much faster than multipart.
> * New stacks, multipart is complicated to implement, with the new API it
> will much more easier to implement new stacks (like JSMQ) or any native
> stack.
>
> Pieter I'm looking forward to see how you expose the routing id in the
> czmq API.
> I also like the czmq API for sending mutlipart messages (the picture
> feature) so maybe we can use that to generate single frame which is also
> compatible with zproto.
>
> About the implementation, none of new sockets support any option now.
> server behave like mandatory router, so when router is not reachable or
> highwater mark is reached an error will be returned.
>
> As ZMTP 3.1 is still in raw status, what do you think of removing the
> multipart from it? maybe the 3.1 will only support the new socket types.
>
> Anyway I really excited about this change.
>
>
>
>
>
> On Mon, Feb 2, 2015 at 4:17 PM, Thomas Rodgers 
> wrote:
>
>> What we really want IMO is per-peer metadata, and an API to get/set
>>> this. Using messages is a hack.
>>
>>
>> Currently working on that :)
>>
>> Having two layers that both
>>> carry per-message data is... wrong IMO.
>>
>>
>> Protocols supporting 'out of band' data aren't exactly uncommon.
>>
>> However the key thing is, what's the problem. Then we can discuss
>>> solutions to that.
>>
>>
>> I don't have an immediate use-case justifying it. I noted it, mostly
>> because it has come up a few times since I started paying attention.
>>
>> On Mon, Feb 2, 2015 at 7:55 AM, Pieter Hintjens  wrote:
>>
>>> > It seems to me that in order to remove multi-part messages and
>>> introduce new
>>> > socket types (e.g. SERVER/CLIENT) that would
>>> > necessitate a revision of the wire protocol. If we are going to do
>>> that, it
>>> > might be worth considering per-message
>>> > metadata -
>>>
>>> We'd have to be very clear about the problem that per-message metadata
>>> is aiming for. There is an elegance to delivering blobs and nothing
>>> more. Metadata can be added on top using zproto.
>>>
>>> What we really want IMO is per-peer metadata, and an API to get/set
>>> this. Using messages is a hack. If we are sending/receiving data on a
>>> per-message basis, that is the message. Having two layers that both
>>> carry per-message data is... wrong IMO.
>>>
>>> However the key thing is, what's the problem. Then we can discuss
>>> solutions to that.
>>>
>>> -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

Re: [zeromq-dev] Notes from a hackathon

[Brian Knox]

I'll be pushing a change to goczmq in a little bit that implement something
similar to this for a io.Reader / io.Writer interface wrapped around zeromq
sockets - it's working very nicely!

Brian

On Mon, Feb 2, 2015 at 11:04 AM, Pieter Hintjens  wrote:

> Ironically I was writing a blog post decrying version numbers. But
> yes, this would perhaps be a V5 API. The thing is, we want to make the
> API contract work across many stacks, including libzmq, JeroMQ, CZMQ,
> NetMQ, etc. So we have evolved past software version numbers, perhaps.
>
> Let's consider this as a new generation of the API and protocol
> contract, document it as such (new RFCs, eventually), and eventually
> move the software stacks to support it, while also supporting older
> stable versions of the contracts.
>
> Brian Knox points out that SERVER and CLIENT also remove all stress of
> REQ / REP state machines. The caller decides: if you do straight recv
> request, send reply on SERVER, it'll work automatically. And if you do
> recv, recv, recv then you manage the routing IDs yourself... :-) Same
> for CLIENT replacing REQ.
>
> -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

Re: [zeromq-dev] zyre

[Brian Knox]

Excellent!

On Mon, Jan 19, 2015 at 8:18 AM, Andrew Hume  wrote:

> ahh, firewalld rears its ugly head.
> after allowing ports 5660, 5670 (and  for testing), it works just fine!
>
> excellent progress.
>
> On Jan 19, 2015, at 5:00 AM, Andrew Hume  wrote:
>
> that looks promising.
> i downloaded it and the chat example doesn’t work
> (of course, i’m not entirely sure what the chat example is supposed to do,
> but it seems like you can type messages and they should appear (labelled)
> in other chat windows.)
>
> i’ll take a poke at it and see if something obvious failed
> (i assume the author had it working at some point.)
>
> On Jan 19, 2015, at 4:24 AM, Brian Knox  wrote:
>
> There is gyre - it hasn't had any work done on it in quite awhile as far
> as I can tell, and I've never tried to use it:
>
> https://github.com/zeromq/gyre
>
> I'm currently working on a zproto template that is compatible with goczmq
> here -
> https://github.com/zeromq/goczmq/blob/master/zproto_codec_goczmq.gsl
>
> My first use for it will be generating a goczmq compatible zgossip
> protocol.
>
> Seeing if we can get a go implementation of gyre working with goczmq would
> be a fun thing to do.
>
> Brian
>
>
> On Mon, Jan 19, 2015 at 4:31 AM, Pieter Hintjens  wrote:
>
>> There are no Go bindings yet, afaik.
>>
>> On Mon, Jan 19, 2015 at 12:30 AM, Andrew Hume  wrote:
>> > are there any Go bindings for the API?
>> >
>> >> On Jan 18, 2015, at 10:14 AM, Pieter Hintjens  wrote:
>> >>
>> >> Zyre has come along nicely, it works well and has a clean API.
>> >>
>> >> On Sun, Jan 18, 2015 at 4:37 PM, Andrew Hume 
>> wrote:
>> >>> pieter,
>> >>>
>> >>>what is the status of zyre? including near term plans and so
>> forth?
>> >>>
>> >>> ___
>> >>> 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
>
>
> ___
> 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] zyre

[Brian Knox]

There is gyre - it hasn't had any work done on it in quite awhile as far as
I can tell, and I've never tried to use it:

https://github.com/zeromq/gyre

I'm currently working on a zproto template that is compatible with goczmq
here - https://github.com/zeromq/goczmq/blob/master/zproto_codec_goczmq.gsl

My first use for it will be generating a goczmq compatible zgossip protocol.

Seeing if we can get a go implementation of gyre working with goczmq would
be a fun thing to do.

Brian


On Mon, Jan 19, 2015 at 4:31 AM, Pieter Hintjens  wrote:

> There are no Go bindings yet, afaik.
>
> On Mon, Jan 19, 2015 at 12:30 AM, Andrew Hume  wrote:
> > are there any Go bindings for the API?
> >
> >> On Jan 18, 2015, at 10:14 AM, Pieter Hintjens  wrote:
> >>
> >> Zyre has come along nicely, it works well and has a clean API.
> >>
> >> On Sun, Jan 18, 2015 at 4:37 PM, Andrew Hume 
> wrote:
> >>> pieter,
> >>>
> >>>what is the status of zyre? including near term plans and so
> forth?
> >>>
> >>> ___
> >>> 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] gozmq beacon

[Brian Knox]

Andrew - the beacon uses IPv4 UDP broadcasts - so it could very well be a
networking issue.  Thanks for all the feedback by the way!  Feel free to
file issues you run into on the issue tracker as well, or hit me up on
#zeromq on freenode irc (I use the nickname taotetek there).

Once I get some coffee into me I'm going to see if I can reproduce the
other issue you were running into.

Brian

On Sun, Jan 18, 2015 at 7:43 AM, Andrew Hume  wrote:

> brian,
>
> maybe this is a setup issue.
> when i run it, the received beacon is empty, and the listener only returns
> after the timeout expires. (i changed the timeout to 5s to help debug
> this.)
> so i deduce the listener never gets what the publisher sends.
>
> can there be firewalls or some other networking crap interfering with this?
>
> On Jan 18, 2015, at 4:29 AM, Brian Knox  wrote:
>
> Andrew: what is actually published is the IP address of the beacon = so
> the "HI" in the example is a topic, and not what is actually received.  So,
> the publisher is publishing on topic "HI", and the subscriber is
> subscribing on topic "HI".   Running locally:
>
> ./b
> Beacon configured on: 192.168.1.199
> Beacon configured on: 192.168.1.199
> Received beacon: 192.168.1.199
>
> I'll fix the example code to the new function names, thanks for catching
> that.  Awhile back, we removed the "Z" prefixes from everything as they
> weren't necessary in a language that has package namespaces.
>
> Brian
>
>
> On Sun, Jan 18, 2015 at 12:17 AM, Andrew Hume  wrote:
>
>> brian,
>>
>> i copied the zbeacon example from the github site and ran it.
>> (i had to change NewZbeacon to NewBeacon.)
>>
>> it doesn’t work, in that listener.Recv is always returning an empty string
>> regardless of what is published.
>>
>> so either i don’t understand what is supposed to happen, or there is a
>> bug somewhere.
>>
>> ___
>> 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] gozmq beacon

[Brian Knox]

Andrew: what is actually published is the IP address of the beacon = so the
"HI" in the example is a topic, and not what is actually received.  So, the
publisher is publishing on topic "HI", and the subscriber is subscribing on
topic "HI".   Running locally:

./b
Beacon configured on: 192.168.1.199
Beacon configured on: 192.168.1.199
Received beacon: 192.168.1.199

I'll fix the example code to the new function names, thanks for catching
that.  Awhile back, we removed the "Z" prefixes from everything as they
weren't necessary in a language that has package namespaces.

Brian


On Sun, Jan 18, 2015 at 12:17 AM, Andrew Hume  wrote:

> brian,
>
> i copied the zbeacon example from the github site and ran it.
> (i had to change NewZbeacon to NewBeacon.)
>
> it doesn’t work, in that listener.Recv is always returning an empty string
> regardless of what is published.
>
> so either i don’t understand what is supposed to happen, or there is a bug
> somewhere.
>
> ___
> 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] zbeacon

[Brian Knox]

Andrew - this might be helpful - http://hintjens.com/blog:32

Note- I am not using the beacon code yet anywhere myself - goczmq has an
implementation that wraps the czmq API, with a simple unit test, and that's
about it at the moment.

Brian

On Sat, Jan 17, 2015 at 9:06 PM, Andrew Hume  wrote:

> is there reference prose describing the beacons and how they work?
>
> ___
> 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] troubles starting to use go czmq

[Brian Knox]

Added an issue for tracking this here -
https://github.com/zeromq/goczmq/issues/79

Cheers,
Brian

On Sat, Jan 17, 2015 at 8:34 PM, Brian Knox  wrote:

> Andrew - thanks so much for the feedback - tomorrow morning when I'm
> coding again, I'll build against those specific versions and see if I can
> reproduce
>
> On Sat, Jan 17, 2015 at 8:25 PM, Andrew Hume  wrote:
>
>> brian,
>>
>> i am using czmq-3.0.0-rc1 and zeromq-4.1.0.-rc1
>>
>> the result of a make build is
>>
>> find . -name \*.go -type f -exec gofmt -w {} \;
>> go get -t -v ./...
>> go test -v .
>> === RUN TestAuthIPAllow
>> I: 15-01-17 17:20:09 zauth: API command=ALLOW
>> I: 15-01-17 17:20:09 zauth: - whitelisting ipaddress=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: ZAP request mechanism=NULL ipaddress=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=200 status_text=OK
>> I: 15-01-17 17:20:09 zauth: API command=$TERM
>> --- PASS: TestAuthIPAllow (0.00s)
>> === RUN TestAuthPlain
>> I: 15-01-17 17:20:09 zauth: API command=ALLOW
>> I: 15-01-17 17:20:09 zauth: - whitelisting ipaddress=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: API command=PLAIN
>> I: 15-01-17 17:20:09 zauth: ZAP request mechanism=PLAIN
>> ipaddress=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: - allowed (PLAIN) username=admin
>> password=Password
>> I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=200 status_text=OK
>> I: 15-01-17 17:20:09 zauth: ZAP request mechanism=PLAIN
>> ipaddress=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
>> I: 15-01-17 17:20:09 zauth: - denied (PLAIN) username=admin
>> password=BadPassword
>> I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=400 status_text=No
>> access
>> I: 15-01-17 17:20:09 zauth: API command=$TERM
>> --- PASS: TestAuthPlain (0.20s)
>> === RUN TestAuthCurveAllow
>> goczmq.test: src/zsockopt.c:482: zsocket_set_curve_secretkey_bin:
>> Assertion `rc == 0 || zmq_errno () == (156384712 + 53)' failed.
>> SIGABRT: abort
>> PC=0x7f0ce5ba2877
>> signal arrived during cgo execution
>>
>> goroutine 7 [syscall, locked to thread]:
>> runtime.cgocall_errno(0x406070, 0xc20801d628, 0x0)
>> /usr/local/go/src/runtime/cgocall.go:130 +0xf5 fp=0xc20801d608
>> sp=0xc20801d5e0
>> github.com/zeromq/goczmq._Cfunc_zsocket_set_curve_secretkey_bin(0x7f0cd800ac90,
>> 0x7f0cd800d010)
>> github.com/zeromq/goczmq/_test/_obj_test/_cgo_gotypes.go:883 +0x45
>> fp=0xc20801d628 sp=0xc20801d608
>> github.com/zeromq/goczmq.(*Cert).Apply(0xc20802c088, 0xc20803c540)
>> /home/andrew/go/src/github.com/zeromq/goczmq/cert.go:75 +0x5e
>> fp=0xc20801d648 sp=0xc20801d628
>> github.com/zeromq/goczmq.TestAuthCurveAllow(0xc208056120)
>> /home/andrew/go/src/github.com/zeromq/goczmq/auth_test.go:211 +0x210
>> fp=0xc20801d778 sp=0xc20801d648
>> testing.tRunner(0xc208056120, 0x84e550)
>> /usr/local/go/src/testing/testing.go:447 +0xbf fp=0xc20801d7d0
>> sp=0xc20801d778
>> runtime.goexit()
>> /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20801d7d8
>> sp=0xc20801d7d0
>> created by testing.RunTests
>> /usr/local/go/src/testing/testing.go:555 +0xa8b
>>
>> goroutine 1 [chan receive]:
>> testing.RunTests(0x5d1ed8, 0x84e520, 0x40, 0x40, 0x7b05f8fffe641201)
>> /usr/local/go/src/testing/testing.go:556 +0xad6
>> testing.(*M).Run(0xc20802e0a0, 0x868fc0)
>> /usr/local/go/src/testing/testing.go:485 +0x6c
>> main.main()
>> github.com/zeromq/goczmq/_test/_testmain.go:178 +0x1d5
>>
>> goroutine 17 [syscall, locked to thread]:
>> runtime.goexit()
>> /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1
>>
>> rax 0x0
>> rbx 0x7f0ce6831000
>> rcx 0x
>> rdx 0x6
>> rdi 0x5be7
>> rsi 0x5be9
>> rbp 0x7f0ce5ce8b48
>> rsp 0x7f0ce493dc28
>> r8  0x1
>> r9  0xfefefefefeff092d
>> r10 0x8
>> r11 0x206
>> r12 0x7f0ce640df40
>> r13 0x7f0ce6418760
>> r14 0x2
>> r15 0xc20803c360
>> rip 0x7f0ce5ba2877
>> rflags  0x206
>> cs  0x33
>> fs  0x0
>> gs  0x0
>> exit status 2
>> FAIL github.com/zeromq/goczmq 0.212s
>> make: *** [test] Error 1
>>
>>
>> is that enough info for you?
>> if i do a go test -v beacon.go, i get
>>
>> [andrew@localhost goczmq]$ go test -v beacon.go
>> # c

Re: [zeromq-dev] troubles starting to use go czmq

[Brian Knox]

Andrew - thanks so much for the feedback - tomorrow morning when I'm coding
again, I'll build against those specific versions and see if I can reproduce

On Sat, Jan 17, 2015 at 8:25 PM, Andrew Hume  wrote:

> brian,
>
> i am using czmq-3.0.0-rc1 and zeromq-4.1.0.-rc1
>
> the result of a make build is
>
> find . -name \*.go -type f -exec gofmt -w {} \;
> go get -t -v ./...
> go test -v .
> === RUN TestAuthIPAllow
> I: 15-01-17 17:20:09 zauth: API command=ALLOW
> I: 15-01-17 17:20:09 zauth: - whitelisting ipaddress=127.0.0.1
> I: 15-01-17 17:20:09 zauth: ZAP request mechanism=NULL ipaddress=127.0.0.1
> I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
> I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=200 status_text=OK
> I: 15-01-17 17:20:09 zauth: API command=$TERM
> --- PASS: TestAuthIPAllow (0.00s)
> === RUN TestAuthPlain
> I: 15-01-17 17:20:09 zauth: API command=ALLOW
> I: 15-01-17 17:20:09 zauth: - whitelisting ipaddress=127.0.0.1
> I: 15-01-17 17:20:09 zauth: API command=PLAIN
> I: 15-01-17 17:20:09 zauth: ZAP request mechanism=PLAIN ipaddress=127.0.0.1
> I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
> I: 15-01-17 17:20:09 zauth: - allowed (PLAIN) username=admin
> password=Password
> I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=200 status_text=OK
> I: 15-01-17 17:20:09 zauth: ZAP request mechanism=PLAIN ipaddress=127.0.0.1
> I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
> I: 15-01-17 17:20:09 zauth: - denied (PLAIN) username=admin
> password=BadPassword
> I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=400 status_text=No
> access
> I: 15-01-17 17:20:09 zauth: API command=$TERM
> --- PASS: TestAuthPlain (0.20s)
> === RUN TestAuthCurveAllow
> goczmq.test: src/zsockopt.c:482: zsocket_set_curve_secretkey_bin:
> Assertion `rc == 0 || zmq_errno () == (156384712 + 53)' failed.
> SIGABRT: abort
> PC=0x7f0ce5ba2877
> signal arrived during cgo execution
>
> goroutine 7 [syscall, locked to thread]:
> runtime.cgocall_errno(0x406070, 0xc20801d628, 0x0)
> /usr/local/go/src/runtime/cgocall.go:130 +0xf5 fp=0xc20801d608
> sp=0xc20801d5e0
> github.com/zeromq/goczmq._Cfunc_zsocket_set_curve_secretkey_bin(0x7f0cd800ac90,
> 0x7f0cd800d010)
> github.com/zeromq/goczmq/_test/_obj_test/_cgo_gotypes.go:883 +0x45
> fp=0xc20801d628 sp=0xc20801d608
> github.com/zeromq/goczmq.(*Cert).Apply(0xc20802c088, 0xc20803c540)
> /home/andrew/go/src/github.com/zeromq/goczmq/cert.go:75 +0x5e
> fp=0xc20801d648 sp=0xc20801d628
> github.com/zeromq/goczmq.TestAuthCurveAllow(0xc208056120)
> /home/andrew/go/src/github.com/zeromq/goczmq/auth_test.go:211 +0x210
> fp=0xc20801d778 sp=0xc20801d648
> testing.tRunner(0xc208056120, 0x84e550)
> /usr/local/go/src/testing/testing.go:447 +0xbf fp=0xc20801d7d0
> sp=0xc20801d778
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20801d7d8
> sp=0xc20801d7d0
> created by testing.RunTests
> /usr/local/go/src/testing/testing.go:555 +0xa8b
>
> goroutine 1 [chan receive]:
> testing.RunTests(0x5d1ed8, 0x84e520, 0x40, 0x40, 0x7b05f8fffe641201)
> /usr/local/go/src/testing/testing.go:556 +0xad6
> testing.(*M).Run(0xc20802e0a0, 0x868fc0)
> /usr/local/go/src/testing/testing.go:485 +0x6c
> main.main()
> github.com/zeromq/goczmq/_test/_testmain.go:178 +0x1d5
>
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1
>
> rax 0x0
> rbx 0x7f0ce6831000
> rcx 0x
> rdx 0x6
> rdi 0x5be7
> rsi 0x5be9
> rbp 0x7f0ce5ce8b48
> rsp 0x7f0ce493dc28
> r8  0x1
> r9  0xfefefefefeff092d
> r10 0x8
> r11 0x206
> r12 0x7f0ce640df40
> r13 0x7f0ce6418760
> r14 0x2
> r15 0xc20803c360
> rip 0x7f0ce5ba2877
> rflags  0x206
> cs  0x33
> fs  0x0
> gs  0x0
> exit status 2
> FAIL github.com/zeromq/goczmq 0.212s
> make: *** [test] Error 1
>
>
> is that enough info for you?
> if i do a go test -v beacon.go, i get
>
> [andrew@localhost goczmq]$ go test -v beacon.go
> # command-line-arguments
> ./beacon.go:36: undefined: ErrActorCmd
> ./beacon.go:47: undefined: ErrActorCmd
> ./beacon.go:52: undefined: ErrActorCmd
> ./beacon.go:64: undefined: ErrActorCmd
> ./beacon.go:69: undefined: ErrActorCmd
> ./beacon.go:75: undefined: ErrActorCmd
> ./beacon.go:85: undefined: ErrActorCmd
> ./beacon.go:90: undefined: ErrActorCmd
>
>
> (beacon is the next thing i want to work on.)
>
> On Jan 17, 2015, at 12:32 PM, Brian Knox  wrote:
>
> Andrew - can you let me know which versions of both libzmq and czmq you
> are building go czmq again?
>
> All tes

Re: [zeromq-dev] what is the purpose of the Go binding for czmq?

[Brian Knox]

Peter -

I am just now getting to a point that I am thinking about the "go-isms"
that I want to build on top of the goczmq bindings myself (outside of
channeler.go, which Luna contributed, which I've used in a small
application now and I like).  I have some problems that I am working on
solving at work, so I've got some real world issues I'm exploring.  I don't
really have a set "plan" yet - things that I find that are useful to me,
I'll add.  Things other people send as pull requests that are useful, I
accept.  I anticipate that I'll experiment a lot and have some false starts
- it's a learning experience.

I'll second what Pieter suggested - consider moving the bindings into the
zeromq org, and try out the C4 process as a way to allow for low friction
contributions.  We seem to have gathered together a small group of people
with an interest in both go and zeromq at this point - with some cross
pollination of ideas I bet we can have some fun and build some useful
things!

Brian


On Sat, Jan 17, 2015 at 5:47 PM, Peter Kleiweg  wrote:

> Brian Knox schreef op de 17e dag van de louwmaand van het jaar 2015:
>
> > Peter - really, it was more about wanting to see how czmq worked as the
> > basis for a language binding (since I contributed some code to czmq),
> than
> > anything particularly lacking in zmq4.
>
> Ah, OK.
>
> I'm a bit insecure. Unsure of what to do with zmq4. I started
> implementing zmq3 after reading about ZeroMQ and the current Go
> binding (which was mainly for ZeroMQ 2, and hard to adjust for
> version 3), and I thought I might have much use for a technology
> like ZeroMQ myself.
>
> So I did zmq3, then zmq2. Then came version 4, and I did zmq4. I
> maintain all three versions. And when I add something to one
> version, I add it to the other versions as well, if possible.
>
> And I implemented all the examples from the tutorial.
>
> The thing is, I never actually got to using it myself. I have
> only one application running that has a PUB socket, and two apps
> with a SUB socket to the first app. Possibly the simplest of
> uses of ZeroMQ.
>
> Now, I have forgotten most of what I learned by doing the
> tutorial. Still, I want to keep zmq2/3/4 up-to-date. But I don't
> actually know about using these techniques in real world,
> complex situations. What are recurrent patterns? Are there
> patterns that could be useful enough and general enough to
> include in the package?
>
> After some discussion, I opened a wiki page for this stuff,
> demonstrations for how to do real world things with zmq4:
>
> https://github.com/pebbe/zmq4/wiki/DesignPatterns
>
> I was hoping for contributions by people using zmq4, but until
> now, nothing.
>
>
> --
> Peter Kleiweg
> http://pkleiweg.home.xs4all.nl/
> ___
> 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] what is the purpose of the Go binding for czmq?

[Brian Knox]

Peter - really, it was more about wanting to see how czmq worked as the
basis for a language binding (since I contributed some code to czmq), than
anything particularly lacking in zmq4.

The "zactor" based services in czmq (proxy, auth, beacon, gossip) are
interesting in that they spawn a non blocking background C thread, which
you then send commands to over a ZMQ_PAIR socket.  These services were
pretty fun to wrap with cgo and it was just interesting

The other thing I really wanted to do was use the C4 contribution process
for commits, and see if anyone else might find the project and contribute
things I hadn't though of (which Luna did, which was great fun)

I link to zmq4 in my readme and recommend it for people looking for
straight libzmq library, as I think it's a very nice one, and I've written
code using it, so thank you for making it!

If you're interested in suggestions or contributions, I'm happy to
collaborate!

Brian


On Sat, Jan 17, 2015 at 3:46 PM, Peter Kleiweg  wrote:

> Brian Knox schreef op de 17e dag van de louwmaand van het jaar 2015:
>
> > I'm the person who started the Go binding for CZMQ.  The number one
> purpose
> > for me, when I started it, was having fun.
>
> That is a valid reason.
>
> Was there anything in particular you found missing in zmq4?
>
>
> --
> Peter Kleiweg
> http://pkleiweg.home.xs4all.nl/
> ___
> 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] troubles starting to use go czmq

[Brian Knox]

I do see a couple of import paths that are set to my personal repo instead
of the goczmq repo in multiperf/multiperf.go, and perf/perf.go - I'll send
a pull request to fix those in just a moment.

On Sat, Jan 17, 2015 at 3:32 PM, Brian Knox  wrote:

> Andrew - can you let me know which versions of both libzmq and czmq you
> are building go czmq again?
>
> All tests are working for me and for Luna (who helps develop it).  If you
> give me a little info maybe we can figure out what you are running into.
>
> Cheers,
> Brian
>
> On Sat, Jan 17, 2015 at 10:39 AM, Andrew Hume  wrote:
>
>> ack on that.
>> i needed to set both LD_LIBRARY_PATH and PKG_CONFIG_PATH.
>>
>> so then
>> go get github.com/zeromq/goczmq
>> now succeeds (silently)
>> and i can then run the weather server example (server in one window,
>> client in another).
>>
>> if i go to github.com/zeromq/goczmq
>> can i do anything useful there?
>> i tried make build and make test and both fail on some tests.
>> are all the tests suppose to work?
>> i want to use zbeacon, and the beacon test fails with an “undefined:
>> ErrActorCmd”
>>
>> andrew
>>
>> On Jan 17, 2015, at 7:08 AM, Quinlan Morake  wrote:
>>
>> Hi,
>>
>> Most likely setting LD_LIBRARY_PATH to include where libczmq is will
>> resolve the issue; depending on how you installed libczmq, it sometimes
>> installs to /usr/local/lib64 or /usr/local/lib.
>>
>> Other than that, could be the pkg.config file, setting the PKG_CONFIG
>> environment variable to include wherever zmq.pc is.
>>
>> Quinlan
>>
>>
>> On 17 Jan 2015, at 15:03, Andrew Hume  wrote:
>>
>> i am gearing up to use czmq with the go binding.
>>
>> i have successfully installed zeromq and czmq, but when i do
>>
>> go get github.com/zeromq/goczmq
>>
>> it fails with “No package ‘libczmq’ found”.
>> this is also the first time i am using github, so it may be related to
>> that.
>>
>> any hints as to what i need to do?
>>
>> andrew
>>
>> ___
>> 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] troubles starting to use go czmq

[Brian Knox]

Andrew - can you let me know which versions of both libzmq and czmq you are
building go czmq again?

All tests are working for me and for Luna (who helps develop it).  If you
give me a little info maybe we can figure out what you are running into.

Cheers,
Brian

On Sat, Jan 17, 2015 at 10:39 AM, Andrew Hume  wrote:

> ack on that.
> i needed to set both LD_LIBRARY_PATH and PKG_CONFIG_PATH.
>
> so then
> go get github.com/zeromq/goczmq
> now succeeds (silently)
> and i can then run the weather server example (server in one window,
> client in another).
>
> if i go to github.com/zeromq/goczmq
> can i do anything useful there?
> i tried make build and make test and both fail on some tests.
> are all the tests suppose to work?
> i want to use zbeacon, and the beacon test fails with an “undefined:
> ErrActorCmd”
>
> andrew
>
> On Jan 17, 2015, at 7:08 AM, Quinlan Morake  wrote:
>
> Hi,
>
> Most likely setting LD_LIBRARY_PATH to include where libczmq is will
> resolve the issue; depending on how you installed libczmq, it sometimes
> installs to /usr/local/lib64 or /usr/local/lib.
>
> Other than that, could be the pkg.config file, setting the PKG_CONFIG
> environment variable to include wherever zmq.pc is.
>
> Quinlan
>
>
> On 17 Jan 2015, at 15:03, Andrew Hume  wrote:
>
> i am gearing up to use czmq with the go binding.
>
> i have successfully installed zeromq and czmq, but when i do
>
> go get github.com/zeromq/goczmq
>
> it fails with “No package ‘libczmq’ found”.
> this is also the first time i am using github, so it may be related to
> that.
>
> any hints as to what i need to do?
>
> andrew
>
> ___
> 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] what is the purpose of the Go binding for czmq?

[Brian Knox]

I'm the person who started the Go binding for CZMQ.  The number one purpose
for me, when I started it, was having fun.

Brian

On Sat, Jan 17, 2015 at 10:35 AM, Peter Kleiweg  wrote:

>
> I thought the main purpose of czmq is to eleviate the 'primitive'
> capabilities of the C language, making working with ZeroMQ in C
> easier. Czmq is also used in the examples for 0MQ - The Guide.
>
> I implemented a Go binding for ZeroMQ (github/pebbe/zmq4, zmq3,
> zmq2), and included Go versions of all examples from The Guide,
> without the need for czmq.
>
> Go already is a less primitive language then C. So why the need
> for a Go binding to czmq? Does czmq offer essential
> functionality that I am missing in my binding for ZeroMQ?
>
>
> --
> Peter Kleiweg
> http://pkleiweg.home.xs4all.nl/
> ___
> 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] czmq container serialization

[Brian Knox]

This is not something I would personally have any need for.  I'm not
certain that it is a general enough problem that it needs solving in czmq
itself, but maybe others feel differently.

Brian


On Mon, Jan 12, 2015 at 7:58 PM, Alex Cornejo  wrote:

> Hi all,
>
> As part of an application I am developing I need to serialize/unserialize a
> zlistx_t and a zhash_t into/from messages.
>
> In my particular use case, the elements stored in these containers
> belong to a custom czmq-style C class with its own
> my_class_new/my_class_destroy.
>
> When I first read the zhashx API I initially thought I could use
> zhashx_pack/zhashx_unpack (at least for the zhashx), but I soon realized
> this doesn't (and can't) work for custom types.
>
> The solution I adopted required the following changes:
>
> Implemented the following functions for the custom class:
>
> // return the size of self in bytes
> size_t my_class_size(my_class_t *self);
>
> // serialize the contents of self into buf.
> // the space used may not exceed my_class_size(self)
> void my_class_store(my_class_t *self, void *buf);
>
> // unserialize the contents of buf into a new my_class_t instance.
> my_class_t *myclass_load(void *buf);
>
> The behavior of myclass_store and myclass_load is such that the
> following
> is a valid implementation of myclass_dup:
>
> my_class_t *myclass_dup(myclass_t *self) {
> void *buf = zmalloc(my_class_size(self));
> myclass_store(self, buf);
> myclass_t *other = myclass_load(buf);
> free(buf);
> return other;
> }
>
> I also implemented the following methods for the container functions:
>
> typedef size_t (size_func_t)(void *);
> typedef void (store_func_t)(void *, void *);
> typedef void *(load_func_t)(void *);
>
> size_t zlistx_size(zlistx_t *self, size_func_t size_func);
> void zlistx_store(zlistx_t *self, void *buf, size_func_t size_func,
> store_func_t store_func);
> zlistx_t *zlistx_load(void *buf, size_func_t size_func, load_func_t
> load_func);
>
> size_t zhashx_size(zhashx_t *self, size_func_t size_func);
> void zhashx_store(zhashx_t *self, void *buf, size_func_t size_func,
> store_func_t store_func);
> zhashx_t *zhashx_load(void *buf, size_func_t size_func, load_func_t
> load_func);
>
> You will notice the load and store function signatures for zlistx and
> zhashx are
> different than for my_class, this is to accomodate for the fact that
> these are containers and therefore must also be able to load and store
> their elements.
>
> Using the above methods its quite trivial to serialze and unserialize
> lists and hashes into zframes for sending messages or into binary files
> for long term storage. The same container serailization methods can be used
> regardless of the type of elements they store, as long as they implement
> the required load/store/size API for these elements.
>
> Although the above works, I wanted to ask experienced czqm developers if
> there is a more elegant way to implement container
> serialization/unserialization in czmq.
>
> Also, I would be surprised to find that I am the first czmq user that
> needs to serialize custom containers into messages. Is there a reason
> something like this is not already included in czmq's core? Should I
> polish and document this and submit a pull-request, or does this seem
> like a very uncommon use of containers in the czmq world?
>
> Alex
>
>
> ___
> 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] Just a neat data visualisation

[Brian Knox]

If I don't finish a commit for goczmq today it's chris's fault now ;)

On Tue, Nov 11, 2014 at 1:13 PM, Brian Knox  wrote:

> ooh you can grab things with the mouse and throw them, and they bounce
> around!
>
> On Tue, Nov 11, 2014 at 1:11 PM, Pieter Hintjens  wrote:
>
>> That is weird and lovely and I can't see what the point is :-)
>>
>> On Tue, Nov 11, 2014 at 11:57 AM, Chris Laws  wrote:
>> > While search around for graph visualisers I encountered this novel data
>> > visualiser and plugged in zeromq to see a github account with lots more
>> > repo's than my user. Not sure about its usefulness and practicality but
>> it's
>> > neat all the same:
>> >
>> > http://ghv.artzub.com/#repo=czmq&climit=100&user=zeromq
>> >
>> > Lots of settings to tweak to adjust the data displayed.
>> >
>> > Enjoy.
>> >
>> >
>> >
>> > ___
>> > 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] Just a neat data visualisation

[Brian Knox]

ooh you can grab things with the mouse and throw them, and they bounce
around!

On Tue, Nov 11, 2014 at 1:11 PM, Pieter Hintjens  wrote:

> That is weird and lovely and I can't see what the point is :-)
>
> On Tue, Nov 11, 2014 at 11:57 AM, Chris Laws  wrote:
> > While search around for graph visualisers I encountered this novel data
> > visualiser and plugged in zeromq to see a github account with lots more
> > repo's than my user. Not sure about its usefulness and practicality but
> it's
> > neat all the same:
> >
> > http://ghv.artzub.com/#repo=czmq&climit=100&user=zeromq
> >
> > Lots of settings to tweak to adjust the data displayed.
> >
> > Enjoy.
> >
> >
> >
> > ___
> > 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] zproject - a project skeleton generator

[Brian Knox]

Can't wait to take this for a spin!

On Sun, Oct 26, 2014 at 6:11 PM, Pieter Hintjens  wrote:

> This is awesome. I've added you to the ZeroMQ owners group, so you can
> move that project into the ZeroMQ organization.
>
> On Sun, Oct 26, 2014 at 9:36 PM, Kevin Sapper 
> wrote:
> > Dear ZeroMQ developers and users,
> >
> > In the recent time a lot of new c-project have been created in the
> > zeromq community which use the czmq build environment. Instead of
> > maintaining all of these build files separately I suggest zproject
> > (https://github.com/sappo/zproject).
> >
> > zproject does several things:
> >
> > * generate files for cross-platform build environments
> > * generate header and sources files for new classes
> >
> > All you need is a project.xml. This is your "One file to rule them all".
> >
> > I like to move the project from my account to the zeromq organization.
> >
> > Regards
> > //Kevin
> >
> > ___
> > 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] CZMQ community & red cards

[Brian Knox]

I have directly addressed a statement about the CZMQ maintainers which was
factually incorrect.  This statement was not made by Pieter, it was made by
mrvn:

"That is something the czmq maintainers are exceedingly bad at. The sad
thing is the "we merge everything and then fix it if its broken"
behaviour is in direct opposition to the C4.1 rules."

As I have now stated more than once and documented, we do not "merge
everything and then fix it if it's broken."

I've already described my personal feelings about the side effects of
mrvn's involvement in the community, as was requested.

I have no interest in the rest of this discussion.

Brian

On Fri, Oct 17, 2014 at 9:10 AM,  wrote:

> >>>>> "Brian" == Brian Knox  writes:
>
> Roland>
> --
> Roland> Citation Brian
> Roland> (
> http://lists.zeromq.org/pipermail/zeromq-dev/2014-October/027554.html)
> Roland> "We do not merge everything and then fix it if it is
> Roland> broken. Your statement is empirically false."
>
> Roland> Citation Pieter (https://github.com/zeromq/czmq/pull/673):
> Roland> "I treat a pull request as a request to merge. I blindly
> Roland> merge everything, and fix up afterwards (or complain if that
> Roland> feels too painful) :-)"
>
> Roland> Hmm, which one is right now???
> Roland>
> -
>
> Brian> Here are the facts concerning my statement.
>
> Brian> 1) We have a continuous integration system in place
> Brian>(travis-ci).
>
> Brian> 2) All pull requests to CZMQ are run through travis-ci
> Brian>against multiple
> Brian> versions of libzmq:
> Brian> https://github.com/zeromq/czmq/blob/master/.travis.yml
>
> Brian> 3) When pull requests break the build on travis-ci,
> Brian>discussion takes place
> Brian> and in general the requests are not merged until they are
> Brian> fixed.  These discussions are easy to find.
>
> Sounds good. Thanks for the clarification. Unfortunately, breaking a
> build is only one aspect of broken code ... and usually the most
> harmless since easy to detect.
>
> Brian> 4) Nowhere in Pieter's statement does he say he merges broken
> Brian>code.
>
> In any case, the definition of "everything" as I know it, would mean
> ***everything*** which includes broken code. If you have a different
> definition, please elaborate.
>
> Roland
> ___
> 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] CZMQ community & red cards

[Brian Knox]

--
Citation Brian
(http://lists.zeromq.org/pipermail/zeromq-dev/2014-October/027554.html)
"We do not merge everything and then fix it if it is broken. Your statement
is empirically false."

Citation Pieter (https://github.com/zeromq/czmq/pull/673):
"I treat a pull request as a request to merge. I blindly merge everything,
and fix up afterwards (or complain if that feels too painful) :-)"

Hmm, which one is right now???
-

Here are the facts concerning my statement.

1) We have a continuous integration system in place (travis-ci).

2) All pull requests to CZMQ are run through travis-ci against multiple
versions of libzmq: https://github.com/zeromq/czmq/blob/master/.travis.yml

3) When pull requests break the build on travis-ci, discussion takes place
and in general the requests are not merged until they are fixed.  These
discussions are easy to find.

4) Nowhere in Pieter's statement does he say he merges broken code.


Brian



On Fri, Oct 17, 2014 at 7:29 AM,  wrote:

> > "Pieter" == Pieter Hintjens  writes:
>
> Hi Pieter,
>
> apart from a mini contribution (CVE assignment) my role in this project
> is only that of a user, but I don't think that should matter too much for
> the purpose of this discussion.
>
> In my opinion Goswin (who is working on ZMQ for a project here at
> Q-Leap) has been bashed enough now and I certainly don't want to negate
> the justification for the blame concerning some of his comments. But
> this discussion was extremely one-sided. I believe your behavior in this
> dissent had a lot of room for improvement as well.
>
> Pieter> Sorry... this is the last thread:
> Pieter> https://github.com/zeromq/czmq/pull/733
>
> Pieter> Related older threads from CZMQ:
>
> Pieter> - https://github.com/zeromq/czmq/pull/725
>
> Can't see any reason for a red card here.
>
> Pieter> - https://github.com/zeromq/czmq/pull/673
>
> Neither here.
>
> Let's cite some facts:
> ==
> Citation Pieter (https://github.com/zeromq/czmq/pull/733):
> "Making mistakes and doing broken things is part of our work. We deal
> with that politely, and nicely."
>
> Citation Pieter (https://github.com/zeromq/czmq/pull/673):
> "What are we supposed to do with that? I don't even want to read the
> code, it looks like vomit. ... Can you please remove all the crap"
> --
>
> Judge yourself. Your two statements sound like a contradiction to
> me. And it wasn't that Goswin started with this tone in 673. Would you
> have tolerated this from Goswin? If not, why do you tolerate it from
> yourself? Bringing in such a tone begs for aggressive answers ...
>
> ==
>
> Citation Pieter
> (http://lists.zeromq.org/pipermail/zeromq-dev/2014-October/027559.html )
> "You have not accepted any criticism at all. You show no regret, or
> apology."
>
> After a heated discussion in https://github.com/zeromq/czmq/pull/698,
> Goswin clearly shows his intent to play with the rules (last two
> comments).
>
> ==
>
> Citation Brian
> (http://lists.zeromq.org/pipermail/zeromq-dev/2014-October/027554.html)
> "We do not merge everything and then fix it if it is broken. Your statement
> is empirically false."
>
> Citation Pieter (https://github.com/zeromq/czmq/pull/673):
> "I treat a pull request as a request to merge. I blindly merge everything,
> and fix up afterwards (or complain if that feels too painful) :-)"
>
> Hmm, which one is right now???
>
> ==
>
> Final comments:
> ---
>
> Important rules for anyone to claim leadership: Obey the rules you set
> yourself. And be open for criticism (yes, it sometimes hurts).
>
> I think this episode and the whole discussion was not something, that this
> project can be proud of. You can just continue like you did, or start
> thinking about the mistakes, you made just like others should think about
> theirs to avoid them in the future. In my opinion, the latter would be
> highly
> beneficial for the actors credibility, authority and respect ... and the
> project ...
>
> It was my idea to contribute the stuff we're doing in the project at
> Q-Leap back to the community. But this obviously didn't work out. So be
> it. To be honest, now I don't really care anymore. For others being
> interested in the code we develop: We'll probably keep our repo
> available and updated at GitHub. Please note, this is not supposed to be
> a fork or anything abusive :) Take the code (if so with a copyright
> assignment) or leave it.
>
> If you still want me to do the CVE assignment for the project, that's
> fine

Re: [zeromq-dev] CZMQ community & red cards

[Brian Knox]

"That is something the czmq maintainers are exceedingly bad at. The sad
thing is the "we merge everything and then fix it if its broken"
behaviour is in direct opposition to the C4.1 rules."

We do not merge everything and then fix it if it is broken.  Your statement
is empirically false.

On Thu, Oct 16, 2014 at 12:30 PM, Goswin von Brederlow 
wrote:

> On Thu, Oct 16, 2014 at 05:37:54PM +0200, Benjamin wrote:
> > For me, "misleading" and "hiding" are quite strong words, and griwes
> > rant did not help.
>
> They are just words. Strong, weak? I'm not a walking theasurus or
> whatever that thing is called that lists lots of words meaning the
> same thing. I write mails like I talk, not like writing an essay for
> university admission that you rewrite 20 times until it is perfect.
> English is not my native language and I've always been bad a languages
> so I have even less words to choose from than other people.
>
> So I didn't pick those exact words because I wanted to put any
> emphasis on them. And I hope you do see a difference between "the
> title is misleading" and "you are misleading".
>
> Maybe a better wording would have been:
>
>I noticed that XX has code changes while the pull request says
>documentation changes. Did that get included there by accident?
>
> But that's too late now.
>
> > Linus has some strong views about Github which are related to your
> > points, especially how pull requests work [1]. But that's more of a
> > Github issue in general. In the end you need many people actively
> > engaged in checking code, right? So in that case checking the source
> > code changes (on the level commits or PR's?)
> >
> > https://github.com/torvalds/linux/pull/17#issuecomment-5654674
>
> Linus is also verry good (as in efficient and no nonsense) in
> rejecting commits that are bad or questionable. Because of that people
> get angry. But also all commits are sane and uniformly documented.
> Something that makes maintaining and fixing the code so much easier.
>
> That is something the czmq maintainers are exceedingly bad at. The sad
> thing is the "we merge everything and then fix it if its broken"
> behaviour is in direct opposition to the C4.1 rules. The C4.1 has some
> good rules but they only work if everybody follows them. That includes
> me but that also include him. One problem, one patch, one pull
> request. Not two unrelated problems in a single pull request.
>
> The smaller and more specific you make each pull request the easier it
> gets to read them even with githubs interface.
>
> MfG
> Goswin
> ___
> 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] CZMQ community & red cards

[Brian Knox]

I'll describe my overall feelings concerning this as best I can.

1. Recently, some of the interactions in the czmq pull request comments
have felt like a game of passive aggressive "point scoring" instead of
people working together to make useful software.
2. I've been involved with ZeroMQ for a decent amount of time now and this
experience was unexpected to me enough for me to be very taken aback by
it.  It is not at all what I expect.  The ZeroMQ community has been for
quite some time (since at least after the problems going from 2.x to 3.2)
been a nice sanctuary where I can focus on results.
3. When I first started contributing to CZMQ, I made some mistakes in the
form of some overly complex commits.  I have never been treated with
anything but respect and all of my interactions with other people have been
helpful.
4. The feelings of negativity, and the suspicions of passive aggressive
gamesmanship have quite frankly always been associated with @mrvn.
5. Since I have observed Pieter interact with many people throughout the
years, including myself, and never observed this in his interactions, I
tend to associate blame for this with @mrvn.

I'm trying to state my observations, from my perspective, without too much
emotion behind it.  I am, in fact, quite angry about this turn in tone in
the interactions in our community.

Brian

On Thu, Oct 16, 2014 at 5:56 AM, Pieter Hintjens  wrote:

> Hi all,
>
> I'd like to get feedback on a thread[1] regarding what I consider to
> be unacceptable behavior from a CZMQ contributor.
>
> There are many people here who use CZMQ and depend on it, and this
> thread is therefore relevant to you.
>
> My observation is that the contributor in question has tried to make
> large changes to CZMQ, driven by his use cases. So far, so good.
>
> However these changes added considerable complexity, and in some cases
> broke the existing APIs. The patches also ignored our coding style
> guidelines, despite repeated requests to confirm. We eventually made
> an automatic reformatter, which seems a sad solution to large and
> messy patches.
>
> CZMQ, like libzmq, is driven by small, incremental changes. The large
> shifts that we got from @mrvn were difficult to deal with, poorly
> argued (IMO) and inconsistent with our process, which demands small,
> focused answers to agreed problems.
>
> We now find ourselves in sniping. I don't have time or energy for
> this, given this contributor's history of "patch by argument".
>
> Two things I've done, therefore. One, our C4.1 process now offers
> project maintainers the option of banning troublesome contributors.
> Two, I've told @mrvn that he will be banned if he continues creating
> what I consider "trouble".
>
> Please weigh in with your constructive opinions on this.
>
> -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

Re: [zeromq-dev] libzmq v4.0.5

[Brian Knox]

"You can't just open a socket and get to work anymore."

I just wanted to say that I find this statement to be empirically false.  I
just open a socket and get to work all the time.

I think this thread is getting fuzzy, and I don't know what the problem is
that it is trying to address anymore.

On Thu, Sep 25, 2014 at 10:01 PM, Goswin von Brederlow 
wrote:

> On Thu, Sep 25, 2014 at 02:20:07PM +0200, Pieter Hintjens wrote:
> > On Thu, Sep 25, 2014 at 1:39 PM, Goswin von Brederlow 
> wrote:
> >
> > > That is fine for major changes where a completly new function makes
> > > sense. But not for minor behaviour changes that only conern corner
> > > cases. It doesn't make sense to end up with 20 zmq_sock() like
> > > functions that all return a slightly differently behaving socket.
> >
> > We've already done this, and no-one complains:
> >
> > - zmq_send
>
> Lowlevel send
>
> > - zmq_sendmsg
> > - zmq_msg_send
>
> Same behaviour with different name. And I would call the msg structure
> a major change to the first function.
>
> And since you asked for it let me complain about this here. :) Maybe
> http://api.zeromq.org/4-1:zmq-sendmsg could be removed from the table
> of contents (or moved to a deprecated section in the table of contents
> so it remains for reference).
>
> When I started with zmq I read a few examples and then started to
> experiment. For this I keept the API reference open and when I wanted
> to do something I would look for a function that sounded right and
> open its page. That easily leads to learning deprecated functions
> instead of finding the proper ones. Ok, after a while I learned to
> first scan for the "this API method is deprecated" boxes. But still,
> wasted time.
>
> On the opposite site the new version has some new functions. Somone
> coming from an old version might want to read up on the new features.
> In the online ocaml reference changes are marked:
>
> http://www.askra.de/software/ocaml-doc/4.00/index.html
>
> That makes it easy to find and read up on changes. Maybe something to
> think about too.
>
>
> > - zmsg_send
> > - zstr_send
> > - zframe_send
> > - zsock_send
> > - zactor_send
>
> Different library altogether. :) And czmq has more of an OO design. So
> every data object has a send function. One isn't preferable over the
> other. They are all ment to coexist.
>
> > All do kind of the same thing. The only time people complained
> > (rightly) was when 3.0 changed zmq_send.
> >
> > In practice you don't get 20 variations. You get 2 or 3, one for each
> > stable generation. Remember we can change draft APIs at will. We make
> > a stable release maybe once a year. We save old APIs for a few
> > generations, then delete them.
> >
> > > HTTP does do exactly that. When you connect you say:
> > >
> > > GET /index.html HTTP/1.1
> >
> > Yes, except it's used for almost nothing significant, and there was
> > never a successful 1.2 or 2.0. That kind of proves my point. (I've
> > written many complete HTTP server stacks.)
> >
> > > Which is fine if you follow your own contract. Zeromq has broken it 3
> > > times now so that isn't the best track record.
> >
> > Indeed. However this isn't my project, it's *our* project and we all
> > enforce the rules, or we don't. My job has been to define workable
> > rules. I'll enforce them on aspects of the project I use and thus care
> > about.
> >
> > Anyone using those pieces that got broken had the tools to stop that
> > happening, and didn't say anything. We can investigate why, and fix
> > that, if someone cares.
> >
> > > And there are a number
> > > of things I would like to change eventually. Like ZMQ_STREAM sockets
> > > shouldn't require the MORE flag for every frame, alternating between
> > > destination and data frames. Instead they should work like ROUTER
> > > sockets and take the first frame of a multi-part message as the
> > > destination address and send the rest onwards.
> >
> > Indeed. You can already do this in several ways. You don't need to
> > expose ABI versions for this. Indeed we have a good, existing
> > mechanism for feature updates to socket types. Check the many ROUTER
> > socket options.
>
> Two points here:
>
> 1) Then why isn't this done for the "now blocks" issue to preserve
> API/ABI compatibility? Or for the monitor socket?
>
> 2) "Check the *many* ROUTER socket options." That was my point. Over
> time such options get more and more and more. So your code gets longer
> and longer. You can't just open a socket and get to work anymore. You
> have to set 20 options first because the default must remain
> compatible with a stoneage version and that for every socket. The idea
> was that by specifying an API version the source expects the defaults
> could be adjusted accordingly. By setting one version all those 20
> options that everyone wants to be changed get set in one go resulting
> in improved defaults for all sockets.
>
> > > That I think is the advantage of the FUSE solution. By defining a
> > > hi

Re: [zeromq-dev] DEALER-ROUTER question

[Brian Knox]

Conceptually I like the idea of czmq folding back into libzmq.  While
requiring both llibzmq and czmq for a language binding that wraps czmq
isn't the end of the world, it is an additional complexity.

I very much look forward to the czmq 3.0 release, and I'm hoping to have
goczmq feature complete for it.

Cheers!
Brian

On Fri, Sep 26, 2014 at 5:36 AM, Goswin von Brederlow 
wrote:

> On Fri, Sep 26, 2014 at 11:06:29AM +0200, Pieter Hintjens wrote:
> > This is one of those rare roadmap / vision threads.
> >
> > Concretely all this has to happen first:
> >
> > - release 4.0.5 sometime very soon
> > - release 4.1.0 RC sometime later
> > - update Guide for 4.1
> > - release CZMQ v3.0 RC
> >
> > I think CZMQ can be sliced in several ways, e.g. the project modeling
> > should go together with zproto into a new project (I think we agreed
> > on a name but I forget what it was now...). Then libzmq should use
> > that.
> >
> > One thing at a time.
> >
> > -Pieter
>
> One last thing and then I will get back to work.
>
> The zring class in CZMQ I feel is still experimental and I would like
> to keep that in flux some more, maybe throw it out alltogether and
> replace it with the equipotent API I mentioned.
>
> You didn't give any ETAs but if CZMQ is still a few weeks away that
> will give plenty of time to get zring and ztimeout into shape and tested.
>
> MfG
> Goswin
> ___
> 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] libzmq v4.0.5

[Brian Knox]

Speaking as someone who started with zeromq at version 2:  The breaking
changes between 2 and 3 almost caused me to abandon zeromq altogether.
Since 3.2 (if I'm remembering correctly that 3.2 was the "fix this mess"
version), things have been relatively smooth sailing.

I've been routinely developing against zeromq head and czmq head since
before libzmq 4 and czmq 2 were stable releases.  This has been a
shockingly painless process and the strict contract is something that I
greatly appreciate.



On Thu, Sep 25, 2014 at 3:05 PM, Pieter Hintjens  wrote:

> The surface API remains simple enough, as we deprecate older calls and
> remove them from examples and so on. The man pages are quite explicit
> about marking deprecated API calls.
>
> We can be more brutal about removing deprecated code, though I've not
> seen anyone raise an issue with the current situation. Removing
> deprecated pieces will certainly cause complaints.
>
> This is really basic. A version bump does NOT excuse breakage. I don't
> know how to keep explaining this in different ways. Let me quote Linus
> Torvalds: "DON'T BREAK EFFING USER SPACE" or something like that.
>
> Even a ZeroMQ v5.0 would have to support 3.2 and 2.0 API calls (which
> can be taken out of the man pages) unless there is a real, significant
> benefit in removing them.
>
> -Pieter
>
>
>
> On Thu, Sep 25, 2014 at 8:26 PM, Tim Crowder 
> wrote:
> > Complaints are not the only (or best) measure of quality.
> > How many questions does the multitude of semi-redundant functions
> generate on this list,
> > especially from new users trying to get started? (More so, since some
> functions take void*
> > and so can't validate by argument type).
> >
> > Perhaps it's time for a major version bump with some consolidation...
> >
> > Cheers!
> >
> > .timrc
> > 
> > From: zeromq-dev-boun...@lists.zeromq.org [
> zeromq-dev-boun...@lists.zeromq.org] on behalf of Pieter Hintjens [
> p...@imatix.com]
> > Sent: Thursday, September 25, 2014 5:20 AM
> > To: ZeroMQ development list
> > Subject: Re: [zeromq-dev] libzmq v4.0.5
> >
> > On Thu, Sep 25, 2014 at 1:39 PM, Goswin von Brederlow 
> wrote:
> >
> >> That is fine for major changes where a completly new function makes
> >> sense. But not for minor behaviour changes that only conern corner
> >> cases. It doesn't make sense to end up with 20 zmq_sock() like
> >> functions that all return a slightly differently behaving socket.
> >
> > We've already done this, and no-one complains:
> >
> > - zmq_send
> > - zmq_sendmsg
> > - zmq_msg_send
> > - zmsg_send
> > - zstr_send
> > - zframe_send
> > - zsock_send
> > - zactor_send
> >
> > All do kind of the same thing. The only time people complained
> > (rightly) was when 3.0 changed zmq_send.
> >
> > In practice you don't get 20 variations. You get 2 or 3, one for each
> > stable generation. Remember we can change draft APIs at will. We make
> > a stable release maybe once a year. We save old APIs for a few
> > generations, then delete them.
> >
> >> HTTP does do exactly that. When you connect you say:
> >>
> >> GET /index.html HTTP/1.1
> >
> > Yes, except it's used for almost nothing significant, and there was
> > never a successful 1.2 or 2.0. That kind of proves my point. (I've
> > written many complete HTTP server stacks.)
> >
> >> Which is fine if you follow your own contract. Zeromq has broken it 3
> >> times now so that isn't the best track record.
> >
> > Indeed. However this isn't my project, it's *our* project and we all
> > enforce the rules, or we don't. My job has been to define workable
> > rules. I'll enforce them on aspects of the project I use and thus care
> > about.
> >
> > Anyone using those pieces that got broken had the tools to stop that
> > happening, and didn't say anything. We can investigate why, and fix
> > that, if someone cares.
> >
> >> And there are a number
> >> of things I would like to change eventually. Like ZMQ_STREAM sockets
> >> shouldn't require the MORE flag for every frame, alternating between
> >> destination and data frames. Instead they should work like ROUTER
> >> sockets and take the first frame of a multi-part message as the
> >> destination address and send the rest onwards.
> >
> > Indeed. You can already do this in several ways. You don't need to
> > expose ABI versions for this. Indeed we have a good, existing
> > mechanism for feature updates to socket types. Check the many ROUTER
> > socket options.
> >
> >> That I think is the advantage of the FUSE solution. By defining a
> >> higher FUSE_USE_VERSION you can not only get new features enabled but
> >> also deprecated features removed.
> >
> > OK, I do accept the problem statement of multiple versions of an API.
> >
> > There are many solutions. Remember our focus is distributed software
> > and a distributed community. This is important. It means we work on
> > many pieces at the same time, and they evolve independently over a
> > long time, and at a dis

Re: [zeromq-dev] Go codec for zproto

[Brian Knox]

Armen - I'm currently working on a gopher server written in go (just..
because).  One of the things I was planning on adding to it was a zeromq
based "new" gopher protocol along with standard gopher.  I'll gladly use
zproto to create it and send feedback and bug reports your way!

Brian


On Mon, Jun 30, 2014 at 5:42 AM, Armen Baghumian 
wrote:

> Ok.
>
> On Mon, 30 Jun 2014 10:47:59 +0200
> Pieter Hintjens  wrote:
>
> > It's actually better to push work as you do it, starting with the
> > minimal (partially) working things you have. That shows other people
> > what you're doing and makes them more likely to join in, use it, etc.
> > Push early, push often :-)
> >
> > On Sun, Jun 29, 2014 at 11:38 PM, Armen Baghumian
> >  wrote:
> > > Yes sure, after I implemented repeat and custom type.
> > >
> > >
> > > On Sun, 29 Jun 2014 17:10:01 +0200
> > > Pieter Hintjens  wrote:
> > >
> > >> This is cool... would you make a pull request to add it to the
> > >> zproto project?
> > >>
> > >> On Sun, Jun 29, 2014 at 4:03 PM, Armen Baghumian
> > >>  wrote:
> > >> > Hello,
> > >> >
> > >> > For anyone whom is interested having a Golang port of Zproto
> > >> > codec, go_codec branch in my fork [1] is an initial port of
> > >> > zproto_codec_c to golang.
> > >> >
> > >> > Obviously the code isn't mature and well tested and should
> > >> > have bugs, so bug reports are welcome and appreciated. Also if
> > >> > you have suggestions on improving the implementation I'll be
> > >> > happy to hear and ofcourse you can fork it as well.
> > >> >
> > >> > In the initial implementation everything should work except
> > >> > "repeat" and "custom type".
> > >> >
> > >> > I'm also looking for a way of testing two codecs in a way to make
> > >> > sure they're 100% compatible, I'm not sure how so I'll be more
> > >> > than happy to hear your suggestions.
> > >> >
> > >> > P.S.: To generate the code use following command in /src
> > >> > directory:
> > >> >
> > >> >gsl -script:zproto_codec_go zproto_example.xml
> > >> >
> > >> >
> > >> > [1] https://github.com/armen/zproto/tree/go_codec
> > >> >
> > >> >
> > >> > --Armen
> > >> >
> > >> > ___
> > >> > 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
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq_utils.h -> zmq.h?

[Brian Knox]

Doesn't bother me.


On Fri, Jun 27, 2014 at 8:35 AM, Pieter Hintjens  wrote:

> Hi all,
>
> I'm wondering if anyone still cares that the utility functions sit in
> a different header file. There is a single library, and having two
> header files for different sections in it seems like complexity for
> nothing.
>
> Does anyone object if I move the contents of zmq_utils.h into zmq.h
> and deprecate the file? (It'll still exist, just be empty.)
>
> -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

Re: [zeromq-dev] Gyre

[Brian Knox]

Armen - I'm currently doing quite a bit of zeromq work with go.  I will
gladly be an immediate test victim for your codec_go.gsl - I've used zproto
from C quite a bit and I have resources to stress test things.

Cheers!
Brian


On Wed, Jun 25, 2014 at 9:08 AM, Armen Baghumian 
wrote:

>
> > Hah, nice! Rather than copy generated code you may want to add a Go
> > codec generator to zproto. It should be fairly simple to port the
> > existing C codec generator.
>
> codec_go.gsl [1] ported about 20-30% of codec_c.gsl, all I needed to
> implement ZRE/Zyre in Go, in fact msg package [2] is the generated
> code of that codec.
>
> I'll contribute it back to zproto as soon as I finished the rest of
> the codec.
>
> --
>
> [1] https://github.com/zeromq/gyre/blob/master/misc/scripts/codec_go.gsl
> [2] https://github.com/zeromq/gyre/tree/master/msg
>
> ___
> 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] Gyre

[Brian Knox]

Armen - this is fantastic!  I'm going to have so much fun reading this
code!


On Wed, Jun 25, 2014 at 7:04 AM, Armen Baghumian 
wrote:

> Hello,
>
> I'm happy to announce that I've ported Zyre to Go. It's a direct
> translation of C code to Go.
>
> https://github.com/armen/gyre
>
> API Documentation:
>
> http://godoc.org/github.com/armen/gyre
>
> Some parts still needs to be polished and completed for instance golang
> codec (codec_go.gsl) which isn't even close to codec_c.gsl or the beacon
> package.
>
> Any comments, bug reports and patches are more than welcome.
>
> Cheers,
> Armen
>
> ___
> 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