Dark Arc @ Dark_Arc @social.packetloss.gg

Hiker, software engineer (primarily C++, Java, and Python), Minecraft modde

---

Read more

Posts

78

Comments

2,258

Joined

2 yr. ago

Moderating

---

I think this is only conditionally true... A good AMD based system on say Fedora with a GPU that's at least a year old ... you really won't have much of a problem on Linux in my experience or much to fix.

I did not say it's not semantically well defined.

https://en.wikipedia.org/wiki/Brainfuck#Hello_World! -- this is semantically well defined, but it's still vague. Vagueness is a property of how well the syntax is conveying intent.

Hm... I'll admit I wasn't awkward of the .__len__ function. However, does this mean it's possible to write a len(x) == 0 that's diverges from not x?

If not, then the substitution is still valid (and not presumably also considers the same fundamental. If so, that's kind of silly.

EDIT: I missed the part of your comment about .__bool__ ... so yeah in theory you could have something where these two operations are not equivalent.

Arguably, you could just say that's pathological and invalid. Then, still have an optimized path to prefer not .__bool__() if .__len__() == 0 is the comparison you'd be making. Even with the extra interpreter check during evaluation, that would quite possibly be faster if the overhead is truly high.

EDIT 2: you'd probably need a little bit more overhead than a straight substitution anyways because you need to maintain the semantic of "if this thing is None it's not valid if the syntax was originally len(x)."

I prefer the clarity of len(x) == 0 personally; it's a pretty low syntactic penalty to clarify intent.

Obviously, if your variable names are good and you're consistent about your usage not list can be fine too, but it is a very JavaScript-y thing to me to be that vague and/or rely on "truthiness."

I don't know about others ... but I'm not using Python for execution speed.

Typically the biggest problem in a program is not 100 million calls of len(x) == 0. If it was, the interpreter could just translate that expression during parsing.

The most tragic thing about MacOS is, it's almost good

Story is relatively cheap to develop. A lion share of the cost of making a game is the coding (which with this being moved to another engine, there almost certainly was a lot of that) and art (which it seems they redid like all of that and there's a good chance a lot of the animations had to be tweaked).

Basically the only thing wouldn't have to pay for was the story writers and some level designers (people still had to touch up the maps even if there was some automated conversion that pulled most of the map into Unreal Engine 5).

https://youtu.be/1jZXzv1-CmA -- like this isn't just a texture upscale and some minor tweaks to the animations, it's a large scale remaster.

I mean ... not really, they all but rebuilt it. New assets on a new engine.

I mean, I've seen a growing number of companies looking for Salesforce; it's even worse (all of your code only works on their platform because it's a proprietary language AND they charge for things as absurd as how many lines of code you have).

A lot of the things that you can't do with serverless expressed in this article are not things you want to do on a web server anyways. Like writing a temporary file, sharing state in process between requests, or spawning a thread.

Sure for a truly small workload where you don't have to worry about abuse and scaling beyond one machine you can get away with that stuff. However, for companies that do need to be able to deal with multiple machine workloads and don't want to worry about hiring a team of engineers to implement a scalable cloud or run their own physical hardware in a data center ... I think serverless likely has some value.

Intel ... why are you still shooting yourself in the foot...?

Launch into 50"?

It's still weird to look at a 2020 and think that was 5 years ago

Hmmm... Working fine for me on a Pixel 9 Pro

🤦‍♂️

I honestly suspect antitrust is the reason Google hasn't laid more fiber (not that antitrust is bad). They're dangerously close to being broken up for so many other things adding this would be a very high risk gambit. Especially because ISPs are known for their shitty business practices and leveraging lawyers to maximum pain on any legitimate competition that threatens them.

Something to implement signing given the key to sign with could almost certainly be created.

I think the biggest reason this stuff hasn't really happened is ... there's not much motivation and Apple will likely respond to such efforts unkindly so you might need to be a bit of a curious masochist (or at least in strange circumstances) to attempt such an effort 😅

You don't really; a cross compilation with a compiler that can generate the ARM instructions for Apple's ARM CPUs should largely just work.

However, it's impossible to test the produced app without using an iPhone or MacOS's tools to simulate running on an iPhone. You also are just going to have way less of an uphill battle using Apple's tools and you're likely to get better optimized binaries.

You also don't have to build iOS apps with Swift; C++ and things like Qt can be used.

For MacOS you're right, for iOS OP is right; you're being a dick about it though, so maybe that's the issue.

Even if you understand the tech, the fediverse has a content discovery problem. The content you want to see may actually exist. However, your instance needs knowledge of the content that best fits you. That's what bluesky's model does better.