From: doug <do...@o2...> - 2013-08-08 11:22:48
|
I think there was some discussion a while ago about making all filters capable of using regular expressions - what are the current state and intentions? The question raised itself recently when I wanted to filter for things like Birth Events lacking a Date, or Birth Events lacking a Place, by putting "^$" in the appropriate field. The filter fails to select any Events. The filter editor has no "Use regular expression" option and the filter sidebar "Use regular expression" has no effect. Doug P.S. gramps 4.0.2 (r22816) |
From: Nick H. <nic...@ho...> - 2013-08-08 12:07:31
|
On 08/08/13 12:22, doug wrote: > I think there was some discussion a while ago about making > all filters capable of using regular expressions - what are > the current state and intentions? I have a patch for v4.0 that adds regular expression functionality to some rules. It enables the functionality available in the base class and combines a few rules, where there is a separate rule for regular expressions. I'll check to see how far I got with it. Nick. |
From: Nick H. <nic...@ho...> - 2013-08-08 23:08:32
|
Devs, I have now added regular expression matching to all applicable rules in gramps40 and trunk. In doing so I have renamed "containing substring" and "matching regular expression" to "containing text". The regular expression checkbox contains a tooltip which briefly explains the functionality. The following rules optionally accept regular expressions: Person People with the <citation> People with the <birth data> People with the <death data> People with the family <event> People with the personal <event> People having notes containing <text> People with Id containing <text> People with the family <attribute> People with the personal <attribute> Family Families having child with Id containing <text> Families with the <citation> Families with the <event> Families having father with Id containing <text> Families having notes containing <text> Families with Id containing <text> Families with the family <attribute> Families having mother with Id containing <text> Event Events with the <citation> Events having notes containing <text> Events with Id containing <text> Events with <data> Events with the attribute <attribute> Place Place with the <citation> Places having notes containing <text> Places matching parameters Places with Id containing <text> Source Sources having notes containing <text> Sources title containing <text> Sources with Id containing <text> Sources with repository reference containing <text> in "Call Number" Citation Citations with Volume/Page containing <text> Citations having notes containing <text> Citations matching parameters Citations with Id containing <text> Sources matching parameters Repository Repositories having notes containing <text> Repositories with Id containing <text> Repositories with name containing <text> Media Media with the <citation> Media objects with Id containing <text> Media objects having notes containing <text> Media objects with the attribute <attribute> Note Notes containing <text> Notes matching parameters Notes with <Id> matching regular expression There are five rules which previously accepted regular expressions. I have left these unchanged: People with records containing <substring> People with the <name> Families with child with the <Name> Families with father with the <Name> Families with mother with the <Name> Please give the updated rules some testing and let me know what you think. Regards, Nick. |
From: doug <do...@o2...> - 2013-08-09 09:24:35
|
On 09/08/13 00:08, Nick Hall wrote: > Devs, > > I have now added regular expression matching to all applicable rules in > gramps40 and trunk. In doing so I have renamed "containing substring" > and "matching regular expression" to "containing text". > > The regular expression checkbox contains a tooltip which briefly > explains the functionality. > > The following rules optionally accept regular expressions: > > Person > > People with the <citation> > People with the <birth data> > People with the <death data> > People with the family <event> > People with the personal <event> > People having notes containing <text> > People with Id containing <text> > People with the family <attribute> > People with the personal <attribute> > > Family > > Families having child with Id containing <text> > Families with the <citation> > Families with the <event> > Families having father with Id containing <text> > Families having notes containing <text> > Families with Id containing <text> > Families with the family <attribute> > Families having mother with Id containing <text> > > Event > > Events with the <citation> > Events having notes containing <text> > Events with Id containing <text> > Events with <data> > Events with the attribute <attribute> > > Place > > Place with the <citation> > Places having notes containing <text> > Places matching parameters > Places with Id containing <text> > > Source > > Sources having notes containing <text> > Sources title containing <text> > Sources with Id containing <text> > Sources with repository reference containing <text> in "Call Number" > > Citation > > Citations with Volume/Page containing <text> > Citations having notes containing <text> > Citations matching parameters > Citations with Id containing <text> > Sources matching parameters > > Repository > > Repositories having notes containing <text> > Repositories with Id containing <text> > Repositories with name containing <text> > > Media > > Media with the <citation> > Media objects with Id containing <text> > Media objects having notes containing <text> > Media objects with the attribute <attribute> > > Note > > Notes containing <text> > Notes matching parameters > Notes with <Id> matching regular expression > > There are five rules which previously accepted regular expressions. I > have left these unchanged: > > People with records containing <substring> > People with the <name> > Families with child with the <Name> > Families with father with the <Name> > Families with mother with the <Name> > > Please give the updated rules some testing and let me know what you think. > > Regards, > > Nick. Terrific! I'll report back when I've had a chance to try things out. Doug |
From: doug <do...@o2...> - 2013-08-09 11:40:06
|
On 09/08/13 10:24, doug wrote: > On 09/08/13 00:08, Nick Hall wrote: >> Devs, >> >> I have now added regular expression matching to all applicable rules in >> gramps40 and trunk. In doing so I have renamed "containing substring" >> and "matching regular expression" to "containing text". >> >> The regular expression checkbox contains a tooltip which briefly >> explains the functionality. >> >> The following rules optionally accept regular expressions: >> >> Person >> >> People with the <citation> >> People with the <birth data> >> People with the <death data> >> People with the family <event> >> People with the personal <event> >> People having notes containing <text> >> People with Id containing <text> >> People with the family <attribute> >> People with the personal <attribute> >> >> Family >> >> Families having child with Id containing <text> >> Families with the <citation> >> Families with the <event> >> Families having father with Id containing <text> >> Families having notes containing <text> >> Families with Id containing <text> >> Families with the family <attribute> >> Families having mother with Id containing <text> >> >> Event >> >> Events with the <citation> >> Events having notes containing <text> >> Events with Id containing <text> >> Events with <data> >> Events with the attribute <attribute> >> >> Place >> >> Place with the <citation> >> Places having notes containing <text> >> Places matching parameters >> Places with Id containing <text> >> >> Source >> >> Sources having notes containing <text> >> Sources title containing <text> >> Sources with Id containing <text> >> Sources with repository reference containing <text> in "Call Number" >> >> Citation >> >> Citations with Volume/Page containing <text> >> Citations having notes containing <text> >> Citations matching parameters >> Citations with Id containing <text> >> Sources matching parameters >> >> Repository >> >> Repositories having notes containing <text> >> Repositories with Id containing <text> >> Repositories with name containing <text> >> >> Media >> >> Media with the <citation> >> Media objects with Id containing <text> >> Media objects having notes containing <text> >> Media objects with the attribute <attribute> >> >> Note >> >> Notes containing <text> >> Notes matching parameters >> Notes with <Id> matching regular expression >> >> There are five rules which previously accepted regular expressions. I >> have left these unchanged: >> >> People with records containing <substring> >> People with the <name> >> Families with child with the <Name> >> Families with father with the <Name> >> Families with mother with the <Name> >> >> Please give the updated rules some testing and let me know what you think. >> >> Regards, >> >> Nick. > > > Terrific! > I'll report back when I've had a chance to try things out. > > Doug First report: Place filters work fine in 3.4.6 (python 2.7) except that Place with the <citation> Date:="^$" doesn't select missing dates. only one Event filter tested so far: Events with the <citation> Citation Volume/Page:="^$" to select missing Vol/Pages crashes gramps. Error Details: =================== 1306385: ERROR: gramps.py: line 107: Unhandled exception Traceback (most recent call last): File "/usr/share/gramps34/src/Filters/SideBar/_SidebarFilter.py", line 109, in clicked self.clicked_func() File "/usr/share/gramps34/src/plugins/gramplet/Filter.py", line 60, in __filter_clicked self.gui.view.build_tree() File "/usr/share/gramps34/src/gui/views/listview.py", line 286, in build_tree self.model.rebuild_data() File "/usr/share/gramps34/src/gui/views/treemodels/flatbasemodel.py", line 559, in _rebuild_filter dlist = self.search.apply(self.db, allkeys, tupleind=1) File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 233, in apply res = m(db, id_list, cb_progress, tupleind) File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, in check_and val = all(rule.apply(db, person) for rule in flist if person) File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, in <genexpr> val = all(rule.apply(db, person) for rule in flist if person) File "/usr/share/gramps34/src/Filters/Rules/_MatchesFilterBase.py", line 79, in apply return filt.check(db, obj.handle) File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 209, in check return self.get_check_func()(db, [handle]) File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, in check_and val = all(rule.apply(db, person) for rule in flist if person) File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, in <genexpr> val = all(rule.apply(db, person) for rule in flist if person) File "/usr/share/gramps34/src/Filters/Rules/Event/_HasCitation.py", line 59, in apply if HasCitationBase.apply(self, dbase, citation): File "/usr/share/gramps34/src/Filters/Rules/_HasCitationBase.py", line 67, in apply for citation_handle in object.get_citation_list(): AttributeError: 'Citation' object has no attribute 'get_citation_list' System Information: =================== Python version: 2.7.3rc2 (default, Apr 22 2012, 22:30:17) [GCC 4.6.3] BSDDB version: 5.1.2 (5, 1, 29) Gramps version: 3.4.6-0.SVN22823 LANG: en_GB.UTF-8 OS: Linux Distribution: 3.2.0-4-amd64 GTK version : (2, 24, 10) pygtk version : (2, 24, 0) gobject version: (2, 28, 6) cairo version : (1, 8, 8) Doug |
From: doug <do...@o2...> - 2013-08-09 11:47:57
|
On 09/08/13 12:39, doug wrote: > On 09/08/13 10:24, doug wrote: >> On 09/08/13 00:08, Nick Hall wrote: >>> Devs, >>> >>> I have now added regular expression matching to all >>> applicable rules in >>> gramps40 and trunk. In doing so I have renamed >>> "containing substring" >>> and "matching regular expression" to "containing text". >>> >>> The regular expression checkbox contains a tooltip which >>> briefly >>> explains the functionality. >>> >>> The following rules optionally accept regular expressions: >>> >>> Person >>> >>> People with the <citation> >>> People with the <birth data> >>> People with the <death data> >>> People with the family <event> >>> People with the personal <event> >>> People having notes containing <text> >>> People with Id containing <text> >>> People with the family <attribute> >>> People with the personal <attribute> >>> >>> Family >>> >>> Families having child with Id containing <text> >>> Families with the <citation> >>> Families with the <event> >>> Families having father with Id containing <text> >>> Families having notes containing <text> >>> Families with Id containing <text> >>> Families with the family <attribute> >>> Families having mother with Id containing <text> >>> >>> Event >>> >>> Events with the <citation> >>> Events having notes containing <text> >>> Events with Id containing <text> >>> Events with <data> >>> Events with the attribute <attribute> >>> >>> Place >>> >>> Place with the <citation> >>> Places having notes containing <text> >>> Places matching parameters >>> Places with Id containing <text> >>> >>> Source >>> >>> Sources having notes containing <text> >>> Sources title containing <text> >>> Sources with Id containing <text> >>> Sources with repository reference containing <text> in >>> "Call Number" >>> >>> Citation >>> >>> Citations with Volume/Page containing <text> >>> Citations having notes containing <text> >>> Citations matching parameters >>> Citations with Id containing <text> >>> Sources matching parameters >>> >>> Repository >>> >>> Repositories having notes containing <text> >>> Repositories with Id containing <text> >>> Repositories with name containing <text> >>> >>> Media >>> >>> Media with the <citation> >>> Media objects with Id containing <text> >>> Media objects having notes containing <text> >>> Media objects with the attribute <attribute> >>> >>> Note >>> >>> Notes containing <text> >>> Notes matching parameters >>> Notes with <Id> matching regular expression >>> >>> There are five rules which previously accepted regular >>> expressions. I >>> have left these unchanged: >>> >>> People with records containing <substring> >>> People with the <name> >>> Families with child with the <Name> >>> Families with father with the <Name> >>> Families with mother with the <Name> >>> >>> Please give the updated rules some testing and let me >>> know what you think. >>> >>> Regards, >>> >>> Nick. >> >> >> Terrific! >> I'll report back when I've had a chance to try things out. >> >> Doug > > > > > First report: > > Place filters work fine in 3.4.6 (python 2.7) except that > Place with the <citation> Date:="^$" doesn't select missing > dates. > > > only one Event filter tested so far: > Events with the <citation> Citation Volume/Page:="^$" to > select missing Vol/Pages crashes gramps. > Error Details: > =================== > > 1306385: ERROR: gramps.py: line 107: Unhandled exception > Traceback (most recent call last): > File > "/usr/share/gramps34/src/Filters/SideBar/_SidebarFilter.py", > line 109, in clicked > self.clicked_func() > File > "/usr/share/gramps34/src/plugins/gramplet/Filter.py", line > 60, in __filter_clicked > self.gui.view.build_tree() > File "/usr/share/gramps34/src/gui/views/listview.py", > line 286, in build_tree > self.model.rebuild_data() > File > "/usr/share/gramps34/src/gui/views/treemodels/flatbasemodel.py", > line 559, in _rebuild_filter > dlist = self.search.apply(self.db, allkeys, tupleind=1) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", > line 233, in apply > res = m(db, id_list, cb_progress, tupleind) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", > line 166, in check_and > val = all(rule.apply(db, person) for rule in flist if > person) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", > line 166, in <genexpr> > val = all(rule.apply(db, person) for rule in flist if > person) > File > "/usr/share/gramps34/src/Filters/Rules/_MatchesFilterBase.py", > line 79, in apply > return filt.check(db, obj.handle) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", > line 209, in check > return self.get_check_func()(db, [handle]) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", > line 166, in check_and > val = all(rule.apply(db, person) for rule in flist if > person) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", > line 166, in <genexpr> > val = all(rule.apply(db, person) for rule in flist if > person) > File > "/usr/share/gramps34/src/Filters/Rules/Event/_HasCitation.py", > line 59, in apply > if HasCitationBase.apply(self, dbase, citation): > File > "/usr/share/gramps34/src/Filters/Rules/_HasCitationBase.py", > line 67, in apply > for citation_handle in object.get_citation_list(): > AttributeError: 'Citation' object has no attribute > 'get_citation_list' > > > System Information: > =================== > > Python version: 2.7.3rc2 (default, Apr 22 2012, 22:30:17) > [GCC 4.6.3] > BSDDB version: 5.1.2 (5, 1, 29) > Gramps version: 3.4.6-0.SVN22823 > LANG: en_GB.UTF-8 > OS: Linux > Distribution: 3.2.0-4-amd64 > > GTK version : (2, 24, 10) > pygtk version : (2, 24, 0) > gobject version: (2, 28, 6) > cairo version : (1, 8, 8) > > > > Doug > P.S. similar crash and error with Events with the <citation> Citation Date:="^$" Doug |
From: doug <do...@o2...> - 2013-08-09 12:24:37
|
On 09/08/13 12:47, doug wrote: > On 09/08/13 12:39, doug wrote: >> On 09/08/13 10:24, doug wrote: >>> On 09/08/13 00:08, Nick Hall wrote: >>>> Devs, >>>> >>>> I have now added regular expression matching to all >>>> applicable rules in >>>> gramps40 and trunk. In doing so I have renamed >>>> "containing substring" >>>> and "matching regular expression" to "containing text". >>>> >>>> The regular expression checkbox contains a tooltip which >>>> briefly >>>> explains the functionality. >>>> >>>> The following rules optionally accept regular expressions: >>>> >>>> Person >>>> >>>> People with the <citation> >>>> People with the <birth data> >>>> People with the <death data> >>>> People with the family <event> >>>> People with the personal <event> >>>> People having notes containing <text> >>>> People with Id containing <text> >>>> People with the family <attribute> >>>> People with the personal <attribute> >>>> >>>> Family >>>> >>>> Families having child with Id containing <text> >>>> Families with the <citation> >>>> Families with the <event> >>>> Families having father with Id containing <text> >>>> Families having notes containing <text> >>>> Families with Id containing <text> >>>> Families with the family <attribute> >>>> Families having mother with Id containing <text> >>>> >>>> Event >>>> >>>> Events with the <citation> >>>> Events having notes containing <text> >>>> Events with Id containing <text> >>>> Events with <data> >>>> Events with the attribute <attribute> >>>> >>>> Place >>>> >>>> Place with the <citation> >>>> Places having notes containing <text> >>>> Places matching parameters >>>> Places with Id containing <text> >>>> >>>> Source >>>> >>>> Sources having notes containing <text> >>>> Sources title containing <text> >>>> Sources with Id containing <text> >>>> Sources with repository reference containing <text> in >>>> "Call Number" >>>> >>>> Citation >>>> >>>> Citations with Volume/Page containing <text> >>>> Citations having notes containing <text> >>>> Citations matching parameters >>>> Citations with Id containing <text> >>>> Sources matching parameters >>>> >>>> Repository >>>> >>>> Repositories having notes containing <text> >>>> Repositories with Id containing <text> >>>> Repositories with name containing <text> >>>> >>>> Media >>>> >>>> Media with the <citation> >>>> Media objects with Id containing <text> >>>> Media objects having notes containing <text> >>>> Media objects with the attribute <attribute> >>>> >>>> Note >>>> >>>> Notes containing <text> >>>> Notes matching parameters >>>> Notes with <Id> matching regular expression >>>> >>>> There are five rules which previously accepted regular >>>> expressions. I >>>> have left these unchanged: >>>> >>>> People with records containing <substring> >>>> People with the <name> >>>> Families with child with the <Name> >>>> Families with father with the <Name> >>>> Families with mother with the <Name> >>>> >>>> Please give the updated rules some testing and let me >>>> know what you think. >>>> >>>> Regards, >>>> >>>> Nick. >>> >>> >>> Terrific! >>> I'll report back when I've had a chance to try things out. >>> >>> Doug >> >> >> >> >> First report: >> <snip> Second report: Events with <data> Date, Place, Description:="^$" doesn't select missing; in fact regular expression doesn't seem to work ( e.g.\d+ for dates) Events with the attribute <attribute> doesn't select with or without regex Sources title containing <text> is absent; Sources title containing <substring> doesn't recognise regex Sources with repository reference containing <text> in "Call Number" is absent; Sources with repository reference containing <substring> in "Call Number" doesn't recognise regex Doug |
From: Nick H. <nic...@ho...> - 2013-08-09 13:23:26
|
On 09/08/13 13:24, doug wrote: > Second report: > > Events with <data> Date, Place, Description:="^$" doesn't select > missing; in fact regular expression doesn't seem to work ( e.g.\d+ for > dates) > Events with the attribute <attribute> doesn't select with or without > regex > > Sources title containing <text> is absent; Sources title containing > <substring> doesn't recognise regex > > Sources with repository reference containing <text> in "Call Number" > is absent; Sources with repository reference containing <substring> in > "Call Number" doesn't recognise regex > Doug, I only made the changes in gramps40 and trunk, not gramps34. Dates use special matching that takes into account approximate dates and date ranges. You must enter a date that can be parsed by Gramps, rather than a regular expression. Gramps types are normally selected from a drop-down list. I haven't implemented regular expression matching for these fields, although it would be possible to do so. When we are happy with the changes in gramps40, I could backport them to gramps34. Nick. |
From: doug <do...@o2...> - 2013-08-09 16:40:59
|
On 09/08/13 14:23, Nick Hall wrote: > On 09/08/13 13:24, doug wrote: >> Second report: >> >> Events with <data> Date, Place, Description:="^$" doesn't >> select missing; in fact regular expression doesn't seem to >> work ( e.g.\d+ for dates) >> Events with the attribute <attribute> doesn't select with >> or without regex >> >> Sources title containing <text> is absent; Sources title >> containing <substring> doesn't recognise regex >> >> Sources with repository reference containing <text> in >> "Call Number" is absent; Sources with repository reference >> containing <substring> in "Call Number" doesn't recognise >> regex >> > > Doug, > > I only made the changes in gramps40 and trunk, not gramps34. > > Dates use special matching that takes into account > approximate dates and date ranges. You must enter a date > that can be parsed by Gramps, rather than a regular expression. > > Gramps types are normally selected from a drop-down list. I > haven't implemented regular expression matching for these > fields, although it would be possible to do so. > > When we are happy with the changes in gramps40, I could > backport them to gramps34. > > Nick. > OK. I'll go back to gramps 40 and start again. Doug |
From: Nick H. <nic...@ho...> - 2013-08-09 21:40:35
|
On 09/08/13 17:40, doug wrote: > On 09/08/13 14:23, Nick Hall wrote: >> On 09/08/13 13:24, doug wrote: >>> Second report: >>> >>> Events with <data> Date, Place, Description:="^$" doesn't >>> select missing; in fact regular expression doesn't seem to >>> work ( e.g.\d+ for dates) >>> Events with the attribute <attribute> doesn't select with >>> or without regex >>> >>> Sources title containing <text> is absent; Sources title >>> containing <substring> doesn't recognise regex >>> >>> Sources with repository reference containing <text> in >>> "Call Number" is absent; Sources with repository reference >>> containing <substring> in "Call Number" doesn't recognise >>> regex >>> >> >> Doug, >> >> I only made the changes in gramps40 and trunk, not gramps34. >> >> Dates use special matching that takes into account >> approximate dates and date ranges. You must enter a date >> that can be parsed by Gramps, rather than a regular expression. >> >> Gramps types are normally selected from a drop-down list. I >> haven't implemented regular expression matching for these >> fields, although it would be possible to do so. >> >> When we are happy with the changes in gramps40, I could >> backport them to gramps34. >> >> Nick. >> > > OK. > I'll go back to gramps 40 and start again. > > Doug > > > Doug, I have now converted the five old rules to use the regular expression functionality in the base class. I have also backported the changes to gramps34. Let me know if you have any problems. Nick. |
From: Serge N. <Ser...@fr...> - 2013-08-11 09:00:04
|
Hi, Le 09/08/2013 23:40, Nick Hall a écrit : > On 09/08/13 17:40, doug wrote: >> On 09/08/13 14:23, Nick Hall wrote: >>> On 09/08/13 13:24, doug wrote: >>>> Second report: ... > Doug, > > I have now converted the five old rules to use the regular expression > functionality in the base class. > > I have also backported the changes to gramps34. It doesn't work any more for me : I get the following messages for all my filters: WARNING: Too many arguments in filter « XXXXX » ! Trying to load with subset of arguments. I needed to edit all the filters and put again "use regexp". Now all filters are working again > > Let me know if you have any problems. > > Nick. |
From: Nick H. <nic...@ho...> - 2013-08-11 14:16:59
|
On 11/08/13 09:59, Serge Noiraud wrote: > It doesn't work any more for me : > I get the following messages for all my filters: > > WARNING: Too many arguments in filter « XXXXX » ! > Trying to load with subset of arguments. > > I needed to edit all the filters and put again "use regexp". > Now all filters are working again Serge, Thanks for reporting this. The warning occurred with the five upgraded rules that already used regular expressions. People with records containing <substring> People with the <name> Families with child with the <Name> Families with father with the <Name> Families with mother with the <Name> I've added some code to automatically update these rules when they are first loaded. Let me know if this fixes your problem. Nick. |
From: Serge N. <Ser...@fr...> - 2013-08-19 21:30:52
|
Hi, I have the following problem when parsing date in the gramplet filter for the person view : 2013-08-19 23:24:54.695: ERROR: gramps.py: line 107: Unhandled exception Traceback (most recent call last): File "/home/gramps/gramps34/src/Filters/SideBar/_SidebarFilter.py", line 109, in clicked self.clicked_func() File "/home/gramps/gramps34/src/plugins/gramplet/Filter.py", line 60, in __filter_clicked self.gui.view.build_tree() File "/home/gramps/gramps34/src/gui/views/listview.py", line 286, in build_tree self.model.rebuild_data() File "/home/gramps/gramps34/src/gui/views/treemodels/flatbasemodel.py", line 559, in _rebuild_filter dlist = self.search.apply(self.db, allkeys, tupleind=1) File "/home/gramps/gramps34/src/Filters/_GenericFilter.py", line 232, in apply rule.requestprepare(db) File "/home/gramps/gramps34/src/Filters/Rules/_Rule.py", line 91, in requestprepare self.prepare(dbase) File "/home/gramps/gramps34/src/Filters/Rules/Person/_HasBirth.py", line 55, in prepare self.date = parser.parse(self.list[0]) NameError: global name 'parser' is not defined Do I need to make a bug report ? Le 11/08/2013 16:16, Nick Hall a écrit : > On 11/08/13 09:59, Serge Noiraud wrote: >> It doesn't work any more for me : >> I get the following messages for all my filters: >> >> WARNING: Too many arguments in filter « XXXXX » ! >> Trying to load with subset of arguments. >> >> I needed to edit all the filters and put again "use regexp". >> Now all filters are working again > > Serge, > > Thanks for reporting this. > > The warning occurred with the five upgraded rules that already used regular expressions. > > People with records containing <substring> > People with the <name> > Families with child with the <Name> > Families with father with the <Name> > Families with mother with the <Name> > > I've added some code to automatically update these rules when they are first loaded. Let me know if this fixes your problem. > > Nick. > > > |
From: Nick H. <nic...@ho...> - 2013-08-19 21:57:32
|
On 19/08/13 22:30, Serge Noiraud wrote: > Hi, > > I have the following problem when parsing date in the gramplet filter > for the person view : > > 2013-08-19 23:24:54.695: ERROR: gramps.py: line 107: Unhandled exception > Traceback (most recent call last): > File "/home/gramps/gramps34/src/Filters/SideBar/_SidebarFilter.py", > line 109, in clicked > self.clicked_func() > File "/home/gramps/gramps34/src/plugins/gramplet/Filter.py", line > 60, in __filter_clicked > self.gui.view.build_tree() > File "/home/gramps/gramps34/src/gui/views/listview.py", line 286, in > build_tree > self.model.rebuild_data() > File > "/home/gramps/gramps34/src/gui/views/treemodels/flatbasemodel.py", > line 559, in _rebuild_filter > dlist = self.search.apply(self.db, allkeys, tupleind=1) > File "/home/gramps/gramps34/src/Filters/_GenericFilter.py", line > 232, in apply > rule.requestprepare(db) > File "/home/gramps/gramps34/src/Filters/Rules/_Rule.py", line 91, in > requestprepare > self.prepare(dbase) > File "/home/gramps/gramps34/src/Filters/Rules/Person/_HasBirth.py", > line 55, in prepare > self.date = parser.parse(self.list[0]) > NameError: global name 'parser' is not defined > > Do I need to make a bug report ? No. I'll fix it. The problem is that I cut & pasted code from gramps40 into gramps34. I obviously didn't correct for the different imports properly. I'll check every rule I changed. Nick. |
From: jerome <rom...@ya...> - 2013-08-21 07:11:14
Attachments:
text_patch.gz
|
Nick, There is a minor textual issues with the backport: some translation strings have been also modified! eg, #: ../src/Filters/Rules/Event/_RegExpIdOf.py:48 -msgid "Events with <Id> matching regular expression" +msgid "Events with Id containing <text>" msgstr "" #: ../src/Filters/Rules/Place/_HasNoteRegexp.py:42 -msgid "Places having notes containing <regular expression>" +msgid "Places having notes containing <text>" msgstr "" etc... It is cosmetic and maybe it provides a better description, but should we commit an updated template, so translators will have time to update these strings, or should we try to keep 'old' strings for 3.4.x branch? Jérôme. ________________________________ De : Nick Hall <nic...@ho...> À : gra...@li... Envoyé le : Lundi 19 août 2013 22h19 Objet : Re: [Gramps-devel] Filters and regular expressions On 19/08/13 22:57, Nick Hall wrote: I've just had a look at every rule I changed in r22837. This bug affected 4 rules, which should now be fixed. > Nick. ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Enno B. <enn...@gm...> - 2013-08-21 11:21:43
|
It is cosmetic and maybe it provides a better description, but should we commit an updated template, so translators will have time to update these strings, or should we try to keep 'old' strings for 3.4.x branch? I prefer the better description, also in 3.4, and will try to help with translation when needed. regards, Enno |
From: Nick H. <nic...@ho...> - 2013-08-21 11:38:55
|
On 21/08/13 12:21, Enno Borgsteede wrote: > > It is cosmetic and maybe it provides a better description, but > should we commit an updated template, so translators will have > time to update these strings, or should we try to keep 'old' > strings for 3.4.x branch? > > I prefer the better description, also in 3.4, and will try to help > with translation when needed. I backported the regular expression enhancements to both gramps34 and gramps40. The updates to the rule names and descriptions indicate to the user that the rule may now be used to match a regular expression or find fields that contain a sub-string. I chose the phrase "containing <text>" for this. There are also a couple of cosmetic changes, and an additional tooltip summarising the basics of regular expressions. Should I change the msgid for updated text in the po files? Users would then see the old translated text, rather then the new English text. Nick. |
From: Vassilii K. <vas...@ta...> - 2013-08-21 11:47:10
|
On 21.08.2013 14:38, Nick Hall wrote: > On 21/08/13 12:21, Enno Borgsteede wrote: >> >> It is cosmetic and maybe it provides a better description, but >> should we commit an updated template, so translators will have >> time to update these strings, or should we try to keep 'old' >> strings for 3.4.x branch? >> >> I prefer the better description, also in 3.4, and will try to help >> with translation when needed. > > I backported the regular expression enhancements to both gramps34 and > gramps40. > > The updates to the rule names and descriptions indicate to the user > that the rule may now be used to match a regular expression or find > fields that contain a sub-string. I chose the phrase "containing > <text>" for this. > > There are also a couple of cosmetic changes, and an additional tooltip > summarising the basics of regular expressions. > > Should I change the msgid for updated text in the po files? Users > would then see the old translated text, rather then the new English text. > > Nick. Since you've added new things that you want to communicate to the user, best to leave it to the translators (even this means more work for me as I maintain ru.po)... V. |
From: Nick H. <nic...@ho...> - 2013-08-09 13:30:37
|
Doug, My changes were in gramps40 and trunk only. I suggest you raise a bug for this, it will be fixed anyway if we backport my regular expression changes to gramps34. Nick. On 09/08/13 12:39, doug wrote: > First report: > > Place filters work fine in 3.4.6 (python 2.7) except that > Place with the <citation> Date:="^$" doesn't select missing dates. > > > only one Event filter tested so far: > Events with the <citation> Citation Volume/Page:="^$" to select > missing Vol/Pages crashes gramps. > Error Details: > =================== > > 1306385: ERROR: gramps.py: line 107: Unhandled exception > Traceback (most recent call last): > File "/usr/share/gramps34/src/Filters/SideBar/_SidebarFilter.py", > line 109, in clicked > self.clicked_func() > File "/usr/share/gramps34/src/plugins/gramplet/Filter.py", line 60, > in __filter_clicked > self.gui.view.build_tree() > File "/usr/share/gramps34/src/gui/views/listview.py", line 286, in > build_tree > self.model.rebuild_data() > File > "/usr/share/gramps34/src/gui/views/treemodels/flatbasemodel.py", line > 559, in _rebuild_filter > dlist = self.search.apply(self.db, allkeys, tupleind=1) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 233, > in apply > res = m(db, id_list, cb_progress, tupleind) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, > in check_and > val = all(rule.apply(db, person) for rule in flist if person) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, > in <genexpr> > val = all(rule.apply(db, person) for rule in flist if person) > File "/usr/share/gramps34/src/Filters/Rules/_MatchesFilterBase.py", > line 79, in apply > return filt.check(db, obj.handle) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 209, > in check > return self.get_check_func()(db, [handle]) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, > in check_and > val = all(rule.apply(db, person) for rule in flist if person) > File "/usr/share/gramps34/src/Filters/_GenericFilter.py", line 166, > in <genexpr> > val = all(rule.apply(db, person) for rule in flist if person) > File "/usr/share/gramps34/src/Filters/Rules/Event/_HasCitation.py", > line 59, in apply > if HasCitationBase.apply(self, dbase, citation): > File "/usr/share/gramps34/src/Filters/Rules/_HasCitationBase.py", > line 67, in apply > for citation_handle in object.get_citation_list(): > AttributeError: 'Citation' object has no attribute 'get_citation_list' > > > System Information: > =================== > > Python version: 2.7.3rc2 (default, Apr 22 2012, 22:30:17) [GCC 4.6.3] > BSDDB version: 5.1.2 (5, 1, 29) > Gramps version: 3.4.6-0.SVN22823 > LANG: en_GB.UTF-8 > OS: Linux > Distribution: 3.2.0-4-amd64 > > GTK version : (2, 24, 10) > pygtk version : (2, 24, 0) > gobject version: (2, 28, 6) > cairo version : (1, 8, 8) |
From: doug <do...@o2...> - 2013-08-13 14:32:29
|
On 09/08/13 22:40, Nick Hall wrote: > On 09/08/13 17:40, doug wrote: >> On 09/08/13 14:23, Nick Hall wrote: >>> On 09/08/13 13:24, doug wrote: >>>> Second report: >>>> >>>> Events with <data> Date, Place, Description:="^$" doesn't >>>> select missing; in fact regular expression doesn't seem to >>>> work ( e.g.\d+ for dates) >>>> Events with the attribute <attribute> doesn't select with >>>> or without regex >>>> >>>> Sources title containing <text> is absent; Sources title >>>> containing <substring> doesn't recognise regex >>>> >>>> Sources with repository reference containing <text> in >>>> "Call Number" is absent; Sources with repository reference >>>> containing <substring> in "Call Number" doesn't recognise >>>> regex >>>> >>> >>> Doug, >>> >>> I only made the changes in gramps40 and trunk, not gramps34. >>> >>> Dates use special matching that takes into account >>> approximate dates and date ranges. You must enter a date >>> that can be parsed by Gramps, rather than a regular >>> expression. >>> >>> Gramps types are normally selected from a drop-down list. I >>> haven't implemented regular expression matching for these >>> fields, although it would be possible to do so. >>> >>> When we are happy with the changes in gramps40, I could >>> backport them to gramps34. >>> >>> Nick. >>> >> >> OK. >> I'll go back to gramps 40 and start again. >> >> Doug >> >> >> > Doug, > > I have now converted the five old rules to use the regular > expression functionality in the base class. > > I have also backported the changes to gramps34. > > Let me know if you have any problems. > > Nick. > Nick, I haven't looked at 3.4 but here are the results for 4.0 svn 22830M: The filter rules mostly work OK with regex, but there are several exceptions: (1) Events with the <citation> crashes gramps (bug #6995) (2) None of the filters "...... having notes containing <text>" work. They either fail to select or select incorrectly, with or without regex. (3) None of the filters allowing the choice of a drop-down type (e.g. event type, attribute type) recognise user-defined types (e.g. "Port of call", "Evacuation") (4) Regex doesn't seem to work on Date fields (e.g 20[0|1]2 for 2002 and 2012) in the filter rules. There seems to be no means of signifying a missing date field - a common need. (5) AFAICT filters ".... with the <attribute>" fail. This may be my fault because I don't understand how they're supposed to work: does <attribute> mean there must be an entry in the field Attribute or does it just mean a "property"? For example "Nickname" is one of the <attribute> drop-down choices, but peoples' Nicknames are not found. On the other hand "Witness" appearing as an Attribute of a person isn't found either. Doug > |
From: Serge N. <Ser...@fr...> - 2013-08-13 18:42:42
|
Hi, Le 13/08/2013 16:32, doug a écrit : > On 09/08/13 22:40, Nick Hall wrote: >> On 09/08/13 17:40, doug wrote: >>> On 09/08/13 14:23, Nick Hall wrote: >>>> On 09/08/13 13:24, doug wrote: ... > Nick, > I haven't looked at 3.4 but here are the results for 4.0 svn > 22830M: > > The filter rules mostly work OK with regex, but there are > several exceptions: > > (1) Events with the <citation> crashes gramps (bug #6995) > > (2) None of the filters "...... having notes containing > <text>" work. > They either fail to select or select incorrectly, with > or without regex. > > (3) None of the filters allowing the choice of a drop-down > type (e.g. event type, attribute type) recognise > user-defined types (e.g. "Port of call", "Evacuation") > > (4) Regex doesn't seem to work on Date fields (e.g 20[0|1]2 > for 2002 and 2012) in the filter rules. I think the regexp is 20[01]2 for 2002 or 2012. you must remove the pipe. > There seems to be no means of signifying a missing date > field - a common need. > > (5) AFAICT filters ".... with the <attribute>" fail. > > This may be my fault because I don't understand how they're > supposed to work: does <attribute> mean there must be an > entry in the field Attribute or does it just mean a "property"? > > For example "Nickname" is one of the <attribute> drop-down > choices, but peoples' Nicknames are not found. > On the other hand "Witness" appearing as an Attribute of a > person isn't found either. > > > Doug Serge |
From: Nick H. <nic...@ho...> - 2013-08-13 20:07:22
|
On 13/08/13 15:32, doug wrote: > The filter rules mostly work OK with regex, but there are several > exceptions: > > (1) Events with the <citation> crashes gramps (bug #6995) > This didn't look related to my changes, but I fixed it anyway. > (2) None of the filters "...... having notes containing <text>" work. > They either fail to select or select incorrectly, with or without > regex. > This another bug that was unrelated to regular expressions. I have fixed it. > (3) None of the filters allowing the choice of a drop-down type (e.g. > event type, attribute type) recognise user-defined types (e.g. "Port > of call", "Evacuation") It works for me. Custom types do not appear in the drop-down lists, so you will have to type in the name of the custom type you are interested in. Regular expressions are not allowed in this field. This is related to a comment I made in another thread. GrampsTypes are not aware of the custom types defined. They are stored separately in the database and extra code needs to be written to add them to the lists. The filter editor does not do this. > > > (4) Regex doesn't seem to work on Date fields (e.g 20[0|1]2 for 2002 > and 2012) in the filter rules. > There seems to be no means of signifying a missing date field - a > common need. > Dates are matched by comparing two date objects directly. Regular expressions are not valid in date fields. What exactly do you want to do? We could add a rule to match events with no date. Do you want to match a date entered as a text value only? > (5) AFAICT filters ".... with the <attribute>" fail. > > This may be my fault because I don't understand how they're supposed > to work: does <attribute> mean there must be an entry in the field > Attribute or does it just mean a "property"? > > For example "Nickname" is one of the <attribute> drop-down choices, > but peoples' Nicknames are not found. > On the other hand "Witness" appearing as an Attribute of a person > isn't found either. > > This works for me. If you enter an attribute type only, the rule will match any object with an attribute of that particular type. The rule will match against a value if entered. Entering a value only matches nothing, which could be considered a bug. Nick. |
From: doug <do...@o2...> - 2013-08-14 10:27:20
|
Nick, Thanks for the modifications! On 13/08/13 21:07, Nick Hall wrote: > On 13/08/13 15:32, doug wrote: >> The filter rules mostly work OK with regex, but there are >> several exceptions: >> >> (1) Events with the <citation> crashes gramps (bug #6995) >> > > This didn't look related to my changes, but I fixed it anyway. > >> (2) None of the filters "...... having notes containing >> <text>" work. >> They either fail to select or select incorrectly, with >> or without regex. >> > > This another bug that was unrelated to regular expressions. > I have fixed it. Both work fine now. > >> (3) None of the filters allowing the choice of a drop-down >> type (e.g. event type, attribute type) recognise >> user-defined types (e.g. "Port of call", "Evacuation") > > It works for me. Custom types do not appear in the > drop-down lists, so you will have to type in the name of the > custom type you are interested in. Regular expressions are > not allowed in this field. > Right - I had wondered about this. >> (4) Regex doesn't seem to work on Date fields (e.g >> 20[0|1]2 for 2002 and 2012) in the filter rules. >> There seems to be no means of signifying a missing >> date field - a common need. >> > > Dates are matched by comparing two date objects directly. > Regular expressions are not valid in date fields. Ah - I didn't realise that > > What exactly do you want to do? We could add a rule to > match events with no date. Do you want to match a date > entered as a text value only? Quite a number of rules involve a Date field, e.g. Persons/Families with events/data/citation Events with data/citation Places/Media with citation Citations matching parameters I'd like to be able to get from any of those rules the items where there is no Date entry, not just in Events. > > >> (5) AFAICT filters ".... with the <attribute>" fail. >> >> This may be my fault because I don't understand how >> they're supposed to work: does <attribute> mean there must >> be an entry in the field Attribute or does it just mean a >> "property"? >> >> For example "Nickname" is one of the <attribute> drop-down >> choices, but peoples' Nicknames are not found. >> On the other hand "Witness" appearing as an Attribute of a >> person isn't found either. >> >> > > This works for me. If you enter an attribute type only, the > rule will match any object with an attribute of that > particular type. The rule will match against a value if > entered. Entering a value only matches nothing, which could > be considered a bug. > > > Nick. Your clarifications were very helpful. Other than this business of the empty Date field, everything's working as expected and desired in 4.0 svn 22863M. Many thanks!! Doug |
From: doug <do...@o2...> - 2013-08-14 10:32:25
|
On 13/08/13 19:42, Serge Noiraud wrote: > Hi, > <snip> > I think the regexp is 20[01]2 for 2002 or 2012. > you must remove the pipe. <snip> > Serge > Thanks for pointing out my boob. However FYI gramps regex seems indifferent to the strict grammar - 20[01]2 or 20[0|1]2 do work equally well. Doug |
From: Serge N. <Ser...@fr...> - 2013-08-14 11:29:59
|
Hi doug, Le 14/08/2013 12:32, doug a écrit : > On 13/08/13 19:42, Serge Noiraud wrote: >> Hi, >> > <snip> >> I think the regexp is 20[01]2 for 2002 or 2012. >> you must remove the pipe. > <snip> >> Serge >> > Thanks for pointing out my boob. > > However FYI gramps regex seems indifferent to the strict > grammar - 20[01]2 or 20[0|1]2 do work equally well. The regexp 20[0|1]2 only means you can have 2002, 2012 and 20|2. This is why it works. The pipe is only useful between ( and ) for example : 20(02|12) > > Doug Serge |