Tamás Nepusz

The attached patch now makes the compilation work with the most recent `master` revision of igraph. I have no idea whether the output makes sense. [igraph.patch.zip](https://github.com/igraph/python-igraph/files/9332096/igraph.patch.zip)

Sanitizers did not reveal anything so I'm pretty convinced that it doesn't cause problems. But, just to be on the safe side, we can wrap them in a wrapper that...

Re the changes to `s_copy()` and `s_cat()`: these are internal f2c functions (not native Fortran ones), but there are variants floating around where they clearly return an `int` (even though...

Committed the prototype changes and updated the Python interface so now both the `master` and the `develop` branch should compile in the Docker container as outlined above, without any patches...

Sorry for the late reply, I'm kinda swamped with work in the last few weeks. Is this patch for IPython? Would this mechanism simply replace the existing `_repr_png` and `_repr_svg`...

I have tried an implementation of `_repr_png_` before (in response to a complaint from a user where `_repr_svg_` did not work for him in a particular setup), but the problem...

Yes, removing `_repr_png_` is acceptable. It would be great if we could somehow detect during import whether we are running inside IPython and then set up the plotting automatically.

Yes, it is also acceptable.

Let's go back to the beginning of this thread. If I understand correctly, the original motivation for this patch was this: > I've found that the svg rendering becomes a...

I don't think that closeness vitality will be added as a separate function to igraph. Simple solutions like the one proposed here or the one proposed in the r-igraph repository...