Errors using Guile 2.0 vs. Guile 1.8

Errors using Guile 2.0 vs. Guile 1.8

[Paul Smith]

Hi all.

To test my GNU make Guile integration I was using guile 1.8 which is
what my distribution provided.  To test the newer Guile 2.x I downloaded
the Guile 2.0.3 release and built it and installed in an alternate
location (/opt/guile).  I compiled GNU make using that version, and all
the tests ultimately work BUT whenever I use (define ...) from within
GNU make I get these errors:

        $ cat g1.mk
        define show
        (define (show s)
          (display s)
          (newline))
        endef
        $(info define display)
        $(guile $(show))
        $(info after define)
        $(guile (show "HI"))
        all:;
        
        $ make -f g1.mk
        define display
        Backtrace:
        In ice-9/boot-9.scm:
         162: 5 [catch #t #<catch-closure 1cb55c0> ...]
         170: 4 [#<procedure 1cb8cd0 ()>]
        In unknown file:
           ?: 3 [catch-closure]
        In ice-9/eval.scm:
         389: 2 [eval # #]
         374: 1 [eval # #]
        In unknown file:
           ?: 0 [scm-error misc-error #f ...]
        
        ERROR: In procedure scm-error:
        ERROR: Unknown object: #<variable 1cd0180 value: #<procedure 1cb95a0 at ice-9/eval.scm:378:13 (a)>>
        after define
        HI
        make: `all' is up to date.

I don't know what this means, or how to proceed with debugging.  The
same code works fine with Guile 1.8.

Did I make a mistake with my build or install of Guile 2.0.3?

Thoughts?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Re: Errors using Guile 2.0 vs. Guile 1.8

[Thien-Thi Nguyen]

() Paul Smith <psmith@gnu.org>
() Sun, 29 Jan 2012 10:54:18 -0500

           $ cat g1.mk
           define show
           (define (show s)
             (display s)
             (newline))
           endef
           $(info define display)
           $(guile $(show))
           $(info after define)
           $(guile (show "HI"))      # this one
           all:;

   I don't know what this means, or how to proceed with debugging.

What happens if you change the marked line to:

           $(guile (map object->string
                        (list show
                              current-output-port
                              (current-output-port))))

?  I would also try simply ‘$(guile show)’, but remember faintly
that such a type would cause an error.  Thinking along these lines
some more, the problem is perhaps with the return value of ‘show’,
which is the return value of calling ‘newline’, which is probably
unspecified.

As for 1.8 vs 2.0, i dare not speculate.

Re: Errors using Guile 2.0 vs. Guile 1.8

[Paul Smith]

On Sun, 2012-01-29 at 22:18 +0100, Thien-Thi Nguyen wrote:
> () Paul Smith <psmith@gnu.org>
> () Sun, 29 Jan 2012 10:54:18 -0500
> 
>            $ cat g1.mk
>            define show
>            (define (show s)
>              (display s)
>              (newline))
>            endef
>            $(info define display)
>            $(guile $(show))
>            $(info after define)
>            $(guile (show "HI"))      # this one
>            all:;
> 
>    I don't know what this means, or how to proceed with debugging.
> 
> What happens if you change the marked line to:
> 
>            $(guile (map object->string
>                         (list show
>                               current-output-port
>                               (current-output-port))))
> 
> ?  I would also try simply ‘$(guile show)’, but remember faintly
> that such a type would cause an error.  Thinking along these lines
> some more, the problem is perhaps with the return value of ‘show’,
> which is the return value of calling ‘newline’, which is probably
> unspecified.
> 
> As for 1.8 vs 2.0, i dare not speculate.

Sorry for being unclear.  What I was trying to indicate by having the
$(info ...) lines there is that the error is actually generated when the
(define ...) is parsed, NOT when the function is invoked.  In fact I can
remove the invocation and still get the errors:

        $ cat /tmp/g2.mk
        define show
        (define (show s)
          (display s)
          (newline))
        endef
        $(info define display)
        $(guile $(show))
        $(info after define)
        all:;
        
        $ ./make -f /tmp/g2.mk
        define display
        Backtrace:
        In ice-9/boot-9.scm:
         162: 5 [catch #t #<catch-closure 19a45c0> ...]
         170: 4 [#<procedure 19a7cd0 ()>]
        In unknown file:
           ?: 3 [catch-closure]
        In ice-9/eval.scm:
         389: 2 [eval # #]
         374: 1 [eval # #]
        In unknown file:
           ?: 0 [scm-error misc-error #f ...]
        
        ERROR: In procedure scm-error:
        ERROR: Unknown object: #<variable 19bf180 value: #<procedure 19a85a0 at ice-9/eval.scm:378:13 (a)>>
        after define
        make: `all' is up to date.

I can also (define ...) a function which is entirely numeric (for
example the Fibonacci calculator in the test suite) so there's no issue
with string return values or ports or anything like that:

        $ cat /tmp/g3.mk
        # Define the "fib" function in Guile
        define fib
        ;; A procedure for counting the n:th Fibonacci number
        ;; See SICP, p. 37
        (define (fib n)
          (cond ((= n 0) 0)
                ((= n 1) 1)
                (else (+ (fib (- n 1))
                         (fib (- n 2))))))
        endef
        $(guile $(fib))
        x:;
        
        $ ./make -f /tmp/g3.mk
        Backtrace:
        In ice-9/boot-9.scm:
         162: 5 [catch #t #<catch-closure add5c0> ...]
         170: 4 [#<procedure ae0cd0 ()>]
        In unknown file:
           ?: 3 [catch-closure]
        In ice-9/eval.scm:
         389: 2 [eval # #]
         374: 1 [eval # #]
        In unknown file:
           ?: 0 [scm-error misc-error #f ...]
        
        ERROR: In procedure scm-error:
        ERROR: Unknown object: #<variable afed00 value: #<procedure ae5630 at ice-9/eval.scm:378:13 (a)>>
        make: `x' is up to date.

As you can see I'm not actually calling these functions at all; simply
defining them is enough to cause the error.

Again these all work perfectly with Guile 1.8.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Re: Errors using Guile 2.0 vs. Guile 1.8

[Mark H Weaver]

Hi Paul,

Paul Smith <psmith@gnu.org> writes:
> To test my GNU make Guile integration I was using guile 1.8 which is
> what my distribution provided.  To test the newer Guile 2.x I downloaded
> the Guile 2.0.3 release and built it and installed in an alternate
> location (/opt/guile).  I compiled GNU make using that version, and all
> the tests ultimately work BUT whenever I use (define ...) from within
> GNU make I get these errors:
>
>         $ cat g1.mk
>         define show
>         (define (show s)
>           (display s)
>           (newline))
>         endef
>         $(info define display)
>         $(guile $(show))
>         $(info after define)
>         $(guile (show "HI"))
>         all:;
>         
>         $ make -f g1.mk
>         define display
>         Backtrace:
>         In ice-9/boot-9.scm:
>          162: 5 [catch #t #<catch-closure 1cb55c0> ...]
>          170: 4 [#<procedure 1cb8cd0 ()>]
>         In unknown file:
>            ?: 3 [catch-closure]
>         In ice-9/eval.scm:
>          389: 2 [eval # #]
>          374: 1 [eval # #]
>         In unknown file:
>            ?: 0 [scm-error misc-error #f ...]
>         
>         ERROR: In procedure scm-error:
>         ERROR: Unknown object: #<variable 1cd0180 value: #<procedure 1cb95a0 at ice-9/eval.scm:378:13 (a)>>
>         after define
>         HI
>         make: `all' is up to date.
>
> I don't know what this means, or how to proceed with debugging.  The
> same code works fine with Guile 1.8.

The relevant difference is that in Guile 1.8, (define foo ...) returns
#<unspecified>, but in Guile 2 it returns the 'variable' object for
'foo'.  Variables are first-class objects that can be accessed or
modified using various functions.  See "Variables" in the Guile manual
for more:

  http://www.gnu.org/software/guile/manual/html_node/Variables.html

My guess is that your code that converts the final results into strings
handles SCM_UNSPECIFIED properly, but fails to cope with variable
objects.

   Regards,
      Mark

Re: Errors using Guile 2.0 vs. Guile 1.8

[Mark H Weaver]

Replying to myself...

> The relevant difference is that in Guile 1.8, (define foo ...) returns
> #<unspecified>, but in Guile 2 it returns the 'variable' object for
> 'foo'.

I actually think that this qualifies as a bug in Guile, so please don't
depend on this behavior.  Ideally, (define foo ...) should always return
#<unspecified>, and I hope we can fix that in 2.0.4.

    Thanks,
      Mark

Re: Errors using Guile 2.0 vs. Guile 1.8

[Paul Smith]

On Sun, 2012-01-29 at 17:57 -0500, Mark H Weaver wrote:
> Replying to myself...
> 
> > The relevant difference is that in Guile 1.8, (define foo ...) returns
> > #<unspecified>, but in Guile 2 it returns the 'variable' object for
> > 'foo'.
> 
> I actually think that this qualifies as a bug in Guile, so please don't
> depend on this behavior.  Ideally, (define foo ...) should always return
> #<unspecified>, and I hope we can fix that in 2.0.4.

This definitely is the culprit.  If I add a #f to the end of my
definition, so the result is #f, then it works fine.  Ouch.  That is
going to be a bummer, and no two ways about it.

Was this change present in 2.0/2.0.1/2.0.2 as well?

Either I have to recommend everyone add #f for portability, or else I
have to modify my guile-to-make string conversion to map Guile variable
objects to empty strings, which could cause compatibility issues in the
future if we decide to do something "interesting" with those objects.


Not to mention that there is clearly some work needed, hopefully aided
by someone more familiar with embedded Guile than I, on handling errors
in the Guile interpreter.  If I can't understand the error resulting
from this behavior there's obviously a problem...

Is there any documentation for Guile embedders dealing with how to
gracefully manage errors in Guile code?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Re: Errors using Guile 2.0 vs. Guile 1.8

[Mark H Weaver]

Paul Smith <psmith@gnu.org> writes:

> On Sun, 2012-01-29 at 17:57 -0500, Mark H Weaver wrote:
>> Replying to myself...
>> 
>> > The relevant difference is that in Guile 1.8, (define foo ...) returns
>> > #<unspecified>, but in Guile 2 it returns the 'variable' object for
>> > 'foo'.
>> 
>> I actually think that this qualifies as a bug in Guile, so please don't
>> depend on this behavior.  Ideally, (define foo ...) should always return
>> #<unspecified>, and I hope we can fix that in 2.0.4.
>
> This definitely is the culprit.  If I add a #f to the end of my
> definition, so the result is #f, then it works fine.  Ouch.  That is
> going to be a bummer, and no two ways about it.
>
> Was this change present in 2.0/2.0.1/2.0.2 as well?

Yes.

> Either I have to recommend everyone add #f for portability, or else I
> have to modify my guile-to-make string conversion to map Guile variable
> objects to empty strings, which could cause compatibility issues in the
> future if we decide to do something "interesting" with those objects.

I think it would almost certainly be fine to map variable objects to "",
because I can't imagine why anyone would ever want to return a variable
object to 'make'.  I agree that it's not ideal, but I can't imagine it
ever being a problem in practice.

I'll respond to your other question (about error handling) later.

    Mark

Re: Errors using Guile 2.0 vs. Guile 1.8

[Paul Smith]

On Sun, 2012-01-29 at 20:16 -0500, Mark H Weaver wrote:
> I think it would almost certainly be fine to map variable objects to
> "", because I can't imagine why anyone would ever want to return a
> variable object to 'make'.

OK, I made this change.  Thanks!

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Re: Errors using Guile 2.0 vs. Guile 1.8

[Andy Wingo]

On Sun 29 Jan 2012 23:57, Mark H Weaver <mhw@netris.org> writes:

> Replying to myself...
>
>> The relevant difference is that in Guile 1.8, (define foo ...) returns
>> #<unspecified>, but in Guile 2 it returns the 'variable' object for
>> 'foo'.
>
> I actually think that this qualifies as a bug in Guile, so please don't
> depend on this behavior.  Ideally, (define foo ...) should always return
> #<unspecified>, and I hope we can fix that in 2.0.4.

Thanks for tracking this one down, Mark.

Andy
-- 
http://wingolog.org/