[cc-ing cffi-devel]

On Sun, Aug 28, 2016 at 8:08 PM, Chris Bagley chris.bagley@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,