Failure to match and `seg[@subtype="sbSeg"]`

[samosafuz]

I noticed something odd today during more tests. I ran the command dotnet run -s 2020 -d 2020 -bps 300 -bpe 301, but the first of the two files pulled by the compiler failed to find its twin in PN Biblio (i.e., 70023). See screenshot, below. Something appears to be off: can you debug?

The other thing I noticed during the same run was that the output file 2001-0300.xml created by the compiler had seg[@subtype="SBandSeg"], when PN uses seg[@subtype="sbSeg"]. Please ensure that we are outputting (and comparing) the latter form.

[halosm1th]

I've updated the program to fix the sbandSeg problem so that now it outputs the sbSeg where it should, and have effectively scrubbed the former from the code base.

As for the lack of match, I'm unsure. I ran the program against my copy of the data pulled from your git repo, and it worked.

I would recommend pulling the latest version that has a few different bug fixes and seeing if it works, it might have been some small internal tweak that fixed it before I even really got to looking at it.

[samosafuz]

A new run on my home machine confirmed that this is a non-issue – thanks. I did notice, however, that the compiler is throwing the error found by encountering the non-XML .DS_Store files (see screenshot).

[halosm1th]

I think I patched the bug. What I suspect happened was a conflict between what I think is standard behaviour on mac vs windows, and the way I implemented the last change to save every time.

Essentially, when I updated the code to save after every instance, I didn't refine the code for creating the directories properly. I just recreated them every time the command was run. On windows the directory doesn't get recreated if it exists. But on Mac, I am guessing that when the create directory command is called, if the directory exists, it wipes it out, deleting whatever files are inside. So any previously updated XML entries would be wiped out on the final run when the directory is remade one last time.

Because I believe this is the bug, I've cleaned up the code by adding a proper check to see if the directory exists, and then only actually create then directory if it does not exist. I also fixed a bug with the numbering, not sure if it was the one causing them to be written as 0, but hopefully. It should now print what it found as the result, and then iterate on that, for the time being, until the new program is written and I assume this section is taken out of this one.

I've also patched a handful of other small bugs. Will be properly starting on the new program tomorrow.