Gmres by inducer · Pull Request #360 · inducer/arraycontext

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

inducer · 2026-06-04T15:49:48Z

Since I want access to a solve in grudge, I figured moving GMRES from pytential would be the easiest. Once this is merged, I'll remove the one in pytential (with deprecation blah). This one isn't totally compatible, fwiw: The pytential one had some actx autodiscovery "stuff" that I'll probably have to re-add.

This also brings sumpy's build_matrix here.

alexfikl

Left a few comments, but overall this looks like a good place for it to me.

alexfikl · 2026-06-04T16:43:40Z

+class InnerProduct(Protocol, Generic[T]):
+ """A :class:`~typing.Protocol` for the inner product used by :func:`gmres`."""
+
+ def __call__(self, a: T, b: T) -> T: ...


Suggested change
def__call__(self, a: T, b: T) ->T: ...
def__call__(self, a: T, b: T) ->float: ...
?

Not really: GPU array contexts return reduction results as device scalars, i.e. arrays. And numpy is forgiving enough that it sort-of fits.

Then this doesn't match what structured_vdot is doing? That does a to_numpy and takes the item inside. Also things like residual_norms: Sequence[float] would need to be updated to hold device scalars?

alexfikl · 2026-06-04T16:47:24Z

+ if (isinstance(x, Number)
+ or (isinstance(x, np.ndarray) and x.dtype.char != "O")):
+ return np.vdot(x, y)


Seeing as we have a NumpyArrayContext now, does this make sense (the isinstance(x, ndarray) part)? Not quite sure where this was used in pytential either..

It does make sense to me. 😁 This gets used on object arrays that look like [DOFArray, scalar], e.g. when there are scalar degrees of freedom floating around somewhere.

What I wasn't sure about here is.. if we're using e.g. a PyOpenCLArrayContext, how would a non-object numpy array sneak in here that we need to guard against it?

alexfikl · 2026-06-04T19:17:54Z

+ if show_spectrum:
+ ev = la.eigvals(mat)
+ import matplotlib.pyplot as pt
+ pt.plot(ev.real, ev.imag, "o")
+ pt.show()


I would remove this?

Don't know. It's not meant for serious use because of the inherent inefficiency, so it doesn't matter? And six times out of ten, the reason I'm reaching for this is because the iterative solve died because of some issue in the spectrum. Compromise: _show_spectrum?

Hm, fair enough, if it's meant more for debugging, it's fine as is. Maybe these deserve a comment or docstring warning me about what I'm getting into? 😁

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

Convert "references" to sphinx redirects
914f060

inducer force-pushed the gmres branch 2 times, most recently from 1afaaaa to ca1a922Compare June 4, 2026 16:44

inducer added 2 commits June 4, 2026 12:02

Bring over gmres from pytential, build_matrix from sumpy
a904220

Update baseline
f36cdbf

inducer force-pushed the gmres branch from ca1a922 to f36cdbfCompare June 4, 2026 17:02

inducer requested a review from alexfikl June 4, 2026 17:22

alexfikl reviewed Jun 4, 2026
View reviewed changes

inducer mentioned this pull request Jun 23, 2026
Track gmres move to arraycontext inducer/pytential#324
Draft

	def__call__(self, a: T, b: T) ->T: ...
	def__call__(self, a: T, b: T) ->float: ...

Conversation

inducer commented Jun 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexfikl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexfiklJun 5, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexfiklJun 5, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

inducer commented Jun 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexfikl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexfiklJun 5, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexfiklJun 5, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

inducer commented Jun 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

inducer commented Jun 4, 2026•
edited
Loading

alexfiklJun 5, 2026•
edited
Loading

alexfiklJun 5, 2026•
edited
Loading

inducer commented Jun 4, 2026•
edited
Loading

alexfiklJun 5, 2026•
edited
Loading

alexfiklJun 5, 2026•
edited
Loading

inducer commented Jun 4, 2026•
edited
Loading

alexfiklJun 5, 2026•
edited
Loading

alexfiklJun 5, 2026•
edited
Loading