nice example of a helping community in CPAN

Reading today the Catalyst mailing list I felt a great satisfaction. I saw how having the right attitude, asking the right questions, listening to people, doing your homework and reporting to CPAN authors sometimes gives you satisfactory results.

All happened in this thread:

[Catalyst] building 'local' lib with dependencies for shipping
where Fernan Aguero asked how to pack a catalyst application with all the needed dependencies. The problem is that if you want to do it platform independent you need to do it by setting list of dependencies (and your current versions of modules) and and use a method to automatically install all of them.

One of the solutions was to use Shipwright, created by Best Practical. It didn't work the first run but seemed the right tool so after a few messages more in the list, Fernan contacted with one of the developers and:

[Fernan]

I contacted sunnavy (one of the Shripwright developers) and this is
what he said:

"I found the archive( PerlMagick ) has an interesting files format, which
shipwright didn't handle before.

I just released 2.4.25 to fix this, which will show up in cpan soon.
in case you are hurry, here it is: http://goo.gl/6Jtzz";

Just tested 2.4.25 and shripwright now imported all of the
dependencies for my cat app correctly.

I'm now building my ship :) and will get into testing the catalyst app
running from the vessel soon.

It is nice to see that collaboration works in the Perl world.

converting ANSI to HTML. How to convert to html the colored shell output

The main aim of this was able to put in html the ouptut of git log and diff.

Googling around I have found that Perl CPAN has the HTML::FromANSI module. Also, this module installs ansi2html which accepts input from stdin.  

ls --color | ansi2html -p > my_web_page.html

ls --color | ansi2html > my_snpipet_code-no_header-footer.html

But I prefer the default output from ansi2html.sh from pixelbeat

 

Unfortunately the ls --color get properly converted to HTML but the git one not. No matter which script I use. Could it be bacause the color is defined in the config as color.ui=auto?

git diff HEAD master -- ensembl/sql/CVS/Tag | ansi2html -p  > ~/public_html/htdocs_dev/diff1.html

git diff HEAD master -- ensembl/sql/CVS/Tag | ansi2html.sh --bg=dark  > ~/public_html/htdocs_dev/diff2.html

[UPDATE]
Yes! the problem would be that I have in the configuration color.ui=auto because explicitly having --color in the command make it work:

$ git diff --color HEAD master -- ensembl/sql/CVS/Tag | ansi2html.sh --bg=dark > ~/public_html/htdocs_dev/diff3.html

new R-pkg version: R 2.13.0

The new R 2.13 is out and contains the package 'compiler'

o Package compiler is now provided as a standard package.  See
      ?compiler::compile for information on how to use the compiler.
      This package implements a byte code compiler for R: by default
      the compiler is not used in this release.  See the 'R
      Installation and Administration Manual' for how to compile the
      base and recommended packages.

See this page for benchmarking on the use of 'compiler' and it also show how the syntax that you use could affect the efficiency of your code! interesting!

This is like the perl /o option in regular expressions,  you compile your function and from now on it run much faster

  > library(compiler)
  > lf <- cmpfun(f)

Some links with tricks for updating your installed modules

Windows
http://www.r-statistics.com/2011/04/how-to-upgrade-r-on-windows-7/
http://stackoverflow.com/questions/1401904/painless-way-to-install-a-new-version-of-r
Linux

http://nsaunders.wordpress.com/2011/04/15/r-2-12-to-2-13-package-upgrade/



Mac
http://onertipaday.blogspot.com/2008/10/r-upgrade-on-mac-os-x-1055-leopard.html

git branching model

This is a nice article about git branching model
http://nvie.com/posts/a-successful-git-branching-model/

A Sampling of Linux Desktops/Window Managers

Copied from Linux Journal

The Second-String Desktop

Mar 31, 2011  By Shawn Powers

http://www.linuxjournal.com/article/10946?page=0,2

Table 1. A Sampling of Linux Desktops/Window Managers

Desktop/Window Manager	Description	Design Goals	Based On	Advantages	Disadvantages
KDE	Full desktop environment	Full system integration, including applications	Uses KWin window manager and Qt libraries	Great application integration, highly customizable	Distinct look; non-KDE apps often seem awkward
GNOME	Full desktop environment	Full system integration, including applications	Uses Metacity window manager, based on GTK+ libraries	Wide variety of native applications, wide adoption in corporate environments	Non-GTK apps often look odd and use more RAM
LXDE	Lightweight desktop environment	Speed and beautiful interface	Uses Openbox window manager and GTK+ libraries	Works well on older/slower hardware, maintains compatibility	Lacks some of the features found in GNOME or KDE
XFCE	Lightweight desktop environment	Full-featured desktop environment, but light on resources	Usually uses XFWM4, but works well with other window managers	Somewhat lower system requirements than GNOME or KDE	Possibly a bit too resource-hungry for low-end systems
Enlightenment E17	Window manager with the features of a desktop manager	Speed and eye candy with integrated functionality	A window manager plus a set of libraries for developing apps	Fast without sacrificing style	Still in beta but quite stable
ROX Desktop	Desktop manager based on the ROX-Filer	Approaches the OS in a file-centric way	ROX-Filer file manager and the OroboBox window manager	Unique file-based design makes installing apps drag and drop	ROX Desktop is either a love or hate affair
IceWM	Hybrid window manager and desktop manager	Speed and simplicity	Simple menu and taskbar design	Fast and easy to make system-wide configuration changes	No way to make desktop icons, requires additional software for some features
Blackbox/Fluxbox	Very minimalistic window managers	Speed and small memory/CPU footprint	Fluxbox is based on Blackbox (it's a fork)	Blazingly fast	Very limited in features, but by design not immaturity
Openbox	Very minimalistic window manager	Speed and small memory/CPU footprint	Originally based on Blackbox, original code since version 3.0	Simple and fast	Limited in features by design
AfterStep/Window Maker	Clones of the NeXTSTEP interface	Functions and looks like NeXTSTEP	Designed after the unique design of the NeXTSTEP interface	Unique	Often difficult to configure, and the interface is an acquired taste
Ratpoison	A window manager that doesn't require a mouse	Kills the need for a mouse	Designed after GNU Screen	No need for a mouse	Very limited in features, which the developers consider a feature
DWM	An extremely minimalist window manager	Manages windows and nothing more	The ideas of other minimalist window managers	Small and fast	No configuration files, must edit source code to coconfigure

Resources

AfterStep: www.afterstep.org
Blackbox: blackboxwm.sourceforge.net
CrunchBang Linux: www.crunchbanglinux.org
DWM: dwm.suckless.org
Elive: www.elivecd.org
Enlightenment E17: www.enlightenment.org
Fluxbox: www.fluxbox.org
GNOME: www.gnome.org
IceWM: www.icewm.org
KDE: www.kde.org
Lubuntu: www.lubuntu.net
LXDE: www.lxde.org
Macbuntu: macbuntu.sourceforge.net
Openbox: www.openbox.org
Puppy Linux: www.puppylinux.org
Ratpoison: www.nongnu.org/ratpoison
ROX Desktop: roscidus.com/desktop
Ubuntu: www.ubuntu.com
Window Maker: www.windowmaker.org
XFCE: www.xfce.org
Xubuntu: www.xubuntu.org