Skip to content

Conversation

jkyang92
Copy link
Contributor

@jkyang92 jkyang92 commented Sep 1, 2025

This is the pull request for the CellularResolutions package for JSAG. The changes are only the author emails since the package was already previously included in the Macualay2 distribution.

See also, these previous pull requests: #2833, #2844

I've created a draft pull request this time so it won't get merged by accident. See #3968

CC: @OlaSobieska

@antonleykin
Copy link
Contributor

Thanks, @jkyang92 (and @OlaSobieska) !
I'm pretty sure your package is in good shape, but let's see what comments we would collect in this PR --- this would be a good test case.

I will propose to have an M2Internals discussion of how to review a general JSAG-linked PR in various scenarios (new package, existing package, etc.) and possible outcomes (for the PR and for the JSAG submission).

@mahrud
Copy link
Member

mahrud commented Sep 2, 2025

but let's see what comments we would collect in this PR --- this would be a good test case.

As I mentioned here, GitHub doesn't allow comments on lines not changed in given PR, nor does it even show beyond a few lines surrounding the diff (e.g. I can see that this package has AuxiliaryFiles => true but only the main file is visible from this PR). Doesn't this make using GitHub PR review interface essentially pointless here?

An alternative is to also leave comments on the previously listed pull requests, but even then it's hard to leave a comment on v1 and check that is hasn't already been changed in v2, etc.

@antonleykin
Copy link
Contributor

Doesn't this make using GitHub PR review interface essentially pointless here?

No, there are still plenty of options for constructive feedback.

@mahrud
Copy link
Member

mahrud commented Sep 2, 2025

No, there are still plenty of options for constructive feedback.

Do you mean just commenting as if this was an issue? Could you give an example of giving feedback using the PR review interface here?

@antonleykin
Copy link
Contributor

No, there are still plenty of options for constructive feedback.

Do you mean just commenting as if this was an issue? Could you give an example of giving feedback using the PR review interface here?

Please (from now) comment only on the package associated to this PR here.
I've created a topic on Zulip (M2Internals Discussions) to collect comments on the general JSAG M2 PR process.

Request: make your comments short and to the point and moderate/neutral in tone.

@antonleykin
Copy link
Contributor

The code looks quite clean, but as we know every program can be made one line shorter. Perhaps this is the line:
https://github.com/jkyang92/M2/blob/cellres-jsag/M2%2FMacaulay2%2Fpackages%2FCellularResolutions.m2#L357

@antonleykin antonleykin self-requested a review September 8, 2025 14:40
Copy link
Contributor

@antonleykin antonleykin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Apart from #3969 (comment))
there is an easy-to-overlook thing: for each net definition there should be texMath definition --- otherwise M2Web and VSCode new interface would not display your new types nicely.
https://github.com/Macaulay2/M2/blob/b1c5e37bf0974f2adebe069ca85b8bd3e6acf13a/M2/Macaulay2/packages/CellularResolutions.m2#L583C1-L597C1
Also, consider documenting both net and texMath (perhaps in the same doc node).

Copy link
Contributor

@antonleykin antonleykin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are several lines commented out in "exports", e.g.,


Should they be removed?

Copy link
Contributor

@antonleykin antonleykin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is beneficial to use = instead of := for "private" functions, e.g.,
https://github.com/Macaulay2/M2/blob/b1c5e37bf0974f2adebe069ca85b8bd3e6acf13a/M2/Macaulay2/packages/CellularResolutions.m2#L69C1-L83C1
These (with =) would be exposed by debug Package.

Copy link
Contributor

@antonleykin antonleykin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if TypicalValue=>CellComplex is specified, consider adding the return type, e.g.,

cellComplex(Ring,List) := CellComplex => {} >> o -> (R,maxCells) -> (

in

cellComplex = method(Options=>true, TypicalValue=>CellComplex)
cellComplex(Ring,List) := {} >> o -> (R,maxCells) -> (
    (realMaxCells,allCells) := maxAndAllCells maxCells;
    mkCellComplex(R, allCells, realMaxCells)
    )

Copy link
Contributor

@antonleykin antonleykin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Several more suggestions:

(1) Consider dropping paretheses: all paretheses can be removed in,for instance,

dim(Cell) := (cell) -> cell.cellDimension

(2) There is a new syntactic sugar that can be used: lines like

zeroDimCells := if p#?true then p#true else {};

can be replaced by

zeroDimCells := p#true ?? {};

(3) This line in isWellDefined, for instance,

if not isSubmodule M then return false;

could be more verbose if debugLevel > 0, for instance,

if not isSubmodule M then (
  if debugLevel > 0 then << "not well defined: expected a submodule" << endl;
  return false;
  )

Copy link
Contributor

@antonleykin antonleykin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last comment for now is that you may want a short example appear on the main doc page for the package.

(By the way, some of the remarks so far are produced reviewing-in-pairs with @mikestillman )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants