On 25 May 2012, at 17:31, Ludovic Courtès wrote:
> Ken Raeburn skribis:
>
>> * Don't use addresses of code labels with LLVM, even if the compiler
>> supports them. At least with the version of LLVM GCC on my Mac ("gcc
>> version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
>> 2336.1.00)")
On 26 May 2012, at 14:44, Ludovic Courtès wrote:
> Hans Aberg skribis:
>
>> On 25 May 2012, at 17:31, Ludovic Courtès wrote:
>>
>>> Ken Raeburn skribis:
>>>
>>>> * Don't use addresses of code labels with LLVM, even if the compiler
>&
On 9 Jun 2012, at 14:32, David Kastrup wrote:
> Scheme/Guile vectors are fixed size. Now I have a situation where I
> have a basic type lattice with records stored in vectors, and this type
> lattice may be extended dynamically (which typically happens at the
> start of a whole file, for potentia
On 5 Nov 2012, at 19:11, Ludovic Courtès wrote:
> I think time has come for 2.0.7. I suggest scheduling it for Week 48,
> WDYT?
FYI, this is the last week of November - a lot of countries do not use this
week numbering system.
https://en.wikipedia.org/wiki/Seven-day_week#Week_numbering
On 5 Nov 2012, at 22:02, Ludovic Courtès wrote:
> Hi Hans,
Hi Ludo,
> Hans Aberg skribis:
>
>> On 5 Nov 2012, at 19:11, Ludovic Courtès wrote:
>>
>>> I think time has come for 2.0.7. I suggest scheduling it for Week 48,
>>> WDYT?
>>
>>
On 6 Nov 2012, at 19:28, Ludovic Courtès wrote:
> Hi,
>
> Hans Aberg skribis:
>
>> On 5 Nov 2012, at 22:02, Ludovic Courtès wrote:
>>
>>> Hi Hans,
>>
>> Hi Ludo,
>>
>>> Hans Aberg skribis:
>>>
>>>> On 5 Nov 2
On 25 Jan 2011, at 00:21, Mike Gran wrote:
2. The #f <=> "ISO-8859-1" equivalence for ‘port-encoding’ and
‘set-port-encoding!’. Likewise, commit
d9544bf012b6e343c80b76bd5761b1583cc106a3 makes ‘port-encoding’
always return a string and pt->encoding always be non-NULL.
Is the cost
On 29 Jan 2011, at 21:53, Ludovic Courtès wrote:
I think there should be a mailing list for people who implement
Schemes, to sort of coordinate our non-standard features. ...
I think comp.lang.scheme is already a good place for this. You
quickly
get feedback and many implementors seem to p
On 1 Feb 2011, at 14:57, Mark H Weaver wrote:
I want to add arbitrary-precision floats to Guile.
I'd use the mpf_t type from GNU MP.
There would be a fluid whose value would determine the minimum
precision
to use for inexact operators. A value of #f (the default) would mean
that normal floa
On 1 Feb 2011, at 18:03, Mark H Weaver wrote:
There would be a fluid whose value would determine the minimum
precision
to use for inexact operators. A value of #f (the default) would
mean
that normal floats would be used unless one of the operands was a
bigfloat.
Only checking takes a lot
On 1 Feb 2011, at 21:37, Andy Wingo wrote:
In (* inum flonum bigflonum), with what precision would the first
multiplication be performed? Note that currently the compiler
compiles
it as (* (* inum flonum) bigflownum).
An idea that comes to my mind is to set a minimum float precision,
whi
On 22 Feb 2011, at 09:11, Andy Wingo wrote:
>> The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
>> can't get a logical result.
>
> I believe this indicates that you compiled this extension against
> headers from 1.8 or earlier. Not sure how you managed that :)
I noticed tha
On 22 Feb 2011, at 12:44, nalaginrut wrote:
The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
can't get a logical result.
>>>
>>> I believe this indicates that you compiled this extension against
>>> headers from 1.8 or earlier. Not sure how you managed that :)
>>
On 25 Feb 2011, at 12:07, Andy Wingo wrote:
>> * Developers should be clearly warned that -I/usr/local/include
>> needs to be after all other -I options, due to guile
>> header naming conflicts.
>
> This is incorrect. Guile 2.0 (and later) does not add
> -I/usr/local/include to the CFLAGS in a
On 25 Feb 2011, at 13:42, Andy Wingo wrote:
>> $ guile-config compile
>> -D_THREAD_SAFE -I/usr/local/include/guile/2.0 -I/usr/local/include
>
> The -I/usr/local/include is added for some other library that Guile
> depends on -- GMP or libgc or something else.
>
> For example on my system I h
On 27 Feb 2011, at 22:37, Andy Wingo wrote:
> Andreas has been struggling with a nonstandard behavior of Guile's
> recently, and we should discuss it more directly.
>
> The issue is in expressions like this:
>
> (define-syntax define-accessor
>(syntax-rules ()
> ((_ getter setter init)
On 2 Mar 2011, at 21:44, Ludovic Courtès wrote:
>> scheme@(guile-user)> (define libm (dynamic-link "/usr/lib/libm.dylib"))
>> ERROR: In procedure dynamic-link: file: "/usr/lib/libm.dylib",
>> message: "file not found"
>
> You should omit the extension, which will be automatically inferred by
> Gu
On 3 Mar 2011, at 00:03, Ludovic Courtès wrote:
scheme@(guile-user)> (define libm (dynamic-link "/usr/lib/libm.dylib"))
ERROR: In procedure dynamic-link: file: "/usr/lib/libm.dylib",
message: "file not found"
>>>
>>> You should omit the extension, which will be automatically inferr
On 3 Mar 2011, at 00:14, Andreas Rottmann wrote:
scheme@(guile-user)> (define libm (dynamic-link "/usr/lib/libm.dylib"))
ERROR: In procedure dynamic-link: file: "/usr/lib/libm.dylib",
message: "file not found"
>>>
>>> You should omit the extension, which will be automatically infer
On 3 Mar 2011, at 11:40, Ludovic Courtès wrote:
>>> The crux is that on older MacOS X versions ‘.dylib’ are shared
>>> libraries (not dlopenable), whereas ‘.so’ are “bundles”
>>> (dlopenable). That’s why lt_dlopenext (which is what ‘dynamic-link’
>>> uses) doesn’t try to open ‘.dylib’ files.
>>
>
On 3 Mar 2011, at 14:11, Ludovic Courtès wrote:
> The crux is that on older MacOS X versions ‘.dylib’ are shared
> libraries (not dlopenable), whereas ‘.so’ are “bundles”
> (dlopenable). That’s why lt_dlopenext (which is what
> ‘dynamic-link’ uses) doesn’t try to open ‘.dylib’ fil
On 8 Mar 2011, at 23:37, Andy Wingo wrote:
> Everyone appears to want gensymmed names. OK! Let's consider this to
> be a bug, and that at some point in the future, Guile will start
> gensymming this names.
I want a syntax that allows one to explicitly choose which macro-bound
variables to expo
On 9 Mar 2011, at 21:14, Andy Wingo wrote:
>> I want a syntax that allows one to explicitly choose which macro-bound
>> variables to export, but otherwise, they should never be visible outside
>> the macro (i.e., be uninterned). When exported, they will just have the
>> name indicated.
>
> You ha
What is the practical difference between the two ways of doing the same thing
(letrec or an environment). Is letrec more efficient in the implementation of
Guile?
Hans
(letrec (
(even? (lambda (n)
(if (zero? n) #t (odd? (- n 1)
(odd? (lambda (n)
(if (zero? n) #f (even? (- n 1))
What method is Guile using to avoid substitution variable clashes (de Bruijn
numbers, combinators, etc.)?
Hans
On 13 Apr 2011, at 16:19, Andy Wingo wrote:
>> What method is Guile using to avoid substitution variable clashes (de
>> Bruijn numbers, combinators, etc.)?
>
> Each lexical variable is given a fresh name (a gensym) when it is
> introduced. The expander keeps an environment as to what name maps t
On 13 Apr 2011, at 17:27, Andy Wingo wrote:
What method is Guile using to avoid substitution variable clashes (de
Bruijn numbers, combinators, etc.)?
>>>
>>> Each lexical variable is given a fresh name (a gensym) when it is
>>> introduced. The expander keeps an environment as to what n
On 13 Apr 2011, at 18:25, Noah Lavine wrote:
> I think that mechanism is all that Guile uses at present. However, it
> should be general enough to resolve all situations where variables of
> the same name refer to different entities, assuming you set up the
> environments correctly.
>
> Are you p
On 13 Apr 2011, at 18:25, Andy Wingo wrote:
>>> Sorry, I don't know what you mean. References?
>>
>> There is an article here:
>> http://en.wikipedia.org/wiki/Variable_binding_operator
>
> I still don't understand. What are you trying to do?
The beta rule is in denotational semantics somethin
On 14 Apr 2011, at 03:08, Noah Lavine wrote:
>> The beta rule is in denotational semantics something like
>> ((lambda x . E_1) E_2) => [E_2/x]E_1, E_2 free for x in in E_1
>> where [E_2/x]E_1 means substituting all free occurrences of x with E_2.
>>
>> In addition, one has the alpha rule
>> (la
On 23 May 2011, at 22:14, Mark H Weaver wrote:
> I really like the basic gist behind Noah's proposal, to allow programs
> to optionally represent paths (roughly) as sequences of path components.
> I haven't worked out all the details, and I'm glad to leave that job to
> someone else, but I do have
I try to understand how Guile transforms 'letrec' (returning to the topic of an
earlier post on this list). Define
(define (a) (letrec (
(even? (lambda (n)
(if (zero? n) #t (odd? (- n 1)
(odd? (lambda (n)
(if (zero? n) #f (even? (- n 1))
(even? 1000)))
(define (b) ((lambda
Just FYI, I found a source saying that R5RS defines (though I could not find it
there) 'letrec' via this transformation (which also answers my question):
(letrec ([x1 e1] ... [xn en]) body)
~>
(let ([x1 undefined] ... [xn undefined])
(let ([t1 e1] ... [tn en])
(set! x1 t1)
..
On 10 Nov 2011, at 00:11, Andy Wingo wrote:
> On Thu 04 Aug 2011 10:56, Hans Aberg writes:
>
>> I try to understand how Guile transforms 'letrec' (returning to the
>> topic of an earlier post on this list).
>
> `letrec' is translated to various things,
On 15 Dec 2011, at 11:21, Andy Wingo wrote:
> The "delayed evaluation" thread is a bit long and confusing, so I would
> like to try to summarize it.
>
> Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
> Lilypond code. The former uses a reader macro, #{#}. The latter uses
On 15 Dec 2011, at 18:24, David Kastrup wrote:
>>> The "delayed evaluation" thread is a bit long and confusing, so I would
>>> like to try to summarize it.
>>>
>>> Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
>>> Lilypond code. The former uses a reader macro, #{#}. Th
On 16 Dec 2011, at 11:33, Mark H Weaver wrote:
> Here's what I currently see:
>
> scheme@(guile-user)> (local-eval #'t (primitive-eval '(let ((t 42)) (or #f
> (the-environment)
> ERROR: In procedure memoize-variable-access!:
> ERROR: Unbound variable: t
>
> This is the correct behavior, no?
On 16 Dec 2011, at 13:43, David Kastrup wrote:
>>> Here's what I currently see:
>>>
>>> scheme@(guile-user)> (local-eval #'t (primitive-eval '(let ((t 42))
>>> (or #f (the-environment)
>>> ERROR: In procedure memoize-variable-access!:
>>> ERROR: Unbound variable: t
>>>
>>> This is the correc
On 16 Dec 2011, at 16:27, Mark H Weaver wrote:
> As an interesting case, suppose that you define the following macro in
> module A:
>
> (define foo 'module-a)
> (define-syntax alt-environment
> (syntax-rules ()
>((_) (the-environment
>
> and then evaluate the following within module B:
On 30 Jan 2012, at 22:13, Ludovic Courtès wrote:
> ... and I forgot to bump the SONAME. :-/
>
> I guess I have to push a 2.0.5 tarball now? Thoughts?
Are you sure it was there in earlier versions? Though OS X uses different
objective file format, I could not find it in the .dylib.
Hans
On 24 Feb 2012, at 20:52, Mark H Weaver wrote:
> I posted this link to IRC, but for the benefit of others, here's a paper
> that I highly recommend for anyone interested in a better way to handle
> sychronization and concurrency:
>
> http://research.microsoft.com/en-us/um/people/simonpj/papers/st
41 matches
Mail list logo
