Todo List:
inline def https://github.com/Log4s/log4s/blob/1155339023744cb6d2f9809cfff8ea5b57c59868/src/main/scala/org/log4s/Logger.scala#L88-L101)@liufengyun
I'm happy to help out with this issue.
I can reiterate what was said at the meeting:
- Which repo will the community build be hosted?
lampepfl/dotty-community-build
- Are there any planned candidate projects for the community build?
We should include the ones already compiling (and working):
Which repo will the community build be hosted?
lampepfl/dotty-community-build
That's not how I undestood what was discussed in the meeting.
The way I understood it:
Keeping it on staging is fine IMO, but the other point I don't agree with.
I propose the structure to be something like:
.
├── dotty (submodule @ latest master)
├── better-files (submodule)
└── scalatest (submodule)
Then you do publishLocal on dotty and use it to compile the other submodules.
Making a fork of dotty which contains submodules sounds messy.
@felixmulder Where is the latest work on compiling scalatest+scalacheck+better-files with dotty?
@DarkDimius Can you invite me and @liufengyun to the dotty-staging organization with permission to create new repositories?
@olafurpg scalatest is here: https://github.com/OlivierBlanvillain/scalatest/commits/dotty
I made some progress today on the infrastructure side, see here https://github.com/lampepfl/dotty-community-build/pull/1
This sets up a build where @OlivierBlanvillain's fork of scalatest is compiled against the latest NIGHTLY release of Dotty. We can then add more projects to the build by adding new submodules.
Scalatest + infrastructure is up! @felixmulder Can you assign me please to this issue so I can check out those boxes.
I've started working on scalacheck now https://github.com/dotty-staging/scalacheck/pull/1
I cannot - @DarkDimius or @Densh has to add you to the dotty team, then you can self assign.
It seems better-files on master branch does not compile with 2.11 since November 2011. It uses uses BufferedIterator.headOption. I'm gonna work put better-files on hold until this gets fixed, better-files is incubating for inclusion in the Scala platform so it will need to support 2.11 according to @jvican.
I'm stuck on an assertion error in typer.Implicits for compiling scalacheck. See stack trace, could someone with more Dotty experience take a look at that? (ps. I asked same question on gitter)
I'm gonna work on squants next.
I cannot - @DarkDimius or @Densh has to add you to the dotty team, then you can self assign.
Done.
The community-build is taking shape now. Here are a few notes that might be helpful on how to add a new project, say project ORG/REPO, to the current infrastructure:
Open dotty-staging/REPO on Github: Settings > Branches > change main branch to "dotty"

go to https://travis-ci.org/profile/dotty-staging and enable that repo, you may need to click on "Sync account" and reload to see the newly forked repo
A nice benefit with this setup is that build failures in lampepfl/dotty-community-build are easy to debug. For example, if only one repo fails the travis build page looks like this

Build logs for each community project are separated so it's easy to track down a failure in a single project: https://travis-ci.org/lampepfl/dotty-community-build/jobs/220623982#L1705
I'm sure this setup can be simplified/automated/improve on many ways, so any feedback is welcome.
BTW. If someone's interested, it might be worth investigating if https://github.com/storm-enroute/mecha can be used for this setup.
@olafurpg - since we're now on 2.12.3 we should add better-files to the community build! :tada:
@olafurpg Is ScalaCheck still stuck on an assertion error with the latest nightly?
https://github.com/pathikrit/better-files is blocked by #3168 and #3171
ScalaCheck is blocked by two implicit resolution failures: https://travis-ci.org/dotty-staging/scalacheck/builds/280025029#L1596
I was not able to minimise the failures though
For the second one, see https://github.com/smarter/scalacheck/commits/fix/ambiguous-implicits
scopt/scopt is blocked by #3189
Idea/question: many projects are hard to test because they use macros, so could we go to their Scala 2.9 version? We'd run into other incompatibilities (view bounds), but I suspect they're much more superficial.
I don't think porting Scala 2.9 code is going to be very useful. Ideally we want to compile libraries with their dependencies, so we need recent version of these dependencies. What we need is to figure out how to replace macros in projects on case by case basis, even if this means adding special cases in the compiler to ease transition (e.g. support for kind-projector syntax)
We also want to have our changes merged into the upstream library when reasonable, fixing an old version of the library wouldn't help for that.
Most helpful comment
Keeping it on staging is fine IMO, but the other point I don't agree with.
I propose the structure to be something like:
Then you do
publishLocalon dotty and use it to compile the other submodules.Making a fork of dotty which contains submodules sounds messy.