Re: Strange error from %search-load-path via include-from-path when parameter is not a literal string

[Ian Hulin]

Hi Andy and Mark,
Many thanks for the info.

Also thanks for the catch re using modules and portability, I'll have
to address the issue of the tidying up what definitions need to be
loaded into the main (lily) module from other files, and which of
those need to be modules, which was work I had been hoping to defer :-{.

Cheers,

Ian Hulin

On 17/10/11 22:36, Andy Wingo wrote:
> Hi,
> 
> On Mon 17 Oct 2011 20:20, Ian Hulin  writes:
> 
>> I'm trying to write a V2/V1 compatible function like the
>> following:
>> 
>> (define (ly:include the-file) (if (string>? (version) "1.9.10") 
>> (include-from-path the-file) (load-from-path the-file)))
>> 
>> I get ERROR in procedure %search-load-path: Wrong type to apply
>> in position 1 (expecting string): the-file.
>> 
>> Bug or user error?
> 
> User error, unfortunately.  `include' is a macro that expects a
> literal string, not a procedure that expects an expression that
> evaluates to a string.  For this to work, ly:include would also
> need to be a macro.
> 
> How about:
> 
> (cond-expand (guile-2 (define-syntax ly:include (syntax-rules () 
> ((_ the-file) (include-from-path the-file) (else (define
> (ly:include the-file) (load-from-path the-file
> 
> Assuming of course that you really need it to be ly:include.  The 
> portable (1.8/2.0) option is to use modules instead of
> load-from-path.
> 
> Regards,
> 
> Andy

Re: Hexadecimal representation of a negative number

[Brian Mokrzycki]

Well I figured this out that it was likely caused by compiling guile with 
llvm-gcc (which is depreciated).  Please see more details on this issue in the 
CGEN mailing list.

Old Nabble - Sourceware - cgen list - 64-bit instruction mask emitting as 
signed hex value



On Oct 4, 2011, at 9:48 PM, Brian Mokrzycki wrote:

> Hi all,
> 
>   I'm running into a problem between Guile 1.6.4 and Guile 1.8.7.  
> Basically I'm manipulating bit masks in Guile and need to generate a 
> hexadecimal string representation of an integer.  Unfortutely this worked 
> just fine in Guile 1.6.4 but not so well in Guile 1.8.7.
> 
> The offending statement:
> 
> guile> (number->string #x 16)
> 
> Resolves to
> 
> "-1" in Guile 1.8.7
> "" in Guile 1.6.4
> 
> It appears that Guile is treating the number as a signed value in 1.8 and an 
> unsigned value in 1.6.  I'm really looking for the 1.6 interpretation. Is 
> this a bug?  If not, how to get this to come out as an unsigned value?
> 
> -Brian
> 
> 
>