headers
james anderson | 6 Mar 2003 23:58
Picon
Gravatar

docbook and clos

hello;

i heard a rumor that you use docbook for your documentation. i'm 
looking for a "reasonable" format for a encoding for system 
documentation. i rummaged through your release and observe that your 
docbook use appears to be restricted to hand-coded sgml. for instance, 
i found nothing in the release which uses the documentation function. 
has there been any work on generating the system documentation from the 
source?

thanks.

...

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
Permalink | Reply | 4 comments |
headers
Paolo Amoroso | 7 Mar 2003 13:57
Picon
Favicon

Re: docbook and clos

On Thu, 6 Mar 2003 23:58:29 +0100, James Anderson wrote:

> i heard a rumor that you use docbook for your documentation. i'm 

The manual of Pierre Mai's MaiSQL(sp?) is based on a version of DocBook
tweaked to the needs of Lisp documentation.

Paolo
--

-- 
Paolo Amoroso <amoroso <at> mclink.it>

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
Permalink | Reply | 0 comments |
headers
William Harold Newman | 7 Mar 2003 15:38

Re: docbook and clos

On Thu, Mar 06, 2003 at 11:58:29PM +0100, james anderson wrote:
> i heard a rumor that you use docbook for your documentation. i'm 
> looking for a "reasonable" format for a encoding for system 
> documentation. i rummaged through your release and observe that your 
> docbook use appears to be restricted to hand-coded sgml. for instance, 
> i found nothing in the release which uses the documentation function. 
> has there been any work on generating the system documentation from the 
> source?

You're right, we use DocBook for the system manual, and we don't have
any special mechanism for generating DocBook-formatted text
automatically from the .lisp source files.

--

-- 
William Harold Newman <william.newman <at> airmail.net>
"Build a man a fire, and he'll be warm for a day. Set a man on fire,
and he'll be warm for the rest of his life." -- Terry Pratchett
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
Permalink | Reply | 2 comments |
headers
Christophe Rhodes | 7 Mar 2003 15:48
Picon
Picon
Favicon

Re: docbook and clos

William Harold Newman <william.newman <at> airmail.net> writes:

> On Thu, Mar 06, 2003 at 11:58:29PM +0100, james anderson wrote:
> > i heard a rumor that you use docbook for your documentation. i'm 
> > looking for a "reasonable" format for a encoding for system 
> > documentation. i rummaged through your release and observe that your 
> > docbook use appears to be restricted to hand-coded sgml. for instance, 
> > i found nothing in the release which uses the documentation function. 
> > has there been any work on generating the system documentation from the 
> > source?
> 
> You're right, we use DocBook for the system manual, and we don't have
> any special mechanism for generating DocBook-formatted text
> automatically from the .lisp source files.

That said, I believe there is something in db-sockets (which has
mutated into the sb-bsd-sockets contrib in the SBCL sources) that does
do some kind of introspective analysis of its source and symbols... I
don't know if the code to do that persists in our CVS, but maybe Dan
can say something about that?

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Barlow | 7 Mar 2003 18:25

Re: docbook and clos

Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

> That said, I believe there is something in db-sockets (which has
> mutated into the sb-bsd-sockets contrib in the SBCL sources) that does
> do some kind of introspective analysis of its source and symbols... I
> don't know if the code to do that persists in our CVS, but maybe Dan
> can say something about that?

It's still there, but it doesn't actually run as part of the default
build.  Look at doc.lisp - output is in index.html

* It needs asdf: first it loads a system, then it reads all the files
  in it.

* It currently generates HTML, not DocBook

* It reads #| |# comments, which it includes verbatim in the output

* It converts methods, functions, classes, and some other forms into
  HTML, attempting to do clever things like make hyperlinks out of
  ALL-CAPS words in doc strings

* It's more than a little bit kludgey

-dan

--

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Weimer | 9 Mar 2003 19:12
Picon

Poor performance of hash tables with EQUAL

I've stumbled across a phenomenon I can't explain.  While EQ hash
tables scale almost linearly in terms of hash tables size, EQUAL hash
tables do not.

Compile and load the following test code:

; --------------------------------------------------------------------

(eval-when (:compile-toplevel :load-toplevel)
  (let ((current-bit-vector #32*00000000000000000000000001))
    (defun make-bit-vector ()
      (declare (values simple-bit-vector)
               (optimize (speed 3)))
      (loop for j from 0
            do (cond
                ((= (sbit current-bit-vector j) 0)
                 (setf (sbit current-bit-vector j) 1)
                 (return-from make-bit-vector
                   (copy-seq current-bit-vector)))
                (t (setf (sbit current-bit-vector j) 0)))))

  (defun reset-bit-vector ()
    (setq current-bit-vector #32*00000000000000000000000001))))

(defun test-eq (n)
  (let ((table (make-hash-table)))
    (reset-bit-vector)
    (time (loop for j from 1 to n
                do (setf (gethash (make-bit-vector) table) 0)))))
(Continue reading)

Permalink | Reply | 6 comments |
headers
Gerd Moellmann | 9 Mar 2003 19:29
Picon
Favicon

Re: Poor performance of hash tables with EQUAL

Florian Weimer <fw <at> deneb.enyo.de> writes:

> How can I debug this problem?  Is there some way to count
> collisions?

Not easily, I think.

> Maybe it's just the hash function that's extraordinarily bad...

From CMUCL, probably similar in SBCL:

(defmacro sxhash-bit-vector (vector)
  `(let* ((length (length ,vector))
	  (hash length))
     (declare (type index length) (type hash hash))
     (dotimes (index (min length sxhash-max-len) hash)
       (declare (type index index))
       (sxmash hash (bit ,vector index)))))

with SXHASH-MAX-LEN = 7 won't give very good results in your test
case, I think.

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
Permalink | Reply | 0 comments |
headers
Christophe Rhodes | 9 Mar 2003 19:43
Picon
Picon
Favicon

Re: Poor performance of hash tables with EQUAL

Florian Weimer <fw <at> deneb.enyo.de> writes:

> I've stumbled across a phenomenon I can't explain.  While EQ hash
> tables scale almost linearly in terms of hash tables size, EQUAL hash
> tables do not.
>
> The same call to test-equal does not terminate within a couple of
> minutes.
> 
> How can I debug this problem?  Is there some way to count collisions?
> Maybe it's just the hash function that's extraordinarily bad...

I'd say that the hash function is extraordinarily bad.

from code/target-sxhash.lisp:

               (array
                (typecase x
                  (simple-string (sxhash x)) ; through DEFTRANSFORM
                  (string (%sxhash-substring x))
                  (bit-vector (let ((result 410823708))
                                (declare (type fixnum result))
                                (dotimes (i (min depthoid (length x)))
                                  (mixf result (aref x i)))
                                result))
                  (t (logxor 191020317 (sxhash (array-rank x))))))

So, bearing in mind that DEPTHOID is at most 4, if the first four
elements of a bitvector are the same, SXHASH will give you the same
answer.  I think it's fairly clear that that's not ideal...  (oh, and
(Continue reading)

Permalink | Reply | 4 comments |
headers
Florian Weimer | 9 Mar 2003 22:42
Picon

Re: Poor performance of hash tables with EQUAL

Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

> So, bearing in mind that DEPTHOID is at most 4, if the first four
> elements of a bitvector are the same, SXHASH will give you the same
> answer.  I think it's fairly clear that that's not ideal...

Oh, I see. 8-(

I'm not really fixed to using bit vectors in this way.  Anyway, I'm
slightly concerned by the fact that there doesn't appear to be an
efficient to treat parts of the bit vector as fixnums (something like
LDB).  If SXHASH worked on machine words instead of individual bytes,
it certainly could look at more than just 4 bits...

The bit vectors I'm interested in are between 0 and 32 bits long.  I
could use a vector of five octets (four for the bits and one for the
length), and get away without a hashed length.  Hmm.

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
Permalink | Reply | 3 comments |
headers
Christophe Rhodes | 9 Mar 2003 23:05
Picon
Picon
Favicon

Re: Poor performance of hash tables with EQUAL

Florian Weimer <fw <at> deneb.enyo.de> writes:

> Christophe Rhodes <csr21 <at> cam.ac.uk> writes:
> 
> > So, bearing in mind that DEPTHOID is at most 4, if the first four
> > elements of a bitvector are the same, SXHASH will give you the same
> > answer.  I think it's fairly clear that that's not ideal...
> 
> Oh, I see. 8-(
> 
> I'm not really fixed to using bit vectors in this way.  Anyway, I'm
> slightly concerned by the fact that there doesn't appear to be an
> efficient to treat parts of the bit vector as fixnums (something like
> LDB).  If SXHASH worked on machine words instead of individual bytes,
> it certainly could look at more than just 4 bits...
> 
> The bit vectors I'm interested in are between 0 and 32 bits long.  I
> could use a vector of five octets (four for the bits and one for the
> length), and get away without a hashed length.  Hmm.

If your application isn't of a "right now this moment" priority, I'm
fairly sure that I or someone else can come up with a fix for this
behaviour, either generally or for you specifically in the next week
or so.

I can't promise anything, obviously, in that I haven't had time to
explore the problem space, but a solution exists, and it's probably
just a matter of finding it.  For instance, there are
(implementation-specific) primitives that we have access to that can
access the elements of this kind of bit-vector as an (unsigned-byte
(Continue reading)

Permalink | Reply | 2 comments |

Gmane