Gedcom.pm 1.17 released

[Paul Johnson]

Really!

As some of you appear to have noticed, I've been a little busy this year
and haven't found much time work with Gedcom.pm. I apologise for that.
In order to make amends to a degree I have spent some time in the last
few of days closing all the bugs reported in both github and RT, adding
some extra features, and I have just released Gedcom.pm 1.17.

The notable improvements include better handling of adding notes,
support for UTF-8 and the addition of a grammar for 5.5.1.

5.5.1 is only 13 years old and is designated as a draft standard. Its
title page says "It must not be used for programming of genealogical
software while in draft." So the standard may change markedly between
this draft and the (no doubt imminent) final version. As such the 5.5.1
grammar is included for the early adopters. Caveat emptor!

When I first designed Gedcom.pm I made it so that multiple grammars
could be used. Now there are multiple grammars. How prescient I was!

Although I have worked through all the tickets on github and RT, I have
no doubt missed matters which have been reported elsewhere. If there is
anything which needs attention, please feel free to open a ticket on
github.

Enjoy 1.17.

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

[Stephen Woodbridge]

Hi Paul,

This is Awesome! Thanks!

I have not used Gedcom in years, but I found this site:
http://www.nantuckethistoricalassociation.net/bgr/BGR-o/p1.htm

Which would be useful to anyone having ancestors that lived in
Nantucket, MA during the early colonial years, but I digress :)

What I noticed was that the data way nicely tag in the HTML so I am
writing a parser to read the HTML can generate a Gedcom file. I have the
basics working, but I have to do more work on it to fix bugs and collect
more of the data than I current am. I'm side tracked with work at the
moment so it is on hold. When I'm done it will have generated a 40K+
person Gedcom file. This should be able able to create a gedcom from any
"Second Site" generated website assuming it is similar to the link
above. Or you can ask the site owner for a copy of the gedcom :), but
this seemed like a worth challenge at the time.

Thanks again for all you work and continued support.

-Steve

[Ron Savage]

Hi Stephen

Are you using HTML::TreeBuilder and the v-e-r-y nice look_down() method?

--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

[Stephen Woodbridge]

Yes, very nice tool! makes it soo easy to parse HTML.

[John Washburn]

Dear Stephen:

I have a perl program that walks the HTML pages of e-FamilyTree.net and
pipes it out to a GEDCOM file. It is also interruptible in that you can run
the program for a while, stop it and upon restart it will pick up where the
search left off.

It uses the HTML:Tree builder and the wonderful look-down functionality
mentioned by Ron. It also used Date::Manip quite heavily.

I would be happy to zip up the code and send the archive to you if you are
interested. The code is a bit bloated because the code grew over time and I
had to add special cases for some of the errors in the e-familynet HTML
structure and to implement the 1-generation look ahead.

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/5997 - Release Date: 12/30/12

[Stephen Woodbridge]

Hi John,

Yes, I would love to get that and I'm willing to share my code once I
have time to fix the most critical issues.

Maybe Paul would like to create a "contrib" directory in the repository
that could be used to make code like this available. I guess we could
all make public repos on github if we have code to contribute but I
think that makes it harder to find it. And/or we could create wiki
page(s) that describes these contrib items and how to use them.

Anyway, please send your code when you get a chance. It might be a month
+- before I get to look at it and give it a try.

Thanks,
-Steve

[John Washburn]

Dear Steven:

The code is currently in an SVN repo on XP-Dev. I could make the repo
public, but the code in its current stage is definitely what I call "work
bench code". It works and does the task for which it is designed, but, even
though I plan to use it for a long time, the code was written with the idea
that it would not leave my workbench. The next step up would be
production-ready code.

I liken this kind of code to the improvised and one-off tools my carpenter
and machinists friends have. The tools work and work well, but the tools
were not made with the intent to distribute beyond their work-shop.

Production of code (or tools) requires you to factor in many maintenance and
support factors that the workbench tools don't have.

But, just like I can borrow the custom work-bench vise my machinist friend
has, I can certainly share this bit of "work bench code". Let me collect up
the pieces into a ZIP archive.

Version: 2013.0.2805 / Virus Database: 2637/6001 - Release Date: 01/01/13

[Ron Savage]

Hi

On 02/01/13 02:48, Stephen Woodbridge wrote:
> Hi John,
>
> Yes, I would love to get that and I'm willing to share my code once I
> have time to fix the most critical issues.

I agree this code should be shared. But read on...

> Maybe Paul would like to create a "contrib" directory in the repository
> that could be used to make code like this available. I guess we could

If by repository you mean the Gedcom.pm distro, that would bloat that
particular distro, which is already 116 KB.

Ideally such code would be made CPAN-ready before release, without - of
course - forcing the author to make it production-ready.

I can help with that. I've written a tool for my own use which lists
pre-reqs, so creating Build.PL and Makefile.PL is quite easy, just a bit
of editing. Still, the code need some sort of docmentation, which is the
author's job.

As for a namespace, there is a long history in Perl (i.e. on CPAN) to
add an X to the primary module's name, giving GedcomX::* as the prefix
for all such modules. There's no doubt in my mind this is the best course.

And since I've recently become one of the admins for CPAN itself, I do
take module naming very seriously.

Of course this is a bit confusing because we've just been discussing
GEDCOM X. Sigh.

So - what to do?

Here's what I suggest: Last year I registered the new namespace
Genealogy::*, so:

1) For modules using, or already based on, Gedcom.pm, I'd call them
GedcomX::*.

2) For brand new modules, e.g. implementing GEDCOM X, or not using
Gedcom.pm, e.g. me new parser we discussed on this list last year, I'd
call them Genealogy::* or (for GEDCOM X) Genealogy::GedcomX::*.

That way, we'd keep separate things separate.

> all make public repos on github if we have code to contribute but I
> think that makes it harder to find it. And/or we could create wiki
> page(s) that describes these contrib items and how to use them.

Definitely. We'll need a road-map to help orient people to these
modules, along the lines of:

http://savage.net.au/Module-reviews.html

> Anyway, please send your code when you get a chance. It might be a month
> +- before I get to look at it and give it a try.

Glad to hear it.

[Philip Durbin]

On 01/01/2013 04:46 PM, Ron Savage wrote:
> Ideally such code would be made CPAN-ready before release, without - of
> course - forcing the author to make it production-ready.

That's what http://prepan.org is for! :)

Phil

[Ron Savage]

Hi Phil

Yes, indeed. I should have linked to that myself :-(.