chore: bump miso pin

[dhess]

Miso's API continues to be unstable, so there are some functional changes, though Primer's implementation remains unchanged.

[dhess]

@georgefst This builds, but it doesn't actually work. Do you have a moment to take a look at these issues?

• In native mode, make develop-frontend starts the server, but in the browser console, we get a connection error over ws://localhost:8001/. I don't know enough about debugOr to know where to start.
• In Wasm mode, make -f Makefile.wasm32 serve-frontend starts the server, but in the browser console, there's an unhandled JavaScript exception. This one I was able to trace to your state reloading wrapper: if I hack startComponentWithSavedState to set the reloaded state to Nothing, then (after force-reloading the page a few times in the browser) I can get the UI to come up, so something appears to be broken in the state/state reloading. I'm also not sure why the exception handler in startComponentWithSavedState doesn't nicely handle this with a console log error rather than the JavaScript exception that gets surfaced.

[dhess]

Perhaps I should look at georgefst/hello-hs#2 and sync up with that. It'd be nice if Primer's Wasm bits looked more like other canonical Miso apps.

[georgefst]

It'd be nice if Primer's Wasm bits looked more like other canonical Miso apps.

I think both descend from the original Tweag Miso example repo. I'd be surprised if there were major differences.

EDIT: Well actually, maybe it is worth syncing up on some of those minor differences, e.g. the CPP around Wasm GHCI browser mode.

[georgefst]

In native mode, make develop-frontend starts the server, but in the browser console, we get a connection error over ws://localhost:8001/. I don't know enough about debugOr to know where to start.

Miso recently dropped JSaddle entirely (resulting in significant performance improvements for one thing). That means debugOr is no longer going to work at all, and we need to embrace #1404.

In Wasm mode, make -f Makefile.wasm32 serve-frontend starts the server, but in the browser console, there's an unhandled JavaScript exception. This one I was able to trace to your state reloading wrapper: if I hack startComponentWithSavedState to set the reloaded state to Nothing, then (after force-reloading the page a few times in the browser) I can get the UI to come up, so something appears to be broken in the state/state reloading.

I think I got this working in this experimental branch. But anyway the recommended approach going forward for hot-reloading is likely to be persisting the model via a pointer on the heap which survives GHCI reloads. See the discussion here. This has the advantages of better performance and not needing ToJSON/FromJSON instances. Downside is that it won't save Primer programs across sessions. But we could do that more manually instead, and obviously it's not what we want in the long run anyway.

[dhess]

OK, I'll take a look at your various branches/PRs and try to reconcile this PR.