A C implementation of the minimal subset of Vanadium (vanadium.github.io) needed to send RPCs
C Go C++ CMake
Permalink
Failed to load latest commit information.
mvrpc
.gitignore
.travis.yml
AUTHORS
CMakeLists.txt
CONTRIBUTORS
LICENSE
README.md
buf.c
buf.h
connection.c
connection.go
connection.h
connection_test.go
endpoint.c
endpoint.go
endpoint.h
endpoint_test.go
err.c
framer.c
framer.go
framer.h
framer_test.go
message.c
message.go
message.h
message_test.go
miniv.h
signature.c
signature.h
teststruct.c
teststruct.h
util.go
v23.h
v23_uniqueid.c
v23_uniqueid.h
vom.c
vom.go
vom.h
vom_test.go

README.md

miniv

An experimental implementation of the minimal part of Vanadium necessary to do an RPC in C.

The target systems are those that are too small to run Go, but big enough to run C and a networking stack.

Build Status

Status: Unfinished and likely to not get finished

On hiatus. At this point, the proof of concept for how the vdl tool should generate the C is done, but I've lost interest in this due to some other stuff I need to do. This has been and interesting experiment but it is unlikely to get finished anytime soon. If you are reading this and interested in moving it forward, feel free to get in touch and I'll show you the first draft of the vdl tool changes.

Go and cgo

If the goal of this project is to write a tiny Vanadium in C, why are there *.go and *_test.go files? Why is there cgo?

Good question.

Imagine you are a Go programmer. You like to write the least C possible, because you prefer Go. Writing C is hard. Writing even more C just to test the first C is maybe not hard, but certainly annoying.

Enter cgo. If you write your C code like you plan for it to be used indpendently of Go, but you test it via cgo, you get to write only the implementation in C, and all your tests in Go.

And if you happened to have a copy of the official v.io Go code in your GOPATH, then you could even do something really snazzy: You can use the reference implementation to validate your new implementation. For an example, see message_test.go where we use v.io/v23/flow/message to serialize a message, and then we use our new implementation in C to deserialize it.

As a general rule, *.[ch] are the C implementation. *.go are the test files, and nothing you see in them is production code for the targeted environment.

The current testing environment is MacOS.

Building without Go

During normal development, the C is built with "go test".

To use the library outside of the Go/cgo test environment, build it with CMake:

$ mkdir obj
$ cd obj
$ cmake .. && make
$ ls -l libminiv.a mvrpc/mvrpc 
    -rwxr-xr-x  1 jra  staff  14296 Feb  6 11:30 mvrpc/mvrpc
-rw-r--r--  1 jra  staff  5016  Feb  4 23:52 libminiv.a

A bit smaller than the Go Vanadium!

C++?

It is 2016. This is a new all C library. What are you smoking?

I'm even worse at C++ than C. That's why I program Go.

But even if I was a C++ hacker, there are lots of embedded systems that are not ready for C++. This Vanadium implementation is targeted to them, so it is in C99.