Open eschaton opened 4 years ago
MCLIDE requires an older version of CCL from around the time it was implemented. It severely monkeypatches CCL for expediency; Unfortunately, that makes the code unlikely to be compatible with newer versions of CCL. The idea was to validate the value proposition and encourage changes to the internals of CCL that would make the functionality a clean addition.
I haven’t really looked at the code; why is that expedient? I’d just assumed MCLIDE was just implemented against CCL, and it was otherwise entirely a front-end to swank.
MCLIDE patches the CCL IDE itself to become a front-end to swank. It turns the CCL REPL to become a remote REPL for swank, and hooks into the various CCL menus and dialogs to communicate with the remote Lisp implementation instead of the local one. Etc.
Note the liberal use of the defcontextual macro to decorate/intercept various functionality in the CCL IDE, using advise
and :around
method definitions. These are likely to rot as CCL changes, and would have to be updated if MCLIDE were to work with the current version of CCL. The flexibility of Common Lisp can be a blessing... and a curse. ;-)
I tried to build MCLIDE today using the latest CCL 1.12 and SLIME 2.24 on my system. Unfortunately it encountered some errors. I didn’t follow the instructions exactly; I made a symlink to my
ccl
andslime
checkouts next to thebuild.sh
script. (I also had tochmod a+x
the script.)(Ignore the hash for CCL, I have a couple commits atop my CCL tree to do things like change the default font in the CCL IDE, so it won’t match anything in the public repository.)