Add Primes in Beef

[rzuckerm]

Description

Prime sieve in Beef. I couldn't get the build for the Beef GitHub repo to work for ARM64, so the image will only work on AMD64.

Contributing requirements

• [x] I read the contribution guidelines in CONTRIBUTING.md.
• [x] I placed my solution in the correct solution folder.
• [x] I added a README.md with the right badge(s).
• [x] I added a Dockerfile that builds and runs my solution.
• [x] I selected drag-race as the target branch.
• [x] All code herein is licensed compatible with BSD-3.

[rzuckerm]

@rbergen Sorry for all the churn on this PR. I'm still getting the feel for this language. I'm done tinkering with this.

[rbergen]

@rzuckerm Not a problem. I recognized the pattern, so I just waited for things to calm down. :) With you being done making changes, I'll review as soon as I can.

In the meantime, could you maybe elaborate a little bit on the nature of the build failures on ARM64? Not to question your conclusion, just because I'm curious. In my simple thinking, in 2024 a new programming language would make an effort to also work on that platform.

[rzuckerm]

@rbergen The Beef programming language can only be built from source on Linux and MacOS. It requires building a very specific version of LLVM from source. I tried to use some of the LLVM binaries, but I couldn't get the Beef source to build with that. LLVM needs to be built in a very specific way with very specific options enabled. When I tried to build for ARM64, I couldn't get LLVM to compile at all. You're welcome to take a look. Here's the source for my docker image. There are a couple of build scripts that I scraped from the original build system:

• beef_llvm_build.sh - Builds LLVM 13.0.1 with specific build flags and adds necessary links that the Beef build system needs. It is based on this with some reductions in the number of things it builds. For some reason everything is build for debug and release. Very wasteful and time-consuming. I could not get this to build for ARM64 using docker multi-arch. I don't remember specifically what failed, but here is the build.
• beef_build.sh - Builds the Beef compiler and other tools. It is based on this. Again, the same wasteful, time-consuming pattern of building for debug and release.

[rbergen]

@rzuckerm You answered my question in the second sentence. Once something requires a specific compiler build to build, I know all bets are off. Thanks for clarifying!

[rzuckerm]

@rbergen I tried to build it locally, it's not LLVM that is having an issue. It is libffi:

$ docker buildx build --builder=mybuilder --platform=linux/arm64 -t rzuckerm/beef:0.43.5a4-dev -f Dockerfile .
...
495.8 Building libffi...
501.2 checking build system type... aarch64-unknown-linux-gnu
502.7 checking host system type... aarch64-unknown-linux-gnu
502.7 checking target system type... aarch64-unknown-linux-gnu
502.9 continue configure in default builddir "./aarch64-unknown-linux-gnu"
503.2 ....exec /bin/bash ..//opt/Beef/BeefySysLib/third_party/libffi/./configure "--srcdir=.." "--enable-builddir=aarch64-unknown-linux-gnu" "linux
503.2 gnu"
503.2 /bin/bash: ..//opt/Beef/BeefySysLib/third_party/libffi/./configure: No such file or directory
504.1 Starting build.sh
504.4 Building from /opt/Beef/bin
504.4 Building libffi...
509.7 checking build system type... aarch64-unknown-linux-gnu
511.3 checking host system type... aarch64-unknown-linux-gnu
511.3 checking target system type... aarch64-unknown-linux-gnu
511.5 continue configure in default builddir "./aarch64-unknown-linux-gnu"
511.8 ....exec /bin/bash ..//opt/Beef/BeefySysLib/third_party/libffi/./configure "--srcdir=.." "--enable-builddir=aarch64-unknown-linux-gnu" "linux
511.8 gnu"
511.9 /bin/bash: ..//opt/Beef/BeefySysLib/third_party/libffi/./configure: No such file or directory

It didn't spend too much time trying to figure out why this was happening.

[rbergen]

What I meant was that when things are so brittle that you need to first compile a specific build of the compiler before you can build what you're actually building, things tend to break very easily further down the line. Looking at the error (thanks for sharing that) I don't think it would be too difficult to fix that one, but it's not a reasonable ask of contributors to this project to debug embedded dependencies of the languages they write solutions for. Also, when the error you run into now is fixed, you may well run into another one immediately after - turning the process into the proverbial rabbit hole.

This being the case, I'm okay with making this an AMD64-only solution.

[rzuckerm]

@rbergen Is there someone else that can review this PR? @marghidanu seems to be unavailable.

[rbergen]

No, since Dave handed over the proverbial keys to this repo and Rolf left the project, @marghidanu and I are the two maintainers. I'll ask him if he can review via another channel, otherwise I'll apply "he who is silent agrees" in a few days.