Re: [zeromq-dev] Problem building application in Suse 11.3 (uuid lib issues)
Hi PJ, On Sun, Mar 6, 2011 at 10:34 PM, PJ Durai wrote: > Greetings, > > I am having some issues in building my application in Suse 11.3 instalation. > > Zero MQ library itself has no problems building. > > But when I build my application, I end up with the following error > > /home/pi/dev/lib/libzmq.a(libzmq_la-uuid.o): In function `uuid_t': > /home/pi/tmp/zeromq-2.1.2/src/uuid.cpp:80: undefined reference to > `uuid_generate' > /home/pi/tmp/zeromq-2.1.2/src/uuid.cpp:81: undefined reference to > `uuid_unparse' > > I have installed, reinstalled uuid-dev packages from repositories. To no > avail. > You have to link your app with -luuid :-P Dhammika ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Problem building application in Suse 11.3 (uuid lib issues)
Greetings, I am having some issues in building my application in Suse 11.3 instalation. Zero MQ library itself has no problems building. But when I build my application, I end up with the following error /home/pi/dev/lib/libzmq.a(libzmq_la-uuid.o): In function `uuid_t': /home/pi/tmp/zeromq-2.1.2/src/uuid.cpp:80: undefined reference to `uuid_generate' /home/pi/tmp/zeromq-2.1.2/src/uuid.cpp:81: undefined reference to `uuid_unparse' I have installed, reinstalled uuid-dev packages from repositories. To no avail. These are the UUID related packages installed in the system. pi@susie:~/tmp/zeromq-2.1.2> rpm -qa | grep uuid libuuid1-2.17.2-5.3.i586 libuuid-devel-2.17.2-5.3.i586 Some more information if that would help: pi@susie:~/source/imo/Apps/Apns/ApnsRelay/Linux> uname -a Linux susie 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 i686 i686 i386 GNU/Linux pi@susie:~/source/imo/Apps/Apns/ApnsRelay/Linux> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.5/lto-wrapper Target: i586-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic --build=i586-suse-linux Thread model: posix gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) (I have no problems in building on Windows with Visual Studio 2005) Appreciate your time. thanks pj ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] 0MQ stable release 2.1 (v2.1.2, rc2) released
woot! zeromq team++ --d 2011/3/6 Pieter Hintjens : > Hi all, > > We're pleased to announce that 0MQ stable release 2.1 (v2.1.2, rc2) > has been released and is available for download at: > > * http://download.zeromq.org/zeromq-2.1.2.tar.gz (UNIX line endings) > * http://download.zeromq.org/zeromq-2.1.2.zip (Windows line endings) > > This 2.1 release candidate is considered highly stable especially over > 2.0.10. We recommend you use this release for all 0MQ projects where > possible. It fixes several memory leaks since rc1, and OpenPGM should > be working properly again. > > The release notes follow this email; full details can of course be > found in the ChangeLog included in the distribution. > > - > Pieter Hintjens > iMatix > > > 0MQ version 2.1.2 (rc2), released on 2011/03/06 > === > > Bug fixes > - > > * 0MQ now correctly handles durable inproc sockets; previously it ignored > explicit identities on inproc sockets. > > * Various memory leaks were fixed. > > * OpenPGM sender/receiver creation fixed. > ___ > 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] 0MQ stable release 2.1 (v2.1.2, rc2) released
On 6 March 2011 17:36, Pieter Hintjens wrote: > This 2.1 release candidate is considered highly stable especially over > 2.0.10. We recommend you use this release for all 0MQ projects where > possible. It fixes several memory leaks since rc1, and OpenPGM should > be working properly again. > > I'd note that there is a 5.0.93 package available and I recently sent a 5.0.94 commit to the 5.0 branch backporting various fixes for Windows 64-bit, SPARC and C++ applications. When targeting 5.1.110 it looks like I broke Win64 again when ticket locks are enabled, hopefully someone with MASM64 experience can verify my patches. Alternative is just to use adaptive mutexes and slim read-write locks and disable the ticket & dumb read-write lock headers. -- Steve-o ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] [PATCH] Update to OpenPGM 5.1.110.
On 7 March 2011 01:31, Alex Forster wrote: > Steven McCoy miru.hk> writes: > > > Clean builds under Win64. > > ... > > Improve spinlock performance with inline ticket based spinlock > implementation. > > > http://www.google.com/search?q=__asm+keyword+not+supported+on+this+architecture > > ticket.h is coughing up because Visual C++ doesn't support inline assembly > when > targeting 64-bit. > > Oh that's nice. > http://code.google.com/p/openpgm/source/diff? > > spec=svn1294&r=1294&format=side&path=/trunk/openpgm/pgm/include/impl/ticket.h > > This diff points out where the problem areas are- > > pgm_atomic_add8 > pgm_atomic_fetch_and_add8 > pgm_atomic_inc8 > > pgm_atomic_add16 > pgm_atomic_fetch_and_add16 > pgm_atomic_inc16 > > It was a clean build before ticket locks :-) I've added some MASM64 to trunk to implement the assembler as functions but I'm without 64-bit MSVC to test, I wouldn't say I"m overly confident on the 64-bit assembler either. -- Steve-o ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] 0MQ stable release 2.1 (v2.1.2, rc2) released
On Sun, Mar 6, 2011 at 9:17 PM, MinRK wrote: > Thanks, I think that makes sense. It's mainly the 'stable beta release' that > caused problems. The small change to the download page is perfect. OK, great. > I think it is a good idea to push people to test the new software, but > being ambiguous about > its stability wasn't helping. It's important to note that calling a > release a 'candidate' or 'beta' > is specifically asking some users *not* to use it (whether you mean it > or not, that's what the words mean to people). Indeed, that was the intention... > As soon as you want everybody to be using a certain version, there > should be no qualifiers. Indeed. We're about a week, 10 days from stable 2.1 afaics, which will be 2.1.3. Once we have that, I'll start making releases (unstable :-) of 2.2. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Fwd: 0MQ stable release 2.1 (v2.1.2, rc2) released
Sorry, forgot to reply to the list... -- Forwarded message -- From: Pieter Hintjens Date: Sun, Mar 6, 2011 at 8:40 PM Subject: Re: [zeromq-dev] 0MQ stable release 2.1 (v2.1.2, rc2) released To: MinRK On Sun, Mar 6, 2011 at 8:15 PM, MinRK wrote: > I do have a question about the use of version numbers and release > candidates. We decided to: (a) continue to increment the version numbers so we have a unique identifier for every release; (b) use the rc notiation to indicate "close to stability" So rc1, rc2 is not part of the version numbering, e.g. on pages like http://api.zeromq.org. It's descriptive. The 'real' version number is in include/zmq.h and the major/minor/patch format hasn't changed. When the 2.1 branch is formally stable, we'll continue to increment the version number sequentially if there are later stable releases. Thus, if we have patches to 2.0.x they'll be released as 2.0.11. Sorry that this doesn't follow tradition. There are other ways to get the same results but they become awkward, e.g. using even numbers for stable versions. > It might be preferable on the website to use just the qualified names: > release candidate: 2.1.2 > stable release: 2.0.10 There is value IMO in pushing people to use the RCs. I've modified the wording a little, see if it works better. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] 0MQ stable release 2.1 (v2.1.2, rc2) released
This is great, it looks like the new repo organization is having the desired effect! I do have a question about the use of version numbers and release candidates. The traditional model for beta/rc is that they represent an unfinished revision to a given version, i.e. 2.1.1-beta will become 2.1.1-rc1, and eventually 2.1.1, but 0MQ is following a model unfamiliar to me, where every beta and release candidate has its own version. It seems more like the model here is: 2.1-beta (called 2.1.0-beta), and 2.1-rc1 (2.1.1-rc1), etc. The result of this is that the website called 2.1.0 both a beta release *and* a stable release, which makes it unclear which classes of users should be using it. By the traditional understanding of the terms (as far as I know), 'stable release' and 'beta' or 'release candidate' are mutually exclusive. A stable release means it is ready for package managers and timid enterprise users to update, and the other two specifically mean the opposite, but a real release is on the way. It might be preferable on the website to use just the qualified names: release candidate: 2.1.2 stable release: 2.0.10 rather than both, as it has been: stable release: 2.1.0 beta stable release: 2.0.10 -MinRK On Sun, Mar 6, 2011 at 01:36, Pieter Hintjens wrote: > Hi all, > > We're pleased to announce that 0MQ stable release 2.1 (v2.1.2, rc2) > has been released and is available for download at: > > * http://download.zeromq.org/zeromq-2.1.2.tar.gz (UNIX line endings) > * http://download.zeromq.org/zeromq-2.1.2.zip (Windows line endings) > > This 2.1 release candidate is considered highly stable especially over > 2.0.10. We recommend you use this release for all 0MQ projects where > possible. It fixes several memory leaks since rc1, and OpenPGM should > be working properly again. > > The release notes follow this email; full details can of course be > found in the ChangeLog included in the distribution. > > - > Pieter Hintjens > iMatix > > > 0MQ version 2.1.2 (rc2), released on 2011/03/06 > === > > Bug fixes > - > > * 0MQ now correctly handles durable inproc sockets; previously it ignored > explicit identities on inproc sockets. > > * Various memory leaks were fixed. > > * OpenPGM sender/receiver creation fixed. > ___ > 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] List of ideas for GSoC
On Sun, Mar 6, 2011 at 6:01 PM, Martin Sustrik wrote: > Also, it would be helpful to expand the text. Say: "Implement a delivery > mechanism that can withstand restarts of both the sender and receiver," > doesn't make much sense for me. Seems clear enough. This particular functionality is almost done for Ch4 of the Guide, Titanic pattern running over Majordomo protocol. MDP is at http://rfc.zeromq.org/spec:7, for those who care. We have C and Python interoperating already. A lot of these wishes (indeed that's what it looks like) should/can be layered on top of 0MQ. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] [PATCH] Update to OpenPGM 5.1.110.
Steven McCoy miru.hk> writes: > Clean builds under Win64. > ... > Improve spinlock performance with inline ticket based spinlock implementation. http://www.google.com/search?q=__asm+keyword+not+supported+on+this+architecture ticket.h is coughing up because Visual C++ doesn't support inline assembly when targeting 64-bit. http://code.google.com/p/openpgm/source/diff? spec=svn1294&r=1294&format=side&path=/trunk/openpgm/pgm/include/impl/ticket.h This diff points out where the problem areas are- pgm_atomic_add8 pgm_atomic_fetch_and_add8 pgm_atomic_inc8 pgm_atomic_add16 pgm_atomic_fetch_and_add16 pgm_atomic_inc16 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] List of ideas for GSoC
Hi all, The page listing the ideas for GSoC looks like a feature wishlist at the moment. Can the authors please reexamine the list and check whether the items are actually doable by a studing during the summer? I think that say implementing XA distributed transactions are far beyond the scope. Also, it would be helpful to expand the text. Say: "Implement a delivery mechanism that can withstand restarts of both the sender and receiver," doesn't make much sense for me. Thanks! Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] GSoC ideas inquiry
Hi Yin,
First of all, you should be aware that organisations participating in
GSoC are to be approved on March 18th. So, 0MQ may or may not be
approved. Still, you are free to contribute to 0MQ in either case.
> I am a CS master student from China, and got interested in some of
> your listed Summer of Code ideas.
>
> First I have to admit that I am new to 0MQ with only a little MQ
> knowledge, but I do have experience in network programming through
> several projects. I enjoy playing with networked systems. I had one
> prior GSoC experience by successfully implementing a task scheduler
> for a cluster computing framework.
Note that the list of ideas is, well, just a list of ideas. You are free
to propose ideas of your own. Given your experience with scheduling,
what about implementing a multi-priority O(1) scheduler for 0MQ (so that
specific connections could be used if preference to other connections)?
> I just checked out the code on github, and took a quick look at the
> guide to see the big picture. Then I got back to the GSoC ideas, and
> would like to implement the following two ideas:
>
> 1) 0MQ Ports Is this idea suggesting, when the tcp transport is used,
> we support creating an endpoint that is able to multiplex incoming
> connections? For example, after doing zmq_bind(sock, "tcp://*:"),
> we can subsequently zmq_connect to "tcp://server_address::1",
> "tcp://server_address::2", etc. (actual syntax yet to be
> defined), the trailing section after the last colon indicating the
> virtual sub-port that the peer wants to connect?
>
> If my understanding is correct, I think the fundamental change should
> be to maintain separate queues for sub-ports, and to modify the way
> the decoder handles incoming tcp data so that it can direct the
> incoming message to the right channel. Please fill with more details
> here for me as I am not yet familiar with 0MQ internals.
No. It's not as complex as that. The ideas is that you could
zmq_bind("tcp://*::1") on one side and
zmq_connect("tcp://localhost::1") on the other side, so what's
needed is to send the "subport" number over the connection on connect(),
receive it on the binding side and assign the new connection to correct
0MQ socket. The hard part about it is that "listener" object would have
to be shared between multiple 0MQ sockets, ie. you would have to take
care of reference counting, proper shutdown etc.
However, keep in mind that this functionality is more of a hack usable
in special corporate scenarios, where firewall blocks all the port
except a single one, so you just *have* to multiplex.
The downside is that if one application binds to tcp://*::1, another
application won't be able to bind to tcp://*::2. It would crash with
EADDRINUSE error. Sharing of listener can be done within a single
process, however, there's no way to share listener between processes.
> 2) Certified sockets I love this idea because I like extremely robust
> designs :-) Unfortunately, I don't have much clue about it. Could you
> give a specific example about this? Besides, is there any restriction
> on the type of the underlying transport if we try to implement
> certified sockets?
This idea have been suggested by Steven McCoy. I don't know what is
actually meant to be. Steven, can you please be more specific about the
idea?
> So basically I want to know more details about these two ideas so
> that I can estimate the scope and the size of the projects. By the
> way, will a summer project consist of a single idea or several ones?
> If it is the former case, I shall pick one from the two.
It's up to our agreement. The project scope should be such that it
matches the timeline (May 23rd - August 22nd). To be discussed.
Martin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Ruby binding s.recv returns 0-terminated string
On Sun, Mar 6, 2011 at 5:12 PM, Han Holl wrote: > It's an almost literal copy from the guide: > // Send reply back to client > zmq::message_t reply (6); > memcpy ((void *) reply.data (), "World", 5); > socket.send (reply); Yes, the C++ code had an error (fixed now). Thanks for catching this. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Ruby binding s.recv returns 0-terminated string
On 03/06/2011 05:12 PM, Han Holl wrote: > zmq::message_t reply (3); > memcpy ((void *) reply.data (), "OK", 2); > socket.send (reply); It's definitely an error. The third byte is un-initialiased, so it's not even guaranteed to be zero. Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Ruby binding s.recv returns 0-terminated string
On Sunday, March 06, 2011, Pieter Hintjens wrote: > On Sun, Mar 6, 2011 at 12:21 PM, Mikko Koppanen > > wrote: > > as the message data is an opaque binary blob I am not sure whether > > removing the trailing \0 is correct behaviour. If you are receiving a > > message with a trailing \0 it means that the sender has included it as > > a part of the message. > > Indeed... this seems to be a fault in the sender. The convention for > strings encoded as 0MQ frames is to NOT include a terminating null > byte. > > -Pieter Hi, Here's the code in the sender (C++): zmq::message_t reply (3); memcpy ((void *) reply.data (), "OK", 2); socket.send (reply); It's an almost literal copy from the guide: // Send reply back to client zmq::message_t reply (6); memcpy ((void *) reply.data (), "World", 5); socket.send (reply); So I guess I should have reported an error in the guide. Thanks for the prompt replies. I've reverted my patch. Han Holl ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Ruby binding s.recv returns 0-terminated string
On Sun, Mar 6, 2011 at 12:21 PM, Mikko Koppanen wrote: > as the message data is an opaque binary blob I am not sure whether > removing the trailing \0 is correct behaviour. If you are receiving a > message with a trailing \0 it means that the sender has included it as > a part of the message. Indeed... this seems to be a fault in the sender. The convention for strings encoded as 0MQ frames is to NOT include a terminating null byte. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Ruby binding s.recv returns 0-terminated string
On Sat, Mar 5, 2011 at 8:49 PM, Han Holl wrote: > > Hi, > > The function > s.recv > returns a string like "OK\000", at least with my ruby-1.8.7.334-1.fc14.x86_64. > Maybe there are ruby implementations that make the trailing zero go away. Hi, as the message data is an opaque binary blob I am not sure whether removing the trailing \0 is correct behaviour. If you are receiving a message with a trailing \0 it means that the sender has included it as a part of the message. It is perfectly OK to send non-null terminated blobs as well and removing the last character would possibly break this. -- Mikko Koppanen ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] 0MQ stable release 2.1 (v2.1.2, rc2) released
Hi all, We're pleased to announce that 0MQ stable release 2.1 (v2.1.2, rc2) has been released and is available for download at: * http://download.zeromq.org/zeromq-2.1.2.tar.gz (UNIX line endings) * http://download.zeromq.org/zeromq-2.1.2.zip (Windows line endings) This 2.1 release candidate is considered highly stable especially over 2.0.10. We recommend you use this release for all 0MQ projects where possible. It fixes several memory leaks since rc1, and OpenPGM should be working properly again. The release notes follow this email; full details can of course be found in the ChangeLog included in the distribution. - Pieter Hintjens iMatix 0MQ version 2.1.2 (rc2), released on 2011/03/06 === Bug fixes - * 0MQ now correctly handles durable inproc sockets; previously it ignored explicit identities on inproc sockets. * Various memory leaks were fixed. * OpenPGM sender/receiver creation fixed. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
