tREADME - clic - Clic is an command line interactive client for gopher written … | |
git clone git://bitreich.org/clic/ git://hg6vgqziawt5s4dj.onion/clic/ | |
Log | |
Files | |
Refs | |
Tags | |
LICENSE | |
--- | |
tREADME (1910B) | |
--- | |
1 Alexandria is a collection of portable public domain utilities that | |
2 meet the following constraints: | |
3 | |
4 * Utilities, not extensions: Alexandria will not contain conceptual | |
5 extensions to Common Lisp, instead limiting itself to tools and | |
6 utilities that fit well within the framework of standard ANSI | |
7 Common Lisp. Test-frameworks, system definitions, logging | |
8 facilities, serialization layers, etc. are all outside the scope of | |
9 Alexandria as a library, though well within the scope of Alexandria | |
10 as a project. | |
11 | |
12 * Conservative: Alexandria limits itself to what project members | |
13 consider conservative utilities. Alexandria does not and will not | |
14 include anaphoric constructs, loop-like binding macros, etc. | |
15 | |
16 * Portable: Alexandria limits itself to portable parts of Common | |
17 Lisp. Even apparently conservative and useful functions remain | |
18 outside the scope of Alexandria if they cannot be implemented | |
19 portably. Portability is here defined as portable within a | |
20 conforming implementation: implementation bugs are not considered | |
21 portability issues. | |
22 | |
23 Homepage: | |
24 | |
25 http://common-lisp.net/project/alexandria/ | |
26 | |
27 Mailing lists: | |
28 | |
29 http://lists.common-lisp.net/mailman/listinfo/alexandria-devel | |
30 http://lists.common-lisp.net/mailman/listinfo/alexandria-cvs | |
31 | |
32 Repository: | |
33 | |
34 git://common-lisp.net/projects/alexandria/alexandria.git | |
35 | |
36 Documentation: | |
37 | |
38 http://common-lisp.net/project/alexandria/draft/alexandria.html | |
39 | |
40 (To build docs locally: cd doc && make html pdf info) | |
41 | |
42 Patches: | |
43 | |
44 Patches are always welcome! Please send them to the mailing list as | |
45 attachments, generated by "git format-patch -1". | |
46 | |
47 Patches should include a commit message that explains what's being | |
48 done and /why/, and when fixing a bug or adding a feature you should | |
49 also include a test-case. | |
50 | |
51 Be advised though that right now new features are unlikely to be | |
52 accepted until 1.0 is officially out of the door. |