Older blog entries for fxn (starting at number 302)

With the last release of Beamer you can put movies and sounds in your presentation: This new version includes a package for including sounds and movies in a beamer presentation. The package also works stand-alone and can be used with any other latex class (like article or prosper). Other new features are the option to automatically break a frame into several frames, to automatically shrink a frame to fit the available area, to add special zoom areas and some other new stuff.

Hey this package rocks even more. Incidentally, the documentation patch I sent after proof-reading the user's guide has been applied.

It had been a while since I played Perl Golf. Today someone posted a mini-golf problem in the fwp mailing list, and since I woke up very early in the morning (4am) I decided to have some fun with it.

Given two strings $x and $y we have to put in $n the index of the first character where they differ. If the strings are equal $n has to be undef. For example, if $x is "foo" and $y is "foobar" then $n has to be 3.

I sent a few solutions and by now the shortest one is mine (with a fix pointed out by Yitzchak Scott-Thoennes):

    {$x ne$y&&$x=~/./sg&$y=~/\G\Q$&/g&&redo;$n=$-[0]}

It's a pity playing golf requires so much effort to squeeze a solution until you get something more or less good. It remembers me to how work with koans is explained in books (I have never worked with koans myself), you visualize your solution and try to improve, change, explore other approaches, consult the documentation to take advantage of corner cases, try to gain some character via some side-effect, reordering, think, think, think, ..., you have to be one with the problem, so to speak. Takes time, concentration, and it's very intensive. Solutions often come by saturation. Otherwise I would play more frequently.

One of the guidelines in Halk is that presentations should be portable and self-contained as much as possible. They should ideally be seen as a file you drop to your hard disk. Running it and pointing your browser to some local port is all what would be needed. No installation, no setup.

This brings some internal issues, as what happens with custom preprocessors and beautifiers, but another kind of problem are dependencies.

Let's imagine you are giving a tutorial about some Python module which is not standard. The code in the presentation needs that module installed to run, what do we do? A solution is for the author to document that the presentation requires that module. Ugh. A presentation property could be some Perl code that checked dependencies so that the engine could warn the user with some informative message about what is missing and how to get it.

But I think an important number of cases can be solved if the config file provides authors with a mean to set environment variables. Since the presentation directory is owned by the author (in Halk's sense) he can install dependencies there. And since he is allowed to use filenames relative to the presentation root everywhere we can provide calls like

    setenv 'PYTHONPATH', 'lib';

or for a presentation about some Java library:

    setenv 'CLASSPATH', 'lib/*.jar', 'lib/*.zip', 'classes';

Those wildcards are possible with zero effort thanks to Perl's glob() builtin.

That won't cover all the cases, for instance if a library has native code and the author includes versions for several operating systems we can easily offer:

    setenv 'LD_LIBRARY_PATH', 'linux_lib' if RUNNING_ON_LINUX;
    setenv 'DYLD_LIBRARY_PATH', 'macosx_lib' if RUNNING_ON_MAC_OS_X;

So that trick would cover a few more. And in the end we always have a README as last solution :-).

Halk

Some classes are already implemented. I did some trials with HTTP::Daemon and works like a charm. In a few lines you've got a simple HTTP server running where you can hook your custom code. It comes with LWP and based on its classes.

I founded an interesting module for config files called Config::General. It provides a syntax based on Apache's, where tags can be nested a la XML, there's file inclusion, variable interpolation, here documents, .... The example of two days ago becomes:

   title: About Foos And Bars
   author: The Author
   theme: clean
   pretty_printer: source_highlight_wrapper.sh
   
   <section>
     title: Section Title
     <subsection>
       title: Subsection Title
   
       <slide>
         title: Slide Title
         body: <<BODY
   This slide introduces foo, which is further detailed
   <a href="[% link_to_sref('bar') %]">later</a>.
   BODY
       </slide>
     </subsection>
   </section>

but looks too verbose to me compared to

   title 'About Foos And Bars';
   author 'The author';
   theme 'clean';
   pretty_printer 'source_highlight_wrapper.sh';
   
   section 'Section Title';
   subsection 'Subsection Title';
   
   slide 'Slide Title', <<'BODY';
   This slide introduces foo, which is further detailed
   <a href="[% link_to_sref('bar') %]">later</a>.
   BODY

Moreover with the latter to configure a presentation those functions are created as clousures before do()ing the file and Perl does the rest. Couldn't be easier.

9 Ball

I entered a 9 Ball Tournament to be held next Sunday in Namcos' at Diagonal Mar. It has been a long time since I touched the cue, but it will funny.

Pasting code in Advogato

Pasting code is something not to be abused here, but I think it would be normal to see it now and then in the diary of software developers more than we do.

That has a couple of inconveniences though, not a big deal, but:

• Special characters have to be substituted with HTML entities.
• mod_virgule doubles blank lines in pre blocks and adds a spurios leading space.

I faced that once again yesterday and said no more. I wrote a simple filter anyone can use. It does the following:

• Escapes special characters.
• Puts a dummy space in blank lines to avoid the bug.
• Indents the whole block.
• Wraps the result in a pre tag.
• Puts the result in the clipboard on Mac OS X and Win32.

In particular, if the stuff to paste is in you editor and the program supports passing some selected text to an external program (M-| in Emacs) the code can be easily copied that way from the very source.

Of course the first application of that script has to be to blog his very listing, but since it is a bit long I'll just post a few lines:

   #!/usr/bin/perl
   
   use strict;
   use warnings;
   
   # indentation of the whole block
   my $indent = ' ' x 3;
   
   # coderef for setting the clipboard
   my $clip = $^O eq 'darwin'  ? \&clip_macosx :
              $^O eq 'MSWin32' ? \&clip_win32  :
                                 \&clip_unsupported;
   
   # ...

A possible way to write presentations in Halk could be using procedural Perl:

   title 'About Foos And Bars';
   author 'The author';
   theme 'clean';
   pretty_printer 'source_highlight_wrapper.sh';
   
   section 'Section title';
   subsection 'Subsection Title';
   
   slide 'Slide Title', <<'BODY';
   This slide introduces foo, which is further detailed
   <a href="[% halk.link_to_sref('bar') %]">later</a>.
   BODY

That would be simply do()ed, and does not require to know Perl, but to know the syntax of the config file, which can be documented. Recursive file inclusion is trivial. It has the drawback that its flexibility is limited however, but what we want to configure might not be that complicated.

I think Halk is going to be based on some templating system for configuration and slides, and on PAR for distribution of the program and stand-alone presentations.

From Beamer I've realized the best solution for writing presentations in this kind of tools is in my opinion to have by default the slides in a single file, and to provide an include facility to structure large presentations. This way short presentations are easy to write, and includes let authors organize their presentations as they wish.

Granted, that's an old idea, but in the prototype there was a directory structure. Its purpose was to have the slide and its related files in a single directory. Since in the presentations the prototype was written for almost every slide has a program and its corresponding HTML listing that sort of made sense. But for Halk that would be clearly a wrong choice.

Now, after seeing YAML wouldn't be a good choice for the config file, I pondered XML. If presentations are going to be writable in a single file I won't choose XML for two reasons:

• There's no clean including mechanism in XML that I know. The canonical options seem to be to create an entity like this

  <!DOCTYPE spec SYSTEM "spec.dtd" [
  <!ENTITY section1 SYSTEM "section1.xml">
  ]>
  

  which I don't like for a friendly config file, or to use XInclude, whose corresponding Perl module I couldn't even install. I could try to add some custom solution for it but the second reason has more weight:
• Since presentations are written in HTML the config file would need to be full of CDATA markers. I don't like that idea.

Next step is to try to come with a neat solution for the requeriments I've got using some templating system. The candidates are Text::Template for its simplicity and, and the Template Toolkit for its power and clear syntax. In any case, authors wouldn't be required to know Perl or to study any of the choosen solutions unless they want to. The documentation should ideally explain how to write slides in a self-contained way.

haruspex, dyork: Yeah, simulated small caps are not true smalls caps.

In case someone does not know this stuff, simulated small caps play with upper-case letters of a normal font in different sizes to get something that resemble them. True small caps, however, are fonts in themselves. To give an example anyone can try, LaTeX comes with Computer Modern true small caps. Compare that with the small caps used by Safari in dyork entries. The former looks smooth, well-proportionated, whereas the latter looks somewhat ugly.

dyork: They look right in Safari 1.2.1.

Quote of the day

From footnote 21 on page 35 of David Foster Wallace's Everything and More: A Compact History of ∞:

[If you're interested] Let's explicitize at the outset that the 'you might recall' and 'it goes without saying's and so on are not tics but rhetorical gambits whose aim is to reduce annoyance in those readers who are already familiar with whatever's being discussed. No particular experience or recall of college math is actually required for this booklet; but it seems only reasonable to assume that some readers will have strong math backgrounds, and only polite to acknowledge this from time to time. As was briefly mentioned in the Foreword, the rhetoric of tech writing is fraught with conundra about various different readers' expertise-levels and confusion-v.-annoyance curves. None of this is your problem, of course—at least not directly.

Listening

D'angelo, Playa, Playa.