Bus Error - Gedcom/Ruby

1 view
Skip to first unread message

Jimmy Z

unread,
Aug 23, 2007, 11:03:20 AM8/23/07
to Utah Ruby Users Group
I'm hoping to get a response from Jamis on this question. (The Gedcom/
Ruby sourceforge project still lists your byu email address).

I'm working on a project that uses your Gedcom/Ruby library to parse
Gedcoms. It's an awesome parser by the way. The best I've found for
any language.

I'm running into some problems where the application crashes with the
following error when it comes across a date that is invalid according
to gedcom specifications:

==============================
[BUG] Bus Error
ruby 1.8.5 (2006-12-25) [i686-darwin8.8.5]

Abort trap
==============================

This crash occurs when I attempt to do the following:

d.to_s

# d is a GEDCOM::Date object

Even if I wrap it in a begin/rescue, the application just quits. I've
never run into a ruby Bus Error before, so I'm wondering if anyone has
any suggestions on how to continue on gracefully, if it's possible.

One common date we're getting tripped up on is BET. 1819 - 1820 where
there is a period after the BET.

I know it's been about 4 years since you released this project, but if
you could give me a suggestion, I don't mind digging through the C
code to add a fix.

Thanks,
Jimmy

Jamis Buck

unread,
Aug 23, 2007, 11:06:05 AM8/23/07
to ur...@googlegroups.com
I'm sure it's something in the C code that is doing something that
isn't compatible with version of Ruby after, say, 1.8.2. :) Beyond
that, I have no idea what's going on there.

You might also want to ping Hans Fugal, I know he's been working on a
gedcom parser recently.

- Jamis

Jimmy Z

unread,
Aug 23, 2007, 1:38:11 PM8/23/07
to Utah Ruby Users Group
Thanks!

--
Jimmy

On Aug 23, 9:06 am, "Jamis Buck" <ja...@37signals.com> wrote:
> I'm sure it's something in the C code that is doing something that
> isn't compatible with version of Ruby after, say, 1.8.2. :) Beyond
> that, I have no idea what's going on there.
>
> You might also want to ping Hans Fugal, I know he's been working on a
> gedcom parser recently.
>
> - Jamis
>

Hans Fugal

unread,
Aug 23, 2007, 4:00:27 PM8/23/07
to ur...@googlegroups.com
As Jamis said, I've been working on a GEDCOM parser too. It uses the
same idea, with some tweaks. You can grab a prerelease peek at
http://hans.fugal.net/tmp/redcom

I'm pretty close to releasing the stream parser portion. I'd
appreciate any feedback. I think Jamis and I have agreed to nuke the
ol' sourceforge project and put it up on rubyforge instead.

On 8/23/07, Jimmy Z <jimmy.z...@gmail.com> wrote:
>


--
Hans Fugal
Fugal Computing

Jimmy Z

unread,
Aug 24, 2007, 6:25:24 PM8/24/07
to Utah Ruby Users Group
Wow. Looks interesting!

It looks like the stream parser will function much like Jamis' parser,
setting handlers for the different elements that you come across. It
seems that is the best way to handle parsing large gedcom files, as
they can get really, really big and require lots of memory to process.

I've never seen the AST concept. If the stream parser is like a SAX
XML parser, would the AST be more like DOM? It appears from the
documentation that it translates each record into a nice object
structure. Is that right?

I also saw in the DESIGN list that you are creating a GEDPath. I'm
guessing that's like XPath but for Gedcoms. That will be way cool!

You also mention parsing to model in the TODO. Are you talking
ActiveRecord?

It looks as though this project has some killer potential for building
cool genealogy apps in Ruby.

--
Jimmy

On Aug 23, 2:00 pm, "Hans Fugal" <fug...@gmail.com> wrote:
> As Jamis said, I've been working on a GEDCOM parser too. It uses the

> same idea, with some tweaks. You can grab a prerelease peek athttp://hans.fugal.net/tmp/redcom


>
> I'm pretty close to releasing the stream parser portion. I'd
> appreciate any feedback. I think Jamis and I have agreed to nuke the
> ol' sourceforge project and put it up on rubyforge instead.
>

Hans Fugal

unread,
Aug 24, 2007, 10:53:14 PM8/24/07
to ur...@googlegroups.com
On 8/24/07, Jimmy Z <jimmy.z...@gmail.com> wrote:
>
> Wow. Looks interesting!
>
> It looks like the stream parser will function much like Jamis' parser,
> setting handlers for the different elements that you come across. It
> seems that is the best way to handle parsing large gedcom files, as
> they can get really, really big and require lots of memory to process.

Yup, that's the idea.

>
> I've never seen the AST concept. If the stream parser is like a SAX
> XML parser, would the AST be more like DOM? It appears from the
> documentation that it translates each record into a nice object
> structure. Is that right?

That's an accurate analogy, but I like to think of the AST as more
like halfway. The AST is just the GEDCOM structure, without the
semantic meaning. The Model will have a similar structure (although
links will be resolved into references rather than explicit), but all
the semantics will be in place. This includes validation and parsing
values like dates into special classes like the ruby Date class (or
perhaps a GEDCOM::Date class that supports approximations and ranges).

>
> I also saw in the DESIGN list that you are creating a GEDPath. I'm
> guessing that's like XPath but for Gedcoms. That will be way cool!

It's actually available in the stream parser now. I intend to make it
available in the AST as well.

>
> You also mention parsing to model in the TODO. Are you talking
> ActiveRecord?

See above. It's the various classes like Individual, Family, Event,
etc. The parser will create the model objects. You will also be able
to generate a GEDCOM file from a set of model objects. So in a way it
is like AR, but it's not backed by a database. Nor is it backed by a
GEDCOM file, though technically you could parse and then overwrite the
same GEDCOM file. It's just an in-memory model.

I plan on making a release as soon as I finish the AST (which is
really quite close to being finished) and doing the release bookwork
like making a README, etc. I don't know when I'll get to it, but feel
free to prod. :)

Reply all
Reply to author
Forward
0 new messages