CodeIsTheEnd

Guilty [1]. But it's really hard to handle both light and dark color themes! On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme. Some color schemes intentionally invert the "bright" colors and makes them darker for a light colored scheme. This is what Gruvbox [2] does, but most other palettes don't. I also have an issue with Solarized which makes some of the Bright colors almost exactly the same as the foreground or background, which can make text printed in certain colors seem invisible.

I've used ANSI codes to invert colors (which works pretty well for highlighting), and dim colors, but those can't solve everything.

[1]: https://github.com/PaulJuliusMartinez/jless/issues/4 [2]: https://github.com/morhetz/gruvbox

(Author here) Homebrew support was added entirely with macOS in mind, but Homebrew for Linux uses the same repository of formulas as Homebrew for macOS [1], so you get Linux support for free. I included Homebrew for Linux because it's an option, but I don't want it to be the only option.

I guess I should explicitly say in the documentation that help would be appreciated in adding support for other package managers. I definitely want jless available through the most standard avenues.

[1]: https://github.com/Homebrew/homebrew-core/blob/master/Formul...

Oops, sorry, I haven't actually made a new release with those commands yet. I'll need to have better discipline maintaining a separate `latest` branch for the website...

Sorry! Someone already filed an issue about this [1], but I haven't had time to investigate exactly what is appropriate to put there. I don't use Linux, nor have I ever released and distributed open-source software before, so I'm just kinda guessing here -- other people have added the project to various package managers, not me.

Installing via Linux Homebrew is simply listed as an option because it's available as a Homebrew formula. And the option to install via cargo is also noted.

[1]: https://github.com/PaulJuliusMartinez/jless/issues/46

Author here! When I originally submitted it, it didn't get a lot of traction (it got on the front-page via the second chance pool a couple days later), and I definitely regretted not including "written in Rust" in the title. I'm acutely aware of HN's love of Rust, and the subsequent grumbling about always bringing it up that something is written in Rust, so I left it out with the false illusion that not mentioning it would make it more "pure" or something.

But I was also pretty confident that I made something useful, and, in hindsight, I don't think I should have preemptively felt bad about using some "cheap" form of marketing to get people to see it. I have really conflicting thoughts about marketing and self-promotion from my experience trying to show people my other project, plaintextsports.com [1] (live sports scores in plain text with no ads or trackers so it loads instantly! I think the HN crowd would love it!). There's a weird line between marketing and advertising and self-promotion, where one is "ok", but the other is frowned upon. It's also a tale as old as time that the better marketed but technically inferior product wins out. (AC vs DC initially, Betamax vs VHS!) How much of success is being brazen enough to ignore those norms and shamelessly promote something? Should it be considered shameful to promote it in the first place?

In this case, being written in Rust is definitely a feature, as least when comparing tools! fx [2], a similar tool that made the front-page a couple months ago runs using Node, and I'm sure jless can handle bigger files and uses less memory (though admittedly I haven't actually verified this).

[1]: https://plaintextsports.com

[2]: https://news.ycombinator.com/item?id=29861043

This reminds me of a very poor interview question I asked a couple of times (and then never asked again because it is a terrible, terrible, interview question).

The snake cube puzzle [1] is a puzzle where you have to fold up a string of 27 cubes, with fixed "turns" like the shapes in the OP, into a 3x3x3 grid.

The goal was not to find a solution to the puzzle, but to find the smallest 2d area the snake could fit into without folding against itself. It turned into a modeling problem (how do you represent the puzzle in code?) and a recursion problem (try all possible folds), but, uh, even with a physical puzzle to play with, it was a little too abstract

A commenter on the link below asked another question over 13 years ago: can the puzzle be folded into a plane without any holes? Obviously if you just lay out the puzzle from end to end it will be in a plane, and without any holes, so maybe the question should be: what is the smallest 2d area the snake can fit into without creating any holes?

[1]: https://mypuzzles.wordpress.com/2008/09/07/the-snake-cube/

I browsed Fiverr to find a few artists whose styles were similar to what I had in mind, then messaged a few of them. annatgraphics [1] was able to take my crude color pencil sketches and turn them into the slick art you see today!

[1]: https://www.fiverr.com/annatgraphics

Thanks to the both of you! plaintextsports was my real passion project over the past year (probably 3x more time spent on it than jless!), so I really appreciate it when other people find value in it. I'm a Milwaukee Bucks fan and building a site explicitly so I could follow the team more easily certainly made winning the championship more personally meaningful.

Yup, someone already made a PR for to add these! It turns out the behavior is pretty subtle in terms of how it handles count arguments (it's actually stateful!), and where the focus moves. I'll take some time to figure out how to exactly match the vim/less behavior, but that should be coming soon!

I'm more of a ctrl-e/ctrl-y guy myself, so I didn't feel a need to implement these commands right away.

That's certainly the plan! I've never released a project like this, so I wasn't sure what the process is for adding things to Homebrew, or other package managers. A few people have been really helpful and already added it to Arch Linux and NetBSD's package managers.

This week I just wanted to get the project out there to see if people liked it, so I compiled stuff locally and manually uploaded them to the GitHub releases page. I'll spend some time over the next few weeks figuring out how to automate a lot of these things.

Anything longer than a few sentences I'll write in vim and am always horrified when I copy to Gmail or Google docs and find spelling mistakes, duplicated words, and incomplete sentences everywhere.

This is incredible! While just controlling the soprano, it does the voice leading for all the other voices and composes together actual chord progressions. I don't have a good enough ear to determine whether it actually stay in the same key, but I could definitely hold it on a dominant chord and then it would resolve to the tonic as I moved. I even heard a suspension thrown in there!

Previously discussed (66 comments) just a few months ago:

https://news.ycombinator.com/item?id=28298729

I recalled this project / paper while reading the comments on "DeepMind’s New AI with a Memory Outperforms Algorithms 25 Times Its Size" (https://news.ycombinator.com/item?id=29645887).

The many iterations of TCP congestion control algorithms (Tahoe/Reno/NewReno/Vegas/BIC/CUBIC) all rely on pretty hard-and-fast rules for detecting congestion and anticipating certain failure conditions, but these are limited by our ability to parse patterns from complex emergent behavior and reduce those to rules that, at least on some level, "make sense".

This project, Remy, keeps track of three variables: - exponential-weighted moving average of interarrival time of acknowledgements - exponential-weighted moving average of time between sender timestamps - ratio between most recent round-trip-time (RTT) and the minimum RTT seen

From these three variables it generates an "action", which is really three parameters that are plugged into a simple rule to determine whether to send more packets. The three parameters are: - A multiple m of the current congestion window - An increment b (possibly negative) to the congestion window - A lower bound r > 0 on the time between sending segments

If the window isn't full, then the algorithm will send more packets, but not more frequently than r units of time. And Remy will occasionally update its action based on new data.

The key then is that Remy generates different actions for different input state variables, providing different behavior based on the observed state of the network in a way that's orders of magnitude more fine-grained than any human written algorithm. (I think these lookup tables are generated offline; not sure if they can be adjusted while running.)

Wow, this is a really great article. Thank you for sharing!

It discusses a fascinating point about browser UI: when the browser displays something inside its chrome, where a malicious page could render arbitrary pixels, it must establish a visual bridge back to the "trusted zone" (the chrome), providing proof that is in fact trusted content.

(The author points out that new APIs allowing writing to the entire screen means it's hopeless and we're all doomed though.)

And if you want an increasingly slower bash startup, you can add the following to your coworker's .bashrc/.bash_profile if they keep forgetting to lock their screen when they go to grab a snack:

    echo 'sleep 0.01' >> ~/.bashrc # or ~/.bash_profile

TIL: Chrome DevTools Layers tab, accessible by going to to the three-dot menu > More Tools > Layers, which allows you to see things rendered outside of the browser viewing area (among many other things I'm sure).

If you have something that "unmounts" things as they scroll off the screen ("virtualized rendering" as the article calls it, a common feature for data grids), this is great tool for verifying that behavior.

Blind mode is great! It'd be cool to be able to see the entire tournament bracket at the end -- I can only see the font that won, but the others were pretty close. I want to see when the font I normally use got knocked out.

Also, for really maximizing utility, it'd be cool to add variations of the same font but with different line-heights. I definitely voted against some fonts because they appeared "squished", but maybe a bit bigger line-height would make me prefer it.

Two things:

1) I recently implemented truncating long lines for CLI tool and went with a hybrid approach using both graphemes and virtual columns -- I'd only truncate a line between graphemes, but when counting how much space was used up I would use virtual columns. In the case of something like , this means things tend to error on the "safe" side of truncating a line too early if the virtual column approach counts it as 4 columns wide rather than 2.

2) I wanted to test something with the scientist emoji and managed to crash Ruby's repl, irb, simply by pasting it into the repl and then backspacing over it. (It was clearly confused about the position of the cursor, and the stacktrace pointed to an error in a line_editor.rb file.) I was on Ruby 2.7.1, but it looks like it's been fixed in 3.0.0!

Work on esbuild started at the start of 2020. It is primarily authored and maintained by Evan Wallace, who, in addition to making this tremendous contribution to the JavaScript ecosystem, is the CTO and co-founder of Figma. Incredible output.

Directly related to dithering and compression, Return of the Obra Dinn is, to an certain extent, an "unstreamable game".

When this streamer on Twitch tried to play it [1], the quality of his composited webcam would immediately drop as the compression algorithm focused on rendering the high-frequency dithering sections of the screen. As soon as he would aim the camera away from the fancy rendering (to the sky for instance, or the menu), the video quality would immediately improve. Really a fascinating clip.

[1]: https://imgur.com/S191sI0

Here's a thread of someone complaining about it on Reddit:

https://www.reddit.com/r/Twitch/comments/ls06j5/the_unstream...

I don't understand why GitHub hasn't solved the issue of diffs starting with a '}' (or ')' or 'end'). Just slide the diff over while it starts with a closing token! I suppose it's an artifact of the diffing algorithm, but aren't there better diffing algorithms, even built-in within git?

This is by far the most obvious example of "git doesn't understand programming languages", but it also seems like the most straightforward to fix.

There seems to be a fair amount of drama brewing on the mailing list [1] for tzdb [2], the time zone database that is the foundation of essentially everything related to dates and time on a computer. The time zone database tracks time zones, UTF offsets and daylight-savings rules and is regularly updated as governments change the local rules regarding time.

As I understand it, recent controversial changes to tzdb effectively removed data for some timezones pre-1970. This email [3] seems to give a rough summary of what this means.

I'm unsure when this change was made, but it seems like in the past month or so there have been calls to revert this change [4], discussions of a fork [5], and calls to replace the TZ coordinator [6].

As a result of Samoa abolishing Daylight Savings Time [7], there is a need to release an updated version of tzdb. The linked proposal is suggesting releasing two new versions, one with and without the recent change, effectively an officially sanctioned (temporary) fork until the issue can be fully resolved.

I don't have any insight into what's going on beyond reading some of the emails on the mailing list and a couple of posts on Twitter, so if anyone wants to step in and provide more detail (and/or correct me), go ahead!

[1]: https://mm.icann.org/pipermail/tz/2021-September/thread.html

[2]: https://www.iana.org/time-zones

[3]: https://mm.icann.org/pipermail/tz/2021-September/030517.html

[4]: https://mm.icann.org/pipermail/tz/2021-June/030220.html

[5]: https://mm.icann.org/pipermail/tz/2021-September/030400.html

[6]: https://mm.icann.org/pipermail/tz/2021-September/030478.html

[7]: https://news.ycombinator.com/item?id=28626595

If anyone is curious, the origami stellated [1] icosahedron in the second image is built from Sonobe modules [2][3], a kind of modular origami. Basic structures formed by Sonobe units have 3-sided 45-45-90 pyramids on top of an underlying polyhedra with triangular faces.

Each Sonobe unit functions as an edge in the underlying structure, so building a structure around an icosahedron, which has 20 faces and 30 edges, requires 30 units, and yields a stellated icosahedron with 60 faces and 90 edges.

You can also build a stellated octahedron from 12 pieces, and a stellated tetrahedron (which actually just appears as a cube) with 6 pieces, but that's just the beginning [4]!

[1]: Strictly speaking, it's not a true stellation, which is formed by extending the planes of faces until they intersect. [2]: https://en.wikipedia.org/wiki/Sonobe [3]: https://www.amherst.edu/media/view/290032/original/oragami.p... (instructions for folding; I believe the image uses the two-mountain folds variation on the first page) [4]: https://www.polypompholyx.com/2017/01/modularorigami/

This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world.

Using Rust promises performance and stability, key features for the thousands of engineers that will be running Rome as a critical part of their workflow. The vast majority of those developers would prefer that the tool runs faster and has fewer errors over having a lower barrier to entry for contributing.

"Contributing" may also encompass the plugin/extensibility ecosystem around the tool, and can be closely tied to the underlying implementation language. This functionality has been integral to the growth of things like Babel and Webpack, but it seems in this case Rome is trying to replace much of that very ecosystem.

I there are some toolchains that may prioritize "barrier of entry to contributions" -- new languages, or niche communities for example -- but I don't think it's an appropriate priority for a toolchain for a massively popular established programming language with $4.5 million in funding [1].

[1]: https://rome.tools/blog/announcing-rome-tools-inc/

A clarification: Rust only makes this guarantee for certain types[1] which you would expect to be represented by a simple pointer under the hood (e.g., Box<U>, &T, function pointers) and for other types which can never be all 0.

Making this optimization for something like Option<u8> is, naturally, impossible.

(I assume you are aware of this and were implicitly referring to this optimization.)

[1]: https://doc.rust-lang.org/std/option/#representation

I haven't used Lunar (https://lunar.fyi/), the app the author built, but it looks fantastic! Clearly great effort has been put into it!

I really appreciate this class of application that exposes more hardware functionality to the end user. Flux (which may or may not be a direct competitor) is another great example, as is Halide, the pro camera app for iPhones. They're certainly not flashy, but they can be great quality-of-life improvements.

And they're difficult to write! They require using APIs that are often woefully under-documented, and terribly difficult to debug. I wanted to write an app that would slowly lower your device's volume over time (so you could raise the volume for a song that you like, but then not accidentally spend the next 30 minutes with the volume super loud), and even doing simple things like listing audio devices and getting their names was endlessly frustrating.

This Ask HN thread from someone in a similar position (“I’m a software engineer going blind, how should I prepare?”) from last April may have some helpful advice:

https://news.ycombinator.com/item?id=22918980

Plain text sports!

https://plaintextsports.com

Though this is presentation only, not editing.

(I made this.)

> Crunching algorithms for 2 semesters probably makes aspiring engineers feel that they are simply memorizing pages from a book which are trivially indexed by google.

I realize that the majority of engineers will never need to use any of the more advanced topics taught in an algorithms class, but I hope you recognize the irony in this comment; the “trivial indexing” performed by Google is anything but, and, in fact, is only enabled by those very algorithms, implemented dozens of times, in multiple languages, with subtle variations and optimizations and under non-obvious reinterpretations, at every level of the stack.