The Print Preview should be in a testable state already. Please give it a try!
I have also included a new stock icon for the 'Zoom to fit width'
button, which is actually stolen from Evince. If anybody could draw a
nicer (more "Tangoish") one would be good.
And no, the problem is not in your system the Print toolbar button is
not working yet ;-)
Zsolt
On 8/19/07, Zsolt Foldvari <zsolt.foldvari@...> wrote:
> Benny,
>
> > A first user error, trying the new Kinship report of Brian.
> > The error itself is not a big problem, but the fact that GRAMPS
> > completely hangs
> > after it needing an xkill is annoying.
> > The file /tmp/previewSIH4WT.pdf itself exists and looks ok.
> At the moment we don't have our own print preview feature implemented,
> thus Gtk is trying to use its own built-in preview mechanism. This
> means it creates a PDF file and opens it in the default PDF viewer.
> It seems this hangs for you for some reason...
> I'm running it under Gnome and I get Evince opened with the preview.
>
> The lesson is that the next thing I need to do is the custom preview
> even before the draw report generation.
>
> Deprecation warnings should be gone now.
>
> Zsolt
>

Actually,
new will normally only be deprecated in python 3.0
I do wonder Don, where do you find this information? I look in google, but
nowhere do I see how one can know InstanceType can be used to have an object
without calling the __init__ method, not in ref documents, not in module
documents.
Only help(InstanceType) gives a somewhat cryptic defenition.
You have a crystal ball or something?
Benny
Quoting Don Allingham <don@...>:
> We are now using the non-deprecated types.InstanceType
>
> Don
>
> On Thu, 2007-08-30 at 18:09 -0600, Don Allingham wrote:
>> That was my first approach. Unfortunately, it provide to be
>> unsuccessful. The way things worked, we still ended up creating a bunch
>> of objects before we could unserialize them.
>>
>> If this method goes away, there is still a way we can do the same thing
>> with a bit of our own code.
>>
>> Don
>>
>> On Thu, 2007-08-30 at 09:54 -0700, Alex Roitman wrote:
>> > Don,
>> >
>> > On Wed, 2007-08-29 at 22:38 -0600, Don Allingham wrote:
>> > > import new
>> > >
>> > > person = new.instance(Person, None)
>> > > person.unserialize(data)
>> >
>> > It seems that "new" is the deprecated module in Python.
>> > I guess it may go away in the future.
>> >
>> > Maybe we could instead modify constructors so that they
>> > can take a serialized tuple as an optional argument?
>> > Something along the lines of:
>> >
>> > class Person:
>> > def __init__(self,data_tuple=tuple()):
>> > if data_tuple:
>> > self.unserialize(data_tuple)
>> > else:
>> > self.attribute1 = value1
>> >
>> > Alex
>> >
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

That was my first approach. Unfortunately, it provide to be
unsuccessful. The way things worked, we still ended up creating a bunch
of objects before we could unserialize them.
If this method goes away, there is still a way we can do the same thing
with a bit of our own code.
Don
On Thu, 2007-08-30 at 09:54 -0700, Alex Roitman wrote:
> Don,
>
> On Wed, 2007-08-29 at 22:38 -0600, Don Allingham wrote:
> > import new
> >
> > person = new.instance(Person, None)
> > person.unserialize(data)
>
> It seems that "new" is the deprecated module in Python.
> I guess it may go away in the future.
>
> Maybe we could instead modify constructors so that they
> can take a serialized tuple as an optional argument?
> Something along the lines of:
>
> class Person:
> def __init__(self,data_tuple=tuple()):
> if data_tuple:
> self.unserialize(data_tuple)
> else:
> self.attribute1 = value1
>
> Alex
>

Quoting St=E9phane Charette <stephanecharette@...>:
>> Stephane,
>>
>> i think you can improve the performance of your filter if you break the
>> for loop
>> if not ok, instead of for all handles running over all backlinks.
>>
>> So eg :
>>
>> for item in db.find_backlink_handles(handle):
>> count +=3D 1
>> if count > value :
>> return False
>
> But what if the filter is to see if count > value -- then I'd have to
> return True. This means putting the return logic code inside the
> "for" loop.
>
> Are you certain putting the logic return code inside the for loop and
> executing it for every handle would really be faster?
Well, it depends on the database structure and how the pages are hit to
look up
backreferences. No idea there.
If you have, db.find_backlink_handles(handle), probably everything is
looked up
before you even start, so
count =3D len(db.find_backlink_handles(handle)) is just as good.
if there is a db method of only obtaining the first backlink handle, then y=
es,
it will be faster, but it needs different way of accessing the data, namely
with iterators. Don't know if that is implemented.
Note that if you worry about the check in the for loop to see if equal, you
could do 3 loops in three different functions, and in prepare set the funct=
ion
that must run. You have the best of both worlds, so
def prepare():
if 'equal':
self.func =3D self._equal_func
else
...
and then in apply :
return self.func()
However, as I said, the db.find_backlink_handles(handle) has probably hit t=
he
database already, so no use optimizing as that is the slow guy (hitting you=
r
hard disk).
I just wrote my first idea down when I saw your code. I just want to make i=
t
very clear that with filters thinking hard about performance pays, as you k=
now
beforehand that all handles in the database will checked, so the faster the
check, the better. Checks that themselves need a lot of db access or
calculation will be slow.
Benny
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Don,
On Wed, 2007-08-29 at 22:38 -0600, Don Allingham wrote:
> import new
>=20
> person =3D new.instance(Person, None)
> person.unserialize(data)
It seems that "new" is the deprecated module in Python.
I guess it may go away in the future.
Maybe we could instead modify constructors so that they
can take a serialized tuple as an optional argument?
Something along the lines of:
class Person:
def __init__(self,data_tuple=3Dtuple()):
if data_tuple:
self.unserialize(data_tuple)
else:
self.attribute1 =3D value1
Alex
--=20
Alexander Roitman http://gramps-project.org

> Stephane,
>
> i think you can improve the performance of your filter if you break the
> for loop
> if not ok, instead of for all handles running over all backlinks.
>
> So eg :
>
> for item in db.find_backlink_handles(handle):
> count += 1
> if count > value :
> return False
But what if the filter is to see if count > value -- then I'd have to
return True. This means putting the return logic code inside the
"for" loop.
Are you certain putting the logic return code inside the for loop and
executing it for every handle would really be faster?
> would greatly improve performance, especially if value=0.
> Also, if you put
>
> value = int(self.list[1])
>
> in the prepare method, as
> def prepare(...)
> self.value = int(self.list[1])
>
> you avoid doing the str to int conversion for every handle that is passed.
> In the same way, you can store the self.list[0] as an integer in the prepar
> e,
> avoiding the need to check with a translated _('lesser than')
> This removes the gettext call on every handle, and improves the equality
> checking.
Thanks! I didn't know about prepare(). Now I see other examples of
it. I'll take care of it today.
Stephane

> So I go to my email to send an apology, and find that Jérôme is way ahead of me.
Maybe you thought on "FTM". I need to translate all english words,
sometimes this could avoid "shortcuts into head" but introduces other
mistakes ...
> Now I've proven to everyone I'm a complete idiot! Ah well, at least you all learned it sooner rather than later.
It is with this current error that idiot is defined ?
Then I am an idiot !!!

Jérôme wrote:
>> I would recommend against calling anything in Gramps "Family Tree
>> Manager". That is the
>> trademarked name of a well-known program, and the owners of that
>> trademark have been known to protect it.
>
> This is an U.S issue !!!
> With localization we will have an other string (i.e in french -
> Gestionnaire d'Arbre Familial)
>
> Why not using Family Trees Manager ?
>
>> trademarked name of a well-known program
>
> which one, there is a Family Tree Maker, don't remenber for "Family Tree
> Manager"?
I was just working on something else, and out of nowhere the thought
popped into my head "Family Tree Manager is fine, the trademark is
Maker, not Manager." So I go to my email to send an apology, and find
that Jérôme is way ahead of me.
My apologies, but thank you Jérôme.
Now I've proven to everyone I'm a complete idiot! Ah well, at least you
all learned it sooner rather than later.
Cheers,
Anne.

> I would recommend against calling anything in Gramps "Family Tree Manager". That is the
> trademarked name of a well-known program, and the owners of that
> trademark have been known to protect it.
This is an U.S issue !!!
With localization we will have an other string (i.e in french -
Gestionnaire d'Arbre Familial)
Why not using Family Trees Manager ?
> trademarked name of a well-known program
which one, there is a Family Tree Maker, don't remenber for "Family Tree
Manager"?

Thanks for the suggestions Benny. I'm going to first follow your
suggestion on the Users list and do a short How Do I that includes a
pointer to the tmg2gramps stuff I wrote. Then (after getting the dev 3.0
version running) I'll get stuck into the Manage Family Trees page you
point to, basing it on the page Don wrote that you refer to.
One comment I have immediately however. I would recommend against
calling anything in Gramps "Family Tree Manager". That is the
trademarked name of a well-known program, and the owners of that
trademark have been known to protect it.
I thought of "Family Tree Organiser", but I'm not very happy with that
and don't know why.
Cheers,
Anne.

OK. I tried it with a large database.
I got the following at the end of the load :
3510853: ERROR: DbLoader.py: line 502: Failed to import database.
Traceback (most recent call last):
File "/usr/share/gramps/DbLoader.py", line 492, in do_import
importer(self.dbstate.db, filename, self.uistate.pulse_progressbar)
File "/usr/share/gramps/GrampsDbUtils/_ReadXML.py", line 144, in importDa=
ta
parser.parse(xml_file,use_trans,lc,pc)
File "/usr/share/gramps/GrampsDbUtils/_ReadXML.py", line 640, in parse
self.p.ParseFile(file)
File "/usr/share/gramps/GrampsDbUtils/_ReadXML.py", line 2017, in endElem=
ent
self.func(''.join(self.tlist))
File "/usr/share/gramps/GrampsDbUtils/_ReadXML.py", line 1379, in=20
stop_object
self.db.commit_media_object(self.object,self.trans,self.change)
File "/usr/share/gramps/GrampsDb/_GrampsDbBase.py", line 516, in=20
commit_media_object
transaction, change_time)
File "/usr/share/gramps/GrampsDb/_GrampsDBDir.py", line 1497, in commit_b=
ase
data_map.put(handle,obj.serialize(),txn=3Dthe_txn)
File "/usr/share/gramps/RelLib/_MediaObject.py", line 107, in serialize
self.marker.serialize(),
AttributeError: 'NoneType' object has no attribute 'serialize'
Le/The jeudi 30 ao=FBt 2007, Don Allingham a =E9crit/wrote=A0:
> I've made a major change in the way we pull data out of the database.
> The new scheme should vastly improve report and export performance.
>
> Please try generating reports and exporting data with the current SVN
> branch. Report any problems to me.
>
> For those of you interested in the low level details, we were
> encountering some performance issues with object initialization. Every
> time we pull data out of the database, we have to create a new object,
> and then populate it.
>
> Typically, we did something like:
>
> person =3D Person()
> person.unserialize(data)
>
> The problem is that every data item is getting written twice. Once in
> the init routine, and once in the unserialize routine.
>
> I've been able to take advantage of the dynamic nature of python, and
> create an empty object, and then rely on the unserialize function to
> load the data properly. This can only be done safely when we are
> creating an object, and then directly and fully populating it. So, the
> code ends up looking like:
>
> import new
>
> person =3D new.instance(Person, None)
> person.unserialize(data)
>
> This prevents the double initialization, and leads to almost a 50%
> increase in performance.
>
> However, since this is a pretty bizarre and obscure thing to do, I would
> like to have some pretty heavy testing.
>
> So, please test.
>
> Don

Quoting St=E9phane Charette <stephanecharette@...>:
>>
>> Filters are easy. In this case, you give a list of media handles to the
>> filter and see if it is present in the backlinks, something like
>>
>> for backlink in database.find_backlink_handles(media_handle):
>> # count number of backlinks
>
> Hmm... :) Slightly more complicated, but thanks for the hint.
>
> If anyone wants to try it out, this is now committed to svn on the
> trunk/3.0 branch. For example:
>
> Events tab -> Edit -> Event Filter Editor -> Add a new filter -> Add
> another rule -> General Filters -> Events with a reference count ->
> ...
>
> St=E9phane
Stephane,
i think you can improve the performance of your filter if you break the
for loop
if not ok, instead of for all handles running over all backlinks.
So eg :
for item in db.find_backlink_handles(handle):
count +=3D 1
if count > value :
return False
would greatly improve performance, especially if value=3D0.
Also, if you put
value =3D int(self.list[1])
in the prepare method, as
def prepare(...)
self.value =3D int(self.list[1])
you avoid doing the str to int conversion for every handle that is passed.
In the same way, you can store the self.list[0] as an integer in the prepar=
e,
avoiding the need to check with a translated _('lesser than')
This removes the gettext call on every handle, and improves the equality
checking.
For filters, all these performance issues are important, especially
with things
like FilterProxyDb, and people complaining it being slower ;-)
As little unneccessary computations should be done in the apply method.
Benny
(Changed to devel list as users have no interest in this mail)
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

I've made a major change in the way we pull data out of the database.
The new scheme should vastly improve report and export performance.
Please try generating reports and exporting data with the current SVN
branch. Report any problems to me.
For those of you interested in the low level details, we were
encountering some performance issues with object initialization. Every
time we pull data out of the database, we have to create a new object,
and then populate it.
Typically, we did something like:
person =3D Person()
person.unserialize(data)
The problem is that every data item is getting written twice. Once in
the init routine, and once in the unserialize routine.
I've been able to take advantage of the dynamic nature of python, and
create an empty object, and then rely on the unserialize function to
load the data properly. This can only be done safely when we are
creating an object, and then directly and fully populating it. So, the
code ends up looking like:
import new
person =3D new.instance(Person, None)
person.unserialize(data)
This prevents the double initialization, and leads to almost a 50%
increase in performance.
However, since this is a pretty bizarre and obscure thing to do, I would
like to have some pretty heavy testing.
So, please test.
Don

Ok, I get it,
the po Changelog is for people changing eg the de.po, and the help
Changelog for
people changing gramps.xml
In that case, lets leave it as it is, and have developers add all their
changes
to ChangeLog. Translators can use the other ones.
I suppose one can also have the situation where translators are allowed to
commit po files and po ChangeLog, but not the rest of the code.
Benny
Quoting Alex Roitman <shura@...>:
> Hi guys,
>
> On Wed, 2007-08-29 at 12:59 -0700, Brian Matherly wrote:
>> I agree completely. Does anyone even know why there is a second
>> ChangeLog? There must be some reason, or it never would have been
>> created? Who would stand to benefit from a separate ChangeLog for po?
>
> It was created by the intltool that works out the tranlsation magic.
> Their logic is, the translators that work with po files are
> usually different set of people that hack on the code. So they
> work with po/ directory and document their changes in po/ChangeLog
>
>> I think that's the heart of the question. It seems to me that it
>> would be prudent to get the opinion of the person who actually
>> creates the code release package (tarball, or whatever you want to
>> call it). Who is that, anyway?
>
> I don't think it's crucial to have two changelogs (actually, three,
> because there's another one in help/ dir, for the manual).
>
> I never had this problem though, because in Emacs the C-x a-4 shortcut
> looks first for the ChangeLog in the current dir, and if not found it
> looks for the one in the upped dir, etc.
>
> This is not crucial and I don't think I should have a big say in
> how things are, now that I don't contribute as much. Still, unless
> it really hurts maybe it's a good idea to leave things as they are?
> If it really hurts then one ChangeLog should be OK. But then,
> you guys are lobbying for now ChangeLogs at all :-)
>
> Alex
>
> --
> Alexander Roitman http://gramps-project.org
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi guys,
On Wed, 2007-08-29 at 12:59 -0700, Brian Matherly wrote:
> I agree completely. Does anyone even know why there is a second ChangeLog=
? There must be some reason, or it never would have been created? Who would=
stand to benefit from a separate ChangeLog for po?
It was created by the intltool that works out the tranlsation magic.
Their logic is, the translators that work with po files are
usually different set of people that hack on the code. So they
work with po/ directory and document their changes in po/ChangeLog
> I think that's the heart of the question. It seems to me that it would be=
prudent to get the opinion of the person who actually creates the code rel=
ease package (tarball, or whatever you want to call it). Who is that, anywa=
y?
I don't think it's crucial to have two changelogs (actually, three,
because there's another one in help/ dir, for the manual).
I never had this problem though, because in Emacs the C-x a-4 shortcut
looks first for the ChangeLog in the current dir, and if not found it
looks for the one in the upped dir, etc.
This is not crucial and I don't think I should have a big say in
how things are, now that I don't contribute as much. Still, unless
it really hurts maybe it's a good idea to leave things as they are?
If it really hurts then one ChangeLog should be OK. But then,
you guys are lobbying for now ChangeLogs at all :-)
Alex
--=20
Alexander Roitman http://gramps-project.org

Zolt,=0A=0A>My only point here was that it is the worst to log the changes =
at two=0A>places. So either let's log it in one of the ChangeLog files (I r=
eally=0A>don't mind which one), or not log it at all.=0A=0AI agree complete=
ly. Does anyone even know why there is a second ChangeLog? There must be so=
me reason, or it never would have been created? Who would stand to benefit =
from a separate ChangeLog for po?=0A=0A>Who's gonna decide?=0A=0AI think th=
at's the heart of the question. It seems to me that it would be prudent to =
get the opinion of the person who actually creates the code release package=
(tarball, or whatever you want to call it). Who is that, anyway?=0A=0A~Bri=
an=0A=0A=0A

Quoting Zsolt Foldvari <zsolt.foldvari@...>:
> Brian,
>
> I don't have any strong feeling to either direction. I don't mind to
> update the ChangeLog file, but for me it would be also fine to use
> subversion log.
>
> My only point here was that it is the worst to log the changes at two
> places. So either let's log it in one of the ChangeLog files (I really
> don't mind which one), or not log it at all.
>
Just like stephanne, I have upto now always added POTFILE changes to
ChangeLog.
It is clear that doing it in /po will be forgotten every time we have new
comitters.
I vote for only one ChangeLog, the ChangeLog.
Benny
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi,
while debugging I see we have a dangerous/difficult to debug/find issue in the
way we export global var in __init__
We have in src/PluginUtils/__init__.py :
from _PluginMgr import \
register_export, register_import, \
register_tool, register_report, \
register_relcalc, relationship_class, \
textdoc_list, drawdoc_list, bookdoc_list, \
bkitems_list, cl_list, cli_tool_list, \
load_plugins, import_list, export_list,\
report_list, quick_report_list, tool_list, \
register_text_doc, register_draw_doc, register_book_doc,\
register_quick_report
So we import here eg export_list, but this fixes the pointer to the list
export_list, which is a global var of _PluginMgr, in the PluginUtils module.
If one now changes the global var in _PluginMgr by assignment
export_list = ['dummy']
one still has the old variable in memory when reached via PluginUtils (eg from
PluginUtils import export_list)!
Conclusion, one should not export global var like this. One should export
functions returning the global var, or do
import _PluginMgr as PluginMgr
and obtain the global var directly as 'PluginMgr.export_list', which will be the
updated version.
As changing all this in PluginUtils would be an errorprone work, I worked around
this by removing the assignments in the PluginMgr module, that is, I changed
export_list = [ item for item in export_list
if item[0].__module__ not in failed_module_names ]
into
export_list[:] = [ item for item in export_list
if item[0].__module__ not in failed_module_names ][:]
This allows to remove the old strange way of making 'purge_fail' a function that
returns the global var to overwrite the PluginUtils var.
Benny
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Brian,
I don't have any strong feeling to either direction. I don't mind to
update the ChangeLog file, but for me it would be also fine to use
subversion log.
My only point here was that it is the worst to log the changes at two
places. So either let's log it in one of the ChangeLog files (I really
don't mind which one), or not log it at all.
Who's gonna decide?
Cheers,
Zsolt
On Tue, 28 Aug 2007 19:11:36 -0700 (PDT) Brian Matherly
<brian@...> wrote:
> Zolt,
>
> Oh good grief. It's bad enough that I have to enter redundant
> information in a ChangeLog and the Subversion commit message when I
> commit a change. When I add a file I also have to edit POTFILES.in
> (surely that could be automated). Now I have to edit another
> ChangeLog when I add a file as well. We're getting to the point were
> it will take me longer to commit my changes than it does to make them
> in the first place.
>
> I've always been a proponent of doing away with the ChangeLog and
> using the Subversion log. But I can't get any support from anyone
> else to do that. Would you be interested in doing that for
> POTFILES.in? It's really simple:
>
> svn log -v POTFILES.in
>
> If you want the good old fashioned GNU style, use svn2cl:
>
> http://linux.die.net/man/1/svn2cl
>
> It is just frustrating to me how much work it is to commit files.
> Especially when adding a new file. I expect my pleas will fall on
> deaf ears again (The CVS ways are deeply entrenched), but I thought
> it would be worth a try.
>
> Nonetheless, I'm gulity of not editing the po/ChangeLog file on
> account of not being aware of that policy. So whatever is decided,
> just let me know.
>
> ~Brian
>
> ----- Original Message ----
> From: zsolt foldvari <zsolt.foldvari@...>
> To: "gramps-devel@..."
> <gramps-devel@...> Sent: Tuesday, August 28, 2007
> 5:33:52 PM Subject: [Gramps-devel] POTFILES.in changes log
>
> At the moment the changes of the po/POTFILES.in file are logged at two
> different places: ./ChangeLog and po/ChangeLog. I think it would be
> better to use only one of them.
> Personally I like the po/ChangeLog better.
>
> Zsolt
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser. Download your FREE copy of Splunk now >>
> http://get.splunk.com/ _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
>
>