Maddingue tag:blogs.perl.org,2009-11-03:/users/maddingue//738 2012-07-09T00:37:11Z A blog about the Perl programming language Movable Type Pro 4.38 Is PCLI possible? tag:blogs.perl.org,2012:/users/maddingue//738.3505 2012-07-08T23:13:36Z 2012-07-09T00:37:11Z At the French Perl Workshop (and probably elsewhere before), Matt Trout talked about why and how some ideas could succeed and most other fail. An interesting talk. The last part was a rant against the numerous modules on the CPAN... Maddingue https://github.com/maddingue At the French Perl Workshop (and probably elsewhere before), Matt Trout talked about why and how some ideas could succeed and most other fail. An interesting talk. The last part was a rant against the numerous modules on the CPAN to parse command-line options. His proposal was to do the same thing to command-line programs (CLI) than PSGI did to web applications: formulate a generic specification, that developers can use to build applications and not depend on a specific implementation.

A very interesting idea. We were a few (BooK, cmaussan, niels and myself) to begin thinking about what this PCLI specification could look like. I wrote down on paper what I've been doing in the numerous CLI programs (for a broad value of the terms) I wrote over the past years.

A CLI program has to go through these steps:


  1. fetch and parse environment variables (%ENV); errors may be warned about or fatal

  2. fetch and parse command-line options (@ARGV); errors are fatal

  3. handle usage and help (Pod::Usage

  4. parse configuration file; errors are fatal

  5. check all parameters (mandatory options, exclusive options, etc); errors are fatal

  6. apply all parameters default values

  7. setup logging; errors may be silent, warned about, or fatal

  8. become a daemon, for the programs intended to run this way

  9. setup basic signals managements (INT, TERM, QUIT, HUP), usually for daemons, but can also be useful for programs running for a long time

Now, I didn't know what PSGI looked like (I'm a sysdev, not a webdev). Today, I read the specification, and it confirmed what I had already identified: yes, PSGI is brilliantly "simple" because it was written by people knowing very well this field, helping themselves with the experience of similar specifications (WSGI, Rack, JSGI). But it is also simple because it is a protocol built on top of a protocol (HTTP), built on top of a protocol (TCP), built... At PSGI level, there's just a bidirectional channel with data going in both directions. And it's platform agnostic.

However, in the CLI world (and let's limit ourselves to the Unix world for the sake of simplicity), we have multiple channels of input (%ENV, options, configuration file(s), STDIN, input data files, signals) and output (STDOUT, STDERR, logging, output data files), and no standardized protocol of any kind.

Now, I'm afraid that either we try to cover most of the features we need, and we end up with a specification too complex, or we limit to a subset of the features, and we end up with a specification too simple to be actually useful.

Did I miss something? Was Matt too optimistic or am I once again too pessimistic?

]]> Beginning with an end tag:blogs.perl.org,2011:/users/maddingue//738.2384 2011-11-01T22:15:02Z 2011-11-01T23:08:20Z The last day of September was also my last day at Orange, after 5 years and 9 months working there as a sysadmin/sysdev. Because I was "the Perl guy" other there, my last message couldn't be a standard "it's been... Maddingue https://github.com/maddingue The last day of September was also my last day at Orange, after 5 years and 9 months working there as a sysadmin/sysdev. Because I was "the Perl guy" other there, my last message couldn't be a standard "it's been a pleasure working with you blah blah". Obviously, I had to send a Perl obfuscation.

]]> Unfortunately, I didn't have the time to work more than one or two hours on it, so I ended with something simple:

use 5.010;$:=v117.116.102.56;eval"use encoding $:=>STDOUT=>'$:'";$c=
1e4;$i=-1;$b=0x3041;@f=(20,71,41,72);while($i<4){@v=map+int rand(86)
,1..4;@v[0..$i]=@f[0..$i]if$i>0;$c--if$c&&$v[1+$i]%4==0;$c=+5e3,$i++
if$c==0&&$v[$i]==$f[$i];print+chr($b+$_)for@v;print"\r"}print"\n\x4"

(I know, it barely deserve the title "obfuscation", but I don't have BooK's or cognominal's experience in this domain. At least, it's correctly justified.)

The aim of this code is to print, in a funny way, 5 important characters. The first 4 are the Japanese characters さよăȘら (sayonara). The last character is ASCII 0x04, EOT (End of Transmission). I'll assume I need not explain the meaning and references.

Now, if I began writing about this code, it's to explain the mistake I did in it. Can you see it?

It's not very apparent because the code basically works. In fact, it works faster than I expected. This is the problem. On my PowerBook G4, it takes a bit more than 5 sec to execute. On a more recent computer, usually less than a second.

The reason? I stupidly used loops to simulate sleeps. This is surely lesson one when making a demo or a game: fix your timestep so the program performs consistently on different platforms. That's not something we're used to think of in sysdev, but that's the basis when making a game.

]]>