unison

mirror of https://github.com/unisonweb/unison.git synced 2024-11-22 01:22:47 +03:00

Table of Contents

Aug 21, 2019
Aug 14, 2019

Aug 21, 2019

Mitchell and Elliot have made amazing progress on the codebase browser. It's written in Elm (see last week's discussion). I was really blown away! Mitchell gave a demo of what's there so far:

There's a rudimentary display of the namespace tree, with lazy loading of children and predecessors in history. This entailed a bunch of writing decoders in Elm, which was a bit tedious but straightforward.
Still todo: term and type declaration rendering.

My summary: basically all the information of the codebase format is being loaded successfully by the browser, so it's "just" a simple matter of coming up with a nice presentation of this information and exposing the interactions we want.

Some things we discussed:

We did some whiteboarding to think about different UI possibilities for showing the namespace tree, which is this interesting structure which has history at every sub-namespace. Summary: this is an interesting UI design problem that could use some thought. We also need some sort of design for the codebase browser UX generally. Mitchell will continue filling things in (like term and type printers), but might be blocked on this somewhat soon.
Also: codebase browser needs beautification at some point.
We talked about pretty-printing and I showed how the current Haskell pretty-printer works. Mitchell suggested punting on doing any width-aware rendering for now in favor of Elm code-formatting type approach. Seems okay for now and probably easy enough to change later.
An important use case is having the codebase browser be able to read a local filesystem repo. JS doesn't have access to arbitrary local files, so you'll need to run a file server locally for your .unison directory. Eventually, we will probably roll this server into ucm and can start adding more capabilities to it, basically bringing us closer to what Ian was interested in working on. For now, any ol' web server will do, it just needs to be able to be able to serve up the files in .unison.

Aug 14, 2019

We had an informal get together last night for folks in Boston area interested in working on Unison. This was our first meeting. It was cool!

Notes from the meeting:

It would be awesome if Unison had a "codebase browser". We have this nice codebase model, but the only way of getting information out of this model is via the command line tool, ucm. Although we are putting some love and care into ucm to make it nice, certain things are just better done with a browser based UI. For example:
- Viewing the current namespace tree, (with like expandable subpaths, etc) and having nice search of that tree (with like a decent autocomplete searchbox).
- Being able to view definitions in the tree, with the code pretty-printed, with hyperlinks so you can click through to see source for definitions referenced.
- Navigating and visualizing the history of the namespace tree. (Aside: we actually have history at every level of the tree, which is kind of interesting and different from Git, which just has history at the root)
- Linking to definitions or namespaces, like on Twitter, Slack, etc. It's unfortunate that there's no 1-step process for this. The current process for "hey, check out this code" requires a push, a pull, and then issuing some commands in ucm. Not good.
- Eventually, it would be great if a codebase browser could also show inline docs, comments, and other metadata.
- Generally, a codebase browser is needed to reach parity with current tools, where people are used to having a straightforward way of viewing their codebase. But it can also add lots of neat stuff with little effort, just because Unison has such straightforward access to semantic information about the codebase.

Next we talked about architecture. A couple options considered:

A totally standalone JS (or Elm, Purescript, GHCJS..) front-end, which reads the Unison codebase format. All the logic for rendering code and the namespace tree is done client side, no server hosting needed. I'll call this the "standalone code browser" option.
A Haskell server which could handle codebase browser services for any Unison codebase you want to point it at, but could also function like Hackage, providing ecosystem-wide search and querying. I'll call this the "Unison ecosystem explorer" option.

Both these options sound good for different reasons and have different tradeoffs, so we eventually decided it's cool if both proceed in parallel, based on what folks are interested in working on:

Mitchell wants to take a crack at the standalone code browser option, and is going to try using Elm for it. He's going to start with just porting the deserialization code to Elm, and can then work on an ugly UI, but thought he could use help when he's further along to make the UI actually nice. Heneli wants to try the same using PureScript. Links to these projects:
- https://github.com/unisonweb/elm-browser
- https://github.com/hkailahi/unison-purescript-browser
- Aside: no one was sure the best approach for front-end development. All the options seem to have different tradeoffs. Okay to explore multiple options in parallel as long as there's interest, people are having fun, and learning.
Ian was more excited about the "Unison ecosystem explorer" idea. Positives of this are we could continue using Haskell to do any heavy lifting, and we get to directly use existing Haskell code already written in the Unison ucm codebase. A downside is it requires running this Haskell server, so it's less ideal for supporting local development, and for things like the gist use case: "Hey, check out this otherwise unpublished code I wrote, <link>". It also seems like this Haskell server could be a bottleneck.
- However, even though I think having a minimal client-only code browser is a win, I am particularly excited about possibility of having ecosystem-wide "Hoogle for Unison".

Meta: Meeting went way long (we wrapped up like 1030) and was kinda disorganized. This was maybe okay for a first meeting, but if we wanna make it a regular thing (💯), Mitchell suggested timeboxing the meetings, like 5-7pm. That seems like a good idea, more sustainable for everyone. And I think we can be more organized about things.