HackerTrans
TopNewTrendsCommentsPastAskShowJobs

blux

no profile record

Submissions

Laid Off After 25 Years in Tech: Anxiety, Sacrifice, and Reality [video]

youtube.com
3 points·by blux·6 months ago·0 comments

Fastmail breaks UI in production

twitter.com
34 points·by blux·11 months ago·51 comments

Hiker discovers first trace of entire prehistoric ecosystem in Italian Alps

theguardian.com
2 points·by blux·2 years ago·0 comments

comments

blux
·last month·discuss
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!
blux
·8 months ago·discuss
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.
blux
·9 months ago·discuss
[flagged]
blux
·last year·discuss
Seems he is using trade deficit percentages in his chart instead of tariff percentages ... :/
blux
·last year·discuss
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.
blux
·last year·discuss
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.
blux
·2 years ago·discuss
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.
blux
·2 years ago·discuss
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
blux
·2 years ago·discuss
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).
blux
·2 years ago·discuss
I implemented GJK almost a decade ago now based on this excellent explanation from Casey: https://www.youtube.com/watch?v=Qupqu1xe7Io
blux
·10 years ago·discuss
See for example: https://awhan.wordpress.com/2010/04/28/urxvt-tabbed/

Configuration is done through ~/.Xdefaults.
blux
·10 years ago·discuss
urxvt supports tabs as well.