sicmutils VS ChezScheme

They seem to be in the middle of transitioning from the old repo.

There are some good resources here including some nicely formatted HTML versions of the book: https://github.com/sicmutils/sicmutils/wiki/SICM-and-FDG-Lea...

^ The Github repo contains a Clojure version of the Scheme library used by the book.

If you want to try this out, give the sicmutils Computer Algebra System a go (I’m the maintainer). Repo lives here: https://github.com/sicmutils/sicmutils

The library works in the browser as well, so interactive TeX rendering from Clojure symbolic expressions and functions is available at the quickstart page here: https://nextjournal.com/try/samritchie/sicmutils

I am the maintainer of the "sicmutils" computer algebra system in Clojure, and I think that you'll find it very nice for your project: https://github.com/sicmutils/sicmutils

https://github.com/sicmutils/sicmutils is a really interesting development in the direction(s) you stated in b. Since terms can be rendered in various ways (latex, js, etc.), they can be embedded in documents, web pages, etc. You can go from symbolic expressions to animated dynamic systems with relevant formulae.

- multiple stories about the same piece of code, but all with the ability to IMPORT the story as a library

I've been writing sicmutils[0] as a "literate library"; see the automatic differentiation implementation as an example[1].

A talk I gave yesterday at ELS demos a much more powerful host that uses Nextjournal's Clerk to power physics animations, TeX rendering etc, but all derived from a piece of Clojure source that you can pull in as a library, ignoring all of these presentation effects.

Code should perform itself, and it would be great if when people thought "LP" they imagined the full range of media through which that performance could happen.

[0] sicmutils: https://github.com/sicmutils/sicmutils

[1] autodiff namespace: https://github.com/sicmutils/sicmutils/blob/main/src/sicmuti...

[2] Talk code: https://github.com/sritchie/programming-2022

[3] Clerk: https://github.com/nextjournal/clerk

Hey, so fun to see this here! These demos feature work from https://github.com/sicmutils/sicmutils and the newly maintained-by-me Mathbox library.

I’m around and happy to answer any questions about the library, future plans, etc.

Give my SICMUtils computer algebra system a look as well, if you like Lisp / Clojure: https://github.com/sicmutils/sicmutils

Works on the web too, which is a big boost for sharing work.

It is good enough! Almost all code forms from the book live in the tests (see the FDG directory[0], for example), and there are a few nice environments like Nextjournal[1] where everything from the books works in the browser.

The Clojure port is quite fast, faster than the original for all benchmarks GJS has sent me, and more fleshed out. (That will change, as I've been pushing bugfixes and performance improvements back upstream as I go, as a meager gift to GJS for making this huge, amazing library in the first place.)

I actually wrote to GJS this morning asking for instructions on how to compile the original "scmutils", since I have the same problem. He responded saying he'll get back to me this afternoon, so I'll post here once I have details.

If you are still interested in getting the books going with MIT-Scheme, I put a decent amount of work into the exercises using the original codebase here[2], including a dockerized version of mit-scheme[3] and the scmutils package[4] that might be useful.

- [0] https://github.com/sicmutils/sicmutils/tree/main/test/sicmut...

- [1] https://nextjournal.com/try/samritchie/sicmutils/

- [2] https://github.com/sicmutils/sicm-exercises

- [3] https://hub.docker.com/r/sritchie/mit-scheme

- [4] https://hub.docker.com/r/sritchie/mechanics

This is an update on building Idris2 for `arm64` Apple silicon. My original guide was posted here a year ago: [Success building native Idris2 on an M1 Mac](https://www.reddit.com/r/Idris/comments/pc5lib/success\_building\_native\_idris2\_on\_an\_m1\_mac/) Some issues I encountered may get fixed, so these notes may best serve as guidance, as others work through this install in the future. I no longer have any Intel Apple machines in use. I am using MacOS Monterey 12.5.1, and a current homebrew installation that includes needed support such as gmp. I have successfully built idris2 on several M1 Mac minis, an M2 Macbook Air, and an M2 Ultra Mac Studio. These directions assume that you have read the install docs for Chez Scheme and Idris. ---- The official Cisco [Chez Scheme](https://github.com/cisco/ChezScheme) is still not `arm64` native. As before, one needs to install Racket's [fork](https://github.com/racket/ChezScheme/), which is `arm64` native and supports Idris2. Cloning the git repository and attempting to build, one encounters the error Source in "zuo" is missing; check out Git submodules using git submodule init git submodule update --depth 1 After these steps, the build is routine using the steps arch=tarm64osx ./configure --pb make ${arch}.bootquick ./configure --threads make sudo make install One can now confirm that `scheme` is `arm64` native using the command file $(which scheme) ---- The Idris 2 build was a delicate puzzle for me, harder than before. I got it to run by hand once, and then lost hours trying to recover what I did right by script. Here is a GitHub Gist for my install script: [Build script for Idris 2 on Apple silicon](https://gist.github.com/Syzygies/15cbaebd5d7a31630650b7a8436a8f1f) Here are the issues I encountered: Seven of the nine case statements involving ta6osx have had t `arm64`osx added, but not the remaining two. This threw me, as I imagined this had to be deliberate, and this was one of several problems that needed fixing. The bootstrap build creates a file `libidris2_support.dylib` but then can't find it later. One needs to attempt the bootstrap build twice, copying this file after the first attempt fails so that the second attempt will succeed. I copied this file everywhere needed, rather than to `/usr/local/lib` (homebrew doesn't like sharing a lane). The executable script itself can fail to find this `.dylib`, but the executable looks in the current working directory, so one could easily miss this during development. I also patch the executable so it changes into the executable's directory before calling it, where one of several identical copies of this `.dylib` can be found. `INSTALL.md` included the curious note **NOTE**: If you're running macOS on Apple Silicon (arm64) you may need to run "`arch -x86_64 make ...`" instead of `make` in the following steps. The correct way to read this is that the author isn't sure. In fact, following this instruction will create `libidris2_support.dylib` with the wrong architecture, as I verified with a matrix of experiments (this or not, edit last two case statements or not). What is the status of official Apple silicon support for Chez Scheme and Idris 2? Searching Cisco [Chez Scheme](https://github.com/cisco/ChezScheme) issues for `arm64` yields several open issues, including [Pull or Backport ARM64 Support from the Racket Backend Version #545](https://github.com/cisco/ChezScheme/issues/545) proposing to pull the Racket fork support for Apple Silicon. Searching pull requests for `arm64` yields [Apple Silicon support #607](https://github.com/cisco/ChezScheme/pull/607), which doesn't work. The author doesn't explain why they are making this effort, rather than pulling the Racket fork changes. Others note that the author also ignores prior art in their naming conventions. Searching [Idris 2](https://github.com/idris-lang/Idris2) issues for `arm64` yields [Racket cannot find libidris2_support on Mac M1 #1032](https://github.com/idris-lang/Idris2/issues/1032), noting the `.dylib` issue I address, and linking to [Clarify installation instructions on macOS (M1) #2233](https://github.com/idris-lang/Idris2/issues/2233) asking for better Apple silicon directions, which backlinks to my first [reddit post](https://www.reddit.com/r/Idris/comments/pc5lib/success\_building\_native\_idris2\_on\_an\_m1\_mac/). The other backlinks I could find are automated scrapes not of interest. There are no pull requests for `arm64`. I admire the Idris project and I want it to succeed. It needs macOS users. However, I'm unlikely to rely on Idris2 for my own work until parallelism is better supported. I'd love someone to change my mind if I'm misreading the situation.

The Racket fork of Chez Scheme runs natively on Apple ARM (AFAIK these changes have not yet been merged into the main branch of Chez Scheme)

https://github.com/racket/ChezScheme/

I succeeding in installing a native arm64 Idris2 on an M1 Mac. I wish that I had found clear directions all in one place. I would be happy to contribute such directions, after experts have commented on what I did. Where should these directions go? As of this writing, the official Chez Scheme is not arm64 native, but the Racket fork of Chez Scheme is arm64 native. I first installed Racket's Chez Scheme (9.5.5.5), which appears to support Idris2. https://github.com/racket/ChezScheme/ It is likely that a full Racket installation will also put this somewhere, but I could not find it. Chez Scheme uses idiosyncratic machine types, which take some sleuthing to find. Once one has a working scheme, `(machine-type)` evaluates to the machine type, but there is a chicken-and-egg problem here. At a command line, `arch` prints the machine architecture, `i386` or `arm64`. The Chez Scheme machine type for an `i386` Mac is `ta6osx`. The Chez Scheme machine type for an `arm64` M1 Mac is `tarm64osx`. The full build instructions for Chez Scheme on an M1 Mac become arch=tarm64osx ./configure --pb make ${arch}.bootquick ./configure --threads make sudo make install sudo chown $(whoami) ${arch}/petite.1 ${arch}/scheme.1 The final `chown` keeps this directory from interfering with synchronization software such as `unison`. The Makefile is a bit sloppy about cleaning up ownership, and leaves these files assigned to `root`. I found that `make clean` did not sufficiently restore the Chez Scheme build directory to be used on a different architecture, so my script unpacks the build directory from scratch. I probably missed the correct scorched earth incantation; I know without diving into code that starting with a virgin build directory works. Now, a bootstrap build of Idris2 requires two tweaks. https://www.idris-lang.org/pages/download.html First, the build needs `gmp` which I installed via Homebrew. However, Homebrew provides the file `/opt/homebrew/include/gmp.h` on an M1 Mac, rather than `/usr/local/include/gmp.h` as on other Macs. The build uses `/usr/bin/cc` which knows about `/usr/local/include` but not `/opt/homebrew/include`. One needs to set the `CPATH` environment variable. One therefore builds with the commands export CPATH="/opt/homebrew/include" make bootstrap SCHEME=scheme make install Apparently Homebrew had an `#M1too` moment where they were convinced that it was poor practice to use `/usr/local` because others do, so they switched to `/opt/homebrew` for M1 Macs. I never had a problem with this, but I don't relish having recurring problems separately teaching every language in my programming zoo how to find libraries provided by Homebrew. I wish I could find the tortuous discussion leading to this decision, for I'm sure it would be delightful reading, and might shed light on this. There is a final problem: The Idris2 build is unaware of the Racket Scheme machine type. As I start with virgin build directories for each machine, I found it simplest to globally replace every occurrence of `ta6osx` by `tarm64osx`. This works. One should perhaps add `arm64osx` and `tarm64osx` to the existing code, alongside `ta6osx`. I don't fully understand the naming conventions (one wants to guess in advance what the official Chez Scheme will choose when it supports M1 Macs), or the code I was modifying, so I didn't test this.