Ok I have made the changes we spoke about and I think it's in a place where we can start testing some projects with it.
Find the latest at: https://github.com/cbaggers/cffi/tree/feature-grovel-caching
Excited to hear your results/issues,
Baggers
On 29 August 2016 at 00:18, Chris Bagley chris.bagley@gmail.com wrote:
[sorry I keep replying to luis instead of the mailinglist]
but I think all we have to do is look at *features* really.
Yup and uiop has #'operating-system and #'architecture that helps us out there
Perhaps grabbing the #+/#- reader macro functions and invoking them directly is slightly more elegant/robust than calling going through read-from-string?
hmm could be, how would we get the feature-expression from those?
Which direction are we copying in, and is that .cache directory grovel's or ASDF's?
So in my branch currently:
- if we have the files cached we copy them to .cache
- if we dont have them cached we build them in .cache
My chance would be to the 'dont have them case'
- if we dont have them cached we build them in .cache and then copy
the results to the cache folder
On 29 August 2016 at 00:17, Chris Bagley chris.bagley@gmail.com wrote:
but I think all we have to do is look at *features* really.
Yup and uiop has #'operating-system and #'architecture that helps us out there
Perhaps grabbing the #+/#- reader macro functions and invoking them directly is slightly more elegant/robust than calling going through read-from-string?
hmm could be, how would we get the feature-expression from those?
Which direction are we copying in, and is that .cache directory grovel's or ASDF's?
So in my branch currently:
- if we have the files cached we copy them to .cache
- if we dont have them cached we build them in .cache
My chance would be to the 'dont have them case'
- if we dont have them cached we build them in .cache and then copy
the results to the cache folder
On 28 August 2016 at 22:21, Luís Oliveira luismbo@gmail.com wrote:
[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,
-- Luís Oliveira http://kerno.org/~luis/
-
Chris Bagley