You miss the point. If you have full control over when and how getenv is called, there's no issue to begin with. The problem is that you don't, as OP demonstrates. It's perfectly natural to call getaddrinfo in a loop.
We need a new API which is not broken like in NetBSD, and a multi-year migration of all core libraries to it. Well a pity it wasn't started years ago though, could've been 95% done by now.
To be fair, I don’t think its so much about white collar jobs being under threat as it is about creative jobs being under threat. Many creative pursuits are viewed as an outlet of human expression in a way that other jobs never were, and I think this is what is driving the new wave of the Resistance^TM
I enjoyed seeing a meme the other day (rare for me to enjoy!) that summed it up as something like -
"Having to do manual labour to make ends meet while the robots paint and write poetry was not the future I had in mind".
And I think that sums up the feeling quite well. I do agree that automation in general has not paid off in the way the utopians would predict - instead of freeing humanity from the need to work, we have disenfranchised large portions of the population. That said, more people than ever (in the west) are freed from manual labour, and are working historically shorter hours for better quality of life than ever before. But the fruits of our productivity gains are not distributed equally and it is all too easy to imagine a future in which it is the owners of the smart systems who reap all the rewards, with everyone else fighting for scraps.
I have visited several art exhibitions this year and generally would say that stuff at front page of /r/StableDiffusion/ is just more original and better than some random art exhibition.
And this kind of highlights the kind of hypocrisy implied by the original comment.
"Having to do manual labour to make ends meet while the _______ paint and write poetry was not the future I had in mind"
For the less fortunate people struggling to make ends meet, it may not matter that much whether it's robots or the aristocracy, or the upper middle class doing the poetry writing.
Until the last couple decades, 99% of humanity was always doing doing manual labor to make ends meet. It's just that the literate class throughout history always identified with the 1% rather than the 99%. We're conditioned to think that creative endeavors are always more "noble" than manual labor because that's what nobles did.
Ironically the fact that we pay "knowledge workers" more than manual laborers might have contributed to this outcome. If toilet janitors commanded a $500k salary maybe more R&D budget would go to inventing robots that are good at cleaning toilets, instead of AI systems that are good at solving leetcode.
I think it’s because of supply and demand in addition to value. A manual laborer, even a very skilled one, is limited by their own output on how much value they can create. A software engineer creates outputs that can generate many multiples of their compensation for doing so.
it could just be that freeing humanity from the need to work takes longer than we thought
are we worse off than we were before industrial automation? I thought the economics said the opposite (even if we exclude the eastern nations that benefits from western job loss from our utilitarian analysis here -- which we shouldn't)
> We could easily feed, house, clothe, entertain, and care for everyone with 25 hour work weeks
Assuming zero innovation or growth, yes. If a society is comfortable opting into declining relative living standards, they should have the right to do so. But framing this is a costless trade-off is facile.
Better argument: we can afford to feed, house, clothe and care for every American, possibly, almost every human. (The long tail is exhaustingly costly.) But it would come at the expense of some peoples’ lifestyles, majorly, and everyone’s, in small ways. It almost certainly doesn’t occur with a reduced work week and current adolescence/education and retirement expectations.
Society's aren't individuals. They are collections of many individuals. I don't think society "chooses" to do or not do things in the same way we assume humans "choose" to do or not do things.
I don't think the complexity of human society can be boiled down to "we just choose not be perfect"
Are you sure? Isn't the Scandinavian model essentially "Socialism" by US standards. Last time I checked they were doing quite well compared to literallly everybody else on the planet (excluding other, similar social democracies).
The US went like: socialism is bad, let's go for the polar opposite and make the poor poorer and the rich richer. For many that are poor in the US people "being equally poor under socialism" is not the threat you think it is, even for the ones that currently go the authoritarian route. Something is brewing in the US and it is an explosive mixture — you can squeeze out only so much from the people without things going sideways.
Based on Pew's income band classification, China's middle class has been among the fastest growing in the world, swelling from 39.1 million people (3.1 percent of the population) in 2000 to roughly 707 million (50.8 percent of the population) in 2018.
China and free market in the same sentence is quite a paradox.
Did you mean to say they moved from a planned economy to a market economy? A market economy yes they do have, but free? Boy oh boy that it is not. Plenty of western companies wanting to enter that market are finding that out the hard way
Sorry, I'm not sure I follow. What does socialism have to do with markets or the lack thereof? I always conceived of that as, like, worker cooperatives, not command economies.
You're cherry-picking one statistic to judge Mao's leadership.
On its own merits, life expectancy is going to be difficult to evaluate China on during this period. Mao's government followed from both a disastrous Japanese invasion as well as a disastrous civil war. Wikipedia says Mao's policies were responsible for 40 to 80 million people dying. Do the life expectancy statistics account for that? How does that compare to the performance of Western governments during the same time period?
This isn’t really correct. Typically exchanges have safety parameters which market makers can set according to how they wish to trade, and if you exceed those your orders will no longer be accepted and existing orders may also be pulled.
Obviously there are false positives occasionally and there is typically communication between the exchange and the market maker to ensure those don’t reoccur.
One of the mantras for Andrew Kelly has been "do not use Zig in production" until it hits 1.0.
People know that, but it's difficult to avoid using it for real things once you've tried it and it works :D.
I haven't done that with Zig, but with Kotlin things like serialization/coroutines/kotest/KAPT (it was the same feeling: oh this stuff is "Experimental" but so cool, I can't do real Kotlin without them!!)... well yeah, I spent many hours rewriting stuff due to that, and totally acknowledge that was on me.
In rust you can also pre-compute (optionally at build time in the build.rs) and load the file at compile time. Either using std::include_str to get a string with the file content (and then parse at startup without needing the separate file) or you generate a valid rust file and use std::include and still get all the potential compiler optimizations from knowing the values of these constants.
But honestly, the const code for generating the values doesn't look thaaat bad. It's bad by rust standards, but not far from what equivalent C code would look like.
While this post has a good amount of substance, I found it rather hard to understand due to small mistakes (or hidden assumptions, or something else?). All of which seem easily fixed/clarified, but these sorts of things are unnecessary friction for readers.
Edit: Thanks to Jasper for stating the big hidden assumption made by the author - that he is only considering the case of being blocked by enemy pieces, not one's own pieces. This is motivated by the fact that one can use the same side occupancy board to trivially remove all moves that are illegal due to self-blocking. This resolves many of the technical issues, although again, it should be be made explicit. The typos/silly errors and pedagogical mistakes remain.
Some examples:
- According to the first bitboard (and the convention stated in the OP), A2 has index 8, not 1.
- In the second bitboard, the rook on e4 should be able to move to e1,a4,e8,h4.
- max of 9 relevant occupancy bits for a bishop - how? A bishop on e4 for example would have to check b1,c2,d3,f5,g6,h7 and a8,b7,c6,d5,f3,g2,h1 for a total of 13 bits. Similar mistake for a the rook.
- The so called "original" masked occupancy bitboard was not mentioned previously
- That same bitboard has variables b1,b2,b3,b4,b5 on it, a notational collision with the squares b1-b5.
- The variables b1-b5 are in the wrong place (presumably they were meant to be on c3,d4,e5,f6,g7 since the bishop is on b2, and again there is the question of why not h8 and the other missing squares).
- Magic number comes out of nowhere. What is it doing? Presumably the purpose is to extract the relevant positional bits to be the most significant ones while keeping the order, done through the multiplication + bitmasking, but this should be explicitly stated. We also have no idea how it is derived.
- What are the "collisions" actually collisions of? It would be nice to see an example of this.
Hi, I'm the original author! This is my first post. I might talk more about chess engines in my blog in the future...
Some background: I taught a class on chess engines this spring (at some point, I'll write up a postmortem on it, maybe). This post was originally derived from my lecture notes for the class, and was (if I remember correctly) the 5th lecture, so I could make more assumptions about the students being steeped in chess-engine lingo.
Josh Triplett is entirely correct here on the masking technique. There are two steps to sliding-piece move generation: first, creating the set of squares a piece can "see," and then the set that it can attack. Magic bitboards are used for generating the set of squares a piece can see.
In terms of where magic bitboards come from: there's not that much in terms of logical derivation. You just have to kind of squint and say, "yeah, I believe that'll work." Magic numbers are found by brute force trial-and-error.
Collisions are caused when the magic multiply doesn't actually yield a perfect bit extraction. Imagine if O * M >> 59 was instead some gross expression of all five bits. The magic number for B1 here is actually an exception - things are not usually so easy. However, if two different positions have the same attack set, and they get sent to the same index by a magic multiply, it doesn't matter that they collided because they map to the same value.
> - max of 9 relevant occupancy bits for a bishop - how? A bishop on e4 for example would have to check b1,c2,d3,f5,g6,h7 and a8,b7,c6,d5,f3,g2,h1 for a total of 13 bits. Similar mistake for a the rook.
If I'm understanding correctly: it's trivial to use a mask with the occupancy bitmap for white/black to eliminate moves atop your own pieces, and generate captures for moves atop your opponent's pieces. The sliding move handling needs to look up whether a piece is in the way of your destination. So, the sliding move handling doesn't need to handle spaces on the edge of the board, because they'll never be in the way of another square.
This makes a lot of sense and gives context to the assumption that we only need to handle the case where an opponent's piece is in the way. Would be great if the author took the 2 sentences to explain this near the beginning of the article.
> - In the second bitboard, the rook on e4 should be able to move to e1,a4,e8,h4.
It's trying to find the set of legal moves. Or, rather, it's trying to find the set of illegal moves that it can exclude from the subset of possible moves. The only thing determining whether a move is legal is whether there's a piece in the way of that move, aka whether a piece is occupying a square, that's what the bitboard check is about. If E1 is occupied, the set of legal moves is the same as if it is unoccupied, so it is irrelevant to check the bitboard for E1. I agree the article could be clearer about this.
I'm clearly misunderstanding something here. Assuming the rest of the board is empty, if e1 is occupied, the rook can't move to e1, whereas if it isn't occupied, the rook can move to e1, so there is at least one position in which we must check e1. What am I misunderstanding here?
Oh, I was assuming it was occupied by an enemy piece, and would capture it. You're right that if it was occupied by an allied piece, it's not a legal move.
