Github [@propensive:matrix.org] [propensive/magnolia] propensive made a line comment on vigoo's pull request #270 (assignee: None): Exclude params and cons from the derivation based on annotations - https://github.com/propensive/magnolia/pull/270#discussion_r517879060
Github [@propensive:matrix.org] [propensive/magnolia] propensive made a line comment on vigoo's pull request #270 (assignee: None): Exclude params and cons from the derivation based on annotations - https://github.com/propensive/magnolia/pull/270#discussion_r517878389
Github [@propensive:matrix.org] [propensive/magnolia] propensive made a line comment on vigoo's pull request #270 (assignee: None): Exclude params and cons from the derivation based on annotations - https://github.com/propensive/magnolia/pull/270#discussion_r517882769
Github [@propensive:matrix.org] [propensive/magnolia] propensive made a line comment on vigoo's pull request #270 (assignee: None): Exclude params and cons from the derivation based on annotations - https://github.com/propensive/magnolia/pull/270#discussion_r517885031
Github [@propensive:matrix.org] [propensive/magnolia] propensive closed issue #113: Update version to 0.8.0 on magnolia.work [closed] - propensive/magnolia#113
GitHub
[propensive/magnolia] New comment on issue #271: Import two derived typeclasses at once
Clever trick ! It now works as I want, thank you !
GitHub [propensive/magnolia] New branch created: main
propensive (@_discord_547426086179307521:t2bot.io) I think I can also tune the particular events which cause messages...
GitHub
propensive/magnolia@c825aef
propensive/magnolia@c825aef Use main branch for Github Actions - propensive
GitHub#0000
propensive/magnolia@259074c
propensive/magnolia@259074c Tests now running with SBT - propensive
GitHub#0000
propensive/magnolia@89dd7a8
propensive/magnolia@89dd7a8 Add @performance annotation - propensive
GitHub#0000
propensive/magnolia@a781b42
propensive/magnolia@a781b42 Use Probably's compiletime support - propensive
Method too large? I am trying to use magnolia to derive a typeclass for a fairly big case class, ~20 parameters, and many of those parameters have more and more nested case classes... one "hack" that comes to mind is to use shapeless to generate the HList of the bigger case class, and then just derive each of its elements using magnolia, although I can see how that could take me back to Method too large
avro4s which uses magnolia to generate code (type classes). my solution was "functions as data". I had to create a function (method) lookup table (a Map) at compile-time, and call the functions at runtime by looking up this table first. I'm not sure how much performance penalty this approach introduces, but at least I got rid of Method too large issue of JVM
I was trying to put the derivation for the biggest case classes in a seperate file/module... but I am seeing this error for some of them
double definition:
[error] def rawConstruct(fieldValues: Seq): Object at line 69 and
[error] def rawConstruct(fieldValues: Seq): Object at line 69
[error] have same typethis only happens when I put many derivation together, when I remove a few, the same instances that were failing with the above error, now succeed, have you ever seen this?
propensive (@_discord_547426086179307521:t2bot.io) @Miguel A "double definition" error will occur when more than one method defined on the same class (or object) has the same name and erased parameter/return types. I can't remember exactly what Magnolia generates in terms of method definitions, but it's plausible that when nested methods are lifted to the outer level, they end up having the same name and parameters. This could be a bug in Scalac along the lines that it fails to notice (at the right point during compilation) that the definitions conflict... but I'm not sure.
propensive (@_discord_547426086179307521:t2bot.io) @Andy There shouldn't be any problems. The companion object for a sealed trait works much the same as the companion object for a case class (at least in this respect).
propensive (@_discord_547426086179307521:t2bot.io) There's no need for the extra instances to go on the companion objects, by the way. They can go anywhere that's in scope. The problem with "too much bytecode" being generated is basically caused by typeclass derivations happening "in-place", so Magnolia is creating a new instance of a typeclass (and all the code that it needs) instead of a simple reference to that same typeclass instance defined elsewhere. So as long as you can put some of those typeclass instances "elsewhere", and have them in-scope when Magnolia expands, it should find them, and won't need to expand the typeclass instance in-place.
Hello :) First of all, thanks for your effort in creating and maintaining this neat library, great effort, great library :)
I have a similar error to one @caente described. I have a huge case class to create avro schema for with avro4s.
First I had a problem with the too large method. I workarounded this one with separate objects
object ASchema {
implicit val aSchema = SchemaFor[A]
}
object BSchema {
import ASchema._
implicit val bSchema = SchemaFor[B]
}It did a trick. I thought that moving this to companion objects of A and B will be alright as well. But not really, it fails with:
[error] def rawConstruct(fieldValues: Seq): Object at line 342 and
[error] def rawConstruct(fieldValues: Seq): Object at line 342
[error] have same type
[error] implicit val bSchema: SchemaFor[B] = SchemaFor.gen[B]any thoughts why putting those into companion objects implicit breaks like that?