KalkulierbaR/kalkulierbar

Starting a Propositional DPLL calculus breaks the app

Closed this issue · 11 comments

JuliusHenke commented

This error only occurs on branch ghlink and not on master.

Reproduce Error:

  • Start proof with valid formula a at http://0.0.0.0:8080/dpll
  • Backend Response (no error):
    {"clauseSet":{"clauses":[{"atoms":[{"lit":"a","negated":false}]}]},"tree":[{"parent":null,"type":"ROOT","label":"true","diff":{"type":"cd-identity"},"children":[],"modelVerified":null}],"seal":"6FB3B78EBAD2D458467246515AE954AF73B3D395ED96968F7B270A0F9CD997D6"}
  • Frontend Error:
    Uncaught (in promise) Error: Objects are not valid as a child. Encountered an object with the keys {}.
  • App is unusable at this point until the user reloads
rec0de commented

@DerDrodt thoughts?

DerDrodt commented

Sounds like one of the dependency updates' responsible. I would assume the cli or one of its extensions (e.g., sass).

Does anyone know what file/line is responsible? I can check it out later

DerDrodt commented

Alright. It's an error in preact (or at least found by preact). Somewhere we have a child that is an object rather than vnode/string/...

Preact doesn't like that. I may be able to find the cause tomorrow (it will take time), but if you have the time, you could also investigate.

rec0de commented

Hmm, weird that a version change in some dependency would trigger that.

Also I just noticed that the formula input and format explainer stay visible when the bug is triggered (but are scrolled out of view by default) - maybe that helps to narrow it down? The js console output isn't too helpful...

DerDrodt commented

I was able to isolate the error: In the DPLL view if the split dialog or the model input are rendered, the error occurs. Will keep you posted

DerDrodt commented

The cause is the getAllLits function in util/dpll. It doesn't return an array of strings, but an array containing the Set. I don't know why. My guess would be an error in the transpiler.

Anyway, I fixed it

DerDrodt commented

Although, @rec0de @JuliusHenke: It would be necessary to check whether we use [...set] anywhere else. I don't remember any instance, but that would be bad

JuliusHenke commented

image
We do use that syntax a few more times. But these cases are not converting a Set to an array. So it should not be a problem, if that was the root of the bug.

DerDrodt commented

I think that was the bug, yes

rec0de commented

Yep, I checked all uses of ... in general, they all seem fine.

Is setCandidateClauses([...candidateClauses]); just shorthand to create a deep copy?

DerDrodt commented

Yep, that's a copy