by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:19
    krzemin commented #176
  • Aug 05 18:06
    d12frosted commented #176
  • Aug 05 17:52
    krzemin commented #175
  • Aug 05 17:35
    krzemin commented #176
  • Aug 05 17:30
    krzemin closed #92
  • Aug 05 17:30
    krzemin commented #92
  • Aug 05 17:00
    d12frosted opened #176
  • Aug 03 08:51
    melgenek opened #175
  • Jul 26 14:59

    krzemin on gh-pages

    updated site (compare)

  • Jul 26 14:33

    krzemin on 0.5.3

    (compare)

  • Jul 26 14:33

    krzemin on master

    bump version to 0.5.3 fix test for scala 2.11 (compare)

  • Jul 26 13:40

    krzemin on master

    add exclusion to ci matrix (compare)

  • Jul 26 13:33

    krzemin on master

    fix ci matrix (compare)

  • Jul 26 11:29

    krzemin on master

    bump scalajs to 1.1.1 bump scala to 2.13.3 bump scalafmt to 2.4.0 (compare)

  • Jul 10 13:19
    calvinlfer commented #172
  • Jul 10 05:56
    krzemin commented #172
  • Jul 10 05:56
    krzemin commented #172
  • Jul 10 05:55

    krzemin on master

    Support Ior (#172) * Support I… (compare)

  • Jul 10 05:55
    krzemin closed #172
  • Jul 10 05:55
    krzemin closed #171
Jakub Kozłowski
@kubukoz
And we can still generalize to Applicative ;)
Calvin Lee Fernandes
@calvinlfer
sorry @kubukoz can you elaborate
i pushed up what we had and added you as a co-committer (hope that's alright)
Jakub Kozłowski
@kubukoz
sure, thanks
Calvin Lee Fernandes
@calvinlfer
:+1:
Jakub Kozłowski
@kubukoz
what I meant is that we don't need to stick to Ior, we could have a single instance for any F[_]: Applicative
product, traverse (like the above) and pure are all possible with just that
Calvin Lee Fernandes
@calvinlfer
oooo
gotcha
Calvin Lee Fernandes
@calvinlfer
SHABOOM
  implicit def deriveTransformerFSupport[F[+_]](implicit F: Applicative[F]): TransformerFSupport[F] = new TransformerFSupport[F] {
    override def pure[A](value: A): F[A] = F.pure(value)

    override def product[A, B](fa: F[A], fb: => F[B]): F[(A, B)] = F.tuple2(fa, fb)

    override def map[A, B](fa: F[A], f: A => B): F[B] = F.map(fa)(f)

    override def traverse[M, A, B](it: Iterator[A], f: A => F[B])(implicit fac: Factory[B, M]): F[M] = {
      F.map(it.foldRight(Eval.always(F.pure(CompatLazyList.empty[B]))) { (next: A, acc: Eval[F[CompatLazyList[B]]]) =>
        F.map2Eval(f(next), acc) { (next: B, acc: CompatLazyList[B]) =>
          next #:: acc
        }
      }.value)(fac.fromSpecific(_))
    }
  }
@kubukoz :D :D :D
Calvin Lee Fernandes
@calvinlfer
that broke all the tests :laughing:
Calvin Lee Fernandes
@calvinlfer
ah for some reason the tests are resolving to all the underlying Impl structures (like NonEmptyChainImpl)
Jakub Kozłowski
@kubukoz
huh?
ah, so it's an ambiguous implicit now?
Calvin Lee Fernandes
@calvinlfer
the implementation is working great
but i cant get the tests to work ;(
Jakub Kozłowski
@kubukoz
do you have a branch?
Calvin Lee Fernandes
@calvinlfer
I’ll add you
Jakub Kozłowski
@kubukoz
cool, I'll take a look
Calvin Lee Fernandes
@calvinlfer
Thank you 🙏😄
Jakub Kozłowski
@kubukoz
not today though...
also, it seems like some weird macro shit I'm not really that familiar with
Calvin Lee Fernandes
@calvinlfer
Ah dang
no worries, whenever you get a chance. That would be a huge ergonomic improvement though
Calvin Lee Fernandes
@calvinlfer
hey all, I have a use case where I have a case class but I want to transform it into itself with Validation, I noticed that's not possible, are there any plans to support it?
  import cats.data.ValidatedNec
  import cats.implicits._
  import io.scalaland.chimney.dsl._
  import io.scalaland.chimney.cats._

    Example("Hello", 1)
      .into[Example]
      .withFieldComputedF[VN, String, String](_.a, e => (e.a + "!").invalidNec[String])
      .transform
    // Valid(Example("Hello", 1))  <-- :(
Piotr Krzemiński
@krzemin
You need to use lifted transformers as in the example here: https://scalalandio.github.io/chimney/transformers/lifted-transformers.html
Essentially you need to replace into with intoF and follow the types
Calvin Lee Fernandes
@calvinlfer
ah okay, thanks @krzemin :D
Calvin Lee Fernandes
@calvinlfer
any idea when a new release will be cut that includes the Ior changes?
Yuval Perry
@yperry
Hi,
Does chimney supports bidirectional or reverse mapping?
Piotr Krzemiński
@krzemin
@yperry nope, not yet, although we have a ticket for it
@calvinlfer I hope I will be able to trigger a release this week
Calvin Lee Fernandes
@calvinlfer
oh great, thanks @krzemin :D
Jakub Kozłowski
@kubukoz
Hey @krzemin, have you considered supporting scala-newtype in chimney?
Piotr Krzemiński
@krzemin
Hey @kubukoz, nope - I did not. I'm not using scala-newtype and don't have use cases for chimney integration. But feel free to create a ticket - I can eventually provide support for someone that wants to deliver a PR.
Piotr Krzemiński
@krzemin
Wojtek Pituła
@Krever
what's the status of chimney on dotty? Anyone tried or still to be investigated?
Piotr Krzemiński
@krzemin
Well, Dotty changes a lot for Chimney. As the library is mostly macro-based and Dotty comes up with brand new metaprogramming APIs, I think that ~90% of the code would need to be rewritten. It would be the best if we could provide the same user APIs and behavioral compatibility (at least for the most common use cases) to make Scala 2 -> Scala 3 transition easy for the Chimney users, but depending on some subtle details it might be either feasible way to go, or extremely unlikely.
Mateusz Kubuszok
@MateuszKubuszok
I think we were discussing this internally some time ago, and we basically decided to wait a bit to see if Dotty's metaprogramming API is stable
Dotty seems to be stable, but once in a while some breaking change is introduced and implementing against moving target (?) would be very demotivating
Piotr Krzemiński
@krzemin
Exactly. There is also a topic of dropping support for Scala 2.11 and Scalajs 0.6.x, which I would prefer to happen before we start supporting another language version.
Mikhail Sokolov
@migesok

Hi!
Probably a stupid question. I tried to write a generic implicit transformer for cats NonEmptyVector and so far derivation doesn't pick it up for me.
The transformer looks like this:

  implicit def nevToVectorTransformer[T, S](implicit
    elemTransformer: Transformer[T, S],
  ): Transformer[NonEmptyVector[T], Vector[S]] = (src: NonEmptyVector[T]) =>
    src.toVector.map(elemTransformer.transform)

  implicit def vectorToNevTransformer[T, S](implicit
    elemTransformer: Transformer[T, S],
  ): Transformer[Vector[T], NonEmptyVector[S]] = (src: Vector[T]) =>
    NonEmptyVector.fromVectorUnsafe(src.map(elemTransformer.transform))

I've even pulled element transformers "explicitly" into implicit scope, still no luck. Is there some kind of limitation in the macro derivation related to this?

Mateusz Kubuszok
@MateuszKubuszok
Did you import cats implicit instances into scope?
Hmm, actually all implicits provided are for TransformerFs
Piotr Krzemiński
@krzemin
Ahh, that seems to be another issue that comes again and again. When you define rule like that, the implicit search for elemtransformer: Transformer[T, S] will not invoke a macro. For now you need to have concrete instances as implicit vals/defs available in the implicit scope.
Mikhail Sokolov
@migesok

For now you need to have concrete instances as implicit vals/defs available in the implicit scope

So I need to have all required elemTransformer implicit instances defined explicitly in the scope, right?
Somehow it didn't work in my real code. At the same time when I tried to come up with a minimal example, I couldn't make it fail. I will dig dipper, maybe the issue is somewhere else.
My real code has those non-empty vectors nested inside a sealed trait hierarchy, with at least 2 levels of nesting.

That trick with pulling element transformers into the scope worked on my real code as well. I just needed to recompile it properly.
Thanks, guys!