Would love some feedback on wip feature

[Luís Oliveira]

[cc-ing cffi-devel]

On Sun, Aug 28, 2016 at 8:08 PM, Chris Bagley <chris.bagley at gmail.com> wrote:
> Cool, thanks for the details and sorry I've been busy this last week.
>
>> cpu/vendor/os triplet
>
> Sounds like it would be good to include these by default in the
> feature check, I'll add that.

At first I was worried we'd need to check this via uname or something
and that'd we need to handle the special case of running a 32-bit Lisp
on a 64-bit OS and things like that, but I think all we have to do is
look at *features* really.


>> dirty-featurep is not super pretty but it seems like the way to go
>
> Cool, then I will move this into cffi itself, and leave my potentially
> less portable version in the with-cached-reader-conditionals library

Perhaps grabbing the #+/#- reader macro functions and invoking them
directly is slightly more elegant/robust than calling going through
read-from-string?


>> Windows is picky about what a valid pathname is and (b) it's got a 260 character limit for pathnames.
>
> 100% agreed, also symbols can be unicode so that would break fast.
>
>> Perhaps we just need to record the result of each reader conditional, store those boolean results as increasingly significant bits in an integer
>
> The case I was worried about there is say someone had the following in
> their spec file:
>
>     (and linux swank (not windows))
>
> And that was #b110
>
> And they change it to:
>
>     (and linux sly (not windows))
>
> And that would still be #b110.
>
> I think we should do what you said about appending to the triplet but
> we should use some simple string hashing function instead of the
> bitmask. Will be a little ugly but robust at least.

Good point. Hashing seems much more reasonable than my suggestion. :-)


>> Can we avoid the copying by just writing to and loading from the cache directory unconditionally?
>
> Good question. I liked asdf's rational for using the system's cache
> directory for fasls and intermediate files and like how cffi uses it
> too. I'm a bit nervous of someone trying to use asdf to load a
> grovelling library from a directory they don't have write permissions
> for as currently that works fine.
>
> Actually, we could just check: if we have write permission we copy
> unconditionally, if not then we just leave it in the .cache dir.

Complying with ASDF's concept of output/cache directory does seem
important. (Perhaps we could ask asdf-devel for advice?) But I didn't
grasp this last solution you've suggested. Which direction are we
copying in, and is that .cache directory grovel's or ASDF's?

>
> I'll get implementing the above. Feel free to throw more ideas in the pile!
>
> Baggers

Cheers,

-- 
Luís Oliveira
http://kerno.org/~luis/