u/Zkirmisher

Borg backup has saved all my files on occasion, so that's what I recommend. I configure & use it through Vorta, which is a GUI client for borg.

I've been using Pop for roughly 6 months as well. It has the best default apps and settings I've ever seen on Linux (except for the GNOME file explorer), hybrid NVIDIA/Intel graphics work out of the box, tiling mode is awesome, audio works flawlessly and the recovery OS is a really nice touch. These alone make it the best Ubuntu-based distro IMO.

However, if there's anything that's going to push me off from Pop OS, it's GNOME: the DE often freezes out of nowhere and I have to force-kill gnome-shell, it is not nearly as flexible as KDE and some fullscreen games require a manual workaround in order to even launch without crashing the DE.

I'm curious to see how things turn out for the upcoming Cosmic DE, but I have no intention on becoming an unpaid beta tester so I'll probably be watching from a distance.

Agreed, having a toggle would be nice.

Cool! I'll keep that in mind for later projects. This one has zero external dependencies, so I don't want to add one for something that's already implemented.

I wrote a CLI tool to plot line charts with live data from Unix pipelines. Using this with tmux allows me to set up something like a Grafana dashboard, but in the terminal.

What's the source of this? Thanks in advance

D has CTFE, the only restriction being that you can't do IO or cast pointers to integers. Everything else works at compile-time.

Sure.

For Click's IR, also known as "the sea of nodes", a quick google search will get you to a presentation of his (recorded on YouTube), explaining how the IR is used in Java Hotspot. There's also his PhD thesis and a paper on just the IR's structure. libFirm adopted a modified version of the Sea of Nodes, and they have a paper which gives an overview on how it allows for certain "on-the-fly" optimizations (optimize while the IR is being built).

The PDG is an older graph-based IR which predates SSA-form. The *DG evolutionary line started there and evolved in parallel with Click's Sea of Nodes. It includes the PDW, the VDG, the VSDG and the RVSDG, each trying to improve on the previous IR. The RVSDG has been used in more recent works (with good benchmark results), so it appears to be the cutting-edge IR in the *DG line of research.

Of course, when we talk about graph-based IRs, the current standard is a CFG with some linear IR (e.g. a three-address-code in SSA-form) to fill in basic blocks. That's what LLVM -- and therefore most of the industry -- uses.

Click's Sea of Nodes, also seen in LibFirm's design. Another line of graph-based IRs are the *DGs: PDG, PDW, VSDG, RVSDG.

To whoever designed and implemented the PLDI 2021 website: good job, it is pretty good to browse

Very relevant question that I, unfortunately, can't answer. As far as C goes, the obvious issue with tail-calls would be that it breaks existing ABIs (but ABIs are not part of the C language, anyway).

You may want to get in touch with the Scheme standard Working Group, which includes implementors that may have first-hand experience with this sort of thing.

Other groups that will probably be able to answer are the compiler people working on LLVM/MLIR, GCC or really any functional language compiler (OCaml, for instance).

Consider the parameters for your cfact function: in CPS style, it takes an extra continuation argument c and calls that on the result of the function, instead of returning "normally". c-ify2 is a higher-order function that does this conversion automatically for functions with two arguments. A better name would be contify2.

For example, the enclosing expression in cfact is a call to c=. Its arguments are (λ (nez) ...), n and 0. This will call = (the original one) on n and 0 and pass the result to the continuation in the first argument, binding it to nez. The rest works the same way.

If you're using .NET Regex, might as well do this with the functionality that is already built-in. The Matches method returns a collection of matches, which has a Count property.

PS: unless you want to parse HTML with regex, in which case please read the stackoverflow answer linked by the other comment here.

Yup, it's on GitHub

I built an online tool for prototyping LL(1) languages (lexers and parsers) using the SAFE stack. On-the-fly parsing of test inputs is not as fast as it could be, but other than that I'm happy with the result. If you want to check it out, I suggest taking a look at one of the example grammars for JSON, regex or a simple arithmetic calculator.

One may consider S-exprs to be the AST representation of a program, so Lisp is not far off from what you're proposing: it is probably close to or at the very frontier between human-readable and trivial for the machine.

You can go through PAIP using Scheme, it doesn't require any libraries or anything

Good bot

https://youtu.be/e0vnRZN5GB0?t=109

unfortunately this great simplicity has lead to a great many implementations which has in turn resulted in many somewhat isolated communities

I don't think the language's simplicity is the problem, nor its many implementations. As someone else already pointed out in this post, RnRS code works in every RnRS-compliant implementation for a given value of n.

There's an argument that the standard library is too small and doesn't include enough batteries, which is true. However, the standard library of languages like Lua, Rust and JavaScript are not that big either and yet these have grown a bigger ecosystem much faster than Scheme has. However, those other languages have good editor tooling (autocomplete, goto definition, etc) and package authoring/using tools. In fact, the only languages I know that managed to become popular despite not having great tooling and easy-to-use libraries are C and C++, but those are there mainly for historical reasons.

I think that what Scheme needs to become more popular is user-experience improvements. Guess what, the average programmer no longer uses Emacs and pretty much the only IDE feature that Scheme (or any Lisp tbh) has outside of Emacs is colored parentheses (well, except for DrRacket, but that's not so great either). Then there's the issue of having lots of incompatible module systems across implementations, which makes the package situation even worse. This is a problem that Akku tries to tackle.

My wishlist for Scheme does not include a great unification thingy, but it has:

1. Better editor/IDE support, but writing a good LSP server is not as fun or as easy as implementing yet another Scheme.
2. A standard way to define and use FFIs.
3. Good tools for authoring and using RnRS-compatible packages, as well as tracking dependencies between them.

Yes and no. If you take a quantitative view of things, it's really the official F# docs, F# for Fun and Profit, and the F# Wiki that make up the bulk of where people end up. Since all are open source, it's not hard to update. Books going out of date (to an extent, see below) is ...eh, okay. But also not that big of a deal.

You're right, and I probably made it seem that those getting out of date would be a bigger problem that it actually is. That said, some content is not that easy to update (videos come to mind) and eventually someone learning the language will find out about the old syntax and will have to remember slightly different ways to do the same thing.

Do you have a use case for knowing the grammar?

I didn't mean remembering the formal grammar, but this sort of change leads to additional corner cases in the language (as pointed out by Don himself in one of the GitHub discussions about the new index syntax). While I don't think this is a big problem here and trust the compiler will provide good warning/error messages (it usually does), I just hope stuff like this doesn't eventually pile up.

Oof. I realize the purpose of both changes is to help beginners coming from other popular languages, but now all existing F# tutorials and books using ref cells or index syntax are out of date and will confuse those very same beginners. Also, these add corner cases to the grammar only an implementer would remember, as is usually the case with unplanned syntax changes.

Well, the error pretty much tells you what's happening, make-key-weak-eqv-hash-table is not defined. The book is probably using a Scheme implementation with built-in hash tables, but this is not the case for Biwa.

I thought this was an update to the Kind model checker, so you might want to rethink the name