[BUG] Registering FSI Printer has no effect #130

Activity

1. kMutagene

   added

   bug

   on May 6, 2021
2. github-actions commented on Apr 3, 2026

   

   github-actionsBot

   on Apr 3, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

   Note

   The pull request was not created — a fallback review issue was created instead due to protected file changes: #366

   🤖 This is an automated response from Repo Assist.

   I investigated this issue. The FSIPrinters.matrix function is defined in FSIPrinters.fs and looks correct — it takes a Matrix<_> and returns a formatted string. However, fsi.AddPrinter can fail silently when the type being matched comes from a transitive dependency (FsMath.Matrix<float> in this case) rather than being directly defined in the loaded assembly.

   Root cause hypothesis: Matrix<float> in FSharp.Stats is provided by the FsMath package. fsi.AddPrinter uses .NET runtime type matching, and there can be edge cases where type identity checks fail when aliases or re-exported types are involved, especially across assembly boundaries.

   Workarounds:

   1. Call the formatter directly: printfn "%s" (FSIPrinters.matrix myMatrix)
   2. For .NET Interactive / Jupyter notebooks, the modern solution is the separate FSharp.Stats.Interactive NuGet package, which registers HTML formatters via IMatrixFormattable.

   Potential fix: Register the printer using the concrete float type explicitly, or ensure FSharp.Stats exposes a proper [<AutoOpen>] module that calls fsi.AddPrinter on load when running in FSI context (similar to how some libraries use #if INTERACTIVE blocks).

   Is this issue still reproducible with the current version? If so, a focused fix in FSIPrinters.fs or a one-liner #load script for users would be straightforward.

   Generated by 🌈 Repo Assist, see workflow run. Learn more.

   To install this agentic workflow, run

   gh aw add githubnext/agentics/workflows/repo-assist.md@4ea8c81959909f40373e2a5c2b7fdb54ea19e0a5