Felix Winkelmann writes:
> The "foreign-declare" syntax expands into "(declare (foreign-declare
> ...))".
Oh *duh* ;)
Thanks,
Christian
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hac
> Felix Winkelmann 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 the declare
Felix Winkelmann 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 the declare makes any
di
> My idea has been that we will wrap all internal "functinal blocks" into
> modules, so that we have a uniform way of controlling access and
> immediately see where a particular procedure is used in core. This might
> be tedious or even busy work but I think we could benefit from that.
>
> I did n
Felix Winkelmann 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 core?
>
> We do, it see
From: Peter Bex
Subject: Re: [Chicken-hackers] Exposing internal APIS
Date: Fri, 12 Sep 2014 12:34:04 +0200
> On Fri, Sep 12, 2014 at 12:31:00PM +0200, Felix Winkelmann wrote:
>> Hello, again!
>>
>>
>> If I understand this correctly, then you want to expose the internal
>> threading stuff in sc
> 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 deta
On Fri, Sep 12, 2014 at 12:31:00PM +0200, Felix Winkelmann wrote:
> Hello, again!
>
>
> If I understand this correctly, then you want to expose the internal
> threading stuff in scheduler.scm as a module?
I think we can do the same I did with the compiler modules: simply wrap
the code in a modul
Hello, again!
If I understand this correctly, then you want to expose the internal
threading stuff in scheduler.scm as a module?
I think this should be avoided - we tie our hands behind our backs by
doing this. Once we fix the interface to deeply internal functionality
like the scheduler and the
* Felix Winkelmann [140912 12:19]:
> What is the intention behind a scheduler module? There is only one
> procedure ("##sys#schedule"), which should definitely not be exported.
To hide all the other helper procedures and to be able to replace
it with something else. As it is now ##sys#schedule is
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
Chicken-hackers@non
From: Christian Kellermann
Subject: Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
Date: Fri, 12 Sep 2014 12:15:10 +0200
> * Felix Winkelmann [140912 12:11]:
>> From: Peter Bex
>> Subject: Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
>> Date: Fri, 12 Sep 2014 11:40:1
* Felix Winkelmann [140912 12:11]:
> From: Peter Bex
> 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!
> >>
> >>
> >> This patch removes support for
From: Peter Bex
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!
>>
>>
>> This patch removes support for srfi-18 and srfi-69. I had to remove
>> some tests as
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
> 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
* Felix Winkelmann [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 removed from the co
Hello!
Signed off and pushed.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
* Felix Winkelmann [140911 18:52]:
> Hello!
>
>
> Attached is a patch for the chicken-5 branch that completes the recent
> CR about removal/eggification of some core stuff.
I have pushed it to chicken-5.
Thank you!
Christian
--
May you be peaceful, may you live in safety, may you be free fr
19 matches
Mail list logo
