Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Luis Miguel Mejía Suárez
    @BalmungSan
    (says the guy whos is doing a Master's degree just to be a professor)
    Anyways, as long as it works and the code is easy to maintain I am all ears.
    It would be great if derives would work too thought.
    Mason Lazalier Edmison
    @masonedmison
    Yeah, I mean I think shapeless3 is very powerful - if anything I think it's just that we don't actually need that power and that pure scala3 language features are enough to solve our problems.
    Given what I have done so far, I would maybe suggest just a pure scala implementation - similar to what circe has done.
    derives should work regardless of the approach :)
    WDYT, mind if I switch paths and try implementing derivation using just plain scala3 features (mirrors, inlining, etc.)?
    Luis Miguel Mejía Suárez
    @BalmungSan

    @masonedmison well, whatever works.
    I just want:

    1. Derivation to work.
    2. Semiaiuto and auto to be different things.
    3. The code to be readabl.e
    4. derives to work.

    My prior experience is that using Mirror and all that as suggested in the official pages does not give those 4 things.

    But if you manage to find the missing piece in my last attempt then by all means please do!
    Mason Lazalier Edmison
    @masonedmison
    Understood. Was there any one thing mentioned above that you you struggled with in your last attempt?
    Luis Miguel Mejía Suárez
    @BalmungSan
    You can find my last Scastie snippet if you follow the conversation upwards.
    If you don't find me let me know.
    Mason Lazalier Edmison
    @masonedmison
    the link shared takes me to the beginning of the scala-users thread.
    Luis Miguel Mejía Suárez
    @BalmungSan
    really?
    damn
    Ugm weird
    It works but then it implies auto derviation always.
    Then I was told that using Shapeless 3 it worked as expected.
    Mason Lazalier Edmison
    @masonedmison
    I see. Cool, thanks for sharing. I have to step away for awhile, but I'll give this a look soon.
    Luis Miguel Mejía Suárez
    @BalmungSan
    :+1:
    Mason Lazalier Edmison
    @masonedmison
    After reading that thread, I am inspired again to try to make shapeless3 work :sweat_smile:. I finally figured out a way to derive "decode-like" typeclasses which is ultimately, IIUC, what we need for ResultMapper - though this currently doesn't work for recursive types but I think unfold is the answer for these types of typeclasses.
      // TODO this doesn't work for recursive types
      given [T] (using inst: K0.ProductInstances[ColumnDecoder, T], labels: Labelling[T]): CSVDecoder[T] with
        def decode(values: List[String]): DecodeError[T] =
          val ((_, errOpt), decodeOpt) = inst.unfold[(List[String], Option[Throwable])](values, None) {
            [t] =>
              (acc: (List[String], Option[Throwable]), dec: ColumnDecoder[t]) => {
                val (vs, err) = acc
                val result = dec.decode(vs.head)
                ((vs.tail, result.left.toOption), result.toOption)
              }
          }
          decodeOpt.toRight(errOpt.getOrElse(new Exception("Oopsies.")))
    Mason Lazalier Edmison
    @masonedmison
    I just pushed some changes where ResultMapper is derived using a similar approach as above. auto, semiauto and derives seem to work (from some simple testing) using this current approach. There are still some todos around fixing tests, resolving some not so good errors, and ambiguous implicit errors when having multiple DerivedResultMapper givens declared. All in all, I think this approach should work out.
    Luis Miguel Mejía Suárez
    @BalmungSan
    :tada:
    Thomas Järvstrand
    @tjarvstrand
    Awesome work!
    Mason Lazalier Edmison
    @masonedmison
    :heart: I'll keep plugging away and will probably have some more questions along the way.
    Luis Miguel Mejía Suárez
    @BalmungSan
    :+1:
    Mason Lazalier Edmison
    @masonedmison
    Unless I am missing something, I believe we will need to break out the HList stuff into a separate scala-2 directory within core-test. Any ideas on how we might do that? I was checking kittens for inspo.
    Luis Miguel Mejía Suárez
    @BalmungSan
    @masonedmison it should work the same as with the main, doesn't it?
    Mason Lazalier Edmison
    @masonedmison
    I believe so, yes. I was more asking about how we should name the tests and extract them out, e.g. what is the best way to extract out the hlist tests from DriverSpec.
    I could imagine us
    1) have a DriverSpec in each the scala-2 and scala-3 directories and the only differing bits would be hlist vs. tuple, respectively
    or
    2) Have a base BaseDriverSpec with the "common" tests that work for both versions in scala and then extend this within scala-2 and scala-3 directories (as DriverSpec) adding the hlist and tuple tests there.
    Luis Miguel Mejía Suárez
    @BalmungSan
    @masonedmison I would follow the typelevel style here.
    A empty class that extends a platform depedant trait that contains the actual tests.
    That way, we can refer to that class in the DriverSpec
    Mason Lazalier Edmison
    @masonedmison
    Ah yes very nice. I'll follow this pattern, thanks @BalmungSan
    Luis Miguel Mejía Suárez
    @BalmungSan
    Let meknow if you find any other problem :)
    Mason Lazalier Edmison
    @masonedmison
    Sounds good. I was going to start looking at the Cypher interpolator macro tonight along with fixing the tests using the above suggestion
    Luis Miguel Mejía Suárez
    @BalmungSan
    :tada:
    Luis Miguel Mejía Suárez
    @BalmungSan

    Hi @/all I just opened an issue that brings some complex topics on the table for discussion, I would be very grateful if you can find the time to read it and leave your thoughts.
    Thanks in advance!

    neotypes/neotypes#561

    Mason Lazalier Edmison
    @masonedmison
    Hey all, sort of an update/non-update. Spinning my wheels regarding the CypherStringInterpolator scala3 port. Particularly the bit I am struggling with is how to work with the args: Any* (within c). In scala3, this ends up being Expr[Seq[Any]] to whereas (IIUC) scala2 we are able to get an Iterator[Expr[Any]] (in which we can ultimately get the Tree and type for each element to splice in the code the QueryArgMapper for said type).
    Luis Miguel Mejía Suárez
    @BalmungSan
    Did you checked how literally does it?
    Mason Lazalier Edmison
    @masonedmison
    Ah I have not, good call.
    I was looking at protoquill for some inspo but that stuff is still above my head.
    Mason Lazalier Edmison
    @masonedmison
    Ah it doesn't look like Literally actually uses the Expr[Seq[Any]] - only in reporting an error if interpolation is not supported (here)[https://github.com/typelevel/literally/blob/main/core/shared/src/main/scala-3/org/typelevel/literally/Literally.scala#L41]

    Alex Ioffe suggested doing something like this

    def myMacro(builder: DeferredQueryBuilder): Something = ${ myMacroImpl('builder) }
    def myMacroImpl(builder: Expr[DeferredQueryBuilder])(using Quotes): Expr[Something] =
      builder match
        case '{ CypherStringInterpolator($partsExpr).c(${ Varargs(params) }: _*) } => 
          partsExpr match
            case '{ StringContext.apply(${ Varargs(parts) }: _*) } =>
              // at this point you have parts: Expr[Seq[String]] and params: Expr[Seq[Any]] or something like that

    but I am not sure how we would pass in DeferredQueryBuilder since that is what the macro itself returns.

    Luis Miguel Mejía Suárez
    @BalmungSan
    So I think it should be the opposite.
    def myMacroImpl(builder: Expr[Seq[Any]])(using Quotes): Expr[DeferredQueryBuilder] =
    Or something, I really have not even looked into a hello world example of Scala 3 macros