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
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
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
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
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
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
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
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
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
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
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
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 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
13 matches
Mail list logo
