andrus

GitHub introduced checksums to their tokens to aid offline secret scanning. AFAIK it’s mostly an optimization for that use case. But the checksums also mean you can reveal a token’s prefix and suffix to show a partially redacted token, which has its benefits.

Yes, this is valid JSON: []

Don’t recent Node.js releases support this already? require(esm) was back ported to Node.js 20 in February

I’ve found it hard to apply this pattern in Go since, if Username is embedded in a struct, and you forget to set it, you’ll get Username’s zero value, which may violate your constraints.

AFAIK, Twilio is shutting down its Video product. I don’t think its Voice product is affected (although the SDKs for both use WebRTC).

> That said, do many see value is in this?

GitHub don't host runners for Linux × arm64, so if you need this, you need to self-host. You can also run custom AMIs with pre-installed packages, which can speed up workflows that depend on those packages.

> When things go wrong, you need people going through logs working out that there's nothing actually wrong with CI…

I'm on a small team who've been running the Philips Lab self-hosted runners for the past year. It hasn't been difficult to operate. Once deployed, it pretty much "just works".

In my experience, the things that go wrong originate from the GitHub workflows themselves. We usually have to review workflow logs regardless of whether the workflow uses a self-hosted runner or not.

Hey, you're welcome! And actually, yes — I reached out to @duvallj from GitHub regarding this earlier today. He has my original email, or you could email me at my address in my HN account info.

Yw! I'm hard at work on https://www.propeldata.com/, but always curious to see what's going on in the WebRTC space :-)

This is very cool to see. I haven't been able to work on or maintain node-webrtc since 2021, but I'm glad people still find these bindings useful.

    app : Vect n a -> Vect m a -> Vect (n + m) a

is a type signature for a function, `app`, which should append a vector (`Vect`) of length `n` to a vector of length `m`.

What's cool about Idris and other dependently-typed languages is that the length of the resulting vector, `n + m`, can be tracked in the type. This can prevent a whole slew of errors.

The theory here is good, but I think the implementation is lacking. Haskell's QuickCheck is one of the most mature frameworks for doing what the author calls "data-driven testing", so It might be worth mentioning one of the JavaScript ports compatible with Mocha: node-quickcheck, JSCheck, etc.

ORTC can interop with WebRTC, so you could create a an Edge to Chrome or Edge to Firefox scenario. In fact, you can implement (to some degree) the WebRTC APIs in terms of the ORTC APIs.

CSCI 0911 and CSCI 0912 are real, though they go by CMSC-16100, CMSC-22311, and CS240h (and I'm sure more).

So do I pass CSCI 0555? ;-)

Yes, Fantasy Land is a specification of Monad (as well as other type classes) for JavaScript:

https://github.com/fantasyland/fantasy-land

I am glad the docs have improved. For example, RoutingRules: you used to have to go to the code to figure out how to use them.

I think the confusion stems from the fact that .then() acts like either .map() or .flatMap() depending on the return type.

If .then() was just .flatMap(), you could expect an error if you didn't return a Promise (for example, reject with a TypeError).

If .then() was just .map(), you could return a value of any type (for example, string or Promise<number>) and get back a Promise for a value of that type (Promise<string> or Promise<Promise<number>>).

Why is this called "SYRO"? Confusing considering the recently-released Aphex Twin album...

Relevant discussion on LtU: http://lambda-the-ultimate.org/node/678

The EitherIO data type given is

  data EitherIO e a = EitherIO {
      runEitherIO :: IO (Either e a)
  }

But, for the sake of clarity, it can be written as

  data EitherIO e a = MakeEitherIO {
      runEitherIO :: IO (Either e a)
  }

The author pointed out two functions that this EitherIO declaration gave us. One is a constructor, MakeEitherIO, with type

  IO (Either e a) -> EitherIO e a

In other words, MakeEitherIO takes a value of type IO (Either e a) and returns a value of type EitherIO e a (you could think of this as "wrapping" the original IO value).

The second function, runEitherIO, is an accessor function for EitherIO's named record field "runEitherIO". It has type

  EitherIO e a -> IO (Either e a)

That is, runEitherIO takes a value of type EitherIO and returns the internal value of type IO (Either e a) (you could think of this as "unwrapping" the IO value).

I hope that helps!

Google "haskell rest". Done. See @sfvisser's comment: https://news.ycombinator.com/item?id=7965468

No, "automatically unboxing the promises that are returned" does not give Promises "the full power of Monads", because you cannot represent a Promise for a Promise for a value. Promises/A+ breaks parametricity.

The Promises/A+ assumption that you'd never want a Promise to return a Promise is really shortsighted.

Neat, I knew about `:set +m` for enabling multiline input, but not `:{ ... }:`.

Just for grins:

    $ alias sum="xargs | tr ' ' '+' | bc"
    $ echo -e "1\n2\n3\n" | sum
    6

Actually, he was in normal mode and issued

    5dd

at the start of the block.

Would like to know whether the author feels his rewrite is more successful than the original. The following takes me longer to read:

    for (
                              ;
            (*to = *from) != 0;
            ++from, ++to
        )
        ;

Whereas the idiomatic version seems simpler:

    for (; (*to = *from) != 0; ++from, ++to);

We have vending machines with these at my university. I often start swiping my card only to realize I've accidentally "tapped to pay" (according to the reader).

I picked up a Samsung ARM Chromebook two weeks ago, installed both the latest Secure Shell and the Development version. Neither worked :-/

Crouton is actually a breeze to use. While the crouton script itself might have a few hacks under-the-hood, the end result is quite slick. Everything just installs under `/usr/local/chroots'. Removing one of your potentially many chrooted installs is just an `rm -rf'.

I prefer keeping ChromeOS primary and just opening a crosh window to expose one of these chroots (a browser and terminal is similar to my work environment on a Mac). Granted, XFCE can act weird if you choose to launch it, but I've never needed that functionality.

If you do want to completely replace ChromeOS, there's Chrubuntu.

I'm surprised the ARM Chromebook shipped without any mechanism for indicating which apps in the Chrome Web Store are compatible with it (maybe they expected PNaCl to be completed?). Moreover, I had no idea what NaCl was until Secure Shell stalled and I tracked down the bug on a mailing list.

There's an enable "Portable Native Client" (PNaCl) in about:flags (dev. branch, at least), but I have little idea if this would fix the problem. This kind of troubleshooting is OK for power users, but seems at odds with the type of users ChromeOS wants to attract. Still love this machine, though.