[cffi-devel] pushing ":cffi" into features?
Hello, Right now :cffi is not pushed into the *features* list, rather :cffi/no-long-long is. Is there any reason why this is done so? Because of this I am not able to write code which can conditionally depend on the presence of cffi, for example `#+cffi (do-something)'. I don't think conditionally compiling on `cffi/no-long-long' will be a good idea because it is something which might not be present in the future. Thanks. -- Surendra Singhi http://www.public.asu.edu/~sksinghi/index.html ,---- | Great wits are sure to madness near allied, | And thin partitions do their bounds divide. | | (John Dryden, Absalom and Achitophel, 1681) `----
On 12/20/05, Surendra Singhi <efuzzyone@netscape.net> wrote:
Hello, Right now :cffi is not pushed into the *features* list, rather :cffi/no-long-long is. Is there any reason why this is done so?
Because of this I am not able to write code which can conditionally depend on the presence of cffi, for example `#+cffi (do-something)'.
Hi Surendra. I hope my perspective might be useful. In my case, I have decided to concentrate on using CFFI, instead of trying to keep native FFI layer code around. My gut feeling is that this is low-risk. I figure that if I run into a problem, I've got the option of writing my own temporary shim to solve the problem in such a way that the conditionalization for each Lisp implementation is hidden. Then see about submitting a patch (which I am certainly not saying *you* need to be reminded to do, just that this is part of my rationale); in any case, I have confidence that a real problem in CFFI could be addressed pretty quickly. Thus, pushing :cffi onto *features* doesn't have any value for me.
I don't think conditionally compiling on `cffi/no-long-long' will be a good idea because it is something which might not be present in the future.
I think cffi/no-long-long is not intended to advertise that CFFI is available, but really is specifically saying "be advised that CFFI doesn't support a long-long type on this target FFI API". -- Jack
Thus, pushing :cffi onto *features* doesn't have any value for me.
well it does for me! and ive asked for it twice so my loading programs can take the appropriate action if it isnt already loaded. i cannot understand the reluctance to add it. programs that dont want to use the feature dont have to use it. --rick
On 12/20/05, Rick Taube <taube@uiuc.edu> wrote:
Thus, pushing :cffi onto *features* doesn't have any value for me.
well it does for me! and ive asked for it twice so my loading programs can take the appropriate action if it isnt already loaded. i cannot understand the reluctance to add it. programs that dont want to use the feature dont have to use it.
I admit previously having a lack of imagination with regard to dependency loading schemes. -- Jack (not a CFFI developer, just a user)
On 2005-dec-21, at 03:12, Rick Taube wrote:
Thus, pushing :cffi onto *features* doesn't have any value for me.
well it does for me! and ive asked for it twice so my loading programs can take the appropriate action if it isnt already loaded. i cannot understand the reluctance to add it. programs that dont want to use the feature dont have to use it.
The consing! One extra cons cell! :-) Or, alternatively, we were waiting until christmas to offer you this feature. Anyway, :cffi is now pushed onto *features*. :-) -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
Luís Oliveira <luismbo@gmail.com> writes:
Anyway, :cffi is now pushed onto *features*. :-)
Thanks. -- Surendra Singhi http://www.public.asu.edu/~sksinghi/index.html ,---- | WHY SHOULD WE SAVE TIGER? | Ans: Saving the tiger means saving mankind.. | | Help http://pudang.tripod.com/ | or https://secure.worldwildlife.org/forms/tiger_appeal_1.cfm `----
Surendra Singhi <efuzzyone@netscape.net> writes:
Right now :cffi is not pushed into the *features* list, rather :cffi/no-long-long is. Is there any reason why this is done so?
Regarding :cffi/no-long-long see: http://common-lisp.net/project/cffi/manual/html_node/Built_002dIn-Types.html... -- Luís Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
participants (4)
-
Jack Unrue -
Luís Oliveira -
Rick Taube -
Surendra Singhi