blogs.perl.org

(As posted on dcbpw.org)

Attention Speakers! You are invited to submit talks for the 2014 DC-Baltimore Perl Workshop, which will be held on Saturday May 3, 2014, in Silver Spring, MD.

As in previous years, by default talks are 20-25 minutes, which we've found is a sweet spot for most topics. We get a great variety -- enough to get a dose of newness and not overwhelm. We also welcome proposals for more tutorial-style talks of around 50 minutes. We'll take the talks and build out a two-track schedule.

Speakers of all levels are welcome! This regional meetup is great for getting your first taste of giving a community talk, sharing projects or topics that you have experience with, or even doing a first run for a talk you'll be presenting at a larger conference such as YAPC::NA 2014 in Orlando! All Perl-related topics are welcome -- from beginner to advanced, from technical to social.

Well leaving off from my last post I was a little frustrated with Moose but not as much as our Moose friend below.

So after a good night of sleep and a large pot of coffee I stumbled on a Moose solution.

Seems some-one else must of had the same problem, some time before my entry into the Moose space, and a quick search of the MooseX namespace and I found 'MooseX::Role::BuildInstanceOf'* which looked to be what I wanted. So here we go

Well in my creator class I started from scratch again with

 package RPG::ADD::Creator;
 use Moose;
 with 'MooseX::Role::BuildInstanceOf' => {
		target => 'RPG::ADD::Creator::Strength',
		prefix => 'Strength',
 	        constructor => 'new',
               inherited_args  => [{roll=>'strength'}],};
 

and in the ability area I added in my delegation like this

has 'strength' =>(
        is           =>'rw',
        isa         =>'AbilityRoll',
);

And in my 'Strength' class I do this

package RPG::ADD::Creator::Strength;
  use Moose;
  has 'roll' =>(
        is    =>'rw',
  );

So then when I give this a try

I mentioned in my last post that I was hoping to be able to give a free public talk in London next month...and now I am happy to be able to confirm that's definitely going ahead.

When: Monday March 10, 7.00pm to 9.00pm
Where: Floor 3, 101 St Martin's Lane, London WC2N 4AZ
What: "A Few Of My Favorite Things"
How: To attend, you'll need to register beforehand

The evening is being sponsored by Venda and the venue provided by Mozilla.
Special thanks to Tom Hukins, who herded the many cats required to make the
event possible.

Damian

* Talking to my fellow Perl Mongers

Due to some family business this weekend, I haven’t had the opportunity to put my full attention into the next installment of my ever-growing series “Perl and Me”.  And I don’t want to do a half-ass job.  So we’ll return to our regularly-scheduled program next week.

In the meantime, if you’re interested in a rerun, I was just talking to a co-worker about my (much shorter) series on agile development over on my Other Blog.  Might be worth checking out, if you’re into that sort of thing.

In my last post I attempted to use 'Class' as roles to weed out Grot characters that can never be used in the game as a PC. In the end I took the advice found in JT Smith's recent post and abandoned that idea.

While I want my program to be flexible enough to allow new races and classes to be added easily. What I do know that there will always be just six 'Ability' rolls, so why not just use them.

I will have to change a number of things in my 'Creator' class as I will drop my 6 Abilities them as simple Int 'Attributes' and I will try to use a class for each that has a 'roll' attribute for the values and on the 'BUILD' of each of these new classes I can see if the present score qualifies in one of the 'Character Classes' as that is all I really need to know.

Over at ImperialViolet , there's an interesting argument observation on Apple's recent SSL/TLS bug in iOS. This is the code in question:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
	OSStatus        err;
	...

	if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
		goto fail;
	if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
		goto fail;
		goto fail;
	if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
		goto fail;
	...

fail:
	SSLFreeBuffer(&signedHashes);
	SSLFreeBuffer(&hashCtx);
	return err;
}

See that third goto fail ? The first two take advantage of the fact that in C, you can have a single statement following an if , or you can use a curly-brace-delimited block. That third goto , positioned as it is, becomes an unconditional branch.

So the SSL signature verification never happens - the session is happily accepted and off we go to who knows where. If the block syntax had been used, there would simply have been a second unreachable goto in the block (and if -Wall was on there'd have been a warning about that) - and there would have been no security bug!

I use R for data analysis. The power of perl is fascinating and I would ike to know if I can load the stata and csv datasets in perl and analyse them.
I have 64 bit 5.18.2 strawberry perl installed in my machine.

Any help.
Eagerly waiting.

Thanks in advance..

I created Constant::Export::Lazy a while ago to consolidate the main constant exporting module at work into something even better. I've just uploaded a major release which allows for adding all the features that I can reasonably think of being useful for a lazy constant exporting module.

It can now support something like Exporter.pm's %EXPORT_TAGS, along with numerous other improvements. I also toiled a bit at it with Devel::Cover and it has 100% test coverage now. In the progress of achieving that I found a few minor bugs that I fixed.

In implementing this module I tried to avoid adding narrow specific features (like %ENV overrides, or support for %EXPORT_TAGS), and instead added more general callbacks that make those features and others I haven't even thought of yet possible.

For why I needed to write the umpteenth constant creation module on the CPAN instead of using something that already exists see the rationale in the documentation.

This module's already been stable for a while and I see no reason why I'd introduce any breaking changes to it. If you'd like an easy-to-use constant defining module that you can use in multiple mutually incompatible environments give it a shot.