• Implement perlxs function macro - allows for additional flexibility in argument unpacking, and more idiomatic function authoring
• Reorganize subcrates to be more tidy
• Update test cases to use new perlxs function macro

This PR replaces #21

Known issue: If arguments are unpacked, AND context object is desired, the &mut Context must be the final argument of the subroutine, otherwise it will experience a double mutable borrow. Does the context object need to be mutable, or does it utilize interior mutability?

First swing at FromPerlKV derive. Tests passing: https://travis-ci.org/dnorman/perl-xs/builds/301790192

I'm pretty inexperienced with proc_macros, so I'm sure there's lots of ways this can be improved. Additionally, I couldn't figure out how to each over HV contents, so hashrefs are currently unhandled.

Option on the struct is handled differently versus T. The end goal here is to loosely reproduce the behavior of a moose constructor. Feedback and improvements greatly welcomed.

#[derive(FromPerlKV)]
struct Test {
    foo: Option<String>,
    bar: String,
    #[perlxs(key = "-meow")]
    meow: bool
};

xs! {
    package Test;

    sub new(ctx, class: String) {
        println!("new {:?}", class);
        let test = Test::from_perl_kv(&mut ctx, 1); # offset to avoid $_[0]
    }
}

...
Test->new( bar => "Something", -meow => 1 ) #does not error for missing foo

• Reorganize existing subcrates in the style of the wasm_bindgen subcrate layout (which seems to be the new hotness) in preparation for the introduction of additional subcrates for #[perlxs] function attribute macro.

• Relicense subcrates to match current best-practice: dual-license MIT/Apache-2.0

• update main perl-xs crate to export macros without having to directly use the subcrate

^_^

Added travisci config and build status badge. In theory all of the environment setup is working for each combination of perl and rust version.

The build still not succeeding at this time, but at least it's failing with the same error under travis (debian) now as it is on my local OSX machine. This implies that there is some bug, or setup step/dependency which I did not understand.

See here for details: https://travis-ci.org/dnorman/perl-xs/jobs/282089474#L517

Debian stretch ships with perl version 5.24, and would be helpful to include it (plus 5.26 for giggles) in the CI testing. Does this seem reasonable? I don't see any need to restore testing for 5.*-shrplib, but these would be helpful :)

vickenty/perl-xs now has a Chat Room on Gitter

@vickenty has just created a chat room. You can visit it here: https://gitter.im/vickenty/perl-xs.

This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.

Happy chatting.

PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

perlxs_derive included dependency on perl_xs, which, on later versions of rustc caused the compiled proc macro library to require perl's symbols. Since the proc macro is loaded by the rustc and not perl, these symbols could not be resolved and compilation failed.

Fix the problem by removing the unnecessary import.

Rust programs will print a message to standard output every time a panic happens in a program. We use panics to propagate perl croaks through rust part of the stack - this is internal detail and the messages produced are not useful to the user. These messages can be disabled by installing a custom panic handler.

Should it be installed globally from a module bootstrap routine, or locally every time a sub is called?

Objectives:

1. Export functions to perl which contain optional arguments.
2. Make argument handling more magical
3. Move toward more idiomatic rust conventions for function binding

At present, the xs! macro is unable to handle Option arguments which may be omitted by the perl caller.

I propose that we do away with the xs! macro_rules in favor of a procedural function attribute macro, similar to wasm_bindgen or the pyo3 crate.

Proposed syntax:

//lib.rs:
mod bar;
mod blah;
perl_base_module!("Foo")

//bar.rs
#[perl]
fn alpha (maybe: Option<Something>){}

//blah.rs
#[perl]
fn beta (definitely: Something){}

By doing this as a procedural macro, this will also improve the ability to perform smarter argument handling / coercion, including derive structs, optional context argument, etc.

The goal here is to have a perfectly ordinary rust function be callable from within perl with little or no special accommodation for the perl guts, at least in some circumstances.

There are four functions to call into Perl in XS, of which only one is currently supported.

• [ ] I32 call_sv(SV* sv, I32 flags);
• [x] I32 call_pv(char *subname, I32 flags);
• [ ] I32 call_method(char *methname, I32 flags);
• [ ] I32 call_argv(char *subname, I32 flags, char **argv);

What would be the best way to represent different combinations of flags? Some of them are mutually exclusive, others depend on other flags.

A further improvement can be a macro that hides different ways to call a sub, and handles argument passing, something like:

call!(ctx, sub_sv, a, b, c);
call!(ctx, "Foo::name", a, b, c);
call!(ctx, sv->"name", a, b, c);
call!(ctx, sv->method_sv, a, b, c);

Allow blessing Rust values into Perl objects.

Allocate struct on the heap. Construct a SV with a pointer. Register destructor in the SV's magic table.

It might be possible to safely borrow string buffer of an SV if it is uniquely owned - reference count is 1 and there are no weak references. At least newly created SVs should allow this.