Non-Boost Asio about azmq HOT 50 CLOSED

I'm taking a shot at this. I don't want to drag Boost into my project. No clue when it will be done, though.

from azmq.

I'm going to stop working on this for the time being. I've come across some issues with ZeroMQ that made me want to look at nanomsg a bit closer and possibly replicate this project for nanomsg.

from azmq.

I haven't seriously considered it. Obviously I could take the route ChrisK
took to mechanically transform sources and that would cover most, but not
all, of the use of Boost in the library. Some of which exists to work
around (still) broken C++11 library implementations and compiler
deficiencies (eg Microsoft).

Also, my projects are all completely dependent on Boost, so it isn't a
priority for me.

What I do want to explore, however, is a version which makes use of the
standards track Asio that is part of the new Networking TS that we voted in
during the fall C++ Standards Committee meeting. This is a longer term plan
as the spec is not yet stable, and still lacks support for one feature that
azmq requires (posix::stream_descriptor).

On Friday, February 6, 2015, Tengiz Sharafiev [email protected]
wrote:

How difficult it will be to rewrite azmq without boost?
http://think-async.com/Asio/AsioStandalone

—
Reply to this email directly or view it on GitHub
#62.

from azmq.

Patches are definitely welcome. Please note, in some cases we switched from
the C++11 standard types to the Boost types to smooth over issues compiling
on MSVC. That should be preserved until MSVC2015 is "the norm". The
"right" way to do this would be to make a set of typedefs to cover which
thread/mutex/condition_variable/error_code/etc. types are used based on
some conditional compilation. I may take a stab at that change in the next
week.

By way of advance warning, I am going to be refactoring
detail/socket_service.hpp in the next week or two to clean that up, it is a
fairly intrusive set of changes so there is likely to be some churn
involving that file and the details in socket.hpp (though not the public
surface area of the socket type).

On Sat, Mar 14, 2015 at 6:53 PM, Rui Pacheco [email protected]
wrote:

I'm taking a shot at this. I don't want to drag Boost into my project. No
clue when it will be done, though.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

I can’t test on Windows unfortunately.

On 15 Mar 2015, at 01:37, Thomas Rodgers [email protected] wrote:

Patches are definitely welcome. Please note, in some cases we switched from
the C++11 standard types to the Boost types to smooth over issues compiling
on MSVC. That should be preserved until MSVC2015 is "the norm". The
"right" way to do this would be to make a set of typedefs to cover which
thread/mutex/condition_variable/error_code/etc. types are used based on
some conditional compilation. I may take a stab at that change in the next
week.

By way of advance warning, I am going to be refactoring
detail/socket_service.hpp in the next week or two to clean that up, it is a
fairly intrusive set of changes so there is likely to be some churn
involving that file and the details in socket.hpp (though not the public
surface area of the socket type).

On Sat, Mar 14, 2015 at 6:53 PM, Rui Pacheco [email protected]
wrote:

I'm taking a shot at this. I don't want to drag Boost into my project. No
clue when it will be done, though.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

Nor can I. We have a CI build on Pull Requests which covers Windows, @oliora usually catches Windows breakage and weighs in on how to best address it.

One other potential issue - The code for bind() on the socket uses regular expressions, specifically boost::regex. I know that std::regex was broken on GCC4.7, and probably 4.8, so the minimum GCC compiler requirement is going to be GCC4.9 (I believe libstdc++ is fine from Clang3.4 on).

from azmq.

Ok

On 15 Mar 2015, at 01:53, Thomas Rodgers [email protected] wrote:

Nor can I. We have a CI build on Pull Requests which covers Windows, @oliora https://github.com/oliora usually catches Windows breakage and weighs in on how to best address it.

One other potential issue - The code for bind() on the socket uses regular expressions, specifically boost::regex. I know that std::regex was broken on GCC4.7, and probably 4.8, so the minimum GCC compiler requirement is going to be GCC4.9 (I believe libstdc++ is fine from Clang3.4 on).

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

I've done some work as you can see from my fork and I've now hit a problem:

./azmq/socket.hpp:108:35: error: use of undeclared identifier 'implementation'; did you mean 'implementation_'?

What are you trying to do here?

I've pushed the changes to my repo so you can try to build it for yourself, if needed.

from azmq.

See the documentation for the asio::basic_io_object
http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio/reference/basic_io_object.html
template. This pattern is repeated throughout both Asio and Azmq, and has
to do with the way basic_io_object interfaces with implementations of
asio::io_service::service_base.

On Sun, Mar 15, 2015 at 8:09 AM, Rui Pacheco [email protected]
wrote:

I've done some work as you can see from my fork and I've now hit a
problem:

./azmq/socket.hpp:108:35: error: use of undeclared identifier
'implementation'; did you mean 'implementation_'?

What are you trying to do here?

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

I still need to finish the 2nd and 3rd parts of this post (Real Soon Now),
but see http://rodgert.github.io/2014/12/24/boost-asio-and-zeromq-pt1/ for
more information on this structure in Asio and Azmq.

On Sun, Mar 15, 2015 at 1:38 PM, Thomas Rodgers [email protected]
wrote:

See the documentation for the asio::basic_io_object
http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio/reference/basic_io_object.html
template. This pattern is repeated throughout both Asio and Azmq, and has
to do with the way basic_io_object interfaces with implementations of
asio::io_service::service_base.

On Sun, Mar 15, 2015 at 8:09 AM, Rui Pacheco [email protected]
wrote:

I've done some work as you can see from my fork and I've now hit a
problem:

./azmq/socket.hpp:108:35: error: use of undeclared identifier
'implementation'; did you mean 'implementation_'?

What are you trying to do here?

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Having a Boost-less version is a nice feature.

Although it has some issues:

1. gcc 4.8 has a very limited std::regex support (better described as doesn't have it :). gcc completely supports regex starting from 4.9. So going without Boost will require quite modern compiler.
2. MSVC 2013 has limited support of C++11 features. Things affecting AZMQ are at least: no noexcept, no inline namespaces. This wrapped by Boost, but can be done by AZMQ code itself.
3. Using of std::thread and std::mutex instead of Boost analogues is more chance to stumble upon DllMain restrictions on Windows and come to a deadlock during startup or shutdown, so using of Boost threading is preferable if available. So we definitely will need two set of typedefs for threading classes.

from azmq.

I'd like to keep my branch as C++11 as possible. Maybe we don't merge
until there is compiler support, meanwhile keeping a reference to my
fork on the README file?

On 18/03/15 16:56, Andrey Upadyshev wrote:

Having a Boost-less version is a nice feature.

Although it has some issues:

1. gcc 4.8 has a very limited |std::regex| support (better described
   as doesn't have it :). Only gcc 4.9 and above completely supports
   it. So going without Boost will require quite modern compiler.
2. MSVC 2013 has limited support of C++11 features. Things affecting
   AZMQ are at least: no noexcept, no inline namespaces. This wrapped
   by Boost, but can be done by AZMQ code itself.
3. Using of |std::thread| and |std::mutex| instead of Boost analogues
   is more chance to stumble upon DllMain restrictions
   https://msdn.microsoft.com/en-us/library/windows/desktop/dn633971%28v=vs.85%29.aspx
   on Windows and come to a deadlock during startup or shutdown, so
   using of Boost threading is preferable if available. So we
   definitely will need two set of typedefs for threading classes.

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

from azmq.

Azmq expects C++11 as the minimum compiler requirement and makes extensive
use of C++11 only features already. The issue then is only how we support
common 'pre-standard' compilers which lack full standards coverage.
Compilers tend to have a fairly long tail (I expect to be encountering
GCC4.8, for instance, for at least another 18-36 months) so maintaining a
fork may be less than pleasant prospect.

I think it is possible to configure, by proper typedefs and macros,
something that can deal with older compilers currently supported without
the need to maintain a fork.

I intend to take an initial stab at this in the next week.

On Thursday, March 19, 2015, Rui Pacheco [email protected] wrote:

I'd like to keep my branch as C++11 as possible. Maybe we don't merge
until there is compiler support, meanwhile keeping a reference to my
fork on the README file?

On 18/03/15 16:56, Andrey Upadyshev wrote:

Having a Boost-less version is a nice feature.

Although it has some issues:

1. gcc 4.8 has a very limited |std::regex| support (better described
   as doesn't have it :). Only gcc 4.9 and above completely supports
   it. So going without Boost will require quite modern compiler.
2. MSVC 2013 has limited support of C++11 features. Things affecting
   AZMQ are at least: no noexcept, no inline namespaces. This wrapped
   by Boost, but can be done by AZMQ code itself.
3. Using of |std::thread| and |std::mutex| instead of Boost analogues
   is more chance to stumble upon DllMain restrictions
   <
   https://msdn.microsoft.com/en-us/library/windows/desktop/dn633971%28v=vs.85%29.aspx

on Windows and come to a deadlock during startup or shutdown, so
using of Boost threading is preferable if available. So we
definitely will need two set of typedefs for threading classes.

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Guys,
I can put boost-free branch under CI and port it on Windows

from azmq.

I won’t be able to get any work done until next weekend unfortunately.

But I need this so it will be done.

On 21 Mar 2015, at 12:00, Andrey Upadyshev [email protected] wrote:

Guys,
I can put boost-free branch under CI and port it on Windows

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

I have a pending pull request that introduces azmq/detail/config.hpp and azmq/detail/config/* to start collecting platform/compiler specific conditional defines, typedefs, etc. My plan is to move slowly toward consuming definitions for things like thread/mutex/etc. from this tree. I think this should also extend to type aliases for Asio types (and system_error/errc) to switch between boost/non-boost Asio.

@oliora For non MSVC targets, I am going to start introducing #defines in config.hpp to select std::thread/std::mutex in preference over their boost equivalents.

from azmq.

I'm moving slowly. I do some work every week but its not as fast as I want.

Sent from my iPhone

On 01 Apr 2015, at 16:59, Thomas Rodgers [email protected] wrote:

I have a pending pull request that introduces azmq/detail/config.hpp and azmq/detail/config/* to start collecting platform/compiler specific conditional defines, typedefs, etc. My plan is to move slowly toward consuming definitions for things like thread/mutex/etc. from this tree. I think this should also extend to type aliases for Asio types (and system_error/errc) to switch between boost/non-boost Asio.

@oliora For non MSVC targets, I am going to start introducing #defines in config.hpp to select std::thread/std::mutex in preference over their boost equivalents.

—
Reply to this email directly or view it on GitHub.

from azmq.

As I said, this is moving slowly.

A question: would you have a problem if with me using clang-format on the source? This would probably ruin the diff so it's something to think about.

Also, this question does not imply that the project is near completion.

from azmq.

I got a demo of the tool a year ago from the Clang devs at a C++ committee
meeting. I think it is an interesting tool, and perhaps worth pursuing,
but I want any source-wide wholesale reformat being part of a change that
only applies a pre-agreed upon style. Such a change would also involve
updating the contribution notes indicating the style.

Which style do you prefer?

On Wednesday, April 8, 2015, Rui Pacheco [email protected] wrote:

As I said, this is moving slowly.

A question: would you have a problem if with me using clang-format
http://clang.llvm.org/docs/ClangFormat.html on the source? This would
probably ruin the diff so it's something to think about.

Also, this question does not imply that the project is near completion.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

I like Google’s C++ style as it saves a lot of space - C++ is pretty verbose.

I already have a .clang-format file that I use in another project. It’s just a question of copying it here and running the tool as needed.

If you prefer another style we can either try to make clang-format adhere to it or just ignore clang-format completely.

On 08 Apr 2015, at 22:10, Thomas Rodgers [email protected] wrote:

I got a demo of the tool a year ago from the Clang devs at a C++ committee
meeting. I think it is an interesting tool, and perhaps worth pursuing,
but I want any source-wide wholesale reformat being part of a change that
only applies a pre-agreed upon style. Such a change would also involve
updating the contribution notes indicating the style.

Which style do you prefer?

On Wednesday, April 8, 2015, Rui Pacheco [email protected] wrote:

As I said, this is moving slowly.

A question: would you have a problem if with me using clang-format
http://clang.llvm.org/docs/ClangFormat.html on the source? This would
probably ruin the diff so it's something to think about.

Also, this question does not imply that the project is near completion.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

Ok, I'd say hold off for now, and let me play around a bit with it. I tend
to prefer liberal use of white space, and I don't really like very 'dense'
code. I have found this to be a maintenance headache in other projects.

On Wednesday, April 8, 2015, Rui Pacheco [email protected] wrote:

I like Google’s C++ style as it saves a lot of space - C++ is pretty
verbose.

I already have a .clang-format file that I use in another project. It’s
just a question of copying it here and running the tool as needed.

If you prefer another style we can either try to make clang-format adhere
to it or just ignore clang-format completely.

On 08 Apr 2015, at 22:10, Thomas Rodgers <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

I got a demo of the tool a year ago from the Clang devs at a C++
committee
meeting. I think it is an interesting tool, and perhaps worth pursuing,
but I want any source-wide wholesale reformat being part of a change that
only applies a pre-agreed upon style. Such a change would also involve
updating the contribution notes indicating the style.

Which style do you prefer?

On Wednesday, April 8, 2015, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

As I said, this is moving slowly.

A question: would you have a problem if with me using clang-format
http://clang.llvm.org/docs/ClangFormat.html on the source? This
would
probably ruin the diff so it's something to think about.

Also, this question does not imply that the project is near completion.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-91021142>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Of course, go for it.

On 08 Apr 2015, at 22:19, Thomas Rodgers [email protected] wrote:

Ok, I'd say hold off for now, and let me play around a bit with it. I tend
to prefer liberal use of white space, and I don't really like very 'dense'
code. I have found this to be a maintenance headache in other projects.

On Wednesday, April 8, 2015, Rui Pacheco [email protected] wrote:

I like Google’s C++ style as it saves a lot of space - C++ is pretty
verbose.

I already have a .clang-format file that I use in another project. It’s
just a question of copying it here and running the tool as needed.

If you prefer another style we can either try to make clang-format adhere
to it or just ignore clang-format completely.

On 08 Apr 2015, at 22:10, Thomas Rodgers <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

I got a demo of the tool a year ago from the Clang devs at a C++
committee
meeting. I think it is an interesting tool, and perhaps worth pursuing,
but I want any source-wide wholesale reformat being part of a change that
only applies a pre-agreed upon style. Such a change would also involve
updating the contribution notes indicating the style.

Which style do you prefer?

On Wednesday, April 8, 2015, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

As I said, this is moving slowly.

A question: would you have a problem if with me using clang-format
http://clang.llvm.org/docs/ClangFormat.html on the source? This
would
probably ruin the diff so it's something to think about.

Also, this question does not imply that the project is near completion.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-91021142>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

It seems that the LLVM style + 4-space indent would be closest to what is currently used. I am going to muck about with this as a starting point.

from azmq.

Ok, that’s cool. If you create a clang-format file send it to me. I don’t want to pull from your repo and diff the formatting.

On 13 Apr 2015, at 21:53, Thomas Rodgers [email protected] wrote:

It seems that the LLVM style + 4-space indent would be closest to what is currently used. I am going to muck about with this as a starting point.

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

If I get something I'm happy with, I may do a bulk reformat according to that style (heads up before doing so obviously). If you reformatted according to the same style file, it should make any subsequent diffs easy (well as easy as such things ever are).

I have some additional commits related to stand alone Asio support that I want to merge upstream first in any event.

from azmq.

Ok. What are they?

On 13 Apr 2015, at 21:58, Thomas Rodgers [email protected] wrote:

If I get something I'm happy with, I may do a bulk reformat according to that style (heads up before doing so obviously). If you reformatted according to the same style file, it should make any subsequent diffs easy (well as easy as such things ever are).

I have some additional commits related to stand alone Asio support that I want to merge upstream first in any event.

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

in general, slowly replacing anything in Boost (except Asio as of yet) with their standard library equivalents. Specifically, the most recent changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/

As I encounter boost-isms that are easily switched out, I am populating this directory and adjusting config.hpp as appropriate, but it is a work in progress. There are also some dependencies on boost flat_map and boost intrusive list that I am working on, along with propagating changes related to the definitions already in config.hpp & config/ but I don't anticipate landing those changes before the weekend.

from azmq.

Check my fork, that’s exactly what I’m doing and I have a ton of work done.

On 13 Apr 2015, at 22:05, Thomas Rodgers [email protected] wrote:

in general, slowly replacing anything in Boost (except Asio as of yet) with their standard library equivalents. Specifically, the most recent changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/ https://github.com/rodgert/azmq/tree/master/azmq/detail/config/
As I encounter boost-isms that are easily switched out, I am populating this directory and adjusting config.hpp as appropriate, but it is a work in progress. There are also some dependencies on boost flat_map and boost intrusive list that I am working on, along with propagating changes related to the definitions already in config.hpp & config/ but I don't anticipate landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

May I ask you to take a look at boost::match_partial? The lack of an std:: equivalent is the only thing keeping me from yanking boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers [email protected] wrote:

in general, slowly replacing anything in Boost (except Asio as of yet) with their standard library equivalents. Specifically, the most recent changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/ https://github.com/rodgert/azmq/tree/master/azmq/detail/config/
As I encounter boost-isms that are easily switched out, I am populating this directory and adjusting config.hpp as appropriate, but it is a work in progress. There are also some dependencies on boost flat_map and boost intrusive list that I am working on, along with propagating changes related to the definitions already in config.hpp & config/ but I don't anticipate landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco [email protected] wrote:

May I ask you to take a look at boost::match_partial? The lack of an std::
equivalent is the only thing keeping me from yanking boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

in general, slowly replacing anything in Boost (except Asio as of yet)
with their standard library equivalents. Specifically, the most recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp>
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/ <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>
As I encounter boost-isms that are easily switched out, I am populating
this directory and adjusting config.hpp as appropriate, but it is a work in
progress. There are also some dependencies on boost flat_map and boost
intrusive list that I am working on, along with propagating changes related
to the definitions already in config.hpp & config/ but I don't anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92481991>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Betrayed by auto-complete. And please do tell me what you think of my commits so far.

It’s a bit silly to have two people do the same work.

On 13 Apr 2015, at 22:34, Thomas Rodgers [email protected] wrote:

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco [email protected] wrote:

May I ask you to take a look at boost::match_partial? The lack of an std::
equivalent is the only thing keeping me from yanking boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

in general, slowly replacing anything in Boost (except Asio as of yet)
with their standard library equivalents. Specifically, the most recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp>
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/ <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>
As I encounter boost-isms that are easily switched out, I am populating
this directory and adjusting config.hpp as appropriate, but it is a work in
progress. There are also some dependencies on boost flat_map and boost
intrusive list that I am working on, along with propagating changes related
to the definitions already in config.hpp & config/ but I don't anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92481991>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

I took a brief look at your fork (I will try to spend more time this
evening), but the biggest difference I see is that it looks like you are
out right preferring the C++11 version to the boost version of a type (e.g.
std::thread vs. boost::thread).

While this is ideal, and in fact my original version was exactly this, it
is not quite practical because the code needs to support a version of the
Microsoft compiler in which there are problems with some of the C++11
constructs. As @oliora worked on porting to MSVC, we switched to the Boost
equivalents to paper over deficiencies in that compiler. I think, in order
to end up with a consistent code base that can target standalone Asio AND
the existing targets these choices need to be configurable at compile time,
which is where I am headed with the whole config.hpp, config/*.hpp
structure.

On Mon, Apr 13, 2015 at 3:36 PM, Rui Pacheco [email protected]
wrote:

Betrayed by auto-complete. And please do tell me what you think of my
commits so far.

It’s a bit silly to have two people do the same work.

On 13 Apr 2015, at 22:34, Thomas Rodgers [email protected]
wrote:

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco [email protected] wrote:

May I ask you to take a look at boost::match_partial? The lack of an
std::
equivalent is the only thing keeping me from yanking boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

in general, slowly replacing anything in Boost (except Asio as of
yet)
with their standard library equivalents. Specifically, the most recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp>
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/ <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>
As I encounter boost-isms that are easily switched out, I am
populating
this directory and adjusting config.hpp as appropriate, but it is a
work in
progress. There are also some dependencies on boost flat_map and boost
intrusive list that I am working on, along with propagating changes
related
to the definitions already in config.hpp & config/ but I don't
anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92481991>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92490479>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

I don't think we have much of a choice, given that the problem lies with
a compiler or family of compilers.

I guess I should stop what I'm doing and give you any backup you need?

On 14/04/15 16:30, Thomas Rodgers wrote:

I took a brief look at your fork (I will try to spend more time this
evening), but the biggest difference I see is that it looks like you are
out right preferring the C++11 version to the boost version of a type
(e.g.
std::thread vs. boost::thread).

While this is ideal, and in fact my original version was exactly this, it
is not quite practical because the code needs to support a version of the
Microsoft compiler in which there are problems with some of the C++11
constructs. As @oliora worked on porting to MSVC, we switched to the Boost
equivalents to paper over deficiencies in that compiler. I think, in order
to end up with a consistent code base that can target standalone Asio AND
the existing targets these choices need to be configurable at compile
time,
which is where I am headed with the whole config.hpp, config/*.hpp
structure.

On Mon, Apr 13, 2015 at 3:36 PM, Rui Pacheco [email protected]
wrote:

Betrayed by auto-complete. And please do tell me what you think of my
commits so far.

It’s a bit silly to have two people do the same work.

On 13 Apr 2015, at 22:34, Thomas Rodgers [email protected]
wrote:

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco [email protected]
wrote:

May I ask you to take a look at boost::match_partial? The lack of an
std::
equivalent is the only thing keeping me from yanking
boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

in general, slowly replacing anything in Boost (except Asio as of
yet)
with their standard library equivalents. Specifically, the most
recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp>
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/ <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>
As I encounter boost-isms that are easily switched out, I am
populating
this directory and adjusting config.hpp as appropriate, but it is a
work in
progress. There are also some dependencies on boost flat_map and
boost
intrusive list that I am working on, along with propagating changes
related
to the definitions already in config.hpp & config/ but I don't
anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92481991>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92490479>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

from azmq.

Perhaps, my interest level in doing this work has gone up since I
originally claimed it wasn't something I had a pressing need for. I would
like to prefer the standard library over Boost where there is functional
parity in any event, and I think that covers the majority of the required
changes in any event.

I have some actor related work and a refactoring of socket_service that
have been slowly moving along in varying stages of completion. I am happy
to shelve them for a few weeks and just pound this out. If you are
interested in collaborating around my personal fork?

On Tue, Apr 14, 2015 at 9:33 AM, Rui Pacheco [email protected]
wrote:

I don't think we have much of a choice, given that the problem lies with
a compiler or family of compilers.

I guess I should stop what I'm doing and give you any backup you need?

On 14/04/15 16:30, Thomas Rodgers wrote:

I took a brief look at your fork (I will try to spend more time this
evening), but the biggest difference I see is that it looks like you are
out right preferring the C++11 version to the boost version of a type
(e.g.
std::thread vs. boost::thread).

While this is ideal, and in fact my original version was exactly this, it
is not quite practical because the code needs to support a version of the
Microsoft compiler in which there are problems with some of the C++11
constructs. As @oliora worked on porting to MSVC, we switched to the
Boost
equivalents to paper over deficiencies in that compiler. I think, in
order
to end up with a consistent code base that can target standalone Asio AND
the existing targets these choices need to be configurable at compile
time,
which is where I am headed with the whole config.hpp, config/*.hpp
structure.

On Mon, Apr 13, 2015 at 3:36 PM, Rui Pacheco [email protected]
wrote:

Betrayed by auto-complete. And please do tell me what you think of my
commits so far.

It’s a bit silly to have two people do the same work.

On 13 Apr 2015, at 22:34, Thomas Rodgers [email protected]
wrote:

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco [email protected]
wrote:

May I ask you to take a look at boost::match_partial? The lack of
an
std::
equivalent is the only thing keeping me from yanking
boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

in general, slowly replacing anything in Boost (except Asio as of
yet)
with their standard library equivalents. Specifically, the most
recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp

https://github.com/rodgert/azmq/tree/master/azmq/detail/config/
<
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>
As I encounter boost-isms that are easily switched out, I am
populating
this directory and adjusting config.hpp as appropriate, but it is a
work in
progress. There are also some dependencies on boost flat_map and
boost
intrusive list that I am working on, along with propagating changes
related
to the definitions already in config.hpp & config/ but I don't
anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92481991>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92490479>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Very much. I suggest you parcel out specific tasks and I’ll do them. You know the library better than me and I’m sure you’re a way better C++ programmer than I am.

On 14 Apr 2015, at 17:04, Thomas Rodgers [email protected] wrote:

Perhaps, my interest level in doing this work has gone up since I
originally claimed it wasn't something I had a pressing need for. I would
like to prefer the standard library over Boost where there is functional
parity in any event, and I think that covers the majority of the required
changes in any event.

I have some actor related work and a refactoring of socket_service that
have been slowly moving along in varying stages of completion. I am happy
to shelve them for a few weeks and just pound this out. If you are
interested in collaborating around my personal fork?

On Tue, Apr 14, 2015 at 9:33 AM, Rui Pacheco [email protected]
wrote:

I don't think we have much of a choice, given that the problem lies with
a compiler or family of compilers.

I guess I should stop what I'm doing and give you any backup you need?

On 14/04/15 16:30, Thomas Rodgers wrote:

I took a brief look at your fork (I will try to spend more time this
evening), but the biggest difference I see is that it looks like you are
out right preferring the C++11 version to the boost version of a type
(e.g.
std::thread vs. boost::thread).

While this is ideal, and in fact my original version was exactly this, it
is not quite practical because the code needs to support a version of the
Microsoft compiler in which there are problems with some of the C++11
constructs. As @oliora worked on porting to MSVC, we switched to the
Boost
equivalents to paper over deficiencies in that compiler. I think, in
order
to end up with a consistent code base that can target standalone Asio AND
the existing targets these choices need to be configurable at compile
time,
which is where I am headed with the whole config.hpp, config/*.hpp
structure.

On Mon, Apr 13, 2015 at 3:36 PM, Rui Pacheco [email protected]
wrote:

Betrayed by auto-complete. And please do tell me what you think of my
commits so far.

It’s a bit silly to have two people do the same work.

On 13 Apr 2015, at 22:34, Thomas Rodgers [email protected]
wrote:

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco [email protected]
wrote:

May I ask you to take a look at boost::match_partial? The lack of
an
std::
equivalent is the only thing keeping me from yanking
boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

in general, slowly replacing anything in Boost (except Asio as of
yet)
with their standard library equivalents. Specifically, the most
recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <
https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp

https://github.com/rodgert/azmq/tree/master/azmq/detail/config/
<
https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>
As I encounter boost-isms that are easily switched out, I am
populating
this directory and adjusting config.hpp as appropriate, but it is a
work in
progress. There are also some dependencies on boost flat_map and
boost
intrusive list that I am working on, along with propagating changes
related
to the definitions already in config.hpp & config/ but I don't
anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92481991>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92490479>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub #62 (comment).

from azmq.

@oliora was also interested, I think, in parcelling out and making these
changes (plus, he has the most experience with the MSFT compiler issues).
Let me try to organize a punch list over the next couple of days and we can
start from there.

On Tue, Apr 14, 2015 at 11:44 AM, Rui Pacheco [email protected]
wrote:

Very much. I suggest you parcel out specific tasks and I’ll do them. You
know the library better than me and I’m sure you’re a way better C++
programmer than I am.

On 14 Apr 2015, at 17:04, Thomas Rodgers [email protected]
wrote:

Perhaps, my interest level in doing this work has gone up since I
originally claimed it wasn't something I had a pressing need for. I would
like to prefer the standard library over Boost where there is functional
parity in any event, and I think that covers the majority of the required
changes in any event.

I have some actor related work and a refactoring of socket_service that
have been slowly moving along in varying stages of completion. I am happy
to shelve them for a few weeks and just pound this out. If you are
interested in collaborating around my personal fork?

On Tue, Apr 14, 2015 at 9:33 AM, Rui Pacheco [email protected]
wrote:

I don't think we have much of a choice, given that the problem lies
with
a compiler or family of compilers.

I guess I should stop what I'm doing and give you any backup you need?

On 14/04/15 16:30, Thomas Rodgers wrote:

I took a brief look at your fork (I will try to spend more time this
evening), but the biggest difference I see is that it looks like you
are
out right preferring the C++11 version to the boost version of a type
(e.g.
std::thread vs. boost::thread).

While this is ideal, and in fact my original version was exactly
this, it
is not quite practical because the code needs to support a version
of the
Microsoft compiler in which there are problems with some of the C++11
constructs. As @oliora worked on porting to MSVC, we switched to the
Boost
equivalents to paper over deficiencies in that compiler. I think, in
order
to end up with a consistent code base that can target standalone
Asio AND
the existing targets these choices need to be configurable at compile
time,
which is where I am headed with the whole config.hpp, config/*.hpp
structure.

On Mon, Apr 13, 2015 at 3:36 PM, Rui Pacheco <
[email protected]>
wrote:

Betrayed by auto-complete. And please do tell me what you think of
my
commits so far.

It’s a bit silly to have two people do the same work.

On 13 Apr 2015, at 22:34, Thomas Rodgers <
[email protected]>
wrote:

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco <[email protected]

wrote:

May I ask you to take a look at boost::match_partial? The lack
of
an
std::
equivalent is the only thing keeping me from yanking
boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

in general, slowly replacing anything in Boost (except Asio
as of
yet)
with their standard library equivalents. Specifically, the most
recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp

https://github.com/rodgert/azmq/tree/master/azmq/detail/config/
<

https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>

As I encounter boost-isms that are easily switched out, I am
populating
this directory and adjusting config.hpp as appropriate, but it
is a
work in
progress. There are also some dependencies on boost flat_map
and
boost
intrusive list that I am working on, along with propagating
changes
related
to the definitions already in config.hpp & config/ but I don't
anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <
#62 (comment)
.

—
Reply to this email directly or view it on GitHub
<
https://github.com/zeromq/azmq/issues/62#issuecomment-92482608>.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92490479>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92894144>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

@ruipacheco please check this discussion to be more on the same page: #71 (diff)

from azmq.

Cool!

On 14/04/15 21:12, Thomas Rodgers wrote:

@oliora was also interested, I think, in parcelling out and making these
changes (plus, he has the most experience with the MSFT compiler issues).
Let me try to organize a punch list over the next couple of days and
we can
start from there.

On Tue, Apr 14, 2015 at 11:44 AM, Rui Pacheco [email protected]
wrote:

Very much. I suggest you parcel out specific tasks and I’ll do them. You
know the library better than me and I’m sure you’re a way better C++
programmer than I am.

On 14 Apr 2015, at 17:04, Thomas Rodgers [email protected]
wrote:

Perhaps, my interest level in doing this work has gone up since I
originally claimed it wasn't something I had a pressing need for.
I would
like to prefer the standard library over Boost where there is
functional
parity in any event, and I think that covers the majority of the
required
changes in any event.

I have some actor related work and a refactoring of socket_service
that
have been slowly moving along in varying stages of completion. I
am happy
to shelve them for a few weeks and just pound this out. If you are
interested in collaborating around my personal fork?

On Tue, Apr 14, 2015 at 9:33 AM, Rui Pacheco
[email protected]
wrote:

I don't think we have much of a choice, given that the problem lies
with
a compiler or family of compilers.

I guess I should stop what I'm doing and give you any backup you
need?

On 14/04/15 16:30, Thomas Rodgers wrote:

I took a brief look at your fork (I will try to spend more
time this
evening), but the biggest difference I see is that it looks
like you
are
out right preferring the C++11 version to the boost version of
a type
(e.g.
std::thread vs. boost::thread).

While this is ideal, and in fact my original version was exactly
this, it
is not quite practical because the code needs to support a version
of the
Microsoft compiler in which there are problems with some of
the C++11
constructs. As @oliora worked on porting to MSVC, we switched
to the
Boost
equivalents to paper over deficiencies in that compiler. I
think, in
order
to end up with a consistent code base that can target standalone
Asio AND
the existing targets these choices need to be configurable at
compile
time,
which is where I am headed with the whole config.hpp, config/*.hpp
structure.

On Mon, Apr 13, 2015 at 3:36 PM, Rui Pacheco <
[email protected]>
wrote:

Betrayed by auto-complete. And please do tell me what you
think of
my
commits so far.

It’s a bit silly to have two people do the same work.

On 13 Apr 2015, at 22:34, Thomas Rodgers <
[email protected]>
wrote:

boost::reggae :)

Yes, I will have a look.

On Monday, April 13, 2015, Rui Pacheco
<[email protected]

wrote:

May I ask you to take a look at boost::match_partial?
The lack
of
an
std::
equivalent is the only thing keeping me from yanking
boost::reggae out.

On 13 Apr 2015, at 22:05, Thomas Rodgers <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

in general, slowly replacing anything in Boost (except
Asio
as of
yet)
with their standard library equivalents. Specifically,
the most
recent
changes are in

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp <

https://github.com/rodgert/azmq/tree/master/azmq/detail/config.hpp

https://github.com/rodgert/azmq/tree/master/azmq/detail/config/
<

https://github.com/rodgert/azmq/tree/master/azmq/detail/config/>

As I encounter boost-isms that are easily switched
out, I am
populating
this directory and adjusting config.hpp as appropriate,
but it
is a
work in
progress. There are also some dependencies on boost flat_map
and
boost
intrusive list that I am working on, along with propagating
changes
related
to the definitions already in config.hpp & config/ but I
don't
anticipate
landing those changes before the weekend.

—
Reply to this email directly or view it on GitHub <

#62 (comment)
.

—
Reply to this email directly or view it on GitHub
<
https://github.com/zeromq/azmq/issues/62#issuecomment-92482608>.

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92490479>.

—
Reply to this email directly or view it on GitHub

#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/zeromq/azmq/issues/62#issuecomment-92894144>.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

from azmq.

Not that I ever hit this issue, but if edge triggering was such an issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco [email protected]
wrote:

I'm going to stop working on this for the time being. I've come across
some issues
https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h
with ZeroMQ that made me want to look at nanomsg a bit closer and possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Ok, I will likely complete it in any event over the next couple of weeks

On Sunday, April 19, 2015, Rui Pacheco [email protected] wrote:

I'm going to stop working on this for the time being. I've come across
some issues
https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h
with ZeroMQ that made me want to look at nanomsg a bit closer and possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Maybe the issue is too complex? I mean, nanomsg was created due to lessos learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens [email protected] wrote:

Not that I ever hit this issue, but if edge triggering was such an issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco [email protected]
wrote:

I'm going to stop working on this for the time being. I've come across
some issues
https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h
with ZeroMQ that made me want to look at nanomsg a bit closer and possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub.

from azmq.

Lessons are relative. ZeroMQ is not a library, it's a community. This is
the only significant difference afaics.
On Apr 20, 2015 7:28 AM, "Rui Pacheco" [email protected] wrote:

Maybe the issue is too complex? I mean, nanomsg was created due to lessos
learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens [email protected]
wrote:

Not that I ever hit this issue, but if edge triggering was such an issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco [email protected]
wrote:

I'm going to stop working on this for the time being. I've come across
some issues
<
https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h

with ZeroMQ that made me want to look at nanomsg a bit closer and
possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

'maybe the issue is too complex' -

There is some complexity in supporting a broad range of compilers at
varying levels of standards compliance. That is not a 'lesson learned' from
ZeroMQ or anything particularly relevant to a merits discussion between zmq
and nanomsg, but rather the sad facts of life as a C++ developer.

I built this library to cover my needs, which don't include nanomsg. They
also don't really include standalone Asio, but IMO that is not particularly
complicated.

Also, ZeroMQ has more traction AFAICT and a more 'vibrant' community, which
I value over 'ooh shiny new'.

On Sunday, April 19, 2015, Rui Pacheco [email protected] wrote:

Maybe the issue is too complex? I mean, nanomsg was created due to lessos
learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Not that I ever hit this issue, but if edge triggering was such an issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

I'm going to stop working on this for the time being. I've come across
some issues
<
https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h

with ZeroMQ that made me want to look at nanomsg a bit closer and
possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

I'm just talking about edge triggering over level triggering. Given the
fact that nanomsg already handles that for me and it's compatible with
0mq, why not use it? The best code is the code you don't write, remember?

On 20/04/15 13:31, Thomas Rodgers wrote:

'maybe the issue is too complex' -

There is some complexity in supporting a broad range of compilers at
varying levels of standards compliance. That is not a 'lesson learned'
from
ZeroMQ or anything particularly relevant to a merits discussion
between zmq
and nanomsg, but rather the sad facts of life as a C++ developer.

I built this library to cover my needs, which don't include nanomsg. They
also don't really include standalone Asio, but IMO that is not
particularly
complicated.

Also, ZeroMQ has more traction AFAICT and a more 'vibrant' community,
which
I value over 'ooh shiny new'.

On Sunday, April 19, 2015, Rui Pacheco [email protected] wrote:

Maybe the issue is too complex? I mean, nanomsg was created due to
lessos
learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Not that I ever hit this issue, but if edge triggering was such an
issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

I'm going to stop working on this for the time being. I've come
across
some issues
<

https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h

with ZeroMQ that made me want to look at nanomsg a bit closer and
possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

from azmq.

Nano isn't compatible with ZeroMQ, in any real sense. Different protocols,
different APIs, and different process. Anyhow it's kind of nonsensical to
be discussing this in a thread on a C++ binding to CZMQ, as neither of
these projects have the slightest relevance to Nano.

On Mon, Apr 20, 2015 at 2:12 PM, Rui Pacheco [email protected]
wrote:

I'm just talking about edge triggering over level triggering. Given the
fact that nanomsg already handles that for me and it's compatible with
0mq, why not use it? The best code is the code you don't write, remember?

On 20/04/15 13:31, Thomas Rodgers wrote:

'maybe the issue is too complex' -

There is some complexity in supporting a broad range of compilers at
varying levels of standards compliance. That is not a 'lesson learned'
from
ZeroMQ or anything particularly relevant to a merits discussion
between zmq
and nanomsg, but rather the sad facts of life as a C++ developer.

I built this library to cover my needs, which don't include nanomsg. They
also don't really include standalone Asio, but IMO that is not
particularly
complicated.

Also, ZeroMQ has more traction AFAICT and a more 'vibrant' community,
which
I value over 'ooh shiny new'.

On Sunday, April 19, 2015, Rui Pacheco [email protected] wrote:

Maybe the issue is too complex? I mean, nanomsg was created due to
lessos
learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Not that I ever hit this issue, but if edge triggering was such an
issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

I'm going to stop working on this for the time being. I've come
across
some issues
<

https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h

with ZeroMQ that made me want to look at nanomsg a bit closer and
possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

The problem I had was integration of internal control messaging with UDP
and TCP protocol handlers I don't have control of. I write the latter
(usually) with Asio. nanomsg doesn't do anything for me in that scenario that
isn't already covered by what I have already written.

On Monday, April 20, 2015, Rui Pacheco [email protected] wrote:

I'm just talking about edge triggering over level triggering. Given the
fact that nanomsg already handles that for me and it's compatible with
0mq, why not use it? The best code is the code you don't write, remember?

On 20/04/15 13:31, Thomas Rodgers wrote:

'maybe the issue is too complex' -

There is some complexity in supporting a broad range of compilers at
varying levels of standards compliance. That is not a 'lesson learned'
from
ZeroMQ or anything particularly relevant to a merits discussion
between zmq
and nanomsg, but rather the sad facts of life as a C++ developer.

I built this library to cover my needs, which don't include nanomsg. They
also don't really include standalone Asio, but IMO that is not
particularly
complicated.

Also, ZeroMQ has more traction AFAICT and a more 'vibrant' community,
which
I value over 'ooh shiny new'.

On Sunday, April 19, 2015, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Maybe the issue is too complex? I mean, nanomsg was created due to
lessos
learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');
<javascript:_e(%7B%7D,'cvml','[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');');>> wrote:

Not that I ever hit this issue, but if edge triggering was such an
issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');
<javascript:_e(%7B%7D,'cvml','[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');');>>
wrote:

I'm going to stop working on this for the time being. I've come
across
some issues
<

https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h

with ZeroMQ that made me want to look at nanomsg a bit closer and
possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Minor clarification, azmq binds to libzmq, and incorporates CZMQ behavior
as time, interest and appropreness permit.

But the point (as usual) is spot on.

On Monday, April 20, 2015, Pieter Hintjens [email protected] wrote:

Nano isn't compatible with ZeroMQ, in any real sense. Different protocols,
different APIs, and different process. Anyhow it's kind of nonsensical to
be discussing this in a thread on a C++ binding to CZMQ, as neither of
these projects have the slightest relevance to Nano.

On Mon, Apr 20, 2015 at 2:12 PM, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

I'm just talking about edge triggering over level triggering. Given the
fact that nanomsg already handles that for me and it's compatible with
0mq, why not use it? The best code is the code you don't write, remember?

On 20/04/15 13:31, Thomas Rodgers wrote:

'maybe the issue is too complex' -

There is some complexity in supporting a broad range of compilers at
varying levels of standards compliance. That is not a 'lesson learned'
from
ZeroMQ or anything particularly relevant to a merits discussion
between zmq
and nanomsg, but rather the sad facts of life as a C++ developer.

I built this library to cover my needs, which don't include nanomsg.
They
also don't really include standalone Asio, but IMO that is not
particularly
complicated.

Also, ZeroMQ has more traction AFAICT and a more 'vibrant' community,
which
I value over 'ooh shiny new'.

On Sunday, April 19, 2015, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Maybe the issue is too complex? I mean, nanomsg was created due to
lessos
learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');
<javascript:_e(%7B%7D,'cvml','[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');');>> wrote:

Not that I ever hit this issue, but if edge triggering was such an
issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');
<javascript:_e(%7B%7D,'cvml','[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');');>>
wrote:

I'm going to stop working on this for the time being. I've come
across
some issues
<

https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h

with ZeroMQ that made me want to look at nanomsg a bit closer and
possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
<#62 (comment)
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

Ah, sorry. Yes, of course azmq doesn't call CZMQ, my bad.

On Mon, Apr 20, 2015 at 2:44 PM, Thomas Rodgers [email protected]
wrote:

Minor clarification, azmq binds to libzmq, and incorporates CZMQ behavior
as time, interest and appropreness permit.

But the point (as usual) is spot on.

On Monday, April 20, 2015, Pieter Hintjens [email protected]
wrote:

Nano isn't compatible with ZeroMQ, in any real sense. Different
protocols,
different APIs, and different process. Anyhow it's kind of nonsensical to
be discussing this in a thread on a C++ binding to CZMQ, as neither of
these projects have the slightest relevance to Nano.

On Mon, Apr 20, 2015 at 2:12 PM, Rui Pacheco <[email protected]

javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

I'm just talking about edge triggering over level triggering. Given the
fact that nanomsg already handles that for me and it's compatible with
0mq, why not use it? The best code is the code you don't write,
remember?

On 20/04/15 13:31, Thomas Rodgers wrote:

'maybe the issue is too complex' -

There is some complexity in supporting a broad range of compilers at
varying levels of standards compliance. That is not a 'lesson
learned'
from
ZeroMQ or anything particularly relevant to a merits discussion
between zmq
and nanomsg, but rather the sad facts of life as a C++ developer.

I built this library to cover my needs, which don't include nanomsg.
They
also don't really include standalone Asio, but IMO that is not
particularly
complicated.

Also, ZeroMQ has more traction AFAICT and a more 'vibrant' community,
which
I value over 'ooh shiny new'.

On Sunday, April 19, 2015, Rui Pacheco <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Maybe the issue is too complex? I mean, nanomsg was created due to
lessos
learned with 0mq.

Sent from my iPhone

On 19 Apr 2015, at 23:09, Pieter Hintjens <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');
<javascript:_e(%7B%7D,'cvml','[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');');>> wrote:

Not that I ever hit this issue, but if edge triggering was such
an
issue,
surely someone would have tried to change it in libzmq by now?

On Sun, Apr 19, 2015 at 9:43 PM, Rui Pacheco <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');
<javascript:_e(%7B%7D,'cvml','[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');');>>
wrote:

I'm going to stop working on this for the time being. I've come
across
some issues
<

https://www.reddit.com/r/programming/comments/3349p7/a_look_at_nanomsg_and_scalability_protocols_why/cqhk13h

with ZeroMQ that made me want to look at nanomsg a bit closer
and
possibly
replicate this project for nanomsg.

—
Reply to this email directly or view it on GitHub
<
#62 (comment)
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

Rui Pacheco

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

—
Reply to this email directly or view it on GitHub
#62 (comment).

from azmq.

After all, looks like the level triggering is emulated in AZMQ to fix #81. So this should not be an issue any more :)

from azmq.

Heard it loud and clear. Didn’t go far with the nanomsg cover because of the day job too :)

On 23 Jun 2015, at 15:48, Andrey Upadyshev [email protected] wrote:

After all, looks like the level triggering is emulated in AZMQ to fix #81 #81. So it should not be an issue any more :)

—
Reply to this email directly or view it on GitHub #62 (comment).

Rui Pacheco
[email protected]

from azmq.