Hi Julian,
Julian Graham writes:
>> Do you think you’ll be able to work on it by Tuesday? :-)
>
> I was planning to devote some time to it this weekend. (Is it okay if
> the changes go up before the release?)
Great. It’s even preferable if the changes are made before the release.
:-)
Thanks
Andy Wingo writes:
> On Fri 11 Feb 2011 17:01, l...@gnu.org (Ludovic Courtès) writes:
>
>>> I guess that's what we need to do with the libtools that are "out
>>> there".
>>
>> The libtool invocations you mean?
>
> No, the libltdls. I was thinking about getting some other API into
> ltdl, instead
On Fri 11 Feb 2011 19:53, Jan Nieuwenhuizen writes:
> I'm attaching the individual files; this works with 1.8.7:
Right, I saw your files, and they do work with 1.8.7; I was just trying
to figure out what the difference is. I suspect it's merge-generics
related.
>> I don't understand what's goi
On Mon 07 Feb 2011 07:28, Noah Lavine writes:
> I think there's a bug in Guile's Posix networking capabilities. I
> first noticed it a few days ago when I couldn't get the example web
> server to work on my system (Mac OS X 10.6). I was getting an error
> from the bind command saying "can't assig
On Thu 10 Feb 2011 18:38, Andy Wingo writes:
> All if this was merged in. The files he attached were as follows:
To be clear, I meant "All of this was merged in".
Thanks to Brian for all his work!
Andy
--
http://wingolog.org/
On Thu 10 Feb 2011 22:01, Mark H Weaver writes:
> Here are some miscellaneous fixes. The only non-trivial patch here is
> the last one, which includes (among other things) another rework of the
> testing framework for number-theoretic division operators.
Applied, thanks.
Andy
--
http://wingol
On Fri 11 Feb 2011 00:42, Mark H Weaver writes:
> Here are three more patches. The first adds fast implementations of the
> remaining number-theoretic division operators as described in Taylor
> Campbell's proposal: floor/, ceiling/, truncate/, round/, as well as the
> single-valued variants. T
On Fri 11 Feb 2011 22:15, "Jose A. Ortega Ruiz" writes:
> scheme@(guile-user)> (define a 3) ;; foo
> <- cursor stays here; no prompt
>
> is that intended? i'm hoping it is not, because it confuses geiser, who
> is waiting for a new prompt to mark the end of the transaction.
It would be n
On Sat, Feb 12 2011, Andy Wingo wrote:
> On Fri 11 Feb 2011 22:15, "Jose A. Ortega Ruiz" writes:
>
>> scheme@(guile-user)> (define a 3) ;; foo
>> <- cursor stays here; no prompt
>>
>> is that intended? i'm hoping it is not, because it confuses geiser, who
>> is waiting for a new prompt to
On Sat 12 Feb 2011 14:21, "Jose A. Ortega Ruiz" writes:
> I'm not sure i understand this reasoning, because when there are two (or
> more) complete sexps in a line they're accepted, and a new prompt
> appears;
Of course.
1. Guile: No input available, print prompt:
guile>
2. User: one
Hi list,
Mark Weaver writes in to say that his mail server crashed. The heavens
conspire against us! I'm mailing the list and bccing Mark at his
webmail (in case he is concerned about it leaking into the archives).
So this mail is really to Mark.
***
Very sorry t
Hello,
> Does guile --listen work? It appears to use a slightly different way to
> set up the sockaddr.
Oddly enough, it worked the first time I tried it (at least enough to
get to a REPL - I didn't try to netcat over to it), but failed the
second and third times.
> Also, can you file a bug in
Hello,
> It would be interesting to see the output of a strace-like tool on both
> the working Python program and the equivalent failing Guile program.
> Apparently (according to the Interwebs), on OS X this tool is called
> "dtruss".
Sorry for the delay in replying. I got the output of dtruss ea
On Sat 12 Feb 2011 21:33, Noah Lavine writes:
>> Does guile --listen work? It appears to use a slightly different way to
>> set up the sockaddr.
>
> Oddly enough, it worked the first time I tried it (at least enough to
> get to a REPL - I didn't try to netcat over to it), but failed the
> second
On Sat 12 Feb 2011 21:47, Noah Lavine writes:
>> It would be interesting to see the output of a strace-like tool on both
>> the working Python program and the equivalent failing Guile program.
>> Apparently (according to the Interwebs), on OS X this tool is called
>> "dtruss".
>
> Sorry for the d
I tried the test program
(define addr (inet-aton "127.0.0.1"))
(define sockaddr (make-socket-address AF_INET addr 8080))
(define sock (socket PF_INET SOCK_STREAM 0))
(setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
(bind sock sockaddr)
And got the same error. I also tried changing the port to 9000 and
Hello,
> I think that's just tracing the shell wrapper; use meta/uninstalled-env
> libtool --mode=execute dtruss guile to get a more proper trace.
Got it, thanks! Again there's a lot of output, but the most important
bit seems to be here (with some context):
;; Here Guile is finishing loading it
Hi Mark,
On Sat 12 Feb 2011 22:03, Mark Weaver writes:
> I really hope you decide to at least apply the first patch for 2.0.
> They are very useful operators, and also they make the existing
> floor/ceiling/truncate/round operators a whole lot faster when applied
> to fractions. I worked very h
Hi Noah,
On Sat 12 Feb 2011 22:35, Noah Lavine writes:
> socket(0x2, 0x1, 0x0) = 73 0; make a socket -
> INET family, SOCK_STREAM, internet protocol; we got one with
> descriptor 73
> fcntl(0x49, 0x3, 0x0) = 2 0 ; get flags for
> file de
Hey Ludovic,
> Great. It’s even preferable if the changes are made before the release.
> :-)
Alright, I think I've made the changes I described in my email. I
wasn't able to commit them, though ("Permission denied (publickey)")
-- are you sure I've got the appropriate permissions? Using the g
Hi,
> #x49 is 73 :)
If I knew a facepalm emoticon, I would use it now. :)
> Could the lseek could be the problem?
Maybe, but I suspect not. My man page for lseek says that lseek will
fail with ESPIPE if it is called on a socket, and my errno.h defines
ESPIPE to be 29, which is the error we got.
Hi all,
I think I have isolated the error (although in fact there are two
things that should be fixed).
I gdb'd Guile's executable and looked at the struct sockaddr just
before it was passed to bind. There were two mistakes.
First of all, that struct has an sa_len field which is supposed to
cont
Hello again,
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.
Noah
On Sat, Feb 12, 2011 at 8:45 PM, Noah Lavine wrote:
> Hi all,
>
> I think I have isolated the error (although in fact there are two
>
And this patch sets the sin_len member of struct sockaddr_in
correctly, even if it doesn't appear in struct sockaddr. It's not
needed to fix the previous bug, but it is more correct. Also it seems
like the sort of thing that could cause trouble later if it's not
fixed.
On Sat, Feb 12, 2011 at 9:22
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_
sockaddr_in6 -> sin6_
sockaddr_storage -> ss_
I suspect you'd do fine if
25 matches
Mail list logo
