On Sun, Feb 13, 2011 at 4:27 PM, Patrick McCarty wrote:
>
> I'm trying to compile LilyPond against Guile git (commit 482d311b),
> and I'm running into a compile failure that I'm having trouble
> understanding. See the attached log.
So, this seems to be caused by LilyPond using `hash-set!' on cer
Hello,
I'm trying to compile LilyPond against Guile git (commit 482d311b),
and I'm running into a compile failure that I'm having trouble
understanding. See the attached log.
I didn't run into this problem compiling against Guile 1.9.14.
Can anyone help decipher this?
Thanks,
Patrick
;;; compi
The attached patch does it. I almost hate to commit it because it's
such a hack, but this is from my last Guile session:
scheme@(guile-user)> 'foo
$2 = foo
scheme@(guile-user)> 'foo ; hi there!
$3 = foo
scheme@(guile-user)> ; why, hello!
scheme@(guile-user)> ,q
Noah
On Sun, Feb 13, 2011 at 2:19
Andy Wingo writes:
> On Sun 13 Feb 2011 10:58, Neil Jerram writes:
>
>> No. But that might be because the libgc on that machine - Debian
>> 1:7.1-3 - is too old. What is the latest recommendation for libgc
>> version? README says "at least version 7.0", but I suspect that's out
>> of date.
>
Hey all,
I bumped the objcode version for what I think is the last time, at least
in an incompatible way. If you have installed any .go files, you will
need to remove them and reinstall.
Happy hacking,
Andy
--
http://wingolog.org/
On Sun 13 Feb 2011 21:34, Noah Lavine writes:
> Here it is.
>
> On Sun, Feb 13, 2011 at 3:10 PM, Noah Lavine wrote:
>>> Yes, I think this is the thing to do.
>>>
>>> Can you rework your patch, Noah?
>>
>> Will do.
>>
Thanks, applied.
Andy
--
http://wingolog.org/
Here it is.
On Sun, Feb 13, 2011 at 3:10 PM, Noah Lavine wrote:
>> Yes, I think this is the thing to do.
>>
>> Can you rework your patch, Noah?
>
> Will do.
>
0001-Set-sockaddr_in.sin_len-field-when-it-exists.patch
Description: Binary data
On Sun 13 Feb 2011 10:58, Neil Jerram writes:
> No. But that might be because the libgc on that machine - Debian
> 1:7.1-3 - is too old. What is the latest recommendation for libgc
> version? README says "at least version 7.0", but I suspect that's out
> of date.
I think we are a little incoh
> Yes, I think this is the thing to do.
>
> Can you rework your patch, Noah?
Will do.
On Sun 13 Feb 2011 15:05, Mark H Weaver writes:
>> Could someone please either (A) tell me briefly what needs to be done to
>> import trunc from gnulib into guile properly, or better yet (B) do it
>
> On second thought, there's no rush on this. I'd still like to know at
> some point, but it can
On Sun 13 Feb 2011 19:34, Ken Raeburn writes:
>> The code I was fixing is creating a sockaddr_in, so in order to
>> use the sa_len field I would have had to cast a sockaddr_in to a
>> sockaddr, and it just seemed cleaner to use the sin_len field. It's no
>> big deal either way, though - this woul
On Sun 13 Feb 2011 03:22, Noah Lavine writes:
> The attached patch fixes the problem for me, and I believe zeroing
> some data structures before they're used won't hurt things for anyone
> else.
Applied, thanks for debugging this.
In the future, please give the function names in the commit logs
Hi Noah,
I think it makes sense to have a reader that actually returns comments.
That, to me, is the general solution: the REPL reader just treats a
comment as whitespace.
On Sun 13 Feb 2011 16:22, Noah Lavine writes:
> - The quicker way: if the language in use is scheme, change the
> next-char
On Feb 13, 2011, at 08:55, Noah Lavine wrote:
> OS X, which I use, has a somewhat weird field-naming situation. The
> generic sockaddr structure has sa_len, but sockaddr_in has a sin_len
> field.
No, that's normal for a traditional C/UNIX API. Each structure's field names
use a prefix that's an
Hello all,
I was thinking about how this might be solved. I can see two ways of doing it:
- The nicer way: add a new read function (or a keyword argument to the
current read function) that can tell it to stop without returning
anything if it hits a newline and there's no more input ready on its
p
Okay, I see what I need to do. I'll change the API as you suggest, and make an
internal wrapper function for SCM_WTA_DISPATCH_2 that unpacks the values object
returned from GOOPS and returns the values via the SCM* output parameters. I
should be able to do this by Monday.
Thanks,
Hi,
Andy Wingo writes:
> Are these lines in load.c right?
>
> /* The file has no encoding declared. We'll presume Latin-1. */
> scm_i_set_port_encoding_x (port, NULL);
>
> I thought we were defaulting to UTF-8 now.
Yes, ‘compile-file’ defaults to UTF-8, so the above line should be
> Could someone please either (A) tell me briefly what needs to be done to
> import trunc from gnulib into guile properly, or better yet (B) do it
On second thought, there's no rush on this. I'd still like to know at
some point, but it can wait until after 2.0.
Best,
Mark
>> I suspect you'd do fine if you ditched the test for sockaddr.sin_len and
>> tested either sockaddr_in.sin_len or sockaddr.sa_len. (And I'd expect an OS
>> to be consistent as to whether the _len field exists for each of the various
>> socket address structures.)
Oh, and as for why I did thi
Hello,
On Sun, Feb 13, 2011 at 12:42 AM, Ken Raeburn wrote:
> What platforms have sin_len in the generic sockaddr structure? The one I've
> always seen is sa_len, and that's consistent with sa_family in terms of field
> name prefixes.
>
> sockaddr -> sa_
> sockaddr_in -> sin_
> so
Andy Wingo writes:
>>> Neil Jerram writes:
>>>
My nightly build of master, on a relatively slow old machine, is
hanging, on most nights, in `make check'.
>>
>> The hang seems to be caused by one thread (A) running (gc) at the same
>> time as another thread (B) is doing GC_malloc_atomic
Hi Ludo,
Are these lines in load.c right?
/* The file has no encoding declared. We'll presume Latin-1. */
scm_i_set_port_encoding_x (port, NULL);
I thought we were defaulting to UTF-8 now.
Cheers,
Andy
--
http://wingolog.org/
Hello all,
Could someone please either (A) tell me briefly what needs to be done to
import trunc from gnulib into guile properly, or better yet (B) do it
for me? I'd really appreciate it. It will make my new implementations
of scm_truncate and scm_truncate_divide much cleaner, and I don't think
23 matches
Mail list logo
