Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 17 14:40
    joroKr21 commented #175
  • Sep 17 14:40
    joroKr21 commented #175
  • Sep 17 14:03
    yanns commented #175
  • Sep 17 14:03
    yanns commented #175
  • Sep 17 13:13
    yanns closed #175
  • Sep 17 13:13
    yanns commented #175
  • Sep 17 13:13
    yanns commented #175
  • Sep 17 13:13
    yanns closed #175
  • Sep 17 13:04
    yanns commented #175
  • Sep 17 13:04
    yanns commented #175
  • Sep 17 09:36
    joroKr21 commented #175
  • Sep 17 09:36
    joroKr21 commented #175
  • Sep 17 09:24
    yanns opened #175
  • Sep 17 09:24
    yanns opened #175
  • Sep 11 07:26
    ghostdogpr commented #154
  • Sep 11 07:26
    ghostdogpr commented #154
  • Sep 02 09:40
    gaoxinyang commented #172
  • Sep 02 09:40
    gaoxinyang commented #172
  • Aug 29 22:03
    kubukoz commented #166
  • Aug 29 22:03
    kubukoz commented #166
Matt Searle
@ChocPanda
I fixed the above using type ascription
Matt Searle
@ChocPanda
Hey @propensive,
I created https://github.com/ChocPanda/argonaut-magnolia and https://github.com/ChocPanda/scala check-magnolia. Could you help me out with some advice on testing?
Jon Pretty
@propensive
Hi @ChocPanda, thanks for your work on these. I think they could potentially be very popular additions!
I'm not sure why the type ascription is necessary, without taking a closer look (which I haven't had a chance to do in a couple of months now...). constructMonadic is rather new, anyway, and relies upon Mercator to provide Monadic typeclasses. So it's seen much less testing than other things.
If you could raise an issue in the issue tracker, that will ensure that I, or someone else, gets to see it. You (and other people in this channel) may have noticed that the issues have been piling up for Magnolia without much triage. As there's only one of me, and I'm almost entirely working on Fury, Magnolia is currently missing out on some love, but I have just announced a partnership to work with Virtus Lab, and I'll be talking to them next week to see if they can help with the maintenance of Magnolia.
Jon Pretty
@propensive
As for testing, there are a few different dimensions to it. Off the top of my head, we need to test that:
  1. No typeclass derivation causes the compiler to crash. There are open issues where it does. This is general Magnolia testing.
  2. Every typeclass definition derives. This depends on the implementation of combine and dispatch.
  3. Magnolia will find the right typeclasses with the right priorities (without ambiguities) as necessary. This is usually specific to the ADT being derived and the scope in which derivation is being done.
There are some tests in the tests submodule which you can run using tests/run in sbt which run on various examples. If you want to use these as test cases, you might be able to copy/paste some of them and just change the typeclass being derived to the one you've written... maybe with a few additional tweaks.
Matt Searle
@ChocPanda
Thanks @propensive I will check for duplicates and raise the issue, if be interested to take a look myself into why this might be the case.
I also appreciate the advice on what to test, I may come back with more questions but thanks for the help
Mark de Jong
@Fristi
import magnolia.{CaseClass, Magnolia, SealedTrait}
import org.specs2.matcher.describe._

import scala.language.experimental.macros

object DiffableDerivation {

  /** binds the Magnolia macro to this derivation object */
  implicit def genDiffable[T]: Diffable[T] = macro Magnolia.gen[T]

  /** type constructor for new instances of the typeclass */
  type Typeclass[T] = Diffable[T]

  def combine[T](ctx: CaseClass[Diffable, T]): Diffable[T] =
    new Diffable[T] {

      override def diff(actual: T, expected: T): ComparisonResult = {
        val res = ctx.parameters.map { param =>
          val result = param.typeclass.diff(param.dereference(actual), param.dereference(expected))
          CaseClassPropertyComparison(param.label, result, result.identical)
        }

        if (res.forall(_.identical)) CaseClassIdentical(ctx.typeName.short)
        else CaseClassDifferent(ctx.typeName.short, res)
      }
    }
  def dispatch[T](ctx: SealedTrait[Diffable, T]): Diffable[T] = new Diffable[T] {
    override def diff(actual: T, expected: T): ComparisonResult = ctx.dispatch(actual) { sub =>
      if (sub.cast.isDefinedAt(expected)) sub.typeclass.diff(sub.cast(actual), sub.cast(expected))
      else OtherDifferent(actual, expected)
    }

  }
}
Magnolia derivation for Diffable for specs2, first stab

Type class:

trait Diffable[-T] {
  def diff(actual: T, expected: T): ComparisonResult
}

It falls back to https://github.com/etorreborre/specs2/blob/master/matcher/shared/src/main/scala/org/specs2/matcher/describe/Diffables.scala#L215 alot

Any comments on my impl and how could I debug why it it's falling back alot ?
Mark de Jong
@Fristi

A little spec illustrates the problem

package io.dhlparcel.courier.util
import org.specs2.matcher.Matchers
import org.specs2.mutable.Specification
import DiffableDerivation._
import org.specs2.matcher.describe._

import scala.collection.mutable.ArrayBuffer

class DiffableDerivationSpec extends Specification with Matchers {

  "Diffable type class derivation" >> {

    "should derive correctly for product type" >> {
      "identical" >> {
        genDiffable[Address].diff(Address("a", 2), Address("a", 2)) must beEqualTo(CaseClassIdentical("Address"))
      }
      "different" >> {
        genDiffable[Address].diff(Address("a", 2), Address("a", 4)) must beEqualTo(CaseClassDifferent("Address",ArrayBuffer(CaseClassPropertyComparison("street",PrimitiveIdentical("a"),true), CaseClassPropertyComparison("houseNumber",PrimitiveDifference(2,4),false))))
      }
    }

    "should derive correctly for nested types" >> {
      "identical" >> {
        genDiffable[Person].diff(Person("Mark", 1337, Address("a", 2)), Person("Mark", 1337, Address("a", 2))) must beEqualTo(CaseClassIdentical("Person"))
      }
      "different" >> {
        genDiffable[Person].diff(Person("Mark", 1337, Address("a", 2)), Person("Mark", 1338, Address("a", 3))) must beEqualTo(
          CaseClassDifferent("Person",
            ArrayBuffer(
              CaseClassPropertyComparison("name",PrimitiveIdentical("Mark"),true),
              CaseClassPropertyComparison("age",PrimitiveDifference(1337,1338),false),
              CaseClassPropertyComparison("address", CaseClassDifferent("Address",
                ArrayBuffer(
                  CaseClassPropertyComparison("street",PrimitiveIdentical("a"),true),
                  CaseClassPropertyComparison("houseNumber",PrimitiveDifference(2,3),false)
                )), false
              )
            )))
      }
    }

  }

}

case class Person(name: String, age: Int, address: Address)
case class Address(street: String, houseNumber: Int)

It fails on the last test:

ClassDifferent(Person,ArrayBuffer(CaseClassPropertyComparison(name,PrimitiveIdentical(Mark),true), CaseClassPropertyComparison(age,PrimitiveDifference(1337,1338),false), CaseClassPropertyComparison(address,CaseClassDifferent(Address,ArrayBuffer(CaseClassPropertyComparison(street,PrimitiveIdentical(a),true), CaseClassPropertyComparison(houseNumber,PrimitiveDifference(2,4),false))),false)))
Expected :CaseClassDifferent(Person,ArrayBuffer(CaseClassPropertyComparison(name,PrimitiveIdentical(Mark),true), CaseClassPropertyComparison(age,PrimitiveDifference(1337,1338),false), CaseClassPropertyComparison(address,CaseClassDifferent(Address,ArrayBuffer(CaseClassPropertyComparison(street,PrimitiveIdentical(a),true), CaseClassPropertyComparison(houseNumber,PrimitiveDifference(2,4),false))),false)))
Actual   :CaseClassDifferent(Person,ArrayBuffer(CaseClassPropertyComparison(name,PrimitiveIdentical(Mark),true), CaseClassPropertyComparison(age,PrimitiveDifference(1337,1338),false), CaseClassPropertyComparison(address,OtherDifferent(Address(a,2),Address(a,3)),false)))
The implicit resolution of the FallbackDiffable seems to take precendence
Andrew Martin
@andrewsmartin
hi, i’m a new magnolia user so apologies if this is a stupid question, but is it possible to just disable sealed trait dispatching? for my use case, if i have a case class with a parameter List[Foo] where Foo is another case class, i would actually like that to fail at compile time, even though magnolia is able to derive an instance for Foo. this is the behavior i get for other collection types, it’s just that list is problematic since it’s a sealed trait.
Andrew Martin
@andrewsmartin
@propensive any ideas?
Andrew Martin
@andrewsmartin
i can get a compile error by making the macro explicit instead, but i’d still like to auto-derive for nested case classes
Andrew Martin
@andrewsmartin
found a workaround! noticed that implicit params can be added to dispatch, allowing to fail at compile-time
Jon Pretty
@propensive
@/all I'm going to delete this room in a couple of days and move all discussion to https://gitter.im/propensive/general/ to try to streamline my communication. I can't keep up with all the messages in so many different places, so any questions about Scala World, Magnolia, Fury or anything else should be directed to the new room. I've historically been quite bad at keeping abreast of messages in various Gitter channels I'm in, but I'm planning to be present in propensive/general more or less daily.
Wojtek Pituła
@Krever
@propensive do you think it makes sense to delete old rooms? I can see a benefit of streamlined communication but I would keep separate rooms for discussion that doesnt require your input :)
Jon Pretty
@propensive
@Krever Yes, I think so. There are lots of questions here which get left unanswered because I don't see them. (Even the ones which tag me.) And I think it gives people an overall worse experience of using these libraries. If I leave the old rooms open, I think it's too easy for people to keep using them and to get a bad experience of them. If projects become active enough in the future that they need their own space, I'll recreate the rooms.
Wojtek Pituła
@Krever
Ok, probably this make sense. I'm just worried that there will be a lot of things going in such a single room and it will be hard to answer questions and help people (or just track communication) if I only care about some subset of the projects. But sure, lets try and we can always go back :)
Jon Pretty
@propensive
Yeah, agreed. I think it's a bootstrapping thing. :)
Alexander Konovalov
@alexknvl
I just discovered that magnolia doesn't work with GADTs:
sealed trait Foo[A]
object Foo {
  final case class Boo(i: Int) extends Foo[Unit]

  implicit def spray[R]: RootJsonFormat[Foo[R]] =
    DerivedFormats.New.derivedFormat[Foo[R]]
}
;(
Jon Pretty
@propensive
@alexknvl Oh... could you open an issue at https://github.com/propensive/magnolia/issues please? I'm also moving all discussion from this room over to https://gitter.im/propensive/general - the only reason I haven't closed this room down is that I want to capture all of the issues people have posted here, first. :)
htch
@htch
Anything I can do to get rid of this error?
magnolia.Deferred is used for derivation of recursive typeclasses
Jon Pretty
@propensive
@htch That looks like a bug in Magnolia. Does it happen every time?
If it's a bug that only occurs after the fourth or fifth compilation (with sbt) then that is a (really horrible) bug we know about.
htch
@htch
@propensive From time to time. For me it occurred when I used magnolia with semi-auto derivation, but not with full auto
Jon Pretty
@propensive
@htch That sounds like the same bug, then. I'm doing some work on Magnolia at the moment, so I'll see if I can fix it.
Andrew Martin
@andrewsmartin
i’ve run into this one as well. spotify/tfexample-derive#13
Jon Pretty
@propensive
Right...
Basically Deferred should only appear in recursively-invoked generic derivations.
It's a placeholder because the inner invocation compiles to something which refers to an identifier in the outer scope, which the typechecker doesn't know exists at the time it gets typechecked... so we return something which does typecheck, temporarily, and then transform the AST afterwards to remove the references to Deferred to point to identifiers once they are within scope.
That's a bit of a complex scenario, but it's not usual, if you have chained implicits.
Jon Pretty
@propensive
*unusual
Riley Oshea
@osheari1
Hey, do you guys have a general timeline/plan for releasing 0.11.0 for scala 2.11?
Georgi Krastev
@joroKr21
I think 2.11 was dropped due to lazy val encoding issues
Jon Pretty
@propensive
@osheari1 Yes, there were some problems with getting the build working for Scala 2.11, so we had to drop it, I'm afraid.
Eric Meisel
@etspaceman

Hello there. We are experiencing some issues using Magnolia in Spark because of CallByNeed not being Serializable (fixed here: propensive/magnolia@bacbbcf). We were giddy to see it fixed in 0.11, but that is not available in scala 2.11.

Scala 2.11 is unfortunately still a big deal for us because Databricks does not offer a runtime in their cloud infrastructure under 2.12 (only 2.11 is supported). Is it possible to simply make a release of 0.10.1 against this hash?

propensive/magnolia@7ac3d5b

CC @propensive
Jon Pretty
@propensive
Hi @etspaceman! We ran into some problems when trying to cross-publish to 2.11, but IIRC, they didn't look too serious.. it's just that the urgency was to get a 2.13 release out. If you don't mind waiting until I've finished with https://scala.world/ I can take a look. Sorry to not have a better way to do this, but would you mind reminding me on https://gitter.im/propensive/general after 8 September?
Eric Meisel
@etspaceman
Hey that works! I've got a slack reminder set up to ask you again :D
Eric Meisel
@etspaceman
Hey @propensive - Reminder just kicked on in my slack :D. Any chance that this is still a possibility on your end?
Jon Pretty
@propensive
Now is a good(ish) time for me to look into it... I'll try to find time this week. :)
Eric Meisel
@etspaceman
Hey @propensive - Did you get a chance to look into this? We reverted to using the shapeless derivations supplied by circe but they are painful for our compiles :sweat_smile: