use Perl

Way back on July 9, 2003 I uploaded Win32::KeyState to CPAN but it was indexed as KeyState. No biggie.

It has not received any love since that day.

I know of one person other than myself who ever used it: Johan Lodin.

Is anyone still using it? Or has everyone moved on to Win32::GuiTest and/or Win32::Console?

I would like to either turn over the module to someone or remove it from CPAN.

Either follow up with a comment here or send me an email at mmusgrove@cpan.org. (The email address listed in the documentation is no longer valid.)

Thank you.

I doubt that anyone is still using Win32::mIRC.

I doubt that anyone other than me ever used this module and I want to remove it from CPAN. (I do not care if it ends up in BackPAN or not.)

If anyone is still using Win32::mIRC, please send an email to mmusgrove@cpan.org and not the email address listed in the module documentation.

Thank you.

Background:
We have been writing all of our security related information to /var/log/secure. We typically use two database handles in our applications: one for the operator logged in and one for administrative purposes. The operator has just enough privileges to do what he or she needs to do in the application. We recently upgraded to Red Hat Enterprise Linux 5.3 64-bit, Oracle 11 Standard 64-bit, DBI 1.607 and DBD::Oracle 1.22 and everything was happy.

About a week ago we started putting that info into the database as well and everything was running wonderfully. That is until someone mistyped his or her password -- then we started seeing odd behaviors. It started out looking like a return was failing to return and instead crashing the app. One person was working through our code looking for something that had changed and added a cluck before the return in an attempt to shed some light on the situation. The app mysteriously made it further along but started crashing with a OCIHandleAlloc failure.

I found some information on the web that indicated that we might be falling back on 32-bit libraries. Our LD_LIBRARY_PATH environment variable turned out to indeed be pointing to 32-bit libraries so I fixed it. The problem persisted.

I saw that were newer versions of DBI (1.608) and DBD::Oracle (1.23). The DBI install went off without a problem. DBD::Oracle 1.23 was failing LOB tests (a known issue without a resolution) so I kept it at 1.22. The problem persisted.

Next I enabled trace level 1. I logged in using a valid username but an invalid password. That is when I saw that, while we were using two database handles, DBI/DBD::Oracle was refusing to accept the good admin connection as good after the bad connection attempt was made.

Then another coworker pointed out that by default, DBD::Oracle reuses the OCI environment for subsequent connections. Usually this is a good thing but it was causing us problems. Fortunately, the solution was as simple as adding ora_envph => 0 to our connection options. I also removed that cluck and it remained fixed.

Many are leaving use.perl.org but I am not (yet any way). I do not post very often so the interface, while annoying at times, is not enough to drive me mad.

Instead I am just letting everyone know that I am working towards a Bachelor of Science in Photography through the Art Institute of Pittsburgh - Online Division. I started a new blog a week or so ago: Online Student of Photography. "Wow, what a boring name for a blog." I know but it was the best I could come up with at the time.

I hate writing assignments with a passion but for some reason blogging is therapeutic.

We are also in the process of finding and hiring a few people. Here are some of the tips that come to mind for potential applicants (and I am sure that I am forgetting some).

When filling out our pre-screening questions:

1. If you do not know the answer, resist the urge to post the perldoc listing verbatim.
2. When answering the questions concerning the code snippets and you do not know the answer, feel free to run it before you take that guess.
3. When you include source code as a part of an answer, ensure that it compiles and runs.

When doing a phone screening or in-house interview:

1. It is perfectly acceptable to be nervous. We have been in your shoes and know how it feels.
2. Be prepared to talk about anything that you list on your resume (duties, responsibilies, applications, systems, operating systems, known languages, technologies, etc).
3. If you do not know the answer to a question then say so. Trying to make something up on the spot, while amusing for us, does not give you bonus points.

When doing a phone screening:

1. Do not schedule the phone screening for a time when you will be in the office at your current job.
2. If you get flustered, then let us know you need a moment to collect yourself. You do not need to terminate the interviewing process altogether. (Hanging up on us only leaves us wondering what happened.)
3. If you need to reschedule once we have started the call then we will reschedule it.
4. Pause from time to time to give us a chance to talk to you.

When doing an in-house interview:

1. You will get points deducted for wearing jeans and t-shirt instead of business casual attire.
2. When addressing someone, make eye contact.

If you have not seen Devel::NYTProf yet then you must be living under a rock. I installed it on one of our development servers at work today (after watching the OSCON presentation. I have not had a chance to use it much but I am already deeply in love!

So I was reading through the docs and thinking "it works with mod_perl but what about normal CGI scripts?" Nothing that I have read indicated that it could not be done so I edited my Apache config to add the following (and restarted Apache of course):

SetEnv PERL5OPT -d:NYTProf
SetEnv NYTPROF=file=/tmp/nytprof.out

I then accessed one of our CGI scripts and went to /tmp to create the HTML. However nytprof.out was not there. In its place was nytprof.out=!

So I changed the second line to be (and restarted Apache):

SetEnv NYTPROF=file=/tmp/nytprof.out:

Yep, that second line really ends with a colon.

I hit the same CGI script and looked in /tmp. Yep, nytprof.out was there. Yay! (But I get "Unknown option:" in my error log.)

I think that I need to file a bug report (but have not yet because I do not know if it is an Apache bug, a Devel::NYTProf bug or simply user error). What do you think?

My next step was to run nytprofhtml.

[mmusgrove@somebox tmp]$ nytprofhtml
Generating report...
Unable to open '/long/path/to/cgi-bin/security/Parser.yp' for reading: No such file or directory. Try running /opt/misc/bin/nytprofhtml in the same directory as you ran Devel::NYTProf, or ensure @INC is correct.

I look in /long/path/to/cgi-bin/security and sure enough there is not a Parser.yp file. The good news is that (most of) the HTML files were generated. *drool* They are absolutely gorgeous!

I pull up the index.html file in Firefox and scroll down a bit. What do I see but:

230    0.00431    0.00002    line . block . sub    /long/path/to/cgi-bin/security/Parser.yp

I click on "line" and everything shown is from Template::Grammar.

28    1    1    0.00033    0.00033    Template::Grammar::    __ANON__[Parser.yp:72]

I do not particularly care that I cannot drop down into the guts of Parser.yp. Yet I still cannot help but wonder if it is a bug in Devel::NYTProf or simply a by-product of how I got the profiling done... Anyone have any ideas?

Gabor Szabo requested comments on several new CPANTS metrics. Short answer: it is not enough.

What benefit does having Debian metrics add for anyone who doesn't use Debian (or a Debian-based OS)? None, I suspect.

When will we see Red Hat specific metrics added? distributed_in_rhel has a nice ring to it. And you can't forget about Slackware; got_slack? Microsoft users will cry out for bill_gates_approved. FreeBSD needs some love too, sold_your_soul_to_the_daemon.

The proposed additions cry out for even more! We want, nay! We NEED additions for every OS imaginable! When can we expect to see those?

Last night Patrick Michaud presented "Rakudo Perl" to the D/FW Perl Mongers. It sounds like a great time to start working with Perl 6. The compiler is far enough along that I can start doing baby programming in it. I can gradually start using more and more features as they become available. That sounds like a nice way to grow into the language.

I was surprised and extremely pleased by the amount of time that he spent talking about the Parrot Compiler Toolkit (PCT) and how to make your own compiler on Parrot. First, he showed us how to quickly make a very basic calculator with it. Then he had to show us the LOLCODE compiler that Will Coleda and Simon Cozens put together in about 4 hours! I wish I had use for PCT as it sounds great.

If you want to check it out, here are Patrick's Rakudo Perl slides.