Brian Palmer

Good info thanks. They watch for `close_write`, which according to http://linux.die.net/man/1/inotifywait means "A watched file or a file within a watched directory was closed, after being opened in writeable mode....

I've got a [WIP branch](https://github.com/codekitchen/fsevents_to_vm/tree/write-events) that simulates WRITE_CLOSE events, which appears to be enough to fix this issue. However, it doesn't look like that's good enough for the inotify.go library...

Hmm this doesn't really seem like a general solution to me. What happens when somebody tries to use a .proto message that contains field named message_fields? That said, I don't...

I'm leaning towards putting everything in a non-conflicting namespace, but retaining the current methods on `Message` as aliases to that namespace, for backwards compatibility. However, we'd change precedence. For example...

This looks like mostly likely a bug in this library -- there is an internal data structure on each Message called `@set_fields` which looks like it is somehow not getting...

Ah actually I tracked it down but it's not what I stated above. The `DNSRR` message has a field defined as `optional uint32 class = 3;`, which ends up overriding...

Thinking about it more, `Message` is really a value type and we should treat it as such, so we should allow methods like `.class` to be defined without mangling them....

haha, totally understand

Hi! I'm glad this project is still useful for you. I honestly haven't used it in a few years myself. This error is probably related to all the go module...

It'll have to be manual testing I'm afraid. I am getting a segfault in join-networks.go with the new image, I haven't dug into why yet. Do you see the same?