Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 16 00:25
    lemastero commented #29
  • Oct 16 00:25
    lemastero commented #29
  • Sep 28 17:41
    lemastero commented #172
  • Sep 28 17:41
    lemastero commented #172
  • Sep 27 14:44
    vigoo opened #270
  • Sep 27 14:44
    vigoo opened #270
  • Sep 27 13:59
    lemastero commented #113
  • Sep 27 13:59
    lemastero commented #113
  • Sep 27 12:29

    joroKr21 on master

    Update dependencies (#269) * U… (compare)

  • Sep 27 12:29

    joroKr21 on master

    Update dependencies (#269) * U… (compare)

  • Sep 27 12:29
    joroKr21 closed #269
  • Sep 27 12:29
    joroKr21 closed #269
  • Sep 27 12:25
    lemastero commented #269
  • Sep 27 12:25
    lemastero commented #269
  • Sep 27 12:20
    lemastero synchronize #269
  • Sep 27 12:20
    lemastero synchronize #269
  • Sep 27 11:40
    joroKr21 commented #269
  • Sep 27 11:40
    joroKr21 commented #269
  • Sep 27 11:33
    lemastero opened #269
  • Sep 27 11:33
    lemastero opened #269
nafg
@nafg
How can you choose to not implement a typeclass for a given case class?
Dmytro Mitin
@DmytroMitin
@nafg
The easiest is good old trick with ambiguity
case class A(i: Int)
implicit val intShow: Show[Int] = _.toString

@implicitAmbiguous("could not find implicit value of type Show[A]")
implicit val ambigA: Show[A] = null
implicit val ambigA1: Show[A] = null

import ShowDerivation.gen
//implicitly[Show[A]] // doesn't compile, Error:could not find implicit value of type Show[A]
nafg
@nafg
@DmytroMitin I was thinking of something more general, for instance only for cases classes of arity 1
Dmytro Mitin
@DmytroMitin
@nafg It's easy to do with Shapeless. I'm afraid with Magnolia you'll have to write a macro for that. In Shapeless macros are split into comparatively small portions (well, some macros are) which are wrapped with custom type classes and data types so you can play with them independently from each other. But Magnolia is more or less a big single macro so you can do easily standard things using API provided but it's harder to do tiny tuning. The advantage of Magnolia is time of compiling.
Dmytro Mitin
@DmytroMitin
@nafg
object ShowDerivation {
  ...

  implicit def gen[T]: Show[T] = macro genImpl[T]

  def genImpl[T: c.WeakTypeTag](c: whitebox.Context): c.Tree = {
    import c.universe._

    val tpe = weakTypeOf[T]

    val primitives = Set(typeOf[Double],
      typeOf[Float],
      typeOf[Short],
      typeOf[Byte],
      typeOf[Int],
      typeOf[Long],
      typeOf[Char],
      typeOf[Boolean],
      typeOf[Unit])

    val isValueClass = tpe <:< typeOf[AnyVal] && !primitives.exists(_ =:= tpe)

    val caseClassParameters = weakTypeOf[T].decls.sorted.collect(
      if (isValueClass) { case p: TermSymbol if p.isParamAccessor && p.isMethod => p }
      else { case p: TermSymbol if p.isCaseAccessor && !p.isMethod => p }
    )

    if (caseClassParameters.length == 1)
      Magnolia.gen[T](c)
    else c.abort(c.enclosingPosition, s"$tpe must have single parameter")
  }
}

case class A(i: Int)
case class B(i: Int, s: String)
case class C()
case object D
implicit val intShow: Show[Int] = _.toString
implicit val strShow: Show[String] = identity

import ShowDerivation.gen

implicitly[Show[A]] // compiles
//  implicitly[Show[B]] // doesn't compile
//  implicitly[Show[C]] // doesn't compile
//  implicitly[Show[D.type]] // doesn't compile
Dmytro Mitin
@DmytroMitin
@nafg In Shapeless it would be enough
object Show {
  // instances for HLists

  implicit def generic[T <: Product, L <: HList](implicit
                                                 gen: LabelledGeneric.Aux[T, L],
                                                 show: Show[L],
                                                 ev: Length.Aux[L, _1] // the only modification
                                                ): Show[T] =
    t => show.show(gen.to(t))
}
nafg
@nafg
@DmytroMitin neat!
Guillaume Poirier
@gpoirier
I'm using Scio, which is using Magnolia for its Coder type class. I moved our ADT / case classed inside a trait that's mixed in a package object. After doing that, Magnolia seems incapable to derive correctly the Coproduct, I get an error that one of the child type of the ADT isn't a subtype of its parent type. Is it a known issue?
Tim Pigden
@TimPigden
Hi, I've just updated to 0.17.0 - now I'm getting a "Method too large" from scalac. Anyone else had the same problem?
Tim Pigden
@TimPigden
never mind, workaround was trivial and it was the "test all the implicit derived parsers" test, so I doubt I'll get much larger
but clearly 0.17 is generating bigger something
Georgi Krastev
@joroKr21
yes, more features = more code
I think it was the type annotations
caeus
@caeus
@propensive How are you? I'm trying to build a package object that provides derivations for two (or more) different typeclasses. Currently, is that possible?
Daniel Vigovszky
@vigoo
Hi all, just wanted to check in and mention that a few days ago I opened a PR with a feature request and a proposed possible solution (propensive/magnolia#270). Whenever you have time, I'd appreciate feedback on it
Tim Pigden
@TimPigden
Hi. I'm looking at scala 3 migration of our code base. We've got 6 different magnolia based objects. We don't need to support scala 2 and scala 3 - we'll just move the whole code base. So the question is - is magnolia still a relevant solution given the dotty-based typeclass derivation? Has anyone taken a magnolia example and tried to port it using just scala 3 standard features?
Denis Mikhaylov
@notxcain
Hi! This must've been asked a lot, but I can't find any :) I have a catch all implicit instance, how do I instruct magnolia to try derivation first and only then fallback to catch all? Lower priority implicit trick doesn't work.
I own the typeclass
So I tried object TC extends MagnoliaDerivation with FallbackInstances but when I call TC[SomeSealedTrait] it looks like magnolia uses FallbackInstances for cases
Denis Mikhaylov
@notxcain
So I see this one is still open propensive/magnolia#58
That's my case
Denis Mikhaylov
@notxcain
Oh, I see :point_up: March 21, 2018 12:44 AM
Denis Mikhaylov
@notxcain
Are there any workarounds?
Kasper Kondzielski
@ghostbuster91
@notxcain I didn't get that: So I tried object TC extends MagnoliaDerivation with FallbackInstances but when I call TC[SomeSealedTrait] it looks like magnolia uses FallbackInstances for cases
Isn't that what you wanted?
Denis Mikhaylov
@notxcain
By cases I mean for case classes and objects of sealed trait.
Kasper Kondzielski
@ghostbuster91
Ok, but isn't that what you wanted?
Denis Mikhaylov
@notxcain

So given

sealed trait Root
case class Foo(a: Int) extends Root
case class Bar(s: String) extends Root

when I summon typeclass it uses fallback instance for Bar and Foo not for Int and String

Kasper Kondzielski
@ghostbuster91
did you mark your fallback method as implicit?
Denis Mikhaylov
@notxcain
sure
Kasper Kondzielski
@ghostbuster91
that's the problem
fallback method is being invoked by magnolia not by the compiler
so it can't be implicit
Denis Mikhaylov
@notxcain
wow, let me check
Anton Sviridov
@keynmol

fallback method is being invoked by magnolia

wow, I had no idea this was the case https://github.com/propensive/magnolia/blob/master/core/shared/src/main/scala/magnolia.scala#L619

Denis Mikhaylov
@notxcain
Ah, it should be named fallback
@ghostbuster91 thank you so much. :pray: I'm getting StackOverflow on recursive type for now. But it must be related to eagerness of construction.
Denis Mikhaylov
@notxcain
Is it documented anywhere?
Kasper Kondzielski
@ghostbuster91
It wasn't when I was looking for it
Don't know if there were any changes to the documentation since then
Denis Mikhaylov
@notxcain
Am I correct that 0.16.0 and 0.17.0 are not binary compatible?
Georgi Krastev
@joroKr21
Yes, they are not
Andy Hamon
@andrewhamon
image.png
Hey all :wave: I noticed that if I have magnolia as a dependency to my project (but without importing or using it in any way), I can no longer fire up a scala repl. I get Exception in thread "main" java.lang.VerifyError: class scala.tools.nsc.Global overrides final method scala.reflect.internal.SymbolTable.phaseWithId()[Lscala/reflect/internal/Phase; (see screenshot above)
I was wondering if anyone has ever seen anything similar? FWIW, I am using bazel + rules_scala to build my project rather than sbt
Also I got here because I noticed this issue when trying to use Caliban but think I narrowed the issue down to magnolia and/or mercator which caliban takes depndencies on (issue presents if either is a dependency to the project)
Georgi Krastev
@joroKr21
Do you have scala-reflect as a provided dependency? We don't have it as a transitive dependency because we don't need it at runtime but unfortunately that means users have to declare it as provided.
Andy Hamon
@andrewhamon

that means users have to declare it as provided.

I'm not super sure what you mean by that (again, might be because I'm using bazel rather than sbt) but I tried adding scala-reflect as a runtime dependency, no luck

Georgi Krastev
@joroKr21
Ok that was the only thing I would suspect, so I don't know. By provided I mean that in sbt you can add % "provided" and the dependency will not be added to the jar or as a transitive dependency. Idk how it works in bazel.