JMH Plugin: Part deux #3582
Open
JMH Plugin: Part deux #3582
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@Quafadas I think this looks great, if you resolve the conflicts I'll merge it |
|
Closing this out of inactivity. Feel free to re-open if necessary |
|
I've just come back from a few weeks afk. I'll try and rebase / resolve it in the coming days. Apologies for the delay. |
Also make the first example on the `intro.adoc` a `foo` module rather than a `RootModule`, since the whole `package extends RootModule` thing is probably scary to newbies and they can discover it later as necessary Fixes com-lihaoyi#2587
…ll-opts` (com-lihaoyi#3841) This PR extends `.mill-jvm-opts` to support interpolating JVM variables. This provides a bit of flexibility in allowing `$PWD` and `$USER` to be used when passing `-Dproperty=` to Mill. This could in theory be fleshed out even further to run arbitrary shell snippets, but for now I this should provide enough flexibility to meet the immediate needs. Also added a `.mill-opts`, which is similar to `.mill-jvm-opts` but used for Mill arguments rather than JVM arguments. This provides a way to persistent required Mill configuration in a format that is similar to what we already have today (CLI args). This would be a common place to put things like `--jobs=0.5C` or `--allow-positional` or `--no-build-lock`. Updated the integration tests and documentation related discussions * com-lihaoyi#1226 * com-lihaoyi#3840
…es, add tests for overriding opts (com-lihaoyi#3844)
This splits out the landing page from the language-specific intros. Merging the two sections into one long page felt like a good idea at the time, but in retrospect I think it just added confusion, especially now that we support 3 main languages. Splitting it out gives us a proper place to talk about what Mill itself is, avoids duplication between the different into first pages, and provides a place we can nicely link to the various language-specific intros and other documentation sections
…yi#3852) Previously we disabled the global one because it was redundant, but it seems the page version switcher doesn't play well with renamed pages even when page aliases are defined, resulting in a lot of page version links being broken. So for now we just disable the page version switcher in favor of the global one Tested locally using `docs.githubPages`. The link to 0.11.12 is still broken, but it should be fixed once we release 0.11.13 with com-lihaoyi@c61d1ed included
Instead of always using `build.mill` we now use the actual buildfile name in the progress logger. ``` > mill resolve _ [build.sc-57/61] compile ... > mv build.sc build.mill.scala > mill resolve _ [build.mill.scala-57/61] compile ... ``` Fix com-lihaoyi#3831 Pull request: com-lihaoyi#3847
* Broke out a new top-level section `The Mill CLI` for what was
previously `Installation & IDE Support`
* Broke out `Mill Command-Line Flags` and `Other installation methods`
into their own sections
* Moved documentation for `--interactive`/`--watch`/`--jobs` into `Mill
Command-Line Flags`
* Moved the `Realistic {language} Example Project` from `build-examples`
to `{language}lib/intro.adoc`
* This helps make a clearer separation between the "tutorial
read-from-top-to-bottom" `intro.adoc` and the rest of the stuff in each
language-specific section which is more "look up stuff as necessary"
* Deleted the `nested-modules` example. Probably not important enough to
deserve a full example/doc on its own
* `build-examples.adoc` now only contains `Example builds for real
projects` and `Real World Mill Builds`
* Add a reference to mill-mima under the Linting pages for Java and
Scala (not sure if it works well with Kotlin so left that out)
* Add the missing kotlin web examples to the kotlin doc pages
Pull request: com-lihaoyi#3855
…ihaoyi#3856) Same as com-lihaoyi#3558, but for `mill.define.Ctx` rather than `mill.main.RootModule.Info`. Because it's provided by the enclosing code-generation, we need to trick IntelliJ into thinking there is something it can use, and so I define a low priority implicit to fall back upon if the main `def make` doesn't work (but `@compileTimeOnly` to show an error message if it ends up being needed) I moved the bulk of the cacher logic from `mill-moduledefs` to `mill.define`. We just need a marker trait in `mill-moduledefs`, and having the rest of the logic in Mill itself simplifies maintenance and evolution of the code Before <img width="976" alt="Screenshot 2024-10-28 at 5 55 39 PM" src="https://github.com/user-attachments/assets/93bd9259-ab81-4e8c-9e71-21142fff107b"> After <img width="976" alt="Screenshot 2024-10-28 at 5 54 22 PM" src="https://github.com/user-attachments/assets/7a5c6964-d212-4efa-805b-ea68917bdcbe">
We have various things to import, but this parameter is for the enabled-state of the meta-build, so reflect it in the name. Pull request: com-lihaoyi#3848
…tructions to join channel (com-lihaoyi#3866) Fixes com-lihaoyi#3864 Somehow the direct channel links always expire even when specifically configured not to
The goal is to be a single page to answer this frequently asked question, skimming over and summarizing the interesting bits from the other more-detailed pages in a way they are easily consumed in one read-through. For now it's mostly transcribed from my Japan Java User Group talk, and very copy-pasty with other parts of the repo. Not perfect, but it can evolve over time
to allow submodule use scala keyword as name, fix com-lihaoyi#3863 I am not sure this is the way we want to match scala keyword though
All currently configured previous versions point to git tags, not branches. Hence editing on Github isn't fruitful. Fix com-lihaoyi#3858 Pull request: com-lihaoyi#3861
…aoyi#3881) If this causes problems, it causes problems really early since Mill can't bootstrap, so we need the documentation on what to do to be really early as well
This is a PR to close issue com-lihaoyi#3647
This now points to the right file, the previous comment points to nowhere.
…com-lihaoyi#3878) This completes com-lihaoyi#3715 with all the cycle cases I could think of. It also touches `resolveDirectChildren` where I made some changes that I would help with readability. I thought I was going to need to build on those but didn't. These can be reverted if it's unwanted. --------- Co-authored-by: Li Haoyi <[email protected]>
…ges (com-lihaoyi#3884) Mill used various tricks to map build scripts written by users to generated enhanced versions, including package objects and other stuff. Since some of these techniques may result in Zinc undercompilation, we want avoid downstream issues, especally in the `methodCodeHashSignatures` task, which is sensitive to inconsistent bytecode. We trait potentially longer compilation against incorrect or too coarse code change detection, which may invalidate a lot more downstream tasks than needed due to invalid data. Fix com-lihaoyi#3874 Pull request: com-lihaoyi#3884
We broaden the scope of `profileLogger`/`chromeProfileLogger` from within `def evaluate` to instead last as long as the `Evaluator` itself, and share it with any sub-`Evaluator`s created e.g. to redirect output during `show` `Evaluator` is now `AutoCloseable`, and needs to be closed after being used in `MillBuildBootstrap` and in `UnitTester` For now I decided not to share the profilers between different evaluation levels of the meta-build, since they already don't overlap: one goes to `out/`, the parent to `out/mill-build/`, etc. We could do that if we think it would be useful to give people a consolidated profile, but it might be a bit more work (e.g. we would need to properly prefix entries in the profile to distinguish the different meta levels). Added a unit test to ensure the `show compile` mill-profile and mill-chrome-profile contain the expected keys for both `show` and for `compile` and some of its upstream tasks Fixes com-lihaoyi#3879
…-lihaoyi#3887) Fixes com-lihaoyi#3875 I placed a check to raise an error when a non-exclusive task depends on an exclusive task. We could place this check any time from task instantiation to just before the `NoSuchElementException` gets thrown. I ended up putting it as late as possible, such that the failure is localized, which allows other un-related parts of the build to proceed despite the failure, as well as allowing other errors in the build to be reported in parallel (rather than having to re-run the build over and over after fixing each one to see the next one) Covered with an integration test that asserts on the error message. Best reviewed with Ignore Whitespace
…ile (com-lihaoyi#3892) Since com-lihaoyi#3818 created a `dist/` sub-folder, we may as well use it. This removes 300+ lines from the root `build.mill` and should speed up incremental compiles of the build code
- Remove dead code for Scala Native 0.4 - Cleanup unused imports Pull Request: com-lihaoyi#3896
|
Rebased onto main - apologies for the delay. |
|
Aw hell, I looked at the PR diff, and apparently it's now advertising all the change made in the rebase onto main. Not just mine. TIL. Would I better off closing and reopening this? Seems to be hard to review TBH. |
|
@Quafadas surr lets do that |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think the previous solution, actually did work. However, something itched at me.
After a night sleep, I've realised that I don't think it correctly follows mills nomenclature.
--add-modules=jdk.incubator.vectoris a JVM init flag, not (I believe) a compiler flag. Hence, I think this really belongs in the "forkArgs" task.The previous solution works, because both are a list of strings in the end, but I think this revised version more correctly follows mill nomenclature. Apologies for the spamminess. I couldn't see it before somehow.
I didn't realise this was possible - for me thought it provides a scary looking compiler error. I've had this with mill before - my previous contributions have been made through bootlegging this proposal #3108 , as I couldn't get mill to compile locally;