I hope you continue this series. 1) git is a totally baroque system that I myself am constantly eluded by. 2) models help to understand such systems, and I’m always amazed how terse Alloy models can be.
See also: ValidAlloy: A tool for validating a git alloy specification using testcase generation. It is an impressive work where model refined using real testcases for real Git implementation.
The graph or dag module contains an implementation of the tree predicate, which I started using instead of constraining the parent relation directly
in Alloy, you mean? Does it have any side effects? (Like opening ordered on some sig making it fixed-size?)
I do wish there were more convenient selection-mode shortcuts for “beginning of line” and “end of line” than home and end, something closer to the home row. Might have to conjure forth my own?
Check out gs
, gl
, etc. Lots of useful stuff under g
for this!
Big challenge going from vim is that single-command jumps (eg |$) are missing - I do think the discoverability and consistency of “g” wins out (ge - gO eND BUFFER (last line), gd - gO TO dEFINISHION, gh - line head (start) etc). (Discoverable, as g pops up menu for g-what).
yeah, I hit $
a lot when switching from Vim to Kakoune, although thankfully the transition to Helix was easier. I actually appreciate having to hit fewer modifier keys in these situations. The same amount of keys in a sequence instead of a chord is just nicer for my hands.
I did try it first - but concluded it just got in my way of using Helix properly. On surface it might seem a bit like “different vi” - but in reality it’s quite different. And I think, probably, better (too soon to tell).
Thanks Brian, now I know! I also added it in my config. You should specify in your article that it is a client config, not a server one though.
Hillel Wayne’s introduction to Alloy 6, and his reference docs mostly covering Alloy 5
I feel called-out
Oh dear, it’s not meant that way. I’ve just been annoyed at telling people how to learn and being like “ok do the filesystem tutorial except ignore anything with single primes and then when it gets to time just ignore that and let’s pair on modeling a stoplight”. Easier to just say what version each source is written for!
looks like it’s in Rust now aww
Look at the last entry in the FAQ. The compiler has always been written in Rust, the runtime is written in Zig. To see some of the Zig source code, look in crates/compiler/builtins/bitcode.
As far as I know, the compiler has always been written in Rust! You can write platforms in whatever language you like, though.
oh, interesting; when they first announced the language i assumed it started life as a straight-up fork of the haskell-based elm compiler
Always rust, though parts of it were translated very directly from the elm compiler. So some sections the code may be quite similar.
This is so cool! It’s something I’ve sort of for a while. An ecosystem around it, e.g. Comby, would be neat.
Hi, I’m the author! Cool that this ended up here. I’d be happy to answer questions, and I also want to repeat: if you are looking at this going “eh, cool, but it doesn’t do {language}”, I’m happy to add it (or help you to, if you’re interested.) There’s a big list of tree-sitter grammars at https://tree-sitter.github.io/tree-sitter/#available-parsers which we can drop in pretty easily.
Hm I like the idea of having it online, might put up my own … I have to copy this between static files, Python, and now PHP (yes I wrote PHP :) )
Here’s one I just made:
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Hello</title>
</head>
which I now realize is inconsistent with oilshell.org:
<!DOCTYPE html>
<html lang=en>
<head>
<meta charset=utf-8>
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Oil</title>
</head>
lang=en
– does this improve anything? Does it stop Chrome from showing you annoying and incorrect translation pop-ups?<meta charset=utf-8>
– I believe this is better because you don’t always control the web server, and the default Content-Type
header does not include UTF-8. So I should add this to my other site.lang is also used to set hyphenation rules. I believe there are some accessibility considerations for screen reader pronunciation, too.
I don’t get the purpose of this, isn’t it easier just to switch sessions the regular way with ^b(
and ^b)
I do that as well (as well as prefix-s
) but it doesn’t start up new sessions in the directory I care about automatically. It’s a couple commands to start one, and potentially getting it wrong if I forget that a session already exists… classic shell script territory 😆
I see, we probably use sessions slightly different. I use a session per active project/customer I’m working on plus one generic/sandbox and usually I have around 3 sessions open, one session usually consist of 2-9 windows with a couple of panes each where I have a window per subproject in a larger project. For instance when I’m working on a client code base where there’s subproject for frontend, a couple of backed services, database, infra, documentation I keep a window for each of them named after their respective name or purpose and name the whole session after the client/project.
I have been investing quite some time for my static website to be as lightweight as possible for the client (for instance, rendering equations off-line), and I noticed the same thing.
I will probably try to see if I can use this approach too. Thanks for sharing!
how are you calculating the tradeoff between rendering equations in the browser vs shipping images to the frontend? Are the images truly tiny, beating the size of mathjax (or whatever you use?) Also curious how you’re keeping this accessible!
Thanks for the article, it’s a very neat approach!
An alternative I always wanted to try but didn’t get around to is using unicode-range and slicing up the font so that the browser can load more glyphs on demand if it needs to. I’m curious if this works as advertised in most browsers (i.e. font files are not downloaded unless there’s some char in their unicode range)
caniuse suggests yes!
https://github.com/Munter/subfont seem like a good alternative tool which probably would be easier to use - from what I can see.
If you’re talking about code blocks, I always set them like my block quotes. If it’s inline code, try and find a code font that has around the same x-height as your body text. If the family you’re using had a monospace variation, that’s probably your best bet as it will have been have designed to look good with the rest of the family.
Aside from general advice, could you share some screenshots? The x/y problem exists in design too. 😅
Oh I am still experimenting, HERE is the current version, and HERE is the same for a trickier situation where the output is displayed below the code. But it is “work in progress” and the design will probably be changed again. I tried too many things this weekend, will need to take a break before revisiting this question later.
But I am interested in the general principles too. The thing is - I have several example websites which look lovely in terms of text typography. But I don’t know of any actual website where I would say “yeah, this one has code display figured out”.
I think it looks fine. You can play around with this forever, but IMHO you quickly get diminishing returns and just gets a distraction from actually writing content.
For me, the biggest issue I try to avoid is horizontal scrolling, as I find that’s just annoying.
I wrote an essay with a bunch of code-blocks in it, and I think they turned out alright. Unfortunately for typesetting code, there’s a bunch of conventions that collide:
Personally, if I’m writing code for an article, I compromise on the second one and wrap my code at 40-60 columns. It feels a bit cramped, but I can present individual code-chunks and provide context in prose, rather than having to present a big lump of code that provides context through indentation (and thus requires wider output).
For the absolute details of formatting, it looks like you’re going minimalist for your text formatting, and so the complexity of your code formatting (background colours, borders, and occasionally horizontal scroll bars) feels distracting. For the examples you’ve posted, I think just removing the borders makes them look much better.
The style of code blocks in your essay look very well and even original. Very nice. Thank you for the comment as well, I found your opinion about conventions that collide to be true. The way I try to solve it is by reducing the font size of code blocks.
And yes, I am trying to be very minimalist but when I just indent code it doesn’t stand out as much as I want it to.
CSS Tricks, possibly?
Looks like you’re using a different size for your code. Even if it’s the same pixel value it’s perceptually different. Adjusting it until the Bowls of the lowercase o are about the same actual size might be a good way to go. It also looks like there is some margin around your inline snippets—that may look more jarring because it is literally offset from the flow of the text.
In fact yes, CSS Tricks is pretty good. https://css-tricks.com/almanac/properties/f/flex/
The inlines are separate but flow well
CSS Tricks work for their case. I tried dark background similar to what they have in this example. However it only works when your syntax has a lot of colors. If you use one color for text it doesn’t look good against the dark background.
Regarding margins - the margins in the example should be consistent between paragraphs as well as paragraph and border of the code block. It looks off in the example I gave because all the paragraphs are one line in length :) I think it will not look too jarring with normal blocks of text like HERE
it’s a self-hosted instance of git.sr.ht, seemingly without an https redirect enabled in nginx and with an expired cert.
I’m not sure why fewer than 200 people said they use Haskell at work in the previous question but more than 600 said they use Haskell at work at least some of the time in this question.
Was the question “Where do you use Haskell?” multiple choice, or was the survey using radio buttons? Could be the source of the discrepancy.
The “where do you use Haskell” question was multiple choice (check boxes). The “do you use Haskell at work” question was single choice (radio buttons).
I had this same problem with State of Elm. The first go ‘round people told me that the binary yes-or-no was unclear because they felt they had to be using it in production. But that wasn’t my intent, so this year I tried to fix it by making the “where are you using Elm” question have the following choices:
Next year I’m going to break it down even more. It turns out that a lot of things I thought were yes/no initially are actually sliding scales. (Except for “can I have your email” or really really specific and leading questions.)
That is actually quite interesting, I’ve been tinkering with both Haskell and Elm at work but haven’t used them on any project meant for production.
I usually experiment with a lot of languages for smaller side projects and when architecting a new product and evaluating tech choices, many of these are never put into production usage while some do.
This seems like it could break a lot of stuff!
I wonder how big the group actually making decisions is here? It’s interesting to see all the names tagged coming in as implementers of specific browsers or members of the working group.
From my forgotten Git internals knowledge, which is very sparse, I remember that the hashes can come from a textual representation, i.e., a tree is a file with a list of blobs, and the tree’s hash is the hash of the file, as any other object in Git.
Given that, is it possible to have two trees with different hashes and the same objects?
From a blog post by Mike Street:
So, as a trivial case, amending a commit message changes the hash, without changing any of the files.
Yes, it’s possible. You’d need to get a SHA-1 hash collision. I linked to someone who did that in the post; they changed the git code to only take the first byte of the hash to see what happened (segfault)