Knowing a bit about how sausages are make (not at Apple specifically), I'm willing to bet that this isn't as much "withholding features" as "getting on the hype train asap, but doing it in a DMA-compliant way would delay the launch by far too long".

Also, it should give you a pause to think what is it about their intelligence features that is not DMA-compliant and why would the rest of the world want that stuff in their pocket.

https://indieweb.social/@stevestreza/112656039226675473

Hmm, do you need to put up a cookie warning if you are using only LocalStorage?

Is it okay to have more dependabot commits in your repo than your own?

I am back at it. Today we will pat that cat.

continuous here: https://m.nevkontakte.com/o/fd3fd5a9c91947c1843aa7cbbcca5dc2

Today's objective is to code something for fun, in a day. It's been far too long I've done something with no purpose other than enjoying the process. An idea has been kicking around my head since (checks timestamps) mid 2020... Time flies

I want to put a cat on the internet. He chills on his page and you can pet him. Or not. He likes when he's getting pets That's it. I have more ideas, but minimalism is the name for the game for today.

Technically, I want to keep things simple and lightweight. It should be clean. It should load fast. Interactions should be simple, no manual required. Giving a pat should leave a footprint of sorts.

To make things a bit more fun, this will be a live development thread

Been thinking about moving off microblog.pub to something else, primarily because it's getting far too slow for what it is. Unfortunately things don't look promising, it seems like there's no good way to migrate existing content to the new account, and replacing the engine in-place is also a source of endless issues. https://voidfox.com/blog/the_sisyphean_effort_of_activitypub_migration/ is a good writeup from about two years ago that covers some of the issues.

This is very annoying. I guess I could pour a bunch of effort into optimizing microblog.pub, but I so don't want to get involved with python.

https://webllm.mlc.ai/ is amazing and terrifying at the same time.

Amazing because you don't need fancy GPU servers to run an LLM, it can just run in a browser. From purely technical point of view this is mind blowing.

Terrifying because before long every other site will download not just 50 MiB of JavaScript and CSS, but also 6 GiB of neural network so they can grace you with another useless AI assistant ready to sell you whatever garbage they are peddling.

It's high time for y'all to get reminded

https://www.youtube.com/watch?v=9v99hclktVA

https://github.com/gopherjs/gopherjs/pull/1305 is one of the weirdest butterfly effect bugs I got to debug.

The effect that starts the chain is simple enough, the hash/maphash.TestHashHighBytes test introduced in Go 1.19 is flaky under GopherJS. What does the test do? It checks that the high 32 bits of the hash are actually sort of random.

The 64-bit hash is computed using a 64-bit seed and a 32-bit low-level hash function, here's an abbreviated version:

func rthash(b []byte, seed uint64) uint64 {
	lo := memhash(b, uint32(seed))
	hi := memhash(b, uint32(seed>>32))
	return uint64(hi)<<32 | uint64(lo)
}

Somehow, half the time the higher 32 bits of the seed are exactly FFFFFFFF. Why would that be?

Well, the seed is generated by this function, which looks innocent enough:

func fastrand64() uint64 {
	return uint64(fastrand())<<32 | uint64(fastrand())
}

Liberal use of print-debugging reveals that the high 32 bits of the right uint64(fastrand()) operand are FFFFFFFF. So when or-ed with the other side or basically stomps whatever randomness would have been there. What is fastrand then?

func fastrand() uint32 {
	return uint32(js.Global.Get("Math").Call("random").Float() * (1<<32 - 1))
}

Wat? How could upsizing a uint32 to uint64 possibly yield FFFFFFFF in the high bits?!

WARNING, we are now exiting vanilla Go lands and delving into JavaScript madness that makes GopherJS work.

Because JavaScript is what it is, GopherJS has little choice but use the same number type to represent all non-64-bit integers, throwing a modulo operation here and there to keep up the appearances. Similarly, float64 and float32 are actually also the same number under the hood. That said, JavaScript does give us a tool to pretend there are signed and unsigned integers: >> and >>> respectively. In JS, the following are true: (4294967295 >> 0) === -1 and (4294967295 >>> 0) === 4294967295 (yeah, the infamous === has a little >>> brother, don't ask what happened to <<<).

Going back to GopherJS, it uses this trick to maintain signed and unsigned integers. We almost have our smoking gun. The last piece of the puzzle has to do with the unit32 → uint64 conversion step. When GopherJS tries to interpret a negative number as uint64, it assumes the number is signed, and sets the high 32 bits to FFFFFFFF as it should. Let's look at fastrand again:

func fastrand() uint32 {
	return uint32(js.Global.Get("Math").Call("random").Float() * (1<<32 - 1))
}

The js.Global.Get("Math").Call("random").Float() * (1<<32 - 1) is not very interesting, it just gives us a float64 in the range of [0, 2^32). But then it gets converted to unit32. The correct way of doing it is using the >>> 0 trick, but the compiler was emitting >> 0. Which meant any value in the [2^31, 2^32) range would be converted to its two's complement negative number. Boom! The gun fires. When our negative supposedly uint32 value is converted to uint64 the high bits get set to FFFFFFFF; when it gets |'ed with another number, it overrides whatever higher bits the other side had. Bad things happen then.

#golang #gopherjs

Today I've heard a wonderful term: cringineer. Now I'm thinking how do I put it into my Linkedin profile.

Another case of a 6-line bug fix accompanies by 160 lines of unit tests.