We already reject style, we should also reject warnings.

https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deny-warnings.md

3cf0c9a modified the create_dimensions_failure_overlap test so that it fails. The double creation should error, not crash the planner.

In the process isolation tests, although multiple processes are able to be created, only one of them actually adds a droplet to the chip when run in parallel. Failing test can be seen in PR #24

Collisions between droplets of the same collision group should actually perform a mix. This will likely require a reroute.

Something is wrong with the dimensions code.
Tests mix_dimensions_size and mix_larger_droplets are ignored right now.

The placer uses graph isomorphism to place commands right now. This nicely handles rotations and symmetries but will "bend" graphs without enough structure.

Example:
The Split command uses a path graph as its shape. This is intended to be a straight line, but isomorphism will happily bend it. I think simple.py actually exhibits this behavior.

We could first try a very simple placer that just tries to stamp out a module and every possible location. It would be nice, however, to still handle rotations and symmetries. That also might entail a more global transition from graph to grid data structures for boards and commands.

Collision group logic is very messy, needlessly complicating all sorts of things.

It introduces unnecessary mutability:

It also just makes the routing waaaay more complicated (and probably) buggy. We could fix this by having some cleaner (non-mutating) way of asking the router to allow things to collide. This would also be cleaner because we will actually know when the mix occurs, allowing us to update the droplet.

Currently, running error experiments on the frontends exhibits weird behavior because the core only supports perfect (volume/2) splits.

It should be possible to specify the error profile of an entire session (or perhaps individual split calls) in the frontends, and have the Core exhibit that behavior.

Example: I want the split error factor to be drawn from N(1, 0.01). When I go to split a 1 volume droplet, and draw 1.2 as the error factor, both the frontend and backend should now see a droplet with volume=0.6 and a droplet with volume=0.4 (see https://github.com/michalpiszczek/puddle/blob/error/src/python/examples/error_dilution.py for the frontend behavior).

Notes:

• One quick way to do this is having expected volumes be a parameter on split calls, and the Core will simply assume those passed values are correct and assign them to the resulting droplets.
• Gaussian error should be sufficient.
• Perhaps we should simulate error for input() as well.

As of 1242094, the dilution example fails non-deterministically. We should reduce non-determinism by using seeded HashMaps

https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.with_hasher

We need to add error detection.

I think that error detection will look something like a "diff" function between the Executor's state and the sensor data from the real worlds. The real world data will be anonymous blobs, meaning that it won't be associated with droplet ids. So the comparison should involve some kind of matching function between the real data and the expected data.

For now, I don't expect that we'll be able to generate a matching for "catastrophic" error cases, things like accidental mixes and splits.

TODO:

• Create test cases for matching
  • identical droplets and blobs should produce an error-free matching
  • close but correctable should generate a matching that we could use for error correction
  • catastrophically wrong (mixes and splits) dont need to work for now
• Implement and individually test a scoring function between droplets and blobs
• Implement the matching function so that it passes the test cases

Right now, move is a strict command that forces a flush. I've written a xfail test for that, as I'm not totally sure that's the right behavior.

One reason that makes sense is that the a droplet's location is going to change only when it's actually moved. That makes movement hard to defer. They tricky part is here is all commands involve movement! So I think we have a couple options:

1. "invalidate" those properties like location when the user shouldn't be looking at them
2. only expose DropletShims to the users, that way we never have to worry about them poking around.

I think I'm leaning towards 2.

Also, looking into this raised another validation question. Droplets cannot be used more than once, this is tracked by the valid flag. Right now, we don't check this in many places (I'll fix that myself on master here #10). So just leave this for now and I'll fix after this is merged.

Expand the data model of the droplets to account for droplets that occupy multiple locations on the board.

In the python simple.py example, some droplets move when it's not necessary. They could instead just stay stationary.

A diagram or something would be nice.

Right now (as of d74a3ca), the visualizer doesn't work at all. It should:

• be fixed to at least show something
• support volume
• have rudimentary support for shape

We can mostly ignore shape in the visualizer because large droplets never get made, but the support should be there.

Right now, routing is "dumb" and will intersect other droplets.

However, making it just avoid all droplets is also not great, because that's unnecessary for mixing (the mix could occur "on the way" to the mix location). This same intelligence is missing for placement too.

Placement requires way too much space between droplets. We should fix this or figure out why it's that way.

Once we have error detection (#32), we need to start actually correcting them.

There are several flaws with how mix plans the combination of droplets.

mix_dimensions_too_large_to_combine tests that it doesn't combine droplets in
an obvious "wrong" direction, leading to shapes that don't fit on the board
(23796a4).

Droplets can only be consumed once. We should crash the program if it's going to be used again. See test here for an example test: https://github.com/mwillsey/puddle/blob/c876326b4568c61152cf0540977c19c75b911b6f/tests/test_execution.py#L139

This is a bug right now, because we (nominally) support large droplets, but the commands that manipulate them don't request enough space to safely contain them.

Consider Mix, which requests 3x2 space. What if the input droplet is 3x3?