Pushing small fixes

When I tested Hans Boldt’s Consanguinity Gramplet yesterday, I found a small bug in the Dutch relationship plug-in, i.e. a Python file in the main repo that generates language dependent strings for relationships, like 12th cousin, and so forth.

After fixing that, by replacing two variable names that seemed to have been constants earlier, I realized that handling the bureaucracy takes way more time then just pushing these two lines to my own fork, and sending a pull request with a short comment. And although our Mantis doesn’t eat my head, and I am a former civil servant, I prefer to avoind the procedure.

In our IT department, we had a special procedure for this, called the BoyScout fix, for which we added BS at the start of the comment line, which of course had a link to the other meaning of that abbreviation, which I won’t repeat here.

Do we have, or can we have, a similar procedure in Gramps? There is no test, and adding one is about a 100 times more work than just pushing the obvious, or rather send a pull request and have a fellow developer see the obvious.

In this specific case, since the Gramplet hasn’t made it into distribution, you could just post that ‘issue’ & pull request in Hans’ GitHub repository. You don’t need to bother with the MantisBT side.

Unfortunately, the indications are that this Gramplet is permanently stalled in peer review.

I would understand that if the error were in his code, but the error is in our own. It can affect other plug-ins too.

Oops! Misread that. But I believe to can do the same thing in the Gramps master. Since you’re not asking a developer to debug, just review the patch.
(Assuming the patch has a useful BS comment!)

What kind of Relationship string generation symptom would be exhibited?

'Cause scanning MantisBT for problems incidentally fixed by Boy Scouts would be good too.

It depends on the exception handling. If it’s too high, the whole execution stops, and no string is displayed. The error is triggered for any string like 12th cousin, 3 times removed.

2022-07-07 23:08:05.036: WARNING: _gramplet.py: line 342: Gramplet gave an error: Consanguinity
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gramps/gen/plug/_gramplet.py", line 326, in _updater
    retval = next(self._generator)
  File "/home/enno/.gramps/gramps51/plugins/consanguinity-main/consanguinity.py", line 543, in main
    ped_coll_section = data_formatter.get_pedigree_collapse()
  File "/home/enno/.gramps/gramps51/plugins/consanguinity-main/consformatter.py", line 220, in get_pedigree_collapse
    outstr += self.format_common_anc_rels \
  File "/home/enno/.gramps/gramps51/plugins/consanguinity-main/consformatter.py", line 335, in format_common_anc_rels
    relstr = relfun(relnum[0] - generations, relnum[1] - generations)
  File "/usr/lib/python3/dist-packages/gramps/plugins/rel/rel_nl.py", line 561, in get_plural_relationship_string
    if Ga <= len(_LEVEL_NAME) and (Gb-Ga) < len(_removed_level):
NameError: name '_LEVEL_NAME' is not defined
Continuing after gramplet error...

In this case the _LEVEL_NAME constant must be replaced by the _ordinal_level variable. And as you can see here, that line comes from the distibution, not from the calling code in the Gramplet.

I haven’t scanned the code for similar errors in other languages.

1 Like

If you look at the gramps/plugins/rel/rel_fr.py file, _LEVEL_NAME is defined in this module.

I think this is a bug. Did this case already tested ?

1 Like

Hello Serge,

I checked a few other languages, and many have that _LEVEL_NAME list, sometimes in lower case, but in the NL file, it has another name, and it looks like someone once forgot to change the code when he or she pasted that from another place.

If there were an automated test, we would have seen this earlier, but until now, I never saw it, until I started experimenting with the Consanguinity Gramplet, which I really like. And that is probably, because it uses other relationship code and strings than the Deep Connections Gramplet, which I use a lot.

1 Like

OK, thanks. I had a fork that was severely outdated, made when we were working on version 4.2, and since no FF was possible, I asked GitHub to disconnect it, and then made a new one.

And in that one, there is a PR waiting:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.