1. 21
  1.  

  2. 4

    Racket would have to be able to target arm64 for that to be feasible

    It does. Without JIT, only interpretation, but works fine.

    1. 2

      Interesting! I had no idea. Do you have any links I could take a look at?

      1. 2

        I don’t have any links. On normal desktop/server aarch64 platforms, you (or the OS packager) just compile it as usual (without --enable-jit) and it just works. It’s cross-platform.

        1. 3

          Sweet. I’ll have to play around with that. I’ve updated the article. Thanks!

          EDIT: Turns out there is info about cross-compilation to iOS and Android in the Racket source README:

          https://github.com/racket/racket/blob/fc258725ba7e5bd7289f15a08843fb2f62af4e27/racket/src/README.txt#L404-L431

    2. 3

      Nice architecture! I have to confess that I was a wee bit disappointed, because I misinterpreted the title. I expected a native GUI defined in Racket; but in fact it’s a platform-agnostic core written in Racket, plus a native GUI written in another language (Swift).

      Still, a very nice architecture, and I hope you get the library version with in-process interop working, too. Good luck, and have fun!

      Edit to add: your architecture, with a platform-agnostic core and a platform-specific front-end, reminded me a lot of Simon Tatham’s portable puzzle collection (enough that I went to look it up for you, and the figured I might as wel submit it to Lobsters). That project has game-specific backends, platform-specific frontends, and both-agnostic middleware that lets the games and the platforms compose to give m × n combinations. The architecture and the problem it solves are a bit different from yours, but perhaps there are enough parallels to make it relevant.

      1. 2

        Thanks! I can see how the title might be interpreted that way. I should’ve added “at their core” to the end or something.

        Those puzzles look really cool, thanks for the link.