jepler

My mind just balks at the idea of having so much source that a 2020s computer could take hours to index it. ctags is nothing special (both in terms of optimization but also the level of detail it gets to: just global function identifiers) and looks like it runs at about 400MB/s on a single core of an i5-1235U. But still it looks ctags could process about 100TB in 4 hours across 16 threads on a workstation class CPU...

I wonder whether you still have a bug. It depends how "scanning" is implemented.

    23:55 start scanning
    23:59:59 message added
    00:00:01 perform timestamp check

If there is the possibility of a message being added very late, and either being omitted from the scan that started earlier, or a delay from finishing the scan to performing the timestamp check, you might still miss a message.

You also mentioned a directory being created 5 minutes early: what if some system has a clock skewed the opposite way, and puts a message in a directory 5 minutes late instead?

I don't know Haskell, so I can imagine if you didn't know Python it'd be "greek to you" (unintelligible). I'll try explaining in prose what I did. [note: I also edited the grandparent comment because when I simplified the session I showed, the assignment of "s" ended up out of order]

I use the Python decimal package to calculate 17^(1/7) to 4000 decimal places. I show the first 12 characters of the ASCII representation ("1.4989198720"), then take the first 1000 characters after the decimal place. I show the first and last 10 characters of this string ("4989198720...6163659068") so that you can verify it against the string you are testing.

Then I use a list comprehension to check each 3-digit string (e.g., 001, 002, 003, ..., 999) to find out whether it is a substring of the concatenation of `s` with itself, and list the ones that don't appear. I manually abbreviated the list, but I'm saying that in my string, 000, 002, 004, 005, 009, [and some other numbers], 993, 994, 995, 998, and 999 did not appear. (The concatenation `s+s` is checked so that the subsequences that occur at the wraparound---here,684 and 849---are found)

Because some of these length-3 sequences are missing, to my understanding this does not constitute a de Bruijn sequence of order 3 on a size-10 alphabet. However, I'm also not entirely sure whether this is what you were claiming.

assuming you mean the decimal expansion and a length-3 de bruijn sequence on 10 symbols, I am not seeing it. There seem to be many sub-sequences which do not appear. (assuming that python's Decimal library at a precision of 4000 digits is actually giving the first 1000 digits correctly; though I have no reason to doubt this I don't know for sure the maximum ULP error of exponent)

    Python 3.11.2 (main, Sep 14 2024, 03:00:30) [GCC 12.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from decimal import Decimal, getcontext
    >>> getcontext().prec = 4000
    >>> d = 17 ** (1 / Decimal(7))
    >>> sd = str(d)
    >>> sd[:12]
    '1.4989198720'
    >>> s = sd[2:][:1000]
    >>> s[:10], s[-10:]
    ('4989198720', '6163659068')
    >>> [i for i in range(1000) if "%03d" % i not in s+s]
    [0, 2, 4, 5, 9, [...], 993, 994, 995, 998, 999]
    >>> len(_)
    361

Too tired to find the actual debunking of these claims but no, d-wave is not effective for cryptanalysis of RSA or AES as deployed.

The papers claim some interesting but not game-changing results on factorization of tiny primes and attacking toy, reduced round cryptosystems that resemble AES in a particular way.

Anil is a given first name, maybe just not in your culture.

You don't need machine code these days to find overflow in IEEE floating point arithmetic.

If any intermediate sum overflows, you get an infinity. Further arithmetic can never return you to the realm of finite numbers (though you can also get into the world of "not a number" NaNs by calculating -inf + inf for instance), so you can use a standard function like (C99 <math.h>) isfinite() to check if any intermediate step of summing FP numbers overflowed the representation.

A modest proposal: stop adopting new digraphs like [:, ^^, [[.

Unicode has at least 50 sets of pairing punctuation just waiting for use...

       \N{MEDIUM LEFT-POINTING ANGLE BRACKET ORNAMENT} U+276c 
       \N{HEAVY LEFT-POINTING ANGLE BRACKET ORNAMENT} U+2770 
       \N{LIGHT LEFT TORTOISE SHELL BRACKET ORNAMENT} U+2772 
       \N{MEDIUM LEFT CURLY BRACKET ORNAMENT} U+2774 

and multiple blocks of mathematical operators including

      ⊥ \N{UP TACK} U+22a5 ⊥
      ⊦ \N{ASSERTION} U+22a6 ⊦
      ⊧ \N{MODELS} U+22a7 ⊧
      ⊨ \N{TRUE} U+22a8 ⊨
      ⊩ \N{FORCES} U+22a9 ⊩

so you could just write the much clearer and more distinctive ⹗derive<serde::Serialize>⹘ and so on for the other new multi-punctuation sequences.

Yes, by the time C++37 comes around it might be necessary to petition Unicode to add additional code points. This wouldn't be a problem, for two reasons:

First, Unicode is accustomed to adding new code points and might even be willing to pre-allocate some entire pages to the C++ committee.

Second, the existing ways to modify emoji could apply to designated mathematical modifiers as well. For instance, ∅ would denote a distinct future C++ operator symbol from ∅ or ∅ (sadly, as of 2024, hacker news can't render "pale woman "A-type" empty set" or the other empty set symbol variations I lovingly entered in this paragraph).

These sequences are highly preferable to ASCII sequences like [: because the ZWJs allow supporting editors to correctly render them as a single glyph occupying a single terminal cell and without using font ligature hacks.