On Tue 27 Jan 2009 06:52, Mike Gran writes:
> I said
>
>> (Though, such a scheme would force scm_take_locale_string to become
>> scm_take_iso88591_string.)
>
> which is incorrect. Under the proposed scheme, scm_take_locale_string
> would only be able to use that storage directly if it happened
Hi Julian,
On Mon 26 Jan 2009 01:27, Julian Graham writes:
> Maybe some more advanced Schemers than I can shed some light on the
> following:
Well, that's not me, but I'll join you in fumbling for a solution :-)
> The levels system is simply a numerical way of encapsulating this
> information,
Hi,
I pushed the following patch to master. Is it OK to push to 1.8 as well?
That way I could drop some modules from guile-lib, and make guile-lib
depend on guile >= 1.8.x.
(Perhaps we can set up a list for patches that get pushed to Guile ?)
Andy
commit 4f7a0504aac215832e99290e31c9944795c5d206
Hi!
Mike Gran writes:
> Gnulib works for me. Bruno is the maintainer of those funcs, so I'm
> sure they work great.
Good!
> So really the first questions to answer are the encoding question and
> whether the R6RS string API is the goal.
SRFI-1[34] (i.e., status quo in terms of supported AP
Hello!
Andy Wingo writes:
> So from 7.2 of R6RS itself:
>
> An implementation may distinguish instances/visits of a library for
> different phases or to use an instance/visit at any phase as an
> instance/visit at any other phase.
>
> Which is to say, "we allow single instantiation"
Hello,
Andy Wingo writes:
> I pushed the following patch to master. Is it OK to push to 1.8 as well?
> That way I could drop some modules from guile-lib, and make guile-lib
> depend on guile >= 1.8.x.
Looks OK to me. (Too bad this module isn't documented BTW.) Do you
have example use cases?
On 01/27/09 10:07:16, Andy Wingo wrote:
> Hi John,
>
> I was going over the licenses in Guile-lib, and realized we didn't
> really have a declamation of copyright or license to your goops-unit
> code.
>
> Your original message was here:
> http://article.gmane.org/gmane.lisp.guile.user/1728
>
l...@gnu.org (Ludovic Courtès) writes:
>> +(define *value-help-handlers* '())
>
> The convention within Guile is rather `%'-prefixed names for globals, as
> in `%load-path'.
I'm not sure about that. I interpret `%' as something to do with the
"system" (e.g. when I was proposing %get-stack-depth)
Andy Wingo writes:
> Hi,
>
> I pushed the following patch to master. Is it OK to push to 1.8 as well?
> That way I could drop some modules from guile-lib, and make guile-lib
> depend on guile >= 1.8.x.
I have no objection to that.
> (Perhaps we can set up a list for patches that get pushed to G
Hi Neil,
Neil Jerram writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> The convention within Guile is rather `%'-prefixed names for globals, as
>> in `%load-path'.
>
> I'm not sure about that. I interpret `%' as something to do with the
> "system" (e.g. when I was proposing %get-stack-depth
Hi all,
Minor nit about the "libguile/inline.h" header:
I typically compile with g++ ... -Wundef -Werror, which catches uses of
undefined preprocessor tokens:
/usr/local/include/libguile/inline.h:57:31: "__APPLE_CC__" is not defined
In file included from /usr/local/include/libguile.h:114,
/us
Neil Jerram writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>>> +(define *value-help-handlers* '())
>>
>> The convention within Guile is rather `%'-prefixed names for globals, as
>> in `%load-path'.
>
> I'm not sure about that. I interpret `%' as something to do with the
> "system" (e.g. when
12 matches
Mail list logo
