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
asdf
Commits
0d60754a
Commit
0d60754a
authored
Aug 06, 2001
by
Daniel Barlow
Browse files
Rewrote the section on dependencies. Dependencies are now between
(operation component) pairs, not just components.
parent
9b286671
Changes
1
Hide whitespace changes
Inline
Side-by-side
README
View file @
0d60754a
asdf
:
another
system
definition
facility
-*-
Text
-*-
$
Id
:
README
,
v
1.
4
2001
/
08
/
0
3
01
:
1
3
:
30
dan_b
Exp
$
$
Id
:
README
,
v
1.
5
2001
/
08
/
0
6
01
:
1
0
:
05
dan_b
Exp
$
This
system
definition
utility
talks
in
terms
of
'components'
and
'operations'
.
...
...
@@ -93,17 +93,51 @@ happen one way or another.
This is a string. It must satisfy the restrictions imposed on a
portable pathname character.
[ This restriction is probably going away ]
*** a version identifier (optional, will default to parent'
s
version
)
This
is
used
by
the
check
-
component
-
version
operation
(
see
later
).
This
is
used
by
the
test
-
system
-
version
operation
(
see
later
).
***
dependencies
on
its
siblings
(
optional
but
often
necessary
)
This
slot
contains
a
list
whose
elements
are
each
names
of
siblings
,
or
lists
of
(
name
version
)
for
siblings
There
is
an
excitingly
complicated
relationship
between
the
initarg
and
the
method
that
you
use
to
ask
about
dependencies
Dependencies
are
between
(
operation
component
)
pairs
.
In
your
initargs
,
you
can
say
:
in
-
order
-
to
((
compile
-
system
(
load
-
system
"a"
"b"
)
(
compile
-
system
"c"
))
(
load
-
system
(
load
-
system
"foo"
)))
-
before
performing
the
compile
-
system
operation
on
this
component
,
we
must
perform
the
load
-
system
operation
on
each
of
"a"
and
"b"
,
and
before
performing
load
-
system
,
we
have
to
load
"foo"
This
is
pretty
similar
to
what
ACL
defsystem
does
.
mk
-
defsystem
is
less
general
:
it
has
an
implied
dependency
for
all
x
,
(
load
x
)
depends
on
(
compile
x
)
and
using
a
:
depends
-
on
argument
to
say
that
b
depends
on
a
_actually_
means
that
(
compile
b
)
depends
on
(
load
a
)
In
asdf
,
the
dependency
information
for
a
given
component
and
operation
can
be
queried
using
(
depends
-
on
operation
component
),
which
returns
a
list
((
load
-
system
"a"
)
(
load
-
system
"b"
)
(
compile
-
system
"c"
)
...)
[
this
will
change
.
Dependencies
are
between
(
component
operation
)
pairs
,
not
between
components
themselves
]
depends
-
on
can
be
subclassed
for
more
specific
component
/
operation
types
:
these
need
to
(
call
-
next
-
method
)
and
append
the
answer
to
their
dependency
,
unless
they
have
a
good
reason
for
completely
overriding
the
default
dependencies
(
If
it
weren
't for CLISP, we'
d
be
using
a
LIST
method
combination
to
do
this
transparently
.
But
,
we
need
to
support
CLISP
.
If
you
have
the
time
for
some
CLISP
hacking
,
I
'm sure they'
d
welcome
your
fixes
)
***
a
filesystem
location
...
...
@@ -303,7 +337,6 @@ the package that they evaluate defsystem forms in
<Krystof> You don'
t
want
to
have
(
defsystem
partition
...)
being
read
in
the
+
cl
-
user
package
<
rahul
>
hrm
<
Krystof
>
Because
that
will
intern
a
cl
-
user
:
partition
symbol
<
rahul
>
yeah
,
accidental
interning
could
be
a
problem
<
Krystof
>
Which
will
then
collide
with
the
partition
:
partition
symbol
...
...
@@ -318,28 +351,8 @@ with symbols and depend on :case :common to map them into customary case.
***
shortcut
to
setting
up
dependencies
using
:
serial
,
:
parallel
options
.
***
split
into
native
syntax
and
mixin
for
mk
-
syntax
extras
**
Argh
dependencies
.
Our
dependencies
are
conceptually
wrong
.
Dependencies
exist
between
the
application
of
operations
to
components
,
not
the
components
themselves
.
For
example
,
there
is
an
implied
dependency
in
mk
-
defsystem
for
all
x
,
(
load
x
)
depends
on
(
compile
x
)
and
specifying
that
b
depends
on
a
_actually_
means
that
(
compile
b
)
depends
on
(
load
a
)
We
currently
intend
to
do
something
rather
like
ACL
's defsystem :
:in-order-to (compile-system (load-system "a" "b")
load-system (load-system "foo"))
We can combine this with a gf that has methods specialised on
component and operation to augment the dependency list with "standard"
dependencies: e.g. in-order-to (load-system x), first (compile-system x)
***
reintroduce
:
depends
-
on
or
some
other
succint
form
of
dependency
specification
**
the
:
pathname
argument
is
misnamed
...
...
@@ -352,6 +365,9 @@ like a pathname, we shouldn't fool the user into thinking it is one
**
all
of
the
above
**
reuse
the
same
scratch
package
whenever
a
system
is
reloaded
from
disk
**
defsystem
syntax
for
EQL
methods
** dependency circularities: test it works
**
versions
**
traverse
this
operation
instantiation
thing
sucks
somewhat
,
as
we
don
't
transfer arguments in any meaningful way. if compile calls load calls
compile, how do we access the original proclamations?
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