epistemex

For something to have the ability to become conscious it need some form of intelligence. There is absolutely zero intelligence in any ML/AI with today's models. None. No wisdom, nothing. Not even remotely close to a retarded cockroach.

The only way "AI" would be conscious would be if the 'machine' it ran on could be possessed by something, somehow. The question then becomes, possessed by what.. We probably don't want that.

The majority of these escape codes start with \x1b[

This is actually the 7-bit version for CSI. A less known variation is the 8-bit CSI which is simply \x9b and is the same as \x1b[ combined. So, for example \x9b33m does the same as \x1b[33m .

Unfortunately, there exist a couple of (8-bit) terminals that don't support this version.

First, thanks for writing and sharing this.

Since many here uses desktops I wanted to share a small tip, but first an anecdotal observation: I got my first computer at age 10-11 back in the 80s (a VIC20) and we only had a 50Hz (Europe) interlaced 21" TV as a "monitor" at that time. After using it a few months even my teacher pointed out I was getting dark circles under my eyes. My sleep was getting worst. Many years later and years in front of computer screens I also found that I had gotten delayed sleep-phase syndrome as well - this at a time CRTs was the norm. For those who say that this light is not enough to affect sleep, I would say you're wrong. But that's anecdotal..

As to the tip: here is what I did - in your color management settings, create a ICC profile which turns off almost all blue and most green. This will leave you with a darker orange color which is perfect if you need to sit late and work. This also affect all programs on your screen. You can also use tools to create ICC profiles that inverts bright colors etc.

Now you can simply toggle between your normal ICC and the dark/orange one.

since they are two different primitive types.

Yes, I'm aware of this, but I was more asking in the realm of internal performance/optimization (as I sort of point out - and not necessarily because of the comparer). F.ex. they are in all practicality the same integer and in other cases, IIRC (please correct me if I'm wrong), V8 optimizes the native Number that could easily be stored internally as IEEE-754, to actual internal integers when using bit-ops on them (to indicate to the optimizer you handle integers) and so forth.

In this case I was curious if this would be optimized internally so these comparisons could be moved directly to CPU registers as integers (assuming being on a 64-bit arc) and compared there, for example. But, future will tell - I'm equally aware of that optimizations is not first priority at this stage (it's just me excited to see this manifest). It's in any case a welcome and useful feature optimized or not.

apaprocki linked (thanks!) to a method that can do unsigned right-shift via a method (1.1.11 BigInt::unsignedRightShift).

This is a welcome feature.

I think this for the most part is useful for WASM, but also storing/reading/writing to binary buffers as in handling file formats that stores (u)int64s (such as f.ex. CAF on the Mac) and with binary protocol responses from environments such as Java/.Net that already supports bigints (and of course, eventually Node), finance calculations.. nice.

Just curious, how will you deal with things like triple-comparing (`0x1n === 0x1` ?) internally (from the perspective of performance)?

BigInts [..] are always signed (in ref. to the >>> operator)

Disclaimer: I haven't taken a deep-dive into the BigInt spec yet, but things like this comes to mind (say you want to shift and mask using unsigned 64-bit values):

    0xffffffffffffffffn >>  24 => 0xffffffffffffffffn (hmm)

    0xffffffffffffffffn >>> 24 => 0x000000ffffffffffn (but won't be supported)