oflebbe

I am really looking forward for using better elevation data. So important for bike planning.

Websites built with tons of polyfills are likely not run on these devices anyway, since they will run out of RAM before, let alone after they will only load after sone minutes because of CPU limitations on top of not being loaded because their x509 certs are outdated as well as the bandwith they support is not suitable to load MB sited pages

Actually the author is building onto my suggestion https://github.com/soasis/idk/pull/17/files which I created several years ago, but adapted a bit too fast while submitting. And yes it looks very similar to GNU nested functions, since I started tinkering with these first.

I am really not sure if all these observations mentioned in the article are 100% correct, though.

First : Code seems to be compiled with clang. On Linux with gcc the native function one is way faster than the clang one.

Second: The author does run the code on ARM64/MacOS .

At least on my ryzen CPU on Linux with gcc the "normal C code" is way faster than anything else. Not that we do not need to thing about "closure" type functionality, but one should be careful to extrapolate implementations from one compiler on one platform to the rest of the pack.

Regarding N3654 I am not sure how to benchmark it here, since C could potentially use __builtin_call_with_static_chain , but I am not sure how to write the function to use the chain for accessing the variables.

I tried to estimate N3654 it by using "tinygo" which is AFAIK using the usual Calling ABI, but it was a factor of two slower than clang. Even "go" with its very specific ABI is still much slower. I discovered this isn't representative since runtime calling costs had been totally shadowed by costs of allocations.

Even the rust example I am usually using http://www.reddit.com/r/rust/comments/2t80mw/the_man_or_boy_... is much slower than anything else, presumably because of the "Cell" needed

TLDR: This micro benchmark might be misleading

I had the chance to test Moment while my Widex Evoke 440 had been in repair. They are indeed a lot better as the Evoke, sounding wise, while having only mild hearing loss. But they are still only MFI (can only connect to an iphone) and since I am migrating away from Apples ecosystem this will be a blocker.

You can sideload apps in ios too, but you may not run it.

I think I will love FORTRAN again

I played with fyne some months ago. Binaries are gigantic and what does drive me crazy it is consuming cpu all the time even if it should stay idle

OpenMP to the rescue

I know about systems who had two types of serial numbers which ought to be the same, but weren‘t because they had been programmed at different eol stages, when daylight savings time kicked in. One of the system run in utc the other in local time. Date was part of the serial.

No Teams meeting with video on Linux any more.

this!

Wait what? This is an blogpost from Chen? I did remember reading better quality content before. This is the usual nightmare dealing with larger C++ codebase.

But you may not have access to API capabilities needed without an paid account.

Only that there is no official mmap support in go, due to gc concerns, afaik

Next: systemd for windows?

At least previous versions of graphhopper do work on android. Had no chance to test graphhopper 8.0, though. Just use the maven artifacts.

For ios you can find projects to transpile to ObjC within the graphhopper project. YMMV

Had an Sharp MZ-731 back in the days. I was able to exchange data with an Sharp MZ-80K from a friend by changing the baud rate of the recording. IIRC Sharp MZ 700 was faster, you could actually hear the different pitch on an audio cassette player.

using an external monitor on an m1 pro at work.

+1 for explaining kerr singularities

if your only tool is a hammer, every problem looks like a nail.

it builds single binaries even for other processors like arm, arm64.

i miss epoc32 source

I remember occasionally contributing to libc at that time. libc4 was a.out, at least that was the name I remember. libc5 was the first ELF libc and libc6 is glibc.

Somehow Xenix is not mentioned

i would recommend to check with archive.org, if the books are already available online and if not if they are interested scanning or get the scans.

Wow this is 25 years ago? I can vaguely remember when Eric Youngdale approached libc's HJ Lu to fix shared libs by not reinventing the wheel but using Sys V ELF. Great article by Eric back than https://www.linuxjournal.com/article/1060 .