Use LCMCore to provide the LCM interface

[rdeits]

LCMCore.jl can now provide all of the interaction we need with the LCM C API. This means:

• better performance
• handle() is now magically safe for @async usage
• almost no code is left inside PyLCM

[rdeits]

Ok, this seems to be working. It will have to wait until LCMCore is registered, though.

[codecov-io]

Current coverage is 100% (diff: 100%)

Merging #14 into master will not change coverage

@@           master   #14   diff @@
===================================
  Files           1     1          
  Lines          11     8     -3   
  Methods         0     0          
  Messages        0     0          
  Branches        0     0          
===================================
- Hits           11     8     -3   
  Misses          0     0          
  Partials        0     0          

Powered by Codecov. Last update e9aa77b...adc1b5e

[tkelman]

no appveyor, huh?

[rdeits]

I'll see if I can get it working: JuliaRobotics/LCMCore.jl#2

[rdeits]

@tkelman while you're here, can I ask, is the BinDeps.BuildProcess provider not supported on Windows? The LCM project doesn't provide any binaries, so I have to build it myself. It's all pretty portable cmake, so it should work, but BinDeps seems not to be able to use my build process:

On appveyor, BinDeps.debug gives:

- Library "glib"
    - Providers:
      - WinRPM.RPM package libglib-2_0-0
      - BinDeps.Yum package glib (can't provide)
 - Library "lcm"
    - Providers:
      - Simple Build Process

but actually running the build fails with:

LoadError: None of the selected providers can install dependency lcm.

I'm guessing this is because https://github.com/JuliaLang/BinDeps.jl/blob/master/src/dependencies.jl#L616 doesn't include BuildProcess in the defaults list on windows. Is that the expected result?

[tkelman]

It's not in the default list because the vast majority of windows users aren't going to have developer tools (compiler, cmake, etc) installed. It's recommended for usability's sake that you build binaries, upload them to something like github releases, and have your package download them at install time for windows users.

You can temporarily push! things to the BinDeps default providers list as long as you're sure to restore it back to what it originally was when you're done.

[rdeits]

Ok. I agree that that's the most usable thing for windows, but I don't have the bandwidth to do it. I'll do the defaults modification and restoration.

[rdeits]

Hm, this is harder than anticipated. LCM requires glib, which WinRPM.jl provides, but not in a form that the LCM build will use (presumably because it doesn't supply the headers). I could build glib from source, but it uses autotools and setting that up is a whole other process.

It's probably easier to just switch to ZCM instead https://github.com/ZeroCM/zcm which doesn't use glib than to fix the glib build on windows. But that's not going to happen right away.

[tkelman]

Are you installing the glib-devel package? Building things for windows is generally complicated and kind of a pain, yeah. You could set up cross-compilation on the opensuse build service and point WinRPM to your personal project, but that's maybe not worth doing if you plan on switching to a different library before putting in the effort to support Windows.

[rdeits]

Ah, I didn't see the glib-dev package. I'll give that a shot. Searching for libglib didn't bring it up, so I assumed it wasn't available.

But yes, agreed on all counts. This probably just isn't worth the effort yet, given that I have roughly two users, one of whom is me and neither of whom is on Windows. I would like to eventually solve this, even if it means moving to ZCM to drop the glib dependency.