Re: [Axiom-developer] Re: source for literate lisp noweb

[Waldek Hebisch]

> I responded to Tim privately, but I should say something on the list
> too - here's the latest.
> 
> This morning I have managed to get back to a point where the notangle
> operation is succeeding again on SBCL and CMUCL.  The previously
> mentioned problems with running on GCL have not vanished, unfortunately
> - so if this work is ever to be incorporated into Axiom we need to
> either get GCL up to par or figure out how to conditionalize for GCL.
> 
> Performance wise, things look pretty good - this is the time report for
> notangle on boot, interp and algebra directories running on sbcl:
> 
> Standard noweb:
> 
> Evaluation took:
>   14.045 seconds of real time
>   2.212138 seconds of user run time
>   1.524095 seconds of system run time
>   [Run times include 0.044 seconds GC run time.]
>   0 calls to %EVAL
>   0 page faults and
>   37,579,008 bytes consed.
> T
>

I wonder why there is so much consing (and run time) here: all you
have to do in Lisp is to create a few thousends of processes.  And
most of the run time should be in system calls (system time looks
just OK for that work).  IIUC actual noweb run time contibutes to real
time, but does not show as Lisp run time, so I wonder what else
is Lisp doing.
 
> Lisp implementation:
> 
> Evaluation took:
>   1.723 seconds of real time
>   1.392087 seconds of user run time
>   0.332021 seconds of system run time
>   [Run times include 0.032 seconds GC run time.]
>   0 calls to %EVAL
>   0 page faults and
>   39,882,408 bytes consed.
> T
> 
> Which is all well and good,

It seems that doing the work takes similar time like creating
worker processes...

> but the correctness does not seem to be
> quite complete yet.  I ran a recursive diff on the two results with my
> latest iteration - most of the differences immediately attributable are
> due to a lack of an ending return character at the end of file, and I
> don't know how critical that is - it can be added if need be.  There is
> a great deal of whitespace difference, but filtering that out the key
> remaining difficulties seem to be in some instances in the code where
> line returns are not present - I don't know if they are critical to
> functionality or not, and with any luck inserting the returns in the
> files will cure it.  The only really serious difference that is
> obviously serious is found in numtheor.spad:
> 
> diff -r -w notangle/algebra/numtheor.spad lispnt/algebra/numtheor.spad
> 56,59c56
> <   chineseRemainder: (I,I,I,I) -> I
> <     ++ \spad{chineseRemainder(x1,m1,x2,m2)} returns w, where w is
> such that
> <     ++ \spad{w = x1 mod m1} and \spad{w = x2 mod m2}. Note: \spad{m1}
> and
> <     ++ \spad{m2} must be relatively prime.
> ---
> > <<chineseRemainder: (I,I,I,I) -> I>>
> 174c171
> <   inverse : (I,I) -> I
> ---
> > <<inverse : (I,I) -> I>>
> 483d479
> 

This discrepancy is in version that I posted in:

http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00158.html

namely the fragment below (which searches for chunk start) assumed that
'>' can not occur in chunk name, if it is allowed one should use the
following code:

       in-chunk-start-tag-3
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code end-tag-code-2)
             (go in-chunk-start-tag-4))
         (if (eql code newline-code)
             (go normal-start))
         (go in-chunk-start-tag)
             ^^^^^^^^^^^^^^^^^^^
    was  (go normal)

Incidentally, the other part (which scans for <<...>> markers)
allows '>' in the name.

-- 
                              Waldek Hebisch
address@hidden