The Perl Hacker Painter

On making a Simple Web-based installer in Perl

2010-09-27T16:02:00.000-07:00

Recently and after 10 years of avoiding the idea, I made a web-based installer for Dada Mail.

My original thought was, something like this isn't necessary, that the installation process had been twiddled down to changing, oh, 3 variables in a heavily documented config file and additional "power user" fancy things to do, if You Knew What You Were Doing. What could possibly be easier?

Oh, how wrong I was - and how I never knew how wrong I was, until I've gotten some feedback on the alternative of having an installer.

You can get a gist of how the installer works in this video:

Basically, you pop up a tar.gz distro and a helper script that just gets things all set, you run the helper script and fill in a few things in a form - most of which are pre-filled with Best Guesses. I am not breaking new ground, here.

BUT what I am doing is giving my users the patented PHP Xperience - and that's what they want:

You throw up some files, you visit some stuff via your browser, you set some params and you go zoom.

The problem with, "But, there's all these CPAN dependencies!!!" was solved a long time ago in this project by only using Pure Perl modules (gets limiting in some instances) and shipping the app with an already pre-filled app-specific perllib. This also is a huge headache and the shipped-perllib is always behind, but it's better than nothing. The cpan deps service has been heaven-sent for roll-your-own-manually folks. The, "But, there's Cool Things in CPAN to do Cool Things in your App!" wish is solved by just making these cools things optional. cPanel, which is what a lot of Very Cheap Web Hosts use as their platform has a web-based cpan installer, so it's even within a mortal's reach to use CPAN to do fun things.

Anyways: here is, after a month of having the installer, some reflections:

The support boards aren't devoid of installation questions, but they sure are a lot quieter.

There are users who are intimidated by the installer. I don't know how else I can make things easier and these users would also be intimidated by doing things manually (which is still an option). I used to be intimidated with oiling the chain on my bicycle, but it takes... I dunno, 5 minutes to learn what you need to do. I don't ever say, "Uh, Google-fu the base level how-to to, (for example) FTP a file", but I don't quite know what I need to say.

But, the other amount of users that were intimidated doing things manually, but can also figure out the installer is the majority. Which is great - solved the problem. Now, the questions are simply bizarre edge cases dealing with weird MySQL setups on questionable hosting accounts. Happy to help.

Since more people are having an easier time installing the program, I get the feeling that more people are installing the program, successfully, which is great. I don't have any hard facts for that one, sadly. There are a small amount of people that tell me they like the Hard Way of doing things, and Why would I ever change? You're ruining my flawed work flow!, and I don't really know what to tell those folks, except to try the new way, that there is a manual way and it's progress - babe. And also, the previous version is still available if you want Hell, again. I had shipped the installer as the only new feature of the current version, so there's nothing that was missing.

Another hunch I have is that my own services to install the program are dramatically down. I can certainly graph how many installs I do per day/month/whatever, but these numbers are affected by a number of things: the economy, other competing programs, if Burning Man was particularly amazing and how long it takes someone after Labor Day to decompress, etc. This is also fine for me, because I loathe having to install the program for people: it takes a lot of time. I would rather they do it, themselves.

When I do install the program? Guess what, I use the web-based installer too. It's that much better/faster/spiffier. I really wish I created the installer earlier, as the time it took to make the installer would have paid back sooner for the time it's saving me number. I would have like 10 years of that time back, instead of just a month, but whatchagonna do.

But I've now raised the bar on Easiness...es and have a new problem: people who found the installer easy to use, want to upgrade just as easy. 10 years of development of a program, especially when Year 0 I knew not of the ways of Perl and Year 10 I'm still very much an amateur with a Right Hemispherical controlled mind.... things are messy. The config file format sucks, for example. And I have ten years of versions people want to upgrade from.

Should be interesting.

Some notes on the design of the installer:

I basically decided to make the installer as separate from the main program as possible, meaning it has its own library files, it's own template files, it's own ~~testing suite~~ (coming soon, I promise!). It does not use a framework, but uses the modulino approach. Things are fairly tidy.

It's written in a procedural design, because installations and configurations have steps. See? I just listed two of them. I made wrappers around things that deal with system calls - copying/removing files/directories, for example. I was thinking there could/would/should be edge cases for different OS's, but I really haven't found any, but I guess it still gives breathing room for someone much smarter than me to move in and make a better version of whatever I've botched. I did start with just using back ticks to system calls and replace those with perlish alternatives.

So. I'm not sure what stops all of us from making similar web-based installers for our web-apps. I am coming from a field (Art) and a preference for visual things, so I never really gotten a handle on system-admin type of tasks. The trend, it seems, in software is less, Give me as many options to roll my own doo-dad as I can have" and more, "Just freakin' work. And On my phone. When my 2-y/o uses it." I'm a little embarrassed at how much of the code I have is simply crap boilerplate to look up boring things about someone's environment to install. It seems that can all be sweeped under the floor and get some shared code. But then again, there's the rub, huh? If its shared code it's on CPAN, and then, how do you get the CPAN module, without a major compromise? And someone will be brilliant and write it in Moose (which is also, sincerely, brilliant) and there goes the baby, with the bathwater.

2010-03-07T21:28:00.001-08:00

Dada Mail Four Point Zero Point Three Released. Super Duper UTF-8/Unicode Support

Download:

http://dadamailproject.com

What's New

We've been working really really hard to get the UTF-8/Unicode support working well in Dada Mail and this release, we really - no foolin' this time, think we've nailed it.

If you require character set support that's a little more than what's usually found in Latin-based languages, well, this is the release for you. We're going to build localization/internationalization support into Dada Mail, starting with this release. That means, we're going to start translating Dada Mail into multiple languages.

This release also has some pleasant bug-fixes. We couldn't have done it without your feedback.

Pro Dada Four - Ever: $44

There's only one more week to take advantage of this deal. After that? Gone.

Purchase Pro Dada for a special price of Forty-Four Dollars and your subscription to download Pro Dada and the Dada Mail Manual lasts Forever.

Pro Dada subscriptions are usually for a year. This offer extends your subscription for the entire life of the Dada Mail Project.

Purchase at:

http://dadamailproject.com/purchase/pro.html

This irrational offer lasts until pi day (3/14/2010)

Pro Dada Four Installed - $88

Get Pro Dada installed by us or get any current Dada Mail upgraded to Pro Dada Mail Four, for $88 (regularly $100). We'll keep upgrading it at your request for a year, but you'll have access to the Pro Dada Download and Dada Mail Manual for the life of the Dada Mail project.

Request an Install or Upgrade:

http://dadamailproject.com/installation/request.html

This irrational offer also only lasts until pi day (3/14/2010) - you have week left to submit that installation request.

Dada Mail Turns Ten in 2010

The Dada Mail Project started ten years ago in December of 1999 as a small curiosity and has gradually evolved and developed into an extremely popular programming and conceptual art project. Happy Birthday, Dada Mail.

Dada Mail Four is our latest release. Thanks for everyone's thoughtful feedback in this year-long development effort.

We couldn't have done it without you.

We're looking forward to receiving your feedback on Dada Mail Four.

Good luck!

Justin J
Lead Dadaist
http://dadamailproject.com

Dada Mail Change Log for version 4.0.3

Unicode/UTF-8 Work

We have worked very, very hard to get Dada Mail working with UTF-8/Unicode.

We think we did a pretty good job and you'll have a most amazing experience when comparing this version to any previous version of Dada Mail (ever), but there may be tiny things still to work out.

We need to know about them, don't be shy!

SQL table schema changes!

People who upgrade to 4.0.3 (and any version afterwards, until things change!) should note that the MySQL and PostgreSQL Table Schemas have changed!

You may need to update your own tables, to support UTF-8 (if they aren't already in that encoding).

Activate Black List

We've enabled the setting to active the Black List, by default.

We're also enabling the below settings:

Move Unsubscribed Subscribers Automatically to the Black List
Continue to Allow Subscriptions From Subscribers of Black Listed Addresses

You still have the option to change new lists to the previous behavior and already created lists will have their previous behavior, if Black List Settings have already been edited.

Print List-Specific Headers option Removed

The option, Print List-Specific Headers has been removed from, Mail Sending -Advanced Sending Preferences has been removed, but the functionality has not. All mailing list messages will have these headers.

Send Unsubscription Confirmation Emails (Closed-Loop Opt-Out) - disabled by default

Send Unsubscription Confirmation Emails (Closed-Loop Opt-Out) has been disabled by default (you can still enable it)

This option, when enabled, requires that when someone wants to unsubscribe, they have to confirm this unsubscription by clicking on the unsubscription confirmation link in a URL sent their subscribed address.

When disabled (the new default), they simply have to fill out the subscribe/unsubscribe form.

Subscription and Unsubscription links now include an Email Address

When available, both the Subscription and Unsubscription links will have the potential subscriber's (or unsubscriber's) email address in the link itself, so that the user does not have to do the two-step of first following the link and then typing in their email address.

These links are created per-subscriber (or potential sub/unsub), when you use the:

http://dadamailproject.com/cgi-bin/dada/mail.cgi/s/dada_announce/example/example.com/

or,

http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dada_announce/example/example.com/

tags. Previously, these tags only provided a link to the subscription/unsubscription form, without the email address embedded within the link itself. There is no way to revert this behaviour, but you can still roll your own links, like this:

Subscription Link:

/s/

Unsubscription Link:

/u/

Unsubscription Links Now Mandatory for Mass Mailing Messages Dada Mail will now do a quick check to make sure that there is a Dada Mail Unsubscription link in your mass mailing messages, before sending them out.

If one is not found, one will be automatically appended to the end of your message.

It will not be very fancy.

We suggest that you make sure that you have a real, valid, Dada Mail unsubscription link in your Mailing List Messages.

Bug Fixes 4.0.3

Send newest archived message may have outdated header information

http://github.com/justingit/dada-mail/issues/issue/30

pop3 username/password not saved when "Save, Then Test..." button pressed in Sending Preferences

http://github.com/justingit/dada-mail/issues/issue/29

Beatitude: Months are listed out of order

http://github.com/justingit/dada-mail/issues/issue/28

profile field names can contain more than just ascii letters, numbers and underscores

http://github.com/justingit/dada-mail/issues/issue/27

list short names can contain more than just ascii letters, numbers and underscores

http://github.com/justingit/dada-mail/issues/issue/26

Beatitude: Scheduled List Not in Any Useable Order?

http://github.com/justingit/dada-mail/issues/issue/16

Dada Bridge: Spam Assassin Level Picker isn't available

http://github.com/justingit/dada-mail/issues/issue/21

Sending Preferences don't correctly state if you can use Use Secure Sockets Layer (SSL) for POP-before-SMTP

http://github.com/justingit/dada-mail/issues/issue/24

Double Subscriptions when using List Invitation

http://github.com/justingit/dada-mail/issues/issue/23

Archived messages not templated out in publicly displayed archives

http://github.com/justingit/dada-mail/issues/issue/20

*Link to edit subscriber information broken when using the search

http://github.com/justingit/dada-mail/issues/issue/19

Unsubsciption Notice to List Owner doesn't have subscriber (profile) fields

http://github.com/justingit/dada-mail/issues/issue/18

Disabled Menu items return server error when using the, "Classic" session type

http://github.com/justingit/dada-mail/issues/issue/15

Experimental Dada Mail w/unicode ¡Support! Released

2010-02-23T22:33:00.000-08:00

(this is a repost from here, 'cause I'm pretty stoked on it)

This is the first step in the localization project, since we can't very well translate Dada Mail if Dada Mail can't use the translations available.

I have to let this project rest for a little bit (and collect my wits - it was a very difficult step!) but any and all feedback is welcome, if you'd like to give this a spin - bug reports/problems of any kind are very much appreciated.

This version of Dada Mail should basically be able to support any language that can in the unicode characters set and UTF-8 encoding. Which, should be, well, a lot of them. It doesn't (Dada Mail), but where it fails? I don't know - but it's a good time to test and see where it's wrong.

For simple Euro-centric stuff, like this:

Je peux manger du verre, ça ne me fait pas mal.

It should be fine. For something a little more wild:

أنا قادر على أكل الزجاج و هذا لا يؤلمني.

(which should be Arabic)

Well, I can only go on if something visually looks correct :) Even this email is sort of a test - I don't know if it's going to work, or not - so, fingers crossed! If it does - we're on a good track, since Dada Bridge taking a random email, having it go through the system that's mostly tested using a very specific way of creating emails and coming out readable on the other side is a great big step - not even talking about the online archive, rss/atom feeds, twitter thingie, etc, etc, etc.

Here's the download to the version I'm now running at the Dada Mail support site:

http://github.com/downloads/justingit/dada-mail/dada-4_0_2-unicode.zip

http://github.com/downloads/justingit/dada-mail/dada-4_0_2-unicode.tar.gz

If you want to check it out via github, the branch is at:

http://github.com/justingit/dada-mail/tree/charset_work

To grab it with git, you have to do this:

git clone git://github.com/justingit/dada-mail.git
cd dada-mail
git fetch
git checkout --track -b your_local_branch_name origin/charset_work

Here's the explanation of all that:

http://groups.google.com/group/github/browse_thread/thread/71f944b925467ab6

There's a guide of what to expect with Dada Mail and unicode/UTF-8 you can read here:

http://dadamailproject.com/support/documentation-4_0_2-unicode/features-UTF-8.pod.html

Which I'll paste the contents of at the end of this message - but you may also want to compare it to the version of this doc for 4.0.2 STABLE:

http://dadamailproject.com/support/documentation-4_0_2/features-UTF-8.pod.html

(Long story short: 4.0.2 UTF-8/Unicode Support: "uhh...")

And, that's about it. This was a hard part of the project, since this is a 10+ y/o codebase - it very much pre-dates even unicode/UTF-8 support in Perl itself, so there's a reason, I guess, why the program was in such bad shape when it came to support it. Many,

many many bugs showed themselves, once this feature was asked for. I think a great majority of them have been solved.

Give it a spin if this interests you and if I can help out with anything, let me know,

--
Introduction

Dada Mail can speak UTF-8 and almost expects that everything else around it does, too.

That means:

• It treats everything it handles as UTF-8
• Everything it returns is in UTF-8
How To Have a Pleasant Experience

If you're installing Dada Mail for the first time, there's nothing you'll need to do, but below are some great guidelines on how to keep your lists configured, so you continue to have a good experience.

If you're upgrading, make sure your configuration reflects the advice below.

It's heavily advised to keep everything in Dada Mail speaking UTF-8 without any real exceptions.

Config Variable: $HTML_CHARSET

By default, the config variable, $HTML_CHARSET is set to, UTF-8

Keep it that way, same case (UTF-8) - same everything.

Dada Mail is only tested with the charset set this way.

Advanced Sending Preferences

Default Character Set

Set this as, UTF-8 UTF-8

Default Plain Text/HTML Message Encoding

There's really only a few choices recommended for Dada Mail.

• 8bit
Should work.

• quoted-printable

If you have any trouble with 8bit, try quoted-printable. Because of the amount of time that Dada Mail creates, tweaks, formats and templates out email messages, the encoding can potentially get mucked up.

This potential mucking-up is mitigated when Dada Mail uses quoted-printable encoding internally. This should be the default for email messages.

Encode Message Headers

Have this option checked.

SQL Backends

Database

PostgreSQL

Encoding for PostgreSQL databases is done when the database is created - make sure to create your database with a, UTF-8 encoding, like so:

CREATE DATABASE dadamail WITH ENCODING 'UTF-8'
MySQL

Nothing you'll have to do.

SQLite

Nothing you'll have to do.

DBM Files

DBM Files have no encoding support, but Dada Mail knows this and compensates.

Schema

MySQL

The MySQL schemas are set to create tables with an encoding of, UTF-8

PostgreSQL

Nothing has changed.

SQLite

Nothing has changed.

Drivers

The current support SQL backends, mysql (MySQL), Pg (PostgreSQL) and SQLite all have different ways to somewhat, "enable" their UTF-8 support.

• MySQL
add,

mysql_enable_utf8 => 1,
has been added to the $DBI_PARAMS hashref.

• PostgreSQL
add,

pg_enable_utf8 => 1,
has been added to the $DBI_PARAMS hashref.

• SQLite
add,

sqlite_unicode => 1
has been added to the $DBI_PARAMS hashref.

No explicit encoding/decoding is done in Dada Mail when saving/retrieving data. Hopefully, the drivers are UTF-8-aware enough.

Plugins/Extensions

The Plugins and Extensions that come with Dada Mail have not been as thoroughly tested as the main program. There's still warts.

Dada Bridge

Dada Bridge has a unique position needing to handle a lot of different stuff thown at it and deal with it gracefully. Dada Mail does, in fact, handle, any realistic character set/encoding you throw at it, but Dada Mail will convert messages it receives to its internal format, before it resends it out to your list.

This means the encoding of your choice (8bit or quoted-printable) and the charset of your choice (as long as your charset is, UTF-8)

Upgrading

You are potentially going to have problems.

Its possible that, since List Settings were never decoded/encoded correctly in past versions, they'll show up the program (once you've upgrade) incorrectly. The easiest thing to do is to edit the mistakes and resave the information. For most of the program, you're going to have to manually export the information and re-import it with the correct encoding, sadly. Dada Mail will probably fail gracefully with old information, but it's possible that you'll see squiggly charaters, instead of what you want to see. There's nothing in Dada Mail that will stop this from happening. If you experience it (from old information), we're not going to count it as a bug, but rather a known issue.

Problems?

Please let us know via the Support Boards:

http://dadamailproject.com/support/boards/

Or the developer mailing list:

http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev/

Thanks!

See Also:

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

http://www.joelonsoftware.com/articles/Unicode.html

• perlunitut - Perl Unicode Tutorial

http://perldoc.perl.org/perlunitut.html

• perlunifaq - Perl Unicode FAQ

http://perldoc.perl.org/perlunifaq.html

--

Post:
mailto:dadadev@dadamailproject.com

Unsubscribe:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/

List Information:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev

Archive:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/archive/dadadev

Developer Info:
http://dev.dadamailproject.com

Perl HTML::Template and UTF-8 Unicode

2010-02-20T14:19:00.001-08:00

HTML::Template does not support file encoding:


#!/usr/bin/perl -w
use strict;
use Encode;
use HTML::Template;
my $template = HTML::Template->new(
filehandle => *DATA,
);
print Encode::encode('UTF-8', $template->output);
__DATA__
¡™£¢∞§¶•ªº

prints, Â¡â„¢Â£Â¢âˆžÂ§Â¶â€¢ÂªÂº (or something like that!)

In the example above, this makes sense, since we're printing on an open filehandle (even if it's only to our magical, DATA) that we didn't put a file layer filter thingy to. That's easy to fix:


#!/usr/bin/perl -w
use strict;
use Encode;

binmode DATA, ':encoding(UTF-8)';

use HTML::Template;
my $template = HTML::Template->new(
     filehandle => *DATA,
);
print Encode::encode('UTF-8', $template->output);
__DATA__
¡™£¢∞§¶•ªº

prints, ¡™£¢∞§¶•ªº, yay!

This also works if we want to just pass a reference to a scalar to HTML::Template:


#!/usr/bin/perl -w
use strict;
use Encode;
my $content    = "\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}";
use HTML::Template;
my $template = HTML::Template->new(
     scalarref => \$content,
);
print Encode::encode('UTF-8', $template->output);

prints, ¡™£¢∞§¶•ªº, yay!

This doesn't work, if we want to just give it a name of a template file. This is really useful, since HTML::Template has a feature to allow you to search through a file structure (or at least an array of directories, looking for the file).

And this is where encoding madness begins.

Cause I know what you're thinking, just treat HTML::Template's output like information that's coming from outside your program (since, if you're using a template *file*, it kinda is).

So, all you need to do is decode (this is the WRONG WAY to solve the problem, but let's just make that mistake...) the return value of ->output, like this:


#!/usr/bin/perl -w
use strict;
use Encode;
my $content = "\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}";

my $filename = 'utf8string.tmpl';

open my $fh, '>:encoding(UTF-8)', $filename or die $!;
print $fh $content;
close $fh;

use HTML::Template;
my $template = HTML::Template->new(
     filename => $filename,
);

my $output = $template->output;
$output = Encode::decode('UTF-8', $output);

print Encode::encode('UTF-8', $output);

prints, ¡™£¢∞§¶•ªº. Yes.

But... what if you have a variable (it is a templating system) and the variable in the param() you pass has UTF-8 strings? MUAHAHA!


#!/usr/bin/perl -w
use strict;
use Encode;
my $content = "
<!-- tmpl_var one -->
\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}
";

my $filename = 'utf8string.tmpl';

open my $fh, '>:encoding(UTF-8)', $filename or die $!;
print $fh $content;
close $fh;


use HTML::Template;
my $template = HTML::Template->new(
     filename => $filename,
);
$template->param(
one => "\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}",
);

my $output = $template->output;
$output = Encode::decode('UTF-8', $output);

print Encode::encode('UTF-8', $output);

Cannot decode string with wide characters at /System/Library/Perl/5.10.0/darwin-thread-multi-2level/Encode.pm line 162.

Bahahaha!

Take those decode/encode lines (I know it looks strange to one, right after the other ) and you'll still get a weird output:


¡™£¢∞§¶•ªº
Â¡â„¢Â£Â¢âˆžÂ§Â¶â€¢ÂªÂº

Darned if you do/don't. Those two lines should have the same string. They don't. No amount of encoding/decoding is going to help.

The trick, other than tweaking HTML::Template's source to include file filter layer thingamabobs, is to decode the contents of the file it opens up.

How to do that.

Trolling through the HTML::Template mailing list archives leads to the idea of using a HTML::Template filter that matches everything, that then does our decoding:


#!/usr/bin/perl -w
use strict;
use Encode;
my $content = "
<!-- tmpl_var one -->
\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}
";

my $filename = 'utf8string.tmpl';

open my $fh, '>:encoding(UTF-8)', $filename or die $!;
print $fh $content;
close $fh;


use HTML::Template;
my $template = HTML::Template->new(
     filename => $filename,
     filter => [
       { sub => \&decode_str, format => 'scalar' },
     ],
);
$template->param(
one => "\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}",
);

my $output = $template->output;


print Encode::encode('UTF-8', $output);



sub decode_str {
my $ref = shift;
${$ref} = Encode::decode('UTF-8', ${$ref});
}

This sort of lines up all the data to be UTF-8 encoded and aware and all that stuff that the unicodefaqthingy perldoc tells you to do.

But, oh, it gets better.

DON'T use that filter trick thing if you're using a scalarref, or a properly encoded file handle! You'll get a nice error, like this:

HTML::Template->new() : fatal error occured during filter call: Cannot decode string with wide characters at /System/Library/Perl/5.10.0/darwin-thread-multi-2level/Encode.pm line 162.
at /Library/Perl/5.10.0/HTML/Template.pm line 1697
HTML::Template::_init_template('HTML::Template=HASH(0x1008aafb8)') called at /Library/Perl/5.10.0/HTML/Template.pm line 1238
HTML::Template::_init('HTML::Template=HASH(0x1008aafb8)') called at /Library/Perl/5.10.0/HTML/Template.pm line 1124

Brilliant.

So I don't know what the best advice is to give. If you're passing the template as a scalarref, DON'T use that filter, unless you want to, perhaps encode your template beforehand (which makes little sense?)

If it's a filename, use that filter trick perhaps (or edit the sourcecode of HTML::Template).

Perl, UTF-8 Email Messages, MIME::Enity and QuotedPrintable encoding

2010-02-15T16:48:00.001-08:00

Some findings after much bashing of head:


#!/usr/bin/perl -w
use strict;

use MIME::Entity;
use Encode;

# My UTF-8 string -
# ¡™£¢∞§¶•ªº
# Basically using Mac OS X, just hold down the alt/option key and hit the 1 through 0 keys, in succession:
#
my $content    = "\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}";

# Build the message, using MIME::Entity.
# MAKE SURE TO ALWAYS encode('UTF-8', 'string') BEFORE ADDING
# Always.

my $pt_entity = MIME::Entity->build(
 Type    => 'text/plain',
 Data    => Encode::encode('UTF-8', $content),
 Encoding => 'quoted-printable',
);



# MAKE SURE TO ALWAYS decode('UTF-8', 'string') BEFORE WORKING WITH STRING
# Always.
my $new_content = $pt_entity->bodyhandle->as_string;
$new_content = Encode::decode('UTF-8', $new_content);

# For example, we're just going to reverse it:
$new_content = reverse($new_content);




my $io = $pt_entity->bodyhandle->open('w');

# YES. You will will need to encode content using the bodyhandle. Always.
# Always.

$new_content = Encode::encode('UTF-8', $new_content);
$io->print($new_content); 
$io->close;
$pt_entity->sync_headers(
 'Length'      =>  'COMPUTE',
'Nonstandard' =>  'ERASE'
);


# And, that's it.



# Before using the content, decode
# Always.
my $result =  $pt_entity->bodyhandle->as_string;
$result = Encode::decode('UTF-8', $result);


# Always encode, before printing.
# Always.
#
# prints, ºª•¶§∞¢£™¡
print Encode::encode('UTF-8', $result);

The trick is to always, always, always encode your data, before creating any sort of entity using MIME::Entity and to always, always always decode the data you get using bodyhandle()

This workflow is strange, since you're told not to encode data, until you're ready to print it. I suspect there's some weird IO::File stuff going on with MIME::Entity (and friends), or, want to think of saving binary data, instead of characters when creating MIME stuff. I don't know.

If you do not encode before, MIME::Entity will barf, when using the quoted/printable encoding, but will probably be just fine with, "8bit" encoding.

This was a huge headache to figure out.

This will all seem to work out, if you don't do that first encode:


#!/usr/bin/perl -w
use strict;

use lib qw(/Users/justin/Documents/DadaMail/git/dada-mail/dada/DADA/perllib);

use MIME::Entity;
use Encode;

# My UTF-8 string -
# ¡™£¢∞§¶•ªº
# Basically using Mac OS X, just hold down the alt/option key and hit the 1 through 0 keys, in succession:
#
my $content    = "\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}";

# Build the message, using MIME::Entity.
# MAKE SURE TO ALWAYS encode('UTF-8', 'string') BEFORE ADDING
# Always.

my $pt_entity = MIME::Entity->build(
 Type    => 'text/plain',
# Data    => Encode::encode('UTF-8', $content),
 Data    => $content,
 Encoding => 'quoted-printable',
);

my $s =  $pt_entity->bodyhandle->as_string;

$s = Encode::decode('UTF-8', $s);

# Let's do a little string manip:
$s = reverse($s);

$s = Encode::encode('UTF-8', $s);

print $s;


Cannot decode string with wide characters at /System/Library/Perl/5.10.0/darwin-thread-multi-2level/Encode.pm line 162.

exception_handler::die     in Encode.pm at line 162
Encode::decode     in test7.pl at line 28

So do that first encode, please. If you don't follow this formula, your prog may work, until that last encode:

 
#!/usr/bin/perl -w
use strict; 

use lib qw(/Users/justin/Documents/DadaMail/git/dada-mail/dada/DADA/perllib); 

use MIME::Entity; 
use Encode; 

# My UTF-8 string - 
# ¡™£¢∞§¶•ªº
# Basically using Mac OS X, just hold down the alt/option key and hit the 1 through 0 keys, in succession: 
#
my $content    = "\x{a1}\x{2122}\x{a3}\x{a2}\x{221e}\x{a7}\x{b6}\x{2022}\x{aa}\x{ba}";

# Build the message, using MIME::Entity. 
# MAKE SURE TO ALWAYS encode('UTF-8', 'string') BEFORE ADDING
# Always. 

my $pt_entity = MIME::Entity->build(
 Type    => 'text/plain', 
# Data    => Encode::encode('UTF-8', $content),
  Data    => $content, 
 Encoding => 'quoted-printable',
 );

my $s =  $pt_entity->bodyhandle->as_string; 

# NAW, we don't need that
# $s = Encode::decode('UTF-8', $s); 

# Let's do a little string manip: 
$s = reverse($s); 

# Well, that's silly! We don't need that one, either! 
# $s = Encode::encode('UTF-8', $s); 

print $s;

 
Wide character in print at /Users/justin/Desktop/test7.pl line 37.

And, you will do what I do, and bang your head, some more.

I couldn't fine any info on how to handle things like MIME::Entity and UTF-8 encoding, in the excellent articles available such as this one:

http://ahinea.com/en/tech/perl-unicode-struggle.html

and,

http://perlgeek.de/en/article/encodings-and-unicode

and,

http://juerd.nl/site.plp/perluniadvice

I have this article labeled as, "do not trust"

http://kbinstuff.googlepages.com/perl,unicodeutf8,cgi.pm,apache,mod_perla

Because it states,

6.1. Encode::encode/decode

For start, you should avoid using Encode::encode/decode/from_to to the greatest possible extent in your scripts. This will only lead to great confusion later. You may think you have gotten everything to work, but then a week later, you shall only add a little more functionality to your work and suddenly, everything falls apart and doodles will appear on your web pages.

I guess I understand what they mean - but you'll need to encode your UTF-8 stuff before it exits your program. Always. And, you have to decode UTF-8 info that goes out of your program. Always. How do you do this? Uh-huh, the Encode module.

Like it says in the perldoc for unicode. So, I don't know what this page is yabbering about. I'm sure, behind the scense, Encode is used when open files with a specific encoding:

http://perldoc.perl.org/perluniintro.html#Unicode-I/O

Which, by the way of features, is a pretty rad one.

ANNOUNCE: Dada Mail 3.1 alpha 3 Released

2009-08-27T22:49:00.000-07:00

(I thought I'd re-post this announcement, since I don't think many people in the perl community really know about this large project. It IS NOT Modern Perl written, as it dates back to even before Perl 5.6, but it's a very large and complex Perl program, that's still sorta/kinda easy to install. (Royal) we try.

Dada Mail 3.1 alpha 3 Released

After a month and a half of more development from the last release, Dada Mail 3.1 alpha 3 has been released.

Download

tar.gz:

http://github.com/justingit/dada-mail/tarball/v3_1_0_alpha3-08_26_09

zip:

http://github.com/justingit/dada-mail/zipball/v3_1_0_alpha3-08_26_09

Changes

To get caught up in what's changed, please see:

Dada Mail 3.0 to 3.1 Changelog

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/changes_3.0_3.1.pod.html

Dada Mail 3.0 to Dada Mail 3.1 Guide

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/dada3_0_to_dada3_1.pod.html

An overview of some of the new features, including:

Dada Profiles (BIG Feature)

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/features-profiles.pod.html

Multiple Mailing List Sending

http:///dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/features-multiple_list_sending.pod.html

(VERY initial) UTF-8 Support

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/features-UTF-8.pod.html

If you plan on upgrading, please also see the 3.0 to 3.1 migration tool:

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/dada_3_to_dada_3.1_sql.pl.html

which should make things a little more pleasant.

There's also more development docs for the new API, including:

DADA::Profile

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/Profile.pm.html

DADA::Profile::Fields

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/Profile_Fields.pm.html

DADA::Profile::Session

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/Profile_Session.pm.html

DADA::ProfileFieldsManager

http://dadamailproject.com/support/documentation-dada-3_1_0-alpha_3/ProfileFieldsManager.pm.html

What is Dada Mail?

Dada Mail is a completely contemporary, mature and intuitive web-based e-mail list management system, which runs on most any Unix-like hosting account that can run custom CGI scripts (details). Dada Mail is also a conceptual art project.
Dada Mail handles Closed-Loop Opt-in/Opt-out subscriptions, sending complex announce-only and/or discussion mailing list messages with an advanced, fault-tolerant mass mailing monitor, supports the archiving/viewing/searching/resending/syndicating (rss, atom) of sent messages and doing all this and a whole lot more with style.

Dada Mail can handle custom subscriber fields and you can use the information it captures for partial list sending based on a query and Dada Mail's email templating system allows you to create targeted and completely custom email messages for each and every one one of your subscribers.

Dada Mail is bundled with additional plugins and extensions to extend Dada Mail's capabilities. Some of the plugins/extensions support advanced bounce handling, clickthrough tracking, mass mail scheduling, blog interfaces of archived messages, AJAX subscription form trickery and lots of other surprises.

Dada Mail produces XHTML valid web content and sticks to best practices when creating email messages. Write Once: Distribute Everywhere. Dada Mail is free software that you're able to use, modify, share and enhance under the terms of the GNU General Public License. Dada Mail is written in Perl because we love Perl.

A Logo design for Rakudo Perl 6

2009-01-22T17:48:00.000-08:00

The below is a post I started on perl6-users@perl.org and is amended by the last weeks of replies.

I'm posting it below to garner a few more eyeballs, before I go from a, "research" stage to a, "playful" stage of trying simple things out and seeing if anything makes sense.

If you're a part of the Perl community, I'd love to hear your input as a Kaduo Perl 6 logo may be something you'll see almost every day:

Hello everyone,

A few weeks ago, probably more than I want to admit (but here! See! My Notes! I've been up to something!), there was one of those, "OMG! Perl is going to DIE!" threads, somewhere and the, "Well, do something about it" call came out, and I sort of replied, "well, alright" and gave my open ended hand to some design work.

Moritz was one of the first to guide it to the idea of making a logo for Rakudo Perl 6 - as there's nothing yet (really) available. I thought that would be a neat project and scratch some of my person itches.

A slight background on me: I'm that guy:

http://xkcd.com/519/

(Although, there should be two more columns for, "Skateboarding" and, "Rock Climbing" in there). I really started working with Perl during a internship in college which started me in a full time job doin' the stuff, which got me to where I am today: just working for myself.

In all of that, I also managed to get through Art School (guess what paid for *that*!). A lot of my work deals with language and text, writing and communication. Some of my work bordered on generative work, but most of it stayed on the canvas, as I wanted to go to school to learn to paint.

Anyways, I've always wanted to help out on larger-than-myself Perl projects, but, although I think my perl-fu is, well, alright - it's not wizard-like. But! I think an interesting niche that I could fill is as someone who, "gets" Perl and it's wonderful and varied culture and also, "gets" visual communication and all that. I am a firm believer that a healthy community is one full of diversity and successful projects come not out of one genius, but of many just normal people, and that's me: just a normal person.

Here's some notes I've collected about what people have said Rakudo Perl 6 is, which is a good baseline on what a logo should try to reflect and communicate:

Rakudo Perl is:
Perl 6 on Parrot
Rakudo as a *implementation* of a *specification*
Rakuda-do (Japanese): Way of the Camel
Rakudo (Japanese): Paradise

Camels, Paradise/Oasis, etc. It's good visuals and it's easy to digest. Camels are mean and smelly close up, but we don't have to get all that close - it's good to remember they're also extremely useful and in some places, absolutely critical to ways of life.

It also doesn't stray far from the original Perl 5 image of Camels and Pyramids and all that jazz. The Japanese lean on all this seems important too, perhaps to get a little more mindshare from the folks that find Ruby interesting and attractive (more on that in just a little bit)

One of the main fears with this name, "Rakudo Perl 6" - at least when it first came out, is that describing Rakudo Perl as, "An implementation (one of possibly, many) of the Perl 6 Specification, built on top of the Parrot Virtual Machine", will leave people going,

"Huh?!"

I think this is a good reason as anything, to think of getting a visual representation of this, somewhat complicated idea out ASAP.

It's interesting that Japanese Word(s) were chosen as the new name - it's grown on me - I like it. Japanese Art and Poetry has the idea of the, "haiga" and the, "gō" - which is sort of like a pen-name, but it changes if there's a change in the style of the artist during their career. You could think of, "Rakudo" as a new, "haiga" for Perl - at least the concept makes things clear to me: we've changed course, but it's still the same hand.

I was also, incidentally, doing some research on the origins of the Latin alphabet - I'm very curious about languages in general - mostly how they're abused in media and popular culture, but also in learning new ones - I took a brief stint solo in France armed with a 5 week Free University course in French to see how well I could get along. Eye-opening.

I happened upon the book, "Mysteries of the Alphabet" (Narc-Alain Ouknin - originally written *in* French) in the shelves of someone I was hanging out with. It's main thesis, really is the Latin/Greek alphabet started with something they term the, "Proto-Sinaitic" alphabet, which was created around the time the lost tribe of Israel was figuring itself out. Moses and all.

One of the, well, the third letter in their alphabet is, "gimmel", which comes from the word gamel, which, if you didn't guess already means, "Camel"! It looks either like the neck of a camel - or, perhaps it's hump. If you think of, "gimmel" as our, "C" you can sort of still see a hump of a camel, if you just turn the, "C" 90 degrees, clockwise.

Early written languages like Proto-Sinaitic are sort of the beginning where pictograms that stood for what things looked like, where changed into a way of writing about an idea - a lot of these early letters still hold a lot of the original meanings. Hebrew, for instance still does and each character is rich in back history. I like the Proto-Sinaitic link, since it's less loaded quite as intensely as Hebrew, which is invariably tied to major traditions and religions.

The, "Gimmel" character is no exception. Start from, "Mysteries of the Alphabet"
------------------------------------------------------------------------------
:: Original Meanings
Carrying the Primal Power beyond, outside the domestic setting

:: Derivative Meanings
Outgoing, break, carry to another, do good, return a favor

:: Acquired Meanings, Perpetuated By The Hebrew Language

Ripen, Ween, Enable to ripen
Release Oneself, Break Away From
------------------------------------------------------------------------------

Which I think beautiful illustrates a nice connection between Perl 5 and Perl 6, Rakuda-do/Rakudo and haiga pen-names - and the, "Big Picture" of what exactly Perl 6 is all about - standing apart from the lineage, but still being, well, "Perl", using the Camel (gimmel) as a fundamental icon from way WAY back in time there -

and it all sounds so Perlish of picking and choosing the best from many ideas and languages.

Taking a step back from this soup of ideas and thinking of a logo itself, it seems that it would help to produce something that's made of somewhat interlocking and inter-related pieces: Perl on Parrot has two separate pieces that come together and complete an idea. But there's other things that could take, "Perl's" place, so it's really,

$x on Parrot

It seems that if a logo would be made, we can modularize, say, that Parrot part and use it for other things - same with the Perl part, if you get into it. Modularization is a way of getting ready for the future. It also allows us to be lazy: we can use other people's work already and - well, you all know this already. It would be an interesting idea to use common programming best practices in the logo of Perl itself.

I bring that all up, because when I look at the various Perl projects, they all look extremely interesting, but fragmented. It would almost make sense to create a logo where pieces can be reused for related thingies. Starting from a logo for Rakudo Perl, one could make a simple Style Guide even, with easy-to-acquire graphic elements that say, an application written using Rakudo Perl could use (at their discretion) to enhance their own project and tie it back into Rakudo Perl (and Perl in general).

So that's sort of the other thing I'm proposing: not only designing a logo for Rakudo Perl, but having the concept of modularization of the logo's basic elements part of the logo design itself and the sharing and remixing of the design elements for related projects, to help strengthen the, (and I'm not a fan of using this word) "branding" (sigh) of Perl and making it not so much the "invisible language that glues everything together", but have it where it belongs: in a positive light with the general (geeky) public.

Right now, all that means to me is perhaps a simple style guide and the image and graphic resources easy to grab in open formats. This also means that simple-is-better when it comes to the design of all these different elements of the logo, as they'll be combined in interesting ways and things will have a tendency to be cluttered. Simplification also lends itself to universality: the simpler the idea is, the more we relate ourselves *to* the idea itself.

Finally, the design of the Rakudo Perl logo should lend itself to change. Just like any other part of the project, the ideas and concept and what the darn thing actually look like should be able to move and change quickly - to be able to be upgraded - hey, why not? I'm not interested in, "owning" the design, but am more interested in playing a part in shaping the whole. And all that stuff. Just like in code, some people do more than adopt a project.

What I really *really* need now is some feedback for any and all of the above research and braindump. This, obviously, is just one regular guy taking the first jump into something a whole lot bigger and more complex than he can even really imagine. The first step is the hardest and the most confusing - the rest of the journey is mostly, one foot in front of the other, until the end,

Here's a few important notes about the above:

Love Marks vs. Trademarks:

Sounds like a great idea. Go for it. Here is a document I prepared for Larry Wall and the Perl Foundation about a trade mark strategy for Perl. You may find some ideas in here to help - I like your idea of interlocking imagery etc.

http://thegoo.org/love-marks-for-perl.pdf

This document encourages the use of memorable, positive, interconnected trademark. The Perl Foundation will be the custodian for such a mark. This is all wonderful. I don't have any problems with giving over the rights for the project to TPF and Perl at large - sort of the point, really.

This is also a very important part of the document above:

If the Perl Community accidentally borrowed “The Camel” it appears O’Reilly accidentally borrowed
the domain name “perl.com”. Goodwill continues to accrue in the trade mark “PERL” and that
goodwill, including any domain names needs to be directed to its rightful owner: TPF.

With the Rakudo Perl 6 logo, we don't want to add even more confusion - Camels, it seems are out. I wouldn't mind a gesture of a camel-like idea - for example, my gimmel idea above, but that idea may just be a stepping stone for something much large - for example, trading the Rakudo Perl 6 logo as a type of primitive written alphabet, which can be combined, with descretion with other people's and project's ideas.

I think, at least in the "playful" stage, the camel be used as a design element, just because it could lead to more interesting things.

BUT - Richard Dice of the Perl Foundation does make this situation absolutely clear:

O'Reilly is the only organization that can have trademarks that incorporate
a camel in reference to the Perl programming language. This statement is a
first-order approximation, but damn good one. Basically, the message is:
stay away from using camels

Patrick Michaud had this to say:

I'll start with my summarized thoughts first, then a few specifics below.
First, I totally agree that Rakudo Perl needs a logo, and the sooner
we can get one to start using on our website (which we're now creating)
and other materials, the better. So, your thoughts and ideas are
quite welcome.

Beyond that, I think your message has neatly captured many of the facets
of what we're working with (and yes, there are a lot of facets). The
message reminds me of some of Larry's "State of the Onion" addresses --
looking at many sides of the Perl (in this case Rakudo Perl 6) world.

So, my primary comment is that I find myself very much in agreement
with your proposal, and a strong hope that you'll continue on in this
direction. I agree with the idea of the style guide and some simple
elements that people can combine together in very expressive and
beautiful ways. Indeed, it sounds very much like you're proposing
an ideographic system for Rakudo Perl, where can combine graphic
symbols for ideas together. That feels very Perlish and Rakudoish
to me -- I like it.

So, I'd say "press on" and let us see what you come up with. :-)

The more I think about the design problem, the more it it seems that a simple but very flexible solution would be best and that reflecting and taking the actual design process and specification of Perl 6 itself as a major influence would be a great way to go about things.

I can't really speak for what Parrot will want or need, as they already
have a (very nice) logo. But having a symbol to represent Parrot in
the system you propose would likely be very workable.

Exactly!

I may do more research with Patrick and see what the current needs are for a Rakudo logo and how that could be worked with a, "Grand Scheme" as well as start playfully working on some ideas.

What I could use now is a whole lot more feedback. Sound off!

How to handle completely clueless users?

2008-12-01T21:14:00.000-08:00

I admit I'm sort of a email traffic controller.

It irks me to the point of a pet peeve, when I spatter the contact page of my project with notes that say, "DO NOT CONTACT ME FOR SUPPORT UNLESS YOU WANT TO BUCK UP SOME MONEY", and I get tons of support emails, wanting free support.

Sigh.

What I don't want to do, is take the time and go,

"Look. We have forums. We have mailing lists. Use those. Thanks." And then not answer they're question.

What I do is exactly that.

I don't want to do this, because I know how much of a pain it is for the person to now, *rewrite* what they just ask me. It also is a pretty weird introduction to what should be a really valuable exchange - someone actually wants to talk to *me* about *my* thingy.

The curious thing is, I don't want to be hired to fix some stupid bug - I have better things to do. I'd rather help fix the bug for *free* - and its beneficial - users let me know it's there, I (or them - ha!) open up a bug report, it gets fixed (probably by me) and *there's a thread of, "something just happened"* that lives far away from my inbox and takes on a life of its own. I don't have to write the same thing twice and with a little work by the user (or if they dare help themselves) they can find it themselves, and keep a thread going. When I say, "thread" - I mean, anything - a forum post about a problem, with a reply of a confirmation that it's a bug, with a link posted to a bug report, that may then give you a patch in a day or so - which then gets referred in another forum post - etc. But, a trail is there.

The thing is, there's better ways to ask the questions.

What's the better way to point them to the right way?

For a while, I just had a auto responder that said,

"Hey, if this is a support question - go here, and here and here and read this and that and then post to this thing or that thing and away you go! America!"

"...but, if this isn't a support question, well, disregard all that, and I'll get back to you, soon"

That seemed a little foolish.

Right now, I'm trying something different - I'm just making up a mail template that first, welcomes the new person emailing me to the *community* and then gives a very brief list of resources that say, "Here's what to read", "Here's where to ask questions"

Then,

well, then if I can, I'll answer they're question - I haven't yet said, "And next time, POST HERE", cause again, that makes me think I'm reprimanding someone for something they may have just missed. Or something. Anyways - let's think positive and we're all humans here, and we probably all have a strong sense to belong.

But, what I want to do is get people active in the program and community. It's pretty hard, since, well, usually my audience is general users and they just have Work They Need To Do, and aren't nerdy enough to get excited about some program. Understandably.

Perhaps, by simply giving a welcome, some encouragement, some links to check out and a head-start on solving the problem, they'll feel as if they're welcome in a community, instead of just a bother to me.

As far as I'm concerned, community in anything is everything. If you're not building a community, you have almost nothing, no matter how great you are, you have nothing without people.

Anyways, I'll let you know how it goes, but I'd be interested in hearing other ideas you yourself may have,

Problem with Email::Valid and newlines

2008-10-08T02:31:00.000-07:00

Found a strange problem in Email::Valid:

 
#!perl
use strict;

use Test::More tests => 4;

BEGIN {
 use_ok('Email::Valid');
}
my $email;

$email = 'withnewline@example.com' . "\r";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\r" at the end return undefined');
diag(Email::Valid->address(-address => $email));

$email = 'withnewline@example.com' . "\r\n";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\r\n" at the end return undefined');
diag(Email::Valid->address(-address => $email));

$email = 'withnewline@example.com' . "\n";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\n" at the end return undefined');
diag ("'" . Email::Valid->address(-address => $email) ."'");

From what I expect, that last test should pass. Email::Valid's docs do say that if address can munge the address, it'll return the munged address, instead of undef - but I have munging (or "fudging, in this module" *off* - as it is off by default). Carriage returns aren't munged, so why newlines?

Perhaps it's the last line in the module:

 
# Regular expression built using Jeffrey Friedl's example in
# _Mastering Regular Expressions_ (http://www.ora.com/catalog/regexp/).

$RFC822PAT = <<'EOF';
# Possibly the most insane regex... possible
EOF

$RFC822PAT =~ s/\n//g;

The test for validity changes the actual string being validated. Drrrrr.

And that kind of brings up another point: Why is a module called, Email::Valid and its validating method (address) also doing double-duty with wanting to munge the string I give it so it may possibly be validated? Sounds like you just need to methods there, validate() and, gimme_back_an_address_if_at_all_possible(),

or,

whatever.

Perl Semaphores 'n stuff

2008-10-05T23:31:00.002-07:00

This is a pretty good and gentle introduction into file locking and using semaphores in Perl:

http://interglacial.com/~sburke/tpj/as_html/tpj23.html

I was having the exact problems being described:

Unfortunately, this means trouble for our flock-using code. Notably, there can still be a problem with instances being out of phase — since we can’t lock a file without already having opened it, things can still happen in that brief moment between opening the file and locking it. Consider when one instance is updating counter.dat just as another new instance is about to read it:
Instance 1                         Instance 2
-----------------                   -----------------
open COUNTER, ">counter.dat"
or die "Can't write-open: $!";
                                  open COUNTER, "<counter.dat"
                                   or die "Can't read-open: $!";
                                  flock COUNTER, LOCK_EX;
                                  my $hits = <COUNTER>;
                                  close(COUNTER);

flock COUNTER, LOCK_EX;
There, the OS dutifully kept two instances at once from having an exclusive lock on the file. But the locking is too late, because instance 1, just by opening the file, has already overwritten counter.dat with a zero-length file, just as instance 2 was about to read it. So we’re back to the same problem that existed before we had any flock calls at all: two processes accessing a file that we wish only one process at a time could access.

In a very very complex part of my app, that has to do with basically managing a queueing system - something that really really really should be written using a transaction capable SQL backend. If only I knew how to do that.

I combined the semaphore file with the, Highlander, THERE CAN BE ONLY ONE! Idea:

http://perlmonks.org/?node_id=14260

http://www.stonehenge.com/merlyn/WebTechniques/col54.html

So if I can't get a lock, I can wait a little longer. I thought, "Hey, sounds like a good idea". It also sorta kinda puts a queueing system to the resources that a lot of different thingies want to hit, and hopefully, stop the programming from giving back errors like, all the fucking time. We'll see.

All the tests pass (you do write tests, right?), but using the app doesn't really... um, work. It's timing out. Most likely from the Highlander idea. More whackin' to do...

Nerd!

2008-10-05T23:31:00.001-07:00

I've decided what computer programming is to me at the moment:

It's a hobby. It's a hobby that currently pays my bills, but to call it a job or a company that I have is not what's going on. I know this, because I explicitly attempt not to do what companies attempt to do really really well. One of these things is to try to sell you the product.

The product I make is free, so there goes that baby/bathwater.

I also write a book about the thing.

The book is just a bunch of HTML I create from a simple doc format. It's akin to me selling you plans on how to make your own land mower from the back of Popular Mechanics, or something.

Another thingy that companys are good at, especially in computer-stuff is automation. I do provide services to install the program. But I do it manually. There's no installer. And, that's stupid.

But if this is just a hobby - one that takes a lot of my time, I don't have a job. And art isn't making any money.

This is all going to come to a head, soon enough. But at least it allows me to identify myself as a, "hacker" rather than a software engineer, which I couldn't possibly be.

It also gives me something to put on my artsy résumé: Computer Hacker. That sounds almost hip. Would you like a painter that has a hobby of collecting pogs, or a painter that also has a hobby of hacking computers?

yeah, you're right, pogs win again.

LWP is Simple.

2008-09-14T01:29:00.000-07:00

While I'm on the nerd tip, this is the simplest example I can get to grab the contents of a URL, with a optional username/password and/or proxy:

 
#!/usr/bin/perl 
 
my $proxy = undef; 
my $user  = undef; 
my $pass  = undef; 
my $url   = 'http://localhost'; 

 # Create a user agent object
 require LWP::UserAgent;
 my $ua = LWP::UserAgent->new;

 if($proxy){ 
  $ua->proxy(
   ['http', 'ftp'], 
   $proxy
  ); 
 }
 
 # Create a request
 my $req = HTTP::Request->new(
    GET => $url
   );
 # Pass request to the user agent and get a response back
 my $res = $ua->request($req);
 if(
   defined($user) && 
   defined($pass)
 ){ 
    $res->authorization_basic(
   $user, 
   $pass
  );
 }
 # Check the outcome of the response
 if ($res->is_success) {
     return $res->content;
 }
 else {
     warn $res->status_line;
  return undef; 
 }
}

Wishing LWP::Simple would do this, but. Nope.

MIME Trickery with MIME::Parser and friends

2008-09-13T01:30:00.000-07:00

You can attach attachments to a multipart/related email message entity (say, a email message created from a website, with the images attached to the message itself) by creating a new multipart/mixed entity, and having the first part be that multipart/related entity and the rest being your new attachments. For example:

 
#!/usr/bin/perl 
use strict; 

use :MyMIMELiteHTML; 
use MIME::Parser; 
use MIME::Entity; 

my $HTMLurl = 'http://localhost'; 
my $jpg_path = '/Users/justin/Desktop/4.jpg';


my $mailHTML = new MyMIMELiteHTML(
 'IncludeType' => 'cid', 
); 
                 
my $MIMELiteObj = $mailHTML->parse($HTMLurl)  ;

 
my $msg_as_string =  $MIMELiteObj->as_string; 


my $parser = new MIME::Parser;

my $entity = $parser->parse_data($msg_as_string);


# Attach stuff to it:


my $cont_entity = MIME::Entity->build(Type        => "multipart/mixed");
   $cont_entity->add_part($entity); 
   $cont_entity->attach(
    Path     => $jpg_path,
                Type          => "image/jpg",
                Encoding      => "base64",
    Disposition   => "attachment",
    );

print $cont_entity->stringify;

MyMIMELiteHTML is just my version of MIME::Lite::HTML, with a few bug fixes and changes to fit in my program better.

http://search.cpan.org/~alian/MIME-Lite-HTML-1.22/HTML.pm

I've tried also just added the attachments to the multipart/related entity, but the new attachments never can be found - at least in Mail.app (Gmail? Yes?), unless you put in a bogus Content-ID header for the attachement - which actually could come in handy in some rare cases, but I digress...

First Post. It's about Perl. Perl Perl Perl.

2008-04-08T22:28:00.000-07:00

So.

There was a recent flurry of postings in the Perl Community dealing with how Perl isn't very sexy any more and lots of, "oh my God, no one uses Perl anymore" and sky falling down and all that.

They also mentioned that the number of teh blogs dealing with Perl, when compared to other languages was a bit lackluster. Perhaps this is because most of the big-shot Perl programmers you see lurking around on teh Perl mailing lists and are creating the majority of quality CPAN modules are on http://use.perl.org? - I dunno.

Anyways, I thoughts to myself, Self, you're eccentric. You're a sexy little beast.

And you program in Perl.

So here's my hat thrown into the ring for teh Blogs about teh Perl.

The other thing I do - I would say my main passion is Art: drawing and painting. It's not Perl. Perl helps pay the bills I guess.

I'm sort of realizing, as I get older, that playing with Perl and being so SO into art is a rarity, and as a nod to the Paul Graham article, "Hackers and Painters (http://paulgraham.com/hp.html)", I give you the Perl Hacker Painter.

Hacking is probably the best way to describe to you how I program. I barely understand the concepts I play around with. I didn't go to school for this. I am not math-inclined.

But, I've flourished, in my own little way, in writing Perl (mostly).

If you're more traditional in your skill-acquiring, I may say/do/write things that makes no sense. And, that's OK. Because, when I ask for help? I get a lot of answers from people that don't make much sense to me. And then, I just hack about.

I'll probably use this thing (I loathe the word, blog) to write examples of code for whatever, problems I solved with Perl and hopefully, artwork Perl helped me with, since, there's a lot of that in my portfolio

So, if you're zooming around on Techorati or something and you've come across, *gasp* a blog about Perl, well, hello to you too.