tjelen

This one is basically my daily driver for similar tasks: https://app.heynote.com/ (full app at https://heynote.com/). And it seems to work almost out-of-box for your first two examples, once you switch the buffer from "Plain-text" into "Math" mode.

It also supports switching between different buffers and some kind of local storage.

Umm, yes? Not sure about the rest of Europe, but here in Czechia most of merchants have a direct payment method based on QR code.

Basically: 1) you select your bank at the checkout; 2) you're redirected to the bank's payment page with a QR code; 3) you scan the code from your banking app and confirm it; 4) the bank redirects back the merchants page with the payment status confirmed/declined. No payment processor involved and the money goes straight from your account to merchant's account.

I would say that the problem really is there. Dealing with native dependencies and addons was almost always a pain as the article describes (and not just from developer perspective), so anything that helps there is really appreciated.

Not sure what you mean by the right tools in this context.

Code testing is a big one for me. I'm currently using in-memory sqlite for tests and I'm often running into differences between sqlite and postgres (default values, JSON handling, etc). This could allow me to use the real thing without running a full Docker instance.

What I meant to say is that this definitely isn't a safe assumption and performance of this loop will be less predictable. That said, I wouldn't be surprised that such complex JITs as V8 or JSC can detect this scenario.

That's a really good point and I think that in this sense the comparison is really made between Rust and JS rather than between WASM and JS (as others have complained).

The innermost rendering loop in the JS seems to create and destruct an array instance for every single pixel iteration (see https://github.com/dmaynard/chaos-screen-saver/blob/master/s...). I guess that this could be potentially optimized away by the JIT, but it will make things slower or at least less predictable.

It has been reported by a major Czech newspaper (it is originally a Czech project): https://domaci.hn.cz/c1-67066670-fiktivni-eshop-se-zbranemi-...

And all that is just for being able to write `response = await fetch(...)` instead of `fetch(...).then(...)`.

https://www.pine64.org/pinetime/ maybe?

Isn't it already supported backend in LLVM? https://github.com/llvm/llvm-project/tree/master/llvm/lib/Ta...

I mean it is still under development but I think it is usable. Here's a quick intro I found some time ago: https://dassur.ma/things/c-to-webassembly/

And at the same time they recommend using UAs to detect agents incompatible with SameSite=None cookies (see https://www.chromium.org/updates/same-site/incompatible-clie...), including certain Chrome versions.

Yeah, I'd say that it's actually pretty good result. Too bad that the benchmark doesn't include any non-browser WASM runtimes, like Wasmtime or Wasmer.

So why not just write the original formula into the comment above the code? Maybe it's not the purest approach, but it sure would help parsing the code in this case.

In my experience, it's better to create a "request context" at the beginning of handling a request and pass it down explicitly to subsequent async calls that handle the request. I think that this approach is similar to Golang's "context" package, for example.

As other commenters note, using CLS (via async hooks or domains) is often too much magic and can possibly cause leaks or at least it results in program logic that's hard to reason about and hard to test.

I think that the AssemblyScript project is halfway there. It compiles a stricter subset of Typescript to webassembly format, which can be then translated to CPU-specific machine code.

That's quite a misleading link - "Mladi zeleni" are not the Green party.

Re 1: Isn't Android One that version?

If I remember it correctly MPEG-2 patents are supposed to expire this year. So maybe it's time for JSMPEG2? (Ok just kidding, the whole MPEG-2 spec looks huge).

TheVerge has a nice hands-on video of the prototype, which I think explains the whole thing better than the official website: https://www.theverge.com/circuitbreaker/2017/2/27/14737824/s...

I like the projector mode a lot.

The Webkit/PhantomJS PDF export actually supports SVG embedding (as real vectors), Webfonts and many other things.

It's possible to create pretty advanced layouts with maps, graphs using that. Even embedding IFrames with e.g. Google Maps works.

Here are some issues that I've seen becoming important when scaling to a higher traffic with both MySQL and PostgreSQL (we're running both for different kinds of databases). Some of this is second-hand from my colleagues, so it might not be exact:

* Thread-per-connection (as opposed to process-per-connection with PG) means much lower memory overhead with many concurrent connections; with PG you might need to use something like pgbouncer, which doesn't come without its own issues.

* Logical replication; the MySQL format is compatible between minor release versions (e.g. between all 5.x releases), which enables upgrading individual replicas or master without complete shutdown. With PG this often a becomes way more complex.

* Better caching/buffer management. Essentially, InnoDB has its own implementation of LRU cache while PG relies on kernel page cache. This generally allows finer tuning on the database configuration level and you don't have dive into kernel page cache tuning (which will be always OS-specific).

EDIT: most of this stuff is probably even better described in the Uber article, linked in other comments here.

Is there a way to remove this library (like de-register its event handlers etc) once it has been activated somewhere on the page?

The reason I'm asking is that I've often ran into problems with similar no-dependency libraries in highly dynamic environment, that they often leave dangling event handlers on elements, that have been since removed from the page. That leads to various memory leaks and weird bugs.

I think the page is just down at the moment. Even when using curl it doesn't return anything.

On the other hand, I remember that there were lot of Czech companies that were privatized into Czech hands and most of them do not exist anymore, because they went bankrupt a long time ago.

At the time (during the 90s), most of those companies that had foreign investors/management grew and survived and those that didn't were often tunneled-out by a corrupt management and were closed down. There were definitely some pretty big cases in 90s. Also there was a big public discussion about this at the time, and many politicians were against the foreign investments in general.

So I simply don't think that it's so clear-cut issue and that it's not like most of Czech people are completely unaware of the problem.

So here's what's happening:

- you can't push to https://git.heroku.com/ (expired cert)

- you can push to ssh://git@heroku.com/; it seems to fail but the deployment actually goes through (I'd advise against trying that though).

- the status page is gone

This is very nice. I'm experiencing some problems taking the picture directly by the camera (Nexus 5; 6.0.1). It takes a picture but the picture is empty or broken (but still shows up in the gallery). As a workaround, it's possible to make pictures by the default Camera app and then select the picture from the gallery.

Anyway, I think it's quite useful and surprisingly precise (+/- 1%). If I may make a feature request, I'd like to see more reference sheet sizes, e.g. the full A0-6 range.. :)

This look really great, thanks! Any ideas how to connect it with JSX code? Is it possible to use it with the JSXTransform from React v0.13 or is there any other alternative (and preferably lightweight) JSX transformer that is not Babel?

Which is an alpha-version feature of a service that's currently in private beta. Looks great and I'd like to try it out, but currently I can't. (edit: missing word)

Thanks for the link. I think that just looking at the "simple" triangle example tells quite a lot about how low-level the API is (at least for me). The source C++ file is >27kB and ~760 LOC..