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.
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.
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).
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
*
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.
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.
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.
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.
In my last AD&D post I was playing with MooseX::SetOnce 'trait' on some of my attributes in order to stop modification after the initial set.
This worked fine for the first few runs but quite quickly I had to add in all sorts of code to set default values stuff like this
my $hps=$character->current_hps()||0
So my code was quickly becoming messy and it was much easier to work when I had default values to work with first. So what I really want is set 'default' and then 'set once' and then 'read only' 'trait'.
Well now that I am getting quite confident with 'Moose' I decided why not discombobulate 'SetOnce' and see if I could make it do what I want.
I've been experimenting with something in the interviews I've been doing most recently. Turns out it works quite well, so I'm sharing this in the hope that it will help you as much as it has me.
One of the most important things on a software team is code reading comprehension and communication: the ability to read code, whether yours or someone else's, and walk through it, explaining to someone else what it does. Sometimes you'll be reading your code and explaining it to someone else; sometimes you'll be reading someone else's code and explaining it to yourself, sometimes you'll be looking at something brand-new to everyone and trying to puzzle it out.
Unit testing and continuous integration testing are ways to make sure that every change to our code won't break stuffs. We execute our tests after each commit and when we want to release our software.
On the other side of the spectrum, there are things outside our code that change and break our non-changing code. Platforms (like new versions of Perl) and dependencies, for example. Integration testing and CPAN Testers are some of the ways to make sure that dependencies and different versions of Perl still work with our software. We must do this testing regularly even when we're not changing our code, since the changing part is the other party.
There is a specific class of scenarios along this end of the spectrum when we're developing scraping libraries and API clients: source websites and API services change all the time, breaking our otherwise working code. For lack of a better term, I'm going to call this third party testing.