Patricio Whittingslow

I'm not sure I understand how `//go:generate` would work. Would the assembly be in a separate file? I personally like `pio.Asm` since the assembly is inside the code and easier...

I'll be watching from the sidelines since most of this exceeds my knowledge on the subject. I'll leave one idea on the drawing board: * It would be nice if...

Flaky test? ``` === RUN TestDsaturExact coloring_test.go:504: test ran too long for "sudoku problem" coloring_test.go:477: we ran out of time by "cs_shc" coloring_test.go:477: we ran out of time by "gis_hc"...

I've tested permute and scaling with Dggbal's results but the way I'm getting there is ridiculous. I fiddle about with the matrix multiplies until the tests pass, then I understand...

I'm not quite agreeing with the abstraction. I'd suggest a I2C factory pattern for each port. Here's what I'd consider an ideal API: ```go type Device struct {...} type Port...

sure! Here's what I've got in mind! ```go onChipI2C := machine.I2C0 // pca9548.Addr would also come handy as a package level function! mux := pca9548.New(onChipI2C, pca9548.Addr(false, true, true)) // Here's...

@conejoninja > the only way I managed to see it working, is that if in func (Port) Tx(addr uint16, w, r []byte) (err error) the port is set/enabled each time...

> I was looking at net.Interface type. It's something that is not implemented with the current TinyGo's "net" package, but I'd like to port it over. It provides a lot...

I've removed several sentinel errors which had not fully convinced me of their usefulness. In any case we can always add them back in the future, but once added they...

@deadprogram yes, the idea is to start using these abstractions once merged to get a better idea of issues with them if any. I'd go easy and replace them one...