Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
asdf
ilc2010
Commits
b0a38790
Commit
b0a38790
authored
Sep 02, 2010
by
Francois-Rene Rideau
Browse files
Integrate feedback from Theam Yong Chew.
parent
a9e4696f
Changes
3
Hide whitespace changes
Inline
Side-by-side
Makefile
View file @
b0a38790
...
...
@@ -23,7 +23,7 @@ clean: semiclean
semiclean
:
-
rm
-f
${OBJ}
website
:
rsync main.pdf common-lisp.net:/project/asdf/public_html/ilc2010.pdf
website
:
main.pdf
rsync main.pdf common-lisp.net:/project/asdf/public_html/ilc2010
draft
.pdf
.PHONY
:
clean semiclean view website
main.tex
View file @
b0a38790
...
...
@@ -407,14 +407,16 @@ in addition to simple function definitions.
to use FASL files instead of recompiling the source code every time,
as some scripting languages do.
Modern Lisp implementations typically include some kind of compiler that
produces reasonably fast code, but take some time to optimize their output.
Some implementations (such as ECL) also include an interpreter simply evaluates
the input code more or less directly. This is practical for code that only gets
run once, while building or interactively. Other implementations (such as SBCL)
eschew an interpreter altogether. For such implementations, evaluation of an
interactive form is done by compiling it then immediately executing the compiled
code.
Modern Lisp implementations typically include
some kind of compiler that produces reasonably fast code,
but take some time to optimize their output.
Some implementations (such as ECL) also include
an interpreter that simply evaluates the input code more or less directly.
This is practical for code that only gets run once,
while building or interactively.
Other implementations (such as SBCL) eschew an interpreter altogether.
For such implementations, evaluation of an interactive form is done
by compiling it then immediately executing the compiled code.
Every implementation has a different format for fasl files,
reflecting different implementation strategies, etc.
...
...
@@ -473,13 +475,12 @@ For {\compileOp} operations on {\clSourceFile} components,
the file pointed to by the
\lisp
{
component-pathname
}
and write it to the
location pointed to by the
\lisp
{
output-files
}
generic function.
By defining an
\texttt
{
around
}
method for
\lisp
{
output-files
}
,
it is possible to redirect where
{
\ASDF
}
stores its outputs;
that methods may then use pathname transations.
for each operation to be
\lisp
{
perform
}
ed what
\lisp
{
output-files
}
there were,
applying some pathname translations to each of the considered pathnames and
substituting the translated pathnames for the original pathnames
when actually
\lisp
{
perform
}
ing the operation.
it is possible to redirect where
{
\ASDF
}
stores its outputs:
such a method may apply some pathname translations
to each of the considered pathnames and
substitute the translated pathnames for the original pathnames.
All
{
\ASDF
}
-defined
{
\perform
}
methods cooperate with this protocol,
and user-defined methods are expected to do so as well.
{
\longABL
}
(henceforth
{
\ABL
}
) was
a popular piece of software to redirect compiler output for
{
\ASDF
}
,
...
...
@@ -678,7 +679,7 @@ and either inherit system-provided configuration or override it,
depending on their needs.
In the end, the aim of our interface modifications was this
change in
the
how programmers interact with the machine and with each other,
change in how programmers interact with the machine and with each other,
smoothing the need for synchronization between experts
and lowering the barriers to entry for newbies.
...
...
@@ -1037,7 +1038,7 @@ composite {\step}s and their constituent sub-{\step}s.
A consequence of this design is that the
{
\step
}
corresponding to operating on the composite component
does not wrap
{
\em
around
}
the
{
\step
}
s involving its constituents,
but is only a synchronization mark scheduled
{
\em
after
}
all of them
;
but is only a synchronization mark scheduled
{
\em
after
}
all of them
.
The
{
\perform
}
method over such an
{
\step
}
does nothing.
So, in
{
\ASDFi
}
, if one was to (compile and) load system
...
...
upgrade.tex
View file @
b0a38790
...
...
@@ -374,7 +374,7 @@ However, it is possible to support dynamic code upgrade much better.
For instance, Erlang solves the issue of dynamic code upgrade
by providing syntactic distinction
between the two semantically different kinds of calls:
calls specifying a
n
syntactically unqualified identifier
calls specifying a syntactically unqualified identifier
are always semantically static calls (to a function in the same module),
and calls to a syntactically module-qualified identifier (even in the same module)
are always semantically dynamic calls.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment