rstarast

There's an active fork of Elm in https://gren-lang.org/.

Hah, memories. I bought my one and only bitcoin from some dude in Munich via localbitcoins back in ~2013. Two weeks later I got a phone call from some Munich police officer asking whether I too was a bank theft victim of that guy. I could explain a bit about what actually happened (police had no idea about bitcoin at the time). It turned out that some money had been stolen via online banking from Spanish bank accounts, and presumably laundered by turning it into bitcoin via my localbitcoins contact.

I have to admit I was a bit disappointed when I scrolled to the end and it didn't turn out this article was written by ChatGPT.

Impressive!

It's lying though when it claims its regexes match the empty parameter cases, right? (The regexes do what's asked, just explanation seems buggy.)

The way this does routing leads to quite hard to read code, compare https://www.okapi.wiki/docs/todo-app:

    todoAPI conn = getTodo conn <|> getAllTodos conn

with

    getTodo conn = do
      methodGET
      pathParam @Text `is` "todos"
      todoID <- pathParam @Int
      ...

so you need to keep in mind both the order of the alternatives in todoAPI as well as the bodies of the individual handlers. That gets unwieldy very quickly.

It also seems likely to lead to the same problems with error handling that you tend to get with combinator parsers, where you usually only get details about the last failing branch, while the interesting failure might have been an earlier one.

Quiz question (I don't know the answer): What happens to a request for /todos/foo?

It seems to address the important problems with Elm, around its overly restrictive project management, by 1. introducing more flexible package management (e.g. you can depend on a fork of a core package, or a private git repo etc.) 2. being open to adding various missing web APIs (e.g. while I'm not sure it's there yet, I expect websockets to make a return, which were dropped with Elm 0.19) 3. generally going for an open development model (even just not having to wait years to fix trivial crippling bugs in the compiler is a step forward...).

The other part is that I have a good impression of the person/people behind it and could see it sticking, for whatever that's worth.

I have high hopes for the young Gren fork of Elm https://gren-lang.org/.

This was a good read! The missing hyperlinks:

- https://man7.org/linux/man-pages/man2/sendfile.2.html

- https://man7.org/linux/man-pages/man2/splice.2.html

(Funny how used I've gotten to "hypertext", I was quite irritated I couldn't click those function names.)

I'd love to work somewhere that uses Zulip over Slack, for the product itself, but particularly because I believe it has a good chance of coming with a more mindful communication approach than your average Slack shop. Anyone hiring?

.xyz domain? Check.

This seems to be largely the same pitch that oscoin.io / monadic.xyz / radicle.xyz had back in 2017. They must have burned, what, 10 million dollars by now? I'm really curious what the business model behind an outfit like this is...

I think I learned how to move my ears once I started wearing glasses -- at some point I was able to actively move them up and down my nose a little through ear movement.

I'm not that sure about "for non-haskell reasons".

Haskell seems to select for people who enjoy going off on puzzling tangents, and it seems like it takes so much learning that for many, meta skills such as good engineering and communication practices fall by the wayside.

(2015)

"Any tips for this tweet will be sent back double!"

Just as a warning if you're considering Guix for server use: Switching generations (e.g., rolling back a system update) requires rebooting to take effect.

That's pretty cool. Feature docs including an example: https://murex.rocks/docs/optional/select.html

So apparently it runs the query against an in-memory sqlite instance. I'm curious what the rough time overhead for that is (compared to, say, the overhead of calling out to grep). Does it feel noticeably slow to run a query on ps output?

And the other thing I'm wondering, can this drop you into a sqlite command line? I.e.,

» ps aux -> select -i

sql> SELECT ...

UK started in December with Pfizer/Biontech, AZ since roughly 2021 I believe.

EDIT: removing link to lifesitenews com article, don't want to give them traffic.

+news/rms.md

Oh boy.

How far do we think human drivers' safety level ranges? Like most drivers I'm falsely convinced I'm a safer driver than most, but still I expect quite a large range (say a factor 10 between 10th and 90th percentile?). It seems reasonable for self-driving cars to be expected to improve safety over human driving for the large majority of drivers, not just half of them.

Oh, curious. I guess the data used by openrouteservice.org might be a bit stale. There was an edit three weeks back: https://www.openstreetmap.org/changeset/95556786 "the section is practically impassable, this is no longer a road"

For what it's worth, OpenStreetMap has a section of it as a "track" with "very_horrible" smoothness, but openrouteservice routes that way anyway: https://maps.openrouteservice.org/directions?n1=61.559148&n2...

With files not identified by file name, I'm curious whether pijul is able to reconcile two independent additions of the same file. I suppose there'll have to be some custom logic to deal with this kind of conflict? E.g.:

Alice creates change

A: add file /README (identified by hash x)

Bob creates change

B: add file /README (identified by hash y) C: adds a copyright header to README

Now Bob pulls from Alice, and wants Alice's README contents (change A). Does pijul notice conflicts between A & B? If Bob records a change resolving the conflict between A & B by keeping A, will it be possible to apply C on top of this?

Putting your personal categorization number into the email subject is such a monumentally bad idea...

Might help to adapt level selection to how quickly levels are being solved.

> I built something better that's actually secure and performant here

That's quite a bold claim, isn't it? I also don't see how it's an alternative to OP considering it doesn't even mention how to integrate the code with any database, let alone Postgres.

As an aside, how does your approach deal with collisions? Why would the chance of collisions be any lower than with the random approach if you're using what seems to come down to a cryptographically secure hash function?

This stackoverflow answer to a related question gives a better suggestion https://stackoverflow.com/a/6955055/3403369:

Create a separate table mapping integers to unique IDs, and join with this. You can generate that in advance, so can avoid gradually building the index.

Use integers as primary keys and don't expose them, and add a (unique) random ID column that's used to interface with the rest of the world.

(I understand there'll still be an index for the public key -- the argument would be that you don't bear the cost for that for most queries.)

Impressed by the speed of the results. Some of my more obscure tests didn't give relevant results, but I guess this is still early on. Do you have any numbers about the size of the index, and where you're aiming to go?

My big question: What's behind the name? I find it a bit confusing and not very memorable at first sight, maybe an explanation would help.

I hoped to find a TLDR in the non-discussion version: https://urbit.org/blog/precepts/

But that's also too long and meandering. :/

The one potential effect of this that I'd love over git is being able to check in local changes that I never intend to upstream. E.g. I could have a local change adding some editor config files, or modifying some compiler flags in the Makefile to suit my local config.

With git my typical solution for this is to basically keep rebasing them as uncommitted changes with `git stash`, until I inevitably lose them. Or keep a separate branch, and keep explicitly rebasing (and stay on my toes not to accidentally push the commits).