Re: [zeromq-dev] [PATCH] Update to OpenPGM 5.1.110.
Ah, is that the trunk version you were saying you got to build successfully on x64? On Mar 6, 2011, at 11:08 PM, Steven McCoy steven.mc...@miru.hk wrote: On 7 March 2011 01:31, Alex Forster a...@alexforster.com wrote: Steven McCoy steven.mccoy at 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=svn1294r=1294format=sidepath=/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 Im 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] [PATCH] Update to OpenPGM 5.1.110.
The trunk builds but skips the asm because CMake 2.8.3 is broken, I've updated to 2.8.4 and CMake is too stupid to find MSVC 2010 Professional and asks me to install the 7.1 SDK so I end up with I guess six compilers now. Aha. The 8-bit and 16-bit atomics are a part of how ticket locks work, they improve latency in low contention situations, i.e. PGM bus scenarios. ?? didn't know what a ticket lock was until yesterday, so I'll take your word for it. Out of interest in playing with new integration features I'll see how long I can put up with the MASM before dumping it. How well do the asm files fit into the build system? Is it an issue? I spent more time than I'd like to admit yesterday googling, since I was only ~30 lines away from a successful build. Essentially the solution you came up with is the only solution there is if you want to maintain MSVC compatibility: use an external assembler. I haven't tried to compile trunk yet, but I'm sure it will be fine. It looks from the commit message that you did exactly what I did - check out how TBB does it. http://people.athenacr.com/~wchow/repos/tbb/tbb-2.0r014/src/tbb/ia32-masm/atomic_support.asm ___ 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.
Just minor tweaks, already noted on stackoverflow that ML64 does not have the same features as ML, the examples in the SDK have an invalid syntax when ported to x64. Also, CMake doesn't generate the MSVC project files including the asm, probably at a later date as it is plastered with notices. Not a huge deal to make the libs beforehand, it will still get me 95% of the way there. I'll give it a try sometime this week, thanks! ___ 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 steven.mccoy at 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=svn1294r=1294format=sidepath=/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
Re: [zeromq-dev] [PATCH] Update to OpenPGM 5.1.110.
This is /fantastic/ Some time in January, the project made a very strong push at improving the build environment in Windows. They introduced support for CMake, which as a developer I dislike, but as a user I very very much like. CMake makes it incredibly easy to target Visual Studio by actually generating the .sln's and .proj's for you. Thank you very much. This will make Windows developers' lives much easier. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Targeting ZeroMQ Interop (my C# wrapper) at ZeroMQ 2.1.0
I'm having a hell of a time compiling ZeroMQ 2.0.10 with support for OpenPGM 2.1.27-pre2. I got it down to 18 linker errors, and then I hit a wall because those errors are all related to missing MinGW libraries, and I'm using Visual Studio. My options now are: (1) dump Visual Studio, install the entire MinGW toolchain, and recompile everything introducing a MinGW dependency in the process, (2) compile .lib versions of the MinGW libraries since the dist binaries are all .a, or (3) move my project to ZeroMQ 2.1.0 which purportedly has ABI stability (very enticing), and support for the latest version of OpenPGM (thus no dependencies on glib). I've been taking a pretty thorough look at the commit log (https://github.com/zeromq/zeromq2/commits/master/) and at the issue log (https://github.com/zeromq/zeromq2/issues/labels/master) and it seems that 2.1.0 is very stable. I'm looking for (1) a general idea of how far along/stable 2.1.0 is, and (2) some feedback on how wise a decision it is to target my wrapper library at this development version. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Targeting ZeroMQ Interop (my C# wrapper) at ZeroMQ 2.1.0
On Feb 19, 2011, at 5:50 PM, Steven McCoy wrote: You can add the MinGW compiler dependencies into MSVC, they're listed here as libgcc.a libmingwex.a http://code.google.com/p/openpgm/wiki/OpenPgmCReferenceLinkTheseLibraryFiles That's a very helpful page. If I can get my hands on those two I'll give it another shot. Obviously OpenPGM 5.1 is a lot easier, I even provide a Windows installer so you don't have to build it yourself. Absolutely. I'm hoping to hear something like 2.1.0 is right around the corner! Don't even bother with 2.0.10 anymore.___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Targeting ZeroMQ Interop (my C# wrapper) at ZeroMQ 2.1.0
Pieter Hintjens ph at imatix.com Close enough to official for me. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] I've written a completely new C# API for ZeroMQ
Great! I would suggest adding a link to your project to www.zeromq.org. It's wiki, so you can do so yourself. Gladly, done. I am not familiar with CLR. Doesn't the problem the context is solving (i.e. zeromq being used from two libraries that are later on linked into a single application and step on each other toes) occur with .NET as well? That is a very good question that I don't know if I can answer. I figured the problem it was solving essentially boiled down to no global variables. Where is there an opportunity for undesirable interaction? A side issue: Wouldn't it make sense for you clrzmq, clrzmq2, NZMQ and Interop guys to at least start working on integration of all the projects? I mean, writing the code is easy, maintaining it and fixing the bugs is hard. If the projects are integrated into a single one you could support four time more features, fix four time more bug, make the whole binding four times more stable. Aside of that, having a community is much more fun than working alone :) I'd be up for it. How active is clrzmq2? NZMQ seems to have stalled 3-4 months ago. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] I've written a completely new C# API for ZeroMQ
For example, the names of inproc endpoints are stored in the context. If library A uses inproc endpoint named X and library B accidentally uses endpoint X as well, they start messining with each other. That's a very good point, I'll definitely have to address that. I'm willing to jump through hoops to keep automatic context management, since it's such a perfect fit for RAII-esque language features, and API simplicity was my main motivation for a rewrite. Are there any other specific points of contention you can think off off-hand, or are there any fundamental issues that completely prevent it from working stably this way? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] I've written a completely new C# API for ZeroMQ
You do know that clrzmq2 supported all of what you mentioned besides the reference counting. If you had of submitted a patch for clrzmq2 it would have been very welcome. I certainly didn't mean to offend. I'll admit that, while I did have some different ideas as to what a C#-ified ZeroMQ API should look like, the biggest motivator for my rewrite was to become more familiar with ZeroMQ. You'll notice that the p/invoke class (ZeroMQ.Interop) is heavily documented and tested - that was purely for my benefit. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] I've written a completely new C# API for ZeroMQ
I notice NUZQ seems to use lambdas, these were introduced in .NET 3.0, I purposely kept clrzmq2 targeting .net 2.0. The fact is a 2.0 is the prevalent .NET framework, many large organization will actually only be using that. The application I maintain as a day job is targeted at 2.0 and I work for a very large investment bank. While the project requires a .NET 3.5 compiler to transform the source into IL, the resulting assembly will run on any ECMA-334 (.NET 2.0) compatible CLI. The new language features added to C# in 3.5 all essentially boil down to syntactical sugar. As long as you don't reference any core assemblies that are 3.5-specific (System.Linq, System.Windows, System.ServiceModel, etc) your resulting assembly is .NET 2.0 compatible. http://www.hanselman.com/blog/HowDoExtensionMethodsWorkAndWhyWasANewCLRNotRequired.aspx ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] I've written a completely new C# API for ZeroMQ
I have quite a few gripes with clrzmq and clrzmq2, and NZMQ is incomplete in
several areas, so over a few weekends this past month I've written a new C# API
for ZeroMQ based on the 2.0.10 release of zmq.h.
ZeroMQ Interop v0.8.190.10354 (beta)
http://zeromq.codeplex.com
* Feature-complete
* MIT licensed
* Targeted at both Microsoft and Mono .NET 2.0 CLRs (though it does require a
3.5 compatible compiler, basically for lambda syntax)
* Includes binaries for both 32 and 64bit platforms (without any #ifdefs)
Here's an example using Pub/Sub sockets-
// Set up a publisher.
var publisher = new ZmqPublishSocket {
Identity = Guid.NewGuid().ToByteArray(),
RecoverySeconds = 10
};
publisher.Bind( address: tcp://127.0.0.1:9292 );
// Set up a subscriber.
var subscriber = new ZmqSubscribeSocket();
subscriber.Connect( address: tcp://127.0.0.1:9292 );
subscriber.Subscribe( prefix: ); // subscribe to all messages
// Add a handler to the subscriber's OnReceive event
subscriber.OnReceive += () = {
String message;
subscriber.Receive( out message, nonblocking: true );
Console.WriteLine( message );
};
// Publish a message to all subscribers.
publisher.Send( Hello world! );
A few things that make this sample stand out from the other two ZeroMQ C#
libraries-
* There's no need to manage your ZeroMQ context; it's taken care of on a
per-AppDomain basis using refcounting.
* There is no message object because it provides no added benefit in C#.
Messages are simply Byte[]s, with overloads throughout the API that accept
Strings.
* First-class support for .NET events programming, implemented using zmq_poll()
(but that's completely transparent to the user).
I'd love some feedback. I'm just starting to use it in a project I'm working
on, and so far it all seems to be working smoothly and at high throughput, but
I'm releasing it as beta because I don't feel that it has enough real-world
experience yet.
Alex Forster___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
