Re: hooking guile to hardware

[Russ McManus <mcmanr@eq.gs.com>]

Corey Sweeney <corey@interaccess.com> writes:

> I'm hopeing to use guile to manipulate video images that i get from
> a framegrabber card.  I can find slow ways of doing it, but i'd like
> to speed it up, by having the card write the frame directly into
> memory, and my program manipulate it from there.  i have 2
> questions:
>
> #1 in order to get the image into memory, would a
> framegrabber->guile chunk of code have to be written in C?

No, it would not *have* to be written in C.  But I suspect that to
meet your earlier requirement of speed, you might *want* to write low
level parts of this program in C.  I'm going to admit it: some things
are better written in C than Scheme.

Of course, it's hard to tell where you really need speed.  So I would
suggest writing only the truly low level stuff in 'C', and then
everything else in Scheme.  You can migrate pieces back to C as the
application demands.

> #2 in order to access the image once it's in memory, what type of
> "sturcture" can be used for the image?  could it be "bluffed" into
> looking like a list of lists to the program?  or should a real
> interface be made for it, so pixels could be accessed by new guile
> commands that are really written in C?

In my experience, the quickest way to do something like this is to
expose a 'C-ish' interface to Scheme using hand coded primitives.  I
use some elisp to make this quick and painless.  What I mean by
'C-ish' is stuff like returning -1 on error, and setting a global var
to the error value.

Then write some Scheme wrapped around the 'C-ish' interface to give
the Scheme program a 'Schemey' interface.  So to extend my example,
there would be a Scheme wrapper around each call to a C primitive,
that would provide exception handling on errors.

This means that the C code you have to write is very straight forward
and easy to write.  And cranking out the Scheme wrappers can be done
very quickly, because there is no compile, link, debug cycle.  I am
currently using this technique to wrap the Reuter's SSL real time data
distribution library, and it works great.  I've also used the same
technique to wrap Sybase's DBLib (I need to crank out a CTLib
replacement soon).

> also, has GIMP already addressed these issues, and come up with data types
> for this (actually their, but hopefully compatible) purpose?

I don't know much about GIMP, I'm afraid.

-russ

--
"Unfortunately the only Windows feature inspired by emacs was size."
             -- Nick C. in alt.religion.emacs