Javier Sagredo [Thu, 7 May 2026 00:04:51 +0000 (02:04 +0200)]
Render external type families as grey diamonds in the classes view
External-ref stubs in the classes view all defaulted to kind:
"class", so external families like SigDSIGN / HeaderHash / SignKeyKES
showed as grey rounded-rectangles instead of the grey diamonds the
external-family styling expects. We DO know which refs are families
when they came from a FamilyApp use site (collectFamilyAppsInArgs)
or an associated-type list (ciAssocTypes); collect those qids and
tag their external nodes with kind: "family". Bare superclass refs
still default to "class" — same case as before for Show / Typeable /
NoThunks shaped externals.
Javier Sagredo [Thu, 7 May 2026 00:03:36 +0000 (02:03 +0200)]
Document data-fam-instance skip in reduceTypeArg
Append a bullet to the resolution-determinism section explaining
why reduceTypeArg skips fiIsData entries: the data-family R: rewrite
makes their fiRhs structurally equal to the input FamilyApp, so
naïve recursion looped forever. Also clarify the prior
UndecidableInstances bullet — the reducer DOES recurse, it relies
on structural progress in the RHS to terminate.
Javier Sagredo [Thu, 7 May 2026 00:01:33 +0000 (02:01 +0200)]
Skip data fam-instances in reduceTypeArg to avoid infinite recursion
The data-family R: rewrite makes a data fam-instance's fiRhs
structurally equal to its FamilyApp LHS (e.g. for `data instance
Crate Int`, fiRhs is `FamilyApp Crate [Int]`). reduceTypeArg used
to unify the use site against fiArgs and recurse on
applySubst(fiRhs, subst) — which produced the same FamilyApp shape
again and looped forever for any constraint mentioning a data
fam-instance.
Skip data fam-instances in reduceTypeArg entirely. Their RHS is
opaque (the synthetic R: TyCon pre-rewrite, the circular FamilyApp
post-rewrite); reducing through them never makes progress, only
ever loops. The use-site FamilyApp falls through unchanged, which
addFamilyLinksFromArgs / the predicate-node + chain machinery then
handle as the data-family use site they actually are.
Javier Sagredo [Thu, 7 May 2026 00:00:23 +0000 (02:00 +0200)]
Re-enable node grabbing in cytoscape
Reverts the autoungrabify: true addition. Grabbing is useful for
manually rearranging nodes after a dagre layout that crowds parts
of the graph together; the previous commit ('Let drill-in work on
external classes...') is the real fix for the double-click-doing-
nothing bug, so disabling grab was unnecessary.
Javier Sagredo [Wed, 6 May 2026 23:59:19 +0000 (01:59 +0200)]
Let drill-in work on external classes that have local instances
drillInto used to gate on classById.has(n.id()) and silently fall
through to highlightOnly when the double-clicked class wasn't
locally defined. That's the wrong call when the class is external
but instances of it *are* in our dumps (orphan-style, or because
the package defining the instances was extracted while the package
defining the class wasn't) — there's still a useful instance view
to render.
Two changes:
* drillInto now drills in whenever the class is locally defined OR
has at least one entry in instancesByClass. When neither is true
(truly nothing to show), it console.warns with the qid so you can
diagnose why your double-click did nothing.
* buildInstanceView synthesises a minimal ClassInfo from the first
matching instance's iiClass when classById misses, so the rest of
the build pipeline (which needs ciSuperclasses, ciAssocTypes,
ciTyVars …) keeps working with empty defaults. The focused-class
node ends up as an external-styled stub but the per-instance
rendering — contexts, superclass requirements, fam-instances — is
all there.
Javier Sagredo [Wed, 6 May 2026 23:53:17 +0000 (01:53 +0200)]
Disable cytoscape node grabbing so taps fire reliably
By default cytoscape lets the user drag nodes around. The drag
detector kicks in if the pointer moves more than a few pixels
between mousedown and mouseup, and when that happens cytoscape
suppresses the corresponding 'tap' event — which is what our
hand-rolled double-click handler listens to. So a slightly-jittery
double-click on a class node looked like the node was being dragged
without ever drilling into the instance view.
Set autoungrabify: true at init. Dagre re-runs the layout every time
loadGraph is invoked, so user repositioning of individual nodes was
already throwaway — disabling grabbing is a clean improvement on
both axes.
Javier Sagredo [Wed, 6 May 2026 23:38:11 +0000 (01:38 +0200)]
Fix data-family R: rewrite to substitute rep tyvars with use-site args
The previous rewrite (commit 723a7c3) called tyConFamInst_maybe and
fed parentArgs straight into typeArg. parentArgs reference the rep
TyCon's *internal* type variables, not the use-site args; without a
substitution they leak through typeArg's TyVar lookup as
@OtherArg "<reptv>"@ because they're absent from boundTvs. So
@R:CrateList Int@ was rewriting to @Crate [<reptv>]@ — which broke
both the rendering (the user saw rep-internal names) and the chain
resolution (replaceFamilyApp's biUnify still succeeded by luck of
the wildcard rule, but the visible label was wrong).
Build a Subst from the rep's tyConTyVars to the actual use-site args
and apply it to parentArgs before recursing. With this fix
@R:CrateList Int@ extracts as @FamilyApp Crate [TyConApp List
[TyConApp Int []]]@ and renders as @Crate [Int]@; the polymorphic
case @R:CrateList a@ in an instance head extracts as
@FamilyApp Crate [TyConApp List [TyVarRef 0]]@ and renders as
@Crate [a]@.
Demo gains a @CrateBound (Crate [a])@ instance so the polymorphic-rep
path is regression-covered.
Javier Sagredo [Wed, 6 May 2026 23:21:02 +0000 (01:21 +0200)]
Render a side panel for external type families
Clicking a family node not present in pdTypeFamilies (e.g. SigDSIGN
from a foreign crypto package) used to render nothing — showSelection
silently fell off the renderFamilyPanel branch. Add
renderExternalFamilyPanel that uses the QualName's package + module
to give a useful description, mirroring the external-class panel
treatment.
Javier Sagredo [Wed, 6 May 2026 23:19:42 +0000 (01:19 +0200)]
Rewrite data-family R: TyCons to abstract family applications
GHC represents `data instance Foo Args = …` internally as a
synthetic TyCon `R:FooArgs`. When such a TyCon shows up inside a
constraint or instance head — `NoThunks (R:ConsensusConfigPraos c)`
— the user reads it as the abstract family application
`NoThunks (ConsensusConfig (Praos c))`. Until now we faithfully
reported the rep TyCon, which surfaced the synthetic name.
In typeArg, gate on tyConFamInst_maybe before the regular TyConApp
path: when the TyCon is a data-family instance representation,
emit `FamilyApp parent parentArgs` instead. The viewer's existing
chain logic then naturally connects the @data instance@ row to any
class instance that mentions the abstract family.
Javier Sagredo [Wed, 6 May 2026 23:18:12 +0000 (01:18 +0200)]
Mention package + module in external-class panel description
The "External (not defined in this program)" status line was
informationless — the QualName already carried the package and
module the class came from. Surface them in the description with a
hint that the user can extend their plugin run to capture the class
locally if that data would be useful.
Javier Sagredo [Wed, 6 May 2026 23:17:42 +0000 (01:17 +0200)]
Center the search box in the topbar
Search-wrap was pinned to the right edge with margin-left: auto.
With Focus chips and Mark-orphans gone from the topbar (previous
commit) it had room to breathe — switch to margin: 0 auto so the
flex's auto margins absorb leftover space symmetrically and the
search lands in the middle.
Javier Sagredo [Wed, 6 May 2026 23:16:52 +0000 (01:16 +0200)]
Move Focus chips and Mark-orphans toggle to the side panel
The topbar got cramped between the title, focus chips, orphan
toggle, and the search input. Moves these two pieces — the focus
chips block and the orphan-marker checkbox — into the side panel,
restyled as panel blocks with consistent borders. The topbar keeps
just back, title, and search.
Javier Sagredo [Wed, 6 May 2026 23:15:54 +0000 (01:15 +0200)]
Show tyvars on class node labels
Class nodes now read "BftCrypto c" / "Bar a b" instead of just the
class name, in both the classes view (Render.hs's classNodes) and
the instance-view ensureClassNode helpers. External classes — for
which we don't know the tyvars — still fall back to the bare name.
Edge labels (the positional substitution into a superclass's args)
keep using the *origin* class's tyvar names via edgeLabel, so an
arrow `Bar a b ──(b)──► Foo b` reads consistently — same letter on
edge and target node.
Javier Sagredo [Wed, 6 May 2026 23:14:34 +0000 (01:14 +0200)]
Document the synthetic Family args = ? placeholder
New section covering when the placeholder fires (broader than just
"family is external" — anywhere unification fails), the conditional
chain edge to the originating predicate, the per-(family, args)
dedup key, the implementation as a fake FamInstInfo with
_unresolved/unresolved flags, and the matching grey-dashed styling
shared with external family diamonds.
Javier Sagredo [Wed, 6 May 2026 22:53:50 +0000 (00:53 +0200)]
Mark external families and synthesise unresolved-fam-instance nodes
External families (referenced via FamilyApp but absent from
pdTypeFamilies) now render as grey dashed diamonds, matching the
external-class styling.
When a context predicate or unmatched superclass mentions a
FamilyApp that no real fam-instance can resolve — typically because
the family is external — synthesise a placeholder fam-instance node
"Family args = ?" for each distinct use site. The chain then reads:
(the dashed leg is the fam-resolves edge to the originating predicate
node). Side panel for these placeholders explains they're use sites,
not equations. Help legend grows two new rows: external family +
unresolved fam-instance.
addFamilyLinksFromArgs gained two parameters (boundTvs, originPredId)
to render the placeholder labels in the right tyvar context and to
chain placeholders back to the predicate that needed them. The
superclass call site reorders so the unmatched-pred node id is
available before the call.
Javier Sagredo [Wed, 6 May 2026 22:49:42 +0000 (00:49 +0200)]
Show class→assoc-family links in the instance view
Until now the assoc-family edges only appeared in the classes view;
the instance view of, say, BftCrypto would show its families
(BftDSIGN, BftHash, …) only as descendants of the *individual*
fam-instances surfaced for each instance. Add an `assoc` arrow
straight from the focused class node to each entry of
`ciAssocTypes`, so the user can see what families the class
declares without having to find an instance that exercises them.
Javier Sagredo [Wed, 6 May 2026 22:36:11 +0000 (00:36 +0200)]
Document predicate-node dedup caveats in INTERNALS.md
New section between the resolution-chain determinism notes and the
"viewer is not doing" wrap-up, covering the structural-hash dedup,
the context-vs-superclass reduction asymmetry, tyvar-index aliasing
across instances, the role-sticky-to-context behaviour, and the
fact that predicate nodes are view-scoped (not persisted).
Javier Sagredo [Wed, 6 May 2026 22:33:10 +0000 (00:33 +0200)]
Unify unmatched superclass with context predicate node
Was: unmatched superclass → class node, edge "needs Foo a b (no
local match)".
Now: unmatched superclass → predicate node (the same one created
from a context constraint when the predicate happens to match,
otherwise a fresh role='extern' grey node), edge labelled
"superclass constraint".
This collapses the case where a constraint appears in *both* the
context and as an unmatched superclass — the user sees one node
with two edges ("instance context" + "superclass constraint")
instead of two disconnected nodes saying the same thing. When the
constraint is purely an external superclass, the grey 'extern'
predicate node makes "must exist somewhere outside this project"
visible at a glance.
Javier Sagredo [Wed, 6 May 2026 22:31:10 +0000 (00:31 +0200)]
Render instance context constraints as predicate nodes
Was: instance → class node, edge labelled "ctx: <args>".
Now: instance → predicate node ("Foo a b" rendered like a constraint),
edge labelled "instance context".
The new node kind 'predicate' deduplicates on a structural id
(class qid + JSON-stringified args), so the same constraint surfaces
once even when it appears in multiple superclass / context slots —
the next commit relies on this to merge unmatched-superclass
requirements with overlapping context predicates.
Side panel grows a renderPredicatePanel that explains the node's role
and links to the underlying class.
Javier Sagredo [Wed, 6 May 2026 22:27:58 +0000 (00:27 +0200)]
Shorten "superclass needed Foo a b" edge label to "superclass constraint"
The class + arg shape is already on the target node (matched instance,
or — after the next commit — a predicate node), so spelling it out on
the edge label was redundant. Plain "superclass constraint" describes
the relationship the edge depicts and lets the eye stay on the nodes.
Javier Sagredo [Wed, 6 May 2026 22:27:28 +0000 (00:27 +0200)]
Don't draw the predicate-class node alongside fam-resolves matches
The "fam-resolves" chain pulled the predicate class into the instance
view as a separate node and connected it to the matched instance with
a green "defines" edge — duplicating information already on the
matched-instance label. Drop the class anchor + defines edge here, the
same way commit 3a8e0ac handled the matched-superclass case.
Javier Sagredo [Wed, 6 May 2026 22:14:26 +0000 (00:14 +0200)]
Drop the instance → fam-instance "= (Rhs)" edge
The dotted-purple edge from a focused instance to its associated
fam-instance carried only the RHS label, which the fam-instance
node's own label already shows in full. Removing it cleans up the
instance view; the fam-instance still surfaces because the family
node points at it via fam-defines, which is enough to indicate the
context relevance.
Also drop the now-dead cytoscape style rule and the legend row.
Javier Sagredo [Wed, 6 May 2026 22:13:09 +0000 (00:13 +0200)]
Drop the "satisfies Foo" label on fam-resolves chain edges
The teal-dotted edge between a fam-instance and the matched class
instance already speaks for itself — its endpoints (and the side
panel on click) carry the same information the inline label was
trying to add. The label was just visual noise.
Javier Sagredo [Wed, 6 May 2026 22:12:43 +0000 (00:12 +0200)]
Remove the "via Bar" instance → family edge
The dashed light-purple arrow connecting an instance to a referenced
type family was visually opaque — readers couldn't tell what
relationship it depicted. Drop it from addFamilyLinksFromArgs along
with its cytoscape style rule and the help-legend row.
The fam-instance nodes the function surfaces and the fam-resolves
chain edges remain — those are the meaningful continuations from the
matched-superclass-instance node.
Javier Sagredo [Wed, 6 May 2026 22:11:33 +0000 (00:11 +0200)]
Don't draw the superclass class node when an instance matches locally
Previously every "superclass needed" arrow pulled in both the matched
instance node *and* a class node for the superclass — joined to the
matched instance by an extra "defines" edge. The class node duplicated
information already on the matched-instance label, just adding clutter.
Restrict the class-node side to the no-local-match branch, which still
needs somewhere for its needs-external edge to terminate.
Javier Sagredo [Wed, 6 May 2026 22:10:50 +0000 (00:10 +0200)]
Relabel "needs Foo" superclass edges to "superclass needed Foo"
The plain "needs Foo …" edge label in the instance view glossed
which kind of constraint we were displaying (context vs. superclass
vs. ambient). Make it explicit: this edge represents a *superclass*
requirement.
Javier Sagredo [Wed, 6 May 2026 22:10:09 +0000 (00:10 +0200)]
Add docs/INTERNALS.md (with neutral examples)
The internals walkthrough was sitting uncommitted from an earlier
session. Adding it now, with the Cardano-flavoured examples
(Ticked / Shelley / Byron / TxOut/LedgerState) swapped for neutral
Wrap / Foo Int / Element shapes — the doc explains classgraph
internals, not any particular downstream project's vocabulary.
Javier Sagredo [Wed, 6 May 2026 22:09:17 +0000 (00:09 +0200)]
Document setup for the two Emacs editor-link schemes
Step-by-step org-protocol setup (init.el snippet + xdg-mime desktop
entry + macOS pointer) plus a DIY emacs:// scheme path with a sample
emacsclient wrapper script. Both end with the "pick from dropdown"
step so the user can see the loop close.
Javier Sagredo [Wed, 6 May 2026 22:08:40 +0000 (00:08 +0200)]
Add two Emacs editor-link schemes
emacs://: a freeform URL the user maps to emacsclient via xdg-mime.
emacs-org://: the canonical org-protocol://open-source URL handler
that ships with Emacs once (require 'org-protocol) is loaded.
Javier Sagredo [Wed, 6 May 2026 22:07:56 +0000 (00:07 +0200)]
Don't recolor the focused type-family node
The [?focused] cytoscape rule used to paint every focused node dark
blue, which on the amber family node left dark-on-dark text that
couldn't be read. Split the rule: class nodes still go navy; family
nodes keep their amber palette and indicate focus via a thicker brown
border and larger text.
Javier Sagredo [Wed, 6 May 2026 22:07:21 +0000 (00:07 +0200)]
Rename Pin to Focus in the side-panel UI
Side-panel button is now "🎯 Focus" / "🎯 Unfocus" (was "📌 Pin" /
"📌 Unpin"). Hint text, help legend, counts line, and README all
updated. Internal identifiers (focusSet, pinClass, the panel-btn.pin
CSS class, data-action="toggle-pin") stay as-is — they're invisible
to users and changing them invites bigger churn.
Javier Sagredo [Wed, 6 May 2026 22:06:25 +0000 (00:06 +0200)]
Render type-level lists as [a, b, c] not (: a (: b []))
renderArg now special-cases GHC's promoted cons (`:`) / nil (`[]`)
TyCons and the unapplied list TyCon, unfolding nested cons chains
into Haskell list syntax. Demo gets a Bagful + BagList exhibit so
the path is exercised.
Javier Sagredo [Wed, 6 May 2026 22:05:20 +0000 (00:05 +0200)]
Infer per-package source roots from classgraph-view --input
Add a --source-root PKG=PATH override and infer a default per-package
root from each --input dir's parent. Schema gains iiDefinedIn /
fiDefinedIn (filled in at merge time from the dump's mdPackage), so
orphan instances resolve under the *defining* package, not the
class's. Render embeds the resulting map; viewer's editor links look
up the per-package root before falling back to the localStorage
override.
projects / classgraph.git / log