Wednesday 27 April 2011

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.

Thursday 21 April 2011

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

Tuesday 19 April 2011

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

Sunday 10 April 2011

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