Example/useownserialization

[dehann]

We put together this example a while back and wondering if you wanted to add it to the registered LCMCore repo. There might be some confusion for people who do not know LCM. Let me know if you have any ideas to change or improve this?

PS, I mistakenly committed the original example file to dehann/LCMCore.jl:master and decided fix it by just deleting the file and re-adding it through a new branch was easiest.

[rdeits]

Yes, I'd definitely be happy to include this, thank you!

Ideally, I'd like to unify this as much as possible with @tkoolen's generic LCMType type, but that doesn't have to happen right now.

Could you just add this to the runtests.jl file so that we can ensure it keeps working going forward?

[codecov-io]

Codecov Report

Merging #22 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #22   +/-   ##
=======================================
  Coverage   79.35%   79.35%           
=======================================
  Files           2        2           
  Lines         155      155           
=======================================
  Hits          123      123           
  Misses         32       32

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ace8e39...8c35626. Read the comment docs.

[dehann]

Sure,will do -- might take a couple of days to bubble up on the queue my side. Thanks, test is definitely the right way to go!

[dehann]

Oh, and on @tkoolen's LCM Type stuff (which is really cool btw):

I was looking at this it the other day and had been trying something similar. I was trying to use Clang.jl to automatically wrap the C code from lcm-gen --c --cpath + compile to .so, although I ran into several unexpected issues and put that on hold. I came to the conclusion there were 3 options:

• LCMCore is able to replicate lcm-gen and make up the carbon copy encode / decode functions,
• We PR lcm-gen to add Julia support to LCM itself, or
• Use ccall to assumed encode and decode functions from lcm-gen --c --cpath + compile to .so, and replicate only the lcmtype generation in native Julia.

It looked like Twan was going down the 'carbon copy' from native Julia path?

Another thought which comes from a project I'm working on: encode/decode is in many ways similar to convert(::Type{Vector{UInt8}}, ::MyType) and convert(::Type{MyType}, ::Vector{UInt8}). See example for out-of-module, multiple-dispatch encoding and decoding which uses multiple convert methods instead. Not sure how you feel about something like that for LCMCore -- better to get native type support first and then worry about compactness.

[tkoolen]

Howdy Dehann.

We PR lcm-gen to add Julia support to LCM itself

Are you aware of ZeroCM/zcm#163?

convert(::Type{Vector{UInt8}}, ::MyType) and convert(::Type{MyType}, ::Vector{UInt8})

I feel the problem with that is that that necessarily creates new byte vectors and new MyType instances, causing allocation and less-than-ideal performance. The current decode! and encode(io::IO, x::LCMType) methods allow you to do everything in place and thus avoid those allocations.

[dehann]

Hi Twan,

Did see zcm yes, but didn't look too deep. They are using zmq for transport but LCM for serialization. Yeah good point, I agree convert would waste memory. I kinda wish Julia would also use convert!(::B, ::A).

I like all the in place stuff btw and your LCMType stuff. I could maybe help out with the autogeneration of the LCMType code from an .lcm definition since I have some of that code lying around.

[tkoolen]

I could maybe help out with the autogeneration of the LCMType code from an .lcm definition

Sounds good. @rdeits at some point suggested starting off by making a string macro that creates the LCMType and calls @lcmtypesetup given a definition in .lcm format. Then actually reading the .lcm file would be just a tiny additional step. But now I'm not sure if that approach will work because it seems you can only use string macros for literals: https://docs.julialang.org/en/stable/manual/metaprogramming/#Non-Standard-String-Literals-1.

[rdeits]

Yeah, my point w.r.t the string macro is that once you've written a function that takes an LCM definition as string and spits out a Julia type definition, then you can use that to read .lcm files or as a string macro for people who want to just dump the text of a .lcm message definition into their Julia code, as in:

const my_t = lcmtype"""
struct my_t {
  int x;
}
"""

[dehann]

we should probably close this PR in favor of the LCMType plumbing as @tkoolen suggested?