Skip to content

Conversation

@rmoehn
Copy link
Contributor

@rmoehn rmoehn commented Aug 13, 2018

For exercising Patchwork with random inputs.

Note that this branch is based on fix-context-eq, which is still a PR.

rmoehn added 3 commits August 8, 2018 08:56
I must have accidentally added it at some point. Remove it, because it
is inconsistent with the rest of the file.
Context.__eq__ was based on the string representation (str-rep) of the
context. This makes sense for the memoizer, which should consider two
contexts the same when they have the same str-rep, because it imitates H
and H only ever sees the str-rep of contexts.

However, this str-rep-based equality throws off other algorithms. See
the test case that I added to test_basic. There we have two contexts
with the same str-rep but different workspaces. Call them C1 and C2.
sched.resolve_action adds both of them to sched.pending_contexts, such
that:

    sched.pending_contexts = deque([C2, C1])

After the Reply("$a1 $a2"), sched.choose_context determines:

    choice = C1

Then it does sched.pending_contexts.remove(C1). However,

    str(C1) == str(C2) → C1 == C2,

so what gets removed from sched.pending_contexts is C2; C1 remains. This
is wrong and leads to failure shortly after.

Fix this by making Context.__eq__ based on a context's workspace_link,
unlocked_locations and parent. I chose these three attributes, because
every context can be constructed from them.

This should work in the general case, but it breaks the memoizer. So
change the memoizer to explicitly stringify contexts before doing
anything with them.

Implemenation notes:

- Change Context.__eq__ to return NotImplemented when `other` is not a
  Context, because that's what the Python docs recommend:
  https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy

- Leave Context.__hash__ as it is, because hash(c1) == hash(c2) is
  allowed to happen occasionally. Also, `hash` has to be fast, so it
  makes sense to use the str-rep, which is already stored in the
  context.

- The `str` calls inside Memoizer are repetitive, but I think it would
  be overkill to implement an abstraction.
For exercising Patchwork with random inputs.

Implementation notes:

- I don't know if the code involving threading is correct.

- Leave many TODOs, because doing them would good, but isn't crucial for
  the random test to be useful.

- Some identifiers have a trailing underscore (hypothesis_) in order to
  avoid shadowing global variables.

- One might think that starting a thread for every act() is slow, but on
  my machine, which is old, it increases the running time of the random
  test by only a few seconds (7 s → 8-12 s).

- Someone in https://stackoverflow.com/questions/2829329/ advises to
  catch BaseException (instead of Exception) and re-raise in
  (Terminable)Thread.join. Don't do that, because a SystemExit in a
  child thread shouldn't terminate the parent, in my opinion.

- Custom exception types are good. Cf.
  https://www.youtube.com/watch?v=wf-BqAjZb8M.
@stuhlmueller
Copy link
Member

Make a new PR that only contains the latest commit? Not sure what went wrong, but now that the other PR is merged into master, the diff should only show the new changes.

@rmoehn
Copy link
Contributor Author

rmoehn commented Aug 21, 2018

Done: #19

Apparently GitHub didn't make a fast-forward when merging the other PR. So master ended up with a merge commit at the end, not 2136b02 and 44eff84. That's why they had to stay in the diff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants