use Perl

I've recently worked a bit more on Perl bindings for OGRE. You might remember that I was working on this a couple years ago. I updated the bindings to minimally work with the Shoggoth (1.6) API (at least on Ubuntu). It still needs a lot of work.

My motivation is to make a sort of game framework. I think there are similar motivations for the recent revival of the SDL bindings. I recently added an example showing how to render Ogre into an SDL OpenGL context, at least on Linux (can be done in Windows too, but I didn't look at it yet). That allows you to write a normal SDL app, with keyboard/mouse input, sounds, and whatever else SDL does, but use Ogre to render 3-D graphics.

A couple years ago, I went to a talk by Guillaume Cottenceau on "the making of" Frozen Bubble at a Geneva.pm meeting. After that, I read a tutorial on "Developing games with Perl and SDL". I took several detours, but eventually got interested in Ogre instead of using SDL. The problem (or nice thing depending on how you look at it) is that Ogre is focussed on 3-D graphics and leaves you to do all the rest yourself. So I also made bindings for OIS, to get keyboard/mouse(/joystick/wiimote/etc.) input; a port of a simple GUI library, to let you make simple menus and GUI widgets; and a binding for OgreAL, which facilitates integrating OpenAL (sound/music) into 3-D scenes (so you have sound seeming to come from points in space).

In the back of my mind, I still would like to work on wrapping another GUI library, such as MyGUI or in my crazier moments CEGUI. I would like to automate more of the API-binding to make it easier to update for each release (have ExtUtils::XSpp in mind, for one thing, and also want to improve the use of GCC-XML) and to make the bindings more complete. I'd also like to get things compiling on Windows, especially after seeing how easily wxPerl compiled on Strawberry Perl this weekend.

This would be my comment at chromatic's book-promotion blog -- in particular in reply to Ovid's comment -- if I weren't required to sign in there.

Perl6 will be out soon, right? Why put MooseX::Declare in the Perl5 core?

Anyway, the module failed to install for me. I'll try to work out why, though at first glance... MooseX::Method::Signatures failed to install, and it required

    Context::Preserve [requires]
    Parse::Method::Signatures [requires]
    MooseX::Meta::TypeConstraint::ForceCoercion [requires]
    MooseX::Types::Structured [requires]
    aliased [requires]
    B::Hooks::EndOfScope [requires]
    MooseX::Types [requires]
    Devel::Declare [requires]

and of course Parse::Method::Signatures requires

    PPI [requires]
    MooseX::Types::Structured [requires]
    aliased [requires]
    MooseX::Traits [requires]
    namespace::clean [requires]
    MooseX::Types [requires]

and naturally PPI needs

    Test::Object [requires]
    Test::ClassAPI [requires]
    Test::SubCalls [requires]

and Test::SubCalls wants to have

    Hook::LexWrap [requires]

Maybe I'll see where the error is sometime soon. Oh, here we go again, MooseX::Types::Structured needs

    Sub::Exporter [requires]
    Devel::PartialDump [requires]

which I'm quite happy to install, yes, now namespace::clean would like

    B::Hooks::EndOfScope [requires]

and why shouldn't it since MooseX::Method::Signatures itself did, but it'll need

    Variable::Magic [requires]

which I thought I had installed already, but that must've been another machine. So now we're installing MooseX::Meta::TypeConstraint::ForceCoercion which couldn't live without

    namespace::autoclean [requires]

which needs a newer version of

    Class::MOP [requires]

which warns me that

***
    This version of Class::MOP conflicts with the version of
    Moose (0.69) you have installed.

    You will need to upgrade Moose after installing
    this version of Class::MOP.
***

Yes, yes, fine fine. But, oh no, finally a test failure in the version 0.01 module MooseX::Meta::TypeConstraint::ForceCoercion. I'll try to get back to you after I analyze the Moose / Class::MOP stacktrace explosion, but in the meantime, yeah sure, put that in the core. Thanks. ^.^

I've had this for a while in my Bio:

Scott Lanning has been nominally hacking Bricolage at the WHO in Geneva, Switzerland since 2003.

No more! After more than six years, as of yesterday I'm no longer at the WHO, although I might still nominally hack on Bricolage. I'm moving to Amsterdam to work at Booking.com.

UPDATE: You're right, I was taking it/things too seriously. $self->panic--

----cut-here---8<---------------------------------------------------

(Note: The following is just my humble opinion, and I don't mean to single out the authors of Perl6::Cookbook or Perl6::Doc. The Subject isn't worded too provocatively, is it? :> )

I don't think it's appropriate for modules like Perl6::Cookbook to go on CPAN. First, I don't think it's a good idea mixing Perl5 and Perl6 code on CPAN unless/until there are clear ways to distinguish them. By that, I don't mean that the module begins with Perl6, for example, but that the tools like the `cpan` shell are able to ignore Perl6 code (or compatibility issues are otherwise resolved). On the other hand, Perl6::Cookbook doesn't actually install code.

And that is my main problem; it is not a useable module. Its content is all under eg/, so it doesn't even install POD files. Now, several distributions have their own cookbooks (Moose, Jifty, ...), but that's different because they are actually documentation of the module, and we certainly don't want to discourage that. Some distributions even separate the docs from the code, like YAML::Manual, but again I don't think that's such a big deal (although that one in particular isn't nearly complete :) because it's associated to some module; it could be especially useful when those are optional dependencies of the code distribution.

So I think Perl6::Cookbook is problematic, at least as it's currently implemented, but there is another similar "module" that I'm not so sure about: Perl6::Doc. It contains the apocalypses, synopses, exigeses for Perl 6. I'm not sure that should be on CPAN, but on the other hand at least it installs POD files. Also, it's sort of like an informal RFC. But on the other hand, what use are they being on CPAN since they are already on the pages I linked to?

(Note: I considered uploading this blog entry to CPAN, but decided not to.)

Bricolage 1.10.6 was released. Might be the last one in the 1.10 series. David will probably release version 1.11.1 soon, which is a "developer release" for 2.0. He's been hacking on the ajaxy stuff recently.