Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> If you're not supposed to use it then any warnings it provokes when
> you do aren't a big deal :).
Right. ;-)
> Now that srfi-1 has a lot more C code it's probably worth using for
> performance.
Yes, that's the point I was trying to make: this modu
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Yes, I'm talking about the module user too, the module user loses some
> core bindings.
>
>> This is exactly the behavior users may expect.
>
> If you don't know about the clashes/replacements then you're likely to
> be unpleasantly surprised to see co
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> [EMAIL PROTECTED] #:replace @var{list}
>> ...
>> +One example of this is @code{(srfi srfi-19)} which exports
>> [EMAIL PROTECTED]
>
> This isn't a great example. See if you can make up something, to
> avoid
Hi,
Recently, Neil and I agreed that the reader setting should be thought of
as per-file instead of per-module. Happily, the second patch I sent
implements per-file readers (which may be set via `set-current-reader')
while maintaining the per-module reader mechanism (via `(define-module
(m) :read
Hallo,
I tried the old version with --without-threads and it worked.
How can I try the new version? the guile-core-unstable.tar.gz
is still the old version...
Best regards
Michael
On Oct 23, 2005, at 23:15 Uhr, Marius Vollmer wrote:
Michael Tuexen <[EMAIL PROTECTED]> writes:
I guess the mos
Michael Tuexen <[EMAIL PROTECTED]> writes:
> eval.c:2658: error: `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP'
> undeclared here (not in a function)
>
> Any idea, how to fix that? I'm trying to compile it on Mac OS X 10.3.9.
Hmm. PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP seems not to be portable
enough
Michael Tuexen <[EMAIL PROTECTED]> writes:
> I tried the old version with --without-threads and it worked.
Ok!
> How can I try the new version? the guile-core-unstable.tar.gz
> is still the old version...
You can wait for the snapshots to catch up (should happen in a day or
so), or you can chec
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Actually, I think that what we disagree on is the rationale behind
> `#:replace'.
No, I'm not bothered about the rationale, I just think "what-if"'s
about builtin stuff is confusing. Create a standalone example and
it's fine.
_
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Greg Troxel <[EMAIL PROTECTED]> writes:
>
> Straight "pass through" to libc sounds good to me.
>
> >and make the implementation set TZ before calling
> >strftime (perhaps unless an implementation which guarantees to read
> >tm_zone is detected
