-
-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that non renderer systems compile on CL implementations #2662
Comments
Actually both |
Totally agree. |
Well, there are many prompter issues... https://github.com/atlas-engineer/nyxt/issues?q=is%3Aissue+is%3Aopen+label%3Aprompt-buffer |
There are only 2 issues that are both labelled as 3.0 and prompt buffer. The remaining prompt buffer issues should be moved to its new github repository. |
Yup, #2134 is very important and requires the major refactoring of switching from calispel to lparallel. In any case, all these issues can be done after the move to a separate repo, it's mostly that it'll be easier to close as many as possible now and not later, to avoid having to bump versions (Guix update, submodule update, etc.). |
Yes, that particular issue is perhaps the most important one. Also, perhaps not all of these prompt buffer issues are related to the library itself, but to prompt buffer and prompt buffer mode in the context of the |
Absolutely. |
This is an important goal, but it seems overkill to test every commit on all CL implementations. For each commit we test on SBCL and CCL (via the GitHub CI), which is already quite good. Maybe testing on more CL implementation should be a practice done exclusively before releasing major versions. |
By the way |
Not sure. Testing on every implementation ensures we're really portable and makes type, performance, and environment preconceptions much more explicit. And then, GitHub CI is free for open-source projects (which is a shaky ground to stand on—GitHub as a commercial entity can always break things and make them paid under our feet), so why not? :D |
This may be important at a later stage, when Nyxt reaches a more mature stage. In the near future, it is unlikely that Nyxt will be distributed with a CL implementation that isn't SBCL. We already test on CCL (which seems to have a stronger typing discipline) and that seems reasonable. The starting point to achieve this goal would be to target the CL libraries developed by @atlas-engineer/atlas. |
All of our non-renderer specific code should be portable across CL implementions.
Systems include:
nyxt
prompter
The implementations we should test with include (besides SBCL):
The text was updated successfully, but these errors were encountered: