casting & division by zero issues

[Markus Pelkonen]

From: Magnus
Sent: 2007-10-17
Subject: Timevisualizerplugin patch

I had some problems making the plugin run on postgres (python2.4 and trac0.10).

The first problem was that 'casting' with +0.0 fails; I have replaces this with some python code that should work with all databases.

The next problem is that code like:

cursor.execute(sql).fetchall()

fails. I have replaces this with

cursor.execute(sql)
cursor.fetchall()

I also got some Division by Zero issues that I have fixed with some max() code.

Included in this mail is the resulting impl.py as well as a patch against 2665.

[Markus Pelkonen]

With a quick reading, the patch seems feasible.

I'm surprised that chained method calls cursor.execute(...).fetchall() doesn't work for u. But well, some say that it is good coding convention to break statements like that, thus I'll migrate... in next release.

[Markus Pelkonen]

#2248 is probably duplicate

[Yves Serrano]

patch against rev 2860

[Yves Serrano]

the patch failed on my installation, added a new patch against 2860 and replaced the command line path with sys.argv[1]

[Markus Pelkonen]

Replying to yserrano:

the patch failed on my installation

What was the error in detail?

added a new patch against 2860 and replaced the command line path with sys.argv[1]

Was this command line handling the only change?

[Markus Pelkonen]

I couldn't ever reproduce the issue, not even in Debian Etch running inside Vmware player. Well, I sill used sqlite.

I've made new 0.5 release candidate under trunk. Please try it and let me know if I merged first patch properly. At least my M$ installation didn't break.

[Markus Pelkonen]

differences between first and second patch

[Markus Pelkonen]

Replying to mape:

Replying to yserrano:

the patch failed on my installation

What was the error in detail?

added a new patch against 2860 and replaced the command line path with sys.argv[1]

Was this command line handling the only change?

I applied both patches afterwards and then compared those local files, result is patch_comparison.diff​. Changes affect only __main__​. I don't see why the first patch then would have failed but the second patch would solve issued. Thus I ignore the latter patch.

Indeed, hard coded values are bad, thus I created new ticket: #2291 because those ideas don't fall under topic of this ticket.

[Yves Serrano]

Replying to mape:

I applied both patches afterwards and then compared those local files, result is patch_comparison.diff​. Changes affect only __main__​. I don't see why the first patch then would have failed but the second patch would solve issued. Thus I ignore the latter patch.

Indeed, hard coded values are bad, thus I created new ticket: #2291 because those ideas don't fall under topic of this ticket.

Strange, when I tried to apply your original patch on mac os x or under linux I got this results:

yserrano:/tmp/timevisualizerplugin$ svn info
URL: http://trac-hacks.org/svn/timevisualizerplugin/tags/TimeVisualizer_0.4
yserrano:/tmp/timevisualizerplugin$ patch -p0 < ../impl.py.patch 
(Stripping trailing CRs from patch.)
patching file tractimevisualizerplugin/impl.py
Hunk #1 FAILED at 90.
Hunk #2 FAILED at 135.
Hunk #3 FAILED at 155.
Hunk #4 FAILED at 241.
Hunk #5 FAILED at 291.
5 out of 5 hunks FAILED -- saving rejects to file tractimevisualizerplugin/impl.py.rej
yserrano:/tmp/timevisualizerplugin$ patch -p0 < ../patch2860-impl.py 
patching file tractimevisualizerplugin/impl.py
yserrano:/tmp/timevisualizerplugin$

but now this fixes are in the trunk, so I switched to the trunk version which works fine.

[Markus Pelkonen]

I don't know nix tools very well, e.g. never used patch tool. That my patch is actually svn diff, may differ from unified diff. Maybe you should have tried 'svn merge ...' instead.

But trunk works for you how, so I consider this issue fixed.