Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

doubi (9222)

doubi
  (email not shown publicly)
+ -

  Journal: Ctypes update: pretty objects on 2010.08.08 22:24

Journal by doubi on 2010.08.08 22:24
User Journal

Since my last couple of posts, things have been done:

  • Complete revamping of call logic
  • Finished objects for basic C Types (int, double etc.)
  • A fairly sound cast() function for Ctypes
  • Array objects
Read More 0 comments

+ -

  Journal: Following convention across language boundaries on 2010.07.20 13:10

Journal by doubi on 2010.07.20 13:10
User Journal

I've been meaning to write this post for a while. I'd like your opinion on it.

Read More 0 comments

+ -

  Journal: Thoughts on a Ctypes::Type object API on 2010.07.20 13:04

Journal by doubi on 2010.07.20 13:04
User Journal

For the past few days I've been considering and experimenting with the design of simple Ctypes::Type objects. These are objects which, funnily enough, represent C data types for manipulation in Perl.

The reference implementation

Looking at the Python ctypes module, there were various things I didn't like. Python's simple types [0] can be summarized thusly:

Read More 0 comments

+ -

  Journal: Callbacks done, weird 64bit libffi issue? on 2010.07.15 23:30

Journal by doubi on 2010.07.15 23:30
User Journal

The week has been frustrating, funny, yet ultimately fruitful.

Research, enhancing C function signatures

Read More 0 comments

+ -

  Journal: GSoC Update: New objects, Perl callbacks on 2010.07.03 2:34

Journal by doubi on 2010.07.03 2:34
Tools

July already - where has the time gone? Oh wait, Twitter can tell me.

Types, Functions and something of a roadmap

Read More 0 comments

+ -

  Comment: Re:PerlC array conversions (Score 1) on 2010.06.13 2:26

by doubi on 2010.06.13 2:26 (#72050)
Attached to: Magic: too powerful?
Cool! Thanks tsee :)
Read More 3 comments
Comments: 3
+ -

  Journal: Magic: too powerful? on 2010.06.12 17:38

Journal by doubi on 2010.06.12 17:38
User Journal
To shazam, or not to shazam

I'm currently at the stage of reading the Python docs and considering what I'll have to keep track of as regards C type objects, and how to do so. The Python ctypes code is delightfully well documented, particularly this nugget. The Ruby and JS projects unfortunately seem to be entirely lacking in any documentation of their internal functioning, but I think I've got enough to wor

Read More 3 comments
Comments: 3
+ -

  Journal: ffi_call( 'Wolf!' ) on 2010.06.04 19:07

Journal by doubi on 2010.06.04 19:07
User Journal
False positive

I was pretty excited today because I thought I had my interface for ffi_call working on Linux, and told Twitter and the #soc-help channel all about it. It did seem to be working, until I changed a slight detail in my test script and it became apparent that either there was bewitchery afoot, or I need to read perlxs / perlguts more and it was random change that it hadn't blown up in the first place. I think I'm nearly there though. Next step will be fleshing out the OO fu

Read More 0 comments

+ -

  Comment: Re:Name change (Score 1) on 2010.05.24 19:29

by doubi on 2010.05.24 19:29 (#72004)
Attached to: Ctypes for Perl: Intro and API spec

Another reason not to use "ptypes" - you're not replacing the C with Perl, you're replacing the Python with Perl.

Granted. In my head, it was meant to be some kind of weird pun. I don't think it worked :F

some pig should be backed.

As they say, when the world gives you pigs, all you can do is back.

Do you envision any special-purpose stuff for creating wrapper modules? One thing that's been fairly clear in the Inline::C world is that the needs of people writing wrapper modules & people writing little scripts that call libraries are pretty different.

If it's not useful for fully wrapping libs, I will consider it a bit of a failure. As you say, there are already a few modules on CPAN you could probably coerce into working for you for the purposes of tinkering, so I do want to go well beyond that.

Read More 6 comments
Comments: 6
+ -

  Comment: Re:Steal their brand (Score 1) on 2010.05.24 19:19

by doubi on 2010.05.24 19:19 (#72003)
Attached to: Ctypes for Perl: Intro and API spec
Good point about the branding.

Also, in the effort of articulating why I was never keen on the Python API, it's just 'clicked' with me. Thanks for that ;)

I take it you can't just simply ask for 'libc' on *nix 'cause you might have several libc.so.x lying around.

Why is that? Could there be a way to mitigate for it? I do like the ol' automatic accessor style: cdll->libc->function('arg').

If that wasn't available cross platform I wouldn't even bother making it an optional syntax for Windows.
Read More 6 comments
Comments: 6
+ -

  Ctypes for Perl: Intro and API spec on 2010.05.20 22:10 doubi

Submitted by doubi on 2010.05.20 22:10
User Journal
Hello, good evening and welcome.

For the next few months I will be using this blog to help document and publicise my "Ctypes for Perl" project. The project is being carried out for TPF under the auspices of the Google Summer of Code programme, and mentored by Reini Urban.

What's a ctypes?

'ctypes' is the Foreign Function Interface (FFI) library distributed with the Python core. It basically allows native C libraries to be called easily from Python; for module authors, it allows the wrapping of C libraries in pure Python.

This is obviously a powerful concept. Imagine a world where Perl module authors didn't need to use XS, and module consumers don't need to have a correctly configured compiler set up on their system. This is the purpose of the project: to create an easy, cross-platform, pure-Perl interface to native C libraries.

Implementations

ctypes is based on libffi. It's small, supports a wide range of systems, and has a very liberal license. It's been distributed with GCC for a number of years, used by gcj for interfacing between interpreted and compiled code.

From what I can gather, Python set the trend in dynamic languages using libffi. Looking at the success of the Python module, developers at Mozilla chose libffi to develop ctypes.jsm. Ruby-FFI uses it too, so there's plenty of prior art which will hopefully help me out.

The FFI problem hasn't been ignored in the Perl world. There's FFI.pm, the biggest disadvantage of which in my view is being built on libffcall, a library analogous to libffi but under the GPL (I don't think libffi was around at the time FFI.pm was written). It also sets out to provide a 'low-level' interface. P5NCI, on the other hand, is all about the lovely interfaces, but only allows up to four arguments passed to C functions, and doesn't yet support passing in pointers. C::Dynalib provides similar functionality to the other two modules; click here for the latest updates on its development. It's worth pointing out that none of these modules worked out of the box on Strawberry 5.10.1.

My proposed API rolls in features of several of the above implementations, particularly P5NCI and FFI.pm. I have indeed copied and pasted swathes from their POD pages (So what? Wanna fight about it?). I plan to also mimic C::DynaLib's acceptance of both positional & named parameters; examples are omitted below for succinctness.

1. Functional

use Ptypes;
# FFI.pm's interface of Absolute Freedom...
my $addr = (address of a C function)
my $signature = (function signature)
my $ret = Ptypes::call($addr, $signature, ...);

# Keeping things where you can see them...
my $library_path = Ptypes::find_lib( 'mathtastic' );
my $library = Ptypes::load_lib( $library_path );
my $double_func = Ptypes::load_func( $library, 'double_double', 'dd' );
my $ret = $double_func->( 1.0 );

# Supplying a Perl callback...
$ret = Ptypes::call($addr, $signature, $subref, ...)

2. Objectionable

use Ptypes;
my $lib = Ptypes->new( library => 'mathtastic' [, package => 'MyPackage' ] );
my $double_func = $lib->load_function( 'double_double', 'dd' );
my $ret = $double_func->( 1.0 );

# Exposing funcs directly in Perl namespaces...
$lib->install_function( 'double_int', 'ii' [, 'perl_sub_name', 'AnotherPackage' ] );
my $ret = AnotherPackage::double_int( 1 );

# or simply...
package AnotherPackage;
my $ret = double_int( 3 );

All fairly self-explanatory, perhaps apart from arguments like 'ii' or 'dd' - these strings describe return values and arguments for C functions in the same notation used by pack. In addition to the above, the module may provide mechanisms for manipulating C data types directly from Perl ($c = new Ptypes::char). To start off with though there'll be a fairly straight-forward / 'stupid' translation based on seeing what kind of data's in your SV*, for initial experimentation.

There's also some exciting stuff to do with GCC::TranslationUnit to tell you about, but details of that will wait till later. For now, I have some questions for you, the community:

  • How d'you like the API proposal above? Anything you'd add? Take out?
  • How does 'Ptypes' take you as a name for this malarky? Y'know, like ctypes, but for Perl. 'FFI' is already taken after all...

Don't want to gush here, but I'm so chuffed* to be working on this. I'm already learning loads, and I think it will save a lot of blood, sweat & tears for module authors and users in the future. I want to thank rurban for his guidance & help so far, and dukeleto and others for organising the The Perl Foundation's participation in GSoC and letting me participate!

I like to work log, so follow @doubious_code on Twitter to get far more information than you want about this project. I hope to be blogging pretty regularly too.

* For American-speakers, 'chuffed' is kinda equivalent to 'stoked'

Read More 0 comments

+ -

  Journal: Ctypes for Perl: Intro and API spec on 2010.05.20 22:10

Journal by doubi on 2010.05.20 22:10
User Journal

Hello, good evening and welcome.

For the next few months I will be using this blog to help document and publicise my "Ctypes for Perl" project. The project is being carried out for TPF under the auspices of the Google Summer of Code programme, and mentored by Reini Urban.

What's a ctypes?

Read More 6 comments
Comments: 6
+ -

  Journal: XS debugging and "holding out for the pretty one" on 2009.08.19 18:19

Journal by doubi on 2009.08.19 18:19
User Journal
In the last couple of days I used gdb a little for the first time as a result of looking around a bit for information on debugging XS, some of which I want to share here.

First is this journal entry by Shlomi Fish where he gives some useful settings for debugging an XS function with gdb.

Read More 0 comments

+ -

  Comment: Publishers / extent of restriction (Score 1) on 2009.08.17 13:07

by doubi on 2009.08.17 13:07 (#70114)
Attached to: LaTeX, the Humanities, and PDF commenting

In my experience at least, the most important thing would be to get JSTOR, Sage, Oxbridge Journals etc. supplying journal articles in something other than PDF, as our departments didn't actually produce digital material themselves. How you'd even start to move publishers like that though, I don't know.

"In order to comment using the free Adobe Reader application, the document needs to be signed with a cryptographic key only available from Adobe's commercial (non-free, for-pay) software suites. Likewise, if one is using Adobe Acrobat (not the free Reader) to view a PDF document, commenting may be activated -- or so I hear. The idea here is that it takes some piece of commercial Adobe software in the scenario -- be it producer or consumer -- to make commenting possible.

There are other free PDF producer and consumer applications that allow some form of annotation, but none of them are equivalent to the "native" form offered by Adobe's products."

To my reading of that stackoverflow comment, the crypto key is "only" necessary for allowing Adobe Reader to edit/add comments (it is able to view them). It's not required for other applications to make them. Is that wrong?

Read More 6 comments
Comments: 6
+ -

  Journal: Wx::WebKit new git repo on 2009.08.15 9:08

Journal by doubi on 2009.08.15 9:08
Module News

Finally got round to making Wx::WebKit available in proper source control:

http://gitorious.org/wx-perl-webkit

General feedback or clues about the issues I mentioned in my last post (missing SetFocus method, inability to change package name) would be equally welcomed :-)

Read More 0 comments