Newer
Older
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
** extending defsystem with new options
You might not want to write a whole parser, but just to add options to
the existing syntax. Reinstate parse-option or something akin
** document all the error classes
** what to do with compile-file failure
Should check the primary return value from compile-file and see if
that gets us any closer to a sensible error handling strategy
** foreign files
lift unix-dso stuff from db-sockets
** Diagnostics
A ``dry run'' of an operation can be made with the following form:
@lisp
(traverse (make-instance '<operation-name>)
(find-system <system-name>)
'explain)
@end lisp
This uses unexported symbols. What would be a nice interface for this
functionality?
@node missing bits in implementation, Inspiration, TODO list, Top
@comment node-name, next, previous, up
@chapter missing bits in implementation
** all of the above
** reuse the same scratch package whenever a system is reloaded from disk
** rules for system pathname defaulting are not yet implemented properly
** proclamations probably aren't
** when a system is reloaded with fewer components than it previously
had, odd things happen
we should do something inventive when processing a defsystem form,
like take the list of kids and setf the slot to nil, then transfer
children from old to new list as they're found
** traverse may become a normal function
If you're defining methods on traverse, speak up.
** a lot of load-op methods can be rewritten to use input-files
so should be.
** (stuff that might happen later)
*** david lichteblau's patch for symlink resolution?
*** Propagation of the :force option. ``I notice that
(oos 'compile-op :araneida :force t)
also forces compilation of every other system the :araneida system
depends on. This is rarely useful to me; usually, when I want to force
recompilation of something more than a single source file, I want to
recompile only one system. So it would be more useful to have
make-sub-operation refuse to propagate @code{:force t} to other systems, and
propagate only something like @code{:force :recursively}.
Ideally what we actually want is some kind of criterion that says to
which systems (and which operations) a @code{:force} switch will
propagate.
The problem is perhaps that `force' is a pretty meaningless concept.
How obvious is it that @code{load :force t} should force
@emph{compilation}? But we don't really have the right dependency
setup for the user to compile @code{:force t} and expect it to work
(files will not be loaded after compilation, so the compile
environment for subsequent files will be emptier than it needs to be)
What does the user actually want to do when he forces? Usually, for
me, update for use with a new version of the lisp compiler. Perhaps
for recovery when he suspects that something has gone wrong. Or else
when he's changed compilation options or configuration in some way
that's not reflected in the dependency graph.
Other possible interface: have a 'revert' function akin to 'make clean'
@lisp
(asdf:revert 'asdf:compile-op 'araneida)
@end lisp
would delete any files produced by 'compile-op 'araneida. Of course, it
wouldn't be able to do much about stuff in the image itself.
How would this work?
traverse
There's a difference between a module's dependencies (peers) and its
components (children). Perhaps there's a similar difference in
operations? For example, @code{(load "use") depends-on (load "macros")} is a
peer, whereas @code{(load "use") depends-on (compile "use")} is more of a
`subservient' relationship.
@node Inspiration, Concept Index, missing bits in implementation, Top
@comment node-name, next, previous, up
@chapter Inspiration
@section mk-defsystem (defsystem-3.x)
We aim to solve basically the same problems as mk-defsystem does.
However, our architecture for extensibility better exploits CL
language features (and is documented), and we intend to be portable
rather than just widely-ported. No slight on the mk-defsystem authors
and maintainers is intended here; that implementation has the
unenviable task of supporting non-ANSI implementations, which I
propose to ignore.
The surface defsystem syntax of asdf is more-or-less compatible with
mk-defsystem
The mk-defsystem code for topologically sorting a module's dependency
list was very useful.
@section defsystem-4 proposal
Marco and Peter's proposal for defsystem 4 served as the driver for
many of the features in here. Notable differences are:
@itemize
@item
We don't specify output files or output file extensions as part of the
system.
If you want to find out what files an operation would create, ask the
operation.
@item
We don't deal with CL packages
If you want to compile in a particular package, use an in-package form
in that file (ilisp / SLIME will like you more if you do this anyway)
@item
There is no proposal here that defsystem does version control.
A system has a given version which can be used to check dependencies,
but that's all.
@end itemize
The defsystem 4 proposal tends to look more at the external features,
whereas this one centres on a protocol for system introspection.
@section kmp's ``The Description of Large Systems'', MIT AI Memu 801
Available in updated-for-CL form on the web at
@url{http://world.std.com/~pitman/Papers/Large-Systems.html}
In our implementation we borrow kmp's overall PROCESS-OPTIONS and
concept to deal with creating component trees from defsystem surface
syntax. [ this is not true right now, though it used to be and
probably will be again soon ]
@c -------------------
@node Concept Index, Function and Class Index, Inspiration, Top
@unnumbered Concept Index
@printindex cp
@node Function and Class Index, Variable Index, Concept Index, Top
@unnumbered Function and Class Index
@printindex fn
@node Variable Index, , Function and Class Index, Top
@unnumbered Variable Index
@printindex vr
@bye