[d-torrance]

mgb help gb offers four S-pair priority queues:

 -spairQueue INTEGER   (default is 0)
   The priority queue used to order S-pairs.
     0   tournament tree in front of triangle
     1   heap in front of triangle
     2   tournament tree
     3   heap

None of them has existed since 2013. This removes the option.

It does nothing

28fb618, "Removed PairTriangle as it is no longer used (it's replaced by the
mathic version)", deleted the code the option selected. mathic::PairQueue
replaced it, with its column queue fixed to a TourTree. The option stayed:
its value was still threaded through ClassicGBAlgParams, ClassicGBAlg,
SignatureGB and SigSPairs, and discarded at both ends, where 33d4394
later added (void)queueType; to keep the compiler quiet.

So every code gives byte-identical output, and mgb reports the same queue
whatever is asked for:

S-pair queue type:  PairQueue-t-tree (si)

An option that is accepted, advertised and ignored tells a user they chose
something when they did not.

Why not restore it instead

Only half of it could come back. The four codes were two bits: heap or
tournament tree, and whether S-pairs were staged behind a triangle. Staging
is how mathic::PairQueue works, so turning it off would mean a second
implementation. The heap-or-tree half needs a new mathic API, which mathicgb
could use only behind feature detection with a fallback, since it has to keep
building against older mathic -- and packaged mathic trails git by years, so
the option would reach almost nobody. That is a lot of machinery for a knob
nobody has been able to turn for twelve years, with no measurement suggesting
a heap ever wins.

Commits

1. dd03d5b -- removes the option, its help text, and every queueType
   parameter behind it. The test harness's all-pairs table loses its
   spairQueue column, and pict.in the matching parameter; the remaining
   columns still cover every pair.
2. e7241d9 -- pict.in said PICT was a closed-source Windows utility and
   linked a pict33.msi. It has been MIT-licensed on GitHub since 2015 and
   builds on Linux; the comment now says so. Both instructions also named the
   table's string allPairsTest rather than allPairsTests.

The table was edited rather than regenerated. PICT built from source and run
on the new pict.in gives 101 rows, the same number, so regenerating would
only have swapped every configuration for a different set of equal size.

Compatibility

-spairQueue is now an unknown option:

ERROR: No option has the prefix "spairQueue".

Nothing else changes. In Macaulay2 the only reference is the option table of
MGBInterface.m2, an undistributed package, which passes the flag only when a
caller sets "SPairQueue" explicitly.

Verification

• 254/254 in cmake Release and Debug, GCC 13.3, no build warnings.
• mgb gb -outputResult and mgb sig -outputResult give byte-identical bases
  before and after on cyclic5 and hilbertkunz1.
• No reference to spairQueue, sPairQueueType or queueType remains in the
  tree.

No autotools distcheck run locally; neither commit touches a build system and
CI covers it.

🤖 Generated with Claude Code