Added support for 'mill init' from existing Gradle project #4363

ajaychandran · 2025-01-17T18:09:10Z

Resolves #3962 by extending mill init with the ability to import a Gradle project.

handles deeply nested modules
configures dependencies for configurations:
- implementation / api
- compileOnly / compileOnlyApi
- runtimeOnly
- testImplementation
- testCompileOnly
configures testing frameworks
supports Gradle plugins
- java
- maven-publish

Additionally, Maven support added in #3756 was improved.

shared logic moved out to module buildgen
added support for BOM dependencies
eliminated creation of redundant test modules
fixed millSourcePath for test module

lihaoyi · 2025-01-18T02:36:28Z

Thanks for the PR @ajaychandran !

To help simplify the review, could you flesh out the PR description with a summary of the code changes and any things worth noting? That would help me understand the PR much more quickly and accurately vs reverse engineering the intent from the diff

Also, could you write an architecture summary of the entire buildgen pipeline and put it in a readme.md file in that folder:

What is the relationship between main.buildgen, main.maven, main.gradle, main.init?
How is the necessary data extracted from Maven and Gradle?
What part of the buildgen logic is shared, and what parts are unique to Maven and Gradle?
Where are the extension points? e.g. if someone wanted to hack in support for a new Maven/Gradle plugin, or new test framework, etc., what code would they need to change?

Now that it's getting more complex, such a summary would help understand this code going forward

main/buildgen/src/mill/main/buildgen/BuildGenUtil.scala

lihaoyi · 2025-01-18T02:43:51Z

main/buildgen/src/mill/main/buildgen/BuildGenUtil.scala

+  }
+
+  def compact(tree: BuildTree): BuildTree = {
+    println("compacting Mill build tree")


Maybe leave a code comment here explaining what "compacting" means and why we want to do it?

Yeah the logic here is kind of hard too read. I suggest either refactoring it to using a functional approach, or at least using Option.None instead of nulls.

I think what the does basically is to serve the merge flag in the config classes: when combining the builds of all modules into a single "build.mill", the imports, the companion objects, and the inners (which are the Module object contents) will be merged with their duplicate fields removed.

I do think refactoring this function to a functional programming approach will make it easier to read and maintain, aka getting rid of the vars and foreachs and using maps,flatMaps, distincts, toSets, etc. instead. See a related comment in Maven's BuildGen for an example.

lihaoyi · 2025-01-18T02:55:40Z

main/gradle/src/mill/main/gradle/JavaModel.java

@@ -0,0 +1,125 @@
+package mill.main.gradle;


Where did these model files come from? Were they copy-pasted from somethird-party code, or did you come up with them from scratch? If you came up with them, did you reference any documentation or code when writing them? We should leave a comment so people can see where these model files came from

All the models were written from scratch.

Gradle requires every model to be a Serializable interface (or a runtime error is thrown).

The relevant plugins/settings were identified by searching the Gradle source repository.

Tooling API usage was adapted from an old demo project.

Latest Gradle API was obtained after posting on the forum.

I have added some docs and links but there isn't much information on the internals of the Gradle API.

@ShreckYe Did you find any documentation that could be useful here?

I guess linking to the Javadocs of gradle.api.Project, org.gradle.api.artifacts.Configuration, org.gradle.api.artifacts.Dependency, etc. should be enough. I can't find other types of tutorials or more elaborate documentation either.

lihaoyi · 2025-01-18T03:11:57Z

main/buildgen/src/mill/main/buildgen/ir.scala

+ * @param module build module
+ */
+@mill.api.experimental
+case class Node[Module](dirs: Seq[String], module: Module)


Would I be correct to say that we generally construct a Node[Something] from the Maven/Gradle build, then transform that into a Node[BuildObject] representing the Mill build, and then we serialize that to build.mill/package.mill files on disk?

ajaychandran · 2025-01-18T03:21:13Z

@lihaoyi
Should the main.gradle and main.maven modules be moved under the main/buildgen folder? They do not have any use outside build generation.

lihaoyi · 2025-01-18T03:30:59Z

@ajaychandran maybe lets move everything into the main/init/ folder?

lefou · 2025-01-18T09:45:13Z

@lihaoyi wrote

Also, could you write an architecture summary of the entire buildgen pipeline and put it in a readme.md file in that folder:

But I would suggest to stick with readme.adoc (not readme.md) for consistency with all the other documentation files.

ShreckYe

Here I have performed a full and rigorous code review as requested by Haoyi in #3962 (comment). First I'd like to say it's a job well done and I see there is a great effort put into this. Given the amount of code, I've left numerous comments. Please note:

In all these comments, I have proposed different alternative implementations, some of which may contradict each other. Please go through all the comments first and make decisions before taking a suggestion and start working on one.
Some suggestions reflect my personal coding style and may not be universally applicable. They may be unnecessary. If you have disagreements with these suggestions, please discuss and seek @lihaoyi's final advice.

@lihaoyi, it would be very helpful if you could provide your initial feedback on these comments when you have a chance.

There are 3 areas I'd like to highlight:

Scala is a language that prefers functional programming and Mill is a tool that favors immutability. Some imperative logic and logic using nulls can be adapted into functional to be more readable and maintainable.
More common code in both BuildGen clases can be extracted.

Especially, please check out my "intermediate model" suggestion from the comments in "main/gradle/src/mill/main/gradle/BuildGen.scala" and consider its potential benefits.
In Scala, it's generally considered more idiomatic to use full words rather than abbreviated forms. I think these 3 abbreviations "interp", "cfg", "reps", especially, are better to be replaced by their full forms. If you accept this, please search and replace all their occurrences in the affected files.

ShreckYe · 2025-01-18T12:24:51Z

build.mill

@@ -202,6 +202,7 @@ object Deps {
  val mavenResolverTransportWagon =
    ivy"org.apache.maven.resolver:maven-resolver-transport-wagon:$mavenResolverVersion"
  val coursierJvmIndexVersion = "0.0.4-70-51469f"
+  val gradleApi = ivy"dev.gradleplugins:gradle-api:8.11.1"


~~The latest is 8.12 but this is not important anyway.~~

I get it now that you are using "dev.gradleplugins:gradle-api" whose latest is 8.11.1.

Additionally, the version is conventionally extracted into a constant:

Suggested change

val gradleApi = ivy"dev.gradleplugins:gradle-api:8.11.1"

val gradleApiVersion = "8.11.1"

val gradleApi = ivy"dev.gradleplugins:gradle-api:$gradleApiVersion"

Additionally, the version is conventionally extracted into a constant:

Looks premature to me.

ShreckYe · 2025-01-18T12:52:39Z

docs/modules/ROOT/pages/migrating/maven.adoc

 ** JUnit 4
 ** JUnit 5
 ** TestNG
 * configures multiple, compile and test, resource directories

 === Command line arguments
-.name of generated base module trait defining project metadata settings
+
+The conversion and it's output (the generated Mill build files) can be customized using


Suggested change

The conversion and it's output (the generated Mill build files) can be customized using

The conversion and its output (the generated Mill build files) can be customized using

ShreckYe · 2025-01-18T12:54:39Z

docs/modules/ROOT/pages/migrating/gradle.adoc

+[#arguments]
+=== Command line arguments
+
+The conversion and it's output (the generated Mill build files) can be customized using


Suggested change

The conversion and it's output (the generated Mill build files) can be customized using

The conversion and its output (the generated Mill build files) can be customized using

docs/modules/ROOT/pages/migrating/gradle.adoc

ShreckYe · 2025-01-18T13:35:18Z

example/javalib/migrating/3-gradle-complete/build.mill

+/** Usage
+
+> rm build.mill # remove any existing build file
+
+> git init .
+> git remote add -f origin https://github.com/komamitsu/fluency.git
+> git checkout 2.7.3 # multi-module Java project that requires Java 16+
+
+> ./mill init --base-module FluencyModule --jvm-id 16
+converting Gradle build
+writing Mill build file to fluency-aws-s3/package.mill
+writing Mill build file to fluency-core/package.mill
+writing Mill build file to fluency-fluentd-ext/package.mill
+writing Mill build file to fluency-fluentd/package.mill
+writing Mill build file to fluency-treasuredata/package.mill
+writing Mill build file to build.mill
+init completed, run "mill resolve _" to list available tasks
+
+> ./mill __.compile
+compiling 9 Java sources to ...out/fluency-aws-s3/compile.dest/classes ...
+compiling 6 Java sources to ...out/fluency-aws-s3/test/compile.dest/classes ...
+compiling 27 Java sources to ...out/fluency-core/compile.dest/classes ...
+compiling 8 Java sources to ...out/fluency-core/test/compile.dest/classes ...
+
+> ./mill fluency-core.test # running all tests takes too long
+Test org.komamitsu.fluency.FluencyTest finished, ...
+Test org.komamitsu.fluency.validation.ValidatableTest finished, ...
+Test org.komamitsu.fluency.buffer.BufferTest finished, ...
+Test org.komamitsu.fluency.buffer.BufferPoolTest finished, ...
+Test org.komamitsu.fluency.flusher.FlusherTest finished, ...
+Test org.komamitsu.fluency.recordformat.MessagePackRecordFormatterTest finished, ...
+*/


Should these files be converted into READMEs since they are just commands and results in comments?

These commands are automatically used as integration tests and the (expected) output will be asserted.

Got it. Thanks for pointing out.

ShreckYe · 2025-01-21T19:36:53Z

main/maven/src/mill/main/maven/BuildGen.scala

-      val url = escape(license.getUrl)
-      val isOsiApproved = false
-      val isFsfLibre = false
-      val distribution = "\"repo\""
-
-      s"License($id, $name, $url, $isOsiApproved, $isFsfLibre, $distribution)"
-    }.mkString("Seq(", ", ", ")")
-    val versionControl = Option(model.getScm).fold(Seq.empty[String]) { scm =>
-      val repo = escapeOption(scm.getUrl)
-      val conn = escapeOption(scm.getConnection)
-      val devConn = escapeOption(scm.getDeveloperConnection)
-      val tag = escapeOption(scm.getTag)
-
-      Seq(repo, conn, devConn, tag)
-    }.mkString("VersionControl(", ", ", ")")
-    val developers = model.getDevelopers.iterator().asScala.map { dev =>
-      val id = escape(dev.getId)
-      val name = escape(dev.getName)
-      val url = escape(dev.getUrl)
-      val org = escapeOption(dev.getOrganization)
-      val orgUrl = escapeOption(dev.getOrganizationUrl)
-
-      s"Developer($id, $name, $url, $org, $orgUrl)"
-    }.mkString("Seq(", ", ", ")")
-    val publishVersion = escape(model.getVersion)
-    val publishProperties =
-      if (cfg.publishProperties.value) {
-        val props = model.getProperties
-        props.stringPropertyNames().iterator().asScala
-          .map(key => s"(\"$key\", ${escape(props.getProperty(key))})")
-      } else Seq.empty
-
-    val pomSettings =
-      s"override def pomSettings = PomSettings($description, $organization, $url, $licenses, $versionControl, $developers)"
-    val publishVersionSetting =
-      s"override def publishVersion = $publishVersion"
-    val publishPropertiesSetting =
-      optional(
-        "override def publishProperties = super.publishProperties() ++ Map",
-        publishProperties
-      )

-    s"""$pomSettings
-       |
-       |$publishVersionSetting
-       |
-       |$publishPropertiesSetting""".stripMargin
-  }
-
-  private def escape(value: String): String =
-    pprint.Util.literalize(if (value == null) "" else value)
-
-  private def escapeOption(value: String): String =
-    if (null == value) "None" else s"Some(${escape(value)})"
-
-  private def optional(start: String, value: String): String =
-    if (null == value) ""
-    else s"$start$value"
-
-  private def optional(construct: String, args: IterableOnce[String]): String =
-    optional(construct + "(", args, ",", ")")
-
-  private def optional(
-      start: String,
-      vals: IterableOnce[String],
-      sep: String,
-      end: String
-  ): String = {
-    val itr = vals.iterator
-    if (itr.isEmpty) ""
-    else itr.mkString(start, sep, end)
-  }
-
-  private def resources(relPaths: IterableOnce[os.RelPath]): String = {
-    val itr = relPaths.iterator
-    if (itr.isEmpty) ""
-    else
-      itr
-        .map(rel => s"PathRef(millSourcePath / \"$rel\")")
-        .mkString(s"override def resources = Task.Sources { super.resources() ++ Seq(", ", ", ") }")
+    val companions = cfg.depsObject.fold(SortedMap.empty[String, BuildObject.Constants])(name =>
+      SortedMap((name, SortedMap(namedIvyDeps.result() *)))
+    )
+
+    (
+      companions,
+      mainBomIvyDeps.result(),
+      mainIvyDeps.result(),
+      mainCompileModuleDeps.result(),
+      mainCompileIvyDeps.result(),
+      mainModuleDeps.result(),
+      mainRunIvyDeps.result(),
+      mainRunModuleDeps.result(),
+      testModule,
+      testBomIvyDeps.result(),
+      testIvyDeps.result(),
+      testModuleDeps.result()
+    )
  }
 }


As above, this is another part that I think a functional approach would be more readable and maintainable. I did adapt this part based on your old implmentation in my implementation, and feel free to borrow the code. Also, I extracted a GenericBuildModels.AllDependencies so we have more abstraction and code reuse.

ShreckYe · 2025-01-21T19:38:35Z

main/maven/src/mill/main/maven/BuildGen.scala

    baseModule: Option[String] = None,
-    @arg(doc = "name of generated nested test module")
+    @arg(doc = "version of custom JVM to configure in --base-module", short = 'j')


As above, "distribution and version".

ShreckYe · 2025-01-21T19:54:33Z

main/src/mill/main/MainModule.scala

+          os.exists(os.pwd / "build.gradle") ||
+          os.exists(os.pwd / "build.gradle.kts") ||


I think you can ignore the build scripts here as they are just for subprojects, like Mill's "package.mill". Just detecting settings scripts should be enough.

Project JCommander does not have a settings script.

OK. Thanks for pointing out.

ShreckYe · 2025-01-21T20:00:29Z

main/package.mill

+    def moduleDeps = Seq(buildgen)
+    def ivyDeps = Agg(
+      build.Deps.gradleApi,
+      build.Deps.logback


Logback is runner's dependency already, but you can leave it if you want this to be explicit.

ShreckYe · 2025-01-21T20:24:33Z

main/maven/src/mill/main/maven/BuildGen.scala

+    val testIvyDeps = SortedSet.newBuilder[String]
+    val testModuleDeps = SortedSet.newBuilder[String]
+
+    val hasTest = os.exists(os.Path(model.getProjectDirectory) / "src/test")


As above in Gradle's, this value is used only once deeply inside the if-blocks

lefou · 2025-01-21T22:44:56Z

docs/modules/ROOT/pages/migrating/gradle.adoc

+* `--base-module` (`-b`): name of generated base module trait defining shared settings
+[source,sh]
+----
+./mill init --base-module MyModule
+----


Example how to keep the source block in the list item.

https://docs.asciidoctor.org/asciidoc/latest/lists/continuation/#list-continuation

Suggested change

* `--base-module` (`-b`): name of generated base module trait defining shared settings

[source,sh]

----

./mill init --base-module MyModule

----

* `--base-module` (`-b`): name of generated base module trait defining shared settings

+

[source,sh]

----

./mill init --base-module MyModule

----

ajaychandran · 2025-01-23T01:23:05Z

The refactoring looks good. Thanks @lihaoyi

I think I addressed the remaining comments. Please let me know if anything is pending.

main/init/maven/src/mill/main/maven/MavenBuildGenMain.scala

lihaoyi · 2025-01-23T01:44:42Z

main/init/gradle/src/mill/main/gradle/GradleBuildGenMain.scala

+      packaging = null,
+      pomParentArtifact = null,
+      resources = Nil,
+      testResources = Nil,
+      publishProperties = Nil


@ajaychandran here as well, we should either leave a comment as to why packaging/pomParentArtifact/resources/testResources/publishProperties are null/Nil? Or fill them out if they do not need to be so

Added support for packaging / publishProperties.
Added comments for

pomParentArtifact: This is not directly available in the Gradle API.

resources/testResources: These were skipped to avoid using JavaPluginExtension.getSourceSets; this would limit support to Gradle version 7.1+.

- Use MavenModel.Pom.packaging - Added comments for skipped settings - Removed unused MavenModel.Pom.organization() - Fix compiler warning

ajaychandran · 2025-01-23T05:51:00Z

CI failures seem to be unrelated.

selective.run 3 tasks failed
example.pythonlib.basic[1-simple].local.server.test 1 tests failed: 
  mill.testkit.UtestExampleTestSuite mill.testkit.UtestExampleTestSuite.exampleTest
example.pythonlib.module[1-common-config].local.server.test 1 tests failed: 
  mill.testkit.UtestExampleTestSuite mill.testkit.UtestExampleTestSuite.exampleTest
example.pythonlib.module[6-pex-config].local.server.test 1 tests failed: 
  mill.testkit.UtestExampleTestSuite mill.testkit.UtestExampleTestSuite.exampleTest

selective.run 1 tasks failed
example.thirdparty[mockito].local.server.test 1 tests failed: 
  mill.testkit.UtestExampleTestSuite mill.testkit.UtestExampleTestSuite.exampleTest

lihaoyi · 2025-01-23T06:37:42Z

Thanks @ajaychandran , I gave CI a few kicks so hopefully it's just flakiness.

lihaoyi · 2025-01-23T07:02:38Z

This looks good to me for now I think, thanks again @ajaychandran for your contribution and @ShreckYe for the review. We can continue to improve this over time but I think this is complete enough to satisfy the original ticket

@ajaychandran I will transfer the bounty using the same details we used before. @ShreckYe please email me (haoyi.sg@gmail.com) your international bank transfer details and I will make the payment

This is from reviewing #4363. I couldn't comment on this because it was not part of the changes.

…4405) As commented in #4363 (comment). The PR got merged before I replied to this.

…yi#4363) Resolves com-lihaoyi#3962 by extending `mill init` with the ability to import a Gradle project. * handles deeply nested modules * configures dependencies for configurations: * implementation / api * compileOnly / compileOnlyApi * runtimeOnly * testImplementation * testCompileOnly * configures testing frameworks * supports Gradle plugins * [java](https://docs.gradle.org/current/userguide/java_plugin.html) * [maven-publish](https://docs.gradle.org/current/userguide/publishing_maven.html) Additionally, Maven support added in com-lihaoyi#3756 was improved. * shared logic moved out to module `buildgen` * added support for BOM dependencies * eliminated creation of redundant test modules * fixed `millSourcePath` for test module --------- Co-authored-by: Li Haoyi <haoyi.sg@gmail.com> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>

This is from reviewing com-lihaoyi#4363. I couldn't comment on this because it was not part of the changes.

…om-lihaoyi#4405) As commented in com-lihaoyi#4363 (comment). The PR got merged before I replied to this.

ajaychandran added 7 commits January 17, 2025 21:47

Added support for importing a Gradle project

a71cecb

Escaped path to fix Windows error and fixed format

49386ba

Fix format

4cf060c

Fix initscript

73c31e2

Cleanup

8e448da

Cleanup

c4a0549

Cleanup

a01f852

ajaychandran marked this pull request as ready for review January 17, 2025 19:57

lihaoyi reviewed Jan 18, 2025

View reviewed changes

main/buildgen/src/mill/main/buildgen/BuildGenUtil.scala Outdated Show resolved Hide resolved

lihaoyi reviewed Jan 18, 2025

View reviewed changes

vaslabs mentioned this pull request Jan 19, 2025

Android Studio Integration: Attempt via bsp for Java android apps #4362

Merged

ajaychandran marked this pull request as draft January 20, 2025 10:27

ShreckYe suggested changes Jan 21, 2025

View reviewed changes

lefou reviewed Jan 21, 2025

View reviewed changes

lihaoyi added 10 commits January 22, 2025 09:04

inline type aliases

7b08e2e

rename reps/interpIvy

96ffc8a

make all string rendering methods start with the word render

723653e

move maven/gradle/buildgen into init

8133658

extract common config fields

6539731

merge

491ef5b

remove unnecessary scalaconversions

688f27a

autofix

c151767

tidy up main/gradle/BuildGen

c277e71

.

df20659

lihaoyi force-pushed the gradle branch from 92cf151 to 35bcc35 Compare January 22, 2025 14:13

autofix-ci bot and others added 9 commits January 22, 2025 14:20

[autofix.ci] apply automated fixes

da1a56c

Fix warnings

c61fce9

Added/updated code docs

2cf079c

Fix golden files

632be2a

[autofix.ci] apply automated fixes

ff8747b

Use variable to improve maintainability

466a0bb

Fixed failing test for Ehcache3 and set jvmId for Moshi test

d8e7be4

Document quirk

afca05e

Resolved some review comments

428310e

lihaoyi reviewed Jan 23, 2025

View reviewed changes

main/init/maven/src/mill/main/maven/MavenBuildGenMain.scala Outdated Show resolved Hide resolved

lihaoyi reviewed Jan 23, 2025

View reviewed changes

ajaychandran added 2 commits January 23, 2025 08:09

Added support for custom repos in Maven conversion

3b863dd

Added suppot for publishing protperties in Gradle Conversion.

25a427e

- Use MavenModel.Pom.packaging - Added comments for skipped settings - Removed unused MavenModel.Pom.organization() - Fix compiler warning

lihaoyi merged commit 2b46ae8 into com-lihaoyi:main Jan 23, 2025
31 checks passed

lefou added this to the 0.12.6 milestone Jan 23, 2025

ajaychandran deleted the gradle branch January 23, 2025 10:44

lihaoyi mentioned this pull request Jan 24, 2025

Support mill init from an existing SBT project (2000USD Bounty) #3450

Open

This was referenced Jan 25, 2025

Fix a possible typo in "maven.adoc" #4404

Merged

Remove some redundant parentheses in the mill init build gen code #4405

Merged

lihaoyi pushed a commit that referenced this pull request Jan 26, 2025

Fix a possible typo in "maven.adoc" (#4404)

e7ea055

This is from reviewing #4363. I couldn't comment on this because it was not part of the changes.

ShreckYe added a commit to ShreckYe/mill that referenced this pull request Jan 26, 2025

Merge branch 'main' into redundant-parentheses-in-com-lihaoyi#4363

be55c70

lihaoyi pushed a commit that referenced this pull request Jan 28, 2025

Remove some redundant parentheses in the mill init build gen code (#…

6899b66

…4405) As commented in #4363 (comment). The PR got merged before I replied to this.

gamlerhart pushed a commit to gamlerhart/mill that referenced this pull request Feb 9, 2025

Fix a possible typo in "maven.adoc" (com-lihaoyi#4404)

e73d693

This is from reviewing com-lihaoyi#4363. I couldn't comment on this because it was not part of the changes.

gamlerhart pushed a commit to gamlerhart/mill that referenced this pull request Feb 9, 2025

Remove some redundant parentheses in the mill init build gen code (c…

2b49e2d

…om-lihaoyi#4405) As commented in com-lihaoyi#4363 (comment). The PR got merged before I replied to this.

	val gradleApi = ivy"dev.gradleplugins:gradle-api:8.11.1"
	val gradleApiVersion = "8.11.1"
	val gradleApi = ivy"dev.gradleplugins:gradle-api:$gradleApiVersion"

	The conversion and it's output (the generated Mill build files) can be customized using
	The conversion and its output (the generated Mill build files) can be customized using

		os.exists(os.pwd / "build.gradle") \|\|
		os.exists(os.pwd / "build.gradle.kts") \|\|

Added support for 'mill init' from existing Gradle project #4363

Added support for 'mill init' from existing Gradle project #4363

Conversation

ajaychandran commented Jan 17, 2025

lihaoyi commented Jan 18, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajaychandran commented Jan 18, 2025

lihaoyi commented Jan 18, 2025

lefou commented Jan 18, 2025

ShreckYe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShreckYe Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShreckYe Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShreckYe Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lefou Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

ajaychandran commented Jan 23, 2025

Choose a reason for hiding this comment

ajaychandran Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

ajaychandran commented Jan 23, 2025

lihaoyi commented Jan 23, 2025

lihaoyi commented Jan 23, 2025 • edited Loading

lihaoyi commented Jan 18, 2025 •

edited

Loading

ShreckYe Jan 21, 2025 •

edited

Loading

ShreckYe Jan 21, 2025 •

edited

Loading

ShreckYe Jan 21, 2025 •

edited

Loading

lefou Jan 21, 2025 •

edited

Loading

ajaychandran Jan 23, 2025 •

edited

Loading

lihaoyi commented Jan 23, 2025 •

edited

Loading