fix: revdepcheck results

[krlmlr]

for 6222e73.

This PR contains the results from checking all reverse dependencies against 6222e73. This is the commit where all indexes in the internal list have been shifted. It seems like our code (or perhaps even other packages) are relying on those indexes. We need to understand what causes the failures, and fix them.

[krlmlr]

@Antonov548: See https://github.com/igraph/rigraph/blob/f-igraph-t-idx-revdepcheck/revdep/problems.md for details on the errors. This file shows the result from running rcmdcheck::rcmdcheck() for downstream packages with igraph 6222e73, compared against the released version of igraph.

[krlmlr]

This branch is based on 6222e73, please don't merge the main branch into this branch for now.

[szhorvat]

Some of these failures may be occurring because the tests of some packages load existing igraph data, which does not follow the changed storage order that's being tested here.

---

It seems to me that dealing with this may not be simple. The format version could be bumped, and upgrade_graph() could be adapted. That's not little work. Is it worth it at all?

[Antonov548]

It seems to me that dealing with this may not be simple.

I checked approximately 7 cases from the list and seems it's something related to loading old graph, since this logic is covered with the tests in igraph and sucsesuflly passed.
Should I really go trough all of them? What do you think? Because in some cases it's really not simple.

@ntamas

[ntamas]

As @szhorvat said, most of these failures are probably caused by the tests trying to load an old graph from a saved Rdata file. In these files, the components of the list representing the graph are in different order than the shuffled order in our new codebase and there's no migration code in place that would rearrange them in the right order.

OTOH it's really hard to distinguish genuine failures in the revdepcheck output from failures caused by the lack of migration code, so if we really want to make use of the revdepcheck result, we should probably come up with the code necessary to convert old saved data in test cases to the new order of items in the list.

[krlmlr]

I started a new round of checks with #799, will push here.

[krlmlr]

@Antonov548: The problems at https://github.com/igraph/rigraph/blob/f-igraph-t-idx-revdepcheck/revdep/problems.md look serious, I didn't expect those. Can you please take a look?

[Antonov548]

Can you please take a look?

Thanks. I will take a look.

[Antonov548]

I checked packages. Seems the really problem related to changes of graph structure are in the leidenbase package. Other seems not related to this change. Also some examples could be outdated.

• causaloptim : load invalid graph
• clustAnalytics: needs an update of igraphdata
• leidenbase : has copy of R_SEXP_to_igraph
• leidenAlg : use leidenbase
• nda : use leidenAlg
• SNscan : expected error to update graph

---

• drake : ?
• netseg : ? (could be something related to structure)
• shazam : ?
• migraph : related to changes of algorithms in igraph?
• metanetwork : related to changes of algorithms in igraph?

[szhorvat]

• migraph : related to changes of algorithms in igraph?

• metanetwork : related to changes of algorithms in igraph?

But this PR doesn't change the igraph version, does it? It merely changes the internal layout of the igraph objects. So there are no changes in algorithms.

[Antonov548]

But this PR doesn't change the igraph version, does it? It merely changes the internal layout of the igraph objects. So there are no changes in algorithms.

I was just wondering if they really didn't update the version of the rigraph relative to the one used in the package we're testing.

Then I will try to check why the values are slightly different in the tests.

[szhorvat]

• leidenAlg : use leidenbase

Did you mean to say that leidenAlg uses leidenbase? That is not so, but leidenAlg does have a partial copy of the igraph code, and it does access the graph object internals as well, so the failure is expected.

[Antonov548]

• leidenAlg : use leidenbase

Did you mean to say that leidenAlg uses leidenbase? That is not so, but leidenAlg does have a partial copy of the igraph code, and it does access the graph object internals as well, so the failure is expected.

Ah, sorry. It's typo. Originally it was that both have igraph code.

[krlmlr]

Running another set of checks with #805. Expecting much fewer failures.

[krlmlr]

Sent an e-mail to the SNscan maintainers, they need to fix that.

[krlmlr]

I'll take a look at gemtc and netseg, the leiden* packages are the only ones remaining.

[krlmlr]

netseg reprex:

netseg::ssi(netseg::EF3, "race")
#> Error in igraph::induced.subgraph(g, which(ids == b)): At core/core/vector.pmt:1030 : Assertion failed: v->stor_begin != NULL. This is an unexpected igraph error; please report this as a bug, along with the steps to reproduce it.
#> Please restart your R session to avoid crashes or other surprising behavior.

^{Created on 2023-05-21 with reprex v2.0.2}

[krlmlr]

netseg gives me headaches. Need to sleep over it.

options(conflicts.policy = list(warn = FALSE))
library(netseg)
ssi(EF3, "race")
#> Error in igraph::induced.subgraph(g, which(ids == b)): At core/core/vector.pmt:1030 : Assertion failed: v->stor_begin != NULL. This is an unexpected igraph error; please report this as a bug, along with the steps to reproduce it.
#> Please restart your R session to avoid crashes or other surprising behavior.

^{Created on 2023-05-21 with reprex v2.0.2}

Even with upgrade_graph() :

options(conflicts.policy = list(warn = FALSE))
library(netseg)

g <- igraph::upgrade_graph(EF3)
ssi(g, "race")
#> Error in igraph::induced.subgraph(g, which(ids == b)): At core/core/vector.pmt:1030 : Assertion failed: v->stor_begin != NULL. This is an unexpected igraph error; please report this as a bug, along with the steps to reproduce it.
#> Please restart your R session to avoid crashes or other surprising behavior.

^{Created on 2023-05-21 with reprex v2.0.2}

[krlmlr]

Can't test gemtc on macOS, will go to Ubuntu for that.

[szhorvat]

Is the netseg error happening only with the reshuffled igraph data structure, or also with 1.4.2 / 1.4.3?

[krlmlr]

All the failures we're seeing here are regressions compared to igraph 1.4.2.

[szhorvat]

@krlmlr Do I understand it correctly that these revdepchecks are done with the reshuffled version of the igraph data structure? Or is it just the dev version of igraph?

I see that you already opened an issue for netseg. But this is a fatal error, which should be impossible to trigger from R/igraph. In other words, if it happens, it's always our fault.

[krlmlr]

This is with an igraph object loaded from storage, and performing some operations on it. Could be off-label use too, I just don't know. We'll see.

[szhorvat]

off-label use

What does this mean?

[krlmlr]

Usage patterns that we don't fully support. Just because something works in 1.4.2 doesn't mean it's necessarily part of the API.

Not suggesting this is the case, but could be.

[krlmlr]

Started another full round of revdepchecks.