[cl-typesetting-devel] A couple of bugs?

[Björn Lindberg]

"Marc Battyani" <marc.battyani at fractalconcept.com> writes:

> Björn Lindberg wrote:
> 
> >I just managed to install cl-typesetting on CMUCL 19/Linux/x86, and
> >had to overcome a couple of difficulties to succeed:
> >
> >1) In boxes.lisp, the generic function
> >
> >  (defgeneric v-split ((box v-mode-mixin) dx dy)
> >   ;;; Split a v-mode box vertically into two parts
> >    ;; Args: dx - area width, dy - area height
> >    ;; Values: box-fitted, box-left, dy-left
> >   (:method (box dx dy)
> >    (declare (ignore dx))
> >    (if (> (dy box) dy)
> >        (values nil box dy)
> >        (values box nil (- dy (dy box))))))
> >
> >should reasonably look like this
> >
> >  (defgeneric v-split (box dx dy)
> >   ;;; Split a v-mode box vertically into two parts
> >    ;; Args: dx - area width, dy - area height
> >    ;; Values: box-fitted, box-left, dy-left
> >   (:method ((box v-mode-mixin) dx dy)
> >    (declare (ignore dx))
> >    (if (> (dy box) dy)
> >        (values nil box dy)
> >        (values box nil (- dy (dy box))))))
> >
> >Ie the argument specialization is moved from the GF lambda list down
> >to the method lambda list.
> 
> You are right, it should be a generic function lambda list, not a
> specialized one.
> I never use defgeneric with methods included in the definition as I think
> it's not readable and not searchable (by grep, etc.)
> I will correct this and put a separate defmethod.
> 
> >2) The file iterate/iterate.lisp in cl-pdf is stored in DOS format,
> >   which breaks the format invocation at line 737ff. I had to convert
> >   it to Unix format.
> 
> Line 737ff ?

Line 737 and following lines. Sorry about any confusion.

I should mention that I bumped into another problem when installing
both cl-pdf and cl-typesetting, although I do not think it is related
to the packages themselves. I have an around method for
asdf:output-files, to make the FASLs go to a separate directory for
every lisp implementation, which is distinct from the source
directory. For many packages which has additional data files, this
causes an error when ASDF tries to find the data files in the FASL
directory, but they are only available in the source directory.

As I said, I consider this to be an error of ASDF, since I do not
think it has provisions for handling this issue within the system
definition. But a package that wanted to behave nicely could of course
copy the files itself, as a part of the installation process.

Not a big deal though.


Björn