by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Pavel Fatin
    @pavelfatin

    @unoexperto

    Hey guys. I'm trying dotty-example-project with new IDEA pluging and not sure if it's plugin or my code that is problem.
    In ContextQueries.scala lines 42,43 code doesn't see implicit executing context.
    Importing scala.concurrent.ExecutionContext.global in scope doesn't help.
    How is it supposed to work now ?

    (It's probably reasonable to use the "intellij-scala" Gitter rather than the "dotty" one)

    "doesn't see implicit executing context" - i.e. there's red code or...?

    ruslan
    @unoexperto
    @pavelfatin I figured it out. What happened is moving files to new package silently removed import ExecutionContext.Implicits.global line in ContextQueries class.
    @pavelfatin Perhaps IDEA should not modify imports when moving classes from one package to another ?
    Pavel Fatin
    @pavelfatin
    Definitely. Thanks for the info!
    Hanns Holger Rutz
    @Sciss
    I usually leave the default of IntelliJ watching build.sbt and asking me if I want to import the changes (so this is manual confirmation not auto-import). I have one project though, where I must have checked some "never" box, and so it doesn't seem to watch build.sbt (so I have to open sbt settingsand refresh explicitly every time); I searched through the preferences and project settings, and could not spot where this setting is saved. Can I reset the default behaviour without having to wipe the .idea directory?
    OlegYch
    @OlegYch
    i think this is the setting http://prntscr.com/rezt7e
    oh you mean i doesn't even notice the changes?
    sounds like a bug or non-standard project
    Hanns Holger Rutz
    @Sciss
    Yes, it doesn't notice changes. Even if I select auto-import. By the way, I cannot find the action in your screenshot, seems missing in my version (using latest stable plugin)
    build.sbt looks not unlike all my others. I will try to wipe .idea and see if it helps
    Yes, now it seems to work again
    nafg
    @nafg
    Lately, importing SBT builds fails if "download SBT sources" is checked
    [error] (updateSbtClassifiers) lmcoursier.internal.shaded.coursier.error.FetchError$DownloadingArtifacts: Error fetching artifacts:
    [error] https://repo1.maven.org/maven2/org/webjars/envjs/1.2/envjs-1.2-sources.jar: not found: https://repo1.maven.org/maven2/org/webjars/envjs/1.2/envjs-1.2-sources.jar
    [error] https://repo1.maven.org/maven2/com/google/javascript/closure-compiler-externs/v20190513/closure-compiler-externs-v20190513-sources.jar: not found: https://repo1.maven.org/maven2/com/google/javascript/closure-compiler-externs/v20190513/closure-compiler-externs-v20190513-sources.jar
    This is true regardless of sbt shell setting
    Justin Kaeser
    @jastice
    @nafg which sbt version?
    nafg
    @nafg
    @jastice I guess ~latest, 1.3.8
    Justin Kaeser
    @jastice
    does it fail lately with change in sbt version, in scala plugin version, or change in dependencies?
    OlegYch
    @OlegYch
    Justin Kaeser
    @jastice
    thanks
    nafg
    @nafg
    @jastice maybe it's possible that if updateSbtClassifiers fails, it shouldn't cause it to lose everything else
    The same thing with project sources
    Isolate failures so they don't cascade, so to speak
    Justin Kaeser
    @jastice
    yeah not entirely trivial in the current implementation I think since it's just all based off the sbt task graph
    OlegYch
    @OlegYch
    nafg: disable 'get sbt sources'
    or exclude those dependencies
    or fix coursier
    or disable it
    nafg
    @nafg
    @jastice how does sbt communicate with intellij these days, is it writing an xml file to a known location?
    yeah it says Writing structure to /tmp/sbt-structure.xml...
    @jastice why not break it into separate commands and write each to a separate file, then don't assume if sbt failed everything is bad; take whatever xml files exist
    So there could be one xml file for each of {project,sbt}-{jars,sources}
    that way if any of them fail, the others, or at least those that ran first, are still there
    Justin Kaeser
    @jastice
    @nafg we might do that but it doesn't feel worth it to mitigate bugs limited to specific sbt versions tbh
    nafg
    @nafg
    @jastice it's not, often I might have some plugin or library dependency that depends on some artifact that for whatever reason doesn't publish a source jar
    Justin Kaeser
    @jastice
    yes, but only specific sbt versions cause this to be an error
    nafg
    @nafg
    I see
    Justin Kaeser
    @jastice
    so if you set project to 1.3.6 and disable automatic sbt upgrading it should work
    nafg
    @nafg
    what is automatic sbt upgrading
    Justin Kaeser
    @jastice
    image.png
    "allow overriding sbt version"
    nafg
    @nafg
    What does that do exactly?
    Justin Kaeser
    @jastice
    it upgrades the project-configured sbt version to use latest known by scala plugin when starting sbt shell
    nafg
    @nafg
    ah
    Maybe you should change the behavior to "forces to use sbt version latest supported by scala plugin" ;)
    So downgrade if necessary to 1.3.6 without requiring me to edit project/build.properties
    OlegYch
    @OlegYch
    or any other piece of software for that matter
    nafg
    @nafg
    ?
    OlegYch
    @OlegYch
    just saying 'override sbt version' should be removed
    Justin Kaeser
    @jastice
    the latest "supported" version is not necessarily known. We assume the latest available version is supported and usually has the least bugs. But every so often there's regressions 🤷‍♂️
    Arnaud Esteve
    @aesteve