Conversation
specializers were getting into method and generic lambda lists, and the latter was causing actual errors due to a-p-o functions.
we no longer give *print-pretty* a definition. Should we? I dunno, but in main it's defined in init.lisp which I'm avoiding. Source infos are physical pathnames right now which is wrong.
host (SBCL) fixnums were worming their way until my build, which screwed up typep of bignum
Trying to keep anything native code related in the cleavir/ directory.
Karsten's code is... pretty confused. I think this is cleaner.
rather than aesthetically, so they're easy to paste into a REPL.
was axing the ABORT restart in new threads. Also, unneeded now that bootstrapping is less bad
it's no longer necessary, and also incorrect w/r/t symbol macros.
boy that who-specializes stuff is misplaced
Leaving it as the standard was messing things up in Cleavir. Which definitely means Cleavir isn't fully ready for cross. Oh well
host (SBCL) doesn't have long float so literals don't work correctly. That's a larger problem so this isn't the best fix. cleavir-type.lisp also has some issues with this.
and lose setf-readtable-case in the eclector.readtable package, which was a weird thing for us to do honestly
Ideally the compiler would do this outside the call, at least for clasp-cleavir. And I've done some stuff in that direction but not very well, and anyway we have bytecode to worry about. So here's the dumb thing for now. copy-pprint-dispatch isn't exactly a hot function anyway.
this is essentially for the same problem as 40f044a, except that with compile-file-parallel we don't know not to increment the ID until further IDs have actually been assigned, so that solution is dead in the water. I think keeping an association between the bytecode module and its native module would be good, but we weren't doing that anyway. Maybe later.
fixes native build, which was giving an error about modules-boehmprecise not being a file, because the input was actually passed to the compilation script rather than only being there for dependency purposes.
as laboriously explained in the comment there was a problem with load-time-values in compile-file type checks being evaluated immediately, which would result in undumpable literals. Bleh. Now I'm just getting a compilation error which is frustrating but not the same so whatever. Also: The prevention of native compilation in ltv native literals appears to be actually required, which is probably bad. There's some problem with native module IDs getting reset.
This starts fixing the cando build.
needed a new build script
Doesn't actually fix the segfaults from autocompilation, but does mean i can compile-module #'= without everything breaking.
as discussed with yitzi (hopefully i got it right). Cando we generally are going to use with native compilation so test that. Autocompilation I'm turning off temporarily since it's segfaulting for inscrutable reasons.
this is the weird semantics of compile time defclass and I don't want to bother on the elaborate fix right now. having defclass define a class unconditionally at compile time would be an easy fix but has its own problems with nontrivial mop usage (#736).
the cross build makes more object files so we've been running out of root sets. Having one root set per CodeBlock may fix the problem although this will require a revisit if we ever manage a precise GC setup.
Ideally this will be temporary, once I fix the low hanging fruit issues like missing variables and catch/progv implementation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overhauls Clasp's build procedure. Instead of bootstrapping itself, another Lisp like SBCL loads a bytecode compiler (Maclina) and a specialized first class environment, and uses these to compile the Clasp library code into a bytecode FASL. This FASL can then be loaded by the Clasp C++ runtime which is mostly unchanged.
A "native" build in which Clasp itself is compiled by clasp-cleavir can be done by taking this bytecode FASL, loading that same specialized environment, and then using it to natively compile the Clasp library code. This produces a bytecode FASL with native versions of most functions through the b2b compiler; the native code is kept as attributes in the FASL.
This is mostly done but still needs a bit more work. In particular a few little things are probably still broken.
Other changes include:
ext:deoptimizecan be used to temporarily replace native-compiled functions with more debuggable bytecode versions