Would love some feedback on wip feature

[Chris Bagley]

[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/