cl-net-snmp-general Mailing List for Common Lisp SNMP (Page 5)
Brought to you by:
binghe
Menu
▾
▴
cl-net-snmp-general — cl-net-snmp general
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(4) |
Apr
(5) |
May
|
Jun
|
Jul
(5) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(22) |
Feb
(20) |
Mar
|
Apr
(2) |
May
(25) |
Jun
(1) |
Jul
(17) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Chun T. (binghe) <bin...@gm...> - 2008-10-28 13:31:22
|
News in SNMP 5.16 * (SNMPv3 fix) Update session when remote peer changed (get a new report), and resend current SNMPv3 query message. News in ASN.1 4.12 * Unknown asn.1 data will be decoded into RAW object but NIL * Multiple OID display (PRINT-OBJECT) enhancements * Condition-friendly OID function News in USOCKET-UDP 2.3 * New platform: Scieneer CL (need a udp-patch from SCL maintainer,) * Souce code align to usocket-0.4.0, the first usocket release which support WAIT-FOR-INPUT. * Drop dependency on LispWorks-UDP package. Download * https://sourceforge.net/project/showfiles.php?group_id=209101 * (ASDF-INSTALL:INSTALL :SNMP) --binghe |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-10-01 09:05:32
|
Hi, Lispers I never give up making my cl-net-snmp project better and better. Now there're some roadmap to be published: [new features will be in next cl-net-snmp 5.x release] * New function SNMP-OPERATION, this new function can do multiple SNMP operation (many session and many PDU) at the same time, which can take performance burst when retrieving status from hundreds of remote agents together. To implement this feature, the USOCKET-UDP package need to be changed to support "Congestion Avoidance and Control" which existed in TCP stack. Because if we send thousands of UDP packets suddenly, bad things maybe happen to your LAN or switch device. * VACM (View-based Access Control Model) in SNMP-SERVER, another big step towards a well-implemented lisp-based SNMP Server. But I still cannot support SNMPv3 on this time (version 5.x) because it's quite low-priority behind other part. * Better condition support on both client side and server side. On client side, any SNMP operation should return correct condition according to the ERROR-STATUS in SNMP PDUs; On server side, wrong- formated SNMP client packets will not bring any CONDITION to SNMP- SERVER's code. Instead, any client error will record into SNMP's own MIB variables. [new features will be in cl-net-snmp 6.0 release] * Real ASN.1 compiler support: All type definition in SNMP MIB files will be well compiled into CLOS class-definition. This will let SNMP- GET to know some return value of type OCTET STRING is actually a "Physical Address" object and coerce them into correct type. This can be a very hard job since no one ever considered before how to map the full ASN.1 into Common Lisp! (but since CORBA is already successful mapped into Common Lisp, ASN.1 will be too, I think.) * Map ASN.1 Module into Common Lisp packages. In cl-net-snmp 3.x and 5.x, all ASN.1 variables are defined in ASN.1 package, this will cause some issues, which the biggest one is that "there's no way to define two MIB node which have the same name". ASN.1 specification doesn't forbidden the existence of OID with same name but different position in MIB tree. To support this, I must define more packages to hold object id symbols. Again, this is very hard since many ASN.1 definition files is not write full correct: they always use symbol which haven't imported correctly. [news in usocket-udp and lispworks-udp] The USOCKET author has started to request for my SVN commit access. After the response of Common-Lisp.net Administrator, I'll commit all my UDP changes into one branch of USOCKET project and work with Erik (the USOCKET auther) to make it better. Maybe in the 0.5.x release (still far away), USOCKET will have full UDP support and can be used directly by my SNMP package without standalone USOCKET-UDP. LispWorks-UDP package has been considered by some people whom need UDP networking on LispWorks. I'm trying to bring more features into this package: ICMP, UDP Multicast and UNIX Domain Socket. Once done, LispWOrks-UDP will have the 4.0 release, and these new features will be tried to merge into USOCKET project and make other CL platforms share the same API. [papers on ILC 2009] I'll try to publish a paper on ILC 2009 about my work on ASN.1 and SNMP, and this will be the first document on how to use these packages (without read source code first). Time is limited, I'm not sure if I can finish it before deadline (but will do my best). ---------------------- Finally, thanks to many Lispers who ever use my packages or give suggestions. Regards, Chun Tian (binghe) NetEase.com, Inc. |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-09-24 11:09:37
|
A.T.T. 下面是被转发的邮件： > 发件人: "Chun Tian (binghe)" <bin...@gm...> > 日期: 2008年9月24日 下午06时52分14秒 > 收件人: bin...@gm... > 主题: [ann] cl-net-snmp 5.5 > > Hi, Lispers > > New cl-net-snmp updates available! > > cl-net-snmp project is the pure-lisp implementation of SNMP (Simple > Network Management Protocol, RFC 2570) in both client and server-side. > > New features: > > * [snmp 5.5] LISP-MIB change: add lispFeatureTable and > lispPackageTable > * [snmp-server 3.0] Full snmp-walk support added > * [asn.1 4.5] Add some new OID functions mainly for snmp-server > * [usocket-udp 2.2] bugfix > * [lispworks-udp 3.2] performance burst and bugfix > > MIB for Common Lisp: > > Months ago, I registered an new IANA enterprise number (31609) for > Lisp itself. I hope this will be a good start for bring Common Lisp > based > applications into industry-standard network monitor platform. > In the future, some server-side lisp projects such as CL-HTTP and > Hunchentoot can be monitored by third-part SNMP-based management > software by using MIB definitions from cl-net-snmp. At current, these > MIB files are in #p"SNMP:SERVER;MIB;" directory, or you can download > the main LISP-MIB.txt here: > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk/server/mib/LISP-MIB.txt > > Participation and suggestions are welcome, I hope someone could work > with me together to make it better. > > Download: > > You can use ASDF-INSTALL to install cl-net-snmp 5.5, or download from > Sourceforge.net: > > http://sourceforge.net/project/showfiles.php?group_id=209101 > > You may need following packages with version requiement: > > snmp (>= 5.5), > asn.1 (>= 4.5), > usocket-udp (>= 2.2), > lispworks-udp (>= 3.2, only useful on LispWorks) > > ASDF Dependency: > > * ironclad > * usocket (0.4.x or trunk, current release 0.3.x cannot use) > * trivial-gray-streams > * ieee-floats > > Current Supported Platforms: > > * LispWorks (include win32) > * CMUCL (version after 2008-8 snapshot) > * SBCL > * Clozure CL (64-bit) > * Allegro CL > > Sample Usage: > > Start from cl-net-snmp 5.5, you can see all *features* and packages > in your > lisp image when doing snmp-walk on "lispSystem" MIB: (for example, a > snmp server running in Clozure CL) > > Lisp side: (start up a snmp server on 0.0.0.0:6161) > > ? (asdf:oos 'asdf:load-op :snmp-server) > ? (snmp:enable-snmp-service) > #<SNMP-SERVER SNMP Server at NIL:8161> > > UNIX side: (do a snmp-walk on the snmp server) > > $ snmpwalk -v 2c -c public localhost:8161 lispSystem > LISP-MIB::lispImplementationType.0 = STRING: "Clozure Common Lisp" > LISP-MIB::lispImplementationVersion.0 = STRING: "Version 1.2-r10805- > trunk (DarwinX8664)" > LISP-MIB::lispLongSiteName.0 = STRING: "unspecified" > LISP-MIB::lispShortSiteName.0 = STRING: "unspecified" > LISP-MIB::lispMachineInstance.0 = STRING: "binghe-mac.people.163.org" > LISP-MIB::lispMachineType.0 = STRING: "i386" > LISP-MIB::lispMachineVersion.0 = STRING: "MacBookPro3,1" > LISP-MIB::lispSoftwareType.0 = STRING: "Darwin" > LISP-MIB::lispSoftwareVersion.0 = STRING: "9.5.0" > LISP-MIB::lispInternalRealTime.0 = INTEGER: 154845250 > LISP-MIB::lispInternalRunTime.0 = INTEGER: 1823243 > LISP-MIB::lispInternalTimeUnitsPerSecond.0 = INTEGER: 1000000 > LISP-MIB::lispUniversalTime.0 = INTEGER: 1000000 > LISP-MIB::lispFeatureName.1 = STRING: "PORTABLE-THREADS-2.3" > LISP-MIB::lispFeatureName.2 = STRING: "PORTABLE-THREADS" > LISP-MIB::lispFeatureName.3 = STRING: "SPLIT-SEQUENCE" > LISP-MIB::lispFeatureName.4 = STRING: "CL-FAD" > LISP-MIB::lispFeatureName.5 = STRING: "ASDF" > LISP-MIB::lispFeatureName.6 = STRING: "PRIMARY-CLASSES" > LISP-MIB::lispFeatureName.7 = STRING: "COMMON-LISP" > LISP-MIB::lispFeatureName.8 = STRING: "OPENMCL" > LISP-MIB::lispFeatureName.9 = STRING: "CCL" > LISP-MIB::lispFeatureName.10 = STRING: "CCL-1.2" > LISP-MIB::lispFeatureName.11 = STRING: "CLOZURE" > LISP-MIB::lispFeatureName.12 = STRING: "CLOZURE-COMMON-LISP" > LISP-MIB::lispFeatureName.13 = STRING: "ANSI-CL" > LISP-MIB::lispFeatureName.14 = STRING: "UNIX" > LISP-MIB::lispFeatureName.15 = STRING: "OPENMCL-UNICODE-STRINGS" > LISP-MIB::lispFeatureName.16 = STRING: "OPENMCL-NATIVE-THREADS" > LISP-MIB::lispFeatureName.17 = STRING: "OPENMCL-PARTIAL-MOP" > LISP-MIB::lispFeatureName.18 = STRING: "MCL-COMMON-MOP-SUBSET" > LISP-MIB::lispFeatureName.19 = STRING: "OPENMCL-MOP-2" > LISP-MIB::lispFeatureName.20 = STRING: "OPENMCL-PRIVATE-HASH-TABLES" > LISP-MIB::lispFeatureName.21 = STRING: "X86-64" > LISP-MIB::lispFeatureName.22 = STRING: "X86_64" > LISP-MIB::lispFeatureName.23 = STRING: "X86-TARGET" > LISP-MIB::lispFeatureName.24 = STRING: "X86-HOST" > LISP-MIB::lispFeatureName.25 = STRING: "X8664-TARGET" > LISP-MIB::lispFeatureName.26 = STRING: "X8664-HOST" > LISP-MIB::lispFeatureName.27 = STRING: "DARWIN-HOST" > LISP-MIB::lispFeatureName.28 = STRING: "DARWIN-TARGET" > LISP-MIB::lispFeatureName.29 = STRING: "DARWINX86-TARGET" > LISP-MIB::lispFeatureName.30 = STRING: "DARWINX8664-TARGET" > LISP-MIB::lispFeatureName.31 = STRING: "DARWINX8664-HOST" > LISP-MIB::lispFeatureName.32 = STRING: "POWEROPEN-TARGET" > LISP-MIB::lispFeatureName.33 = STRING: "64-BIT-TARGET" > LISP-MIB::lispFeatureName.34 = STRING: "64-BIT-HOST" > LISP-MIB::lispFeatureName.35 = STRING: "LITTLE-ENDIAN-TARGET" > LISP-MIB::lispFeatureName.36 = STRING: "LITTLE-ENDIAN-HOST" > LISP-MIB::lispFeatureName.37 = STRING: "DARWIN" > LISP-MIB::lispPackageName.1 = STRING: "SNMP" > LISP-MIB::lispPackageName.2 = STRING: "PORTABLE-THREADS" > LISP-MIB::lispPackageName.3 = STRING: "IRONCLAD" > LISP-MIB::lispPackageName.4 = STRING: "ASN.1" > LISP-MIB::lispPackageName.5 = STRING: "USOCKET" > LISP-MIB::lispPackageName.6 = STRING: "SPLIT-SEQUENCE" > LISP-MIB::lispPackageName.7 = STRING: "TRIVIAL-GRAY-STREAMS" > LISP-MIB::lispPackageName.8 = STRING: "IEEE-FLOATS" > LISP-MIB::lispPackageName.9 = STRING: "TRIVIAL-GRAY-STREAMS-SYSTEM" > LISP-MIB::lispPackageName.10 = STRING: "IEEE-FLOATS-SYSTEM" > LISP-MIB::lispPackageName.11 = STRING: "IRONCLAD-TESTS" > LISP-MIB::lispPackageName.12 = STRING: "IRONCLAD-SYSTEM" > LISP-MIB::lispPackageName.13 = STRING: "SPLIT-SEQUENCE-SYSTEM" > LISP-MIB::lispPackageName.14 = STRING: "USOCKET-SYSTEM" > LISP-MIB::lispPackageName.15 = STRING: "SNMP-SYSTEM" > LISP-MIB::lispPackageName.16 = STRING: "CL-FAD-TEST" > LISP-MIB::lispPackageName.17 = STRING: "CL-FAD" > LISP-MIB::lispPackageName.18 = STRING: "ASDF" > LISP-MIB::lispPackageName.19 = STRING: "COMMON-LISP-USER" > LISP-MIB::lispPackageName.20 = STRING: "OPENMCL-MOP" > LISP-MIB::lispPackageName.21 = STRING: "ANSI-LOOP" > LISP-MIB::lispPackageName.22 = STRING: "INSPECTOR" > LISP-MIB::lispPackageName.23 = STRING: "ARCH" > LISP-MIB::lispPackageName.24 = STRING: "X86" > LISP-MIB::lispPackageName.25 = STRING: "X8632" > LISP-MIB::lispPackageName.26 = STRING: "OPENMCL-SOCKET" > LISP-MIB::lispPackageName.27 = STRING: "GRAY" > LISP-MIB::lispPackageName.28 = STRING: "SETF" > LISP-MIB::lispPackageName.29 = STRING: "COMMON-LISP" > LISP-MIB::lispPackageName.30 = STRING: "CCL" > LISP-MIB::lispPackageName.31 = STRING: "KEYWORD" > LISP-MIB::lispPackageName.32 = STRING: "X8664" > LISP-MIB::lispPackageName.33 = STRING: "X86-DARWIN64" > > Regards, > > Chun Tian (binghe) > |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-09-08 06:43:15
|
Hi, cl-net-snmp users After one and a half year since I started this project (0.01 on May 2007, 1.2 on Oct 2007, 3.0 on July 21), I'm glad to release cl-net-snmp 5.0 today, the pure-lisp implementation of Simple Network Management Protocol (RFC 2570). This project is part of my big plan: write a new system administration platform (like HP OpenView) completely in Common Lisp. New feature in 5.0: * Portable SNMP Server (snmp-server 2.0). * Auto-learn UDP timeout and retransmit support based on algorithms from TCP (usocket-udp 2.1). * Many bugfix include SNMPv3 support and thread-safe. * Seprate ASDF files: snmp.asd, snmp-server.asd, snmp-test.asd SourceForge Project Home: http://sourceforge.net/projects/cl-net-snmp Project Dependency: * ironclad * usocket (0.4.x or trunk, current release (0.3.x) cannot use) * trivial-gray-streams * ieee-floats * portable-threads (from GBBopen project) Current Supported Platforms: * LispWorks (include win32) * CMUCL * SBCL * Clozure CL (64-bit) * Allegro CL Features: * Full SNMP protocol support (SNMPv1, SNMPv2c, SNMPv3) * Support MIB and ASN.1 object id names * Fast BER encode/decode based on CLOS * UDP retransmit support * Simple SNMP Server * [LispWorks] GUI MIB Browser Documents: Still in progess. At current, you can see sample usage from test directory. If any user still get confused, feel free to ask me through email. Download: You can use ASDF-INSTALL to install cl-net-snmp 5.0, or download from Sourceforge.net: (newest version in each sub-project except onlisp-cn) http://sourceforge.net/project/showfiles.php?group_id=209101 I'm glad to hear at least one corpration use my SNMP package for monitoring remote UNIX servers in their lisp product. I hope more lispers use my software and report any bug or suggestion back to me. Regards, Chun Tian (binghe) |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-08-11 06:09:18
|
Hi, Ingvar Thanks for the patch. I think just replace *load-pathname* to *load- truename* is OK. I'll merge this fix in next release. Currently I'm working on another big release of cl-net-snmp, a little API change, and some new features: * Portable SNMP server (can be used to receive SNMP trap/inform) * Better condition handling when doing ASN.1 and SNMP jobs. * SNMP access detect: snmp-set to a readonly OID can be denied without networking. * Many bugfixes from my users. * Optimize: parallel SNMP operations and BER encode. I'll glad to receive more bug-report and suggestion from you and your NOCtool project. Regards, Chun Tian (binghe) 在 2008-8-11，下午1:55， Ingvar 写道： > Hiya, I finally have some spare time and am now looking at making > NOCtool use > CL-Net-SNMP for assorted probing. However, as-is, the ASDF system > definition > file is not entirely happy with symlinks back and forth. > > So, here's a patch to make it so: > --- snmp.asd 2008-08-11 06:45:32.000000000 +0100 > +++ snmp.asd 2008-08-11 06:46:38.000000000 +0100 > @@ -29,7 +29,7 @@ > (s (let ((file (merge-pathnames > (make- > pathname :name "mib" > :type > "lisp-expr") > - *load-pathname*))) > + (truename *load- > pathname*)))) > (format t ";; Load MIB list > from ~A~%" file) > file) :direction :input) > (let ((mibs (read s))) > > |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-08-11 05:09:43
|
Hi, David
This is a trivial bug when using sbcl + asdf-install, you just need to
change snmp.asd a little:
Index: snmp.asd
===================================================================
--- snmp.asd (revision 441)
+++ snmp.asd (working copy)
@@ -29,7 +29,7 @@
(s (let ((file (merge-pathnames
(make-pathname :name "mib"
:type "lisp-expr")
- *load-pathname*)))
+ *load-truename*)))
(format t ";; Load MIB list
from ~A~%" file)
file) :direction :input)
(let ((mibs (read s)))
Regards,
Chun Tian (binghe)
在 2008-8-11，下午12:13， David Leimbach 写道：
> Hi,
>
> I'm trying to install the asdf package cl-net-snmp, and it's failing
> with:
>
> debugger invoked on a SB-INT:SIMPLE-FILE-ERROR:
> error opening #P"/usr/local/lib/sbcl/site-systems/mib.lisp-expr":
> No such file or directory
>
>
> I tried to just "touch" this file, but it's not liking it being
> empty either. Is there something I forgot to do or is the package
> just a bit buggy for systems that don't have this file?
>
> Dave
|
|
From: Chun T. (binghe) <bin...@gm...> - 2008-08-04 06:14:05
|
binghe@binghe-mac:~$ snmpwalk -v 2c -c public localhost:8161 system SNMPv2-MIB::sysDescr.0 = STRING: LispWorks Personal Edition 5.1.1 SNMPv2-MIB::sysObjectID.0 = OID: LISP-MIB::clNetSnmpAgentLispWorks DISMAN-EVENT-MIB::sysUpTimeInstance.0 = Timeticks: (13656) 0:02:16.56 SNMPv2-MIB::sysContact.0 = STRING: Chun Tian (binghe) <bin...@gm... > SNMPv2-MIB::sysName.0 = STRING: binghe-mac.people.163.org SNMPv2-MIB::sysLocation.0 = STRING: binghe-mac.people.163.org SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00 --binghe |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-07-21 15:18:34
|
A.T.T. > > Hi, Lispers > > After one and a half year since I started this project (0.01 on May > 2007, 1.2 on Oct 2007), I'm glad to > release cl-net-snmp 3.0 today, the pure-lisp implementation of Simple > Network Management Protocol (SNMP, RFC 2271). > > From this release, I throw out the ZEBU LALR parser and write a simple > ASN.1 compiler (based on LispWorks parsergen) to > generate Lisp code from ASN.1 MIB files, then use ASDF to load them > directly. Any ASN.1 Object Identifier value are treated as a Lisp > variable. > > This project is part of my big plan: write a new system administration > platform (like HP OpenView) completely in Common Lisp. > > Cliki page: (contains link to other resources) > > http://www.cliki.net/cl-net-snmp > > Current Supported Platforms: > > * LispWorks > * CMUCL > * SBCL > * Clozure CL > * Allegro CL > > Features: > > * Full SNMP protocol support (SNMPv1, SNMPv2c, SNMPv3) > * Support MIB and ASN.1 object id names > * Fast BER encode/decode based on CLOS > * UDP retransmit support > * [LispWorks] Simple SNMP Server > * [LispWorks] GUI MIB Browser > > Download: > > You can use ASDF-INSTALL to install cl-net-snmp 3.0, or download > following release files: > > * The core: SNMP 3.0: > > http://common-lisp.net/project/cl-net-snmp/release/snmp_3.0.tar.gz > > * ASN.1 runtime and compiler, version 2.3: > > http://common-lisp.net/project/cl-net-snmp/release/asn.1_2.3.tar.gz > > * UDP patch for usocket, version 1.2: > > http://common-lisp.net/project/cl-net-snmp/release/usocket-udp_1.2.tar.gz > > * LispWorks UDP support, version 2.1: > > http://common-lisp.net/project/cl-net-snmp/release/lispworks-udp_2.1.tar.gz > > Sample Usage: > > ? (snmp:snmp-walk "debian-amd64.local" '("system")) > (((#<OBJECT-ID sysDescr.0> > "Linux debian-amd64 2.6.25-2-amd64 #1 SMP Fri Jun 27 00:16:12 UTC > 2008 x86_64") > (#<OBJECT-ID sysObjectID.0> #<OBJECT-ID netSnmpAgentOIDs.10>) > (#<OBJECT-ID sysUpTimeInstance (0) [0]> #<TIMETICKS (208848) > 0:34:48.48>) > (#<OBJECT-ID sysContact.0> > "Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)") > (#<OBJECT-ID sysName.0> "debian-amd64") > (#<OBJECT-ID sysLocation.0> "Unknown (configure /etc/snmp/ > snmpd.local.conf)") > (#<OBJECT-ID sysORLastChange.0> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORID.1> #<OBJECT-ID snmpFrameworkMIBCompliances.1>) > (#<OBJECT-ID sysORID.2> #<OBJECT-ID snmpMPDMIBCompliances.1>) > (#<OBJECT-ID sysORID.3> #<OBJECT-ID usmMIBCompliances.1>) > (#<OBJECT-ID sysORID.4> #<OBJECT-ID snmpMIB (1) [2]>) > (#<OBJECT-ID sysORID.5> #<OBJECT-ID tcpMIB (49) [1]>) > (#<OBJECT-ID sysORID.6> #<OBJECT-ID ip (4) [39]>) > (#<OBJECT-ID sysORID.7> #<OBJECT-ID udpMIB (50) [1]>) > (#<OBJECT-ID sysORID.8> #<OBJECT-ID vacmBasicGroup (1) [0]>) > (#<OBJECT-ID sysORDescr.1> "The SNMP Management Architecture MIB.") > (#<OBJECT-ID sysORDescr.2> "The MIB for Message Processing and > Dispatching.") > (#<OBJECT-ID sysORDescr.3> > "The management information definitions for the SNMP User-based > Security Model.") > (#<OBJECT-ID sysORDescr.4> "The MIB module for SNMPv2 entities") > (#<OBJECT-ID sysORDescr.5> "The MIB module for managing TCP > implementations") > (#<OBJECT-ID sysORDescr.6> > "The MIB module for managing IP and ICMP implementations") > (#<OBJECT-ID sysORDescr.7> "The MIB module for managing UDP > implementations") > (#<OBJECT-ID sysORDescr.8> "View-based Access Control Model for > SNMP.") > (#<OBJECT-ID sysORUpTime.1> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.2> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.3> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.4> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.5> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.6> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.7> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.8> #<TIMETICKS (0) 0:00:00.00>))) > > Regards, > > Chun Tian (binghe) > |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-07-13 15:16:46
|
Hi, Ingvar
Now you can ASDF-install my SNMP package. I've fixed it under SBCL/
CMUCL/Clozure CL today
Call this:
* (asdf-install:install :snmp)
should work, I test it and seems good. But you should use USOCKET 0.4
branch or trunk, current release version (0.3.x) doesn't have DATADRAM
class and WAIT-FOR-INPUT support, cannot fit SNMP package.
No document yet, but I can give you two example usage:
* (snmp:snmp-walk "localhost" '(#(1 3 6 1 2 1 1)))
(((#<SNMP:OBJECT-ID 1.3.6.1.2.1.1.1.0>
"Linux debian-amd64 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC
2008 x86_64")
(#<SNMP:OBJECT-ID 1.3.6.1.2.1.1.2.0>
#<SNMP:OBJECT-ID 1.3.6.1.4.1.8072.3.2.10>)
(#<SNMP:OBJECT-ID 1.3.6.1.2.1.1.3.0>
#<SNMP:TIMETICKS (1712822) 4:45:28.22>)
(#<SNMP:OBJECT-ID 1.3.6.1.2.1.1.4.0>
"Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)")
(#<SNMP:OBJECT-ID 1.3.6.1.2.1.1.5.0> "debian-amd64")
(#<SNMP:OBJECT-ID 1.3.6.1.2.1.1.6.0>
"Unknown (configure /etc/snmp/snmpd.local.conf)")
...
* (snmp:with-open-session (s "localhost" :version snmp:+snmp-version-2c+
:community "public")
(snmp:snmp-get s '(#(1 3 6 1 2 1 1 1 0) #(1 3 6 1 2 1 1 5 0))))
("Linux debian-amd64 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC
2008 x86_64"
"debian-amd64")
In old versions of SNMP package, user can use "sysDescr.0" instead of
#(1 3 6 1 2 1 1 1 0). But this facility need a LALR parser. It was
ZEBU but very hard to use and even install correctly. Now I'm working
on write a ASN.1 compiler to get alive without any LALR parser. Just
give me more days I can work it out.
I'll watching you guys on how to integrate SNMP monitor ability into
your NOCtool:)
Any bug reports and idea are welcome!
Regards,
Chun Tian (binghe)
在 2008-7-13，上午2:55， Ingvar 写道：
> Chun Tian writes:
> [ I have CCd the noctool-devel mailing list ]
>> Hi, Ingvar Mattsson
>>
>> I'm a UNIX system administrator and Lisp programmer in China.
>>
>> Recently I saw your NOCtool project [1] on common-lisp.net. I also
>> want to build such a package for monitor my UNIX servers. My plan is
>> write a pure lisp SNMP client first, then IPMI client, then other
>> monitoring support (HTTP, Ping, ...), finally build a Web server on
>> cl-
>> http and add graph drawing facility.
>>
>> It seems that your project already done the later part of my plan:)
>
> Yeah, it's slowly getting there and I was looking at SNMP packages a
> while
> back, since I can see that having (some sort of) SNMP support would
> make it
> much easier monitoring some types of equipment.
>
>> Now I have a working SNMP client (even server) package[2]. For this
>> project, I also write a USOCKET UDP patch and LispWorks UDP support.
>> If your're still interesting in improve your package to monitor more
>> things, you may want to see my work.
>>
>> The SNMP package is on SVN: (tested on LispWorks, other CLs maybe
>> need
>> small fixes)
>>
>> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/
>> trunk
>>
>> The USOCKET UDP patch (as an ASDF package, waiting USOCKET author
>> merge it):
>>
>> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk
>>
>> The IPMI package (still under development, not usable)
>>
>> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/
>> trunk
>
> Cool. Are the packages in such a stage that it would make sense to
> package
> them up so ASDF-INSTALL can grab and build them? From what I can
> tell, what's
> needed is an ASDF system definition file, a tar-ball with the
> relevant source
> files and an entry in CLiki.
>
> //Ingvar
>
|
|
From: Jim P. <dow...@hp...> - 2008-07-13 11:08:49
|
Hello, For NOCtool, we're targeting SBCL primarily. Jim James E. Prewett Ji...@Pr... dow...@hp... Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 On Sun, 13 Jul 2008, Chun Tian (binghe) wrote: > > > > > Now I have a working SNMP client (even server) package[2]. For this > > > project, I also write a USOCKET UDP patch and LispWorks UDP support. > > > If your're still interesting in improve your package to monitor more > > > things, you may want to see my work. > > > > > > The SNMP package is on SVN: (tested on LispWorks, other CLs maybe need > > > small fixes) > > > > > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk > > > > > > The USOCKET UDP patch (as an ASDF package, waiting USOCKET author > > > merge it): > > > > > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk > > > > > > The IPMI package (still under development, not usable) > > > > > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/trunk > > > > Cool. Are the packages in such a stage that it would make sense to package > > them up so ASDF-INSTALL can grab and build them? From what I can tell, > > what's > > needed is an ASDF system definition file, a tar-ball with the relevant > > source > > files and an entry in CLiki. > > No problem, I'll soon package them up and upload to my space on common- > lisp.net. When I'm done, I'll notice you again. > > By the way, what is your main development CL platform? I'll consider fix it > first. > > > > > > > //Ingvar > > > > _______________________________________________ > noctool-devel mailing list > noc...@co... > http://common-lisp.net/cgi-bin/mailman/listinfo/noctool-devel > |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-07-13 05:13:49
|
> >> Now I have a working SNMP client (even server) package[2]. For this >> project, I also write a USOCKET UDP patch and LispWorks UDP support. >> If your're still interesting in improve your package to monitor more >> things, you may want to see my work. >> >> The SNMP package is on SVN: (tested on LispWorks, other CLs maybe >> need >> small fixes) >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/ >> trunk >> >> The USOCKET UDP patch (as an ASDF package, waiting USOCKET author >> merge it): >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk >> >> The IPMI package (still under development, not usable) >> >> https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/ >> trunk > > Cool. Are the packages in such a stage that it would make sense to > package > them up so ASDF-INSTALL can grab and build them? From what I can > tell, what's > needed is an ASDF system definition file, a tar-ball with the > relevant source > files and an entry in CLiki. No problem, I'll soon package them up and upload to my space on common- lisp.net. When I'm done, I'll notice you again. By the way, what is your main development CL platform? I'll consider fix it first. > > > //Ingvar > |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-07-12 14:47:44
|
Hi, cl-net-snmp-general Finally I have a plan to get alive without ZEBU. I create a standalone ASN.1 "compiler" sub-project [1], this package will be two part: a runtime support and a "compiler". Using this package, I can translate ASN.1 MIB files into Common Lisp source code which presents ASN.1 definitions in CLOS. Then I'll move all BER encode/decode facility into this ASN.1 package, to leave SNMP package [2] only have core SNMP function. This ASN.1 package will lead my working on IPMI and LDAP much easier. The ASN.1 package did not use ZEBU to parse ASN.1 syntax. Instead, I just use Common Lisp readtable to be a ASN.1 lexer (see it's reader.lisp), and LispWorks' ParserGen package to be a LALR parser. Since I didn't use a portable LALR parser, the compiler part will only for LispWorks, but the result (ASN.1->Lisp) code can be compiled on any Common Lisp implementation. So, in my next SNMP package release, all platform can use MIB for ASN.1 OID name resolve and other new features. Regards, Chun Tian (binghe) [1] https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/asn.1/trunk [2] https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-04-23 15:35:08
|
Hi, W. A. > >> And during these weeks, I have moved usocket-udp dir out of the snmp >> directory. The author of USOCKET seems forget my post or do not want >> to merge my UDP patch at this time. I think it OK. It's him who >> define >> a DATAGRAM-USOCKET in his own tree, not me. So I think in the future >> there will be a UDP support, if not from me, must from himself. > > Ok. I'll keep a closer eye on those libraries, too. > >> I tested it in SBCL, seems OK now. Try it and tell me your new >> result. > > I've updated everything - including SBCL to current - and I'm > back in business. Good. > > > In a somewhat different matter, I recently used CL-YACC on a > project of my own (http://code.google.com/p/cl-period/). It seems a > lot less esoteric than ZEBU. Is it capable of handling ASN.1, or did > you already decide against it for particular faults? Thank you for your notes. Actually I do use cl-yacc and cl-lexer on earlier version, and soon find too many conflicts which cannot shift by cl-yacc and then turn to ZEBU. There's a ASN.1 Book which talk about the parse of ASN.1: http://www.oss.com/asn1/dubuisson.html In this book, author said the ASN.1 BNF, when using a LALR parser, can produce hundred of conflicts. And this book suggest that, to parse full ASN.1, LALR parser isn't fit to use. Maybe LL parser is better. I'm still reading this book. I decide to finish reading first, then continue to think about my ASN.1 parse job. I think I need more knowledge of ASN.1, it's quite complex. Regards, Chun Tian (binghe) |
|
From: William A. <an...@bi...> - 2008-04-23 15:10:25
|
>And during these weeks, I have moved usocket-udp dir out of the snmp
>directory. The author of USOCKET seems forget my post or do not want
>to merge my UDP patch at this time. I think it OK. It's him who define
>a DATAGRAM-USOCKET in his own tree, not me. So I think in the future
>there will be a UDP support, if not from me, must from himself.
Ok. I'll keep a closer eye on those libraries, too.
>I tested it in SBCL, seems OK now. Try it and tell me your new result.
I've updated everything - including SBCL to current - and I'm
back in business.
In a somewhat different matter, I recently used CL-YACC on a
project of my own (http://code.google.com/p/cl-period/). It seems a
lot less esoteric than ZEBU. Is it capable of handling ASN.1, or did
you already decide against it for particular faults?
--
wm
|
|
From: Chun T. (binghe) <bin...@gm...> - 2008-04-19 06:43:40
|
Hi, Annis I think your USOCKET source tree is not the latest SVN trunk, these CLOS condition indicates that the DATAGRAM-USOCKET class haven't defined. And during these weeks, I have moved usocket-udp dir out of the snmp directory. The author of USOCKET seems forget my post or do not want to merge my UDP patch at this time. I think it OK. It's him who define a DATAGRAM-USOCKET in his own tree, not me. So I think in the future there will be a UDP support, if not from me, must from himself. So I suggest you try following steps: 1. Update your usocket to latest version from this link and make it ASDF-loadable: svn://common-lisp.net/project/usocket/svn/usocket/trunk 2. Check out the USOCKET-UDP sub-project from this link and make it ASDF-loadable: https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp 3. Update snmp directory to at least r226: https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk I tested it in SBCL, seems OK now. Try it and tell me your new result. Thanks. Chun Tian (binghe) > > I let my cl-net-snmp get a few weeks stale. I updated it recently, > and also grabbed the USOCKET-UDP library from your SVN repository. > I've pulled out anything that references USOCKET, but SBCL gives me > this loveliness when I try an SNMP-GET: > > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > While computing the class precedence list of the class named > USOCKET:STREAM-DATAGRAM-USOCKET. > The class named USOCKET::DATAGRAM-USOCKET is a forward referenced > class. > The class named USOCKET::DATAGRAM-USOCKET is a direct superclass of > the class named USOCKET:STREAM-DATAGRAM-USOCKET. > [Condition of type SIMPLE-ERROR] > > Restarts: > 0: [ABORT] Return to SLIME's top level. > 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl- > thread" {100279D1B1}>) > > Backtrace: > 0: (SB-PCL::CPL-ERROR #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- > USOCKET> "The class ~A is a forward referenced class.~@ > The class ~A is ~A.")[:EXTERNAL] > 1: ((LABELS SB-PCL::WALK) #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- > USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD- > REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>)) > 2: (SB-PCL::COMPUTE-STD-CPL-PHASE-1 #<STANDARD-CLASS USOCKET:STREAM- > DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB- > MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>)) > 3: (SB-PCL::COMPUTE-STD-CPL #<STANDARD-CLASS USOCKET:STREAM- > DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB- > MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>)) > 4: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- > USOCKET> T) > 5: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- > USOCKET> T)[:EXTERNAL] > 6: (SB-PCL::INSTALL-OPTIMIZED-CONSTRUCTOR #<SB-PCL::CTOR > {1002DB0139}>) > 7: ((LAMBDA (&REST SB-PCL::ARGS)) #<SB-BSD-SOCKETS:INET-SOCKET > descriptor 5 {10026C16F1}> #<SB-SYS:FD-STREAM for "a > socket" {10026CEFA1}>) > 8: (OPEN-SESSION "lp2")[:EXTERNAL] > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > > I've done a little staring at the code, but this error takes us into > the outer reaches of CLOS, in which I'm no expert. Any ideas? I've > seen some of your email to the USOCKET list. Will your UDP stuff be > getting rolled into the main trunk? I can always revert to an older > SNMP until that's ready. > > -- > wm > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save > $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > CL-Net-SNMP-General mailing list > CL-...@li... > https://lists.sourceforge.net/lists/listinfo/cl-net-snmp-general |
|
From: William A. <an...@bi...> - 2008-04-18 19:45:33
|
I let my cl-net-snmp get a few weeks stale. I updated it recently,
and also grabbed the USOCKET-UDP library from your SVN repository.
I've pulled out anything that references USOCKET, but SBCL gives me
this loveliness when I try an SNMP-GET:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
While computing the class precedence list of the class named USOCKET:STREAM-DATAGRAM-USOCKET.
The class named USOCKET::DATAGRAM-USOCKET is a forward referenced class.
The class named USOCKET::DATAGRAM-USOCKET is a direct superclass of the class named USOCKET:STREAM-DATAGRAM-USOCKET.
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {100279D1B1}>)
Backtrace:
0: (SB-PCL::CPL-ERROR #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> "The class ~A is a forward referenced class.~@
The class ~A is ~A.")[:EXTERNAL]
1: ((LABELS SB-PCL::WALK) #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
2: (SB-PCL::COMPUTE-STD-CPL-PHASE-1 #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
3: (SB-PCL::COMPUTE-STD-CPL #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
4: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> T)
5: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> T)[:EXTERNAL]
6: (SB-PCL::INSTALL-OPTIMIZED-CONSTRUCTOR #<SB-PCL::CTOR {1002DB0139}>)
7: ((LAMBDA (&REST SB-PCL::ARGS)) #<SB-BSD-SOCKETS:INET-SOCKET descriptor 5 {10026C16F1}> #<SB-SYS:FD-STREAM for "a socket" {10026CEFA1}>)
8: (OPEN-SESSION "lp2")[:EXTERNAL]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
I've done a little staring at the code, but this error takes us into
the outer reaches of CLOS, in which I'm no expert. Any ideas? I've
seen some of your email to the USOCKET list. Will your UDP stuff be
getting rolled into the main trunk? I can always revert to an older
SNMP until that's ready.
--
wm
|
|
From: Chun T. (binghe) <bin...@gm...> - 2008-04-05 15:35:19
|
Hi, Kov Chai Welcome back! Regards, Chun Tian (binghe) 在 2008-4-5，下午8:24， tch...@us... 写道： > Revision: 213 > http://cl-net-snmp.svn.sourceforge.net/cl-net-snmp/?rev=213&view=rev > Author: tchaikov > Date: 2008-04-05 05:24:54 -0700 (Sat, 05 Apr 2008) > > Log Message: > ----------- > * finish packages.tex > * add more indexes > > Modified Paths: > -------------- > onlisp-cn/trunk/10-other_macro_pitfalls.tex > onlisp-cn/trunk/11-classic_macros.tex > onlisp-cn/trunk/12-generalized_variables.tex > onlisp-cn/trunk/13-computation_at_compile-time.tex > onlisp-cn/trunk/4-utility_functions.tex > onlisp-cn/trunk/5-returning_functions.tex > onlisp-cn/trunk/7-macros.tex > onlisp-cn/trunk/9-variable_capture.tex > onlisp-cn/trunk/onlisp-cn.pdf > onlisp-cn/trunk/packages.tex > > Modified: onlisp-cn/trunk/10-other_macro_pitfalls.tex > =================================================================== > --- onlisp-cn/trunk/10-other_macro_pitfalls.tex 2008-04-02 12:44:57 > UTC (rev 212) > +++ onlisp-cn/trunk/10-other_macro_pitfalls.tex 2008-04-05 12:24:54 > UTC (rev 213) > @@ -115,10 +115,10 @@ > \label{sec:non-functional_expanders} > > Lisp 期望它所生成的宏展开式代码都是纯函数型的，就像第% > -~\ref{chap:functional_programming} 章 > 里描述的那样。展开器代码应该除了作为参数传给它的 > -形式之外不依赖任何其他东西，并且除了 > 通过返回值以外不应该对外界产生其他影响。 > +~\ref{chap:functional_programming} 章 > 里描述的那样。展开器代码除了作为参数传给它的 > +形式 (form) 之外不应该有其他依赖，并 > 且它影响外界的唯一渠道只能是通过其返回值。 > > -正如~\textsc{cltl2} (685 页) 所说，可 > 以安全地假定在编译代码中的宏调用将不会在运行期重新 > +正如~\textsc{cltl2} (685 页) 所述，在 > 编译代码中的宏调用可以保证不会在运行期重新 > 展开。另一方面，Common Lisp 并不保证一 > 个宏调用将在何时被展开，或者被展开多少次。如果一个宏 > 的展开式随上述两种情况而变的话，那么应 > 该将其视为错误。例如，假设我们想要统计某些宏被使用的 > 次数。我们不能简单地在源代码文件里做一 > 次搜索，因为宏可能会在由程序生成的代码里被调用。我们 > @@ -134,13 +134,13 @@ > 决定是否变换代码之前可能不得不展开表达式中的宏调用。 > > 作为一项通用规则，展开器代码除了其参数 > 之外不应依赖于其他任何东西。所以任何宏，比如说通过 > -字符串来构造展开式的那种，应当小心不 > 要对宏展开时所在的包做任何假设。这个间接但相当有代表性 > +字符串来构造展开式的那种，应当小心不 > 要对宏展开时所在的包做任何假设。下面这个简明但相当有代表性 > 的例子， > \begin{verbatim} > (defmacro string-call (opstring &rest args) ; wrong > `(,(intern opstring) ,@args)) > \end{verbatim} > -定义了一个宏，其接受一个操作符的打印 > 名称然后将其展开成一个对该操作符的调用： > +定义了一个宏，它接受一个操作符的打印 > 名称，然后将其展开成一个对该操作符的调用： > \begin{verbatim} >> (defun our+ (x y) (+ x y)) > OUR+ > @@ -305,8 +305,8 @@ > 如此这般地进入无限循环。一个宏展开成对 > 自身的调用是可以的，但不是这么用的。 > > 像~\texttt{nthb} 这样的递归宏其真正危险之处在 > 于它们通常在解释器里工作正常。然后当你最终 > -将你的程序跑起来然后试图编译它的时 > 候，它甚至不能编译。不仅如此，通常也不会有指示说问题出在 > -一个递归的宏身上；编译器只会简单地进 > 入无限循环然后留给你来找出究竟哪里搞错了。 > +将程序跑起来，然后试图编译它的时候， > 它甚至不能编译通过。不仅如此，通常也不会有提示，指出问题 > +来自一个递归的宏；编译器只会陷入无限循环，让你来找出究竟哪里搞错了。 > > 在这个案例中，\texttt{ntha} 是尾递归的。一个尾 > 递归函数可以轻易转换成一个迭代的等价形式， > \textsl{然后}用作宏的模型。一个像~\texttt{nthb} 的宏可以写成 > @@ -352,7 +352,7 @@ > 会调用全局定义的函数~\texttt{nth-fn}，\texttt{nthe} 的每次展开 > 将在它里面拥有一个它自己 > 的该函数的版本。 > > -尽管你不能将递归函数直接转化成一个 > 宏，你却可以写一个宏其展开式是递归生成的。一个宏的展开 > +尽管你不能将递归函数直接转化成一个 > 宏，你却可以写出一个宏，让它的展开式是递归生成的。一个宏的展开 > 函数就是正常的~Lisp 函数，并且当然是可以递归的。例如， > 如果我们想定义内置~\texttt{or} 的 > 一个版本，我们将会需要用到一个递归的展开函数。 > > > Modified: onlisp-cn/trunk/11-classic_macros.tex > =================================================================== > --- onlisp-cn/trunk/11-classic_macros.tex 2008-04-02 12:44:57 UTC > (rev 212) > +++ onlisp-cn/trunk/11-classic_macros.tex 2008-04-05 12:24:54 UTC > (rev 213) > @@ -298,7 +298,7 @@ > \section{条件求值} > \label{sec:conditional_evaluation} > > -有时我们需要让宏调用中的某个参数仅在 > 特定条件下才被求值。这超出了函数的能力所及，因为函数总是 > +有时我们需要让宏调用中的某个参数仅在 > 特定条件下才被求值。这超出了函数的能力，因为函数总是 > 会求值其全部参数。诸如~\texttt{if}， > \texttt{and} 和~\texttt{cond} 这样的内置操作符能够 > 在保护其某些参数免于被求值，除非其他参 > 数返回特定值。例如，在这个表达式中 > \begin{verbatim} > @@ -385,6 +385,10 @@ > ((inq key t otherwise) `(t ,@rest)) > (t (error "bad >case clause"))))) > \end{verbatim} > +\index{in@\texttt{in}} > +\index{inq@\texttt{inq}} > +\index{in-if@\texttt{in-if}} > +\index{case@\texttt{>case}} > \caption{使用条件求值的宏} > \label{fig:macros_for_conditional_evaluation_2} > \end{figure} > @@ -515,11 +519,11 @@ > 同样在前面看到过~(\pageref{macro:for} 页)，在一个数字范围上做迭代。 > > 通过定义这些宏展开到~\texttt{do} 上 > 面，我们就允许在它们的主体里使用~\texttt{go} 和 > -~\texttt{return}。正如~\texttt{do} 从 > ~\texttt{block} 和~\texttt{tagbody} 处继承 > +~\texttt{return}。正如~\texttt{do} 从 > ~\texttt{block} 和~\texttt{tagbody} > \index{tagbody@\texttt{tagbody}} 处继承 > 了这些权力，\texttt{while}，\texttt{till} 和~ > \texttt{for} 也从~\texttt{do} 处继承 > 了它们。就像~ > \pageref{block_and_capture} 页上所解释的那样，\texttt{do} 内部隐含 > ~\texttt{block} 里的~\texttt{nil} 标签 > 将被图~\ref{fig:simple_iteration_macros} > -中的宏所捕捉。这更多的是一个特征而非 > ~bug，但它至少应该被明显地注意到。 > +中的宏所捕捉。虽然与其说这是个~bug， > 不如说它是个特性，但它至少应该被清楚地提到。 > > \begin{figure} > \begin{verbatim} > @@ -583,7 +587,7 @@ > \end{verbatim} > 两个宏都返回~\texttt{nil}，除非一个显式的~\texttt{return} 出现 > 在主体中。 > > -这类迭代在需要处理某些路径概念的程序 > 里经常需要。后缀~\texttt{/o} 和~\texttt{/c} 用来 > +在需要处理某种路径表示的程序里，这类 > 迭代会经常用到。后缀~\texttt{/o} 和~\texttt{/c} 用来 > 说明这两个版本分别在开放和封闭的路径上 > 操作。举个例子，如果~\texttt{points} 是一个点的 > 列表而~\texttt{(drawline $x$ $y$)} 在~$x$ 和~$y$ 之间 > 画线，那么画一条从起点到终点的 > 路径我们写成 > @@ -899,8 +903,8 @@ > #'(lambda () (go-sailing)) > #'(lambda () (rob-bank))) > \end{verbatim} > -如果我们想要的全部就是条件求值，宏绝 > 对是不需要的。它们只是使程序更清晰罢了。尽管如此，当我们 > -需要介入参数形式，或者绑定作为参数传递的变量时宏就是必需的了。 > +如果所有我们想要的就是条件求值，那么 > 宏也不是非要不可的。它们只是使程序更清晰罢了。尽管如此，当我们 > +需要介入参数形式，或者绑定作为参数传递的变量时，宏就是必需的了。 > > 同样的情况也适用于那些用于迭代的宏。尽 > 管只有宏才提供这种定义一个可以带有表达式体的迭代结构 > 的方式，其实用函数来做迭代也是可能的， > 只要循环体被包装在那个函数里。\footnote{ > > Modified: onlisp-cn/trunk/12-generalized_variables.tex > =================================================================== > --- onlisp-cn/trunk/12-generalized_variables.tex 2008-04-02 12:44:57 > UTC (rev 212) > +++ onlisp-cn/trunk/12-generalized_variables.tex 2008-04-05 12:24:54 > UTC (rev 213) > @@ -3,12 +3,12 @@ > \label{chap:generalized_variables} > > 第~\ref{chap:when_to_use_macros} 章曾提到宏的一个优点是它们变 > 换其参数的能力。这类宏 > -中的一个是~\texttt{setf}。本章关注~\texttt{setf} 的内涵，然后 > 给出一些建立在其之上宏的 > -示例。 > +中的一个是~\texttt{setf}。本章关注~\texttt{setf} 的内涵，然后 > 给出一些宏作为例子，它们 > +将建立在~\texttt{setf} 的基础之上。 > > -在~\texttt{setf} 上编写正确的宏令人惊 > 奇地困难。为介绍这一主题，第一节将提供一个有略微 > -不正确的简单例子。接下来一节将解释该 > 宏的错误之处，然后展示如何修复它。第三和第四节展示建立 > -在~\texttt{setf} 之上的\utility的例 > 子，而最后一节解释如何定义你自己的~\texttt{setf} > +要在~\texttt{setf} 上编写正确无误的宏 > 是一件难事，其难度令人咋舌。为介绍这一主题，第一节将给出一个有点 > +小问题的简单例子。接下来一节将解释该 > 宏的错误之处，然后展示如何修复它。第三和第四节会介绍一些基于 > +~\texttt{setf} 的\utility的例子，而最 > 后一节会说明如何定义你自己的~\texttt{setf} > \inversion。 > > \section{概念} > @@ -54,12 +54,12 @@ > 完整的列表在~\textsc{cltl2} 的第~125 页。) > > 一个可以作为~\texttt{setf} 第一个参数的表达式 > 称为\textsl{\gv}。\gv已经成为一种强有力的 > -抽象。宏调用和\gv的相似之处在于任何能 > 展开成可逆引用的宏调用其本身可以可逆的\footnote{原文： > +抽象。宏调用和\gv的相似之处在于：任何 > 能展开成可逆引用的宏调用，其本身就会是可逆的\footnote{原文： > A macro call resembles a generalized variable in that any macro call > which expands into an invertible reference will itself be invertible. > 译者注：这意味着可逆的宏或者\gv都是可 > 以嵌套使用的，有些~``正则序'' 的意味。}。 > > -当我们也在~\texttt{setf} 之上编写我们 > 自己的宏时，这种组合可以导致明显更为清晰的程序。 > +当我们也在~\texttt{setf} 之上编写我们 > 自己的宏时，这种组合可以产生显然更为清爽的程序。 > 其中一个我们可以定义在~\texttt{setf} 上面的宏是~ > \texttt{toggle}\footnote{这个定义是 > 不正确的，下一节将给出解释。}， > \begin{verbatim} > @@ -110,9 +110,9 @@ > (toggle (friend-of x y)) > \end{verbatim} > > -\gv就像是美味的健康食品。它们能带来良 > 好模块化同时优美典雅的程序。如果你为你的数据结构提供 > +\gv就像是美味的健康食品。它们能让你的 > 程序良好地模块化，同时变得更为优雅。如果你为你的数据结构提供 > 了通过宏或者可逆函数的访问能力，其他模 > 块就可以使用~\texttt{setf} 来修改你的数据结构而无需 > -知道它们的表达细节。 > +知道它们的内部细节。 > > \section{多重求值问题} > \label{sec:the_multiple_evaluation_problem} > @@ -199,6 +199,10 @@ > > (define-modify-macro toggle2 () not) > \end{verbatim} > +\index{allf@\texttt{allf}} > +\index{nilf@\texttt{nilf}} > +\index{tf@\texttt{tf}} > +\index{toggle@\texttt{toggle}} > \caption{操作在\gv上的宏。} > \label{fig:macros_which_operate_on_generalized_variables} > \end{figure} > @@ -206,7 +210,7 @@ > \section{新的\utility} > \label{sec:new_utilities} > > -本节给出一些操作在\gv上的新\utility的 > 例子。它们必须是宏以便将参数完整地传给 > +本节给出一些操作在\gv上的新\utility的 > 例子。它们必须是宏，以便将参数完整地传给 > ~\texttt{setf}。 > > 图~ > \ref{fig:macros_which_operate_on_generalized_variables} 显示了构建在 > @@ -703,9 +707,9 @@ > \end{verbatim} > 该查询返回第二个值~\texttt{t}，以表明在缓存中找到了答案。 > > -就像宏本身那样，gv是一种不寻常威力的 > 抽象。这里可能有更多需要探索的东西。个别用户已经发现了 > -一些使用\gv的方式可以带来更为优雅和强 > 有力的程序。但也有可能以全新的方式来使用 > -~\texttt{setf} 逆，或者探索类似的其他类别的有用的变换技术。 > +就像宏本身那样，\gv 是一种具有非凡威 > 力的抽象。这里可能还有更多有待探索的东 > 西。当然，有的用户很可能已经发现了 > +一些使用\gv的方法，通过它们能得到更为 > 优雅和强大的程序。但也有可能以全新的方式来使用 > +~\texttt{setf} 逆，或者找到其他类似的有用的变换技术。 > > %%% Local Variables: > %%% coding: utf-8 > > Modified: onlisp-cn/trunk/13-computation_at_compile-time.tex > =================================================================== > --- onlisp-cn/trunk/13-computation_at_compile-time.tex 2008-04-02 > 12:44:57 UTC (rev 212) > +++ onlisp-cn/trunk/13-computation_at_compile-time.tex 2008-04-05 > 12:24:54 UTC (rev 213) > @@ -4,8 +4,8 @@ > > 前面的章节描述了几类必须用宏来实现的操 > 作符。本章描述可以用函数来解决，但用宏可以更加高效 > 的一类问题。第~ > \ref{sec:macro_or_function} 节列出了在给定情形下使用宏的利弊。 > -有利的一面包括~``在编译期做计算''。通过定义一个操作符 > 为宏，有时你可在其展开时做掉它的 > -某些工作。本章关注那些充分利用这种可能性的宏。 > +有利的一面包括~``在编译期做计算''。通过定义一个操作符 > 为宏，有时你可在其展开时完成它的 > +某些工作。本章会关注那些充分利用这种可能性的宏。 > > \section{新的\utility} > \label{sec:new_utility_13} > @@ -18,6 +18,7 @@ > (defmacro avg (&rest args) > `(/ (+ ,@args) ,(length args))) > \end{verbatim} > +\index{avg@\texttt{avg}} > \caption{求平均值时转移计算。} > \label{fig:shifting_computation_when_finding_averages} > \end{figure} > @@ -51,6 +52,7 @@ > `(and ,a (> (incf ,hits) ,need))) > args))))) > \end{verbatim} > +\index{most-of@\texttt{most-of}} > \caption{转移和避开计算。} > \label{fig:shifting_and_avoiding_computation} > \end{figure} > @@ -111,6 +113,7 @@ > ,(car vars) ,var) > ,else))))) > \end{verbatim} > +\index{nthmost@\texttt{nthmost}} > \caption{使用编译期知道的参数。} > \label{fig:use_of_arguments_known_at_compile-time} > \end{figure} > > Modified: onlisp-cn/trunk/4-utility_functions.tex > =================================================================== > --- onlisp-cn/trunk/4-utility_functions.tex 2008-04-02 12:44:57 UTC > (rev 212) > +++ onlisp-cn/trunk/4-utility_functions.tex 2008-04-05 12:24:54 UTC > (rev 213) > @@ -19,17 +19,17 @@ > 感觉太小, 要是把它作为特定程序的一个组 > 成部分的话, 这段代码又太通用了, 这时就可以称之为 > \utility. 举例来说, 一个数据库不能称为\utility, 但是一个在列表上做单一 > 操作的函数就可以. > 大多数\utility和~Lisp 已有的函数和宏很 > 相似. 事实上, 许多~Common Lisp 内置的操作符就源自 > -\utility. 用于收集列表中所有满足条件元素的~\texttt{remove-if- > not} 函数, 在它成为~ > -Common Lisp 的一部分以前, 就被程序员们各自私下里定义了多年. > +\utility. 用于收集列表中所有满足条件元素的~\texttt{remove-if- > not}\index{remove-if-not@\texttt{remove-if-not}} 函数, > +在它成为~Common Lisp 的一部分以前, 就被程序员们各自私下里定义了多年. > > 学习编写\utility与其说是学习编写的技 > 术, 不如说是学习养成编写\utility的习惯. > \bup意味着同时写程序和编程语言. > -为了做好这一点, 你必须发展出一种能洞 > 察程序中缺少何种操作符的悟性. 你必须能够在看到一个程序时说, > +为了做好这一点, 你必须培养出一种能看 > 出程序中缺少何种操作符的洞察力. 你必须能够在看到一个程序时说, > ``啊, 其实你真正的意思是\textsl{这个}.'' > > 举个例子\label{page:nicknames}, 假设~ > \texttt{nicknames} 是这样一个函数, > -它接受一个名字然后构造出一个由源自 > -该名字的所有昵称组成的列表. 有了这个 > 函数, 我们怎样收集一个名字列表所对应的所有昵称呢? > +它接受一个名字，然后构造出一个列表，列表由 > +这个名字的所有昵称组成. 有了这个函 > 数, 我们怎样收集一个名字列表所对应的所有昵称呢? > 某个正在学习~Lisp 的人可能写出类似这样的函数: > \begin{verbatim} > (defun all-nicknames (names) > @@ -39,7 +39,7 @@ > (all-nicknames (cdr names))))) > \end{verbatim} > 而一个更有经验的~Lisp 程序员可能一看到这样的函数就会说 > ``啊, 其实你真正想要的是~ > \texttt{mapcan}\index{mapcan@\texttt{mapca}}.'' > -然后, 不再用定义并调用一个不得已的新 > 函数来找出一组人的所有昵称, 现在你只使用一个表达式足矣: > +然后, 不再被迫定义并调用一个新函数来 > 找出一组人的所有昵称, 现在只消用一个表达式就够了: > \begin{verbatim} > (mapcan #'nicknames people) > \end{verbatim} > @@ -140,7 +140,7 @@ > 来表示它. 即使一种编程构造开销较大, 如果我们写 > 代码的时候能比其他更便宜的方法省一半力气的话, 也会更喜欢用它. > \end{quote} > -在任何语言里, 这一``对简洁代码的倾向性''将带来麻烦, 除非允许用新的 > +在任何语言里, 这一``对简洁代码的倾向性''将招致麻烦, 除非允许用新的 > \utility来表达自身. 最简短的表达方式很少是最高效的. 如果我们想知道 > 一个列表是否比另一个列表更长, 原始的~Lisp 将诱使我们写出 > \begin{verbatim} > @@ -170,7 +170,7 @@ > \label{sec:operations_on_lists} > > 列表最初曾是~Lisp 的主要数据结构. 事实上, ``Lisp'' 这个名字就来自 > -``LISt Processing (列表处理)''. 不过请不要被这一历史事实所误解, > +``LISt Processing (列表处理)''. 不过请不要被这一历史事实所蒙蔽, > 尽管如此, Lisp 跟列表处理之间的关系并不比马球衫~(Polo shirts) > 和马球之间的关系好多少. 一个高度优化的~Common Lisp 程序里可能根本看不 > 到列表. > @@ -664,7 +664,7 @@ > (defun our-mapcan (fn &rest lsts) > (apply #'nconc (apply #'mapcar fn lsts))) > \end{verbatim} > -\index{mapcan@\texttt{mapcan}!草就而成的} > +\index{mapcan@\texttt{mapcan}!sketch of 草就而成的} > 由于~\texttt{mapcan} 用~ > \texttt{nconc} 把列表拼接在一起, 第一个参数返回的 > 列表最好是新创建的, 否则等下次看的时候它可能就变了. 这也是为什么 > ~\texttt{nicknames} (第~ > \pageref{page:nicknames} 页) 被定义成一个根据昵称 > @@ -676,24 +676,24 @@ > 下一个\utility, \texttt{mapcars}\index{mapcars@\texttt{mapcars}}, > 用于那些你想在一组列表上~mapcar 某个函数的场合. > \index{mapcar@\texttt{mapcar}!version for > multiple lists 用于多个列表的版本} > -如果我们有两个数列并且我们希望得到一个它们的平方根列表, 用原始~ > +如果我们有两个数列，并且希望得到一个它们的平方根列表, 用原始~ > Lisp 我们这样写: > \begin{verbatim} > (mapcar #'sqrt (append list1 list2)) > \end{verbatim} > -但这里的~cons 没有必要. 我们将~ > \texttt{list1} 和~\texttt{list2} 追加到 > -一起之后立即又把结果丢掉了. 借助~ > \texttt{mapcars} 我们用下列方法就可以得 > +但这里的~cons 没有必要. 我们将~\texttt{list1} 和~\texttt{list2} 串在 > +一起之后立即又把结果丢弃了. 借助~ > \texttt{mapcars} 我们用下面的方法就可以得 > 到相同结果: > \begin{verbatim} > (mapcars #'sqrt list1 list2) > \end{verbatim} > -而且还不用做额外的~cons 了. > +而且还避免了多余的~cons. > > 图~\ref{fig:mapping_functions} 中最后一个函数是 > ~\texttt{mapcar}\index{rmapcar@\texttt{rmapcar}}, 用于树的版本. > \index{mapcar@\texttt{mapcar}!version for trees 用于树的版本} > 它的名字, \texttt{rmapcar}, 是``递归~\texttt{mapcar}'' 的缩写, > -并且所有~\texttt{mapcar} 在扁平列表上做的事, 它可以在树上做到: > +并且所有~\texttt{mapcar} 在扁平列表上 > 能完成的功能, 它都可以在树上做到: > \begin{verbatim} >> (rmapcar #'princ '(1 2 (3 4 (5) 6) 7 (8 9))) > 123456789 > @@ -871,7 +871,7 @@ > 你很可能在做某件低效率的事情. 尽管如此, 在原型开发, 而 > 非产品软件中, 这类 > \utility还是有其用武之地的. > > -\section{致密性} > +\section{紧凑性} > \label{sec:density} > > 如果你的代码里使用了大量\utility, 某些 > 读者可能会抱怨它们难以理解. 那些还没能自如地使用 > @@ -903,8 +903,8 @@ > 阅读这种程序可能需要花一些力气, 但如果 > 不是这样写的话，你会需要花更多的精力 > 来读懂它们。 > > -有一种情况你应慎重地避免使用 > \utility: 如果你需要写一个和你代码其余部分无关的独 > -立分发的小程序. 一个\utility通常至少 > 要被使用两到三次才值得引入, 但在小程序里, > +有一种情况下，你应该有意地避免使用 > \utility，即: 如果你需要写一个小程序，它将独立于其余部分的代码发布. > +一个\utility通常至少要被使用两到三次才值得引入, 但在小程序里, > 如果一个\utility用得太少的话，可能就没有必要包含它了。 > > %%% Local Variables: > > Modified: onlisp-cn/trunk/5-returning_functions.tex > =================================================================== > --- onlisp-cn/trunk/5-returning_functions.tex 2008-04-02 12:44:57 > UTC (rev 212) > +++ onlisp-cn/trunk/5-returning_functions.tex 2008-04-05 12:24:54 > UTC (rev 213) > @@ -110,7 +110,7 @@ > 我们可以只用一半数量的函数就完成了全部的功能. > > 同样, \texttt{setf} 宏也增强了~Lisp 的 > 正交性. Lisp 的早期方言常会用成对的 > -函数分别实现读写数据的功能. 举例来说, 对于属性列表~(property-list), > 就会有 > +函数分别实现读数据和写数据的功能. 举 > 例来说, 对于属性列表~(property-list), 就会有 > 一个函数用来加入属性, 另一个函数则被用来查询它们. 在~Common Lisp 里面, > 我们只有后者, 即~\texttt{get} > \index{get@\texttt{get}}. 为了加入一个属性, 我们把~\texttt{get} 和 > ~\texttt{setf} 一同使用: > @@ -118,8 +118,8 @@ > (setf (get 'ball 'color) 'red) > \end{verbatim} > > -我们或许无法让~Common Lisp 变得更精 > 简, 但是我们可以作些努力达到差不多的效果: > -即使用这门语言的一个较小的子集. 可以 > 定义一些新的操作符, 就像~\texttt{complement} > +我们或许无法让~Common Lisp 变得更精 > 简, 但是我们可以作些努力达到差不多的效果，即: > +使用这门语言的一个较小的子集. 可以定 > 义一些新的操作符, 就像~\texttt{complement} > 和~\texttt{setf} 那样, 让它们帮助我们 > 更接近这个目标吗? 至少另外还有一种 > 方式让函数成对出现. 许多函数都有其破坏 > 性~(destructive) 的版本: 像~\texttt{remove-if} > 和~\texttt{delete-if}、 > \texttt{reverse} 和~\texttt{nreverse}、\texttt{append} > @@ -650,7 +650,7 @@ > 函数会在运行时让程序做一些不必要的工作。虽然~sharp-quoted 的 ~lambda > 表 > 达式是一个常量, 但是对构造函数的调用将 > 会在运行时估值。如果你真的必须在运行 > 时执行这个调用，可能使用构造函数并非上 > 策。不过，至少有的时候我们可以在事前就 > -调用这个构造函数。通过使用~ > \texttt{\#.}，即~sharp-dot 读取宏，我们可以让 > +调用这个构造函数。通过使用~ > \texttt{\#.}\index{\#.@\texttt{\#.}}，即~sharp-dot 读取宏，我们可以让 > 函数在读取时~(read-time) 就被构造出来。假设~\texttt{compose} > 和它的参数 > 在下面的表达式被读取时已经被定义了，那么我们可以这样写，举例如下： > \begin{verbatim} > > Modified: onlisp-cn/trunk/7-macros.tex > =================================================================== > --- onlisp-cn/trunk/7-macros.tex 2008-04-02 12:44:57 UTC (rev 212) > +++ onlisp-cn/trunk/7-macros.tex 2008-04-05 12:24:54 UTC (rev 213) > @@ -95,7 +95,7 @@ > \mbox{\texttt{`(a b c)} 等价于~\texttt{'(a b c)}.} > \end{equation*} > > -\bq只有当它和\comma，``\texttt{,}''， > 以及\commaat~符号，``\texttt{,@}''，组合出现时才 > +\bq只有当它和\comma，`` > \texttt{,}''\index{,@\texttt{,}}，以及 > \commaat~符号，``\texttt{,@}''，组合出现时才 > 有用。如果说\bq创建了一个模板，那么 > \comma就在\bq中创建了一个槽位~(slot)。 > 一个\bq列表等价于将其元素引用起来调用一次~\texttt{list}。也就是， > \begin{equation*} > @@ -199,7 +199,7 @@ > 因为宏定义体看起来就像它生成的宏展开 > 式。要想理解第二个版本，不使用\bq的， > 你将不得不在头脑中跟踪展开式的构造过程。 > > -\commaat~符号，\texttt{,@}，是\comma > 的变种，它的行为和\comma相似，但有一点不同： > +\commaat~符号，\texttt{,@}\index{,"@@ > \texttt{,"@}}，是\comma的变种，它的行为和\comma相似，但有一点不同： > 它不只是像\comma那样将表达式的值插入到其所在的位置，\commaat~ > \textsl{拼接}到当前位置。 > 拼接可以认为是在插入时去掉了最外层的括号： > \begin{verbatim} > @@ -596,7 +596,7 @@ > 技术，所以某些读者可能需要稍后再回过头来读懂它。 > > 图~\ref{fig:a_sketch_of_defmacro} 中的 > 定义给出了关于宏的工作的相当精确的再现， > -但就像任何草稿一样它是不完整的。它不能正确地处理~ > \texttt{\&whole} 关键字。 > +但就像任何草稿一样它是不完整的。它不能正确地处理~\texttt{\&whole} > \index{whole@\texttt{\&whole}} 关键字。 > 而且~\texttt{defmacro} 实际上作为其第 > 一个参数的~\texttt{macro-function} 存储的 > 是一个带有两个变元的函数：宏调用本身， > 以及其发生时的词法环境。尽管如此，这些 > 缺失的特性只用在最刁钻的宏里才会用到。就算假设宏就是像图~ > > Modified: onlisp-cn/trunk/9-variable_capture.tex > =================================================================== > --- onlisp-cn/trunk/9-variable_capture.tex 2008-04-02 12:44:57 UTC > (rev 212) > +++ onlisp-cn/trunk/9-variable_capture.tex 2008-04-05 12:24:54 UTC > (rev 213) > @@ -89,7 +89,7 @@ > (/ vn wn)))) > \end{verbatim} > 如果用~\texttt{w = (b)} 来调用~ > \texttt{sample-ratio}，那么它将会警告说它的一个 > -参数，只有一个元素，从统计上来讲没有 > 意义。但是当对~\texttt{gripe} 的调用被展开 > +参数只有一个元素，所得出的结果从统计 > 上来讲没有意义。但是当对~\texttt{gripe} 的调用被展开 > 时，\texttt{sample-ratio} 就好像被定义成： > \begin{verbatim} > (defun sample-ratio (v w) > @@ -421,7 +421,7 @@ > \pozhehao可以想象在同一个宏的嵌套实例中仍然会出现名字冲突。 > > 我们需要某种方式来\textsl{确保}一个符 > 号是唯一的。Common Lisp 函数~\texttt{gensym} > -的存在目的就在于此。它返回一个符号， > 称为一个\textsl{\gensym}，可以保证不会和任何明确 > +的存在目的就在于此。\bubblenote它返回 > 一个符号，称为一个\textsl{\gensym}，可以保证不会和任何明确 > 输入的或者由程序生成的符号~\texttt{eq} 相等。 > > Lisp 是如何确保这一点的呢？在~Common > Lisp 里，每一个包都保持一个该包知道的所有符号的列表。 > @@ -444,7 +444,7 @@ > \end{verbatim} > 它打印出来的东西基本上就相当于~``John Doe'' 的 > ~Lisp 等价物，一个为如何命名无关紧要的东西 > 构造的毫无意义的名字。并且为了确保我们 > 不会对此产生任何错觉，\gensym在显示上前缀一个星号-- > -冒号，一个特殊的读取宏~(read--macro) > 其存在是为了在我们试图第二次读取该\gensym时产生一个 > +冒号\index{\#:@\texttt{\#:}}，一个特 > 殊的读取宏~(read--macro) 其存在是为了在我们试图第二次读取该\gensym时产 > 生一个 > 错误。 > > 在~\textsc{cltl2} Common Lisp 里，\gensym的打印形式中的数字来自~ > > Modified: onlisp-cn/trunk/onlisp-cn.pdf > =================================================================== > (Binary files differ) > > Modified: onlisp-cn/trunk/packages.tex > =================================================================== > --- onlisp-cn/trunk/packages.tex 2008-04-02 12:44:57 UTC (rev 212) > +++ onlisp-cn/trunk/packages.tex 2008-04-05 12:24:54 UTC (rev 213) > @@ -1,7 +1,7 @@ > -\chapter*{附录: 包~(packages)} > +\chapter{附录: 包~(packages)} > \label{chap:packages} > -包~(packages)，是~Common Lisp 用来把代码组织成模块的方式。早期的~Lisp > -方言有一张符号表，名叫~ > \textsl{oblist}。在这张表里列出了系统中所有已经 > +包~(packages)，是~Common Lisp 把代码组织成模块的方式。早期的~Lisp > +方言有一张符号表，即~\textsl{oblist}。在这张表里列出了系统中所有已经 > 读取到的符号。借助~oblist 里的符号表项，系统得以存取数据，诸如对象的 > 值，以及属性列表等。被保存在~oblist 里的符号被称为~\textsl{interned}。 > > @@ -10,10 +10,10 @@ > 为在一个包里的~intern 的符号只有在其被显式申明为能被其它包访问的时 > 候，它才能为外部访问~(除非用一些歪门邪道的招数)。 > > -包是一种~Liso 对象。当前包常常被保存 > 在一个名为~\texttt{*package*} 的全 > +包是一种~Lisp 对象。当前包常常被保存 > 在一个名为~\texttt{*package*} 的全 > 局变量里面。当~Common Lisp 启动时，当前包就是用户包：或者 > -叫~\texttt{user} (\textsc{CLTL1} 实 > 现)，或者叫~\texttt{common-lisp-user} > -(\textsc{CLTL2} 实现)。 > +叫~\texttt{user} (\textsc{cltl1} 实 > 现)，或者叫~\texttt{common-lisp-user} > +(\textsc{cltl2} 实现)。 > > 包一般使用它们的名字相互区别，而这些名 > 字采用的是字符串的形式。要知道当前包的包名， > 可以试试： > @@ -34,7 +34,7 @@ > 99 > \end{verbatim} > > -使用~\texttt{in-package}，我们就可以 > 切换到另一个新的包，如果需要的话这 > +使用~\texttt{in-package}\index{in- > package@\texttt{in-package}}，我们就可 > 以切换到另一个新的包，如果需要的话这 > 个包会被创建出来\footnote{在较早期的~Common Lisp 实现下，请省略 > 掉~\texttt{:use} 参数}： > \begin{verbatim} > @@ -72,8 +72,8 @@ > 这样做的话，就违背了模块化设计的初衷，而这正是包本来想要提供的。如果你 > 不得不使用双冒号来引用一个符号，这应该就是有人根本就不希望你引用它。 > > -一般来说，如果你之应该引用那些被~ > \textsl{expert} 的那些符号。通过把符号 > -从它所~intern 的包~export 出来，我们 > 就能让这个符号对其它包也是可见的。 > +一般来说，如果你只应该引用那些被~\textsl{expert} 了的那些符号。把符号 > +从它所属的包~export 出来，我们就能让这个符号对其它包变得可见。 > 要引出一个符号，我们可以调用~(你肯定已经猜到了) \texttt{export}： > \begin{verbatim} > MINE> (in-package 'common-lisp-user) > @@ -94,8 +94,154 @@ > 在导入了~\texttt{bar} 之后，我们可以完全不用加上任何包的限定符就能引用 > 它了。现在，这两个包共享了同一个符号\pozhehao再没有一个独立 > 的~\texttt{mine:bar} 了。 > -% p383 > > +万一已经有了一个会怎么样呢？在这种情 > 况下，\texttt{import} 调用会导致一 > +个错误，就像下面我们试着~import \texttt{foo} 时造成的错误一样： > +\begin{verbatim} > +MINE> (import 'common-lisp-user::foo) > +>>Error: FOO is already present in MINE. > +\end{verbatim} > + > +之前，我们在~\texttt{mine} 里对~\texttt{foo} 进行了一次不成功 > 的求值，这 > +次求值顺带着使得一个名为~\texttt{foo} 的符号 > 被加入了~\texttt{mine}。由 > +于这个符号在全局范围内还没有值，因此 > 产生了一个错误，但是输入符号名字的直接 > +后果就是使它被~intern 进了这个包。所以，当我们现在想把~\texttt{foo} > 引 > +进~\texttt{mine} 的时候，\texttt{mine} 里面已经有一个相同名字 > 的符号了。 > + > +通过让一个包\textsl{使用}~(use) 另一个包，我们也能批量的引入符号： > +\begin{verbatim} > +MINE> (use-package 'common-lisp-user) > +T > +\end{verbatim} > +这样，所有~user package 引出的符号就会自动地 > 被引进到~\texttt{mine} 里面 > +去了。(要是~user package 已经引出了~\texttt{foo} 的话，这个函 > 数调用也会 > +出一个错。) > + > +如~\textsc{cltl1} 所言，包含内建操作符和变量名字的包被称 > +为~\texttt{common-lisp} 而不是~ > \texttt{lisp}，因此新一些的包在缺省情况 > +下已不再使用~\texttt{lisp} 包了。由于我们通过调用~\texttt{in-package} > +创建了~\texttt{mine}，而在这次调用中也~\texttt{use} 了这个包，所以所 > +有~Common Lisp 的名字在~\texttt{mine} 中都是可见的： > +\begin{verbatim} > +MINE> #'cons > +#<Compiled-Function CONS 462A3E> > +\end{verbatim} > +在实际的编程中，你不得不让所有新编写 > 的包使用~\texttt{common-lisp} (或者 > +其他某个含~Lisp 操作符的包)。否则你甚至会没办法跳出这个新的 > +包。\footnote{译者注：即你不仅没有办法使用~\texttt{cons}，更糟糕的 > + 是，你也不能用~\texttt{in-package} 切换到其它包。} > + > +一般来说，在编译后的代码中，不会像刚 > 才这样在顶层进行包的操作。更多的时 > +候，这些关于包的函数调用会被包含在源文件中。通常，只要 > +把~\texttt{in-package} 和~ > \texttt{defpackage}\index{defpackage@ > \texttt{defpackage}} 放在源文件的开头就可以 > +了。(\texttt{defpackage} 宏是~\textsc{cltl2} 里新引进 > 的，但是有些较老的 > +实现也提供了它。) 如果你要编写一个独立的包，下面列出了你可能会放在 > +对应的源文件最开始地方的代码： > +\begin{verbatim} > +(in-package ’my-application :use ’common-lisp) > +(defpackage my-application > + (:use common-lisp my-utilities) > + (:nicknames app) > + (:export win lose draw)) > +\end{verbatim} > +这会使得该文件里所有的代码，或者更准确地说，文件里所有的名字，都纳入 > +了~\texttt{my-application} 这个包。\texttt{my-application} 同时使用 > +了~\texttt{common-lisp} 和~ > \texttt{my-utilities}，因此，不用加任何包名 > +作为前缀，所有被引出的符号都可以直接使用。 > + > +\texttt{my-application} 本身仅仅引出了三个符号，它们分别 > +是：\texttt{win}、\texttt{lose} 和~\texttt{draw}。由于在调 > +用~\texttt{in-package} 的时候，我们给~\texttt{my- > application} 取了一个 > +绰号~\texttt{app}，在其它包里面的代码可以用类 > 似~\texttt{app:win} 的名字 > +来引用这些符号。 > + > +像这样的用包来提供的模块化的确有点不 > 自然。我们的包里面不是对象，而是一 > +堆名字。每个使用~\texttt{common- > lisp} 的包都引入了~\texttt{cons} 这个名 > +字，原因在于~\texttt{common-lisp} 包含了一个叫这个名字的函数。但是， > 这 > +样会导致一个名字叫~\texttt{cons} 的变量也在每个使 > +用~\texttt{common-lisp} 可见。这样的 > 事情同样也会在~Common Lisp 的其他名 > +字空间重演。如果包 (package) 这个机制 > 让你头痛，那么这就是一个最主要的原 > +因\pozhehao包不是基于对象的，它们基于名字。 > + > +和包相关的操作会发生在读取时 (read- > time)，而非运行时。这可能会造成一些 > +困扰。我们输入的第二个表达式： > +\begin{verbatim} > +(symbol-package ’foo) > +\end{verbatim} > +之所以会返回它返回的那个值是因为： > \textsl{读取这个查询语句的同时，答案就被生成了}。 > +为了求值这个表达式，Lisp 必须先读入 > 它，这意味着要~intern~\texttt{foo}。 > + > +再来个例子，看看下面把两个表达式交换 > 顺序的结果，这两个表达式上面曾出现过： > +\begin{verbatim} > +MINE> (in-package ’common-lisp-user) > +#<Package "COMMON-LISP-USER" 4CD15E> > +> (export ’bar) > +\end{verbatim} > +通常来说，在顶层输入两个表达式的效果等价于把这两个表达式放在一 > +个~\texttt{progn}里面。不过这次有些不同。如果我们这样说 > +\begin{verbatim} > +MINE> (progn (in-package ’common-lisp-user) > + (export ’bar)) > +>>Error: MINE::BAR is not accessible in COMMON-LISP-USER. > +\end{verbatim} > +我们则会得到个错误提示。错误的原因在 > 于~\texttt{progn} 表达式在求值之前 > +就已经被~\texttt{read} 处理过了。当调用~\texttt{read} 时，当前包还 > +是~\texttt{mine}，因而~\texttt{bar} 被认为是~ > \texttt{mine:bar}。 运行这 > +个表达式的效果就好像我们想要~export ~ > \texttt{mine:bar}，而不是从 user 包 > +里~\texttt{common-lisp-user:bar}。 > + > +package 被如此定义，使得编写那些把符 > 号当作数据的程序成为一桩麻烦事。举个例 > 子，要是我们像下面那样定义~\texttt{noise}： > +\begin{verbatim} > +(in-package ’other :use ’common-lisp) > +(defpackage other > + (:use common-lisp) > + (:export noise)) > +(defun noise (animal) > + (case animal > + (dog ’woof) > + (cat ’meow) > + (pig ’oink))) > +\end{verbatim} > +这样的话，如果我们从另外一个包调用~ > \texttt{noise}，同时传进去的参数是不 > +恰当的符号，\texttt{noise} 会走到~\texttt{case} 语句的末尾，并且返 > +回~\texttt{nil}： > +\begin{verbatim} > +OTHER> (in-package ’common-lisp-user) > +#<Package "COMMON-LISP-USER" 4CD15E> > +> (other:noise ’pig) > +NIL > +\end{verbatim} > +这是因为我们传进去的参数是~ > \texttt{common-lisp-user:pig} (这不是想冒犯 > +你)，然而~\texttt{case} 接受~key 是~\texttt{other:pig}。为了 > +让~\texttt{noise} 如所想的那样工作， > 我们必须把里面用到的所有六个符号都 > +引出来，再在我们调用~\texttt{noise} 的包里面引入它们。 > + > +在这个例子里面，我们也可以通过使用关 > 键字而不是常规的符号，来绕过这个问 > +题。倘若~\texttt{noise} 像下面这样定义 > +\begin{verbatim} > +(defun noise (animal) > + (case animal > + (:dog :woof) > + (:cat :meow) > + (:pig :oink))) > +\end{verbatim} > +这样我们就能从任意一个包调用安全地调用这个函数了： > +\begin{verbatim} > +OTHER> (in-package ’common-lisp-user) > +#<Package "COMMON-LISP-USER" 4CD15E> > +> (other:noise :pig) > +:OINK > +\end{verbatim} > + > +关键字就像金子：普适而且自身就能表明其价值。它们不论在哪里都是可见 > +的，而且从来就没有要加上引用才能使用 > 它们的必要。符号驱动的函数几乎总是 > +应当使用关键字编写而成，比如~\texttt{defamaph} > +(第~\pageref{func:defanaph} 页)。 > + > +包里面有很多地方让人困惑不解。这里对 > 这一主题的介绍仅仅是冰山一角。要知 > +道所有的细节，请参考~\textsc{cltl2}，第~11 章。 > + > + > %%% Local Variables: > %%% coding: utf-8 > %%% mode: latex > > > This was sent by the SourceForge.net collaborative development > platform, the world's largest Open Source development site. |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-03-14 19:24:12
|
Hi, > >>> This works great. Obviously MIP parsing is desirable, but so >>> many of my other tools don't bother that its easy to use the >>> OIDs. I >>> keep lists of the things myself in several tools. >> >> I decide throw ZEBU and switch to other LALR parser tools. On >> LispWorks, I can use the "parsergen" tool which shiped with LW, and >> for other Lisps, the cl-yacc and cl-lexer can work. > > Is ASN.1 parsable with a META parser, or is it too tricky? Sorry, not quite know about "META" parser, I'm newbie in this area. I've read most of ASN.1 specifications, it's too complex, even the subset use by SNMP. At begin I want to write a ASN.1 compiler which "transform" ASN.1 type definitions into CLOS and Lisp code which do encode/decode, but soon found it's too hard for me. So now I only get SNMP Object ID definitions from SNMP MIB files, this can be done by a pure LALR parser. > > >> The most important part of my design is A expert system built on >> KnowledgeWorks(R) or LISA (lisa.sourceforge.net), and ResearchCyc. I >> want to use AI theory to detect whether/when a remote device is >> health >> or not, then give SA alerts (SMS, Mail, GTalk, ...) and even >> operation >> advice... In this part, OPS5/CLIPS_like forward-chain rules is more >> fit than the Prolog_like backward-chain rules. The GBBopen project >> may >> also be used to solve something... > > I agree that LISA or some similar tool would be very useful > here. My main interest in PROLOG is that I find it (or rather, > unification) is a really nice database. With careful rules you can > extract data in sophisticated ways I find more pleasant than > SQL+postprocessing. There's a book called "Knowledge Representation" by John F. Sowa. I suggest you read it (if haven't) PROLOG is good for backward-chain logic, which can basically be expressed by SQL's VIEW. (And a forward-chain logic can be expressed as SQL's TRIGGER) The problem is: you cannot write all your "data" in PROLOG source code files, as many FACTs, there must be a external storage for PROLOG logic engine to get/put FACTs. So far as I know, SWI-Prolog can use facts which be stored in SQL databases by a ODBC interface. And LispWorks' KnowledgeWorks(R) can use CommonSQL to access data in SQL databases. For LISA, don't know that. If you choose a PROLOG or other similar tools to do a SA job, it's better to choose one which can support external data source. > > >> A little crazy, like you? ^_^ > > It's uncanny! Except for a few technology choices (I favor > Hunchentoot over CL-HTTP), we want to do a lot of the same things. The Web interface part is not the key part, use whatever is good. I do not have a full plan but just write part by part from bottom to top, it's the Lisp way to do a big project. > > > -- > wm > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > CL-Net-SNMP-General mailing list > CL-...@li... > https://lists.sourceforge.net/lists/listinfo/cl-net-snmp-general |
|
From: William A. <an...@bi...> - 2008-03-14 18:38:49
|
>> This works great. Obviously MIP parsing is desirable, but so
>> many of my other tools don't bother that its easy to use the OIDs. I
>> keep lists of the things myself in several tools.
>
>I decide throw ZEBU and switch to other LALR parser tools. On
>LispWorks, I can use the "parsergen" tool which shiped with LW, and
>for other Lisps, the cl-yacc and cl-lexer can work.
Is ASN.1 parsable with a META parser, or is it too tricky?
>The most important part of my design is A expert system built on
>KnowledgeWorks(R) or LISA (lisa.sourceforge.net), and ResearchCyc. I
>want to use AI theory to detect whether/when a remote device is health
>or not, then give SA alerts (SMS, Mail, GTalk, ...) and even operation
>advice... In this part, OPS5/CLIPS_like forward-chain rules is more
>fit than the Prolog_like backward-chain rules. The GBBopen project may
>also be used to solve something...
I agree that LISA or some similar tool would be very useful
here. My main interest in PROLOG is that I find it (or rather,
unification) is a really nice database. With careful rules you can
extract data in sophisticated ways I find more pleasant than
SQL+postprocessing.
>A little crazy, like you? ^_^
It's uncanny! Except for a few technology choices (I favor
Hunchentoot over CL-HTTP), we want to do a lot of the same things.
--
wm
|
|
From: Chun T. (binghe) <bin...@gm...> - 2008-03-14 16:45:38
|
Hi, W. A. (I've made a mailing list: cl-...@li...) > >> The key is, use #(1 3 6 1 2 1 1 1 0), just a sequence (list is also >> OK), instead of "sysDescr.0" >> >> This can let you quick start to test the core of cl-net-snmp. > > This works great. Obviously MIP parsing is desirable, but so > many of my other tools don't bother that its easy to use the OIDs. I > keep lists of the things myself in several tools. I decide throw ZEBU and switch to other LALR parser tools. On LispWorks, I can use the "parsergen" tool which shiped with LW, and for other Lisps, the cl-yacc and cl-lexer can work. Today I've done the UDP retransmit support on LispWorks, and implement the SNMPv1 Trap (SNMPv2-Trap, and InformRequest support are under way). The UDP retransmit support is necessary for product use of SNMP package, I'll try to use USOCKET to port to other CLs. So much TODO, if you want more, wait:) > > > Are you using your SNMP library in other tools? If you're > interested, here are some of my crazy ideas about system monitoring: > http://www.biostat.wisc.edu/~annis/granny/ I started to implement > this in Python, but I found myself wanting to use certain kinds of > PROLOG functionality, and Lisp has better libraries for that than > Python. Besides, I like Lisp better. My goal is a intelligent network management platform based on Lisp. I want to use SNMP and IPMI protocol to get remote *nix server status (both software and hardware), store these status into SQL database (use CL-SQL) or Object database (use the Elephant project). Use a Common Lisp Web Server (CL-HTTP for LispWorks) as a user interface. I also write native GUI clients (some of them in cl-net-snmp repository). The most important part of my design is A expert system built on KnowledgeWorks(R) or LISA (lisa.sourceforge.net), and ResearchCyc. I want to use AI theory to detect whether/when a remote device is health or not, then give SA alerts (SMS, Mail, GTalk, ...) and even operation advice... In this part, OPS5/CLIPS_like forward-chain rules is more fit than the Prolog_like backward-chain rules. The GBBopen project may also be used to solve something... A little crazy, like you? ^_^ Regards, Chun Tian (binghe) > > > -- > wm |
|
From: Chun T. (binghe) <bin...@gm...> - 2008-03-13 20:19:33
|
Hi, cl-net-snmp-general Check if things can work... -- binghe Owner |
