I guess it is the socklen_t error, I reported earlier...
Best regards
Michael
On Mar 29, 2006, at 2:34 AM, Kevin Ryde wrote:
Jay Cotton <[EMAIL PROTECTED]> writes:
In file included from /usr/include/netinet/in.h:78,
from /usr/include/netdb.h:86,
from posix.c
Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> There doesn't seem to be any room in that struct, but if it's always
>> created by scm_make_port_type then perhaps adding new fields to the
>> end would keep compatibility.
>
> Yes, that is good enough.
I might do something for stat and readdir first
Marius Vollmer <[EMAIL PROTECTED]> writes:
>
> It should clearly be possible to use equal? with all kinds of arrays.
> If this isn't the case, we would need to fix.
Eg, picking out a diagonal with a shared array:
(equal? (make-shared-array #2((a b c) (d e f) (g h i))
Jay Cotton <[EMAIL PROTECTED]> writes:
>
> In file included from /usr/include/netinet/in.h:78,
> from /usr/include/netdb.h:86,
> from posix.c:122:
> /usr/include/sys/socket.h:99: error: two or more data types in
> declaration specifiers
What does that offending sy
Hello all,
Apologies if this is the wrong forum for addressing this problem. I'm
not an experienced guile user. Last week I tried upgrading to 1.8.0,
but ran into the following error during the make process. So I
thought I'd send a report.
I'm using an iBook G3/800 running Mac OS 10.4.5 (
Howdy Guilers,
(sorry if you've seen this already, the mail server seems to be
refusing to talk to me)
The current (and previous) Guile reference manual mentions Anthony
Greens libffi in the "contrib archive". See the last paragraph at
http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Lo
ind enough to loan me an account on a 64-bit
machine:
[EMAIL PROTECTED]:~/guile-core-1.8-20060328$ uname -a
Linux we 2.6.8-11-amd64-k8-smp #1 SMP Wed Jun 1 00:01:27 CEST 2005 x86_64
GNU/Linux
But using the latest 1.8 snapshot, guile-core-1.8-20060328.tar.gz, I
can't reproduce the proble
Hi,
Marius Vollmer <[EMAIL PROTECTED]> writes:
> It wasn't really planned that way. We did it differently in 1.6 vs
> HEAD, where we applied patches to both branches simultaneously by
> hand, and we might switch to that mode once HEAD has suffifiently
> diverted from the 1.8 branch.
Hmm, sorry
