Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 19:25
    som-snytt commented #8577
  • 19:23
    scala-jenkins milestoned #8577
  • 19:23
    som-snytt opened #8577
  • 19:00
    SethTisue demilestoned #8555
  • 18:50
    alissapaluska opened #1598
  • 17:55
    SethTisue commented #11821
  • 17:54
    SethTisue milestoned #11821
  • 17:54
    SethTisue labeled #11821
  • 17:54
    SethTisue labeled #11821
  • 17:54
    SethTisue labeled #11821
  • 17:54
    SethTisue commented #11821
  • 16:33
    som-snytt commented #11818
  • 16:17

    szeiger on 2.12.x

    [nomerge] Avoid allocations of … use existing ClassTag review comments order matches i… and 2 more (compare)

  • 16:17
    szeiger closed #8467
  • 15:43
    SethTisue closed #10434
  • 15:43
    SethTisue labeled #10434
  • 15:43
    SethTisue commented #11818
  • 15:42
    SethTisue labeled #11819
  • 15:41
    SethTisue commented #1594
  • 14:46
    som-snytt closed #8571
Paul S.
@pshirshov
And lower-bounds may happen
Guillaume Martres
@smarter
disambiguate ?
Paul S.
@pshirshov
It's a library, a module system
So, in case I have λ %0, %1 → Map[%0, %1]
And apply it to (Nothing, Nothing)
I wouldn't be able to understand which Nothing is which in Map[Nothing, Nothing]
Actually this is another unspecified behaviour: def materialize1[T[_]]: LightTypeTag = macro makeTag[T[Nothing]]
Fortunately it works :)
Kai
@neko-kai
@pshirshov

I wouldn't be able to understand which Nothing is which in Map[Nothing, Nothing]

I had the same issue in TagMacro, which led to TagKK[F[_, _]] = HKTag[{ type Arg[A, B] = F[A, B] }] encoding. There’s code there that manufactures new type parameters to create the Arg type alias, i guess it may be reused

Kai
@neko-kai
But it's still a huge amount of code to write to apply types when you only need to compare type constructors
Georgi Krastev
@joroKr21
What exactly are you trying to achieve?
Andriy Plokhotnyuk
@plokhotnyuk
Got a strange MiMa checking error after switching to Scala 2.12.9 as shown bellow... is it a known issue or should be reported?
[error]  * method this()Unit in class com.github.plokhotnyuk.rtree2d.core.RTreeNil has a different signature in current version, where it is [N/A] rather than ()V
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("com.github.plokhotnyuk.rtree2d.core.RTreeNil.this")
[error]  * method this(Float,Int)Unit in class com.github.plokhotnyuk.rtree2d.core.RTreeEntryBinaryHeap has a different signature in current version, where it is [N/A] rather than (FI)V
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("com.github.plokhotnyuk.rtree2d.core.RTreeEntryBinaryHeap.this")
[error]  * method this()Unit in class com.github.plokhotnyuk.rtree2d.core.RTreeNil has a different signature in other version, where it is ()V rather than [N/A]
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("com.github.plokhotnyuk.rtree2d.core.RTreeNil.this")
[error]  * method this(Float,Int)Unit in class com.github.plokhotnyuk.rtree2d.core.RTreeEntryBinaryHeap has a different signature in other version, where it is (FI)V rather than [N/A]
[error]    filter with: ProblemFilters.exclude[IncompatibleSignatureProblem]("com.github.plokhotnyuk.rtree2d.core.RTreeEntryBinaryHeap.this")
Seth Tisue
@SethTisue
@plokhotnyuk what MiMa version? see e.g. lightbend/mima#361 and linked tickets/PRs
Andriy Plokhotnyuk
@plokhotnyuk
@SethTisue thanks! it is exactly my case, the version of MiMa is same
Kai
@neko-kai
@joroKr21 Recreate runtime TypeTags for dotty with =:= and <:< since it won't have them. Not trying, but did.
Also for Scala.js. These generated tags are immutable and do not have concurrency issues
Kai
@neko-kai
Guillaume Martres
@smarter
Impressive, but also :scream: :scream: :scream:
Andriy Plokhotnyuk
@plokhotnyuk
TypeTag machinery should be used wisely to avoid unacceptable overhead in run-time like here: pathikrit/dijon#30
Kai
@neko-kai
Exactly why we made our own ;) no more 500ms startup penalty for tests just for scala-reflect universe to start...
Andriy Plokhotnyuk
@plokhotnyuk
@kaishh indeed, great work! will it be ported to Dotty?
Andriy Plokhotnyuk
@plokhotnyuk
Georgi Krastev
@joroKr21
Yikes but the full subtyping algorithm is extremely complex
And also carefull
Georgi Krastev
@joroKr21
But I guess the question for me is why do you even need subtype checks at runtime? And even then why concurrently?
Paul S.
@pshirshov
@joroKr21 : okay, let me explain
Kai
@neko-kai
@joroKr21 It's not full, we admit some false positives e.g. in F-bounds. I've detailed the usage here - https://gitter.im/lampepfl/dotty?at=5d1f6f26e8278223710ff9c5 . We need type equality for distage, a runtime DI framework, we need subtype checks for a few specific features there, crucially HKT-subtype checks for effect-bindings.
Paul S.
@pshirshov
So, we have a "solving module system" with garbage collection. You define what do you want to have in your app, then we decided how to produce your instances - excluding unrequired instances and solving conflicts
This may happen in runtime and compile time
So, you may call it "dependency injection" also, but it significantly differs from a typical DI framework
Kai
@neko-kai
We need to do it concurrently because DI runs to create fixtures for tests. Obviously the tests run in parallel
Paul S.
@pshirshov
We have a useful extension - once the graph is built we may scan it and populate a set with all the instances of type T (like hooks, handlers, etc). So, that's the primary reason to have subtype checks
Regarding concurrent execution
Yes, we have huge test suites
And we run them in parallel
Currently we use scalatest and it doesn't allow to have global knowledge and build all the graphs ahead of time in a single thread
So we need to work with reflection concurrently. Moreover, it happens during initialization and even if we synchronize on everything - <:< and =:= still may fail
You may fine more if you read my comments in this topic: https://github.com/scala/scala-dev/issues/641#issuecomment-510855889
@plokhotnyuk : yup, I'll update the post, it's just a draft at this point
Georgi Krastev
@joroKr21
Oh ok thanks for explaining. I don't think I can understand the use case atm (in general I don't understand DI frameworks). But I will probably take a look later. Also I remember using reflection in a compile time vs runtime agnostic way but I don't remember if we were running tests in parallel (you can turn it off I think) so I have to check that
Paul S.
@pshirshov
It's not a DI framework
It's a solver for modules
Georgi Krastev
@joroKr21
I'm not sure what's the difference
Kai
@neko-kai
The difference is stigma from scalaz-type people...
Though I wouldn’t pay much attention to it
Btw the runtime universe is just lazy val universe: api.JavaUniverse = new runtime.JavaUniverse