Tamás Nepusz

> The problem is that we also call vector_shuffle() within the main loop, which already includes an RNG_BEGIN/END pair. aaah. This is something that should be fixed in 1.0 (if...

1. Agreed 2. A warning would be nice. 3. I don't think the performance implictions are significant here, except for maybe sparse matrices. Plain cast is okay for me. 4....

I think that the functions might have changed since you added this issue and some of the points raised here are no longer relevent: * I don't see any calls...

Yes, one would need the edge IDs in weighted multigraphs -- but only in weighted multigraphs and not in weighted simple graphs or non-weighted multigraphs, where the matching vector is...

Not sure about this; in theory, the function could be useful, but it needs to be generalized in several ways in order to make it really flexible, and I'm not...

Python interface updated and adapted in igraph/python-igraph@1c423c60

Unfortunately even if the one in pydot is functionally equivalent to the "official" parser, we would still need to implement an equivalent parser in C (preferably based on Flex/Bison as...

Yes; most of the reader functions implemented in igraph use some kind of an internal data structure (like the one you have found in `foreign-ncol-header.h`) to collect all the information...

Okay, this bothers me and it's a fuzzing issue so let's try to tackle it. I'll make a quick patch with an internal "resizable string" data type and re-write `dot_escape()`...

Okay, check out the commit above. it rewrites `dot_escape()` to use an `igraph_vector_char_t` that is grown only when needed.