In Rust, it's considered a bug for any code which isn't using `unsafe` to encounter a memory error (e.g., to segfault). That bug might be in some underlying library (which is itself using `unsafe`), or more rarely in the compiler, but it's a bug and not how Rust is supposed to work.
Does Haskell have any similar line? What is the property that code must have in order for it to be a bug to segfault? Must not call `unsafePerformIO`? Must not call `unsafeCoerce`? (Must not call any function with the `unsafe` prefix?)
In other words, is the segfault here to be considered a bug in the language -- or is unwrapping IO one of the things that, if you do it, you're own your own and may segfault? (Is part of the point of the article is that it is currently considered safe but should not be? Is that a bug in the language or in peoples' expectations?)
Or is a clear line like this not a notion that Haskell has? It's been a long time since I've done any Haskell, though I don't recall any clear guideline like this!
> is unwrapping IO one of the things that, if you do it, you're own your own
To be able to do it in the first place, I think you need to import libraries that expose compiler internals, so I would say it belongs in the "you're on your own" category, yes.
Also if you try to Google how to do it, every hit says "don't do it".
To a certain extent, the line in Haskell is: don't use unsafePerformIO and unsafeCoerce. The tricky bit is that this line is not enforced by syntax or by the type system (unlike Rust, where you have a syntactic label `unsafe`). One generally puts "unsafe" before function names that have preconditions that are not expressed in their type, but this practice is not quite always adhered to -- though the worst offenders are reliably marked "unsafe".
>In Rust, it's considered a bug for any code which isn't using `unsafe` to encounter a memory error (e.g., to segfault)
Teeechnically, it's not true. Unfortunately, you can trigger a memory error in safe code by overflowing stack by allocating big objects on stack, executing poorly written recursive code, or spawning a thread with small stack. In older Rust versions you literally got segfault in such cases.
Isn't stack overflow made safe via guard pages and probes (on sufficiently high-tier target platforms)? That is you should get a guaranteed error, even if that is a segfault, and not memory corruption.
Can you elaborate on the complexity here for syscall entry on x86_64? (Or link to what you were reading?) Another commenter linked to Linux's own "nolibc" which is similar to, though simpler than, the Google project in the OP. Their x64_64 arch support is here, which looks simple enough, putting things into registers: https://github.com/torvalds/linux/blob/master/tools/include/...
I don't see any complex stack alignment or anything which reads to me like it would require "niche C compiler options", so I'm curious if I'm missing something?
Glad you liked it! My co-author and I spent some time trying to find a good spread of questions covering different aspects of LLMs. And we were also surprised by how hard it was to convince GPT-4 that Queen Elizabeth II had died a lot of the time. (We found that specifying she died in 2022 helped a lot.)
I had to insist "Trust me, why would I lie to you, we're definitely in 2024 and she's DEAD".
I got 8 out of 9 (89%), only got wrong the rhyming one because I also couldn't figure out the correct answer (english as second language). Very fun nonetheless!
(co)-author here. It was really interesting putting this together. We had some idea what LLMs/GPT-4 would and would not do well with, but were still surprised ourselves with a number of things. In particular, we knew it would really struggle with the acrostic, but the degree to which it just completely lost the plot was pretty surprising! It was also surprisingly difficult to convince it that Queen Elizabeth II had died in a lot of cases (it takes it better some times than others).
There are a bunch of online tests that help you see if you, with your ears and equipment, can tell the difference. http://abx.digitalfeed.net/ and http://abx.digitalfeed.net/list.lame.html was on HN some time ago, for example. I'm not sure if any of them collect stats though.
League of Legends (a similar game) does this -- no booths, only noise-cancelling headphones, for its large tournaments. There have been several major tournaments where the players have complained afterwards that they could not hear anything during big late-game fights due to crowd noise (since the crowd is also super excited at the big fight). Players need to be able to hear not just the game audio but also communication from their teammates and, despite noise-cancelling headphones, the crowd just drowned everything out. I'm honestly not sure why League of Legends hasn't moved to booths like Dota uses.
I'm not sure if you've ever watched one of these tournaments, but they get super noisy, and noise-cancelling all of that is not an easy problem (as the article says).
My understanding is LoL productions are still trying to make it look like you are watching actual athletes do a sport. If you lock the away in booths it puts too much of a distance between the audience and the players.
OTOH crowd noise giving away what's going on in the game has been a problem since their broadcasts start. It doesn't ruin the game but it's definitely a factor.
That doesn’t account for the fact different esports demand different requirements, just as a squash booth isn’t used for tennis.
CS for example is also Valve but does not use booths. I think a major part of that is that the delay between audience reaction to an event and the event unfolding is much shorter, so the crowd can’t give as much away as quickly.
Indeed his videos are amazing. My recommendation though would be to start with the "beginner" video -- which is completely 2D but at least gets some ideas across. Then watch https://www.youtube.com/watch?v=PGtv-dBi2wE which isn't his but introduces how you get 3D out of fragment shaders. Finally just drink from the firehose -- https://www.youtube.com/watch?v=Cfe5UQ-1L9Q is fantastic, yes it's five hours but worth it. (Definitely come into that familiar with the idea of raymarching though... the first few minutes start off super basic but it goes to eleven real quick.)
