CFFI govels size_t into :sizet [Was: cffi 0.17.0 breaks some stuff]

[Liam Healy]

On Wed, Feb 24, 2016 at 2:21 PM, Luís Oliveira <luismbo at gmail.com> wrote:
> On Wed, Feb 24, 2016 at 7:10 PM, Attila Lendvai <attila at lendvai.name> wrote:
>>  - for me it seems pretty ad-hoc why this one definition is included
>>    and the other C stdlib definitions are not.
>>
>>  - if we want to include and support size_t in the CFFI contract, then
>>    why in cffi-libffi? keep in mind that it requires groveling, which
>>    is quite a heavy dependency that CFFI proper doesn't require at
>>    this point.
>
> I suppose it was convenient for Liam. I agree it doesn't belong there.
> Liam, is it too much of a hassle to move the size_t grovelling to
> gsll? (If it is, maybe we can figure out something else.)

It was in GSLL originally but I moved it to CFFI-libffi because I
thought others would need it; why force people to reinvent it over and
over; isn't that the point of having a library? The discussion we had
on #lisp seems to bear me out on this. I agree with the grovel issue,
and putting it in cffi-libffi was just a hack to get grovel, so maybe
the right place for it is a new system like Attila suggests. I'm happy
with whatever we end up calling the symbol, I just need to do a global
search replace in GSLL (and so would the other systems that use it),
so we need to stall a bit and sync up with Zach in the end. As Attila
point out on #lisp, there are possibly other symbols that could go
there, so it might well be that people will want to add on to it. I
don't think it should go back into GSLL for the reason I stated.


>
>>  - why in the keyword package? (and it's another discussion why :int
>>    and other standard C definitions (not to be confused with stdlib.h)
>>    are in the keyword package, but i won't pursuit that argument at
>>    this point in time)
>
> Re the standard CFFI types: convenience.
>
>
>> maybe we want to open a new ASDF system for the C stdlib that would
>> depend on the groveler and accommodate for C stdlib definitions like
>> errno, size_t, etc?
>
> Maybe. Osicat sort of plays that role right now. It has size_t, and it
> has a bunch of errno functionality. (I don't remember if those are
> exported or anything.)

Interesting, I didn't know that. I had a dependence (for filenames, I
think) on osicat and I was convinced that UIOP is now the way to go,
so I switched over and removed the osicat dependence. (This may not
have been GSLL, but in one of my systems.) Do you think that the
osicat maintainer would be willing to "contribute" the stdlib
definitions to the proposed new system?

I am fairly neutral on the keyword vs other package issue. I chose the
keyword package because to me, size_t is like a built in, so it looks
a little cleaner. But I don't really care, as I said, it's really
matter of global search replace once we decide on a course of action.
And sizet is used *a lot* in GSLL, so there are a lot of replaces to
do.


>
> Should I make a bugfix release for Zach to test?
>
> --
> Luís Oliveira
> http://kerno.org/~luis/
>
I think the temporary reversion is enough to get us through the
moment, then once we've decided on the final form, all the changes
should be made at the same time so the next QL update everything is
consistent.  Over the next couple days I will have no time to work on
this, but on the weekend I should get some time.

Thanks,
Liam