Once upon a time I decided to write myself a webapp in lisp, and so
began my tale of woe. On the recommendations of the livejournal lisp
community, I settled on SBCL and Araneida. I'm slowly working my way
through 'Practical Common Lisp' and the HyperSpec, but at the moment I
don't really know any lisp. Just so you know where I'm at in my lisp
development.
Once I had a server I could start and stop, my first order of business
followed the usual 'nixy behavior of dropping root once attached to a
privileged port (80). That should be pretty easy.
(if (= 0 (sb-posix:getuid))
; sb-posix doesn't have a similar function?
(let ((pw (osicat:user-info server-user)))
(sb-posix:setgid (cdr (assoc :group-id pw)))
(sb-posix:setuid (cdr (assoc :user-id pw)))))
osicat drags in UFFI as a requirement, which seemed like overkill for
the one function I wanted, but it worked well enough.
Somehow I came across CFFI, which has an uffi-compatibility layer.
Being one who prefers to avoid having multiple libraries doing the same
thing, I thought CFFI would be awesome. I could get rid of UFFI, and
work with anything which requires either CFFI or UFFI. (I've also seen
on this list some suggesting CFFI is better than UFFI, and who am I to
argue with people who've used both?)
Figuring 'compatibility layer' means 'drop-in replacement' (ha-ha-ha),
I started by creating uffi.asd
(defsystem uffi
:depends-on (cffi-uffi-compat))
and tried compiling osicat. That didn't work.
; compiling file ".../osicat/ffi.lisp"
; ...
; compiling (def-array-pointer cstring-array ...)
debugger invoked...
Unknown CFFI type: '(:uffi-array :cstring)
I managed to get rid of that particular error by editing cffi's
uffi-compat.lisp. In (defmacro def-array-pointer):
-`(cffi:defctype ,name '(:uffi-array ,type))
+`(cffi:defctype ,name ,(convert-uffi-type `(:array ,type)))
(Is this a good change, or am I breaking more than I'm fixing?)
Unfortunately, that only gets me to the next line in osicat's ffi.lisp
(def-array-pointer cstring-array :cstring) ; old complaint
(def-foreign-var "environ" 'cstring-array "osicat") ; new complaint
where it complains with "Unknown CFFI type: nil". Blarg! I've tried to
fix it, but having absolutely no idea what I'm doing makes that rather
difficult. It'd probably be easier to just convert osicat to use CFFI
or to reinstall UFFI, but neither of those options are any fun! :P
I don't need environment-variable access at the moment, so I've
commented out that line (osicat:user-info works just dandy, after all)
to move on to other things. But I know this is going to nag at me from
the back of my mind until it works, so to spare myself from that, I
figured I'd ask if anyone here has gotten all of osicat to work with
cffi-uffi-compat?
( Of all things, I had to pick C bindings--okay, FFI--as my )
( introduction to lisp. Some day I'll learn to start at the )
( beginning. At least, that's what I keep telling myself. )
pinterface wrote:
> Once upon a time I decided to write myself a webapp in lisp, and so
> began my tale of woe. On the recommendations of the livejournal lisp
> community, I settled on SBCL and Araneida. I'm slowly working my way
> through 'Practical Common Lisp' and the HyperSpec, but at the moment I
> don't really know any lisp. Just so you know where I'm at in my lisp
> development.
>
> Once I had a server I could start and stop, my first order of business
> followed the usual 'nixy behavior of dropping root once attached to a
> privileged port (80). That should be pretty easy.
>
> (if (= 0 (sb-posix:getuid))
> ; sb-posix doesn't have a similar function?
> (let ((pw (osicat:user-info server-user)))
> (sb-posix:setgid (cdr (assoc :group-id pw)))
> (sb-posix:setuid (cdr (assoc :user-id pw)))))
>
> osicat drags in UFFI as a requirement, which seemed like overkill for
> the one function I wanted, but it worked well enough.
>
> Somehow I came across CFFI, which has an uffi-compatibility layer.
> Being one who prefers to avoid having multiple libraries doing the same
> thing, I thought CFFI would be awesome. I could get rid of UFFI, and
> work with anything which requires either CFFI or UFFI. (I've also seen
> on this list some suggesting CFFI is better than UFFI, and who am I to
> argue with people who've used both?)
>
> Figuring 'compatibility layer' means 'drop-in replacement' (ha-ha-ha),
> I started by creating uffi.asd
> (defsystem uffi
> :depends-on (cffi-uffi-compat))
> and tried compiling osicat. That didn't work.
> ; compiling file ".../osicat/ffi.lisp"
> ; ...
> ; compiling (def-array-pointer cstring-array ...)
> debugger invoked...
> Unknown CFFI type: '(:uffi-array :cstring)
>
> I managed to get rid of that particular error by editing cffi's
> uffi-compat.lisp. In (defmacro def-array-pointer):
> -`(cffi:defctype ,name '(:uffi-array ,type))
> +`(cffi:defctype ,name ,(convert-uffi-type `(:array ,type)))
> (Is this a good change, or am I breaking more than I'm fixing?)
>
> Unfortunately, that only gets me to the next line in osicat's ffi.lisp
> (def-array-pointer cstring-array :cstring) ; old complaint
> (def-foreign-var "environ" 'cstring-array "osicat") ; new complaint
> where it complains with "Unknown CFFI type: nil". Blarg! I've tried to
> fix it, but having absolutely no idea what I'm doing makes that rather
> difficult. It'd probably be easier to just convert osicat to use CFFI
> or to reinstall UFFI, but neither of those options are any fun! :P
>
> I don't need environment-variable access at the moment, so I've
> commented out that line (osicat:user-info works just dandy, after all)
> to move on to other things. But I know this is going to nag at me from
> the back of my mind until it works, so to spare myself from that, I
> figured I'd ask if anyone here has gotten all of osicat to work with
> cffi-uffi-compat?
>
> ( Of all things, I had to pick C bindings--okay, FFI--as my )
> ( introduction to lisp. Some day I'll learn to start at the )
> ( beginning. At least, that's what I keep telling myself. )
>
Don't listen to yourself. He's wrong. Here is what you did wrong:
>> osicat drags in UFFI as a requirement, which seemed like overkill for
>> the one function I wanted, but it worked well enough.
>>
>> Somehow I came across CFFI, which has an uffi-compatibility layer.
>> Being one who prefers to avoid having multiple libraries doing the same thing...
Right there. That is your mistake. You are a newby who just wanted to
get a library working, and you allowed some esthetic over multiple FFI
libraries lead you into a quagmire. It probably takes three seconds to
compile UFFI from scratch, maybe less.
A lesser mistake was asking here instead of on the CFFI-devel mailing
list. Did you grab CFFI or the new branch started under the Google
Summer of Code, cffi-luis? The latter is currently under heavy
development, so you should be pounding that mailing list for help if you
end up using cffi-luis for non-osicat work.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
> You are a newby who just wanted to get a library working, and you allowed
> some esthetic over multiple FFI libraries lead you into a quagmire.
You're right. I've reinstalled UFFI and set things up such that I can
switch between it and uffi-compat fairly easily for when I know enough
to do something useful with them, but for now they can (hopefully) just
work and stay out of my way.
> A lesser mistake was asking here instead of on the CFFI-devel mailing list.
I almost posted my message to CFFI-devel, but didn't because I wasn't
sure just how much of my problem was me being an idiot, though even
them cffi-devel probably would have been a more appropriate place. Next
time! :)
> Did you grab CFFI or the new branch started under the Google
> Summer of Code, cffi-luis? The latter is currently under heavy
> development, so you should be pounding that mailing list for help if you
> end up using cffi-luis for non-osicat work.
cffi-luis, and will do.
"pinterface" <··············@gmail.com> writes:
> Somehow I came across CFFI, which has an uffi-compatibility layer.
> Being one who prefers to avoid having multiple libraries doing the same
> thing, I thought CFFI would be awesome. I could get rid of UFFI, and
> work with anything which requires either CFFI or UFFI. (I've also seen
> on this list some suggesting CFFI is better than UFFI, and who am I to
> argue with people who've used both?)
>
> Figuring 'compatibility layer' means 'drop-in replacement' (ha-ha-ha),
> I started by creating uffi.asd
> (defsystem uffi
> :depends-on (cffi-uffi-compat))
You could alternatively edit osicat.asd and make it depend on
cffi-uffi-compat instead of uffi.
> and tried compiling osicat. That didn't work.
> ; compiling file ".../osicat/ffi.lisp"
> ; ...
> ; compiling (def-array-pointer cstring-array ...)
> debugger invoked...
> Unknown CFFI type: '(:uffi-array :cstring)
>
> I managed to get rid of that particular error by editing cffi's
> uffi-compat.lisp. In (defmacro def-array-pointer):
> -`(cffi:defctype ,name '(:uffi-array ,type))
> +`(cffi:defctype ,name ,(convert-uffi-type `(:array ,type)))
> (Is this a good change, or am I breaking more than I'm fixing?)
Thanks for the bug report. This passed undetected because UFFI's test
suite doesn't test def-array-pointer. Anyway, this is now fixed,
thanks.
CFFI has a mailing list btw, bug reports are welcome there.
> Unfortunately, that only gets me to the next line in osicat's ffi.lisp
> (def-array-pointer cstring-array :cstring) ; old complaint
> (def-foreign-var "environ" 'cstring-array "osicat") ; new complaint
> where it complains with "Unknown CFFI type: nil". Blarg! I've tried to
> fix it, but having absolutely no idea what I'm doing makes that rather
> difficult. It'd probably be easier to just convert osicat to use CFFI
> or to reinstall UFFI, but neither of those options are any fun! :P
That def-foreign-var declaration is bogus, it should be:
(def-foreign-var "environ" cstring-array "osicat")
> figured I'd ask if anyone here has gotten all of osicat to work with
> cffi-uffi-compat?
Not with cffi-uffi-compat or uffi itself. Osicat needs some fixing.
Besides the above mention erroneous declaration
(deref-array environ cstring-array i) in osicat.lisp, line 277, should
be (deref-array environ 'cstring-array i). In my system a couple of
tests fail either with uffi or cffi-uffi-compat running Allegro or
OpenMCL. Compiling it with a recent sbcl fails.
--
Luis Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt
On 2005-09-15, Luis Oliveira <·············@deadspam.com> wrote:
> Not with cffi-uffi-compat or uffi itself. Osicat needs some fixing.
> Besides the above mention erroneous declaration
> (deref-array environ cstring-array i) in osicat.lisp, line 277, should
> be (deref-array environ 'cstring-array i). In my system a couple of
> tests fail either with uffi or cffi-uffi-compat running Allegro or
> OpenMCL. Compiling it with a recent sbcl fails.
Is this against the version in CVS? I went around and fixed a bunch of
things a while ago, and ISTR what's in CVS should work on most things
(at least SBCL and OpenMCL), but I am not the maintainer and wouldn't
feel right doing a proper release.
Glad to hear someone else is using osicat, too.
Cheers.
--
Julian Squires
Julian Squires wrote:
> On 2005-09-15, Luis Oliveira <·············@deadspam.com> wrote:
>
>>Not with cffi-uffi-compat or uffi itself. Osicat needs some fixing.
>>Besides the above mention erroneous declaration
>>(deref-array environ cstring-array i) in osicat.lisp, line 277, should
>>be (deref-array environ 'cstring-array i). In my system a couple of
>>tests fail either with uffi or cffi-uffi-compat running Allegro or
>>OpenMCL. Compiling it with a recent sbcl fails.
>
>
> Is this against the version in CVS?
Which reminds me of a note for potential CFFI users: you might need the
latest CVS version or patches for your Lisp of choice. Luis did a great
job of working with Lisp providers as the CFFI validation/regression
test unearthed limitations here and there, and many of them have done a
great job of correcting things. Methinks the critical mass will be
sufficient to make the foot-draggers catch up or bow out of the Lisp
game as CFFI becomes a defacto standard. YHIHF.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Julian Squires <······@cipht.net> writes:
> On 2005-09-15, Luis Oliveira <·············@deadspam.com> wrote:
>> Not with cffi-uffi-compat or uffi itself. Osicat needs some fixing.
>> Besides the above mention erroneous declaration
>> (deref-array environ cstring-array i) in osicat.lisp, line 277, should
>> be (deref-array environ 'cstring-array i). In my system a couple of
>> tests fail either with uffi or cffi-uffi-compat running Allegro or
>> OpenMCL. Compiling it with a recent sbcl fails.
>
> Is this against the version in CVS?
> I went around and fixed a bunch of
> things a while ago, and ISTR what's in CVS should work on most things
> (at least SBCL and OpenMCL), but I am not the maintainer and wouldn't
> feel right doing a proper release.
I downloaded what's in CVS and I see the same two errors I mentioned
above. Here's a patch.
--- src.orig/ffi.lisp Fri Sep 16 02:50:28 2005
+++ src/ffi.lisp Fri Sep 16 02:50:48 2005
@@ -104,7 +104,7 @@
:returning :int)
(def-array-pointer cstring-array :cstring)
-(def-foreign-var "environ" 'cstring-array "osicat")
+(def-foreign-var "environ" cstring-array "osicat")
(def-function "getpwnam" ((name :cstring))
:module "osicat"
--- src.orig/osicat.lisp Fri Sep 16 02:40:57 2005
+++ src/osicat.lisp Fri Sep 16 02:43:58 2005
@@ -312,7 +312,7 @@
(handler-case
(loop for i from 0 by 1
for string = (convert-from-cstring
- (deref-array environ cstring-array i))
+ (deref-array environ 'cstring-array i))
for split = (position #\= string)
while string
collecting (cons (subseq string 0 split)
Still doesn't compile with SBCL 0.9.4.57 (darwin/ppc) and fails a few
tests with OpenMCL.
--
Luis Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt
On 2005-09-16, Luis Oliveira <·············@deadspam.com> wrote:
> I downloaded what's in CVS and I see the same two errors I mentioned
> above. Here's a patch.
Thanks. I'll apply it and update the tests as well, hopefully this
weekend sometime.
--
Julian Squires
On 2005-09-16, Luis Oliveira <·············@deadspam.com> wrote:
> Still doesn't compile with SBCL 0.9.4.57 (darwin/ppc) and fails a few
> tests with OpenMCL.
I'm not sure why SBCL wouldn't have worked -- it seems to have worked
for me on Linux/ppc consistently. In any case, thanks for the patch,
which is now applied in CVS. The failing tests aren't anything to worry
about, I still have to find some time to make them more robust.
--
Julian Squires
Luis Oliveira wrote:
> "pinterface" <··············@gmail.com> writes:
> > Figuring 'compatibility layer' means 'drop-in replacement' (ha-ha-ha),
> > I started by creating uffi.asd
> > (defsystem uffi
> > :depends-on (cffi-uffi-compat))
>
> You could alternatively edit osicat.asd and make it depend on
> cffi-uffi-compat instead of uffi.
Heh, didn't think of that.
> > [broken uffi-array]
>
> Thanks for the bug report. This passed undetected because UFFI's test
> suite doesn't test def-array-pointer. Anyway, this is now fixed,
> thanks.
>
> CFFI has a mailing list btw, bug reports are welcome there.
Nice to know in the midst of my bumbling I managed to find an actual
bug. :) I'll be sure to hit the mailing list if I can identify any
more.
Thank you for being so awesomely quick to fix the bug!
[getting osicat to work with uffi/cffi-uffi-compat]
(this is true as of late yesterday, I haven't checked since then:) It's
interesting* the cvs version of osicat doesn't compile on your SBCL.
With SBCL 0.9.3.36 (x86), UFFI 1.5.1, and the CVS copy of osicat, it
compiles and works just fine for me. With an updated copy of cffi-luis
and the two changes to osicat you suggested, it fails the three
environment tests but otherwise works okay.
Just to be on the safe side, I think I'll avoid updating my SBCL and
move on to writing my own programs for the time being, and come back to
the FFI stuff when I have a better understanding of lisp.
* Granted, I don't know what's changed in SBCL between the versions, so
maybe the brokenness shouldn't be surprising.