Open eschulte opened 2 years ago
I'm of the opinion that it would be better to modify cl-tree-sitter to not need the CFFI fork than to maintain our own.
If we're going to monkey with cffi, can we look into efficiency? I'm seeing as much as 75% of the time during a parse being spent in cffi interface code.
If it's possible and reasonably easy to modify cl-tree-sitter so it can use the upstream cffi then I agree that definitely sounds preferable. I haven't looked at any of the cl-tree-sitter CFFI calls and don't know anything of the content of the CFFI fork used by cl-tree-sitter. I suspect death would be supportive as they don't seem excited about maintaining CFFI forks.
https://github.com/death/cl-tree-sitter/pull/8 We've made some changes to make cl-tree-sitter work with stock CFFI.
To load CFFI (and thus SEL) on a Mac M1 the latest changes from the main CFFI branch are required. Unfortunately death doesn't want to merge those into their fork of CFFI used by SEL. They suggest (see https://github.com/death/cffi/pull/2#issuecomment-1221834971) maintaining a fork of CFFI with these changes and any others needed by SEL. You're welcome to use the fork I've started for this purpose (https://github.com/eschulte/cffi) or maybe you'd rather host one under GrammaTech on GitHub.