On Thu, Feb 16, 2012 at 11:39 AM, Boris Gulay bo...@boressoft.ru wrote:
27.01.2012 19:30, Pieter Hintjens пишет:
See http://www.zeromq.org/docs:contributing for submitting the
patches. You can attach comments to a github pull request, or use this
list to discuss your changes. Both will work
I've just downloaded latest branch (from libzmq repo on GitHub) and try
to compile it for Windows with MSVC 2008.
Compilation fails because if inet_ntop function which is available only
on Vista and later but windows.hpp declares _WIN32_WINNT as 0x0501 which
means Windows XP (
On Thu, Feb 16, 2012 at 5:39 AM, Boris Gulay bo...@boressoft.ru wrote:
Whet repo should I use to submit a patch?
zeromq2-1 is OK? I have made my port to WM on ZeroMQ 2.1 source.
Like Mikko said, the right place is libzmq (3.1). You may also want to
point people to your 2.1 fork, if they want
Any chance of pull request 39 for the zeromq2-1 repo getting applied?
Without them, 2-1 won't build on HPUX
Thank you,
--
AJ Lewis
Software Engineer
Quantum Corporation
Work:651 688-4346
--
The information contained in
On Thu, Feb 16, 2012 at 11:38 AM, AJ Lewis aj.le...@quantum.com wrote:
Any chance of pull request 39 for the zeromq2-1 repo getting applied?
Without them, 2-1 won't build on HPUX
Sorry for missing that. I've pulled it into zeromq2-1 master, and the
patch will go into 2.1.12.
Thanks
Pieter
Hi guys,
In short: inet_ntop is not available in Windows XP.
I'm maintaining a side project, where I have luajit ffi bindings for
zeromq, and support them for osx, windows, linux, etc.
One of my platforms is Windows XP, and I use Windows DDK, now called
just WDK, so I
On 17/02/2012, at 5:43 AM, Dimiter 'malkia' Stanev wrote:
other people might be affected. (Then again who would used Windows XP
still :))
I do, for my yacht's backup chart plotter (because the software doesn't run on
Vista).
--
john skaller
skal...@users.sourceforge.net
Hi guys,
I have a question about ZMQ_HAUSNUMERO in zmq.h. It looks like this is a
workaround the Windows headers, so that proper Exxx error codes are
declared.
I'm just having hard-time translating this correctly into a binding.
For example:
#ifndef EPROTONOSUPPORT
#define EPROTONOSUPPORT
On Thu, Feb 16, 2012 at 12:11:17PM -0600, Pieter Hintjens wrote:
On Thu, Feb 16, 2012 at 11:38 AM, AJ Lewis aj.le...@quantum.com wrote:
Any chance of pull request 39 for the zeromq2-1 repo getting applied?
Without them, 2-1 won't build on HPUX
Sorry for missing that. I've pulled it into
16.02.2012 22:43, Dimiter 'malkia' Stanev пишет:
Hi guys,
In short: inet_ntop is not available in Windows XP.
I write message about that five hours ago (subject Compile branch with
MSVC). :)
I agree, this function should not be used if we want ZeroMQ compile on
XP. But your
Ah, no :) Boost is one thing that I try to avoid. I'm actually more of
a C guy that C++ and zmq has been nice to have first and foremost
C interface, even if written in C++.
I was more thinking of the second solution:
http://stackoverflow.com/a/1564907/743263
On 16 February 2012 13:43, Dimiter 'malkia' Stanev mal...@gmail.com wrote:
Hi guys,
In short: inet_ntop is not available in Windows XP.
No idea why Microsoft finally added it to Windows Vista when the API is
already known to be broken with IPv6, just use getnameinfo()
--
I'm using a jruby gem that has it's own reactor, and monitors zeromq
file descriptors so you can send messages to the reactor via zeromq.
I'm running into a strange issue where the reactor is not getting
events from the fd. It gets a couple then no more. This happens to
me when using the queue
On Thu, Feb 16, 2012 at 8:36 PM, Steven McCoy steven.mc...@miru.hk wrote:
On 16 February 2012 13:43, Dimiter 'malkia' Stanev mal...@gmail.comwrote:
Hi guys,
In short: inet_ntop is not available in Windows XP.
No idea why Microsoft finally added it to Windows Vista when the
Hi,
Does anyone have a valid use case for thread-safe sockets? It seems
that the semantics are fuzzy and using this would lead to poor design.
What happens if two threads are polling the same sockets, but one
message arrives? What if two threads are in a blocking recv on the
same socket?
If we
On Feb 16, 2012, at 3:51 PM, Pieter Hintjens wrote:
Hi,
Does anyone have a valid use case for thread-safe sockets? It seems
that the semantics are fuzzy and using this would lead to poor design.
What happens if two threads are polling the same sockets, but one
message arrives?
zmq_poll()
On Thu, Feb 16, 2012 at 4:05 PM, Chuck Remes cremes.devl...@mac.com wrote:
I don't have a use-case but I think there are at least 2 people on the list
who do. I hope they speak up.
Well, the minimal implementation is on libzmq/master, so anyone who
wants to try it can do so now.
-Pieter
Thanks guys! Awesome community!
On 2/16/2012 12:45 PM, Ian Barber wrote:
On Thu, Feb 16, 2012 at 8:36 PM, Steven McCoy steven.mc...@miru.hk
mailto:steven.mc...@miru.hk wrote:
On 16 February 2012 13:43, Dimiter 'malkia' Stanev mal...@gmail.com
mailto:mal...@gmail.com wrote:
On Thu, Feb 16, 2012 at 4:10 PM, Dimiter 'malkia' Stanev
mal...@gmail.com wrote:
Thanks guys! Awesome community!
Ian's patch is now merged into libzmq/master.
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
Synced to latest, but ssize_t is not declared for Windows WDK 7.1, and
one of the zmq.h functions uses it.
There is an easy workaround -Dssize_t=ptrdiff_t for my compilation
process (I compile the library using my own batch file). There is also
intptr_t, but I chose ptrdiff_t for the
Actually in WDK there is SSIZE_T (not a macro), which seems more
appropriate for the workaround (e.g. -Dssize_t=SSIZE_T).
There is one more problem, unrelated to it:
socket_base.cpp
..\..\..\src\socket_base.cpp(468) : error C2512: 'zmq::ipc_address_t' :
no appropriate default constructor
On Thu, Feb 16, 2012 at 4:38 PM, Dimiter 'malkia' Stanev
mal...@gmail.com wrote:
Actually in WDK there is SSIZE_T (not a macro), which seems more
appropriate for the workaround (e.g. -Dssize_t=SSIZE_T).
You may define this conditionally in include/zmq.,h, and in
src/msg.hpp. If that works,
I would like to propose another point, for your consideration.
I don't know that it is a good idea to marry 0mq to a threading library
(even if it is a platform foundation like pthreads), as this might make
adoption hard for folks that need to in other threading environments,
such as TBB or
Hi all,
It's probably a good time to start moving 0MQ/3.1 towards stable status.
Several things you can do to help:
* If you have outstanding issues in 3.1 that you need fixed, please
remind us of them
* If you're maintaining a language binding, make sure you have 3.1
support in place
* If
On Thu, Feb 16, 2012 at 5:12 PM, Luca Fascione lu...@wetafx.co.nz wrote:
I don't know that it is a good idea to marry 0mq to a threading library
(even if it is a platform foundation like pthreads), as this might make
adoption hard for folks that need to in other threading environments,
such
Great news, Pieter. I just did a build of our rsyslog plugins against 3.1
today to start testing.
Brian
On Thu, Feb 16, 2012 at 6:14 PM, Pieter Hintjens p...@imatix.com wrote:
Hi all,
It's probably a good time to start moving 0MQ/3.1 towards stable status.
Several things you can do to
So the two main issues we need to fix are #264 and #270. They are, by
all accounts, extremely hard to solve, and anyone finding a clean
solution would be regarded with awe and admiration.
-Pieter
On Thu, Feb 16, 2012 at 5:28 PM, Brian Knox taote...@gmail.com wrote:
Great news, Pieter. I just
On Feb 16, 2012, at 5:50 PM, Pieter Hintjens wrote:
So the two main issues we need to fix are #264 and #270. They are, by
all accounts, extremely hard to solve, and anyone finding a clean
solution would be regarded with awe and admiration.
-Pieter
Yes, plus both issues have C test cases to
On 17/02/2012, at 7:41 AM, snacktime wrote:
I'm using a jruby gem that has it's own reactor, and monitors zeromq
file descriptors so you can send messages to the reactor via zeromq.
I'm running into a strange issue where the reactor is not getting
events from the fd. It gets a couple then
On 17/02/2012, at 8:51 AM, Pieter Hintjens wrote:
Hi,
Does anyone have a valid use case for thread-safe sockets?
There's an example in the test cases. Using ts sockets to serialise
sends from different threads is much easier than using inproc
transport.
You can take any existing code that
On 17/02/2012, at 9:05 AM, Chuck Remes wrote:
On Feb 16, 2012, at 3:51 PM, Pieter Hintjens wrote:
Hi,
Does anyone have a valid use case for thread-safe sockets? It seems
that the semantics are fuzzy and using this would lead to poor design.
What happens if two threads are polling the
On 17/02/2012, at 10:12 AM, Luca Fascione wrote:
Also, if my app is using already libzmq in a thread safe way, why should
I pay for all this locking and unlocking?
You pay for a boolean test only: the locking is conditional
on a flag.
--
john skaller
skal...@users.sourceforge.net
On Thu, Feb 16, 2012 at 6:32 PM, john skaller
skal...@users.sourceforge.net wrote:
No need to change it at all. It is the same as now: if you misuse a feature,
you can't
expect reliable results.
The difference is now you get unexpected results instead of a segfault.
There needs to be a
I've updated the 2.1 - 3.1 conversion guide here:
http://www.zeromq.org/docs:3-1-upgrade
Will retest tomorrow with CZMQ. If anyone has things to correct or add
on that page, go for it...
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
On 17/02/2012, at 10:14 AM, Pieter Hintjens wrote:
Hi all,
It's probably a good time to start moving 0MQ/3.1 towards stable status.
Several things you can do to help:
Sure: please fork or whatever is necessary, the Guide
so there is an editable 3.1 version.
Please check all the 3.1
nice.
I'll rename the perl binding to ZMQ for 3.1 support as well
--d
2012/02/17 8:14 Pieter Hintjens p...@imatix.com:
Hi all,
It's probably a good time to start moving 0MQ/3.1 towards stable status.
Several things you can do to help:
* If you have outstanding issues in 3.1 that you need
On 17/02/2012, at 11:41 AM, Pieter Hintjens wrote:
John, if you had a single clear use case yourself, code which is ugly
and fragile without this, and simpler with it, that would help a lot.
libzmq/tests/test_ts_context.cpp
uses it, you could rewrite that with inproc and compare.
I
Just a comment on the *misconception* that it is OK to do thread
safety in a binding or application logic.
No, it isn't. The reason is illustrated by a counter example:
1. CPython-ZMQ binding.
2. CPython-fun-twister stuff client API.
The problem is that (1) might add thread safety.
But (2)
For 3.1.x release:
More tests and ifo about ZMQ_ROUTER to ZMQ_ROUTER bug LIBZMQ-304.
https://zeromq.jira.com/browse/LIBZMQ-304
ZMQ_ROUTER to ZMQ_ROUTER does not work for first sent messages. Message parts
are ok. In this test s_dump() is a non-blocking read. Blocking read will block
in first
Aja Walker a...@ciscor.com wrote:
Hi all!
I posted this question about a week ago, but it was fairly long-winded, and
there was some other deep, heated discussion going on so I thought I'd give
it one more shot. I hope I'm not offending the etiquette of the mailing list
by re-posting,
On Feb 16, 2012, at 8:56 PM, john skaller wrote:
There is an analogue in Posix: optional locking. It's fairly useless.
Because anyone can write into a locked region of a file by ignoring
the locks.
That is a pretty broad generalization. Advisory locks are quite useful
when you are dealing
On Thu, Feb 16, 2012 at 8:50 PM, Pasi Mankinen
mailing.l...@manageapp.com wrote:
For 3.1.x release:
More tests and ifo about ZMQ_ROUTER to ZMQ_ROUTER bug LIBZMQ-304.
https://zeromq.jira.com/browse/LIBZMQ-304
Pasi, can you add this to the Jira issue?
It's possible that the removal of
On 17.02.2012, at 3:32, john skaller skal...@users.sourceforge.net wrote:
On 17/02/2012, at 9:05 AM, Chuck Remes wrote:
On Feb 16, 2012, at 3:51 PM, Pieter Hintjens wrote:
zmq_poll() would probably need to be modified to disallow multiple threads
from polling. Alternately, zmq_poll()
I am by far no expert in 0MQ, but actually the question of thread-safe
socket is no question any more for me. It has been written in the
documentation in a clear way, that one should not use sockets from
different threads. Over the last weeks - and due to a question from me -
it was in a more
I apologize for jumping in mid-conversation, but I see two thread-safety
goals:
1) 0MQ has no built-in locks on sockets. Applications may use a socket in
different threads provided the application itself uses its own locks around the
socket accesses.
2) 0MQ has its own locks built-in, so you
On Fri, Feb 17, 2012 at 3:25 AM, Pasi Mankinen
mailing.l...@manageapp.comwrote:
Hi.
I am not a C/C++ developer. I use higher level languages but sometimes I
do some simple C plugins. Zmq is so easy to use that even I can use it :).
I don't have a glue how to fix this correctly in zmq
46 matches
Mail list logo
