Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

OO, from a blank file: an old perler dog tries new tricks

by Intrepid (Deacon)
on Feb 21, 2013 at 03:31 UTC ( #1019876=perlmeditation: print w/ replies, xml ) Need Help??

I am going to try something new here. I need to write an app in Perl to parse the output of Cygwin's CygCheck.exe utility. I say "parse" as a shorthand for "read, munge, output" ;-)

What is new is that I am going to try writing the spec for the app as a Meditation on PMo first before I start the app. Well, I know me, so I am already lying. I'll start to write the spec here, and then start the coding. Then return to this writeup.

"Huh? Why?"

Just to do something fresh, to break some habits. I am not looking for upvotes or for a way to promote my app (although I do intend to publish it; there will be a link in the post sooner or later). The habits I want to break involve the organic way my coding usually proceeds. I start out with an idea, code the skeleton, look for what breaks, decide to add some features, code, repeat, lather, rinse, repeat. It's fine, its what I enjoy. It's also not as disciplined as other approaches, leads to featuritis, and so on.

(As per the top heading), I think the best way is to start with a Perl-OO approach from the beginning. That is really the realization that prompted this idea to write a Meditation. The realization is that these days, I really have no idea where to start with writing Perl-OO code. There are so many Perl-OO memes out there. There are so many helper modules on CPAN that template-ize or automate the creation of objects. Damian's book is considered a good primer, but out of date. <hands pulling out hair>. So where to begin?

I'm not going to wait for advice before I make some decisions and plunge in. For a PMo newbie that would be fine, perhaps, although I do think that a lot of our newer posters don't show that they get that they need to post code from the top of their Question ...but that's neither here nor overthere.

Event-driven

I know that I want to treat my input as a sequence of events. Roughly, the input data is a series of sections that describe system configuration and status data for the Cygwin installation. I will run the CygCheck.exe tool with the flags -v -s -h -r to get verbosity, helpful hints, and Registry queries.

The shape of the input data

A first glance at the input we expect breaks down like this (note: to an extent this is misleading and contrived, because the CygCheck utility outputs some data that is not for public publishing).

  • Cygwin Configuration Diagnostics
  • Path: D:\UserSW\root\bin
  • Output from D:\UserSW\root\bin\id.exe
  • Here's some environment variables that may affect cygwin:
  • Here's the rest of your environment variables:
  • Scanning registry for keys with 'Cygwin' in them...
  • Cygwin installations found in the registry:
  • Listing available drives...
  • Mount entries: these map POSIX directories to your NT drives.
  • Looking to see where common programs can be found, if at all...
  • Looking for various Cygwin DLLs... (-v gives version info)
  • Checking for any Cygwin services...
  • Cygwin Package Information

Sweet, Eh?!

This gives a Perler a true-life opportunity to test themselves against some perversely difficult input. These "headings" are highly irregular (arbitrary) in format; it may be that Localization will affect this output (I have no idea), etc.

Preliminary Spec

What will be "success":

  • The “section events” will all be detected;
  • All data within each section can be manipulated (filtered, reformatted);
  • Any section can be removed from the output;
  • No “unhandled” text data will be lost after the input stream is terminated.

Design:

  • Each section will be represented in code as an object with attributes (properties, methods).
  • There will be at least 2 "dump" or "stringification" methods common to all instance/objects: plain text and YAML.
  • There will be a "filter" method for each instance/object that will receive a coderef as @_[1].
  • Each instance/object will know where in the input stream its instantiating triggering event occured.
  • There will be a common / consistent “placeholder” string representation for elided data.

And there we have it. Time to start coding ;-)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." George Bernard Shaw

Comment on OO, from a blank file: an old perler dog tries new tricks
Download Code

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1019876]
Approved by Paladin
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2014-11-26 11:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (167 votes), past polls