On Tue, 2007-12-04 at 07:50 +0100, Marco Maggi wrote:
> 3. For Guile 2.0 backwards compatibility at the C level can
>be broken. Freely. No shame. No blame.
This message references another message that I can't find:
http://lists.gnu.org/archive/html/guile-devel/2003-04/msg00076.html
> 4. If
Hi,
"Marco Maggi" <[EMAIL PROTECTED]> writes:
> But it does not have to because, like it or not, Guile is a
> language for extensions. With this in mind...
Right, although I question the "language for extensions" paradigm: why
would you choose language Y for "extensions" and language X for the
> Right, although I question the "language for extensions" paradigm: why
> would you choose language Y for "extensions" and language X for the
> rest, given that (i) X sucks, (ii) Y rocks, and (iii) nothing inherently
> makes programs in language Y "slower". :-)
There are several reasons to h
() [EMAIL PROTECTED] (Ludovic Courtès)
() Fri, 30 Nov 2007 16:44:34 +0100
Guile-RPC[0] `serve-one-stream-request/asynchronous' [...]
idea is to pass the RPC handler a continuation that
it must invoke to actually return the RPC result over the network.
interesting, thanks for the pointer.
Hi,
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
> There are several reasons to have different base and extension
> languages. The worst is that Guile/Scheme is 10 to 30 times
> slower than the equivalent C code, and in DSP work, that matters.
Of course it matters, but another solution would
On 4 Dec, 2007, at 15:50, [EMAIL PROTECTED] wrote:
1a. Why functions like SIN have a Scheme implementation for
complex numbers when standard C has "csin"?
In Scheme, any real is also complex. That's not the case in C. I hope
you're not proposing to separate the numeric types in Scheme.
Hi,
dskr <[EMAIL PROTECTED]> writes:
> the fport fill input code provides a way to avoid some threaded
> deadlocks with fport_wait_for_input. I appreciate this tremendously!
>
> Should this protection be extended to 'accept' in the socket code to
> prevent the entire runtime from blocking if a th
"Marco Maggi":
4. If a garbage collector allows to remove the need for
"scm_remember_upto_here" it must be adopted even if it
makes Guile slower and it raises memory usage a bit (or
more than a bit).
If we replace "should" with "must", I agree.
Regarding the HBGC, a few nonsc
On Tue, 4 Dec 2007, Kjetil S. Matheussen wrote:
>
> "Marco Maggi":
> >
> > 4. If a garbage collector allows to remove the need for
> > "scm_remember_upto_here" it must be adopted even if it
> > makes Guile slower and it raises memory usage a bit (or
> > more than a bit).
>
> If w
GEE/Streams is a C language library extension for Guile, the
GNU's Ubiquitous Intelligent Language for Extensions. It
implements a replacement for the (ice-9 streams) module
distributed with Guile.
If we are not Scheme newbies and we see a form starting with
(fold ...): we know immedi
On 4 Dec, 2007, at 18:01, [EMAIL PROTECTED] wrote:
1a. Why functions like SIN have a Scheme implementation for
complex numbers when standard C has "csin"?
In Scheme, any real is also complex. That's not the case in C. I hope
you're not proposing to separate the numeric types in Scheme.
On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote:
...
> Oh, and another thing. My tests (available in the guile-devel archives)
> also showed that the HBGC version usually use a bit less memory
> than Guile's old garbage collector. (Yet another "should"
> for replacing. :-) )
I don't
Hi,
Roland Orre <[EMAIL PROTECTED]> writes:
> If the GC should be replaced I would consider it wise to
> replace it with an algorithm than can be run in a thread.
HBGC can be configured with `--enable-parallel-mark'. The `GC_MARKERS'
environment variable then sets the number of marker threads.
On Tue, 4 Dec 2007, Roland Orre wrote:
On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote:
...
Oh, and another thing. My tests (available in the guile-devel archives)
also showed that the HBGC version usually use a bit less memory
than Guile's old garbage collector. (Yet another "s
"Marco Maggi" <[EMAIL PROTECTED]> writes:
> 3. For Guile 2.0 backwards compatibility at the C level can
>be broken. Freely. No shame. No blame.
Disagree, in general. Why should we be arbitrarily awkward? If there
are specific motivations, we should consider those case by case.
> 2. GOOPS
15 matches
Mail list logo
