> 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 wi
> 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
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 wrote:
> On 7 March 2011 01:31, Alex Forster wrote:
> Steven McCoy miru.hk> writes:
>
> > Clean builds under Win64.
> > ...
> > Imp
e:
> Ok, installed MSVC x64 and it nows builds in trunk with cmake -G "NMake
> Makefiles". Still might be broken though :D
>
> --
> Steve-o
>
> On 7 March 2011 12:08, Steven McCoy wrote:
> On 7 March 2011 01:31, Alex Forster wrote:
> Steven McCoy m
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 asse
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 ge
> Pieter Hintjens 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
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 tw
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
> 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
> 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 ZeroM
> 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 thr
> 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
> applica
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
14 matches
Mail list logo
