ASCIIVILLE

I needed to run LWP::UserAgent / HTTP::Request with an HTTPS URL to check the operation of a SOAP web service without the benefit of any Perl SOAP modules. I was running ActiveState (AS) Perl 5.10 originally and was able to perform HTTPS requests but since switching to Strawberry Perl there was a little more work to do.

Note that both the Strawberry Perl bin path and Strawberry C bin path will need to be listed in your environmental path. Also note that I no longer have AS Perl installed! (You could get the wrong Perl binary/environment while running the OpenSSL build or the CPAN operations if both AS Perl and Strawberry Perl are installed. This could lead to erratic results.)

After starting the Strawberry bundled CPAN command line tool "cpan" from with a Windows/DOS Command Prompt, I ran "make Crypt::SSLeay" at the "cpan>" prompt and was alerted immediately to a missing OpenSSL environment. In order to resolve that dependency, I had to obtain the latest OpenSSL 0.98 release and create an installation directory called "c:\openssl" as well as untar the archive to "c:\openssl\src." I tried extracting the tarball with the utilities bundled with Strawberry; the minigzip.exe worked, but the ptar script borked when trying to extract the files from the OpenSSL tarball.

Got this when running ptar -xvf on the OpenSSL tarball.

Can't use an undefined value as an ARRAY reference at C:/strawberry/perl/lib/Archive/Tar.pm line 953.

Oh, well. Fortunately, I had a late model WinZip already installed on my workstation.

In the "c:\openssl\src\<release>" directory you simply run "ms\mingw32" and hopefully everything will build properly within several minutes. Near the end of the bundled OpenSSL INSTALL.W32 text file are instructions for building within the MinGW environment (and not using MSYS by the way), which is the build environment bundled with Strawberry Perl itself. The instructions are basically accurate, but some of the library file names differ slightly. Here's a snapshot of my tree to show the files copied over after building a successful OpenSSL. I have excluded the contents from the "openssl" include directory under "c:\openssl\include" since it contains approximately 69 separate C header files. Your file sizes may vary depending on build options.

Directory of C:\openssl\bin

07/01/2009  11:14 AM    <DIR>          .
07/01/2009  11:14 AM    <DIR>          ..
07/01/2009  11:04 AM         1,546,781 libeay32.dll
07/01/2009  11:04 AM           332,254 libssl32.dll
07/01/2009  11:03 AM         1,843,527 openssl.exe
               3 File(s)      3,722,562 bytes
               2 Dir(s)  30,017,982,464 bytes free

Directory of C:\openssl\lib

07/01/2009  11:14 AM    <DIR>          .
07/01/2009  11:14 AM    <DIR>          ..
07/01/2009  11:04 AM         2,273,502 libeay32.a
07/01/2009  11:04 AM           168,560 libssl32.a
               2 File(s)      2,442,062 bytes
               2 Dir(s)  30,017,982,464 bytes free

Directory of C:\openssl\include

07/01/2009  11:07 AM    <DIR>          .
07/01/2009  11:07 AM    <DIR>          ..
07/01/2009  11:08 AM    <DIR>          openssl
               0 File(s)              0 bytes
               3 Dir(s)  30,017,847,296 bytes free

Under the openssl subdir are ~69 .h files [ not shown ].

Once the OpenSSL libraries and headers have been created and moved to the proper target directories, you'll need to be in the CPAN shell again and do a little wrangling to get Crypt::SSLeay to build.

cpan> clean Crypt::SSLeay

Should clean up old failed build if any.

cpan> make Crypt::SSLeay

Accept the default library path presented "c:\openssl." At this point I got about 40 missing references during the linking of SSLeay.o. To fix this required me to edit the Makefile generated during the CPAN shell build process. The problem I encountered was that only the libeay32.a import library was included in the const_loadlibs section. So to finish up the task, required going to the directory and editing the Makefile directly. There may be alternate ways of doing this, but this was the quickest route for me.

cpan> look Crypt::SSLeay

This command should drop you into the Windows/DOS Command Prompt subshell and into the temporary build directory for the Crypt::SSLeay module under c:\strawberry\cpan\build. Open the "Makefile", not Makefile.PL, and locate the section:


There are two directives that will require editing: EXTRALIBS, and LDLOADLIBS. I added "c:\openssl\lib\libssl32.a" to the end of both directives. Here are the sections from my Makefile (note that the lines are wrapped in this post, but form one complete line in the Makefile itself.)

EXTRALIBS = c:\openssl\lib\libeay32.a C:\strawberry\c\lib\libmsvcrt.a C:\strawberry\c\lib\libmoldname.a C:\strawberry\c\lib\libkernel32.a C:\strawberry\c\lib\libuser32.a C:\strawberry\c\lib\libgdi32.a C:\strawberry\c\lib\libwinspool.a C:\strawberry\c\lib\libcomdlg32.a C:\strawberry\c\lib\libadvapi32.a C:\strawberry\c\lib\libshell32.a C:\strawberry\c\lib\libole32.a C:\strawberry\c\lib\liboleaut32.a C:\strawberry\c\lib\libnetapi32.a C:\strawberry\c\lib\libuuid.a C:\strawberry\c\lib\libws2_32.a C:\strawberry\c\lib\libmpr.a C:\strawberry\c\lib\libwinmm.a C:\strawberry\c\lib\libversion.a C:\strawberry\c\lib\libodbc32.a C:\strawberry\c\lib\libodbccp32.a c:\openssl\lib\libssl32.a

LDLOADLIBS = c:\openssl\lib\libeay32.a C:\strawberry\c\lib\libmsvcrt.a C:\strawberry\c\lib\libmoldname.a C:\strawberry\c\lib\libkernel32.a C:\strawberry\c\lib\libuser32.a C:\strawberry\c\lib\libgdi32.a C:\strawberry\c\lib\libwinspool.a C:\strawberry\c\lib\libcomdlg32.a C:\strawberry\c\lib\libadvapi32.a C:\strawberry\c\lib\libshell32.a C:\strawberry\c\lib\libole32.a C:\strawberry\c\lib\liboleaut32.a C:\strawberry\c\lib\libnetapi32.a C:\strawberry\c\lib\libuuid.a C:\strawberry\c\lib\libws2_32.a C:\strawberry\c\lib\libmpr.a C:\strawberry\c\lib\libwinmm.a C:\strawberry\c\lib\libversion.a C:\strawberry\c\lib\libodbc32.a C:\strawberry\c\lib\libodbccp32.a c:\openssl\lib\libssl32.a

Save the Makefile and exit your editor.

While still in your Windows/DOS Command Prompt subshell, run "dmake". Crypt::SSLeay should build correctly...hopefully :)

If it builds without errors, be sure to run "dmake test" and make sure the tests pass!

If the tests pass, you can run "dmake install" to complete the process.

After the installation of Crypt::SSLeay completes, you can type "exit" to return to the CPAN shell. "quit" will return you to the Windows/DOS Command Prompt.

Basically, you're starting the process in the CPAN shell but you're exiting temporarily to the Windows/DOS Command Prompt subshell to finish the job. I don't know if the next action taken was needed for the build explicitly, but while in the Windows/DOS Command Prompt subshell I added c:\openssl\bin to my path using the "set PATH=%PATH%;c:\openssl\bin" just in case the OpenSSL DLLs were required to run the tests.

I hope this example helps if you experienced problems getting Crypt::SSLeay to build when running Strawberry Perl as your Perl environment.

FYI: Build was done on Windows XP SP2, OpenSSL 0.98k, Crypt::SSLeay 0.57, Strawberry Perl 5.10.0.5 (in default installation location "c:\strawberry").

I'm guessing this would be a lot less work on Ubuntu... :)

It is just past the core YAPC 10th anniversary and it was definitely a great adventure. The conference organizers (Casey, Dan, Robert, and Tom) did a phenomenal job planning and executing the event. Having the presentations back-to-back separated by 10-minute breaks was like attending a Perl circuit training workout. My mental muscles got flexed all the way from the command line Perl up to Perl 6 (Rakudo).

 

Here is my interpretation of the key YAPC 10 takeaways:

 

• There will be a production ready Rakudo in my stocking for Christmas ...
• CPAN is the generally accepted means to extend the Perl language ...
• Standardization is a hot topic on the minds of the Perl Community ...
• Git/GitHub is the greatest thing to hit software revision control ...
• Web development in Perl is becoming more modular ...
• Moose/Mouse is the cat's meow for Perl OOP ...
• The Perl community likes beer and has a great sense of humor to boot ...
• Volunteers are needed for various Perl development and supportive efforts ...
• Blog, blog, blog about Perl ...
• After 4 minutes is a bell, 5 minutes is a gong ...

 

Since moving my website/blog to Movable Type, I was very much interested in the talk about Movable Type Open Source. However, the presentation took a complete 180 with the announcement of OpenMelody, the community-supported fork of late model MTOS. It appears that it will be an effort to refactor the codebase to incorporate many of the module contributions from CPAN, most notably the CGI::Application MVC framework.

 

The first bit of "YAPC10 Inspiration" led me to investigate CGI::Application, and I created a mini web application project. The framework was remarkably intuitive; the app skeleton was running on my local Apache HTTPD and Strawberry Perl within about 10 minutes. In some respects CGI::Application reminded me of Apache Struts (but not too much :) My key requirements are as much pure Perl as possible since my current web host provider does not allow the installation of Perl modules, access to make, or even a C compiler. It appears that CGI::Application core and several or more modules are Perl-only and have relatively few dependencies. I will find out for sure when I install the mini app on my web host.

 

Hmmm, I may now have a topic for the next Perl Mongers meeting!

 

Aha!

I was having trouble using the pbc_to_exe.exe tool with the Win32 binary distribution of Parrot 1.2.0. After running the utility, I would eventually get the resulting .c file, but it would not compile since there were a lot of dependencies on libraries and header files not in my default Strawberry Perl Mingw subsystem.

One of the bigger problems was the I18N dependencies that are actually present in the GnuWin32 library distribution. I installed GnuWin32 and tinkered with header file paths, -Include flags etc., but kept getting build errors. My assumption was that I could not get a Win32 native executable from the .pbc generated from a simple .pir program.

I decided to build Parrot 1.2.0 from source by first getting the current developer release tarball from the Parrot website. I extracted the source into a temporary directory, set my Strawberry paths to precede my ActiveState paths, and ran "perl Configure.pl --ask" and basically just pressed enter on every prompt. Apparently the configuration phase understood that I did not have the prerequisites for i18n and unicode and it generated a makefile for anyway. There are build instructions bundled with the tarball and the instructions indicated the optional libraries that can be incorporated into the local build of Parrot.

The build went pretty smoothly. However running "mingw32-make test" borked on a small percentage of tests. Nonetheless, it appears that all the binaries were built, even though I only used parrot.exe and pbc_to_exe.exe. I'm guessing a smoke test is in order for the other binaries since not all the tests ran smoothly.

I took my original .pir and created a .pbc and then ran the pbc_to_exe.exe binary on my .pbc file. Ouila! A Win32 native executable was built!  Even though my .pir was a toy program, it proved the basic plumbing worked.

How cool is that?

Microsoft Windows is my main desktop platform. Although, not my first choice, it is mandated at the office and I have investments in various software tools that are Windows-only so I use it at home as well. Fortunately, my trusty workstation has been around since 2003 and still sports the latest version of XP. The only real upgrades have been a new hard drive, memory, and video card so I can play Warcraft. I hope the box lasts long enough so I can bypass Vista all together.

Being relegated to Windows, I have always used ActiveState's offering for my local Perl installation. Every so often I get the itch to compile my own Perl but usually fallback to the ActiveState release since it is so easy to manage. The only downside to AS Perl is when a module needed is not available in their repository. This is not really an issue since there are several other Perl PPM repositories. Yet being in the AS Perl world tends to shield me from CPAN and I like CPAN. When on Linux/UNIX I use either the CPAN tool/shell or get the tarball itself from CPAN and build it myself.

Strawberry Perl enter stage left. This is a cool distribution. Bottom line. You get a late model, CPAN-friendly, Perl for WinTel along with a good portion of the GNU-based MinGW compiler suite of tools in one easy-to-install package. Not only can you build Perl modules that require XS, I was able to build the wxWindows 2.8.x libraries for a side project using the bundled MinGW compiler suite. Strawberry is also an excellent choice if you want to tinker with Parrot on WinTel as it too was built with Strawberry.

Am I abandoning ActiveState? Heck no. I use the Komodo IDE and I can only assume it is Strawberry friendly since the absolute path to Strawberry was listed as an option in the "Default Perl Interpreter" combo box in the Preferences dialog.

Interesting note: If I remember correctly, the AS Perl based on 5.8 was built with Microsoft compiler tools, whereas AS Perl for 5.10 was built with GNU compiler tools...

(Excerpt from AS Perl with -V switch)

ccversion='', gccversion='3.4.5 (mingw-vista special r3)'

Every developer has got 'em...

A coding style is a developer's signature, somewhat akin to how an artist applies paint to a canvas. Well, that's probably not the best analogy. On the surface, how code is edited shouldn't be that important: "It works, right?" At the last T.O. Perl Mongers meeting, the first presenter made a statement about how important it was to have "code craftsmanship" in mind when developing software. I have felt that same passion as well throughout my career.

The SPACEs versus TABs Dilemma

My earliest recollection for this aspect of the coding style controversy involved the SPACEs vs. TABs indentation problem. TABs are easier to use but SPACEs are forever. The argument for TABs was always to adjust your TAB resolution in the text editor or IDE. Ok. It is an annoying extra step, but it is certainly not the end of the world.

If your team goes SPACEs for indentation, the next hurdle is usually "how many?" This seems to be even more heated than the TABs vs. SPACEs question itself. Personally, I like either 2 or 4, and tend to favor 2 spaces lately. The most important issue is consistent application of spacing in the code and consensus from the team. At one place where I performed work, the software division had a bonafide code formatting design document. Although, I did not agree with every nuance of the formatting choices, I did appreciate the fact that everyone adhered to the guidelines.

However, the impetus for this post and what really got me heated up as of late was having to debug a critical production issue and being forced to trace through miles of sloppy PL/SQL source that had been formatted with TABs and then compiled into the DB. Was it lack of programmer pride on the part of the 3rd-party developer or just the end result of having to produce a working solution within the constraints of some absurd deadline? Either way, I was the poor sucker who had to fix it. :)

Method, Function, and/or Procedure Signatures

Ok. Now for my real coding style pet peeve.

Nipping at the heels of the SPACES vs TABs controversy [for me at least] is the formatting of method, function, and/or procedure signatures regardless of language implementation. This was actually irksome almost a decade ago, but I still find the approach rearing its ugly head again and again.

The basic problem is that of maintenance efficiency with the premise being that the less you have to type the more you will get done on any given day. I'll illustrate the point with some PL/SQL-ish pseudo code...(it probably won't compile)...

--------------------------------------------------------------------------------------------------------

PROCEDURE really_long_procedure_name_with_many_params(   p_param1 varchar2,

                                                                                              p_param2 boolean,

                                                                                              p_param3 number,

                                                                                              p_param4 varchar2,

                                                                                              p_param5 varchar2,

                                                                                              p_param6 boolean,

                                                                                              p_param7 number,

                                                                                              p_param8 number,

                                                                                              p_param9 varchar2,

                                                                                              p_param10 varchar2,

                                                                                              p_param11 char,

                                                                                              p_param12 boolean,

                                                                                              p_param13 varchar2,

                                                                                              p_param14 boolean,

                                                                                              p_param15 number)

IS

    l_local_this VARCHAR2(30);

    l_local_that NUMBER;

    l_local_something_else BOOLEAN;

BEGIN

    NULL; /* 1000's of lines follow */

END really_long_procedure_name_with_many_params;

--------------------------------------------------------------------------------------------------------

If you ever watched the series "Lost in Space," you will be hearing two catch phrases repeated in your head at this moment.

Robot: "Danger, Will Robinson."

Dr. Smith: "Oh, the pain."

If you ask me, the negative space to the left flank of the parameter list is ripe and ready to have a JPEG graphic inserted. :)

The real problem is if the interface changes here and that can mean a lot of extra typing!

How would I fix this?

1. Add one line after the beginning paren and have only one level of indentation for each parameter in the list.
2. With 15 params, it might be time to think about replacing the parameter list with a user-defined data type instead.
   

At any rate, think about how much more time those extra keystrokes add up to in month's time, a year's time.

Well that is my main pet peeve...

Conclusion

So what is the best solution for this ongoing battle? Not to fight about it of course, and try to implement a post-processing model that will automate the code formatting (e.g., Perl Tidy or similar) based on unanimously agreed upon rules and applied some time on or before the actual code check-in.

Now it is time to think up some cartoons.

Ok. There is about forty-ish pages posted now and another forty-ish to go. I had to create a custom page listing widget since the default widget was recursing all folders whether or not those folders actually contained content (pages).

All the images are uploaded, so it is just a matter of creating the actual pages and backdating the pages to the original posting date of the cartoons. I'm not exactly sure why the original posting date is important, other than to determine where my head was at when creating the cartoons in the first place.

Still trying to determine if there is already a tag set for automatic navigation between pages based on some sort criteria (date, etc.) kind of the way the "Pages" manager is setup by default in the "Create Page Entry" screen.

"Ah. Nothing like learning a new software tool..."