[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Omaha.pm] lines2perl: partition.pl



Paul's response.

j


-------- Original Message --------
Subject: Re: lines2perl: partition.pl
Date: Sun, 30 Apr 2006 23:35:20 +0200
From: Paul Johnson <paul@pjcj.net>
To: Jay Hannah <jay@jays.net>

On Sun, Apr 30, 2006 at 03:25:02PM -0500, Jay Hannah wrote:

Paul Johnson wrote:
>Argh - sorry about that.  Yes, there are a few LifeLines functions which
>I haven't implemented - including all the functions since LifeLines got
>its new lease of life.

Did LifeLines (almost?) die at some point? Are you trying to bridge the work into the next generation through your Perl re-write? It'd be terrible to lose all that amazing software to the sands of time... It's a little scary all the LifeLines copyright notices end in the mid 90s. :)

Yes, for a while there was no active LifeLines development.  It was
during this time that I wrote Gedcom.pm and I decided that all those
LifeLines scripts were too useful to lose.  That's the main reason I
wrote lines2perl.  Then the author, Tom Wetmore, later put the source
under an MIT style licence and others started maintenance and further
development.

Here's my scorecard:

relation.pl: Fast, but lied to me twice, reporting no relation between me and 2 of my relatives. relation.ll: Fast, and identified relations that the Perl version had me convinced didn't exist.

This is the bit that mainly concerns me since, as you surmise, it
probably indicates a bug in either lines2perl or Gedcom::LifeLines.  It
might take a bit of work to track down though.

Of course, since having written Gedcom.pm I have also written
Devel::Cover, so the proper approach here would be to increase the
coverage of the test suite, and in so doing the bug should become
apparent.

partition_option1.ll: Fast.
partition_option1.pl: Fast, exact same results.

This just means that I have written the perl code well.  Good to know,
but doesn't take us too much further.

partition_option2.ll: Fast, split my GEDCOM for me.
partition_option2.pl: SLOW, blew up.

I'm not too worried about the automatic translation being slow, as long
as it is correct.  It would be nice it it was fast, of course, and
profiling might show up some obvious improvements, but for most reports
I think the time is fine.  And it blew up because of a missing function.
Adding that should already be in the TODO.

So since partition_option1.pl CAN correctly identify all the partitions very very quickly, there just must be something in the lines2perl translation process that makes the attempt of a GEDCOM output format unbearably slow in the .pl version... with an explosive finale! :)

And I don't know what the deal is with relation.pl. I could try to debug it or write a test set for you that demonstrates the problem... I'm not sure I could ever tackle the underlying language translation patch(es) that would be needed... Do you ever "bless" tweaked Perl scripts as ports of the LL scripts, or do you always try to patch lines2perl?

So far, I have just changed lines2perl and Gedcom::LifeLines.  There
seems little value in adding the automatically generated files to the
distribution, but hand translated files, like the one I posted before,
would be useful, both because of their utility and as examples of using
Gedcom.pm.  Someone recently suggested and examples directory be added
to the distribution and I think that is a good idea.  I'll add the
partition translation to start that off.

Thanks for all your help!!!

You're welcome.

By the way, all my posts are rejected from Omaha.pm, so I hope the folks
there don't mind a somewhat one sided discussion.

--
Paul Johnson - paul@pjcj.net
http://www.pjcj.net