Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 05 2020 09:16
    propensive closed #113
  • Nov 05 2020 09:16
    propensive closed #113
  • Nov 05 2020 09:04
    propensive labeled #271
  • Nov 05 2020 09:04
    propensive labeled #271
  • Nov 05 2020 07:44
    propensive commented #271
  • Nov 05 2020 07:44
    propensive commented #271
  • Nov 04 2020 21:01
    joroKr21 commented #271
  • Nov 04 2020 21:01
    joroKr21 commented #271
  • Nov 04 2020 20:36
    xela85 commented #271
  • Nov 04 2020 20:36
    xela85 commented #271
  • Nov 04 2020 03:42
    joroKr21 commented #271
  • Nov 04 2020 03:42
    joroKr21 commented #271
  • Nov 03 2020 20:36
    xela85 opened #271
  • Nov 03 2020 20:36
    xela85 opened #271
  • Oct 16 2020 00:25
    lemastero commented #29
  • Oct 16 2020 00:25
    lemastero commented #29
  • Sep 28 2020 17:41
    lemastero commented #172
  • Sep 28 2020 17:41
    lemastero commented #172
  • Sep 27 2020 14:44
    vigoo opened #270
  • Sep 27 2020 14:44
    vigoo opened #270
Jon Pretty
@propensive
@vigoo I will take a look at your PR now.
(Sorry for the delay!)
matrixbot
@matrixbot
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
matrixbot
@matrixbot
Github [@propensive:matrix.org] [propensive/magnolia] propensive closed issue #113: Update version to 0.8.0 on magnolia.work [closed] - propensive/magnolia#113
matrixbot
@matrixbot

GitHub


propensive/magnolia@23c1ed5

propensive/magnolia@23c1ed5 Update badges - propensive

GitHub


propensive/magnolia@c2dd7cf

propensive/magnolia@c2dd7cf Remove old badge - propensive

matrixbot
@matrixbot

GitHub


[propensive/magnolia] New comment on issue #271: Import two derived typeclasses at once

Clever trick ! It now works as I want, thank you !

matrixbot
@matrixbot
matrixbot
@matrixbot
GitHub
[propensive/magnolia] New branch created: main

GitHub


propensive/magnolia@8554f60

propensive/magnolia@8554f60 Removal of old files - propensive

Anton Sviridov
@keynmol
Something tells me an integration is about to be taken out back and shot.. :D
matrixbot
@matrixbot
propensive (@_discord_547426086179307521:t2bot.io) I think it needs some finetuning... 😉
Anton Sviridov
@keynmol
This feels like talking through an ouija board :D Are the things uppercase on the other side as well?
matrixbot
@matrixbot
propensive (@_discord_547426086179307521:t2bot.io) Ok, I had to log in to Gitter to check what you were talking about... 😉 The answer is "no".
Anton Sviridov
@keynmol
Hah. That's good. It's very intimidating here on gitter. all those FAILURE ON MAIN screaming at people
matrixbot
@matrixbot
propensive (@_discord_547426086179307521:t2bot.io) There are effectively three bridges in place between GitHub, Gitter, Discord and Matrix. GitHub is currently bridged to Discord, though bridging it to Gitter might work better.
propensive (@_discord_547426086179307521:t2bot.io) I think I can also tune the particular events which cause messages...
matrixbot
@matrixbot

GitHub


propensive/magnolia@c825aef

propensive/magnolia@c825aef Use main branch for Github Actions - propensive

matrixbot
@matrixbot

GitHub


propensive/magnolia@1ff09a8

propensive/magnolia@1ff09a8 Update fury build - propensive

matrixbot
@matrixbot

GitHub


propensive/magnolia@91a0ddf

propensive/magnolia@91a0ddf Fix tests for Fury - propensive

matrixbot
@matrixbot

GitHub#0000

propensive/magnolia@259074c

propensive/magnolia@259074c Tests now running with SBT - propensive

GitHub#0000

propensive/magnolia@fe499bf

propensive/magnolia@fe499bf Fix tests (#272) - propensive

matrixbot
@matrixbot

GitHub#0000

propensive/magnolia@89dd7a8

propensive/magnolia@89dd7a8 Add @performance annotation - propensive

matrixbot
@matrixbot

GitHub#0000

propensive/magnolia@a781b42

propensive/magnolia@a781b42 Use Probably's compiletime support - propensive

matrixbot
@matrixbot

GitHub#0000

propensive/magnolia@3d4e3c1

propensive/magnolia@3d4e3c1 Update docs - propensive

Miguel Iglesias
@caente
hello! is it frequent to stumble with the error 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
Zhenhao Li
@Zhen-hao
@caente I encountered this issue with 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
Georgi Krastev
@joroKr21
Hmm one solution is to derive instances for the nested classes and put them in their companion objects. That definitely helps.
We have made changes to reduce generated bytecode, but there is probably more we can optimize
Miguel Iglesias
@caente

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 type

this 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?

I'd like to avoid to put the the typeclass derivations in the companion objects, since that would be super intrussive...
but I am starting to fear that won't be possible
Georgi Krastev
@joroKr21
I've not seen this
matrixbot
@matrixbot
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).
matrixbot
@matrixbot
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.
Krzysztof Borowski
@liosedhel

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?

Krzysztof Borowski
@liosedhel
Somehow the problem was resolved with adding everywhere the val type explicitly like:
object A {
  implicit val aSchema: SchemaFor[A] = SchemaFor[A]
}
object B {
  implicit val bSchema: SchemaFor[B] = SchemaFor[B]
}
matrixbot
@matrixbot
heksesang What is the current status for Scala 3 support in Magnolia?
matrixbot
@matrixbot
propensive (@_discord_547426086179307521:t2bot.io) At the moment we don't really have it, as it's going to involve almost a compete rewrite of the library, but there is work being done on it by Philipp Martini, and potentially some help from Virtus Lab too...