m3 issueshttps://dgit.cs.uni-saarland.de/pseuco/m3/-/issues2021-12-06T12:50:21+01:00https://dgit.cs.uni-saarland.de/pseuco/m3/-/issues/30More verbose crashes2021-12-06T12:50:21+01:00Dominic ZimmerMore verbose crashesThere are several instances, where one can get the `m3` server to crash or not reply to the user at all. I don't mind the crashes too much — since they are mostly caused by inproper usage — but reporting to the user that something went w...There are several instances, where one can get the `m3` server to crash or not reply to the user at all. I don't mind the crashes too much — since they are mostly caused by inproper usage — but reporting to the user that something went wrong (and what went wrong) seems crucial to me.
My aim with this issue is to polish up 80% of the outstanding problems with about 20% work. I don't mind getting my fingers dirty myself, either. If you have some specific pointers for me, where to poke, I'll be happy to hear @fkosmale! If fixing these issues seems like to much work, I'd be absolutely happy with a wits-end error message saying `The m3 server worker crashed. Are you sure you are running tinyPseuco code?`.
Currently I am observing these issues:
- [ ] asserting writeValueSet to some program initialization throws `writeValueSet` is not supported, though I thought it was...? ![image](/uploads/b3a1e5530c9d625e20c12bf444b49b66/image.png). As a consequence, the UI gets thrown in a very odd state where said assertion can not be interacted with anymore.
- [ ] providing certain illegal tinyPseuco instructions, such as declarations as `string z = "";`, appear to pass the parser, but don't report back to the server, as the Future throws an exception that is not caught. I'd prefer to catch these kinds of exceptions and report to the user that (something, eg.) parsing went wrong.https://dgit.cs.uni-saarland.de/pseuco/m3/-/issues/22Minimal in-dialog help2021-12-06T12:48:23+01:00Felix FreibergerMinimal in-dialog helpI think we should add a small help section (consider it a legend) to the aside, hidden behind a `<details>` toggle, that explains what the colors of arrows mean, and what _OOTR_ means.I think we should add a small help section (consider it a legend) to the aside, hidden behind a `<details>` toggle, that explains what the colors of arrows mean, and what _OOTR_ means.https://dgit.cs.uni-saarland.de/pseuco/m3/-/issues/20Show incomplete order constraints2019-03-27T14:46:17+01:00Felix FreibergerShow incomplete order constraintsAfter the start node of an order arrow has been clicked, it would be nice to show an arrow starting at that node, with the end following the mouse pointer, so the user can see the order arrow he's drawing. The same is true for write-seen...After the start node of an order arrow has been clicked, it would be nice to show an arrow starting at that node, with the end following the mouse pointer, so the user can see the order arrow he's drawing. The same is true for write-seen arrows.Fabian KosmaleFabian Kosmalehttps://dgit.cs.uni-saarland.de/pseuco/m3/-/issues/15Indicate name of local variable for reads2019-03-27T19:29:14+01:00Felix FreibergerIndicate name of local variable for readsCurrently, nodes in concrete execution graphs can have labels like this:
1. `x?0`
2. `y = $0`
3. `println($1)`
This is a bit inconsistent. :one: uses the exact notation from the lecture, and reveals the actual value. :two: and :thre...Currently, nodes in concrete execution graphs can have labels like this:
1. `x?0`
2. `y = $0`
3. `println($1)`
This is a bit inconsistent. :one: uses the exact notation from the lecture, and reveals the actual value. :two: and :three: use a different notation (which is strictly necessary for :three:) which reveal the names of (temporary) local variables, but do not show the actual value.
I suggest we switch everything over to a notation that shows the actual value:
1. `x?0`
2. `y!0`
3. `println(0)`
If this is not clear enough, the name of the local variable could always be added in gray:
1. `x?0 [r]`
2. `y!0 [$0]`
3. `println(0) [$1]`Fabian KosmaleFabian Kosmalehttps://dgit.cs.uni-saarland.de/pseuco/m3/-/issues/13Zooming inhibits scrolling2021-02-05T12:48:23+01:00Felix FreibergerZooming inhibits scrollingIt's too easy to zoom a graph instead of scrolling. Maybe we should have a toggle for this feature, or use zoom buttons instead.It's too easy to zoom a graph instead of scrolling. Maybe we should have a toggle for this feature, or use zoom buttons instead.https://dgit.cs.uni-saarland.de/pseuco/m3/-/issues/1Parser/Compiler should local variable assignment into SSA form2018-05-20T12:54:58+02:00Fabian KosmaleParser/Compiler should local variable assignment into SSA formThe transformation from TinyPseuCo requires that each variable is only assigned once. Instead of pushing this constraint to the user, we can handle this during the parse/compile stage.
This also enables setting local variables to differ...The transformation from TinyPseuCo requires that each variable is only assigned once. Instead of pushing this constraint to the user, we can handle this during the parse/compile stage.
This also enables setting local variables to different values in the branches of an if-then-else expression, which is currently impossible.