28 Aug
2016
28 Aug
'16
10:18 p.m.
[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/