Months ago I was selecting .NET library to use for implementing ZeroMQ communication, and I was pretty confused with the fact that there are few libraries suggested at zeromq.org.
Meanwhile I've learned few things, so I'll share here. Someone may find this helpful. So let me ask myself:
What is the difference between NetMQ and clrzmq?
(Although I'll answer this myself, if anyone else has some experience on the subject - alternative answer is welcome!)
The key difference between the two is in the approach:
CLRZMQ is binding project which actually uses libzmq library in background (it's a .NET wrapper for libzmq library);
NetMQ is .NET-native port of ZeroMQ, meaning that it does not wrap existing libzmq but rewrites it in pure C#.
Which one to use? Well, there's no simple answer. Here are few important things to keep in mind while choosing:
When it comes to portability - NetMQ wins by far, especially due to the fact that there's .NET Core version of NetMQ. Deployment is also easier with NetMQ - there are no native libraries to worry about (x64 / x86, etc.).
On the other side the fact that NetMQ actually rewrites everything is bit scary for me - there's always risk that something is not precisely mirrored from the original code, and that it may cause incompatibility with other ZeroMQ nodes. There's also question how fast NetMQ will implement new features from the original library.
Performances. At the moment I don't know which library wins in performances, but this is definitely thing to consider while choosing. libzmq should be significantly faster than any managed code, but in communication between CLRZMQ and libzmq marshaling has to take place, so I really can't predict which library will win in speed.
UPDATE: Another important advantage of NetMQ is support - You'll get the answer in up to day or two, and sometimes within hours.
UPDATE 2: A problem with poller implementation in NetMQ (described here) turned out to be show-stopper problem for NetMQ in my case. Due to this problem I've migrated my projects to CLRZMQ (I may change my mind down the road...) Nevertheless, talking about poller, there's one problem in CLRZMQ documentation you should be aware of, and it's described here
According to Doron Somech:
http://somdoron.com/2013/03/introducing-netmq/
As of 2014 C# binding (CLRZMQ) is no longer maintained and NetMQ is the default choice for ZeroMQ and .Net.
It seems that:
https://github.com/zeromq/clrzmq4
replaced the original CLRZMQ project.
I'm using NetMQ and looking forward to contribute to the project.
P.S. I build same Pub-Sub scenario for NetMQ and native ZeroMQ and didn't find any performance difference. Great work, Doron!
Related
So as I have asked in a previous post, I want to be able to make programs or functions written in different languages to communicate between them.
I have come across zeromq recently and I'm trying to figure out whether or not this is something that could help me since it provides some sort of sockets. Can zeromq for example exchange data (or pass arguments) between a program written in python with a program or a function written in C++ or is its function for something completely different?
A: Oh Yes, exactly that is the power of ZeroMQ or nanomsg frameworks
Both of these are not sockets but rather BEHAVIOUR created within a context of a Zero-* -- a set of courageous maxims the Scaleable Formal Communication Pattern Framework was designed, developed and finetuned to meet.
That will enable you to assemble your own fast & smart messaging layer(s).
Q: What is the best next step?
In spite of your first impression, simly do forget anything you know about sockets and multithreaded synchronisation tricks.
Yes, rather forget and build your new understanding on "green field".
Take Pieter HINTJENS' book "Code Connected, Volume 1" (accessible in PDF ) and spend a few weeks on understanding both the motivation and the typical errors Pieter has hammered into this must-read bible of ZeroMQ.
Code-snippets are dangerous in case you did not get or completely missed the full-context of the bigger picture.
Believe me. I could not give you better advice. You may check my other posts on ZeroMQ & nanomsg, to see the difference.
You will definitely benefit from this book and ZeroMQ will give you many powers you would never ( and believe me never ) would be ready to program from scratch on your own. The power is so immense ( if well re-used ).
nota bene
For real-world inter-process communications, there is one minor issue to be aware of. Various ZeroMQ versions' inter-operability. Yes, the power of ZeroMQ is immense, nevertheless, it is necessary to keep the version control built in your messaging layer so as to solve situations, where some platforms do not have an update-path to "newer" releases available. Went into this issue with re-integration of a trading system with a component, where as old as zmq.__version__ == 2.1.11 was necessary, while recent are versions well above 14.x.y, so as to be assured to be 100% end-to-end backward-compatible.
Still, the overall potential is so immense, it makes sense to persevere and get the job done. G/L on that.
ZeroMQ is an abstraction of sockets. It is cross platform and have lots of language binding: I personally don't know any language that doesn't have ZeroMQ bindings.
So yes, you can use ZeroMQ to communicate between a program written in Python and program written in C++.
I recommend going through the zguide as it contains a lot of very useful information about ZeroMQ.
PyZMQ can be used as Python binding, and zmqpp for your C++ code. Note that for the C++ code you could also use cppzmq or the zmq C API directly. I would recommend using zmqpp as its higher level and (imho) easier to use.
I've spent the better part of my morning and afternoon playing around with GUI frameworks in Haskell, as I need some visualization and interaction capabilities and I'm not in love with writing my core functionality in Haskell then piping out to a front end written in another GUI; I'd prefer to do it all from one language. The better part of that better part has been spent compiling and patching source code, or Googling obscure compilation errors.
I've spent plenty of time reading SO questions, plenty of time on haskell.org, and plenty of time reading documentation. What I've encountered is a very large swath of outdated or poorly documented information. I can boil it down to these three things:
A glut of options built on top of Gtk+ bindings. I don't care for Gtk+ very much, mostly because I find it to be quite unpleasant to look at, especially on OS X. Griping about the UI looking out of place and/or just plain ugly might seem silly, but that's important to me. Especially if I want other people to utilize any of the programs that I create.
wxHaskell, which is stable and incredibly easy to install but many of the existing tutorials seem to be for wx-0.1x and the conventions for bridging the wxWidgets 2.9.x docs to wx-0.90.x are very very spotty and hard to grok, when they even exist.
qtHaskell, which seems to be mostly abandoned (correct me if I'm wrong), only compiles with newer versions of GHC after applying a year-old patch, and spits out a massive amount of warnings that indicate they will soon become compile errors in newer versions of GHC.
In effect, I'm looking for Haskell's answer to Java's Swing; a library that is robust, maintained, well documented, easy to get started with, makes an attempt to be native in look and feel, can keep up with GHC's development pace, and not at high risk for abandonment. This seems to be exactly zero GUI frameworks, but then it seems that most of the "official" resources/wikis/pages/docs related to GUI frameworks are woefully unmaintained so I decided to turn to the community to see if there was something I just wasn't finding. I'm not terribly worried about the framework being cross platform, just so long as it works on modern versions of OS X.
To reiterate, I'm not really looking for someone to send me a link to haskell.org or the WikiBook. I've been there, and I didn't like what I saw. Most of the information there is just so out of date that it only creates more work, not less.
I realize that my "demands" are a little extreme, especially for a language with a smaller community like Haskell, but I was hoping that someone out there could be of assistance to me. In the mean time, I intend to simply try and ride out wxHaskell or qtHaskell until I succeed or die.
I hope I'm not coming across as gruff or frazzled.
wxHaskell is good, yes, and my go-to GUI middle level library. I admit there's been a focus on updating the code before the docs in the new version.
For modern, functional-reactive-programming fun stuff on top of it I gor for reactive banana, which is actively maintained, and has the added benefit that Heinrich Apfelmus himself may well turn up here to answer your questions.
Threepenny-gui is the most recent contender in the space of Haskell GUI libraries.
Its main selling point is that it is very easy to install, because it uses the web browser as a display. It's also easy to get started with.
On the other hand, it doesn't even attempt to have a native look and feel – the UI is built solely on HTML. (This may change in the future, as we have the option of using XUL). Also, the API is still very much in flux, so be prepared that new major versions of the library are likely to break backwards compatibility. (On the other hand, this means that it's actively developed. :-))
(Disclosure: I'm the author / maintainer of the threepenny-gui package.)
I feel your pain; this answer is an attempt to provide some alternatives that may be good enough and perhaps help you with your search.
First, there is a language called Concurrent Clean. It is supposed to be similar to Haskell, has GUI support and is meant for writing real-world applications. It differs in some respects; for instance, its I/O is based on unique types rather than Monads, which as far as I'm concerned, is a good thing :). Here is a link:
http://wiki.clean.cs.ru.nl/Clean
Next, I dug around for a Haskell compiled to the JVM, in the hopes that it would piggy-back on the Java libraries, ala Clojure. No dice. What I did find was a SO thread discussing the lack and the challenges thereof:
Haskell on JVM?
From that thread however, two other options were brought up. One is Frege:
http://code.google.com/p/frege/
The other is CAL:
https://github.com/levans/Open-Quark
There's also work on functional reactive programming in Haskell. It's supposed to enable things like GUIs, although whether or not you'll actually get a GUI out of it is another matter:
http://www.haskell.org/haskellwiki/Functional_Reactive_Programming
It's sad. Here we have the JVM and .NET and yet zilch for Haskell. It's worse than that; .NET has shown an alarming tendency to ditch promising implementations. Whatever happened to IronScheme, IronLisp and IronHaskell? All dead as far as I can tell.
Not good :(
I'm interested in working with Lucene from a Cocoa application. I'm aware that there are many ways to do this, but my question is, "which way is best?" My investigations so far:
LuceneKit is an Objective-C port of Lucene, but is based on a version of Lucene that is ancient at this point, and in trying to use it, I've run into several major issues from the get go. (Improper subclass of NSDate; A basic query that works in Luke doesn't work with LuceneKit;) It appears to be a non-starter.
CLucene looked like it might be viable, but it fails a bunch of it's own tests on build, including an intermittent concurrency related problem where half the time I run the tests they deadlock. Not inspiring. This still may be the answer, but I'm very nervous considering my experience just building it and running its own tests.
Current Apache Lucene via JNI - Having simply never called a Java library from C, I'm unsure what's involved here. I certainly feel like the official Apache-curated incarnation of Lucene is likely to be the most mature and functional, but having not done the C <-> Java JNI thing before, I'm unclear how the effort involved would compare to working with CLucene.
Maybe there are other options. I'm not necessarily looking for a first-class Objective-C interface (although I wouldn't turn one down, either) just something functional and hopefully reasonably mature and reasonably performant. Anyone have any sage advice?
From my experience using JNI (although, not with Lucene), it's not too tricky to get something simple working, but you can wind up writing a lot of fairly monotonous code wiring everything up.
Another option you may want to consider is JCC, which is used by the PyLucene project to generate a boilerplate C++ wrapping around the JNI itnerface, which they then use to wrap a Python API around.
I’m looking into multithreading, and GCD seems like a much better option than manually writing a solution using pthread.h and pthreads-win32. However, although it looks like libdispatch is either working on, or soon going to be working on, most newer POSIX-compatible systems… I have to ask, what about Windows? What are the chances of libdispatch being ported to Windows? What are the barriers preventing that from happening?
If it came down to it, what would I need to do to preform that portage?
Edit: Some things I already know, to get the discussion started:
We need a blocks-compatible compiler that will compile on Windows, no? Will PLBlocks handle that?
Can we use the LLVM blocks runtime?
Can’t we replace all the pthread.h dependencies in userspace libdispatch with APR calls, for portability? Or, alternatively, use pthreads-win32 I suppose…
Edit 1: I am hearing that this is completely and totally impossible, ever, because libdispatch depends (somehow) on kqueue, which can’t be made available on Windows… does anybody know if this is true?
Take a look at : http://opensource.mlba-team.de/xdispatch/
This project (and other third-party libs) brings libdispatch into platforms(windows, linux) other than macosx
https://github.com/DrPizza/libdispatch
The Windows equivalent of libdispatch, from my basic understanding of it, is the Concurrency Runtime for unmanaged code and a collection of technologies collectively known as Parallel Extensions for managed code. It appears to me that GCD maps pretty well to both of these, since they both abstract work units (or "tasks") in a similar way.
From a bit of research, it appears that there's already a fair bit of interest in a port, but that port would be a fairly drastic undertaking and might end up being basically just another implementation of the API and not actually sharing significant code with the original libdispatch. I did see some proposals to porting libdispatch to being based on the Apache Portable Runtime instead of POSIX which'd make it easier to make it cross-platform to Windows, but even this would not be an easy change.
Likely, this would be by no means a small undertaking.
I think that rather than libdispatch-on-pthreads and pthreads-on-Win32, or libdispatch-on-APR and APR-on-Win32, it might be better to implement libdispatch directly on the Win32 Thread Pool API. The good news is that the two APIs are similar enough that you could probably do the port yourself. The bad news is that there would probably be lots of corner cases where there are small semantic mismatches that make exact behavior hard to achieve.
Is VCL dead, or does it have a future as a GUI library? As CLX ended, is there any chance for cross-platform support in future releases?
I've had to do some work with legacy app that uses Borland's VCL(BCB6). Now that new features have to be implemented, it's necessary to revalue alternatives. Whether to stick with VCL or migrate to some other library/framework.
I've never read much what's happening in the field Embarcadero(Borland) tools. At least there seems to be only few VCL tagged questions here in SO and no much luck with google either.
Whether to continue using VCL in your project, or migrate to an alternative depends alot on your requirements. The VCL framework is powerful and mature, with lots of 3rd party components, which makes it a good idea to consider. The alternatives have been improving rapidly, and to point out one as the ultimate choice really requires you to carefully consider your requirements, and validate the strengths and weaknesses of the different frameworks.
Considering that cross platform is on the road map, I remind you that so has 64 bit support been for quite a while. We might see cross platform support, perhaps on schedule, perhaps delayed as we have seen with many previous features. I want to believe its coming because I truly like the VCL framework, but I always have a natural doubt concerning the official road map of the RAD studio series - sorry David. ;)
If you've researched the different alternatives, and found VCL to be the best choice based on its relevance to your project, then I'd consider using the VCL framework, especially if it is a framework you are familiar with. Learning a new framework can - while often a good idea - be a time consuming job. So even though there might be a risk of the framework not being held alive (as will there be with any alternatives) you might save a lot of work staying with the familiar framework, if it is the framework that suits your project the most.
If you do consider going with C++ Builder and the VCL, you might find that the C++ Builder Journal is a valuable source of information, they have a relatively quite forum, but with some interesting posts in it, and some free hints on their website: www.bcbjournal.com.
Of course there is also the embarcadero forums, and this site, it may be a good idea to search the Delphi forums and categories, since it seems there are more active users on these, and by far more posts. One good thing though, is that conversion from Delphi to C++ in VCL related questions is quite simple.
VCL is undergoing continued development.
Cross platform is on the current roadmap.
The embarcadero forums are still a valuable resource.
As a user of VCL I must say that your observations are truly correct. VCL might appeal to you, but the resources available compared to QT and other toolkits is poor at least esp. at SO. Our team have also found several bugs in their components, and have more than once patched components to make our application stable. Still for me the main reason to migrate is that VCL locks you in with a single set of development tools. I must admit that I have a hard time trying to find any really good reasons to continue to use it if you have the resources to migrate.
Given that bcc32 and its libraries is also very buggy, the lockin gets even more serious, The last months me and my team have spent more time fixing issues caused by the compiler than actually developing features. For me this is such a serious impediment that its cost overweight its benefits tenfold. Unfortunately the costs of migrating for us is so high that we at least for now have to endure its pains.