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 ]

slanning (5049)

slanning
  (email not shown publicly)
http://search.cpan.org/~slanning/

Scott Lanning is currently working in Amsterdam at a hotel-booking company. The following interviews and commentaries are for entertainment only. The views and opinions expressed therein do not necessarily represent the views of his employer or even himself.

Journal of slanning (5049)

Thursday March 25, 2010
05:09 PM

pearls cheaper than Perl?

According to http://news.discovery.com/tech/artificial-mother-of-pearl.html, the material that makes up pearls can now be made as cheaply as paper. So, the cost of producing Perl is more than producing pearl. (Okay, it probably was even before, but I had to make a pun. I'm sorry...)
Monday October 05, 2009
02:09 AM

OGRE

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.

Sunday May 03, 2009
04:01 AM

concision

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. ^.^

Saturday April 25, 2009
11:06 AM

moving to Amsterdam

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.

Thursday March 12, 2009
12:59 PM

Bricolage 1.10.7 released

Bricolage 1.10.7 has been uploaded to the world-wide web. The distribution tarball can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=34789&package_id=177005 or http://bricolage.cc/downloads/ .
Tuesday January 27, 2009
07:48 AM

PerlIO spreadsheet2csv

I haven't got it ready for CPAN yet, but I've recently been working on PerlIO::via::Spreadsheet (I don't like the name, but what else could I call it?). It should let you do this:

open my $fh, '<:via(Spreadsheet)', 'file.xls' or die "Couldn't open file.xls: $!";
while (<$fh>) {
    # spreadsheet emulated as an input stream is translated to CSV
    # $_ is a line of CSV;   (note: for a few minutes this was wrong, updated)
    ...
}

The spreadsheet would be whatever Spreadsheet::Read can deal with. Probably more a "neat to hack on" thing than something actually useful. (There are xls2csv utilities already. There are also problems with more complicated spreadsheets that aren't easily handled by a simple IO layer.)

Another idea I'm playing with is a layer to handle JSON.
Thursday January 22, 2009
06:10 AM

ok, Perl6:: docs might as well be on CPAN (updated)

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.)

Thursday November 27, 2008
09:31 AM

$1.5 trillion stolen

Am I misunderstanding something, or have the US banks stolen $1.5 trillion in US tax money in the past month or two? It's not the first time this has happened, either. They kept on deregulating away, and now we get to hear how the bailouts will save the economy.
Thursday October 02, 2008
09:09 AM

Bricolage 1.10.6 released

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.

Friday September 05, 2008
04:27 AM

school text books

There's a boycott in Chicago by school children from urban schools. In the first paragraph it's mentioned that "they often have to share books ... meaning they can't take books home to study". At the bottom they talk about spending $120 million over three years to build more schools. Just for Chicago. We have the web now, even in the USA. Why can't money like that be invested in more fundamental improvements that would benefit everybody, like building free, public-domain, online textbooks? At least at the state level. It's like schools are letting textbook publishers steal money from children.