It seems that my never ending story of AD&D Moose posts are coming to an end. I have a good bunch of code written and things are working quite well. I did run into a slight problem. If you remember this post where I was adding in the available classes seems I let a cheat get in there.
If a user declares a class before adding in a race this is is possible to get race-character combinations that are not allowed, such as Dwarf Magic-User or Halfling Paladin.
Now I could go back and add in some more if then else logic in my BUILD but this is an easy way to add the required test with only a slight modification of my BUILD.
On my Class and Race attribute I can add in the 'predicate' method to both like this
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.
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.
I have been a Mojo::head for a few years now and I have heard alot a good things and bad things over the years. One thing that has always sort of seemed funny to me was the cliam that it taks less than 1 min to install.
Of couse you need a good connection and a fast computer. The are a numbe of demos of this out there and Glen Hinkle even did it live during an intro to Mojo talk.
So my mission tonight was to see if it really does install in a min.
Well Glen was wrong, It took almost 6 mins on my box. But my box is a 6 year old laptop with 2meg and only a 4.5 meg line so by any mesure this was actully fast INHO.
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.
Imagine this scenario: you ran a program to do some (potentially) long-running task. The program has a --verbose or --debug command-line option to print progress report to stdout and/or log file. This time you forgot to issue the command-line option and 10 minutes into it you wonder how the program is doing. You could start over by terminating the program and run it again. But it would be nice if we can get the running program to report its progress.
We can of course. One of the ways is to use Unix signals. We can use either SIGUSR1 or SIGUSR2, which are reserved for application purposes. Here's a sample program:
Sinan Ünür and I have started writing for O'Reilly Programming. I can't speak for Sinan, who has been doing more technically-oriented articles, but I'm taking suggestions for softer topics.
The story begins with me needing to install some new code on my production box. Well of course the dev and test environments where much more up to date in terms of perl and modules so my code had about 5+ dependencies to clean up. Never fun to do these sorts of fixes.
So out I whipped good old 'V' and just typed this
*
Good morning, this will be about GCL (my attempt to make WxPerl programming fun) and I want alsohear from you if its allright to talk about that at this stage of development on Perl Workshop (one month to go so a lot will change).
First of all, thank you to everyone who has joined gittip. So far we've put Perl into the top ten largest communities on the site and even passed the Ruby on Rails community. Keep it going!
Next, I've decided to upload a very strange module to the CPAN, one that may prove incomprehensible to most folks, but if it works, it might make working with DBIx::Class a bit more interesting (for curious values of 'interesting'). In short, it allows you to automatically create an object hierarchy of objects that delegate off to their DBIx::Class counterparts rather than inherit from DBIx::Class. That sounds weird, but let me explain.
One of the really fun aspects playing D&D was the plethora of spells that where available to the various player characters. To a programmer they introduce a whole nightmare of very vague rules that have to be implements some-how hopefully without an endless chain of it thens, given whens or, God help us, gotos or even gosub (yikes any one remember Applesoft BASIC basic?)
Because spellcasting is such a mine-field of subtle rules or at least rules that could never be applied in a game. For example the wish spell, In real game play a player could wish for, well almost anything, How would you do that in a computer game? The few times I have seen it in a game there was always a list of things you could choose from to happen.
So game designers usually opt for a more simplified spell system where the spells can be more closely codified. Usually blast this, heal that, protect this, or find that.
Perl 5.19.9 was released today, and it includes some exciting new features like subroutine signatures, and postfix dereferencing.
The 5.19.X line also includes a number of optimisations that I'd like to discuss briefly, without going into too much detail (I hope).
Combined and/or operators in void context
The first improvement was added back in 5.19.6, and effects and and or operators in void context. It improves the short-cirtcuiting logic of and/or operations when inside of an if statement.
What this means is that in many cases, this:
if ($var1 || $var2) { ... }
will be ever-so-slightly faster if $var1 is true than it used to, and
unless ($var1 && $var2) { ... }
will be ever-so-slightly faster if $var1 is false. This is about a 2% speed improvement in my tests, for each of the above constructs being evaluated.
Want to make some money writing a tutorial on what you can do with Perl?
Then head over to Digital Ocean and submit your Perl tutorial. Digital Ocean provides Cloud servers for as low as $5 bucks a month. Digital Ocean will pay $50.00 for each artcle that has been accepted ( you can get the $50 in DigitalOcean credit or through paypal ) .
In my on going effort to provide Perl interfaces to lots of web services, I’m pleased to announce Chat::iFly. Using this module you can integrate iflychat.com (a web chat service) into your web site with relative ease.
Well I must say MooseX has helped me out again today, You might remember way back to the very first post of this AD&D series I mentioned that I would need all sorts of flavors for the values of my Character Abilities, ie tombstone, present values, magically enhanced values etc.
Well as I was programming along and setting up some playing parts of the game I was continually having to make calls back to the persistence layer (if you can call a YAML file that) for the starting value of an attribute for the current gaming session.
Then while playing with MAP of CPAN(you can tell I really like that site) I found what I think is a solution to this little problem MooseX::BuildArgs
This nifty little gem keeps your build arguments around for you in case you need them.
All I need to do is this
The main UAV::Pilot distro was getting too big. The WumpusRover server had already been spun off into its own distribution, and now the same is happening for many other portions of the system.
Reasons:
UAV::Pilot hasn't been passing CPAN smoke testing because of the ffmpeg dependency. Splitting that off means the main distro can still be tested.
There's no reason to get the WumpusRover stuff if you just want to play with the AR.Drone
General aim towards making UAV::Pilot into the DBI of Drones
UAV::Pilot itself will contain all the basic roles used to build UAV clients and servers, as well as what video handling we can do in pure Perl.
UAV::Pilot::Video::Ffmpeg will have the non-pure Perl video decoding.
UAV::Pilot::SDL will take the current SDL handling, such as for joysticks and video display.
UAV::Pilot::ARDrone and UAV::Pilot::WumpusRover will take the client end of things for thier respective drones.
I expect the first release to have interdependency issues. I've tested things out on a clean install, but I still might have missed something. I'm going to be watching the CPAN smoke test reports closely and filling in fixes as they come.
I didn't want to write this, but couldn't find any existing cli tool on CPAN or Debian. Since I put reminders on my ~/.bash_profile and I open many many terminals in a day, I needed a way to run some scripts just once a day. It's surprising that I couldn't find a tool to let me do it easily, and I hope someone can correct me on this.