Greets :)
On Wed 27 Feb 2013 23:11, Mark H Weaver writes:
> Also, I've since realized that the new arity limit is 127, not 255 as my
> previous patch had assumed.
Good catch.
> Here's a new patch. What do you think?
Looks great, please apply. Thank you!
Andy
--
http://wingolog.org/
On Thu 28 Feb 2013 04:24, Mark H Weaver writes:
> Instead of having 'input_cd' and 'output_cd' point directly to the
> platform's iconv_t structures, let's have them point to our own internal
> structure(s) that hold the needed transcoder state. This could include
> things like the state for int
I wrote:
> This seems questionable to me. It may currently be the case that N32
> and O32 are more common, but that is unlikely to remain the case for
> much longer.
>
> Is there any way to specify the N64 ABI for MIPS?
Please disregard this message. I should have looked at the patch and
not jus
Hi Mark,
Mark H Weaver skribis:
> "Ludovic Courtès" writes:
>> commit cc2948aa3189b7bd29c23e7a93ccb1217a1b4eff
>> Author: Ludovic Courtès
>> Date: Wed Feb 27 20:07:12 2013 +0100
>>
>> Recognize mips64* as having 32-bit pointers by default.
>>
>> * module/system/base/target.scm (
Andy Wingo skribis:
> On Thu 28 Feb 2013 04:24, Mark H Weaver writes:
>
>> Instead of having 'input_cd' and 'output_cd' point directly to the
>> platform's iconv_t structures, let's have them point to our own internal
>> structure(s) that hold the needed transcoder state. This could include
>>
On Thu 28 Feb 2013 12:04, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribis:
>
>> On Thu 28 Feb 2013 04:24, Mark H Weaver writes:
>>
>>> Instead of having 'input_cd' and 'output_cd' point directly to the
>>> platform's iconv_t structures, let's have them point to our own internal
>>> s
On Feb 22, 2013, at 01:22, Noah Lavine wrote:
> I agree about the speed issue, but I hope it will get better soon. The RTL VM
> will fix some of it, and native compilation will fix more.
That's on Scheme, but there are also many optimization issues related to array
operations. Temporaries, ord
Here's an article from a reputable source that backs up my claim that
the lazy-initialization pattern that we use in a few places is not
thread-safe:
http://www.ibm.com/developerworks/java/library/j-dcl/index.html
Here are the thread-unsafe lazy initializations that I'm aware of:
./posix.c:137
If guile introduces full-fledged support of arrays for numeric
computing, and for communicating with external libraries, such as the
currently-moribund Guile-numerics interface to GNU Scientific Library
(GSL), libsndfile, FFTW, and LAPACK
http://www.nongnu.org/guile-num/
please do not for
Here's my proposed patch to fix these problems.
What do you think?
Mark
>From dadcb1512569c1be039fc75f0a2967e370939e42 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Thu, 28 Feb 2013 17:56:58 -0500
Subject: [PATCH] Fix thread-unsafe lazy initializations.
* libguile/debug.c (scm_local_e
Hello,
On Thu, Feb 28, 2013 at 2:10 PM, Daniel Llorens
wrote:
>
> On Feb 22, 2013, at 01:22, Noah Lavine wrote:
>
> > I agree about the speed issue, but I hope it will get better soon. The
> RTL VM will fix some of it, and native compilation will fix more.
>
> That's on Scheme, but there are als
After reading through my email, I realize that I left out the most
important part - a reason *why* functions shouldn't map over arrays.
My reason is that this makes function application a more complicated
process. Right now, functions are very simple things in Scheme. If we add
automatic mapping b
> From: Mike Gran
> What would you think about applying the following patch?
>
> It is a standalone test that, in effect, checks to see if
> BDW-GC is running marking in its own non-Guile thread. If
> BDW does have parallel marking enabled, this test will SEGV.
> If it doesn't have parallel mar
13 matches
Mail list logo
