[cc-ing cffi-devel] On Sun, Aug 28, 2016 at 8:08 PM, Chris Bagley <chris.bag...@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/
