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.
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...
2011/10/11 Tiago de Paula Peixoto <tiago(a)skewed.de>
Hi Giuseppe,
> 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.
2011/10/11 Giuseppe Profiti <gamma2(a)users.sourceforge.net>
Hi Tiago,
2011/10/11 Tiago de Paula Peixoto <tiago(a)skewed.de>
Hi Giuseppe,
> 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()
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?
2011/10/11 Tiago de Paula Peixoto <tiago(a)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).
2011/10/11 Giuseppe Profiti <gamma2(a)users.sourceforge.net>
2011/10/11 Tiago de Paula Peixoto <tiago(a)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.
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.
)