I am trying to wrap my head around the internals of the Python
compiler, or at least the version of it in SBCL since I've found it to
be much easier to track the SBCL sources and they seem to be more
cleanly organized than CMUCL's.
What I'd really like to do is get into the compiler and take a look at
the internal data structures, such as with SLIME, to interactively see
what happens at each step of the way.
I've tried reading :trace-file output, but it leaves a lot out of the
process and in particular does not make clear where the initial
source-to-IR1 transformations come from. Reading the compiler sources
themselves makes it hard to find the connections between data
structures and translations, mostly because there is just so much
code.
Ideally, I'd like to be able to step through a call to the compiler,
watching which functions get called along the way and inspecting local
variables at each point.
Does anyone have pointers on getting an interactive handle on the
compiler internals? Thanks.
On Feb 26, 12:40 pm, Ari Johnson <·········@gmail.com> wrote:
> I am trying to wrap my head around the internals of the Python
> compiler, or at least the version of it in SBCL since I've found it to
> be much easier to track the SBCL sources and they seem to be more
> cleanly organized than CMUCL's.
>
> What I'd really like to do is get into the compiler and take a look at
> the internal data structures, such as with SLIME, to interactively see
> what happens at each step of the way.
>
> I've tried reading :trace-file output, but it leaves a lot out of the
> process and in particular does not make clear where the initial
> source-to-IR1 transformations come from. Reading the compiler sources
> themselves makes it hard to find the connections between data
> structures and translations, mostly because there is just so much
> code.
>
> Ideally, I'd like to be able to step through a call to the compiler,
> watching which functions get called along the way and inspecting local
> variables at each point.
>
> Does anyone have pointers on getting an interactive handle on the
> compiler internals? Thanks.
python is not quite lisp yet, give it a decade.....
gavino <·········@gmail.com> writes:
>> On Feb 26, 12:40 pm, Ari Johnson <·········@gmail.com> wrote:
>> I am trying to wrap my head around the internals of the Python
>> compiler, or at least the version of it in SBCL since I've found it to
>> be much easier to track the SBCL sources and they seem to be more
>> cleanly organized than CMUCL's.
>>
>> What I'd really like to do is get into the compiler and take a look at
>> the internal data structures, such as with SLIME, to interactively see
>> what happens at each step of the way.
>>
>> I've tried reading :trace-file output, but it leaves a lot out of the
>> process and in particular does not make clear where the initial
>> source-to-IR1 transformations come from. Reading the compiler sources
>> themselves makes it hard to find the connections between data
>> structures and translations, mostly because there is just so much
>> code.
>>
>> Ideally, I'd like to be able to step through a call to the compiler,
>> watching which functions get called along the way and inspecting local
>> variables at each point.
>>
>> Does anyone have pointers on getting an interactive handle on the
>> compiler internals? Thanks.
>
> python is not quite lisp yet, give it a decade.....
You've got the wrong Python. A basic knowledge of English would have
allowed you to understand that from what I wrote. What's
disappointing, though, is that nobody but gavino has responded so
far. :P
On Feb 26, 5:24 pm, Ari Johnson <·········@gmail.com> wrote:
> gavino <·········@gmail.com> writes:
> >> On Feb 26, 12:40 pm, Ari Johnson <·········@gmail.com> wrote:
> >> I am trying to wrap my head around the internals of the Python
> >> compiler, or at least the version of it in SBCL since I've found it to
> >> be much easier to track the SBCL sources and they seem to be more
> >> cleanly organized than CMUCL's.
>
> >> What I'd really like to do is get into the compiler and take a look at
> >> the internal data structures, such as with SLIME, to interactively see
> >> what happens at each step of the way.
>
> >> I've tried reading :trace-file output, but it leaves a lot out of the
> >> process and in particular does not make clear where the initial
> >> source-to-IR1 transformations come from. Reading the compiler sources
> >> themselves makes it hard to find the connections between data
> >> structures and translations, mostly because there is just so much
> >> code.
>
> >> Ideally, I'd like to be able to step through a call to the compiler,
> >> watching which functions get called along the way and inspecting local
> >> variables at each point.
>
> >> Does anyone have pointers on getting an interactive handle on the
> >> compiler internals? Thanks.
>
> > python is not quite lisp yet, give it a decade.....
>
> You've got the wrong Python. A basic knowledge of English would have
> allowed you to understand that from what I wrote. What's
> disappointing, though, is that nobody but gavino has responded so
> far. :P
Oh really? What exact part of english am I missing?
On Feb 26, 5:32 pm, gavino <·········@gmail.com> wrote:
> On Feb 26, 5:24 pm, Ari Johnson <·········@gmail.com> wrote:
>
>
>
> > gavino <·········@gmail.com> writes:
> > >> On Feb 26, 12:40 pm, Ari Johnson <·········@gmail.com> wrote:
> > >> I am trying to wrap my head around the internals of the Python
> > >> compiler, or at least the version of it in SBCL since I've found it to
> > >> be much easier to track the SBCL sources and they seem to be more
> > >> cleanly organized than CMUCL's.
>
> > >> What I'd really like to do is get into the compiler and take a look at
> > >> the internal data structures, such as with SLIME, to interactively see
> > >> what happens at each step of the way.
>
> > >> I've tried reading :trace-file output, but it leaves a lot out of the
> > >> process and in particular does not make clear where the initial
> > >> source-to-IR1 transformations come from. Reading the compiler sources
> > >> themselves makes it hard to find the connections between data
> > >> structures and translations, mostly because there is just so much
> > >> code.
>
> > >> Ideally, I'd like to be able to step through a call to the compiler,
> > >> watching which functions get called along the way and inspecting local
> > >> variables at each point.
>
> > >> Does anyone have pointers on getting an interactive handle on the
> > >> compiler internals? Thanks.
>
> > > python is not quite lisp yet, give it a decade.....
>
> > You've got the wrong Python. A basic knowledge of English would have
> > allowed you to understand that from what I wrote. What's
> > disappointing, though, is that nobody but gavino has responded so
> > far. :P
>
> Oh really? What exact part of english am I missing?
The part that allows you to recognize that in the fragment, "Python
compiler," the word "compiler" modifies the word "Python," making it
clear that the post was not about the python language, but about a
python compiler implemented in lisp (of which I know nothing about,
sorry).
On Feb 26, 5:42 pm, jc <··········@gmail.com> wrote:
> On Feb 26, 5:32 pm, gavino <·········@gmail.com> wrote:
>
>
>
> > On Feb 26, 5:24 pm, Ari Johnson <·········@gmail.com> wrote:
>
> > > gavino <·········@gmail.com> writes:
> > > >> On Feb 26, 12:40 pm, Ari Johnson <·········@gmail.com> wrote:
> > > >> I am trying to wrap my head around the internals of the Python
> > > >> compiler, or at least the version of it in SBCL since I've found it to
> > > >> be much easier to track the SBCL sources and they seem to be more
> > > >> cleanly organized than CMUCL's.
>
> > > >> What I'd really like to do is get into the compiler and take a look at
> > > >> the internal data structures, such as with SLIME, to interactively see
> > > >> what happens at each step of the way.
>
> > > >> I've tried reading :trace-file output, but it leaves a lot out of the
> > > >> process and in particular does not make clear where the initial
> > > >> source-to-IR1 transformations come from. Reading the compiler sources
> > > >> themselves makes it hard to find the connections between data
> > > >> structures and translations, mostly because there is just so much
> > > >> code.
>
> > > >> Ideally, I'd like to be able to step through a call to the compiler,
> > > >> watching which functions get called along the way and inspecting local
> > > >> variables at each point.
>
> > > >> Does anyone have pointers on getting an interactive handle on the
> > > >> compiler internals? Thanks.
>
> > > > python is not quite lisp yet, give it a decade.....
>
> > > You've got the wrong Python. A basic knowledge of English would have
> > > allowed you to understand that from what I wrote. What's
> > > disappointing, though, is that nobody but gavino has responded so
> > > far. :P
>
> > Oh really? What exact part of english am I missing?
>
> The part that allows you to recognize that in the fragment, "Python
> compiler," the word "compiler" modifies the word "Python," making it
> clear that the post was not about the python language, but about a
> python compiler implemented in lisp (of which I know nothing about,
> sorry).
LOL
bullsheep it makes it clear
that is a complete construction!
python has compilers you tool!!
On Feb 26, 8:44 pm, gavino <·········@gmail.com> wrote:
> LOL
> bullsheep it makes it clear
> that is a complete construction!
> python has compilers you tool!!
"Python" was the name used for the Common Lisp compiler developed at
CMU, resulting in CMUCL, which was forked to create SBCL.
Unfortunately, it was also the name Guido later chose for his
language.
P� Wed, 27 Feb 2008 02:44:30 +0100, skrev gavino <·········@gmail.com>:
>
> LOL
> bullsheep it makes it clear
> that is a complete construction!
> python has compilers you tool!!
Python is the Lisp compiler found in SBCL and CMUCL Common Lisp systems.
It predates the language Python with quite a few years.
--------------
John Thingstad
jc <··········@gmail.com> writes:
> On Feb 26, 5:32 pm, gavino <·········@gmail.com> wrote:
>> On Feb 26, 5:24 pm, Ari Johnson <·········@gmail.com> wrote:
>>
>>
>>
>> > gavino <·········@gmail.com> writes:
>> > >> On Feb 26, 12:40 pm, Ari Johnson <·········@gmail.com> wrote:
>> > >> I am trying to wrap my head around the internals of the Python
>> > >> compiler, or at least the version of it in SBCL since I've found it to
>> > >> be much easier to track the SBCL sources and they seem to be more
>> > >> cleanly organized than CMUCL's.
>>
>> > >> What I'd really like to do is get into the compiler and take a look at
>> > >> the internal data structures, such as with SLIME, to interactively see
>> > >> what happens at each step of the way.
>>
>> > >> I've tried reading :trace-file output, but it leaves a lot out of the
>> > >> process and in particular does not make clear where the initial
>> > >> source-to-IR1 transformations come from. Reading the compiler sources
>> > >> themselves makes it hard to find the connections between data
>> > >> structures and translations, mostly because there is just so much
>> > >> code.
>>
>> > >> Ideally, I'd like to be able to step through a call to the compiler,
>> > >> watching which functions get called along the way and inspecting local
>> > >> variables at each point.
>>
>> > >> Does anyone have pointers on getting an interactive handle on the
>> > >> compiler internals? Thanks.
>>
>> > > python is not quite lisp yet, give it a decade.....
>>
>> > You've got the wrong Python. A basic knowledge of English would have
>> > allowed you to understand that from what I wrote. What's
>> > disappointing, though, is that nobody but gavino has responded so
>> > far. :P
>>
>> Oh really? What exact part of english am I missing?
>
> The part that allows you to recognize that in the fragment, "Python
> compiler," the word "compiler" modifies the word "Python," making it
> clear that the post was not about the python language, but about a
> python compiler implemented in lisp (of which I know nothing about,
> sorry).
How about this part (I will put ^'s beneath the relevant words):
I am trying to wrap my head around the internals of the Python
^^^^^^
compiler, or at least the version of it in SBCL since I've found it to
^^^^^^^^ ^^^^^^^
be much easier to track the SBCL sources and they seem to be more
^^^^^^^^^^^^
cleanly organized than CMUCL's.
^^^^^
Python is the name of the compiler in CMUCL, inherited by SBCL when it
forked from CMUCL. The CMUCL compiler has been named Python since, I
believe, 1987.
According to Wikipedia, Python the programming language first appeared
in 1991.
Fortunately, most people who will have answers to my question need
only see two things to know what I'm talking about: "comp.lang.lisp"
and "Python internals." =)
On Feb 26, 6:10 pm, Ari Johnson <·········@gmail.com> wrote:
> jc <··········@gmail.com> writes:
> > On Feb 26, 5:32 pm, gavino <·········@gmail.com> wrote:
> >> On Feb 26, 5:24 pm, Ari Johnson <·········@gmail.com> wrote:
>
> >> > gavino <·········@gmail.com> writes:
> >> > >> On Feb 26, 12:40 pm, Ari Johnson <·········@gmail.com> wrote:
> >> > >> I am trying to wrap my head around the internals of the Python
> >> > >> compiler, or at least the version of it in SBCL since I've found it to
> >> > >> be much easier to track the SBCL sources and they seem to be more
> >> > >> cleanly organized than CMUCL's.
>
> >> > >> What I'd really like to do is get into the compiler and take a look at
> >> > >> the internal data structures, such as with SLIME, to interactively see
> >> > >> what happens at each step of the way.
>
> >> > >> I've tried reading :trace-file output, but it leaves a lot out of the
> >> > >> process and in particular does not make clear where the initial
> >> > >> source-to-IR1 transformations come from. Reading the compiler sources
> >> > >> themselves makes it hard to find the connections between data
> >> > >> structures and translations, mostly because there is just so much
> >> > >> code.
>
> >> > >> Ideally, I'd like to be able to step through a call to the compiler,
> >> > >> watching which functions get called along the way and inspecting local
> >> > >> variables at each point.
>
> >> > >> Does anyone have pointers on getting an interactive handle on the
> >> > >> compiler internals? Thanks.
>
> >> > > python is not quite lisp yet, give it a decade.....
>
> >> > You've got the wrong Python. A basic knowledge of English would have
> >> > allowed you to understand that from what I wrote. What's
> >> > disappointing, though, is that nobody but gavino has responded so
> >> > far. :P
>
> >> Oh really? What exact part of english am I missing?
>
> > The part that allows you to recognize that in the fragment, "Python
> > compiler," the word "compiler" modifies the word "Python," making it
> > clear that the post was not about the python language, but about a
> > python compiler implemented in lisp (of which I know nothing about,
> > sorry).
>
> How about this part (I will put ^'s beneath the relevant words):
>
> I am trying to wrap my head around the internals of the Python
> ^^^^^^
> compiler, or at least the version of it in SBCL since I've found it to
> ^^^^^^^^ ^^^^^^^
> be much easier to track the SBCL sources and they seem to be more
> ^^^^^^^^^^^^
> cleanly organized than CMUCL's.
> ^^^^^
>
> Python is the name of the compiler in CMUCL, inherited by SBCL when it
> forked from CMUCL. The CMUCL compiler has been named Python since, I
> believe, 1987.
>
> According to Wikipedia, Python the programming language first appeared
> in 1991.
>
> Fortunately, most people who will have answers to my question need
> only see two things to know what I'm talking about: "comp.lang.lisp"
> and "Python internals." =)
Ok you may have won the argument, but that doesn't mean I have to be
happy about it...
Ari Johnson wrote:
> You've got the wrong Python. A basic knowledge of English would have
> allowed you to understand that from what I wrote. What's
> disappointing, though, is that nobody but gavino has responded so
> far. :P
I think most people likely to know the answers are more often found on
the sbcl-devel list than here on c.l.l
https://lists.sourceforge.net/lists/listinfo/sbcl-devel ;; start here
-dan
Ari Johnson wrote:
> I am trying to wrap my head around the internals of the Python
> compiler, or at least the version of it in SBCL since I've found it to
> be much easier to track the SBCL sources and they seem to be more
> cleanly organized than CMUCL's.
>
> What I'd really like to do is get into the compiler and take a look at
> the internal data structures, such as with SLIME, to interactively see
> what happens at each step of the way.
>
> I've tried reading :trace-file output, but it leaves a lot out of the
> process and in particular does not make clear where the initial
> source-to-IR1 transformations come from. Reading the compiler sources
> themselves makes it hard to find the connections between data
> structures and translations, mostly because there is just so much
> code.
>
> Ideally, I'd like to be able to step through a call to the compiler,
> watching which functions get called along the way and inspecting local
> variables at each point.
>
> Does anyone have pointers on getting an interactive handle on the
> compiler internals? Thanks.
Not interactive, but have you found
http://sbcl-internals.cliki.net/index
and
http://sbcl.sourceforge.net/sbcl-internals/
?
- Daniel
D Herring <········@at.tentpost.dot.com> writes:
> Ari Johnson wrote:
>> I am trying to wrap my head around the internals of the Python
>> compiler, or at least the version of it in SBCL since I've found it to
>> be much easier to track the SBCL sources and they seem to be more
>> cleanly organized than CMUCL's.
>>
>> What I'd really like to do is get into the compiler and take a look at
>> the internal data structures, such as with SLIME, to interactively see
>> what happens at each step of the way.
>>
>> I've tried reading :trace-file output, but it leaves a lot out of the
>> process and in particular does not make clear where the initial
>> source-to-IR1 transformations come from. Reading the compiler sources
>> themselves makes it hard to find the connections between data
>> structures and translations, mostly because there is just so much
>> code.
>>
>> Ideally, I'd like to be able to step through a call to the compiler,
>> watching which functions get called along the way and inspecting local
>> variables at each point.
>>
>> Does anyone have pointers on getting an interactive handle on the
>> compiler internals? Thanks.
>
> Not interactive, but have you found
> http://sbcl-internals.cliki.net/index
> and
> http://sbcl.sourceforge.net/sbcl-internals/
Yeah - fairly limited as to the details of how the process works. I
want to see the structures in the inspector. The internals manual and
wiki are too high-level and not descriptive enough (not to mention
riddled with ambiguities and unexplained acronyms). On the other
hand, the source code itself is too low-level and verbose - you have
to read too much of it to understand how it fits together.
With live IR1 data and INSPECT, I'd be more able to poke and prod and
see snapshots of what actually goes on. That's what I think I am
missing to grok what's going on with blocks and nodes.
On Feb 26, 10:40 pm, Ari Johnson <·········@gmail.com> wrote:
> I am trying to wrap my head around the internals of the Python
> compiler, or at least the version of it in SBCL since I've found it to
> be much easier to track the SBCL sources and they seem to be more
> cleanly organized than CMUCL's.
>
> What I'd really like to do is get into the compiler and take a look at
> the internal data structures, such as with SLIME, to interactively see
> what happens at each step of the way.
>
> I've tried reading :trace-file output, but it leaves a lot out of the
> process and in particular does not make clear where the initial
> source-to-IR1 transformations come from. Reading the compiler sources
> themselves makes it hard to find the connections between data
> structures and translations, mostly because there is just so much
> code.
>
> Ideally, I'd like to be able to step through a call to the compiler,
> watching which functions get called along the way and inspecting local
> variables at each point.
>
> Does anyone have pointers on getting an interactive handle on the
> compiler internals? Thanks.
There is a document available online in the CMUCL web site at
http://www.cons.org/cmucl/doc/index.html (look for "internals").
Cheers
--
Marco
Marco Antoniotti <·······@gmail.com> writes:
> On Feb 26, 10:40�pm, Ari Johnson <·········@gmail.com> wrote:
> > I am trying to wrap my head around the internals of the Python
> > compiler, or at least the version of it in SBCL since I've found it to
> > be much easier to track the SBCL sources and they seem to be more
> > cleanly organized than CMUCL's.
> >
> > What I'd really like to do is get into the compiler and take a look at
> > the internal data structures, such as with SLIME, to interactively see
> > what happens at each step of the way.
> >
> > I've tried reading :trace-file output, but it leaves a lot out of the
> > process and in particular does not make clear where the initial
> > source-to-IR1 transformations come from. �Reading the compiler sources
> > themselves makes it hard to find the connections between data
> > structures and translations, mostly because there is just so much
> > code.
> >
> > Ideally, I'd like to be able to step through a call to the compiler,
> > watching which functions get called along the way and inspecting local
> > variables at each point.
> >
> > Does anyone have pointers on getting an interactive handle on the
> > compiler internals? �Thanks.
>
> There is a document available online in the CMUCL web site at
> http://www.cons.org/cmucl/doc/index.html (look for "internals").
The CMUCL-design.pdf section regarding the compiler is helpful, but
still too high-level and sometimes ambiguous regarding exactly what is
going on. I'm really looking for forms I can throw at SLIME to end up
in an inspector looking at the ICR/IR1 data structures that represent
my code.
The closest I've come so far goes like this:
(let* ((form '(lambda (n) (list n)))
(sb-c::*lexenv* (sb-c::make-null-lexenv))
(sb-c::*source-info* (sb-c::make-lisp-source-info form)))
(sb-c::with-ir1-namespace
(sb-c::ir1-toplevel form '(original-source-start 0 0) t)))
This code returns a SB-C::CLAMBDA structure that feels somewhat opaque
but is at least a starting point. Part of the problem is that it's so
hard to get at the intermediate functions between calling IR1-TOPLEVEL
and getting the CLAMBDA structure back.
Nathan Froyd <·······@gmail.com> writes:
> On Feb 27, 3:41 pm, Ari Johnson <·········@gmail.com> wrote:
>> The CMUCL-design.pdf section regarding the compiler is helpful, but
>> still too high-level and sometimes ambiguous regarding exactly what is
>> going on. I'm really looking for forms I can throw at SLIME to end up
>> in an inspector looking at the ICR/IR1 data structures that represent
>> my code.
>
> Juho Snellman's cl-dot package comes with an example file describing
> how to generate a graph for IR1. I hacked on it a year or two ago and
> got it to generate decent looking graphs. My code for doing so is
> below; I haven't tested it recently and I might have left it in a half-
> working state, soo..
>
> Find %COMPILE-COMPONENT in src/compiler/main.lisp and add these bits
> prior to the function:
>
> (defvar *generating-dot* nil)
> (defvar *draw-graphs* t)
>
> Then, in the body of %COMPILE-COMPONENT, add:
>
> (when (and (not *generating-dot*) *draw-graphs*)
> (let ((*generating-dot* t))
> (with-open-file (stream #p"/Users/froydnj/Documents/frob.dot"
> :direction :output :if-
> exists :supersede)
> (cl-dot:print-graph (cl-dot:generate-graph component)
> stream))))
>
> Pick a suitable output file. Note that I did this work on a Mac,
> where there's a super-convenient interface to graphviz that
> automagically redisplays a file if it notices that it's changed. So
> one can just load up that file and toggle back and forth between your
> SLIME window and the graphviz output.
>
> Of course, you'll want to have the appropriate cl-dot bits loaded,
> which you can find below.
>
> I usually stuck the function I wanted to look at into a file, and then
> ran COMPILE-FILE on that, so I could get the dot output and the trace
> file all at the same time. You could extend this to generate
> successive dumps after each round of optimization or type propagation,
> too.
>
> Hope this helps,
> -Nathan
I don't suppose you remember the procedure to get these things loaded
into SBCL? I thought about hacking it into the source around genesis
time, but cl-dot uses CLOS, which I don't believe to be available in
SB!C-land.
I really like this idea and am excited to get it up and running.
Thanks!
On Feb 27, 6:49 pm, Ari Johnson <·········@gmail.com> wrote:
> I don't suppose you remember the procedure to get these things loaded
> into SBCL? I thought about hacking it into the source around genesis
> time, but cl-dot uses CLOS, which I don't believe to be available in
> SB!C-land.
This is Lisp: it's OK to incrementally redefine bits of the compiler.
You just load the code into the image via C-M-x or what have you.
-Nathan
Nathan Froyd <·······@gmail.com> writes:
> On Feb 27, 6:49 pm, Ari Johnson <·········@gmail.com> wrote:
>> I don't suppose you remember the procedure to get these things loaded
>> into SBCL? I thought about hacking it into the source around genesis
>> time, but cl-dot uses CLOS, which I don't believe to be available in
>> SB!C-land.
>
> This is Lisp: it's OK to incrementally redefine bits of the compiler.
> You just load the code into the image via C-M-x or what have you.
src/compiler/main.lisp is defined in terms of (in-package "SB!C"), so
I was hoping for a way to avoid (load "src/cold/chill.lisp")
Ari Johnson <·········@gmail.com> writes:
> Nathan Froyd <·······@gmail.com> writes:
> > On Feb 27, 6:49 pm, Ari Johnson <·········@gmail.com> wrote:
> >> I don't suppose you remember the procedure to get these things loaded
> >> into SBCL? I thought about hacking it into the source around genesis
> >> time, but cl-dot uses CLOS, which I don't believe to be available in
> >> SB!C-land.
> >
> > This is Lisp: it's OK to incrementally redefine bits of the compiler.
> > You just load the code into the image via C-M-x or what have you.
>
> src/compiler/main.lisp is defined in terms of (in-package "SB!C"), so
> I was hoping for a way to avoid (load "src/cold/chill.lisp")
You do not need to do anything special, just C-c C-c the
function. Slime has magic to automatically install the SBCL bootstrap
packages and readtables for the duration of a compilation of a SBCL
source file.
--
Juho Snellman
On Feb 27, 8:47 pm, Juho Snellman <······@iki.fi> wrote:
> Ari Johnson <·········@gmail.com> writes:
> > src/compiler/main.lisp is defined in terms of (in-package "SB!C"), so
> > I was hoping for a way to avoid (load "src/cold/chill.lisp")
>
> You do not need to do anything special, just C-c C-c the
> function. Slime has magic to automatically install the SBCL bootstrap
> packages and readtables for the duration of a compilation of a SBCL
> source file.
If you didn't have slime available, you could create a new source file
that's (in-package :sb-c) and put the DEFVAR forms in there, along
with a cut-paste-and-modified version of %COMPILE-COMPONENT and load
that, too.
-Nathan