Bug: nodes are missing in dagzet

For example nodes like "cpp" and "magsign_cpp" are missing.

It's not being added to the data.

jq .nodes[] | .name data/codestudy/potential/index.json | grep magsign_cpp

These are the missing files

How is this being created?

Not the problem I wanted to troubleshoot, but hey I need this for the visibility.

The debug mode flag is never set to true here. Confirmed with printing and filtering output.

Also confirmed that it doesn't matter if you're using the function dbg I made or checking the variable itself. It's the same. So, I'm pretty sure the dbg shortcut function is fine.

I need to be able to track down when this is being set, and then unset.

I think what's happening is the variable is being copied over when it is loaded up in the module. Hoping to fix this by using a big global that can be read everywhere.

This is NOT what I'm debugging. I just need visibility.

I have a clumsier approach now, but it works, and I've wasted too much time chasing this pre-bug to improve it.

Confirmed that the nodes do come up, but they aren't being traversed for whatever reason.

should be 33, but I'm getting 20.

I tried looking for something to make sense in the code, but I can't yet see a pattern for what is there and what isn't there.

Clocking out for now

Using magsign_cpp as an example, which currently has the id of 146.

It doesn't seem to be showing up.

Connections look right.

This comes next after populating connections. I have a feeling that calling table.remove and table.insert aren't doing the things I expected.

Checking these nodes.

I mean, I guess it looks right?

"cpp" would have to be added to the "no incoming" table. Which, I would expect wouldn't be happening.

The nodes_connected_to function: which way is the direction? if "nodes connected to A" returns B, is it "B->A" or "A->B"?

It's checking if the node is on the left, so "A->B", so the parent nodes.

If this is true, header_file_looks_like_boilerplate (id 137) should return the cpp node (id 134). Let's test this.

It's not showing up. Nevermind that was my fault.

Okay the cpp node is indeed showing up as expected.

This is insightful: the cpp node shows up 2/3 times. The missing node here is magsign_cpp. So, cpp might be forever missing if magsign_cpp is missing. That's enough for today.

Actually not too much of an issue, I have enough printing happening now that I can update when/if needed.

The magsign_cpp is what we are investigating. What would need to happen for it to not show up in cpp?

Not sure if that is helpful or not.

Of the three, It's also the only one that only shows up once as a left-node (it only has one parent node). That parent is magsign_cpp.

As we go down this tree, we are approaching the only two external nodes here: rust/std and rust/std_iter_zip. The TOC generates the links just fine, but it just seems like anything that has those links doesn't want to show up.

What's up with that?

Removing those external nodes causes it to render properly.

I don't think the edges are supposed to be nil, even though they are here.

I have another hunch: there is a local node called "rust", and the namespace for these external nodes also starts with "rust". Going to re-introduce the external nodes, and change the local "rust" node to be "rustrust". It could be that there is some faulty logic related to string matching somewhere.

Neither worked. Okay, so I have to check out those nil edges now.

While populating a local copy of the edges table (to be pruned later by the topsort algo), I added a check to see if the left node id shows up in the nodes list. If it doesn't, it indicates that it is an externally linked node outside of the namespace.

TL;DR: Check for foreign nodes.