Ken Raeburn <[EMAIL PROTECTED]> writes:
> If at all possible, this code should be switched to use get*by*_r, or
> in the gethostby* cases, perhaps getaddrinfo and getnameinfo.
Yes, definitely. Could you help with that?
___
Guile-devel mailing list
Gu
Rob Browning <[EMAIL PROTECTED]> writes:
> Alhough I agree that it would be good to have a clear configure
> error message when libltdl is not detected.
Of course.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/
[EMAIL PROTECTED] writes:
> Can't guile distribute libltdl but only use
> it iff there's no local version found (or if the user states her
> intention by configure magic)?
That is how it works right now. I am not happy about the fact that
Guile does this silently and that it is a configure decis
Rob Browning <[EMAIL PROTECTED]> writes:
> Though is a terminated thread very "heavy"? i.e. is it much heavier
> than a cons pair?
Yes. It is a scm_i_thread struct, but the OS thread has been
deallocated already.
___
Guile-devel mailing list
Guile-d
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
>> Would that make sense?
>
> I don't think so for obvious reasons. It would not make sense to
> spawn new pthreads for the kind of usage patterns for which futures
> are intended. In my opinion it's better to scrap futures entirely than
> to provide t
On Wed, Mar 09, 2005 at 04:08:07PM +0100, Marius Vollmer wrote:
> [EMAIL PROTECTED] writes:
>
> > Can't guile distribute libltdl but only use
> > it iff there's no local version found (or if the user states her
> > intention by configure magic)?
>
> That is how it works right now. I am not happy
Marius Vollmer <[EMAIL PROTECTED]> writes:
> What I would be happy with is to include a copy of libltdl in the
> Guile distribution but to have it completely ignored by configure
> and the Makefiles. When libltdl is not found in the system, a
> message could be printed that instructs the user to
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Ken Raeburn <[EMAIL PROTECTED]> writes:
>
>> If at all possible, this code should be switched to use get*by*_r, or
>> in the gethostby* cases, perhaps getaddrinfo and getnameinfo.
>
> Yes, definitely. Could you help with that?
>
FWIW, I just stole some
Marius Vollmer <[EMAIL PROTECTED]> writes:
> (I will also try to benchmark them, but there is a bug right now that
> prevents me from using a huge number of threads... (that bug is not
> related to futures))
Okaaay, after fixing a couple of nice bugs (gdb is really good
with threads these day
Marius Vollmer <[EMAIL PROTECTED]> writes:
> So futures are clearly faster than threads (as expected). Nice!
Indeed, and as I think someone may have mentioned, we definitely need
some clarification in the docs, since they don't make it clear how
futures differ from threads.
--
Rob Browning
rlb
We are pleased to announce the release of Guile 1.7.2. This is a
'technology preview' for the upcoming Guile 1.8. It can be found
here:
ftp://alpha.gnu.org/gnu/guile/guile-1.7.2.tar.gz
Its MD5 checksum is
7fabb64198993e971f65a27846202388 guile-1.7.2.tar.gz
This version is guaranteed
I had a bit of a go at the new srfi-60 for the cvs head (below).
There's only a half dozen functions not already in the core.
`bit-count' clashes, in srfi-60 it's an alias for logcount but in the
core it's for bit vectors. I'm not sure what to do with that. It
should be exported, but there'd be
12 matches
Mail list logo
