headers
Gary Byers | 2 Jun 2007 09:27
Favicon

Re: `run-program' path search broken

I (somehow) managed to miss this message twice, both with and
without a subject ...  sorry.

My first reaction was to suggest that RUN-PROGRAM's first argument
be changed from "a string or pathname ..." to "a string ... used
in combination with the value of PATH to identify an executable file".
That might be a little too restrictive, and it might be better to
just say that 'any translation of the program argument into something
that the OS can use takes place as if *DEFAULT-PATHNAME-DEFAULTS*
was bound to #p""'.

This would mean that if anyone's (intentionally) doing something
like:

(let* ((*default-pathname-defaults* #p"/usr/local/bin/"))
   ...
   (run-program "ls" ...))

they'd have to instead do

(let* ((*default-pathname-defaults* #p"/usr/local/bin/"))
   ...
   (run-program (merge-pathnames "ls") ...))

That doesn't seem too onerous.

The MERGE-PATHNAMES that currently happens during "translation to
something that the OS can use" isn't entirely intentional, but
it leads to a situation where two referentially opaque things
(PATH and *DEFAULT-PATHNAME-DEFAULTS*) exert influence over what
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scott L. Burson | 2 Jun 2007 20:52

Re: `run-program' path search broken

Hi Gary,

Well, the current documentation for RUN-PROGRAM says "The PATH  
environment variable is used to find programs whose name doesn't  
contain a directory component."  To me this entails that *DEFAULT- 
PATHNAME-DEFAULTS* is irrelevant for this purpose.  (I'm guessing  
that OpenMCL 1.0 indeed ignored it, or the bug I ran into would have  
been found sooner.)  So I would say, if anyone is doing this,

> (let* ((*default-pathname-defaults* #p"/usr/local/bin/"))
>   ...
>   (run-program "ls" ...))

that the documentation doesn't endorse this usage.

On Jun 2, 2007, at 12:27 AM, Gary Byers wrote:

> My first reaction was to suggest that RUN-PROGRAM's first argument
> be changed from "a string or pathname ..." to "a string ... used
> in combination with the value of PATH to identify an executable file".
> That might be a little too restrictive, and it might be better to
> just say that 'any translation of the program argument into something
> that the OS can use takes place as if *DEFAULT-PATHNAME-DEFAULTS*
> was bound to #p""'.

Hmm, I don't get the difference, but maybe it doesn't matter.  I  
agree that adding some clarification to the doc wouldn't hurt.

> The MERGE-PATHNAMES that currently happens during "translation to
> something that the OS can use" isn't entirely intentional
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael J. Ferrador | 9 Jun 2007 04:00
Picon
Favicon

compiled closures for Qi?


I've been apropos-ing around CCL:

does anyone know what might be needed for OpenMCL here?

(DEFUN fix-closures ()
      #+CMU   (SETQ *closures* '(FUNCTION COMPILED-FUNCTION EVAL::INTERPRETED-FUNCTION))
      #+CLISP  (SETQ *closures* '(FUNCTION COMPILED-FUNCTION))
      #+ALLEGRO (SETQ *closures* '(EXCL::CLOSURE FUNCTION COMPILED-FUNCTION))
      #+SBCL   (SETQ *closures*
                   '(FUNCTION COMPILED-FUNCTION SB-EVAL:INTERPRETED-FUNCTION))
     #-(OR CLISP CMU SBCL ALLEGRO)
       (ERROR "Qi does not recognise this platform ~A" (LISP-IMPLEMENTATION-TYPE)))

I have the other blocks of save (core), & quit

just dabbling on the Prolog side with Qi from http://www.lambdassociates.org/
Permalink | Reply | 3 comments |
headers
Gary Byers | 9 Jun 2007 11:23
Favicon

Re: compiled closures for Qi?


On Sat, 9 Jun 2007, Michael J. Ferrador wrote:

>
> I've been apropos-ing around CCL:
>
> does anyone know what might be needed for OpenMCL here?
>

How would anyone know what would be needed ?  Is there documentation
anywhere that explains what value *CLOSURES* is supposed to have or
how that value is used ?

Is it supposed to be an exhaustive list of specifiers for all subtypes
of FUNCTION in each supported implementation ? If so, why is it called
*CLOSURES*, and if not, which subtypes of FUNCTION are included and
which are excluded ?

> (DEFUN fix-closures ()
>      #+CMU   (SETQ *closures* '(FUNCTION COMPILED-FUNCTION EVAL::INTERPRETED-FUNCTION))
>      #+CLISP  (SETQ *closures* '(FUNCTION COMPILED-FUNCTION))
>      #+ALLEGRO (SETQ *closures* '(EXCL::CLOSURE FUNCTION COMPILED-FUNCTION))
>      #+SBCL   (SETQ *closures*
>                   '(FUNCTION COMPILED-FUNCTION SB-EVAL:INTERPRETED-FUNCTION))
>     #-(OR CLISP CMU SBCL ALLEGRO)
>       (ERROR "Qi does not recognise this platform ~A" (LISP-IMPLEMENTATION-TYPE)))
>
> I have the other blocks of save (core), & quit
>
> just dabbling on the Prolog side with Qi from http://www.lambdassociates.org/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael J. Ferrador | 9 Jun 2007 17:47
Picon
Favicon

Re: compiled closures for Qi?

Gary Byers <gb <at> clozure.com> writes:
> 
> On Sat, 9 Jun 2007, Michael J. Ferrador wrote:
> 
> > I've been apropos-ing around CCL:
> >
> > does anyone know what might be needed for OpenMCL here?
> 
> How would anyone know what would be needed ?

Sorry if this was inapropriate.

I was just trying to cut down the number of CLs 
I have on certain machines and this seemed like a
somewhat deep internal thing.

I thought there might be some people here who
knew / compared to some other CL internals.

> Is there documentation anywhere that explains what value
> *CLOSURES* is supposed to have or how that value is used ?

I'm still learning to read Qi (written in itself)
though it does compile into CL.

I think the Qi functions, in addition to the CL compiled function,
is packing up some (In -> Out) type info along with it.

> > I have the other blocks of save (core), & quit
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gary Byers | 9 Jun 2007 20:25
Favicon

Re: compiled closures for Qi?

Here's a list of the names of all classes which are subtypes of FUNCTION
in OpenMCL:

FUNCTION
COMPILED-FUNCTION       ; Note that FUNCTION and COMPILED-FUNCTION
                         ; are the same type/class in OpenMCL:
                         ; all FUNCTIONs are COMPILED-FUNCTIONs.

STANDARD-GENERIC-FUNCTION ; as per CLhS
GENERIC-FUNCTION        ; as per CLhS

CCL:METHOD-FUNCTION     ; a special type of function that implements
                         ;  a method.  (The symbol is also an
                         ;  accessor for METHOD objects ad defined in
                         ;  the MOP spec.)
CCL::COMBINED-METHOD    ; used internally in the CLOS implementation

CCL:FUNCALLABLE-STANDARD-OBJECT ; as per the MOP, a superclass of
                         ; GENERIC-FUNCTION.

CCL:COMPILED-LEXICAL-CLOSURE ; A FUNCTION (compiled function) which
                         ; is not a CCL:METHOD-FUNCTION and is not
                         ; a FUNCALLABLE-STANDARD-OBJECT and which
                         ; references things (variable bindings, usually)
                         ; defined in the enclosing lexical environment.

If anyone does know what *CLOSURES* is in Qi and how it's used, that
information might help them to determine how it should be set for
OpenMCL.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jared C. Davis | 15 Jun 2007 17:31
Picon
Gravatar

Trouble with save-application

Hi,

I am trying to create a lisp image which runs a "main" function at
startup.  Here is how I created the image:

    (defun main ()
      (format t "Hello, world!")
      (CCL::quit))

    (CCL::save-application "hello-world.image" :toplevel-function #'main)

This successfuly creates the hello-world.image file, but when I try to
use the image I get this error:

    [jared <at> lhug-1 OpenMCL]$ openmcl -I hello-world.image
    Error during early application initialization:

    value #<A Dead Mac Pointer> is not of the expected type MACPTR.
    ? for help
    [26302] OpenMCL kernel debugger:

I am using 1.1-pre-070512 (LinuxX8664).  I'm not sure if I've done
something wrong or if this is a bug, so in case it's a bug here is the
backtrace.

current thread: tcr = 0x2b2baac46de0, native thread ID = 0x66be,
interrupts enabled

(#x00002B2BAAE58CF8) #x000030004055281C : #<Anonymous Function
#x000030004055192F> + 3821
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gary Byers | 15 Jun 2007 18:11
Favicon

Re: Trouble with save-application

None of this is documented, and large chunks of it aren't finished.

The general (handwavy) idea is that the image by default contains
a certain type of application (a "lisp development system"), and
that it should be possible to create an image that contains a
different class of application by defining that class and defining
a few methods.

? (defclass hello-world-application (ccl::application) ())
HELLO-WORLD-APPLICATION
? (defmethod toplevel-function ((app hello-world-application) init-file)
      (declare (ignore init-file))
      (call-next-method) ; this is critical, but shouldn't be.
      (format t "~& hello world")
      (quit))

;;; Tell SAVE-APPLICATION what class of application the saved image
;;; will be.
? (save-application "hello-world.image" :application-class 'hello-world-application)

shell> openmcl64 -I hello-world.image
  hello, world

That works (as far as it goes), but if you want to do something more
elaborate, it gets complicated and a lot of this just isn't ready for
prime-time.

The CALL-NEXT-METHOD in the definition of the method above is critical:
the superclass's method does a lot of things (reinitializing streams,
etc.)  That stuff is critical to practically any application, but it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jared C. Davis | 15 Jun 2007 19:19
Picon
Gravatar

Inlining bug?

Hi,

It seems like inlining breaks the following code on 1.1-pre-070512
(LinuxX8664) and also on
1.1-pre-070408 (LinuxX8664).

When I remove any of the "(declaim (inline ...))" calls, (len '(1 2
3)) correctly returns 3.  But when they are all present, it
incorrectly returns 0.

   (declaim (inline natp))
   (declaim (inline nfix))
   (declaim (inline nat+))

   (defun natp (x)
     (and (integerp x)
          (<= 0 x)))

   (defun nfix (x)
     (if (natp x) x 0))

   (defun nat+ (a b)
     (+ (nfix a) (nfix b)))

   (defun len (x)
     (if (consp x)
         (nat+ 1 (len (cdr x)))
       0))

   (len '(1 2 3))  ;; Incorrectly returns 0 instead of 3
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gary Byers | 15 Jun 2007 21:31
Favicon

Re: Inlining bug?

If I checked in the right file to the right place, the fix should show
up in CVS in about 45 minutes.

On Fri, 15 Jun 2007, Jared C. Davis wrote:

> Hi,
>
> It seems like inlining breaks the following code on 1.1-pre-070512
> (LinuxX8664) and also on
> 1.1-pre-070408 (LinuxX8664).
>
> When I remove any of the "(declaim (inline ...))" calls, (len '(1 2
> 3)) correctly returns 3.  But when they are all present, it
> incorrectly returns 0.
>
>   (declaim (inline natp))
>   (declaim (inline nfix))
>   (declaim (inline nat+))
>
>   (defun natp (x)
>     (and (integerp x)
>          (<= 0 x)))
>
>   (defun nfix (x)
>     (if (natp x) x 0))
>
>   (defun nat+ (a b)
>     (+ (nfix a) (nfix b)))
>
>   (defun len (x)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane