Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
A
asdf
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jan Moringen
asdf
Commits
b8e92e30
Commit
b8e92e30
authored
22 years ago
by
Daniel Barlow
Browse files
Options
Downloads
Patches
Plain Diff
TODO stuff mostly
parent
7f8c2f0a
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
README
+51
-10
51 additions, 10 deletions
README
with
51 additions
and
10 deletions
README
+
51
−
10
View file @
b8e92e30
$Id: README,v 1.2
2
2002/08/2
3 20:54:08 kevinrosenberg
Exp $ -*- Text -*-
$Id: README,v 1.2
3
2002/08/2
8 12:33:26 dan_b
Exp $ -*- Text -*-
asdf: another system definition facility
...
...
@@ -39,12 +39,16 @@ a custom core, or something.
designators. A ssytem directory designator is either a function
designator for a function of one argument, which when called with
the system name will return a directory to look for .asd files in,
or it is a form which evaluates to a directory to look in.
Typically you might for example have
or it is a form which will be evaluated whenever a system is to be
found, and must evaluate to a directory to look in. For example,
you might have
(*default-pathname-defaults* "/home/me/cl/systems/"
"/usr/share/common-lisp/systems/")
(When we say "directory" here, we mean "designator for a pathname
with a supplied DIRECTORY component")
- To compile and load a system 'foo', you need to (1) ensure that
foo.asd is in one of the directories in *central-registry* (a
symlink to the real location of foo.asd is preferred), (2) execute
...
...
@@ -606,17 +610,25 @@ the existing syntax. Reinstate parse-option or something akin
** document all the error classes
** putting functions onto *central-registry* ?
** 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
For the benefit of people who don't want to keep all their systems in
the same place, we could
** Diagnostics
1) put functions onto *central-registry*. These would take the
syestem name as argument
A "dry run" of an operation can be made with the following form:
2) expose the system-definition-pathname function. Problem, it's
currently a function not a gf. What would it specialize on?
(traverse (make-instance '<operation-name>)
(find-system <system-name>)
'explain)
This uses unexported symbols. What would be a nice interface for this
functionality?
* missing bits in implementation
...
...
@@ -624,4 +636,33 @@ the same place, we could
** 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
** circularities may not be being detected as they should
** now
*** restarts may not be as visible as we'd like when chasing dependencies
*** some reasonably neat way to deal with this-file-already-loaded
perhaps compile-op/load-op perform after methods should be setting the
last-loaded and last-compiled properties?
*** better integration of load-binary-ignoring-state-of-source-op
** 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 ":force t" to other systems, and
propagate only something like ":force :recursively".
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment