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
95b71bcf
Commit
95b71bcf
authored
11 years ago
by
Francois-Rene Rideau
Browse files
Options
Downloads
Patches
Plain Diff
By general demand, a README to UIOP.
parent
ab1522e8
No related branches found
No related tags found
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
bin/asdf-builder
+1
-1
1 addition, 1 deletion
bin/asdf-builder
uiop/README
+113
-0
113 additions, 0 deletions
uiop/README
with
114 additions
and
1 deletion
bin/asdf-builder
+
1
−
1
View file @
95b71bcf
...
@@ -138,7 +138,7 @@
...
@@ -138,7 +138,7 @@
(values)))
(values)))
(defun driver-files ()
(defun driver-files ()
(list* "uiop.asd" "asdf-driver.asd" (system-source-files :uiop)))
(list*
"README"
"uiop.asd" "asdf-driver.asd" (system-source-files :uiop)))
(defun driver-name ()
(defun driver-name ()
(format nil "uiop-~A" *version*))
(format nil "uiop-~A" *version*))
(defun make-driver-tarball ()
(defun make-driver-tarball ()
...
...
This diff is collapsed.
Click to expand it.
uiop/README
0 → 100644
+
113
−
0
View file @
95b71bcf
UIOP the Utilities for Implementation- and OS- Portability
==========================================================
UIOP is the portability layer of ASDF.
It provides utilities that abstract over discrepancies between implementations,
between operating systems, and between what the standard provides and
what programmers actually need, to write portable Common Lisp programs.
It is organized by topic in many files, each of which defines its own package
according to its topic: e.g pathname.lisp will define package UIOP/PATHNAME
and contain utilities related to the handling of pathname objects.
All exported symbols are reexported in a convenience package UIOP.
The files that constitute UIOP are, in order:
* package: to deal with packages and their symbols, most notably including
DEFINE-PACKAGE, a variant of defpackage capable of hot-upgrade.
* common-lisp: to let you paper over various sub-standard implementations
Corman, GCL, Genera, MCL are the biggest (unmaintained) offenders.
* utility: to provide macros and functions that do not involve I/O, handling
control-flow, (p)lists, character, strings, functions, classes, conditions,
"stamps" (number or boolean for +/- infinity), versions, etc.
It also sports uiop-debug, a useful tool to help you debug programs.
* os: to extract information from your environment, including
an API identifier, unix vs windows, getenv, hostname, getcwd and chdir, etc.
* pathname: to survive the gruesome non-portability trap that are CL pathnames
(and their lovecraftian "logical" variant), offering a vast array of functions
and a sensible, usable abstraction to specify relative pathnames.
* filesystem: to provide portable access to the filesystem, inspecting it,
only using truename when desired, using native OS namestrings,
atomic file renaming, creating or deleting directories, etc.
* stream: to portably deal with character encodings (external formats),
element types, safe READing and WRITEing, opening files or temporary files,
providing FORMAT-like designators for streams, flushing output buffers,
consuming or copying streams, concatenating files, copying files, etc.
* image: to portably deal with images, dumping them, restoring from them,
registering hooks to run at suitable events in the image lifetime,
printing backtraces, handling fatal conditions, using or avoiding debug modes,
accessing command line arguments or quitting the process.
* run-program: to portably spawn external processes and capture their output.
* lisp-build: to portably compile common-lisp code, handle compilation results,
muffle uninteresting conditions, save and restore deferred warnings,
run hooks around compilation (to e.g. control optimizations or syntax),
identify the pathname of the current file, combine FASLs, etc.
* configuration: to write portable configuration files, using best practices
to define and validate syntax, search standard paths,
let users specify pathnames or pathname patterns, etc.
* backward-driver: to provide backward-compatibility with earlier incarnations
of this library (i.e. ASDF internals that have leaked, or ASDF-UTILS)
* driver: to reexport all the above utilities in a single package UIOP.
Documentation
-------------
Each file starts with a package definition form that lists the exported symbols.
All the exported functions, macros and variables ought to have proper docstrings.
If not, then it's a legitimate bug that we invite you to report.
Maybe some automated tool will extract all that information and
make a webpage from it, at which point it would be nice to insert a link here.
Unhappily, at the time of this writing, quickdocs only extracts information
from the first package::
http://quickdocs.org/uiop/api
Using UIOP
----------
UIOP is part of ASDF 3, and any modern Common Lisp implementation
will have all of UIOP available when you (require "asdf").
NB: (require :asdf) also works on all implementations but CLISP.
If you need some functionality only available in a recent version of UIOP,
but cannot or will not upgrade ASDF, UIOP is also distributed separately;
see e.g. in Quicklisp. You may then have to load it like any other library::
(asdf:load-system :uiop)
If you want to use UIOP while preserving compatibility with ASDF 2,
we recommend that in your ASDF system definition you may use the like of::
:depends-on (#-asdf3 :uiop)
Some history
------------
UIOP, formerly known as ASDF-DRIVER (the package and system nicknames live on),
evolved from ASDF 2's internal utilities and portability layer.
It has since fully superseded functionality from the following libraries:
ASDF-UTILS (UIOP carries on the ASDF 2 utilities that this exported),
CL-FAD (UIOP's pathname and filesystem functions are much more portable),
CL-LAUNCH (UIOP took its image and command-line argument handling from it),
EXTERNAL-PROGRAM, TRIVIAL-SHELL and XCVB-DRIVER (UIOP's run-program is better),
SLIME's swank-loader (UIOP has better compilation and API identification),
TRIVIAL-BACKTRACE (UIOP/IMAGE has all of it and more), etc.
UIOP also captures a large subset of the functionality from TRIVIAL-FEATURES,
and a small subset of the functionality from ALEXANDRIA.
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