blux

I have read 'C++ High Performance', and I recommend to avoid it unless you are interested in reading an STL reference guide with only minimum hints on performance sprinkled in left and right. Or unless you do not know that `std::move` will avoid a copy in some cases, etc.

In short, overpromises, underdelivers.

Hey fellow TU/e'er :) I followed his course as well, somewhere around 2004/5. Executing man in the middle attacks, writing buffer overflow exploits. Good memories!

Could not agree more.

As a child in the 80s I read a programming book (can't remember the name anymore unfortunately) where the reader was encouraged to write software that is always friendly and human when it comes to communicating with the user. For example, 'Please input a number:' instead of 'Input a number:'. But also exactly the thing the writer talks about in the article; do not be lazy when it comes to pluralization.

I get nostalgic remembering that era in computing.

Seems he is using trade deficit percentages in his chart instead of tariff percentages ... :/

Could have been if backwards compatibility was not a thing indeed.

Move constructors are not needed, they don't solve a 'problem', but improve on previous semantics.

This is becoming such a tiresome opinion. How are concepts fixing a problem created by previous features to the langue? What about ranges? Auto? Move semantics? Coroutines? Constexpr? Consteval? It is time for this narrative to stop.

AFAIK, 250W is the net energy of light arriving at the wafer after it has reflected off of many mirrors, with a very inefficient process to generate light from the tin plasma on top of that.

I wrote this library once; https://github.com/ton/fast_int.

Removed `std::atoi` from the benchmarks since it was performing so poorly; not a contender. Should be easy to verify.

Rough results (last column is #iterations):

  BM_fast_int<std::int64_t>/10                  1961 ns         1958 ns       355081
  BM_fast_int<std::int64_t>/100                 2973 ns         2969 ns       233953
  BM_fast_int<std::int64_t>/1000                3636 ns         3631 ns       186585
  BM_fast_int<std::int64_t>/10000               4314 ns         4309 ns       161831
  BM_fast_int<std::int64_t>/100000              5184 ns         5179 ns       136308
  BM_fast_int<std::int64_t>/1000000             5867 ns         5859 ns       119398
  BM_fast_int_swar<std::int64_t>/10             2235 ns         2232 ns       316949
  BM_fast_int_swar<std::int64_t>/100            3446 ns         3441 ns       206437
  BM_fast_int_swar<std::int64_t>/1000           3561 ns         3556 ns       197795
  BM_fast_int_swar<std::int64_t>/10000          3650 ns         3646 ns       188613
  BM_fast_int_swar<std::int64_t>/100000         4248 ns         4243 ns       165313
  BM_fast_int_swar<std::int64_t>/1000000        4979 ns         4973 ns       140722
  BM_atoi<std::int64_t>/10                     10248 ns        10234 ns        69021
  BM_atoi<std::int64_t>/100                    10996 ns        10985 ns        63810
  BM_atoi<std::int64_t>/1000                   12238 ns        12225 ns        56556
  BM_atoi<std::int64_t>/10000                  13606 ns        13589 ns        51645
  BM_atoi<std::int64_t>/100000                 14984 ns        14964 ns        47046
  BM_atoi<std::int64_t>/1000000                16226 ns        16206 ns        43279
  BM_from_chars<std::int64_t>/10                2162 ns         2160 ns       302880
  BM_from_chars<std::int64_t>/100               2410 ns         2407 ns       282778
  BM_from_chars<std::int64_t>/1000              3309 ns         3306 ns       208070
  BM_from_chars<std::int64_t>/10000             5034 ns         5028 ns       100000
  BM_from_chars<std::int64_t>/100000            6282 ns         6275 ns       107023
  BM_from_chars<std::int64_t>/1000000           7267 ns         7259 ns        96114
  BM_fast_float<std::int64_t>/10                2670 ns         2666 ns       262721
  BM_fast_float<std::int64_t>/100               3547 ns         3542 ns       196704
  BM_fast_float<std::int64_t>/1000              4643 ns         4638 ns       154391
  BM_fast_float<std::int64_t>/10000             5056 ns         5050 ns       132722
  BM_fast_float<std::int64_t>/100000            6207 ns         6200 ns       111565
  BM_fast_float<std::int64_t>/1000000           7113 ns         7105 ns        98847

Did you verify their claims or are you just calling BS and that's it? The new functions are in fact much faster than their C equivalent (and yes, I did verify that).

I implemented GJK almost a decade ago now based on this excellent explanation from Casey: https://www.youtube.com/watch?v=Qupqu1xe7Io

Ok, I'll bite. What happened at Canonical?

I did not know about `includeIf`...this allows getting rid of the hacks I used to achieve something similar, great!

There are so many examples in the insect world of mind control its truly bizarre.

The other day I encountered an example in David Goulson's recent book Silent Earth (https://www.goodreads.com/book/show/56470413-silent-earth) that I did not know yet about; the emerald cockroach wasp (ampulex compressa).

Rough transcription; for its reproduction, the wasp injects a cockroach with poison to paralyze it, then stings it in exactly that part of the brain responsible for its flight reflex to make it docile. After knibbling a bit on the cockroach's antennae and enjoying the hemolymph seeping out of the cockrach, the wasp takes the cockroach by its antennae and, even though it is much bigger than the wasp, directs it to its nest like a dog on a leech. In the nest of the cockroach the wasp lays an egg, which soon hatches a larvae that in turn proceeds to eat the cockroach alive while it is still dazed...And this is just the top of the ice berg.

I'm not sure why you are downvoted; I have the exact same on an up-to-date Firefox.

I didn't know about `jump`, that is super useful.

For the text rendering part, is there no off-the-shelf library that provides that functionality?

This times 100 :)

It is only recently that I started to realize this and once you do it makes a lot of sense.

Does anyone know what happened with Herb's idea for zero-overhead exceptions?

I remember liking the idea when he presented it at CppCon (https://www.youtube.com/watch?v=ARYP83yNAWk).

I'm wondering, when will programmers be replaced by AI?

Or less strong, when is the fun, creative job of programming replaced by entering queries for some AI code bot?

I've always argued that that time is still a long way off, but seeing these advanced makes me less confident...AI is evolving so so rapidly. I hope I can make it to my pension as an old-school programmer!

Same here, computer flagged, nothing happens.

I fail to see the point of this, in fact, I think this is a fundamentally flawed approach to dealing with your revision history. The problem is that rebasing commits has the potential of screwing up the integrity of your commit history.

How are you going to deal with non-trivial feature branches that need to be integrated into master? Squash them and commit? Good luck when you need to git bisect an issue. Or rebase and potentially screwing up the integrity of the unit test results in the rebased branch? Both sound unappealing to me.

The problem is not a history with a lot of branches in it, it is in not knowing how to use your tools to present a view on that history you are interested in and is easy for you to understand.

It doesn't really mean anything, it is just a modern thing to say when announcing a software project.

I implemented GJK years ago based on a nice presentation by Casey Muratori: https://www.youtube.com/watch?v=Qupqu1xe7Io

To me it's surprising and unsettling to see how small the market share of Firefox has become.

The logo on the title page works for me too, but none of the examples do.

Yes, there is, to block this by default, set 'permissions.default.shortcuts' to 2.

I just found out that doing that does not prevent shortcuts from the extension to work contrary to what I just posted although I'm sure that when I tested this yesterday it did...:) So this is a step in the right direction.

Then I'm still left with sites stealing focus preventing shortcuts to work. Even though Vimium has an option to prevent sites from doing it, it is not fool proof. YouTrack/Upsource for example insist on stealing focus, so when I'm happily switching tabs using shortcuts as soon as I stumble upon YouTrack/Upsource I have to grab the mouse again :'(.

Hear hear, the shortcut stealing is so annoying. Github for example does this; Ctrl-k is some search within Github instead of focusing the search bar in Firefox.

Then we have this option to disable shortcuts in sites which fixes this, but that also disables all shortcuts of the Vimium extension...I want to use an extension like Vimium so badly and its almost there but these little things make it that in the end the whole extension is unusable.

"...means things break often..."

Citation needed. I can provide some anecdotal evidence to the contrary; I've been running Arch both privately and professionally now for about 15 years and sure there were some issues initially but the last decade or so I've been updating my systems fearlessly on a regular basis.

Why can't we have something like Linux in the web browser world? A web browser built by the community that does not depend on a big bag of money for its continued operation.

Surely writing an open-source operating system that drives the world cannot be harder than writing a web browser? Or am I missing something?

I disagree, I think that is just the way idiomatic C code looks like and should look like. A post incremented dereferenced pointer for example is an idiom, it is so common that at some point you will immediately recognize it for what it is. These idioms keep the code concise, which has a lot of value in itself, since they make it easier to recognize what the code is all about instead of figuring out code that essentially expresses the same intent but does it in some non-idiomatic way. They are like chords in music, standard positions in chess, etc.