On Wed, Feb 24, 2016 at 2:21 PM, Luís Oliveira luismbo@gmail.com wrote:
On Wed, Feb 24, 2016 at 7:10 PM, Attila Lendvai attila@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