Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 06 10:53
    cornerman closed #10
  • Apr 06 10:53
    cornerman commented #10
  • Apr 06 10:52

    cornerman on serialize-methods-args

    (compare)

  • Apr 06 10:52

    cornerman on master

    switch to tuple serialization i… (compare)

  • Apr 06 10:52
    cornerman closed #100
  • Apr 05 21:31
    marcgrue commented #21
  • Apr 01 08:21
    scala-steward closed #95
  • Apr 01 08:21
    scala-steward commented #95
  • Apr 01 08:21
    scala-steward opened #101
  • Mar 31 22:31
    cornerman synchronize #100
  • Mar 31 22:31

    cornerman on serialize-methods-args

    switch to tuple serialization i… (compare)

  • Mar 31 22:31

    cornerman on master

    increase metaspace size for jit… (compare)

  • Mar 31 22:23

    cornerman on serialize-method-parameters-as

    (compare)

  • Mar 31 22:18
    cornerman commented #19
  • Mar 31 22:13
    cornerman closed #19
  • Mar 31 22:13
    cornerman commented #19
  • Mar 31 22:10
    cornerman opened #100
  • Mar 31 22:10

    cornerman on serialize-methods-args

    switch to tuple serialization i… (compare)

  • Mar 29 23:25
    scala-steward closed #89
  • Mar 29 23:25
    scala-steward commented #89
johannes karoff
@cornerman
@nafg No, just updated cats and chameleon. But otherwise functionality is the same
Though, I had to drop 2.11 for now, because of chameleon (I currently use optional dependencies there and circe is not available for 2.11 anymore).
I will want to revisit the two open PRs about multiple result types and serialization. So I think, i will make another release 0.3.0 soonish.
nafg
@nafg
I had an issue recently with the log thingy
johannes karoff
@cornerman
You mean the Logger for the client?
nafg
@nafg
Why does LogHandler#logRequest take a type parameter? It's good that you moved Result[_] to the trait level but shouldn't T be moved as well?
How can I write an implementation that returns a Result[T] when I don't know what T is
This message was deleted
I see it comes back to ClientImpl#execute taking R
johannes karoff
@cornerman

How can I write an implementation that returns a Result[T] when I don't know what T is

You get the current result Result[T]. I thought it would make sense for IO or Task, where then can map over the result and return the new one with logging

nafg
@nafg
Yeah I guess I'm probably abusing LogHandler
johannes karoff
@cornerman

I see it comes back to ClientImpl#execute taking R

exactly! We get the the result R wrapped in Result[R], so I need to pass the around :)

nafg
@nafg
Either that or did something wrong.
To be clear the T is the deserialized response from the request?
johannes karoff
@cornerman
Yes!
nafg
@nafg
Ok I misunderstood when I migrated to 0.1.0 it seems
johannes karoff
@cornerman
Feel free to share your code, maybe we can fix it
nafg
@nafg
Before that I had
    override def logRequest[R[_], ErrorType](path: List[String], argumentObject: Product, result: R[_])
                                            (implicit monad: MonadError[R, _ >: ErrorType]) =
so I thought that you moved R out to the trait and what remained was ErrorType
of course that can't be because result is now Result[T]
but I didn't think into it I guess
johannes karoff
@cornerman
I moved the Errortype out of the method, because you would not know what it is. and the monad error was there to actually do something with the Result R[_], but actually you do know your Result{_]and therefor your ErrorType
nafg
@nafg
yeah
I think I'm good now
johannes karoff
@cornerman
Great!
What I do not like about the logRequest is that you actually have to come up with a way to log (stringify) it, so there is only toString or pattern matching. Not sure what could be a better approach.
nafg
@nafg
Well what purpose does it serve, precisely?
i.e. what are the motivating use cases
johannes karoff
@cornerman
The purpose is to enable centralized logging in the client. The router is typically on the backend and you have ways to log your requests between your, e.g., http-api and calling the router. But in the client, you might use Future or Task or your result type. So in order to not do the logging on each method call, you can define the loghandler through which all requests with their results go.
Is is empty by default and does nothing, but it makes sense for some applications.
nafg
@nafg
What I mean is, what would I want to log and why?
My use case for extending it was to log failures
But when would I want to log the response object
moritz bust
@busti
Why does Request use List for it's path?
Isn't Seq more appropriate, or does it explicitly require linked list capabilities?
moritz bust
@busti
Also, is #12 rebased onto the 2.13 update?
johannes karoff
@cornerman
@Busti Yes, i rebased #12 on top of the current master
Currently, we pretty much just use the request path List with two strings (the trait name and the method name). See: https://github.com/cornerman/sloth/blob/master/sloth/src/main/scala/Router.scala#L13
@nafg I currently use the logger only for development and debugging. So, in development I have debug logs in the LogHandler and in production the LogHandler is empty. Otherwise, I agree with you - you normally want to log failures.
nafg
@nafg
Thank G-d, I've finally solved the slow compile times
All it took was avoiding full auto derivation using shapeless, by writing magnolia derivers that respect existing instances
I can share the code later
Kenner Stross
@kennerstross
Hello. I've been using covenant and sloth to manage my client/server interactions in a Scala 2.12 / Scala JS 0.6.x environment. Now... for various reasons, I must move to Scala JS 1.x, but it doesn't look like there are covenant/sloth versions for 1.x, which leaves me high-and-dry. Any suggestions? What are others doing in this situation? Thanks in advance for any advice you have.
johannes karoff
@cornerman
@kennerstross Hi there! There was work done on it, but currently an optional dependency in chameleon hinders a merge of the PR: cornerman/sloth#55
We need to wait for an issue in the boopickle release.
Alternatively, we could split up chameleon into multiple projects (for each dependency instead of having one release with optional dependencies). And in sloth only depend on the core types. Then we could make this faster.
Kenner Stross
@kennerstross
Thanks for the response, @cornerman. Personally, I would love to see the split approach!
johannes karoff
@cornerman
@kennerstross I will see whether I can do it soonish - I do not have so much time as of right now. Otherwise a PR would be awesome.
johannes karoff
@cornerman
@kennerstross This issue has been fixed by the way. You can use sloth now with scalajs 1.x with sloth version 0.3.0.
Kenner Stross
@kennerstross
Thanks, @cornerman !