On Fri, Sep 12, 2014 at 12:12:56PM +0200, Felix Winkelmann wrote:
Hi!
Attached is a new version of the patch, which removes tests/signal-tests.scm
(this was forgotten and moved to the srfi-18 egg)
Thanks, I've pushed this patch.
Cheers,
Peter
--
http://www.more-magic.net
* Felix Winkelmann felix.winkelm...@bevuta.com [140912 10:40]:
Hello!
This patch removes support for srfi-18 and srfi-69. I had to remove
some tests as well, specifically those that use threads.
I will also move the eggs into the release/5 branch, together with
most tests that have been
Does it make sense to keep the scheduler in core then? Or in other
words, do we need to have an internal/inofficial/##sys#secret#
thread api for it to make sense?
The threading implementation does not have to be identical with the
scheduling mechanism. The latter needs to be embedded deep into
On Fri, Sep 12, 2014 at 10:39:59AM +0200, Felix Winkelmann wrote:
Hello!
This patch removes support for srfi-18 and srfi-69. I had to remove
some tests as well, specifically those that use threads.
This seems like a bad idea. These tests are there because we've had
very hairy problems
* Felix Winkelmann felix.winkelm...@bevuta.com [140912 12:11]:
From: Peter Bex peter@xs4all.nl
Subject: Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
Date: Fri, 12 Sep 2014 11:40:17 +0200
On Fri, Sep 12, 2014 at 10:39:59AM +0200, Felix Winkelmann wrote:
Hello
From: Christian Kellermann ck...@pestilenz.org
Subject: Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
Date: Fri, 12 Sep 2014 12:15:10 +0200
* Felix Winkelmann felix.winkelm...@bevuta.com [140912 12:11]:
From: Peter Bex peter@xs4all.nl
Subject: Re: [Chicken-hackers] [PATCH(5
On Fri, Sep 12, 2014 at 12:15:10PM +0200, Christian Kellermann wrote:
I am in favor of pushing this patch. Peter, what do you think?
I think that's okay.
Cheers,
Peter
--
http://www.more-magic.net
___
Chicken-hackers mailing list
To hide all the other helper procedures and to be able to replace
it with something else. As it is now ##sys#schedule is already
available so I don't see any harm in this. Maybe we have different
expectations about the modularisation of core?
We do, it seems.
Can you describe in more detail
Felix Winkelmann felix.winkelm...@bevuta.com writes:
To hide all the other helper procedures and to be able to replace
it with something else. As it is now ##sys#schedule is already
available so I don't see any harm in this. Maybe we have different
expectations about the modularisation of
Felix Winkelmann felix.winkelm...@bevuta.com writes:
It includes literal C code directly in the code generated by the compiler.
There are a couple of helper functions and macros in there. You can ignore it,
just leave the foreign-declaration as it is.
I just wondered whether pulling it out of
Felix Winkelmann felix.winkelm...@bevuta.com writes:
It includes literal C code directly in the code generated by the compiler.
There are a couple of helper functions and macros in there. You can ignore
it,
just leave the foreign-declaration as it is.
I just wondered whether pulling it
Felix Winkelmann felix.winkelm...@bevuta.com writes:
The foreign-declare syntax expands into (declare (foreign-declare
...)).
Oh *duh* ;)
Thanks,
Christian
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
12 matches
Mail list logo
