Nigel Brooke

I think that extract function is just too general in it's type signature. It'll run on ANY type, but basically only safely functions on things that are integer-like primitives or...

That could also extend reasonably well to supporting a few more complicated types, if we had: ``` extension Data { public func extract(start: Int, length: Int) throws -> T {...

`value` being an object might not work (or at least, not work by itself). The fields are going to be order dependant (except in the trivial case of only one...

Transplanting comment by @larryonoff from #91 that is more appropriate here: > I didn't mean using Codable 1-by-1. I meant implementing something similar like Encoder / Decoder. > Codable doesn't...

I'm not sure that with the Encode/Decoder system is a significant win over what that implementation would be with Bluejay right now using the existing Data category for extraction (though...

It's usually in order, but it's occasionally not tightly packed, so there has to be some way to represent gaps in the data, which specifying start does allow (though there...

Using the newer peripheral does seem like a totally reasonable change, even if it doesn't actually fix this. From.a quick glance at the referenced threads, it looks like there also...

Filed #527 to just disable it for now (since it being disabled is probably better then the current behaviour), and then we can do a good version of it later....

Probably we should do height positioning at the same time, if you can do one you are probably going to want to do the other to get a reasonable view.

I believe that we have now disabled all the places that you could leave a node selected and run a transition. It'd be nice to fix this so that we...