52 lines
		
	
	
	
		
			1.9 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			52 lines
		
	
	
	
		
			1.9 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| Alexandria is a collection of portable public domain utilities that
 | |
| meet the following constraints:
 | |
| 
 | |
|  * Utilities, not extensions: Alexandria will not contain conceptual
 | |
|    extensions to Common Lisp, instead limiting itself to tools and
 | |
|    utilities that fit well within the framework of standard ANSI
 | |
|    Common Lisp. Test-frameworks, system definitions, logging
 | |
|    facilities, serialization layers, etc. are all outside the scope of
 | |
|    Alexandria as a library, though well within the scope of Alexandria
 | |
|    as a project.
 | |
| 
 | |
|  * Conservative: Alexandria limits itself to what project members
 | |
|    consider conservative utilities. Alexandria does not and will not
 | |
|    include anaphoric constructs, loop-like binding macros, etc.
 | |
| 
 | |
|  * Portable: Alexandria limits itself to portable parts of Common
 | |
|    Lisp. Even apparently conservative and useful functions remain
 | |
|    outside the scope of Alexandria if they cannot be implemented
 | |
|    portably. Portability is here defined as portable within a
 | |
|    conforming implementation: implementation bugs are not considered
 | |
|    portability issues.
 | |
| 
 | |
| Homepage:
 | |
| 
 | |
|   http://common-lisp.net/project/alexandria/
 | |
| 
 | |
| Mailing lists:
 | |
| 
 | |
|   http://lists.common-lisp.net/mailman/listinfo/alexandria-devel
 | |
|   http://lists.common-lisp.net/mailman/listinfo/alexandria-cvs
 | |
| 
 | |
| Repository:
 | |
| 
 | |
|   git://gitlab.common-lisp.net/alexandria/alexandria.git
 | |
| 
 | |
| Documentation:
 | |
| 
 | |
|   http://common-lisp.net/project/alexandria/draft/alexandria.html
 | |
| 
 | |
|   (To build docs locally: cd doc && make html pdf info)
 | |
| 
 | |
| Patches:
 | |
| 
 | |
|   Patches are always welcome! Please send them to the mailing list as
 | |
|   attachments, generated by "git format-patch -1".
 | |
| 
 | |
|   Patches should include a commit message that explains what's being
 | |
|   done and /why/, and when fixing a bug or adding a feature you should
 | |
|   also include a test-case.
 | |
| 
 | |
|   Be advised though that right now new features are unlikely to be
 | |
|   accepted until 1.0 is officially out of the door.
 |