HPy on CPython uses the existing C-API under the hood, so there is zero need to build up some keep someone out...
1,085 karma · joined November 27, 2014
HPy on CPython uses the existing C-API under the hood, so there is zero need to build up some keep someone out...
- OTP27 added sigils[0], which allow you write UTF8 strings with just an additional tilde character
~"hallöchen" =:= <<"hallöchen"/utf8>>
- Also, since OTP27, Erlang's own documentation[1] is written in Markdown and created using ex_doc[2]
- doc attributes etc. have been added in OTP27 as well, I think
- You can use ex_doc in your own Erlang projects using rebar3_ex_doc for a while now[3]I also miss the pipe operator, but there seems to be some opposition against it in Erlang-land (and it would need to be adjusted as Erlang's standard library doesn't put the "main" argument consistently in the first argument slot like Elixir does).
[0]: https://www.erlang.org/blog/highlights-otp-27/#sigils [1]: https://www.erlang.org/doc/readme.html [2]: https://hexdocs.pm/elixir/writing-documentation.html [3]: https://hexdocs.pm/rebar3_ex_doc/readme.html
Quite obvious, if you scroll to the "Getting Started" section.
The code would have looked just as correct and would have been just as wrong with the "old" non-sigil `try!(...)` syntax.
That also gives the allocator the flexibility to use part of a block that it gave to you for someone else if that makes sense.
E.g. you request 200 bytes, a block of 256 bytes is actually allocated. Now you request with some other code 30 bytes. If the allocator had told you at allocation time "here are your 200 bytes, but just so you know, there's another 56" it could not hand the unused part of the 256 bytes to the next allocation.
When the Touchpad was firesaled, I got one and was disappointed with the PDF viewer. Because there was no such thing as WASM (or even asm.js) at the time, it used out of the box a service provided by Adobe that on request from the UI rendered tiles of the PDF at different resolutions, depending on the zoom level.
Since the frontend code was JS, it was easy to implement an alternative via mupdf (https://github.com/filmor/webos-pdf/blob/master/arxservice.c...). Via the same inefficient process (rendering png tiles onto the filesystem), the mupdf implementation was about 3 times faster than the original (though, it's been 13 years, the actual speedup might have been less :)).
Lennart Poettering stated on a mailing list that e.g. libselinux als links liblzma and ends up in a lot of services on SELinux-enabled systems.
https://www.worlddata.info/america/uruguay/energy-consumptio... (3.4 MWh) https://www.worlddata.info/america/brazil/energy-consumption... (2.5 MWh) https://www.worlddata.info/america/argentina/energy-consumpt... (2.6 MWh)
.expect("should have opened file")