CC @odersky @hamzaremmal as we discussed this when I visited lausanne

We can't use os-lib or requests while still supporting Java 8, as they require Java 11, so for now I just use java.io/java.nio to do the same thing. It looks super ugly, but when we start requiring Java >=17 we can clean this up

@lihaoyi we already require Java >= 17, the main branch is already set to 3.8

@Gedochao the community_build_n jobs were failing when I was using Java 11 APIs such as the java.net.HttpClient (transitively via requests-scala)

Looks to me like

is failing, though I have no idea about that tests. Something connected to tmp and the new changes.

This line of test outputs gives us a hint: https://github.com/scala/scala3/actions/runs/17377385477/job/49667379148?pr=23849#step:9:8944
test 'hello world' = 'Building Dotty...
Which is printed for

I bealive the test assumed that ./bin/scala is ready to use and does not need to require building compiler/runner again.
However, in the logs we can see that it does actually bootstrap the new binary and finishes by printing hello world as expected.
It might be related to changes made to the build file and introduced source generator.
A workaround can trimming the output to the last lines, but it would not fix the underlying issue - need to build compiler on each usage from ./bin/scala

Shouldn't using bin/scala build the compiler locally? I assumed that such a script is meant to give you the scala compiler/REPL representing the compiler sources currently checked out, and not some cached version of the compiler/REPL built from earlier sources. Or is that mistaken?

Shouldn't using bin/scala build the compiler locally? I assumed that such a script is meant to give you the scala compiler/REPL representing the compiler sources currently checked out, and not some cached version of the compiler/REPL built from earlier sources. Or is that mistaken?

bin/scala runs the official Scala runner... being Scala CLI 😅 So no, it doesn't build the compiler locally.

Thanks @Gedochao ! Looks like adding a caching layer to the source downloader is enough to avoid the noisy logs and make the test pass

@WojciechMazur Another argument for downloading and unpacking sourcejars on the fly v.s. vendoring it statically is that we already do that for a bunch of different source jars in https://github.com/scala/scala3/blob/main/project/Build.scala: mtags-shared in one case and scalajs-ir in three other cases. So for PPrint/Fansi/SourceCode to do the same would be in line with the current design patterns

I've cut over the shadedSourceGenerator implementation to use SBT's IO.* APIs rather than raw java.net/java.io. Now it should look a lot more similar to the code that downloads/unpacks mtags-shared and scalajs-ir

In the last commits I set the default pprint dimensions to width=100 height=50, and added a import dotty.shaded.pprint.pprintln to the predef of every REPL so users have pprintln available in scope. Users who want to print more than 50 lines can call pprintln which prints up to 100x500 by default, and can take a custom height=9999 if they want to print more.

The numbers 100x50 and 100x500 are heuristics:

• 100x50 as the default for echo-ed values is a heuristic optimizing for terminal use, where width=100 approximates the common maximum width people tend to format their code to (typically 80-120), and 50 reflects about 0.5 to 1 vertical screenful of text so it doesn't kick previous terminal output off the top of your terminal
• 100x500 as the default for pprintln is a heuristic optimizing for non-terminal use: it's about 5-10 vertical screenfuls of text, and about the limit of what we expect people to usefully be able to skim through. Typically, in most cases when the output is larger than this, you'd want to cut it down by selecting a subset of the output programmatically.
• If the user really wants to print everything, they can run pprintln(foo, height=99999) or similar

The heuristics can be tweaked, but they should provide a decent baseline for printing a useful amount of output to screen without flooding the user's terminal.

Setting the default max width and height based on the users terminal is a TODO, I can submit a follow up PR to do so

Could we squash all those commits, or at least have reasonable commit messages, please?

@sjrd I assumed you would use the Squash and Merge button on the Github UI, that will embed the PR description in the commit message which will make it easy to follow understand the commit when going through history later on

If you want I can squash it manually too, if you don't want to use the squash button

he means the . , which will present after squashing merge

There's a button to squash-and-use-PR-description-as-commit-message IIRC? That's what I've been using this whole time the last decade

Done, with so many commits, github took the PR description as the message

Thanks again @lihaoyi !