Code and Hacks

Stuff I've stumbled on or figured out... mostly Perl, Linux, Mac and Cygwin.

My Photo
Name:
Location: CA, United States

Perl hacker, investor and entrepreneur.

Monday, April 12, 2010

Setting the Terminal Title in Gnu Screen

I often have multiple terminals open and screen running in each one. I then try to group all my work for a particular project in that terminal. While I am trying to limit the amount of multitasking and concentrate on one thing at a time, I might leave a terminal/screen session up for days and when I come back I can jump right back where I started.

The downside to this is using cmd-tab (or alt-tab with Witch) gives me a list of several terminals each with the title screen - bash - username or maybe screen - vim - username… not very helpful. What I want is to set a name for each terminal and display it in the terminal’s title. If I anticipate this before launching screen, I can accomplish it with screen -t <My Title>. Once I am inside a session though, you need to change each window’s title/name for this to work.

After searching the web and a bunch of trial-and-error, I found a solution. The first part is pretty well documented. Changing the name for all windows and the default for new windows took quite a bit a tinkering.

  1. Setup screen (via .screenrc) to update your terminals title bar and include the name of the current window.

    # Add to .screenrc
    termcapinfo xterm* 'hs:ts=\E]0;:fs=\007:ds=\E]0;\007'
    defhstatus "screen ^E (^Et) | $USER@^EH"
    hardstatus off

    The escape string ^Et in the defhstatus is converted into the current window’s name/title.

  2. Create a function to update the name of each screen window.

    # Add to .bashrc
    # Set the title of a Terminal window
    function settitle() {
     if [ -n "$STY" ] ; then         # We are in a screen session
      echo "Setting screen titles to $@"
      printf "\033k%s\033\\" "$@"
      screen -X eval "at \\# title $@" "shelltitle $@"
     else
      printf "\033]0;%s\007" "$@"
     fi
    }

    You can change the name of the current window by pressing Ctrl-a A, but we want to change the title for all the windows. screen -X eval will execute each of its arguments in the current screen. The command at \# title will execute the title command in all the windows (the \ before # is required otherwise # will be interpreted as the beginning of a comment). The shelltitle command will ensure that any newly created windows use this title.

Labels:

Friday, April 2, 2010

Open Source Presentation Software

I am thinking about giving a presentation at one of my local Perl Monger meetings. So as usual, I have spent a bunch of time toying with new tools rather than getting work done! Which tools: open source presentation creation software. I wanted something that would take a simple text file and easily create an attractive and easy to use presentation.

Here is a quick summary of the options that I tried or looked into:

  • Vroom::Vroom - This is cool. If you like vim and aren’t hung up on the output format it might be for you. I had some trouble getting the key-bindings to work, but I would guess it was a conflict with another vim plugin.

    Vroom can present right in vim or output to html. Both are pretty plain looking, but I didn’t look into customizing the html output. I love that you can press RR and run the code on the slide. The input is a custom format but it is pretty similar to markdown.

  • Pod::S5 - I really wanted to like this one–it is written in Perl, uses a standard method input format, and it creates an HTML presentation. But I was hung up on a couple of things. While pod is great, it isn’t nearly as easy to use as markdown, and the text slides just aren’t that easy to read. Things like lists just take up too much room:

    =over 4
    
    =item *
    
    A Bullet
    
    =item *
    
    Another Bullet
    
    =back

    That’s just too much vertical whitespace.

    Second, the output is S5 which has been superseded by S6. The templates in S5 didn’t really appeal to me and had some issues in my browser.

  • Spork / Spork::S5 - I had some trouble installing this, but eventually realized I just needed to install Kwiki::Cache first. The default themes are not particularly attractive, but again I didn’t look into customizing the output. I do like that it automatically scales text. The ability to highlight sections of the text/code with underlining or colors sounds very cool. For example, this markup:

    .pretty.
     sub greet {
      print "Hello there\n";
    #             _______________
    #              RRRRR
     }    
    .pretty.

    Should underline and make “Hello there” red. I didn’t test this, but according to the documentation it is “coming soon”.

  • Slide Show (S9) - I ended up settling on Slide Show. While I was biased toward a Perl solution, and this is written in Ruby, it definitely seemed the most mature and robust solution. (Maybe I’ll end up learning a bit of Ruby as a side benefit.)

    Slide show can take either textile or markdown as input, it outputs S5 or S6, and has some nice (and simple) templates bundled. It will use any one of a number of markdown parsers so I am using Maruku which has some nice additions to the core markdown syntax (ie, add a css class declaration to an element).

    Installation was easy (once I googled for one error message):

    gem install slideshow
    gem install ultraviolet
    # got error: oniguruma.h: No such file or directory
    port install oniguruma
    gem install ultraviolet

    Slide show also handles syntax highlighting for your code and can import external files into the presentation.

    # Import a file
    <%= include 'help.txt' %>
    # Highlight and import code
    <% code 'test.pl', :lang => 'perl' %> 
    # Highlight inline code
    <% code :lang => 'perl' do %> 
     my $code = 'is simple';
    <% end %>

    All in all, it seems like it fits the bill.

Summary

I probably missed some very nice alternatives. I know there is spod5 on CPAN, but that seems very similar to Pod::S5. I’m sure there are more. Let me know if I should be trying out your favorite.

One other aspect that I’ve been tinkering with: printing the presentation. I don’t need it for the PM presentation I am working on, but if I were to try to switch from PowerPoint to Slide Share for my day job, I would definitely need a way to create .pdf files.

This seems like an issue that others are running into, but there is no great solution so far. It looks like the trick may be to customize the print.css file. The following should change the page layout and add page breaks:

@page {size: landscape;}  /* only works in Opera? */
.slide {page-break-after: always;}

But we are still missing the nice background and layout. I’ll need to spend some more time on this.

Last note: I stumbled into what may be a nice tool to convert a web page to .pdf from the command line: wkhtmltopdf. It barfed on my S6 presentation, but it printed a few other websites nicely.

Labels:

Wednesday, October 21, 2009

Making Catalyst Debug Logs Really Be Quiet

I have recently been adding and updating tests to my biggest Catalyst project and have been a bit perplexed by the debugging output...in particular that I was seeing any of it! Generally, I like to see all that output scroll by, but when running Test::WWW::Mechanize::Catalyst tests over and over again, it just clutters things and obfuscates any failures.

I had removed -Debug from the plugin list and tried CATALYST_DEBUG=0 env variable, but I continued to see a lot of the debug messages. After a bit of googling, I finally learned that this was a feature.

The -Debug flag and CATALYST_DEBUG env variable are just for the internal Catalyst debug logs. What I needed to do was to set the log levels with MyApp->log->levels to control what is dumped with $c->log->debug and its brethren. In general, I want my custom debugging and the internal Catalyst debugging to be tied together, so I added the following to lib/MyApp.pm after __PACKAGE__->setup:

__PACKAGE__->log->levels( qw/info warn error fatal/ ) unless __PACKAGE__->debug;

Now, if I run the server with -d or do something like "CATALYST_DEBUG=1 prove -l t" I see all the usual log message, otherwise I get nice clean test output.

Labels: ,

Wednesday, October 14, 2009

Moving to a Mac... which Perl?

We'll after neglecting this blog for quite some time, I'm now back. I had to swap my laptop during the summer, and I decided to give one of the MacBook Pros a try. So I'll be adding Perl on the Mac and the Mac in general to the topics covered here. My first dilemma with the new Mac was which perl to use.

  • Leopard only had 5.8 installed, and I've been hooked on 5.10 for a while now. (Snow Leopard has added 5.10, but by the time I got the upgrade I was commited to the ideal of keeping the system perl separate from my development perl.)
  • Having come from Arch Linux, I stumbled upon and really liked Arch OS/X. Unfortunately, it appears that it isn't as well tested as MacPorts. In order to build any Perl modules that us XS with the Arch OS/X perl, I needed to use:
    $ perl Makefile.PL \
        LDDLFLAGS="-arch x86_64 -arch i386 -arch ppc \
                 -bundle -undefined dynamic_lookup -L/usr/local/lib" \  
        LDFLAGS="-arch x86_64 -arch i386 -arch ppc -L/usr/local/lib" \
        CCFLAGS="-arch x86_64 -arch i386 -arch ppc -g -pipe \
                 -fno-common -DPERL_DARWIN -fno-strict-aliasing \
                 -I/usr/local/include -I." \
        OPTIMIZE="-Os"
    
    Ummm... I don't think so! While I created an bash alias for it, cpan/cpanp where requiring constant tweaks. I assume I could have exported those variable from my bashrc, but I would rather avoid global changes like that.
  • Next I tried compiling my own perl. I ended up doing it several times as I learned where to put it, and realized I had forgotten to enable things like threads. This really seems to be the best way to go, but I would rather someone else keep up with security patches, new versions, etc.
  • So finally I tried MacPorts. So far so good. I have had trouble remembering to check the variants (port variants <port-file>), but otherwise thumbs up.

One thing I realized that I want, is a record of all the ports that I have installed (not a list of all the installed ports, just those that I had purposely installed). So, I wrote a short bash script that I stuck in ~/bin/port to keep a log:

#!/bin/bash

case "$1" in
  install|uninstall|upgrade|activate )
      echo "`date` $@" >> ~/.macports.log
      ;;
  *)      
esac

/opt/local/bin/port $@

Now anytime I run port install perl5.10 +shared +threads it is added to a log file. Rebuilding the system should be a snap. (I'm sure I could have gotten this by grepping for sudo and port install from the /var/log/system.log* files, but I like having it all in one place and not worrying about log files being rotated out.)

One other tweak I need to make, was for CPANPLUS. I wanted to be able to install modules in either the system perl (by running /usr/bin/cpanp) or the MacPort perl (/opt/local/bin/cpanp), but both of those read my user config file (~/.cpanplus/lib/CPANPLUS/Config/User.pm) which need a full path for perlwrapper => '/usr/bin/cpanp-run-perl'. So I moved just that part of the config to the system config file by runnning the following in each cpanp:

$ s save system
$ s edit system

Then removing everything but the perlwrapper configuration. And finally taking the perlwrapper configuration out of my User.pm file. One other thing I needed to do to make 5.10 the default perl. MacPort defaults to perl5.8, but the following took care of that:

$ cd /opt/local/bin
$ sudo mv perl perl.bak
$ sudo cp perl-5.10 perl
# make cpanp -> cpanp-5.10, etc.
$ for i in *-5.10 ; do x=${i%%-5.10} ;  sudo mv $x $x-5.8 ; sudo ln -s $i $x ; done 

I see Python has a python_select port-file. Maybe we need something like that for Perl.

Labels: , ,

Saturday, July 4, 2009

Stealing from Padre for Vim part 3

As promised in my last post, I have released a new version of App::EditorTools and have a number of screenshots of the new functionality. This version includes App::EditorTools::Vim, which provides an easy way to add the vim scripts to integrate the package into Vim.

perl -MApp::EditorTools::Vim -e run > ~/.vim/ftplugin/perl/editortools.vim

And now you should have the following mappings:

  • ,pp - Show a menu of the functions availabe from App::EditorTools
  • ,pL - Lexically rename the variable under the cursor (make sure the cursor is at the start of the variable for now
  • ,pP - Rename the package based on the path of the current buffer
  • ,pI - Introduce a temporary variable

Here are a few screenshots of these actions:

Lexically Rename Variables:
vim-renamevar
Rename Package based on the current file's path:
vim-renamepackage
Introduce Temporary Variable
vim-introtempvar

I'd love to hear feedback and any suggestions for future PPI based tools that Vim, Padre and other editors could leverage.

I also have to note that the editortools-vim script from App::EditorTools was very easy to put together (although it still needs a fair amount of clean-up work and documentation) since is was based on Ricardo's App::Cmd--very easy to use and feature rich.

** Updated 7/5/09 10:37am: moved the screencasts to an external server and fixed some spelling

Labels: ,

Saturday, June 27, 2009

More theft from Padre

I was pleasantly surprise at the positive response to my last post on Stealing from Padre for Vim--particularly from the Padre developers! Seems they had hoped/planned on separating some of the tools out of the Padre core from the beginning (and many seem to be vimmers).

With their blessing and encouragement, I have pulled the editor independent parts of their PPI::Task tools into its own distribution--PPIx::EditorTools--available now on CPAN. I also adapted the current version of Padre to work wit the external package and released App::EditorTools to provide a command line interface for those editors that need it (i.e., vim). I'll post another screencast and the Vim scripts needed to integrate it shortly.

As a result, I'm depreciating App::LexVarRepl--which was only ever available on github.

Sorry for the short post which is light on links and code, but we are in the process of moving so I'm dedicating the few moments I have to coding this rather than blogging about it...for now at least!

Labels: ,

Tuesday, June 16, 2009

Stealing from Padre for Vim

I'm sure the Padre developers weren't hoping to have their code absconded for those of us addicted to vim, but tsee's recent blog post on refactoring with Padre's lexical variable replace made me jealous--I want that for vim! So hack, hack, hack and voila:

screenshot
This really is just leveraging the Padre code. At this point I actually use Padre::PPI but that has the downside of requiring Wx (which I personally like but it is quite a requirement). I only added a bit of code to make this into its own package and included some hints on vim scripting. The idea is to show how this could be abstracted into a standalone module then Padre, vim and any other reasonably powerful editor could use it. For now, I have packaged it as App::LexVarReplace with App::LexVarReplace::Vim pod. I would appreciate suggestions on the package layout and name, and any feedback from the Padre guys would be great. The git repository is available for your perusal. I must say that Padre seems very cool. I continue to check it out every once in a while, but I just can't seem to give up vim, gnu screen and a good old xterm. The developers have really done a great job leveraging modern Perl tools. You should check it out! I am only publishing this on github for now. I would like to speak with tsee or one of the Padre developers before this makes it debut on CPAN, but I'm a bit short on time at the moment.

Labels: ,