From: Kristian Lein-Mathisen
Subject: Re: [Chicken-hackers] incorrect warning during compilation
Date: Fri, 27 Jun 2014 17:13:21 +0200
> Actually, that's really cool! A "string-buffer" type! I wouldn't mind
> seeing this in core. So how does this work, Felix, do we vote and things?
Here is an at
> Sounds like candidates for "lolevel subset" APIs. There are also a room
> for leveraging Chicken close relationship with C when optimizing code.
> We have some bottlenecks where Scheme is "too high level" but using its
> C API directly is too troublesome. It would be nice to have some more
> low
From: Moritz Heidkamp
Subject: Re: [Chicken-hackers] incorrect warning during compilation
Date: Fri, 27 Jun 2014 18:01:51 +0200
> Hi,
>
> Felix Winkelmann writes:
>> So, I can't think of a solution that answers all of your questions.
>> I would go with the scheme-pointer.
>>
>> We could add an
On 06/27/14 18:41, Felix Winkelmann wrote:
>> Depending on how large the subset of procedures is we could perhaps pull
>> a simplified version of them into core and optimise that to hell, and
>> excise the slow remaining crap from core and move it to an egg (we
>> already have some duplication like
On 06/26/14 16:33, Peter Bex wrote:
> On Mon, Jun 23, 2014 at 04:02:59AM +0400, Oleg Kolosov wrote:
>> On 06/19/14 23:27, Peter Bex wrote:
>> Units are also used for separate compilation of large code bases. It is
>> not always make sense to separate everything into modules. This is
>> useful, but
This one I'd like. Currently using the "scheme-pointer plus type cast
in C" approach. Quite often actually.
Am 27.06.2014 17:13, schrieb Kristian Lein-Mathisen:
Actually, that's really cool! A "string-buffer" type! I wouldn't mind
seeing this in core. So how does this work, Felix, do we vot
Kristian Lein-Mathisen scripsit:
> And I guess string->blob/shared isn't all that useful if no other Schemes
> support it and we have plenty of other workarounds. I never really got
> blobs anyway, when do you *not* just want to use a string instead? They
> print so much nicer than blobs, even wit
Hi,
Felix Winkelmann writes:
> So, I can't think of a solution that answers all of your questions.
> I would go with the scheme-pointer.
>
> We could add another foreign type, that accepts strings but doesn't
> copy. I'll look into that.
how about extending the [nonnull-]scheme-pointer type to
Actually, that's really cool! A "string-buffer" type! I wouldn't mind
seeing this in core. So how does this work, Felix, do we vote and things?
K.
On Fri, Jun 27, 2014 at 4:43 PM, Felix Winkelmann <
felix.winkelm...@bevuta.com> wrote:
> > I talked to Peter on #chicken and he wasn't happy about
> I talked to Peter on #chicken and he wasn't happy about another
> foreign-type. I suppose I agree with him, there are quite a few already and
> maybe it'll just be confusing: having a "c-string" and a "string" foreign
> type would probably do more harm than gain.
Well, no problem. Attached a pat
> Depending on how large the subset of procedures is we could perhaps pull
> a simplified version of them into core and optimise that to hell, and
> excise the slow remaining crap from core and move it to an egg (we
> already have some duplication like foldl vs fold and string-intersperse
> vs stri
Thanks for you feedback Felix,
I talked to Peter on #chicken and he wasn't happy about another
foreign-type. I suppose I agree with him, there are quite a few already and
maybe it'll just be confusing: having a "c-string" and a "string" foreign
type would probably do more harm than gain.
I decide
> Oh, I see. I though it was meant to be used interchangeably. I can't use
> string->blob, though, because that will copy the data and I need to modify
> it from C. What foreign type should I use for this sort of thing?
>
> - (c-pointer char) with (location "string") works, but is a lot of typing
13 matches
Mail list logo
