File Changes for mspeir

v503_preview to v503_preview2 (2026-08-17 to 2026-08-24) v503

• src/hg/makeDb/scripts/singleCellSignalsPeaks/copySingleCellSignalsPeaksFiles.py
  • lines changed 29, context: html, text, full: html, text
    423ffa0448b4e60620b62e201aae813f069ba832 Fri Aug 21 07:59:07 2026 -0700
    singleCellSignalsPeaks: fix the copy script's abort order and --stanzas, refs #38142 Two code-review items from Jairo. The zero-subtracks check ran after the facet metadata had already been copied, so in the one case it guards against, the bed directory was left holding fresh metadata and no matching data files. It now aborts before the copy. --manifest and the metadata path were still keyed off HUB_BUILD, while the sibling makeSingleCellSignalsPeaksRa.py had already moved to deriving them from --stanzas. Pointing --stanzas at a second build therefore read the default build's manifest and copied the default build's metadata. Both now resolve from the stanza file's build root, so the two scripts treat the flag the same way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 49, context: html, text, full: html, text
    678310fdb6c3c8f61955476a5002c26ef4bff95a Fri Aug 21 13:01:39 2026 -0700
    singleCellSignalsPeaks: fail loudly on an unusable copy, and copy atomically, refs #38142 Three things found while reviewing this script after the code review. Resolving every subtrack and then finding not one of their source files used to print a MISSING list and exit 0, which is the same silent success the zero- subtracks check guards against, one step further in. It now aborts and names both the stanza file and the manifest, since the usual cause is the two coming from different builds. Missing facet metadata was skipped quietly, leaving the bed directory advertising the previous build's facets against this build's data files. makeSingleCellSignalsPeaksRa.py already treats that as fatal; so does this now. The bed directory is served live, through the /gbdb/<asm>/bbi/singleCellSignalsPeaks symlink, so copying in place handed out a truncated bigBed for as long as each copy took. Copies now go to a temp file beside the destination and get renamed into place. While here, the already-copied test compares mtime as well as size: a rebuilt file often lands on the same size, and skipping it then served the old data indefinitely. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
• src/hg/utils/otto/g2p/doG2p.py
  • lines changed 10, context: html, text, full: html, text
    fd12b362b0ccddedbc7055cc08f7fbe34b1bbdea Fri Aug 21 07:59:17 2026 -0700
    G2P otto: report the raw unrecognized confidence value, refs #38142 Code-review item from Jairo. The tally is keyed on the normalized value, so the log printed the folded form rather than the text that is actually in the CSV. Keep one raw example alongside each count and print that, so the value can be found in the source file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 18, context: html, text, full: html, text
    62fad287d92a5937f768173e48381544043e7b3e Fri Aug 21 13:03:58 2026 -0700
    G2P otto: stop csv.writer putting quotes into the track text, refs #38142 The BED was written with csv.writer, whose default dialect treats the double quote as its own quote character. Any field containing a quotation therefore came out wrapped in quotes with the inner quotes doubled, and nine G2P comments carry one, so that punctuation is in the released track today: "Note, a 7-residue ""hot spot"" within the so-called hinge domain ... Fields now go through bedField(), which keeps the text as G2P wrote it and only takes out the tab and newline that would break the row. The same change drops the CRLF line endings the excel dialect was emitting; bedToBigBed was already stripping those, so they did no harm, but the BED is a plain tab file now. Rebuilding hg38 from the same CSV changes exactly those nine records and nothing else: same 4,214 items, same 29 fields, coordinates untouched. /gbdb/{hg19,hg38}/g2p/g2p.bb still point at the previous build, so this needs a rebuild to reach the track. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 43, context: html, text, full: html, text
    cd98d642c99cbe1e5648734f7735452b69c01c23 Fri Aug 21 13:05:22 2026 -0700
    G2P otto: a lock, an atomic install, and separate stderr, refs #38142 Four hardening items from the same review, none of which change the track data. install() claimed to be atomic but did rm followed by ln, leaving a window in which /gbdb/<db>/g2p/g2p.bb did not exist. It now builds the symlink under a temp name and renames it over the live one. bash() folded stderr into stdout, and loadCoordinates parses that return value as bigBed rows, so a single warning from bigBedToBed would have arrived looking like data. The two streams are separate now, with stderr passed through to ours so the otto mail still shows it. Two runs would share a build directory and race on the move of AllG2P.csv over prevAllG2P.csv, which decides whether the next run thinks anything changed. A non-blocking flock means the second run says so and stops. The hgnc_id field is stripped, as the value used to join on it already was. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 8, context: html, text, full: html, text
    ca19bd51444a79e823160124e602ac92b9c6469e Fri Aug 21 13:41:12 2026 -0700
    G2P otto: keep a successful build quiet again, refs #38142 Separating stdout from stderr in cd98d642c99 also echoed stderr onward, and bedToBigBed narrates its progress there, so every build gained a dozen lines of "pass1 - making usageList" in the otto mail. stderr is now only reported when the command fails. The streams stay separate, so the parsing fix holds. No change to the track data. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
• src/hg/utils/otto/otto.crontab
  • lines changed 8, context: html, text, full: html, text
    92bee1b2bdd55e432b33a9061b11e09859601d4e Sat Aug 22 10:24:00 2026 -0700
    commenting out DE worker lines from otto crontab, since they're now running on hgcompute-08, not hgwdev. But leaving them in this crontab file so that the lines can be recovered in case the hgcompute-08 cron is ever lost, refs #24912