[Sbcl-commits] CVS: sbcl/contrib README,1.1.1.1,1.2 STANDARDS,1.2,1.3

[Daniel B. <da...@us...>]

Update of /cvsroot/sbcl/sbcl/contrib
In directory sc8-pr-cvs1:/tmp/cvs-serv32236/contrib

Modified Files:
	README STANDARDS 
Log Message:
0.8.4.25
	Update text files in contrib/ directory




Index: README
===================================================================
RCS file: /cvsroot/sbcl/sbcl/contrib/README,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -d -r1.1.1.1 -r1.2
--- README	18 Sep 2000 01:30:53 -0000	1.1.1.1
+++ README	16 Oct 2003 12:03:32 -0000	1.2
@@ -1,14 +1,28 @@
 This directory is for extensions to SBCL. They aren't necessary for
 core SBCL functionality, or else they'd be built into the main SBCL
 binary automatically. And they're not portable Common Lisp, or they'd
-be put elsewhere (e.g. http://clocc.sourceforge.net/).
+be put elsewhere (see http://sbcl.sf.net/libs.php for pointers)
+
+There are two kinds of contrib module in this directory:
+
+  * Newer contrib modules conform to the contrib standard (see 
+    STANDARDS) and are automatically built and installed along with
+    SBCL itself.  Each of these is in its own subdirectory with a
+    Makefile, and can be loaded with REQUIRE
+
+    Many of them use ASDF, so you have to require that first: e.g.
+
+        * (require 'asdf)
+        * (require 'sb-bsd-sockets)
+
+  * Older standalone files are effectively unpackaged and may or may 
+    not work with the current SBCL version.
 
 Some good candidates for future extensions here are:
   * bindings to existing foreign libraries (e.g. to a regexp library
     like PCRE, or to a compression library like zlib, or to a graphics
     library like Tk)
-  * new libraries (e.g. a CORBA interface, or a port of the CMU CL
-    POSIX functions, or a new higher-level POSIX functions)
+  * new libraries (e.g. a CORBA interface)
   * low-level hooks into SBCL needed to interface it to some wrapper
     system (e.g. to interface to a graphical debugger of some sort)
   * a too-alpha-to-be-supported-yet tree shaker
@@ -17,5 +31,5 @@
 interface of the Oracle RDBMS, or particularly large extensions, e.g.
 big graphics frameworks, can also be associated with the SBCL project,
 but instead of being included in this directory as part of the
-distribution, they will be made available on the SBCL project web
-site.
+distribution, they will be made available or linked to on the SBCL
+project web site.

Index: STANDARDS
===================================================================
RCS file: /cvsroot/sbcl/sbcl/contrib/STANDARDS,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- STANDARDS	7 Feb 2003 17:11:44 -0000	1.2
+++ STANDARDS	16 Oct 2003 12:03:32 -0000	1.3
@@ -1,6 +1,6 @@
 Proposed contrib standard, version $Revision$
 
-The SBCL contrib mechanism is intended to provide a mechanism to
+The SBCL contrib mechanism provides a mechanism to
 manage code which does not form part of SBCL itself, but which is
 sufficiently closely associated with it that it would not be sensible
 to run it as a completely separate project.  For example, alternative
@@ -21,10 +21,9 @@
 against a given version of SBCL will not be installed in that release.
 
 Note that despite leaving you the contrib maintainer with the
-responsibility of maintenance, we don't _necessarily_ (although we
-quite possibly would) offer you CVS access to the SBCL tree.  This is
-because we can't do that without letting you write to the rest of the
-tree as well (at least as far as I know, at sourceforge).  
+responsibility of maintenance, it doesn't follow that we'd
+_necessarily_ offer you CVS access to the SBCL tree: each application
+is considered individually.  We often do, though.
 
 ** Release cycle
 
@@ -93,5 +92,5 @@
 preserved.  If in doubt, seek consensus on the sbcl-devel list
 
 A contrib must load into its own Lisp package(s) instead of polluting
-CL-USER or one of the system packages.  The Lisp package name should
+CL-USER or one of the system packages.  The Lisp package names should
 begin with "SB-".  Ask the sbcl-devel list for a suitable name.