Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tobias Roeser
    @lefou
    Is there any documentation about the BSP testkit?
    I'm looking for something that helps me testing the mill BSP support, where mill is the real BSP server. I'd like to write test cases, with some test projects with mill. So, I'd like to script the BSP client and assert the expected outcome from mill.
    Or, maybe, you already have some test suite, and the only thing I need to provide is the proper mill setup...
    Justin Kaeser
    @jastice
    @lefou not really, documentation is just me and Andre Rocha and the code we wrote with it :sweat_smile:
    there are some prepared test case functions
    Tobias Roeser
    @lefou
    @jastice Thanks. Do you know how other build tools test it? I think these test suites must all look the same, only difference is the build tool specific config, but the tests should be driven by the BSP client, shouldn't they?
    Justin Kaeser
    @jastice
    so the testkit has parts to test the client and parts to test the server. the latter was written for https://github.com/JetBrains/bazel-bsp
    so maybe that repo is helpful to you
    Tobias Roeser
    @lefou
    Ok, I know nothing about bazel, but I will have a look. Thank you!
    Justin Kaeser
    @jastice
    yup
    Runnable[] tests is where it uses the test functions
    Tobias Roeser
    @lefou
    import ch.epfl.scala.bsp.testkit.client.TestClient;
    Where does this come from?
    I think this is the key: "@maven//:ch_epfl_scala_bsp_testkit_2_13",
    Ok, I will see what I can do with it.
    Thanks
    Eric Peters
    @er1c
    How do you re-run the generator?
    Eric Peters
    @er1c
    Think I found it "xtend"
    Vadim Chelyshov
    @dos65
    1 reply
    Tobias Roeser
    @lefou

    Hi, we got the following issue open in mill: com-lihaoyi/mill#1323

    Mill 0.9.6 failed to add BSP test via Intellij, which was implmented by @samvel1024 in JetBrains/intellij-scala#476

    [Trace - 04:06:30 AM] Received request 'buildTarget/scalaTestClasses - (3)'
    Params: {
      "targets": [
        {
          "uri": "file:///project/directory"
        }
      ],
      "originId": "5dcf406b-5e73-46db-919b-aecde0891332"
    }
    
    
    [Trace - 04:06:51 AM] Sending response 'buildTarget/scalaTestClasses - (3)'. Processing request took 20545ms
    Result: null

    However in https://build-server-protocol.github.io/docs/specification.html, I didn't see any definition of request buildTarget/scalaTestClasses
    But I do searched related request from https://github.com/build-server-protocol/build-server-protocol/blob/master/docs/extensions/scala.md
    Does Intellij BSP implements a out-of-date spec? or BSP from build-server-protocol.github.io is out-of-date, and mill didn't implement it.

    2 replies
    Question is, is build-server-protocol.github.io out-of-date?
    macdevign
    @macdevign

    HI, recently I'm interested in Learning about Scala 3, and I thought that Intellij Scala has one of best Scala IDE support, and hope to see it continue to be so. However there is some challenge in IDE integrating support for Scala 3 due to tasty format, and there are some remarks made by Pavel Fatin from Intellij Scala team, from https://youtrack.jetbrains.com/issue/SCL-19042

    Pavel Fatin's remark:

    So there's no way to read a .tasty file as raw data, only as a compiler tree (even if that's an implementation detail). This scheme is necessary and is originally intended for the Go To and Type Info actions (as a workaround), because .tasty files themselves don't contain all the required information, such as types of expressions of local definitions.

    Using that scheme for indexing, however, is problematic because:

    We have to bundle scala-compiler.jar, which is rather large.
    The scala-compiler.jar depends on a specific Scala version (more that the data in a .tasty file), while we may need to parse different versions.
    The compiler reads the data fully, whereas we don't need right-hand sides, private definitions, etc.
    Redundant transformations: "bytes -> compiler tree -> tasty extractors -> string", whereas we need "bytes -> string".
    More GC overhead (as we instantiate compiler trees in the same process).
    More JVM classes to load / JIT compile.
    The compiler indexes data during the reading, which we don't need (we build our own indexes).
    There's no way to distinguish between "just reading .tasty" and invoking some advanced compiler logic (e.g. for type inference).
    There's no way to read TASTy as a byte array, only as a file on disk, so we have to extract each .tasty file from a JAR during indexing.
    The compiler sometimes requires a full classpath (which we don't even have during indexing) and throws an exception otherwise (this might be a bug though).
    The TASTy Inspect API has bugs (because it's not actively used - the compiler accesses its trees directly). We report bugs but there are still plenty (you can see that in console during the indexing).
    The SourceCode printer has bugs - because it's build on top of the TASTy Inspect API and is used even less (mostly for debug output). For example - SCL-19039, SCL-19088, SCL-19089, SCL-19090, etc.

    For the purpose of indexing, it would be better to read .tasty files directly. Note that, we don't need to reimplement the extensive TASTy Reflect capabilities for that, we don't even need to read all the trees (such as right-hand sides). However, because .tasty files don't contain textual information, this would require some effort (particularly, to convert types), but it seems to be a reasonable and necessary task, which will make indexing simpler, more reliable, and more fast.
    //===========================================================
    I wonder if there is clear official direction to add tasty support into IDE , rather keep reinventing the wheel.

    cmhteixeira
    @cmhteixeira

    Hey there. I have a basic question which I sure will be very easy for you guys.
    What is the analogue of bloop for other languages that have a Language Server?

    In Scala, we have metals as the LSP, and bloop as the BSP, whereby metals directly uses bloop. But on my searches, I have found:

    1. The LSP protocol originated from microsoft in the context of vscode. (https://en.wikipedia.org/wiki/Language_Server_Protocol)
    2. Many other languages besides Scala have a LSP (https://microsoft.github.io/language-server-protocol/implementors/servers/)
    3. However, the BSP seems to be an initiate of the Scala community alone??? (https://build-server-protocol.github.io/)
    4. There doesn't seem to exist BSP implementations for other languages

    So that begs the question. How do the LSP implementations for other languages work? Do they bundle everything together? As in, do they do the 2 tasks which in the Scala community is separated between Metals and Bloop?

    Ólafur Páll Geirsson
    @olafurpg
    1. There’s a BSP server implementation for Bazel that supports Scala, Java and Kotlin C++ in the works https://blog.jetbrains.com/scala/2021/08/24/bsp-support-for-bazel/
    (That was a reply to point 4)
    LSP servers for other languages typically bundle the logic to integrate with build tools
    Metals delegates that logic to a separate process
    through a documented protocol so any build tool can integrate
    I don’t know the name of Bloop equivalent tools in other ecosystems but they probably exist. Eclipse and IntelliJ both have their own build systems, for example
    cmhteixeira
    @cmhteixeira
    Thanks @olafurpg . From the outside, having the 2 composable protocols does seem to make more sense.
    Question answered
    Tobias Roeser
    @lefou
    I saw that there is a bsp4s package, which seem to contain a scala API for BSP. From a distance it looks more appropriate to use it from Scala, also as it looks like better structured (e.g. separation of buildTraget command from build or workspace commands). Is there some recomendation to use it over bsp4j? Is there documentation? To me, it's not obvious how to set it up.
    Ólafur Páll Geirsson
    @olafurpg
    @lefou I recommend using bsp4j
    that's what Metals and IntelliJ use
    it's quite complicated to wire everything together the first time, but once it's setup then it usually continues working.
    most of the complexity is in implementing the build server/client logic, not the JSON-RPC bindings
    Tobias Roeser
    @lefou
    @olafurpg Thanks. Can you tell why bsp4s exists and has a test suite that ensures compatibility with bsp4j? What I like about it more than bsp4j is its more modular approach. We currently use bsp4j in mill, but it forces us to implement all aspects in the same class. The ability to provide additional endpoints e.g. by mill plugins sounds nice, e.g. Kotlin support is not built-in in mill, but there is a mill-kotlin plugin. There is currently no nice way to let that work in a modular way with bsp4j. (Maybe Cpp is a better example as there is already a CppBuildServer, but we currently have no mill-cpp plugin)
    Tobias Roeser
    @lefou
    Is it ok to implement a reload workspace request with a bsp server shutdown? Will the client automatically restart the bsp server?
    Tobias Roeser
    @lefou
    https://build-server-protocol.github.io/docs/extensions/scala.html#scala-test-classes-request references an origin field, which is not present in ScalaTestClassesResult. Is this an oversight or is origin-mapping automatically applied ?
    Ólafur Páll Geirsson
    @olafurpg

    it forces us to implement all aspects in the same class

    @lefou bsp4j allows you to define custom endpoints and you don't have to implement all methods

    We don't extend the LanguageServer superclass
    bsp4s exists because bloop was using it and the migration to bsp4j was not worth it
    Ólafur Páll Geirsson
    @olafurpg
    BTW, I implemented the original version of the underlying JSON-RPC engine that bsp4s uses, including the loop that sends requests, notifications and implements cancelation. I agree it has more modular approach than bsp4j :)
    Tobias Roeser
    @lefou
    @olafurpg Thanks for all these pointer! And the infos. Much appreciated.
    Justin Kaeser
    @jastice
    @lefou To add to that, we recommend bsp4j by default because it is much lighter on the dependencies, which is at least a little relevant for software distributed to many users. IntelliJ-Scala originally used bsp4s but it added too much weight to the plugin archive, so we migrated to bsp4j
    Tobias Roeser
    @lefou
    @jastice Thanks for pointing that out.