TL;DR – We built a Wifi-capable four-way mains socket using a NodeMCU ESP8266 development board, some relays, and the Arduino libraries (but not their hardware). We coded it in C++, which you’ll find on GitHub.
I believe I mentioned that I’m back at work on the Curb project. In case you missed that, Curb is a ruby extension that provides bindings to the libcurl library. I started it way back, left to concentrate on other things (having kids, making money, etc) and now I’m involved again, working with Todd Fisher who took over maintaining the project when I bowed out. I’ll be fixing bugs, answering questions and generally helping out.
In the meantime, I’ve also started work on porting (if that’s the right word) Curb to FFI, with a view to moving away from the existing C code. The motivations are manifold:
- As it stands, Curb is pretty much tied to MRI. In the modern Ruby world, where you’ve got JRuby and Rubinius and who-knows-what-next, this is recognised as a bad thing.
- It’s a nightmare to get it working on Windows. This is because, and I can speak with some authority here as someone who develops on Windows every day, Windows sucks for development. Unless you’re using all-Microsoft tooling, in which case it’s pretty awesome. But for interoperability with portable code, and libraries targeted primarily at other platforms, it sucks.
- FFI is probably the right way to do these things these days. 10+ years ago, when Curb was first hacked together in about six hours, C extensions were the shizz. Now, not so much. Unless you really need the level of hardware hackery and performance you can get with C, things are better off in Ruby code.
So to sum up, this port is about future-proofing Curb, making it easier to develop, easier to use cross-platform, and (in the long run) safer, probably more performant, and ensuring it can run on all Rubies, including whatever whizz-bang next-gen thing comes out next week (my bet is it’ll be written in Rust. Or Go. Or something…).
Check it out (or clone it, as the cool kids say nowadays) at https://github.com/roscopeco/curb/tree/ffi.
As I mentioned in my previous post, I’m now working on Curb again, and currently on Windows. Back in 2006 when I wrote the original Curb, I wouldn’t go near a Windows box for religious reasons, and the project has never officially supported the platform. There are plenty of bugs and posts around about people having mixed success with getting it to work.
Since then, my views have mellowed, partly I think because I’ve come to appreciate that there’s no room for religion in software engineering – you use the right tool for the job. Partly that, and partly by my desire to, you know, get paid and own stuff and whatnot. These days I do as much work on Windows as I do on *nix, and my bank balance is all the better for it. So anyway, back to the point of this post.
Building Curb on Windows is a bit of a nightmare. It took me a fair while to figure it out, and I wrote the damn thing. If it got me feeling like the guy in the picture above, then how must the everyday user trying to get the gem going feel? If they’re just trying to install it and write some code, I’m guessing they immediately give up and go with another library. But what if they are trying to use something else that depends on the Curb gem? I’m guessing that’s when they get so frustrated they file shouty bug reports with the project. And I don’t blame them. It would have been nice to have someone to shout at while I was trying to get it working.
In the end, I did get it going, but it required me to build libcurl from source. I posted an answer to the bug report I mentioned above with the how-to of it, and the poor person who filed it reported back that it worked. You could click through, but I’ll reproduce the steps below to save your finger.
Most likely, your compiled libcurl is incompatible with the ruby devkit compiler. You can verify this by running (this is on my machine, obviously change your paths):
> c:\Ruby200Devkit\mingw\bin\gcc.exe -L. -lcurl # c:/[...]/ld.exe: skipping incompatible ./libcurl.dll when searching for -lcurl # c:/[...]/ld.exe: skipping incompatible ./libcurl.dll when searching for -lcurl # c:/[...]/bin/ld.exe: cannot find -lcurl # collect2.exe: error: ld returned 1 exit status
Notice the lines about “Skipping incompatible” before the final “cannot find lcurl”. Try grabbing the curl source from https://curl.haxx.se/download/curl-7.54.0.tar.gz , extract it somewhere, and then open up a terminal and try the following:
> c:\path-to-your-ruby-devkit\devkitvars.sh > which gcc # important - verify here that the gcc is the one from your ruby devkit! > cd > sh configure --with-winssl # and whatever other options you require > make > make install
It’s very important that you don’t have any other mingw/msys/cygwin compilers in your path, and that you do this in a windows terminal, not msys/cygwin sh. Otherwise, you’ll probably just build another incompatible library.
You should now have
c:\path-to-your-ruby-devkit\local\bin. Now it gets a bit messy, so hang in there. This part is probably a bug in the build, but easy to work around.
> cd c:\path-to-your-ruby-devkit\local\bin > copy libcurl-4.dll libcurl.dll
The build needs
libcurl.dll (it won’t compile with
libcurl-4.dll, but the extension won’t run without the -4 suffix, so we’ll have to manually copy the dll later on).
> gem install curb -- --with-curl-lib=c:\path-to-your-ruby-devkit\local\bin --with-curl-include=c:\path-to-your-ruby-devkit\local\include
Assuming the build goes well (it should, though it might take a while), you now just need to copy the curl dll to the appropriate place:
> copy c:\path-to-your-ruby-devkit\local\bin\libcurl-4.dll C:\Ruby22-x64\lib\ruby\gems\2.2.0\gems\curb-0.9.3\ext
irb -rcurl and, all being well, you should be good to go.