Hi, I encountered a strange problem. While saving a graph from a script, the generated file is mostly )or completely) composed by "NUL" characters. This happens with both dot and xml.gz outputs. The script correclty prints the number of edges and vertices. The properties list is also correct and the labels of the vertices are correctly stored in memory andd printed on screen. The only output to the file is a huge number of NUL and, in the dot case, some of the edges. The error happens after building the graph from a data file (with a custom script) and also after loading (in the interactive console) graphs previously saved in xml.gz format with graph_tool. I cannot reproduce the error via interactive console creating a graph with 2 nodes, 1 edge and no properties.
OS is ubuntu and graph_tool version is 2.2.15-1
Everything worked just fine until past week.
Thanks in advance for the help, Giuseppe
Hi Giuseppe,
On 10/10/2011 11:40 AM, Giuseppe Profiti wrote:
Hi, I encountered a strange problem. While saving a graph from a script, the generated file is mostly )or completely) composed by "NUL" characters. This happens with both dot and xml.gz outputs. The script correclty prints the number of edges and vertices. The properties list is also correct and the labels of the vertices are correctly stored in memory andd printed on screen. The only output to the file is a huge number of NUL and, in the dot case, some of the edges. The error happens after building the graph from a data file (with a custom script) and also after loading (in the interactive console) graphs previously saved in xml.gz format with graph_tool. I cannot reproduce the error via interactive console creating a graph with 2 nodes, 1 edge and no properties.
OS is ubuntu and graph_tool version is 2.2.15-1
Everything worked just fine until past week.
In order for me to understand what might be going on, you must provide some sort of example of this problem happening. I've never experienced anything remotely like this.
Try to reproduce the problem with a short script, and send me the script so that I may look at it. It would also be useful to take a look at the corrupt data file itself...
Cheers, Tiago
Hi Tiago,
2011/10/11 Tiago de Paula Peixoto tiago@skewed.de
Hi Giuseppe,
On 10/10/2011 11:40 AM, Giuseppe Profiti wrote:
Hi, I encountered a strange problem. While saving a graph from a script, the
generated file is mostly )or completely) composed by "NUL" characters. This happens with both dot and xml.gz outputs.
The script correclty prints the number of edges and vertices. The
properties list is also correct and the labels of the vertices are correctly stored in memory andd printed on screen.
The only output to the file is a huge number of NUL and, in the dot case,
some of the edges.
The error happens after building the graph from a data file (with a
custom script) and also after loading (in the interactive console) graphs previously saved in xml.gz format with graph_tool.
I cannot reproduce the error via interactive console creating a graph
with 2 nodes, 1 edge and no properties.
OS is ubuntu and graph_tool version is 2.2.15-1
Everything worked just fine until past week.
In order for me to understand what might be going on, you must provide some sort of example of this problem happening. I've never experienced anything remotely like this.
Try to reproduce the problem with a short script, and send me the script so that I may look at it. It would also be useful to take a look at the corrupt data file itself...
I'll try to create a graph similar to those I'm using, because I cannot share the actual data (NDA and stuff like that). It seems to be closely related to my graphs: simple graphs (7 nodes, few edges) are not affected. However, just a simple script like that:
from graph_tool.all import * g = load_graph('old_graph.xml.gz') g.save('test.dot')
generates the error. 'old_graph.xml.gz' was created few days ago on another machine running graph_tool 2.2.14. The output is attached (I can share that, it contains almost nothing :-) )
I'm trying to pinpoint the type of graph affected by this issue and then I'll share my results with you.
Thanks again, Giuseppe
2011/10/11 Giuseppe Profiti gamma2@users.sourceforge.net
Hi Tiago,
2011/10/11 Tiago de Paula Peixoto tiago@skewed.de
Hi Giuseppe,
On 10/10/2011 11:40 AM, Giuseppe Profiti wrote:
Hi, I encountered a strange problem. While saving a graph from a script, the
generated file is mostly )or completely) composed by "NUL" characters. This happens with both dot and xml.gz outputs.
The script correclty prints the number of edges and vertices. The
properties list is also correct and the labels of the vertices are correctly stored in memory andd printed on screen.
The only output to the file is a huge number of NUL and, in the dot
case, some of the edges.
The error happens after building the graph from a data file (with a
custom script) and also after loading (in the interactive console) graphs previously saved in xml.gz format with graph_tool.
I cannot reproduce the error via interactive console creating a graph
with 2 nodes, 1 edge and no properties.
OS is ubuntu and graph_tool version is 2.2.15-1
Everything worked just fine until past week.
In order for me to understand what might be going on, you must provide some sort of example of this problem happening. I've never experienced anything remotely like this.
Try to reproduce the problem with a short script, and send me the script so that I may look at it. It would also be useful to take a look at the corrupt data file itself...
I'll try to create a graph similar to those I'm using, because I cannot share the actual data (NDA and stuff like that). It seems to be closely related to my graphs: simple graphs (7 nodes, few edges) are not affected. However, just a simple script like that:
from graph_tool.all import * g = load_graph('old_graph.xml.gz') g.save('test.dot')
generates the error. 'old_graph.xml.gz' was created few days ago on another machine running graph_tool 2.2.14. The output is attached (I can share that, it contains almost nothing :-) )
I'm trying to pinpoint the type of graph affected by this issue and then I'll share my results with you.
I purged all the label attributes, so it has become an "anonymous" graph. This is the trace of the python console: as you can see, nodes, edges and properties are correctly loaded
g = load_graph('my.graph.xml.gz') g.num_vertices()
153
g.num_edges()
1786
g.list_properties()
L (graph) (type: double, val: 1554100010.16) C(1) (graph) (type: python::object, val: (0.4511453168253582, 0.018514982664053672)) Cdepth (graph) (type: int32_t, val: 3) C(2) (graph) (type: double, val: 0.720623810024) label (graph) (type: string, val: my.graph) h (vertex) (type: string) weight (edge) (type: double) bl (edge) (type: double) identity (edge) (type: double)
but when I save it, the output is corrupted. Just a side note: I'm running ubuntu on virtualbox.
Thanks, Giuseppe
On 10/11/2011 11:19 AM, Giuseppe Profiti wrote:
I purged all the label attributes, so it has become an "anonymous" graph. This is the trace of the python console: as you can see, nodes, edges and properties are correctly loaded
g = load_graph('my.graph.xml.gz') g.num_vertices()
153
g.num_edges()
1786
g.list_properties()
L (graph) (type: double, val: 1554100010.16) C(1) (graph) (type: python::object, val: (0.4511453168253582, 0.018514982664053672)) Cdepth (graph) (type: int32_t, val: 3) C(2) (graph) (type: double, val: 0.720623810024) label (graph) (type: string, val: my.graph) h (vertex) (type: string) weight (edge) (type: double) bl (edge) (type: double) identity (edge) (type: double)
but when I save it, the output is corrupted. Just a side note: I'm running ubuntu on virtualbox.
I loaded your graph, and saved it in both formats and everything came out fine. I even tried on an ubuntu machine, and everything worked just as well.
I have been saving and loading graphs repeatedly, on diverse machines (with Gentoo, Debian, MacOS), clusters nodes, etc, and I've never observed this problem.
I'm inclined to believe this is due to something peculiar on your setup. The fact it is running on a virtual machine is maybe relevant... Have you observed any other problems?
Cheers, Tiago
2011/10/11 Tiago de Paula Peixoto tiago@skewed.de
[cut]
I loaded your graph, and saved it in both formats and everything came out fine. I even tried on an ubuntu machine, and everything worked just as well.
I have been saving and loading graphs repeatedly, on diverse machines (with Gentoo, Debian, MacOS), clusters nodes, etc, and I've never observed this problem.
I'm inclined to believe this is due to something peculiar on your setup. The fact it is running on a virtual machine is maybe relevant... Have you observed any other problems?
Besides the bug I submitted a while ago, this is the first serious problem I'm having with graph_tool. It is possible that the problem may be located in the C++ back end used for reading/writing? I mean, some corrupt C++ library recently installed on my machine. Also, it seems strange mostly because smaller hand made graphs seems not to be affected by this issue.
The only other thing that comes to my mind is a problem evaluating the average shortest path on the graph: as you can see from the file, the number is a bit wrong, but I tested it again on that machine (the virtualbox one) and I'm inclined to think that there was a bug on the script that generated the value (on another machine, a plain simple debian stable running graph_tool 2.2.14).
Thanks anyways, Giuseppe
2011/10/11 Giuseppe Profiti gamma2@users.sourceforge.net
2011/10/11 Tiago de Paula Peixoto tiago@skewed.de
[cut]
I loaded your graph, and saved it in both formats and everything came out fine. I even tried on an ubuntu machine, and everything worked just as well.
I have been saving and loading graphs repeatedly, on diverse machines (with Gentoo, Debian, MacOS), clusters nodes, etc, and I've never observed this problem.
I'm inclined to believe this is due to something peculiar on your setup. The fact it is running on a virtual machine is maybe relevant... Have you observed any other problems?
Besides the bug I submitted a while ago, this is the first serious problem I'm having with graph_tool. It is possible that the problem may be located in the C++ back end used for reading/writing? I mean, some corrupt C++ library recently installed on my machine. Also, it seems strange mostly because smaller hand made graphs seems not to be affected by this issue.
The only other thing that comes to my mind is a problem evaluating the average shortest path on the graph: as you can see from the file, the number is a bit wrong, but I tested it again on that machine (the virtualbox one) and I'm inclined to think that there was a bug on the script that generated the value (on another machine, a plain simple debian stable running graph_tool 2.2.14).
I'm sorry for the multiple emails: I just tested the same script on the same file, but with output in a directory local to the virtual machine (instead of a shared folder as before). Everything worked just fine, so the issue seems to be file-system/virtual machine related.
Thanks for the help, Giuseppe
PS: I hope that I can contribute to graph_tool in the future, there are a couple of algorithms that I had to implement in python (and they are way too slow) or use from another library (in Java, then I had to develop another program) that I would gladly see in your library.
On 10/11/2011 12:18 PM, Giuseppe Profiti wrote:
I'm sorry for the multiple emails: I just tested the same script on the same file, but with output in a directory local to the virtual machine (instead of a shared folder as before). Everything worked just fine, so the issue seems to be file-system/virtual machine related.
Well, that explains it then. :-)
PS: I hope that I can contribute to graph_tool in the future, there are a couple of algorithms that I had to implement in python (and they are way too slow) or use from another library (in Java, then I had to develop another program) that I would gladly see in your library.
Contributions are encouraged!
You may open a ticket on the website for algorithms you want to see implemented. I don't have enough time to implement everything right away, but it is useful to keep an overview of what is needed or wanted.
Cheers, Tiago
-
Giuseppe Profiti -
Tiago de Paula Peixoto