Re: Why Lisp is too hard for me to use

From: Björn Lindberg (d95-bli_at_nada.kth.se)
Date: 12/28/03 

Date: 28 Dec 2003 01:28:40 +0100

ngps@netmemetic.com (Ng Pheng Siong) writes:

> According to Eladio <eladio_ventura@yahoo.com>:
> > struggling to do just that, and if FreeBSD won't let me...
>
> Of course FreeBSD lets you; you just have to ask properly. ;-)
>
> But really this hasn't much to do with operating systems. (My POV may be
> "different": I was a system administrator of several flavours of Un*x and
> Windows for some years before moving to programming.)
>
> Going back two nodes in this thread tree, I see you're talking about
> (require 'asdf) and (require 'asdf-install).
>
> Well, I haven't looked at asdf-install, but for asdf, I did the following:
>
> [ ... ]

I have the following code for getting asdf packages to work:

==>BEGIN<==================================
(in-package :asdf)

(push "/home/bjorn/share/common-lisp/system/" *central-registry*)

(defvar *system-configuration-paths*
  '(("/home/bjorn/share/common-lisp/src/"
     "/home/bjorn/lib/common-lisp/cmucl/")))

(defun pathname-prefix-p (prefix pathname)
  "Tar två sökvägsnamn eller namnsträngar och returnerar sant om det
första är ett prefix i det andra. :absolute/:relative först i
kataloglistan fungerar som ankare, vilket gör att SEARCH inte kan
matcha en dellista mitt i."
  (search (pathname-directory prefix)
          (pathname-directory pathname)
          :test #'equal))

(defmacro iterate (name bindings &body body)
  `(labels ((,name ,(mapcar #'first bindings)
             ,@body))
    (,name ,@(mapcar #'second bindings))))

(defmethod output-files :around ((operation compile-op)
                                      (c cl-source-file))
  (let* ((source-pathname (component-pathname c))
         (default-pathname (car (call-next-method)))
         (type (pathname-type default-pathname)))
    (iterate iter ((translations *system-configuration-paths*))
      (let ((translation (first translations)))
        (cond ((null translations) default-pathname)
              ((pathname-prefix-p (first translation) default-pathname)
               (list
                (translate-pathname source-pathname
                                    (merge-pathnames
                                     (make-pathname :directory
                                                    '(:relative :wild-inferiors)
                                                    :type
                                                    :wild)
                                     (first translation))
                                    (merge-pathnames
                                     (make-pathname :directory
                                                    '(:relative :wild-inferiors)
                                                    :type
                                                    type)
                                     (second translation)))))
              (t
               (iter (rest translations))))))))

==>END<====================================

Now I can put asdf-installable packages (in the tarball sense) under
/home/bjorn/share/common-lisp/src & symlink the .asd file to
/home/bjorn/share/common-lisp/system. That is all that is necessary to
be able to work with it in lisp. In cmucl I can now just write (asdf:oos
'asdf:load-op :cl-ppcre) to eg load the cl-ppcre library. I meant to
expand on the code to make it work with defsystem and clisp as well,
but I haven't gotten around to it yet. Half the point is trying to
parameterize the directories where source, binaries & system
definitions exist. For instance, the *system-configuration-paths*
variable above can have several directory pairs, and the right ones
will be used (eg one can have both /home/user/.../ dirs and
/usr/local/.../ dirs). (Sorry about the iterate macro; I haven't
really learned LOOP yet.)

A comment on the broader issue discussed in this thread: I would like
to see some sort of agreed-upon (informal) standards developed for CL
on Unix. Standardized places where source and binary files go in the
file system, perhaps some standardized environment variables. Compare
with C: anyone writing or installing a C library, or packaging a
library for a distro, can count on the basic directory structure, with
/.../{lib,include}, can count on environment variables like CC, LD_*,
etc. I think more of a de facto standard in this area for CL would
make it much easier for people to use different
administration/installation tools, different distro packaging systems,
and lots of other issues like that.

Björn

Relevant Pages

  • Re: J3 Responses to Public Comments
    ... implented in various operating systems and applications for many ... standards in this area that could be referenced. ... section notes they should reference the appropriate other ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Comparison of Linux/Unix binary package formats
    ... A series of interviews with dpkg developers: ... working with binary packages ... ... "Another big benefit of pkgsrc is its simplicity. ... selecting different operating systems: ...
    (comp.os.minix)
  • Re: How About..............
    ... > there were lots of OSes around not just unix and dos. ... >> Back in the old days when Unix and Dos were the only operating systems, ... >> would have abstracted this layer out of the way, ... >> So much talk about reusability, abstraction and standards, yet there is ...
    (comp.lang.java.programmer)
  • Re: PL/SQL Coding Standards
    ... > the Oracle PL/SQL Coding ... > Standards to Follow. ... include a "who am I" type function. ... Great for managing packages that might be updated outside your control ...
    (comp.databases.oracle.misc)
  • Re: Consultation on Public Sector Web Sites
    ... should not support British computers and operating systems. ... their take on standards or in Microsofts langauage enhanced standards ... Using an IYONIX pc and RISC OS 5.13, ...
    (comp.sys.acorn.advocacy)