A big question is the ease of installation for those using OS package
systems vs those doing things by hand. My view is that the really big
issue is making things
a) easy to package
and
b) easy to use once packaged
Since that's what is in the critical path to having things like
gnumeric have guil
Greg Troxel <[EMAIL PROTECTED]> writes:
> A big question is the ease of installation for those using OS package
> systems vs those doing things by hand. My view is that the really big
> issue is making things
> a) easy to package
> and
> b) easy to use once packaged
Those two things would benefi
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> Does it still fail for you?
>
> Yes. I'm not sure if it's something I've done. I had trouble getting
> gdb to show anything.
I remember seeing strange blocking as well, and I think it was because
some pipe
Bruce Korb <[EMAIL PROTECTED]> writes:
> My opinion: the more impediments to installation that there are
> results in more folks deciding that it isn't worth the bother.
> I really hate downloading a package only to find that there's
> a bunch of other stuff to find, download and install first.
Hi Marius,
Marius Vollmer wrote:
> Yes, but I think Guile is very reasonable with its "bunch of other
> stuff". It only really requires libgmp and libltdl. The versions of
> these that are in the mainstream distributions should suffice.
The mainstream distributions "of Linux" :). My world is
Bruce Korb <[EMAIL PROTECTED]> writes:
> Since you are not proposing to fail the configure and leave no clues,
Yes, good documentation is of course needed. Right now, Guile fails with
configure: error: libltdl not found. See README.
And the README says:
Required External Packages ===
On Tue, Mar 08, 2005 at 09:13:48AM -0800, Bruce Korb wrote:
> Hi Marius,
>
> Marius Vollmer wrote:
>
> > Yes, but I think Guile is very reasonable with its "bunch of other
> > stuff". It only really requires libgmp and libltdl. The versions of
> > these that are in the mainstream distributions
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Those two things would benefit when Guile explicitely declares as a
> external dependency. The Right Thing for a Guile OS package such as a
> .deb or .rpm is not to contain libltdl but to depend on the package
> that contains libltdl.
For the record,
Hi,
what is the difference between
(join-thread (begin-thread (foo)))
and
(future-ref (future (foo)))
I am thinking about implementing futures as just
(define-macro (future exp) `(begin-thread ,exp))
(define future-ref join-thread)
Would that make sense?
___
Rob Browning wrote:
Marius Vollmer <[EMAIL PROTECTED]> writes:
Those two things would benefit when Guile explicitely declares as a
external dependency. The Right Thing for a Guile OS package such as a
.deb or .rpm is not to contain libltdl but to depend on the package
that contains libltdl.
For
On Tue, 08 Mar 2005 19:04:17 +0100, Marius Vollmer
<[EMAIL PROTECTED]> wrote:
> what is the difference between
>
> (join-thread (begin-thread (foo)))
>
> and
>
> (future-ref (future (foo)))
The first construct is guaranteed to start a new OS thread with its
own, complete, dynamic contex
Marius Vollmer <[EMAIL PROTECTED]> writes:
> what is the difference between
>
> (join-thread (begin-thread (foo)))
>
> and
>
> (future-ref (future (foo)))
>
> I am thinking about implementing futures as just
>
> (define-macro (future exp) `(begin-thread ,exp))
> (define future-ref
> Yes, but I think Guile is very reasonable with its "bunch of other
> stuff". It only really requires libgmp and libltdl. The versions of
> these that are in the mainstream distributions should suffice.
The mainstream distributions "of Linux" :). My world is about 1/4 Linux
and doesn
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
>
> The current implementation caches a number of "workers", so rather
> than spawning a new thread,
Do they get gc'ed after a while?
The relative lightness of futures probably wants mentioning in the
manual.
_
14 matches
Mail list logo