u/ctesibius

In brief, I am running Emacs on an M1 Max (a Mac with an Apple Silicon CPU) and attempting to install treesitter grammars for various languages. For example, I follow the instructions to install the grammar for the Gleam language using

M-x gleam-ts-install-grammar

This does create the expected file ~/.emacs.d/treesitter/libtree-sitter-gleam.dylib, but any attempt to open a .gleam file gives an extremely long warning message which seems to imply that the grammar cannot be found. Here is the start of the warning (with line breaks added):

Warning (treesit): The installed language grammar for gleam cannot be located or has problems (not-found):
dlopen(/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.so, 0x0009): 
tried: '/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.so' (no such file), 

(many lines omitted here!)

After a lot of chasing down blind alleys, I found the cause is actually flagged in the warning message, but long way down:

...
dlopen(/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.dylib, 0x0009): tried: 
'/Users/ctesibius/.emacs.d/tree-sitter/libtree-sitter-gleam.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), 
...

Ok, so the problem is not that the grammar can't be found: it's in the right place, with the right name, but gleam-ts-install-grammar compiled it for the x86_64 processor, not for arm64 (which the M1 Max has). This seems to be a bug rather than intended behaviour. Presumably there is a compiler argument somewhere that gleam-ts-install-grammar calls on which incorrectly selects a target processor. I'm pretty sure this is not in the package for the Gleam language mode, since I see the same problem with grammars for other languages.

The fix would be to correct that bug, but I don't have any insight in to how to do that, and I'm actually aiming to learn Gleam, not Elisp. However the workaround is simple: just manually compile and install the grammar. The following will be obvious to anyone who uses Github all the time, but I hope it's useful to someone

To do this, I created a scratch directory. The grammar I want is at https://github.com/gleam-lang/tree-sitter-gleam, but of course this will depend on the language. Then:

scratch % git clone https://github.com/gleam-lang/tree-sitter-gleam
Cloning into 'tree-sitter-gleam'...
remote: Enumerating objects: 1904, done.
remote: Counting objects: 100% (339/339), done.
remote: Compressing objects: 100% (106/106), done.
remote: Total 1904 (delta 269), reused 264 (delta 233), pack-reused 1565 (from 3)
Receiving objects: 100% (1904/1904), 5.46 MiB | 4.63 MiB/s, done.
Resolving deltas: 100% (1236/1236), done.

ctesibius@tile scratch % ls
tree-sitter-gleam

ctesibius@tile scratch % cd tree-sitter-gleam 

ctesibius@tile tree-sitter-gleam % make
cc -Isrc -std=c11 -fPIC   -c -o src/parser.o src/parser.c
cc -Isrc -std=c11 -fPIC   -c -o src/scanner.o src/scanner.c
ar rv libtree-sitter-gleam.a src/parser.o src/scanner.o
ar: creating archive libtree-sitter-gleam.a
a - src/parser.o
a - src/scanner.o
cc  -dynamiclib -Wl,-install_name,/usr/local/lib/libtree-sitter-gleam.15.1.dylib,-rpath,@executable_path/../Frameworks src/parser.o src/scanner.o  -o libtree-sitter-gleam.dylib
sed -e 's|@PROJECT_VERSION@|1.0.0|' \
-e 's|@CMAKE_INSTALL_LIBDIR@|lib|' \
-e 's|@CMAKE_INSTALL_INCLUDEDIR@|include|' \
-e 's|@PROJECT_DESCRIPTION@||' \
-e 's|@PROJECT_HOMEPAGE_URL@|https://github.com/gleam-lang/tree-sitter-gleam|' \
-e 's|@CMAKE_INSTALL_PREFIX@|/usr/local|' bindings/c/tree-sitter-gleam.pc.in > tree-sitter-gleam.pc


ctesibius@tile tree-sitter-gleam % ls -l
total 2064
-rw-r--r--  1 ctesibius  staff     334 28 Aug 18:43 binding.gyp
drwxr-xr-x  8 ctesibius  staff     256 28 Aug 18:43 bindings
-rw-r--r--  1 ctesibius  staff    5155 28 Aug 18:43 Cargo.lock
-rw-r--r--  1 ctesibius  staff     594 28 Aug 18:43 Cargo.toml
-rw-r--r--  1 ctesibius  staff    2852 28 Aug 18:43 CMakeLists.txt
-rw-r--r--  1 ctesibius  staff     111 28 Aug 18:43 go.mod
-rw-r--r--  1 ctesibius  staff   33373 28 Aug 18:43 grammar.js
-rw-r--r--  1 ctesibius  staff  447160 28 Aug 18:43 libtree-sitter-gleam.a
-rwxr-xr-x  1 ctesibius  staff  463744 28 Aug 18:43 libtree-sitter-gleam.dylib
-rw-r--r--  1 ctesibius  staff   11358 28 Aug 18:43 LICENSE
-rw-r--r--  1 ctesibius  staff    3404 28 Aug 18:43 Makefile
-rw-r--r--  1 ctesibius  staff   29428 28 Aug 18:43 package-lock.json
-rw-r--r--  1 ctesibius  staff    1150 28 Aug 18:43 package.json
-rw-r--r--  1 ctesibius  staff    1083 28 Aug 18:43 Package.swift
-rw-r--r--  1 ctesibius  staff     806 28 Aug 18:43 pyproject.toml
drwxr-xr-x  6 ctesibius  staff     192 28 Aug 18:43 queries
-rw-r--r--  1 ctesibius  staff    3951 28 Aug 18:43 README.md
drwxr-xr-x  4 ctesibius  staff     128 28 Aug 18:43 scripts
-rw-r--r--  1 ctesibius  staff    2061 28 Aug 18:43 setup.py
drwxr-xr-x  9 ctesibius  staff     288 28 Aug 18:43 src
drwxr-xr-x  6 ctesibius  staff     192 28 Aug 18:43 test
-rw-r--r--  1 ctesibius  staff     237 28 Aug 18:43 tree-sitter-gleam.pc
-rw-r--r--  1 ctesibius  staff     945 28 Aug 18:43 tree-sitter.json


ctesibius@tile tree-sitter-gleam % file libtree-sitter-gleam.dylib
libtree-sitter-gleam.dylib: Mach-O 64-bit dynamically linked shared library arm64

ctesibius@tile tree-sitter-gleam % cp libtree-sitter-gleam.dylib ~/.emacs.d/tree-sitter

At this point, Emacs stops emitting warnings and highlights a test Gleam language file correctly, so the work-around works.

Can anyone point me to where I should file a bug report for the underlying problem?

Some motorcycles use shaft drive rather than chain drive. In addition to the hinge point near the gearbox, modern designs have a second hinge point near the axis of the rear wheel. This is done so that a parallelogram linkage can be used to isolate the suspension from the effect of engine torque - without it, you can lose a significant amount of ground clearance if you back off the throttle in a corner. Externally, the rear hinge point is implemented as hinge in the shaft casing. Internally, the shaft has a simple universal joint in all cases that I have seen. While there is another UJ at the front of the shaft, the two do not operate together as a conventional constant velocity joint because the two points will commonly bend in opposite directions.

The rear UJ does not run in the oil bath of the rear bevel box because it has to move around, and depends on grease fitted at the factory. It is a known weak point: if the joint overheats and seizes, it can break, letting the remaining shaft thrash around and break the swinging arm, which can detach the rear wheel and introduce a sky-ground-sky scenario. BMW have introduced a free mileage-based replacement of the shaft for life on some models, and the problem is known to happen on other makes. While using a double Cardan joint would not solve the lubrication problem, it is said to be more suitable for high articulation angles. These tend to happen on bikes due to varying load and suspension movement. The shaft casings are made to have a large amount of internal room at this point to accommodate movement, so fitting a larger joint doesn't seem to be an obvious problem.

So in brief: is there some reason why simple UJs are used rather than constant velocity joints?