Hi,
I am debugging a program that calls some C functions via CFFI.
Printing stuff from C would be useful (via printf), but the output
doesn't show up. I am using SBCL, inside Emacs and SLIME. Is there a
way to see the output of printf called from C somewhere?
Thanks,
Tamas
Tamas Papp <······@gmail.com> writes:
> I am debugging a program that calls some C functions via CFFI.
> Printing stuff from C would be useful (via printf), but the output
> doesn't show up. I am using SBCL, inside Emacs and SLIME. Is there a
> way to see the output of printf called from C somewhere?
What about *inferior-lisp*?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon <···@informatimago.com> writes:
> Tamas Papp <······@gmail.com> writes:
>> I am debugging a program that calls some C functions via CFFI.
>> Printing stuff from C would be useful (via printf), but the output
>> doesn't show up. I am using SBCL, inside Emacs and SLIME. Is there a
>> way to see the output of printf called from C somewhere?
>
> What about *inferior-lisp*?
It is not there. Maybe because I am using SBCL, which uses threads?
Currently I am printing to a file, which is a bit clunky.
Tamas
On Jul 11, 7:55 am, Tamas Papp <······@gmail.com> wrote:
> Pascal Bourguignon <····@informatimago.com> writes:
> > Tamas Papp <······@gmail.com> writes:
> >> I am debugging a program that calls some C functions via CFFI.
> >> Printing stuff from C would be useful (via printf), but the output
> >> doesn't show up. I am using SBCL, inside Emacs and SLIME. Is there a
> >> way to see the output of printf called from C somewhere?
>
> > What about *inferior-lisp*?
>
> It is not there. Maybe because I am using SBCL, which uses threads?
>
> Currently I am printing to a file, which is a bit clunky.
>
> Tamas
You can use sprintf together with with-foreign-pointer-as-string to
view a value for debugging. From the CFFI docs:
(defcfun "sprintf" :int
(str :pointer)
(control :string)
&rest)
CFFI> (with-foreign-pointer-as-string (s 100)
(sprintf s "%c %d %.2f %s" :char 90 :short 42 :float pi
:string "super-locrian"))
=> "A 42 3.14 super-locrian"
Tamas Papp <······@gmail.com> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Tamas Papp <······@gmail.com> writes:
>>> I am debugging a program that calls some C functions via CFFI.
>>> Printing stuff from C would be useful (via printf), but the output
>>> doesn't show up. I am using SBCL, inside Emacs and SLIME. Is there a
>>> way to see the output of printf called from C somewhere?
>>
>> What about *inferior-lisp*?
>
> It is not there. Maybe because I am using SBCL, which uses threads?
>
> Currently I am printing to a file, which is a bit clunky.
Ah, I tried with slime+clisp; perhaps with sbcl slime doesn't open
*inferior-lisp*... I can't try right now.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Works for me. printf output shows up in *inferior-lisp* with slime
+sbcl.
On Jul 11, 9:13 am, Pascal Bourguignon <····@informatimago.com> wrote:
> Ah, I tried with slime+clisp; perhaps with sbcl slime doesn't open
> *inferior-lisp*... I can't try right now.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NOTE: The most fundamental particles in this product are held
> together by a "gluing" force about which little is currently known
> and whose adhesive power can therefore not be permanently
> guaranteed.
On Wed, 11 Jul 2007 13:55:47 +0200, Tamas Papp wrote:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> [quoted text muted]
>
> It is not there. Maybe because I am using SBCL, which uses threads?
>
> Currently I am printing to a file, which is a bit clunky.
>
> Tamas
If you're running SBCL with Slime, printf outputs go to the
*inferior-lisp* buffer, at least when using SBCL's native FFI methodology
or CFFI.
Jeff Cunningham
jkc <·······@makewavs.com> writes:
> On Wed, 11 Jul 2007 13:55:47 +0200, Tamas Papp wrote:
>
>> Pascal Bourguignon <···@informatimago.com> writes:
>>
>>> [quoted text muted]
>>
>> It is not there. Maybe because I am using SBCL, which uses threads?
>>
>> Currently I am printing to a file, which is a bit clunky.
>>
>> Tamas
>
> If you're running SBCL with Slime, printf outputs go to the
> *inferior-lisp* buffer, at least when using SBCL's native FFI methodology
> or CFFI.
>
> Jeff Cunningham
Thanks for the answers. After debugging C for a while, I learned that
it is much more productive to write the CFFI bindings for the C
functions I am using, and write the whole thing in Lisp.
I was reluctant to do this first, because I had to deal with then
internals of some C structures and wanted to avoid those defstructs.
But working in Lisp makes debugging a thousand times easier than C. I
finished the task in an afternoon, and I have spent a week on it
before chasing silly bugs in my C code.
So now I realize that the reason people don't debug complex C code
called from Lisp using printf's is that they write it in Lisp instead.
Slowly, slowly creep along
The slope of Fuji, O Snail
Up to the very top of the mountain!
(Issa, 1763-1828)
Tamas
On Wed, 11 Jul 2007 11:11:56 +0200, Tamas Papp wrote:
> Hi,
>
> I am debugging a program that calls some C functions via CFFI.
> Printing stuff from C would be useful (via printf), but the output
> doesn't show up. I am using SBCL, inside Emacs and SLIME. Is there a
> way to see the output of printf called from C somewhere?
Not portable. A simple C printf will print to file descriptor 1 of the
hosting LISP - and that will most likely not be visible from SLIME.
You _could_ of course try to get hold of the socket file descriptor that
swank uses to communicate with SLIME but you would still need to write
write swank messages (or look for the messages in the inferior lisp buffer
...) - probably not worth the struggle.
HTH Ralf Mattes
>
> Thanks,
>
> Tamas