From: Doug B. <dou...@gm...> - 2013-09-27 11:08:29
|
print_fonction is mispelled. -Doug On Fri, Sep 27, 2013 at 6:51 AM, jerome <rom...@ya...> wrote: > Benny, > > >> from __future__ import print_function > > This does not work for this plugins! > > It seems that I need to set something somewhere else: > > File "/usr/share/gramps/gen/plug/_manager.py", line 219, in load_plugin > _module = self.import_plugin(pdata) > File "/usr/share/gramps/gen/plug/_manager.py", line 251, in import_plugin > module = __import__(pdata.mod_name) > SyntaxError: future feature print_fonction is not defined > > I have some "print_line", "print_help", etc ... but no "print_function" via __future__ ! > > > > Note, once I get some lists, dict, etc... or whatever, with my database from backup files, displayed into the experimental gramplet, I will try to look at a patch for 'Check and Repair' tool. > > Maybe we should not release new versions with this state! > > OK, no more broken links (sourceref) after merging citations. > But dummy empty citation records created by 'Check and Repair' tool are making recovery harder. > > > Maybe it will be possible to include an option into the tool for looking at any backup files before creating these dummy records? There is the same process by importing a backup file, fixing links with dummy records. > > It is great for few records, but batch tools can generate a lot of changes, at a glance. > So, merging citations (3.4.5 and before), then running 'Check and Repair' might create a lot of dummy records... :( A data loss could happen around some citation records. > > Right now, I see two/three ways for looking at possible data loss. > The simplier is maybe via 'Check and Repair' tool! > > I have a workaround on the experimental gramplet because the note created by the tool, has been generated few secondes after dummy records. So, by ignoring the last character on timestamp string/value we can get these records. Same as backlinks for the note but maybe more easy to know the type of object. Check and Repair does not need this workaround because broken links are already listed. > > I tried to backport to 3.4.x, Doug's environment (to_struct), but it seems that there is more[1][2] than only 3rd party libs. > > I will try to provide a patch, maybe without a generic way (all OS) for gunzip(ing) .gramps, it will be easier to review changes and look at possible improvements. > > > > [1] http://www.gramps-project.org/bugs/view.php?id=7072#c31539 > [2] http://www.gramps-project.org/bugs/view.php?id=7072#c31545 > > > Jérôme > > > > ________________________________ > De : Benny Malengier <ben...@gm...> > À : Jerome <rom...@ya...> > Cc : Vassilii Khachaturov <vas...@ta...>; Gramps Development List <gra...@li...> > Envoyé le : Vendredi 27 septembre 2013 9h35 > Objet : Re: [RESOLVED] Inconsistency on database [was Gramps 3.4.6 / 4.0.2] > > > > And add a > from __future__ import print_function > > > Benny > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |