rntz

why the sharp divide around december 2022, with almost none imported before that and plenty after?

Is it ironic, though? "Right to repair" has to do with freedom, sure, but not free-as-in-beer. It doesn't mean "it costs me no money to repair things". It means "I am not prevented from repairing things". Selling stuff - including selling writing - is not incompatible with the right to repair.

Have you tried writing with your non-dominant hand? I'm a righty and I find left-handed writing effectively impossible.

With Talon on Mac I believe this is possible (Mac has surprisingly nice accessibility APIs), but I don't know whether Talon on X11 can do it. If it's possible it would probably(?) involve rolling your own at-spi stuff.

Is this duplication the reason why the OP is flagged? Otherwise I'm flummoxed - it seems a perfectly reasonable/normal article.

> (The same principle can be used to entice people to leave a crowded sauna — just pour water on the hot rocks to generate loyle.)

I have never come across the word "loyle" before, and googling suggests it does not exist. Does anyone know what the reference here is? Or what this is a typo for?

I think that's actually IBM Selectric Script, not Scribe (the images are labelled at the bottom not the top). https://fontsinuse.com/typefaces/10922/script-ibm finds two uses of it.

It turns out to be not that hard to just compute the language of the regex, if it is finite, and otherwise note that it is infinite:

    import Prelude hiding (null)
    import Data.Set (Set, toList, fromList, empty, singleton, isSubsetOf, unions, null)

    data Regex = Class [Char]   -- character class
               | Seq [Regex]    -- sequence, ABC
               | Choice [Regex] -- choice, A|B|C
               | Star Regex     -- zero or more, A*
                 deriving (Show)

    -- The language of a regex is either finite or infinite.
    -- We only care about the finite case.
    data Lang = Finite (Set String) | Infinite deriving (Show, Eq)

    zero = Finite empty
    one = Finite (singleton "")

    isEmpty (Finite s) = null s
    isEmpty Infinite = False

    cat :: Lang -> Lang -> Lang
    cat x y | isEmpty x || isEmpty y = zero
    cat (Finite s) (Finite t) = Finite $ fromList [x ++ y | x <- toList s, y <- toList t]
    cat _ _ = Infinite

    subsingleton :: Lang -> Bool
    subsingleton Infinite = False
    subsingleton (Finite s) = isSubsetOf s (fromList [""])

    eval :: Regex -> Lang
    eval (Class chars) = Finite $ fromList [[c] | c <- chars]
    eval (Seq rs) = foldr cat one $ map eval rs
    eval (Choice rs) | any (== Infinite) langs = Infinite
                     | otherwise = Finite $ unions [s | Finite s <- langs]
      where langs = map eval rs
    eval (Star r) | subsingleton (eval r) = one
                  | otherwise = Infinite

You're correct, and I don't see any good way to avoid this that doesn't involve enumerating the actual language (at least when the language is finite).

Oof, my hubris.

Here's a simple Haskell program to do it: -- https://gist.github.com/rntz/03604e36888a8c6f08bb5e8c665ba9d...

    import qualified Data.List as List

    data Regex = Class [Char]   -- character class
               | Seq [Regex]    -- sequence, ABC
               | Choice [Regex] -- choice, A|B|C
               | Star Regex     -- zero or more, A*
                 deriving (Show)

    data Size = Finite Int | Infinite deriving (Show, Eq)

    instance Num Size where
      abs = undefined; signum = undefined; negate = undefined -- unnecessary
      fromInteger = Finite . fromInteger
      Finite x + Finite y = Finite (x + y)
      _ + _ = Infinite
      Finite x * Finite y = Finite (x * y)
      x * y = if x == 0 || y == 0 then 0 else Infinite

    -- computes size & language (list of all matching strings)
    eval :: Regex -> (Size, [String])
    eval (Class chars) = (Finite (length cset), [[c] | c <- cset])
      where cset = List.nub chars
    eval (Seq regexes) = (product sizes, concat <$> sequence langs)
      where (sizes, langs) = unzip $ map eval regexes
    eval (Choice regexes) = (size, lang)
      where (sizes, langs) = unzip $ map eval regexes
            lang = concat langs
            size = if elem Infinite sizes then Infinite
                   -- finite, so just count 'em. inefficient but works.
                   else Finite (length (List.nub lang))
    eval (Star r) = (rsize * Infinite, lang)
      where (rsize, rlang) = eval r
            lang = [""] ++ ((++) <$> rlang <*> lang)

    size :: Regex -> Size
    size = fst . eval

NB. just realized this code has some bugs, eg `size (Star (Choice []))` and `size (Star (Seq []))`. Also the generated string-sets may not be exhaustive for infinite languages, which doesn't affect the size calculation but does make fixing the previous bug harder. Oof, my hubris.

This depends heavily on how repetition is implemented.

With a backtracking-search implementation of regexes, bounded iteration is pretty easy.

But the linked webpage appears to compile regexes to finite state machines (it shows you their finite-state-machine, for instance), and eg [a-z]{1,256} will have 256 states: 256 times the 1 state needed for [a-z]. If [a-z] were a complex regex, you could get a combinatorial explosion.

This alone probably isn't the issue? 256 is not a very large number. But I suspect there are follow-on algorithmic issues. This is just speculation, but I wouldn't be surprised if that 256-state machine were computed by applying DFA minimization, an algorithm with worst-case exponential running time, to a more naively generated machine.

^ and $ are a problem, although one with a workaround.

The standard theory of regular expressions focuses entirely on regex matching, rather than searching. For matching, ^ and $ don't really mean anything. In particular, regexp theory is defined in terms of the "language of" a regexp: the set of strings which match it. What's the set of strings that "^" matches? Well, it's the empty string, but only if it comes at the beginning of a line (or sometimes the beginning of the document). This beginning-of-line constraint doesn't fit nicely into the "a regexp is defined by its language/set of strings" theory, much the same way lookahead/lookbehind assertions don't quite fit the theory of regular expressions.

The standard workaround is to augment your alphabet with special beginning/end-of-line characters (or beginning/end-of-document), and say that "^" matches the beginning-of-line character.

title typo: "Purely Functional Data Structure" -> "Purely Functional Data Structures" (pluralization)

reads a bit weird otherwise - sounds like it's discussing a particular purely functional data structure when it's actually a survey of many (pretty much the canonical survey of them, in fact).

Corporations make profits if their products are worth it to people, true. But in a sufficiently unequal world, what's "worth it" to a rich person matters more in the market than what's "worth it" to a poor person - the rich command more money than the poor. If the money made by corporations accrues only to a few, we get a positive feedback cycle of inequality: corporations cater to the market; the market caters to rich people; and in a highly concentrated market, only a few people get rich off of this. The result is a poor underclass. Society as a whole gets richer, perhaps, but very unevenly. Besides causing political instability, this is also an inefficient allocation of resources - an additional $1000 improves a poor person's life more than it does a rich person's.

> All of these low-level concerns make working in AI feel like the candle that burns bright and short. I'm oscillating between the most motivated I've ever been and some of the closest to burnt-out I've ever felt. This whiplash effect is very exhausting.

My candle burns at both ends;

It will not last the night;

But ah, my foes, and oh, my friends—

It gives a lovely light!

(First Fig, Edna St Vincent Millay)

This is a great set of examples for showing off how current chatbot AIs have impressive capabilities but are also prone to getting important details wrong.

For instance:

1. The description it gives of how to generate a Shepard tone is wrong; to make a Shepard tone, you need to modulate _frequency_, not (or not only) amplitude.

2. The Shepard tone it generates is also wrong, but in a different way. For instance, there's no bass at the end matching the bass at the beginning, so it can't be looped to create the illusion of infinite ascending motion.

3. The "Game of Life QR code" isn't actually playing the Game of Life in a way that results in a QR code. It looks like it's starting with a QR code and playing the game of life, then time-reversing the result; so you see the Game of Life running "backward" until you get to the QR code as an initial state. I say "seems like" because I can't be confident it hasn't made any mistakes. This _may_ be what the author intended by "working backwards"? But I took that to mean that it should "work backwards" by first finding a state S that stepped to the QR code, then finding a state S' which stepped to S, etc; so that you'd have a run of the game of life ending in a QR code. This would involve actual search, and there are patterns which simply cannot be achieved this way (have no predecessors).

4. The planet orbit simulation seems to have all planets in circular orbits, rather than elliptical. For Earth this is probably unnoticeable, but Mars' orbit varies from 1.38 AU to 1.67 AU - quite noticeably elliptic - but appears circular in the "simulation".

etcetera, etcetera. There are also plenty of "obvious" glitches in the graphics simulations, but those concern me less - precisely because they're obvious.

> If you are hell-bent on using FixedBufferAllocator only and you want to avoid copies, there is a way. Using two buffers (and separate allocators backed by them), it is possible to keep swapping between them after every iteration.

I found this bit lovely: the author has independently reinvented the core idea of semispace copying garbage collectors (see eg https://wingolog.org/archives/2022/12/10/a-simple-semi-space...).

One argument is: if font designers had to pick just one price, instead of charging a higher price to bigger customers and a lower price to smaller ones, they'd need to pick a higher price in order to recoup their costs. This would price some smaller customers out of the market entirely.

The comparison with a freelancer misses the weirdness of digital goods, where there's zero marginal cost. The work of designing a font is only done once, and then has to be recouped over many sales; since each sale involves basically zero additional work, any choice of how to split up the cost among customers is inevitably artificial, and not based on "how much work" it represents.

And of course, any artificial way to decide how much each customer pays is going to screw somebody over for no good reason. I don't think there is a perfect solution here.

This situation is beginning to improve if you know where to look. There are several typeface designers who offer both low prices and reasonable licensing terms for their fonts; for instance, David Jonathan Ross (https://djr.com/) has a "Font of the Month Club" that gives you one font per month at $6/month; even without membership you can get previous club fonts for $24; and the licensing terms are plain english. Matthew Butterick's fonts cost more ($120 for a full typeface; mbtype.com) but have a very reasonable plain-English license.

That said, usage tiers (where you must pay more if your website gets a certain # of views/month) seem ubiquitous. I think these are ok - big websites can afford to pay more, and I wouldn't be surprised if a disproportionate amount of a typeface designer's income will come from a few heavy hitters; so without charging more for big websites, they'd have to raise the price for small ones, pricing hobbyists like me out of the market. Big font companies, though, often require you to install intrusive javascript tracking code to enforce these agreements, which is a step too far for me.

Fonts are pretty much a pure crystallization of the "information wants to be free"/"artists want to be paid" tradeoff. Digital fonts are nothing but information, so it seems absurd to charge more for using them on more websites/in more documents/with a larger team - there's no additional cost being incurred!; but without artificial restrictions on reuse, typeface designers wouldn't get paid at all.

tl;dr You're going to get better treatment and better prices from little one-person font designer shops than from the big companies (Monotype, Hoefler & Co). Unless you're a big co yourself, the OP is right; they're a waste of your time. But the little guys are a decent option, you just have to hunt around.

Possibly a mistranslation? I can't read Khmer, but someone on twitter claims there were 12 contacts (rather than infected individuals) with the index case (the deceased girl, I assume) of which 4 report flu-like symptoms: https://twitter.com/jurreysi/status/1628816263295438849

It seems to me the author misses a purely practical reason to have respect for a variety of religions: peaceful and happy coexistence. Historically a lot of blood has been spilt over religious differences and a lot of people have suffered oppression because of their religion. This was straightforwardly bad, and we are not free of these conflicts or their causes yet; so it's wise to try to keep things smooth and tolerate a variety of religious practices (dietary restrictions, days off, prayer times, etc). Obviously the exact level to which this respect ought to be enshrined in law is up for debate. But "respect for religion" can be an instrumental rather than a terminal value.

The article appears to misrepresent the result of a study it links to. From the article:

> A study conducted by researchers in Switzerland found that a wine labelled with a difficult-to-read script was liked more by drinkers than the same wine carrying a simpler typeface.

But from the abstract of the study linked to (https://www.sciencedirect.com/science/article/abs/pii/S09503...):

> Fluency was manipulated via an easy- or difficult-to-read font. Results showed that there was no effect of the consumption domain. However, the wine was liked more in the high-fluency condition compared to the low-fluency condition. Thus, the results indicate that a wine tastes better if the labeled visual information can be processed relatively fluently.

Which is exactly the opposite.

Objects, messages (OO, Smalltalk, Alan Kay)

Function (lambda calculus, FP)

String (shell, tcl, perl)

Process, actor (the actor model, Carl Hewitt, Erlang)

Value, immutable, pure (pure FP)

Thunk, lazy (lazy FP, Haskell)

File (Unix, plan 9)

List (lisp)

Expression (lisp macros, see linked essay)

Copyable (languages without linear type systems, ie. almost everything but rust; tbf some languages have a move/copy distinction even if they don't enforce it with a type system)

Serializable, transmissible over the network (anything that tries to do transparent RPC or state saving, smalltalk images, object databases, X windows)

Sortable (anything with a generic sort function that doesn't take a comparator or similar; ditto generic collection types like maps or sets that don't take a comparator or hash function)

goto (see Dijkstra's "goto considered harmful" essay)

call/cc (Scheme; see also recent work on algebraic effects and delimited continuations)

(I'm the author)

Talon actually can work with Dragon; it started out requiring Dragon but has since grown its own voice recognition. Anecdotally, a lot of folks on the talon slack seem to be refugees from Dragon-based solutions, and a common observation is that Talon's voice recognition is much lower-latency than Dragon. Unfortunately I can't confirm this as I haven't used Dragon myself.

My impression of talon's speech recognition is that it's good enough for voice coding, but could be improved when it comes to dictating English prose. That said, there are promising avenues of improvement. If you pay for the Talon beta, there's a more advanced voice recognition engine available that's much better at English, and you can also hook into Chrome's voice recognition for dictation.

> If we take 'specifications' one level further and actually want our algorithms to be proven correct, as in, by a proof assistant it is quite unclear that this possible or desirable.

It is not only possible, it is how dependently-typed languages/proof-checkers like Agda work.