Would love some feedback on wip feature

[Chris Bagley]

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 at 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 at 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 at gmail.com> wrote:
>>> [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/