On 11/30/2010 05:44 PM, Martin Lucina wrote:
Remove unnecessary cast in kevent_delete
Fixes the build on NetBSD where the compiler complains about casting NULL
to (int).
Signed-off-by: Martin Lucinam...@kotelna.sk
Applied to both maint and master.
Thanks!
Martin
Mikko,
Applied to master.
Thanks!
Martin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Martin,
as discussed, the upcoming 2.1.0 release will use proper ABI versioning, so
I'm sending a patch to bump the ABI version to 1.0.0.
This will need to be updated in the release procedures; the ABI version
should be reviewed as the last step before a public release; the comments
in
I hope this can fit in before the first 2.1 release.
--
Steve-o
0001-Bump-OpenPGM-to-5.0.92.patch
Description: Binary data
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
steven.mc...@miru.hk said:
I hope this can fit in before the first 2.1 release.
Done.
Cheers,
-mato
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Hi all,
we're pleased to announce that 0MQ version 2.1.0 (Beta) has been released
and is available for download at:
* http://download.zeromq.org/zeromq-2.1.0.tar.gz (UNIX line endings)
* http://download.zeromq.org/zeromq-2.1.0.zip (Windows line endings)
As part of improving the 0MQ downloads,
On Wed, Dec 1, 2010 at 4:53 PM, Steve Atkins st...@blighty.com wrote:
make check-TESTS
PASS: test_pair_inproc
PASS: test_pair_ipc
PASS: test_pair_tcp
PASS: test_reqrep_inproc
PASS: test_reqrep_ipc
PASS: test_reqrep_tcp
Assertion failed: nbytes == sizeof (command_t) (mailbox.cpp:193)
Mato, Martin, Mikko, and everyone who contributed to ØMQ/2.1...
Congratulations on a major new release!
-Pieter
On 1 Dec 2010 17:14, Martin Lucina m...@kotelna.sk wrote:
Hi all,
we're pleased to announce that 0MQ version 2.1.0 (Beta) has been released
and is available for download at:
*
Hi Steve,
st...@blighty.com said:
This build reliably fails it's self tests on OS X.
./configure make check
[...]
make check-TESTS
PASS: test_pair_inproc
PASS: test_pair_ipc
PASS: test_pair_tcp
PASS: test_reqrep_inproc
PASS: test_reqrep_ipc
PASS: test_reqrep_tcp
Assertion
Folks;
I realize that I'm dealing with an edge case here, CentOS 4 is long in
the tooth to say the least, but that's the environment we're stuck
with for the moment at my work place.
I get this identical error when building from Git or tarball, I also
upgraded autoconf, automake, libtool and m4
cpa...@gmail.com said:
Folks;
I realize that I'm dealing with an edge case here, CentOS 4 is long in
the tooth to say the least, but that's the environment we're stuck
with for the moment at my work place.
I get this identical error when building from Git or tarball, I also
upgraded
On Wed, Dec 1, 2010 at 2:47 PM, Martin Lucina m...@kotelna.sk wrote:
cpa...@gmail.com said:
Folks;
I realize that I'm dealing with an edge case here, CentOS 4 is long in
the tooth to say the least, but that's the environment we're stuck
with for the moment at my work place.
I get this
cpa...@gmail.com said:
On Wed, Dec 1, 2010 at 2:47 PM, Martin Lucina m...@kotelna.sk wrote:
cpa...@gmail.com said:
Folks;
I realize that I'm dealing with an edge case here, CentOS 4 is long in
the tooth to say the least, but that's the environment we're stuck
with for the moment at my
Hello All!
I was just reading the Advanced Stuff chapter of the guide and found the
XREP socket as a router pretty interesting.
I just need a clarification that is not found anywhere in the guide or else
where.
XREP(Router) uses the identity envelope to route the message to the correct
On Dec 1, 2010, at 2:57 PM, Praveen Baratam wrote:
Hello All!
I was just reading the Advanced Stuff chapter of the guide and found the XREP
socket as a router pretty interesting.
I just need a clarification that is not found anywhere in the guide or else
where.
XREP(Router) uses
Dear Chuck,
Thanks for the quick reply.
Well if ever an Identity is reused, I guess the earlier socket connected
with that identity will be orphaned and all the messages will be routed to
the new socket with that ID. Effectively the session held by the old socket
will be hijacked by the new one.
On Dec 1, 2010, at 4:19 PM, Praveen Baratam wrote:
Dear Chuck,
Thanks for the quick reply.
Well if ever an Identity is reused, I guess the earlier socket connected with
that identity will be orphaned and all the messages will be routed to the new
socket with that ID. Effectively the
woot!
--d
2010/12/2 Martin Lucina m...@kotelna.sk:
Hi all,
we're pleased to announce that 0MQ version 2.1.0 (Beta) has been released
and is available for download at:
* http://download.zeromq.org/zeromq-2.1.0.tar.gz (UNIX line endings)
* http://download.zeromq.org/zeromq-2.1.0.zip
On Wed, Dec 1, 2010 at 12:15 PM, Pieter Hintjens p...@imatix.com wrote:
Mato, Martin, Mikko, and everyone who contributed to ØMQ/2.1...
Congratulations on a major new release!
-Pieter
On 1 Dec 2010 17:14, Martin Lucina m...@kotelna.sk wrote:
Hi all,
we're pleased to announce that 0MQ
Hi Praveen,
On Wed, Dec 1, 2010 at 2:19 PM, Praveen Baratam
praveen.baratam+...@gmail.com wrote:
Dear Chuck,
Thanks for the quick reply.
Well if ever an Identity is reused, I guess the earlier socket connected
with that identity will be orphaned and all the messages will be routed to
the new
On short test runs the underlying socket isn't plugged, on longer test runs
the encoder is stalling, on longer tests some messages are pushed through
and then the encoder stalls again.
*remote_thr.exe epgm://10.6.15.88;239.192.0.1:7500 100 1*
pub_t::xsend
single pipe
pgm_sender_t::pgm_sender_t
On 2 December 2010 12:54, Steven McCoy steven.mc...@miru.hk wrote:
*remote_thr.exe epgm://10.6.15.88;239.192.0.1:7500 100 3*
pub_t::xsend
single pipe
pub_t::xsend
single pipe
pub_t::xsend
single pipe
pgm_sender_t::pgm_sender_t
pgm_sender_t::init
pgm_sender_t::plug
On 2 December 2010 13:16, Steven McCoy steven.mc...@miru.hk wrote:
* zmq_assert (!!to_write);*
Which produces the following output with the encoder trying to pull beyond
the test data.
*remote_thr.exe epgm://10.6.15.88;239.192.0.1:7500 100 5*
pub_t::xsend
single pipe
pub_t::xsend
single
On 2 December 2010 13:23, Steven McCoy steven.mc...@miru.hk wrote:
to_write 100 // message #1 payload
Ok, imagine the numbers were actually incrementing.
Looks like a concurrency issue. If I add the following simple trace the
issue disappears,
bool zmq::encoder_t::message_ready ()
{
On 2 December 2010 14:11, Steven McCoy steven.mc...@miru.hk wrote:
On 2 December 2010 13:51, Steven McCoy steven.mc...@miru.hk wrote:
Looks like a concurrency issue. If I add the following simple trace the
issue disappears,
Or just a compiler bug or feature, too much code being inlined
On 2 December 2010 14:14, Steven McCoy steven.mc...@miru.hk wrote:
Disable optimisation for encoder.cpp and it works as expected.
Alternative is a memory barrier before the re-init of in_progress.
bool zmq::encoder_t::message_ready ()
{
LONG volatile target = 0;
// Destroy content of the
26 matches
Mail list logo
