Readit NewsIt's not easy and the major compositors (Gnome, KDE) are NOT wlroots based, making this point mostly moot anyway.
This protocol at least has a chance of using a custom WM with an advanced compositor (which wlroots is not).
Animations are usually "serial", while (my) thought is usually "fractal"/"parallel", ie. I quickly take in the entire content, and then start focusing on individual parts according to intuitive salience (or other features).
Instead of animations, visual hierarchy / typography etc. is used by professional designers to convey eg. appropriate reading order.
The problem is semantic ambiguity, ie. which sense of a noun/verb (concept/operator/function/relation) is meant. The concepts inside the syntax in the paper are still ambiguous.
Also underspecification in general - having a formal syntax does nothing to address this. Both formal and natural language specifications can and commonly are incomplete.
Don't see anything in this proposal to address that. (and any solution probably applies to natural language syntax as well)
The only problem with (formal) natural language syntax these days is that it's a bit too verbose and harder to read (ironically) compared to more math-y/codey ones.
Or, y'know, use the language you have (JavaScript) properly, eg. add a `sum` abstraction instead of `.reduce((acc, val) => { return acc+val }, 0)`.
In particular, the problem of "all the calculations are blocked for a single user input" is solved by eg. applicatives or arrows (these are fairly trivial abstract algebraic concepts, but foreign to most programmers), which have syntactic support in the abovementioned languages.
(Of course, avoid the temptation to overcomplicate it with too abstract functional programming concepts.)
If you write an XML DSL:
1. You have to solve the problem of "what parts can I parallelize and evaluate independently" anyway. Except in this case, that problem has been solved a long time ago by functional programming / abstract algebra / category-theoretic concepts.
2. It looks ugly (IMHO).
3. You are inventing an entirely new vocabulary unreadable to fellow programmers.
4. You will very likely run into Greenspun's tenth rule if the domain is non-trivial.
The author's approach is really good, and he hits on pretty much all the problems that arise from more naive approaches. In particular, using a perceptual colorspace, and how the most representative colour may not be the one that appears the most.
However, image processing makes my neck tingle because there are a lot of footguns. PNG bombs, anyone? I feel like any library needs to either be defensively programmed or explicit in its documentation.
The README says "Finding main colors of a reasonably sized image takes about 100ms" -- that's way too slow. I bet the operation takes a few hundred MB of RAM too.
For anyone that uses this, scale down your images substantially first, or only sample every N pixels. Avoid loading the whole thing into memory if possible, unless this handled serially by a job queue of some sort.
You can operate this kind of algorithm much faster and with less RAM usage on a small thumbnail than you would on a large input image. This makes performance concerns less of an issue. And prevents a whole class of OOM DoS vulnerabilities!
As a defensive step, I'd add something like this https://github.com/iamcalledrob/saferimg/blob/master/asset/p... to your test suite and see what happens.
> Okmain downsamples the image by a power of two until the total number of pixels is below 250,000.
It does look like more and more apps/tools are going to come built-in with - you can either type or talk - go wild.
Ask: Someone commented some time back that they mapped their CAPSLOCK key to push-to-talk. I’ve looked around and could not figure out without a third party tool. I’d love to know how to do it in macOS - map the un-used CAPSLOCK Key to Push to Talk.
You can still browse it a bit online with some 3rd party sites: https://en-word.net/
(the link is broken though, it should be https://github.com/globalwordnet/english-wordnet)
Nobody in their right mind would publish this to ArXiv. I suggest looking up and reading guides on how to write a research paper.
1. ISPC [1], the Intel® Implicit SPMD Program Compiler also compiles SIMD programs with branches and other control flow efficiently using predication/masking etc.
2. Futhark [2] compiles nice-looking functional programs into efficent parallel GPU/CPU code.
[1]: https://github.com/ispc/ispc [2]: https://futhark-lang.org/