Michael Drumheller wrote:
>
> Brian,
>
> Hi, my name is Mike Drumheller. I recently read your
> article on Inline in TPJ and I am really excited about
> it. It looks like you have done a beautiful
> job of fixing some Hateful Stuff, and I am looking
> forward to using it (haven't quite used it yet).
>
> I have some questions about a couple of statements
> in your article: on p.37 you say "...you'll need to
> write your own wrapper...If this seems crummy at
> first,
> consider that all of your code will be in your module,
> and that it will be laid out in the true order of
> execution instead of being masked by a lot of extra
> syntax."
>
> I'm not sure what you mean by the above. As for the
> phrase "all of your code will be in your module" I'm
> confused because I'm thinking "where else would it
> be?"
> As for the phrase "it will be laid out in the true
> order of execution", I'm thinking *what* will be laid
> out that way, what is the "true order of execution",
> and how *else* would it be "laid out"?
Mike,
This section of the article was not very comprehensive to begin with and
I think some of the meaning was lost in the editing.
I'll try to explain with a simple example from the C-Cookbook manpage:
---------------------8<---------------------------
use Inline C => DATA =>
LIBS => '-luser32';
WinBox('Inline Text Box', 'Hello Mike');
__END__
__C__
#include <windows.h>
int WinBox(char* Caption, char* Text) {
return MessageBoxA(0, Text, Caption, 0);
}
---------------------8<---------------------------
I have a script and I want to make use of the 'MessageBoxA' function
from the Windows library 'user32.dll'. I have written an Inline wrapper
function called 'WinBox' that will be exposed in Perl space. (It draws a
small text window on the screen).
With XS I would have to create a whole new module 'WinCrap.pm' as well
as an XS file 'WinCrap.xs'. Also a 'Makefile.PL' and perhaps a 'typemap'
file. Of course I'd also need the small script (like above) to actually
run it. That's 4 or 5 files.
My point was that with Inline I have everything in one file. With XS
it's all over the place.
Inline creates/runs all that stuff behind the scenes for you. The only
'crummy' part is that you need to write this little wrapper, which has
different name than the original function. (Inline v0.30 lets you work
around the name changing with the PREFIX option) But I think that's OK
because it shows what you're doing right in your code. If this example
required custom typemapping, you would do it right in the wrapper,
instead of a (separate) typemap file.
Of course, if you wanted to expose *every* function in the user32
library and they all used the same typemaps over and over, this could
get cumbersome. That's one reason why I added support for external
typemap files in Inline 0.30. Now you can just say something like:
use Inline C => DATA =>
TYPEMAPS => '/my/own/windoze/typemap',
LIBS => '-luser32';
and Inline will let you use any of those new types in your function
definitions and invoke the proper mapping automatically. But you still
need to write the wrappers.
Hope this helps,
Brian
BTW Inline has obviously evolved since that article was written (in
August). Check out the latest doc, and the new Inline modules at
search.cpan.org.
> By the way, I noticed in TPJ that you are now at
> ActiveState. Does that you mean you live in
> Vancouver,
> or do you live in Seattle and commute? I live in
> Seattle and am just curious.
I moved from Seattle to Vancouver in September. I still go down to
Seattle for the Seattle Perl Users' Group monthly meetings when I can
make it. You should check them out: http://www.halcyon.com/spug/
>
> Thanks a lot--and thanks for writing Inline,
>
> Mike
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
