tooker

I read the entire thing and still can't tell if this is a joke.

Reminds me of http://www.realultimatepower.net/

Author note: Hopefully you have fun with this. You can compare the performance of your phone to your workstation on any architecture. I'm having fun learning about WASM performance and loving that Firefox is somehow the BEST WASM engine in the game right now. Super fun!

I use MDN heavily every day and this is really depressing. When I first landed on a fresh page today I thought I'd clicked on the wrong link and got some low-rent MDN knockoff by accident. It instantly looked cheap and jarring on a squint test.

Also, why is everything error-toned? Red is a danger color and invokes negative emotion almost universally. Red MDN!? Really?

I'm a browser extension developer and I'm strongly considering burning a week to write an extension to fix this.

Could not agree more! Firefox begining to support V3 is also extremely troubling; regardless of the compromises they are offering for adblockers. We need to resist this.

V3 is a cancer. As a full time extension developer I am dreading the notion of chrome successfully deprecating V2. Hopefully developers can rise up against V3 before it's too late.

Go Jonathan!

Netscape ran on Unix platforms.. buggy or not its support was vastly more important than IE on an ethical level.

Bravo

THIS * 1000

https://forsta.io is missing.

It's agnostic. Really any person/agency that wants E2E messaging but with some e-discovery capabilities done in a decentralized fashion.

It's ported directly from the javascript lib so most of the interfaces are exactly the same (async differences in some cases and a couple storage interface differences, see: <https://github.com/ForstaLabs/libsignal-node/issues/1>). The commit history is intact as well. Haven't had enough time to port tests but she works.. We use it for various bots in our signal based message platform.

The C components are just a few emscripten compiled curve25519-donna and ed25519 functions for elliptic curve routines. It comes directly from the web library without any alteration. Honestly I was surprised at how well it works and the performance isn't too shabby. I did several investigations of replacing it with libsodium and others but the the emscripten builds have been pretty reliable for us..

It used to irritate me having to use alternative grammar for accessing values in a mapping vs accessing object attributes. However this is an area where I learned to appreciate Python's hardline on consistency. Guido in particular has been responsible for keeping the language predictable and concise by disallowing patterns like this in the language itself. So on one hand it's beautiful that it's so easy to implement things like this (which I am guilty of doing too), but on the other it is a perversion of the intentional distinction between attributes and mappings.

I've since learned to love the distinction between object attributes and items in a mapping and happily implement ['this style'] accessors without complaint now.

That being said, if the library just did difflib.get_close_matches() on the key lookup that would be neat for some use cases where you want fuzzy keep lookup.

That's almost exactly the use case I began with. It unapologetically requires python 3.5+ but if you're already there I'd be happy to see and support some of your use cases. Hit me up on github if you want to try it and need some guidance (the docs are nonexistent).

I have a library for doing coordinated async IO in python that addresses some of the scheduling and resource contention issues hinted out in the later part of this post. It's called cellulario in reference to containing async IO mechanics inside a cell wall..

    https://github.com/mayfield/cellulario

And an example of using it to manage a multi-tiered scheme where a first layer of IO requests seeds another layer and then you finally reduce all the responses..

    https://github.com/mayfield/ecmcli/blob/master/ecmcli/api.py#L456