Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Shlomi Fish (918)

Shlomi Fish
  shlomif@iglu.org.il
http://www.shlomifish.org/
AOL IM: ShlomiFish (Add Buddy, Send Message)
Yahoo! ID: shlomif2 (Add User, Send Message)
Jabber: ShlomiFish@jabber.org

I'm a hacker of Perl, C, Shell, and occasionally other languages. Perl is my favourite language by far. I'm a member of the Israeli Perl Mongers, and contribute to and advocate open-source technologies. Technorati Profile [technorati.com]

Journal of Shlomi Fish (918)

Tuesday June 03, 2008
04:20 PM

Nominating szabgab for the White Camel Award

I alread sent it to jose-at-pm.org and advocacy-at-perl.org, but here it is just in case:

I'd like to nominate Gábor Szabó (the Hugarian-Israeli Perl programmer, not the Jazz musician) for his contributions to the Israeli and Global Perl Communities. See:

Gabor Szabo is responsible for the fact that the Israeli Perl community, and that of other dynamic languages has took off. So far he:

  1. Set up an alternate mailing list, which proved to be more active - perl@perl.org.il.
  2. Set up a tradition of monthly Israeli Perl meetings, which have turned out to be popular.
  3. Organised 3 YAPC::Israel conferences - YAPC::Israel::2003, YAPC::Israel::2004 and YAPC::Israel::2005 and an OSDC::Israel conference - OSDC::Israel::2006.
  4. He helped organise the Hungarian Perl Workshops in Hungary, and a Hungarian YAPC.
  5. He set up CPAN Forum - as a way to get help and ask questions with individual CPAN distributions. Also allows users to tag their modules using delicious-like tags.
  6. His commmercial venture - http://www.pti.co.il/ - has been responsible for training material and sessions for Perl and other FOSS technologies, as well as general FOSS development and support. Some of its material has been made available online free-of-charge.
  7. He has written many weblog entries, comments, emails and other material about communal and technical issues.
  8. Aside from all that, he has done numerous contributions of code, and documentation.

Monday June 02, 2008
06:25 PM

Next OSDClub Tel Aviv Meetings

On Tuesday, 3-June-2008 (tomorrow or today depending how you look on it), on 18:30, the OSDClub of Tel Aviv, which is a joint venture of the Tel Aviv Linux club, and Perl-Israel (and some other FOSS clubs who want to join the fun), will hold a social meeting. It will take place at the Café of Tel Aviv University near the junction of Einstein and Haim Levanon Streets. This social was scheduled because Zvi is in Israel. (If you don't know who he is, then come to meet him.)

Much later, on Sunday, 15-June-2008, OSDClub Tel Aviv will meet to share some Vim/gvim (= the text editor) Tips and Tricks. We'll meet in Schreiber (Math & CS) building in Tel Aviv University. We have more meaty presentations planned for July, but we hope these two meetings will be a a useful start after a long neglect.

Thursday May 29, 2008
02:54 PM

No outgoing email to @perl.org and @pm.org

Hi all! Due to a technical problem, I have been unable to send any outgoing email to the @perl.org and @pm.org domains from either my home email address or my gmail.com email address. This is while outgoing mail to other places is mostly working, and most people have no problem sending email to the perl.org and pm.org domains. I receive bounces on any mailing list addresses, or @perl.org forwards.

This is the reason why I've been unusually quiet there lately, so don't worry. I can still be reached in many ways, and have many ideas for things I'd like to post on my blogs and on my homepage.

Anyway, cheers, and sorry for the inconvenience.

Thursday May 22, 2008
05:22 AM

Perl vs. Ruby on Two Idioms

I've been meaning to blog about it for a few weeks, so here goes. In a Ruby-Israel thread someone asked how to convert an array to a hash that contains all of its keys as members (and "true" as a value). They came up with:

a = [1, 2, 3, 'other']
h = a.inject({}) {|h, v| h[v] = true; h }

In Perl, it's:

@a = (1,2,3, 'other');
my %h = (map { $_ => 1 } @a);

Much cleaner. I also though of a way to do a flat concatenation of an array of array references. Like [[1,2,3],[4,5,6],[7,["One", "Two",],9]] into [1,2,3,4,5,6,7,["One", "Two",],9]. In Ruby it is:

[[1,2],[3,4],[5,6,["Hello","There"],7]].inject([]) { |a,e| a+e }

While in Perl it is:

(map { @$_ } ([1,2],[3,4],[5,6,["Hello","There",],7]))

Both of these are caused by the fact that lists are not references in Perl, and that one can initialise arrays and hashes from them. This is while in Ruby or Python (and most Lisps) they are references. That or Ruby lacks more primitives.

Saturday May 17, 2008
04:31 PM

PerlBuildSystem (PBS) is now FOSS

Got no Google, got no email, got no love - gotta blog!

I met Nadim (NKH) on Freenode's #perl, and he seemed very pleasant. I told him how I heard everybody got a kick out of his App::Asciio graphics app. Then when visiting his CPAN page, I noticed that he's the author of PerlBuildSystem, which had been released under a problematic "not-for-military-use" licence, which sparked an active discussion on module-authors back at the time.

I asked Nadim if he can make it non-restricted, and he said that he could. So he uploaded a new version under the Artistic License 2.0, which is the Parrot licence, is FOSS, and is GPL-compatible. W00t! Nadim++.

He also said that he is working on a heavily improved version, for which he uses git, and should be released sometimes. I'm contemplating converting my homepage from a really-funky GNU make configuration to something more decent, and now that PBS is unrestricted I may take a look.

Friday May 09, 2008
03:04 PM

Why People Are Passionate About Perl

Well, Per brian d foy's blog post, I'd like to answer the question "Why I'm Passionate About Perl". First of all, I should note my "The Joy of Perl" essay, which I wrote back in 2004. It gave a lot of good reasons why I like Perl so much and am still passionate about it. But now to answer brian's questions:

The person who introduced me to Perl showed me that... - I still remember him (Ran) telling me that one can write a TCP/IP client in 4 lines, and a TCP/IP server in 10 lines. (Or something like that). I ended up not understanding what regular expressions were all about and he explained that they matched patterns in texts. Back then, I had to learn perl 5 from perl*.pod (what are now the perldocs).

I first started using Perl to... - had to learn Perl (and Unix) because I wanted the job working for Ran's company. I liked both Perl and Unix so much that I understood why I had not been content with all the technologies I encountered previously. (DOS and Windows 3.11).

I kept using Perl because... that was what I knew and I was comfortable writing it, and found that most various techniques were readily available in some form or another. For example, after reading SICP I was able to easily implement the closure-based techniques shown there in Perl. Then after I learned Object-Oriented Programming in Perl, I found out how nice it was, and how much better it was than C++. (Which if you ask me now supports Object-Oriented Programming roughly as much as COBOL supports Functional Programming.)

I later on learned how to effectively use the CPAN, use accessors, and many other tricks and techniques. I got involved in the Local and International Perl community, which was also a lot of fun.

I'm not a Perl fanatic and see myself sometimes using, learning or experimenting with other technologies. But I still like Perl 5 the most.

I can't stop thinking about Perl... - actually I often can. The amount of time I spend coding is small, and Perl is even less than that.

I get other people to use Perl by quietly telling them how Perl is important and how it is enlightening and useful, and also telling them about the things I'm doing with Perl.

I also program in Bash, C/C++, PHP and a little Python (and small experimental stuff in many other languages) but I like Perl better since: 1. It's a real, and safe programming language unlike Bash. 2. It's much more easier to write than C, C++ or Bash. 3. It's more comfortable to me than Python due to the TMTOWTDY, use strict and other factors. (Though I can understand why Python has its appeal to some people.) 4. It's much less hacky than Bash and PHP. 5. The Perl community is great, and has a very healthy attitude.

Note that I'm still using bash for the command line and for some really minimal scripts, and am happy with it, and prefer it over Perl.

Comments are welcome. (I leave the comments open, as I almost always do).

Thursday May 08, 2008
11:26 AM

Looking for a Good Personal Blog Engine

Dear Lazyweb,

I'm looking for a recommendation for a good personal blog engine that I'd install on my site. It should be Free Software (preferably GPL-compatible); it should be Perl, Python or PHP (Perl is preferable), possibly also Ruby; it should be able to use PostgreSQL as a backend; and it should be good: easy to install, mostly works out of the box, easy to extend, with an active developer community, readable (not necessarily too modular) code, good security practices, etc.

Here's what I tried so far:

  1. MovableType - has a weirdo HTML caching system, and ended up putting a lot of world-writable files on my hard disk. Also doesn't work out of the box with recent PostgreSQL's (which is easy to fix).

  2. WordPress - from using it elsewhere I had at least three occassions where it ate my comments and refused to allow me to repost them. Also, it has many bad defaults like non-threaded comments, A single "Submit" button with no preview, no pure-HTML input, and these weird ?id=$INDEX URLs which I hate. All of them can be fixed using Plugins, but it's still an extra hassle.

    It also had a very poor security record, and pkrumins said he isn't content with it for his blog, and working on something from scratch.

There are many other blog engines out there, but I'm looking for a personal recommendation from experience. Comment below or drop me a line. I'll probably blog here about what my final verdict is.

Tuesday May 06, 2008
06:42 AM

New Essay: "What Makes Software High-Quality"

I wrote a new Essay about what makes software applications high-quality, as well as which parameters and methods, while desirable and quality-enhancing, are not exactly quality. It was inspired by a post on a public mailing list I set up, and Perl and perl 5 are mentioned there a few times, as are many other open-source projects.

It is available in several formats: HTML to read online (on Page), DocBook/XML source (which can in turn render other formats), PDF (please don't print it even though you are legally allowed to). The licence is CC-by-2.5. Comments are welcome.

Friday April 18, 2008
03:29 PM

Test-Run Tests Breakage on BSD Systems

OK, as I expected my previous entry sparked an active discussion - nothing like a good licences war to liven things up. But it was more civil than I expected. Here's a much more technical entry.

As I discovered, Test-Run-0.0115 consistently failed to pass "./Build test" on all BSD systems, while doing mostly fine on Linux. Inspecting the logs of the failure yielded a "File name too long" error. What happened was that I created a filename that was artificially very long (../t/../t/../t/), but still well within the limits of my Linux system's 4096 bytes limit for file paths. However, as I discovered the POSIX standard defined a minimum of 256 bytes for maximal paths which is what BSD is supporting.

The reason I had this long path in the first place was to make sure long paths are handled properly by the harness output after some customisations. This in turn was inspired by a problem I found when using Test-Run at my workplace for some internal test suite, which inspired me to write the Trim-displayed-Filenames plugin.

So after I received all these failure reports, I added some logic to t/output.t that makes use of POSIX::PATH_MAX() to keep the path at bay. A bit convulted, but it now passes on BSD systems (as well as Linux and Solaris), with a two isolated failures on Linux, which I have not looked into yet. I'd like to thank apeiron from Freenode for testing the pre-release in Mac OS X and verifying it works there.

In any case, I'm a bit tired of doing unknowledgable UNIX programming, and therefore would like to read the 2nd edition of Stevens' book (which is considered the Bible of UNIX programming). The book is kinda costy, and big (960 pages), so I think I'll renew my Safari subscription and see if I can read it there effectively. If I can't I'll just use it for something else, and order a paper-copy of the book.

And finally, I wonder how a 256-octets path limit can ever be enough. In this day and age of long filenames and UTF-8 ones (which require several bytes), one can expect that a path with a few especially long components will quickly overflow such a short limit. Can any BSD users comment?

Thursday April 03, 2008
03:22 PM

The Problem with the "Same Terms as Perl" Licensing

This entry was adapted from some comments I wrote for a different, mostly orthogonal, journal post. I hope it's not too flamebait. If you have something to say, please try to be civil and good-natured. Here goes nothing:

Most modules on CPAN carry a licensing blurb saying something like "you can distribute this software under the same terms as Perl itself". This obviously begs the question what does it mean. Here is what it means for different Perl versions:

  • Early versions of perl, before it adopted the GPL were under a very restrictive loosely-defined licence.

  • After a while perl adopted the GPL exclusively.

  • Eventually, seeing that some people and companies had problems with the GPL, Larry Wall phrased the so-called "Artistic License", which was supposed to be more permissive than the GPL, but purposely phrased vaguley, and as such was found to be non-free and ergo GPL-incompatible.

    In any case, the perl implementation was dual-licensed under the "Artistic License" (version unspecified) and the GPL version 2 or any later version. perl5 is still licensed under these terms.

  • For Parrot and for future work on Perl 6, the Artistic License 2.0 was created based on the original Artistic License. This license has been approved as a free software licence by the Free Software Foundation and found to be compatible with the GPL version 2 or Later. Parrot now carries this licence.

    There's also the Clarified Artistic License which is an earlier effort to correct the original Artistic License and is the minimal set of changes to make it FSF-free and GPL-compatible. I suppose that now the Artistic License 2.0 would be preferable.

The problem is that perl up to and including perl-5.10.0 and bleadperl (which were licensed under the GPL version 2 or above but only the "Artistic License" not the "Artistic License version 1.0 or above". I've already noted that the Artistic License is problematic, but the GPL has its own share of potential problems (see also its FAQ), and is otherwise widely mis-understood, over-hyped (both positively and negatively) and disputed. For example, unlike the Artistic License, it does not allow (at least by linking or normal function calls) non-GPL-compatible code, including all non-open-source code, to make use of it.

Now, since both the "GPL version 2 or above" and the original "Artistic License" are problematic, and the term "under the same terms as Perl" may probably mean just that if it's a perl5 module (although who knows what it would means if someone would ever write a compatible Perl 5 implementation under a different software licence), then licensing a module as such is probably no longer such a good idea. There are several alternatives:

  1. Explicitly allow the Artistic License 2.0 (or possibly above) in the licensing.
  2. License as Artistic 2.0 or above exclusively. Without the GPL as it is generally no longer needed.
  3. Use a more permissive, non-copyleft licence, that allows re-licensing into different licences. The MIT X11 licence explicitly allows "sub-licensing" by third-parties and as such is a good choice. By doing that you are making the licence more permissive than the GPL or the Artistic licences, so you have been warned.

So my suggestion is that you use one of these licensing phrasings for your future work, and to re-license your old CPAN or Perl work (copyright ownership permitting) under such phrasings. It remains to be seen what will happen with perl5 itself which has 905 authors as of perl-5.10.0 many bringing in their own ownerships of the code. The Linux kernel now faces a similar problem if it would wish to adopt a different licence than the GPL version 2 (and no later version).

I suppose you can still make most use of perl5-like licensed code, in your own open-source, proprietary or in-house code, without getting sued, so I wouldn't worry too much. But it would still be a good idea to convert newer code (and code that can be easily converted) to licensing terms that are less ambigious, more usable, and that would play better with future versions of Perl.

For the record, most of my Perl and non-Perl open-source code is either Public Domain or MIT X11-licensed (which are both extremely permissive and allow sub-licensing), or if it is derived from a different code, then under the same licensing terms, but while disclaiming my explicit or implicit ownership (to allow the originator to relicense future versions of the code). The latter policy applies to my (relatively limited) contributions to perl5 where I am listed in the AUTHORS file.