Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 22 2015 11:10
    japgolly commented #2066
  • Jun 22 2015 08:25
    keepscoding commented #2044
  • Jun 21 2015 03:24
    xerial commented #157
  • Jun 21 2015 00:10
    eed3si9n unlabeled #2057
  • Jun 21 2015 00:10

    eed3si9n on 0.13

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 3 more (compare)

  • Jun 21 2015 00:10
    eed3si9n closed #2057
  • Jun 21 2015 00:10

    eed3si9n on fixbuild

    (compare)

  • Jun 20 2015 18:42
    eed3si9n synchronize #2057
  • Jun 20 2015 18:42

    eed3si9n on fixbuild

    Fix typo (compare)

  • Jun 20 2015 18:23

    eed3si9n on fixbuild

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 1 more (compare)

  • Jun 20 2015 18:23
    eed3si9n synchronize #2057
  • Jun 20 2015 14:59

    eed3si9n on scalaversionbump

    (compare)

  • Jun 20 2015 14:59

    eed3si9n on 0.13

    Bumping up Scala version to 2.1… Try to keep bincompat Fixes #1666 and 1 more (compare)

  • Jun 20 2015 14:59
    eed3si9n unlabeled #2068
  • Jun 20 2015 14:59
    eed3si9n closed #2068
  • Jun 20 2015 14:59
    eed3si9n closed #1666
  • Jun 20 2015 14:57
    eed3si9n commented #2068
  • Jun 20 2015 12:55
    dwijnand commented #2068
  • Jun 20 2015 04:51
    eed3si9n synchronize #2068
  • Jun 20 2015 04:51

    eed3si9n on scalaversionbump

    Fixes #1666 (compare)

Adelbert Chang
@adelbertc
@jmcardon i think sbt-onejar is no longer maintained is it? sbt-assembly seems to be the way to go. also less classloader voodoo
Sukant Hajra
@shajra
I just looked at the sbt-coursier project. Maybe I'm a bit dense, but which problem does it solve that people find most useful? Resolutions taking a while?
Ghost
@ghost~540393fe163965c9bc2018ce
is there an option that when a macro is changed, all downstream code is marked dirty?
it's really hard to find it given that most google for "sbt macro incremental compiler" give completely the wrong thing
Jorge
@jvican
yes, there's a way.
and it's been proven to work well. i would like to try to merge it in the future inside Zinc (in a minor release, after sbt 1.0) @fommil
have a look at Martin Duhem's thesis on incremental macro compilation https://infoscience.epfl.ch/record/204855/files/MacrosInSbtProblemSolved.pdf
Thomas Sutton
@thsutton
@shajra Being faster and not having the ridiculous Ivy lock are the two reasons that leap to mind. I've found the concurrent downloading is especially pleasing when I'm stuck behind particularly obnoxious corporate proxies with rate limiting, etc.
Sukant Hajra
@shajra
I see... I'm not having incredible problems with this right now, but I'll keep it in mind.
Sukant Hajra
@shajra
Is there a good SBT API for comparing versions scalaVersion, which is just a String?
CrossVersion, I see it now.
Sukant Hajra
@shajra
So I tried to change a setting based on scalaVersion.value, and was crossing my fingers that this would work with cross-compiling, but that didn't work. I feel when the +/++ commands are run, the settings don't get re-evaluated.
Ghost
@ghost~540393fe163965c9bc2018ce
@jvican I mean a brute force recompile the world flag, I'm sure I seen it somewhere.
Dale Wijnand
@dwijnand
that's the out the box behaviour
if you don't opt-out it comes with a big annoying message telling you exactly everything it's undone because you're a (dirty) macro user.
@shajra yeah +/++ create session settings, that are used to re-evaluate and re-define all the setting values. If you can share what you're seeing we might be able to help you out.
And your sbt-doge question, did you mean in your project or are you talking about whether sbt-doge should be changed?
Ghost
@ghost~540393fe163965c9bc2018ce
@dwijnand hmm, maybe it's broken for scala.meta
or, rather, doesn't support scala.meta
I was making changes to the freestyle @free macro, and nothing downstream was getting recompiled
I'd have been happy with everything being marked dirty
Dale Wijnand
@dwijnand
mmm could be
Sukant Hajra
@shajra
@dwijnand no, I mean enabling it for all projects internally. It seems to work fine.
Dale Wijnand
@dwijnand
yeah it's fine
Dale Wijnand
@dwijnand
:+1:
Jose C
@jmcardon
As we spoke I opened the gates to discussion on this hopefully reasonably
I sincerely believe this would lead to a positive change long term
less docs to maintain
and more convergence from the entire community
Dale Wijnand
@dwijnand
You propose deprecating a style that I don't see too common in the (OSS) wild, so provided we cater for those that are using that style (deprecation warnings, opt-in/opt-out, auto-rewrite) I think it's very achievable.
Jose C
@jmcardon
I do believe play framework is using the recursive sbt in folders style as an example
Jorge
@jvican
@jmcardon I don't understand what you're proposing
hasn't Build.scala disappeared in sbt 1.0?
Jose C
@jmcardon
@jvican removing recursive build.sbt definitions
wherein you have to recurse into folders
Jorge
@jvican
No way, that's impossible
First, that's not a different style, it's a feature
Second, that's the foundation for the way plugins work
Jose C
@jmcardon
I mean... different build.sbt files in different folders
not so much the plugins
Jorge
@jvican
Ah, so then I wouldn't call it recursive build definition
Jose C
@jmcardon
my bad on the wording then
This is partly what causes a rift so hard when having any discussions as to how to do things in sbt. Essentially supporting many different ways of doing the same thing
Jorge
@jvican
No worries, that was a misunderstanding
So I think that's very contentious, because what do you do with multiple .sbt files in a directory?
Dale Wijnand
@dwijnand
You keep those, imo.
Being able to define a gitignored local.sbt is useful.