by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Jakub Kozłowski
@kubukoz
@srnb_gitlab you don't need to use Sync if you already use Async like this https://gitter.im/typelevel/cats?at=5cb388b631aec969e8a6cb84
Soren
@srnb_gitlab
@kubukoz Well, that's for closing, which has a callback. Send executes asynchronously but doesn't have a callback, which is why I'm confused on what to do
Jakub Kozłowski
@kubukoz
hmm so send doesn't have any callback at all? I would've thought it would complete once the message leaves your system
or browser, assuming it's js world
Soren
@srnb_gitlab
I'm pretty sure it's async
I'll check the docs and ask people who know more about it
The WebSocket.send() method enqueues the specified data to be transmitted to the server over the WebSocket connection, increasing the value of bufferedAmount by the number of bytes needed to contain the data. If the data can't be sent (for example, because it needs to be buffered but the buffer is full), the socket is closed automatically.
Jakub Kozłowski
@kubukoz

If the data can't be sent (for example, because it needs to be buffered but the buffer is full), the socket is closed automatically.

this seems annoying as hell

@srnb_gitlab what's your runtime? is it scalajs?
Soren
@srnb_gitlab
Yeah, this is the scalajs-side impl of the crossproject
Jakub Kozłowski
@kubukoz
okay. where does the WebSocket type come from? Does it correspond 1-1 to the JS API?
Soren
@srnb_gitlab
scalajs-dom, and yes
It's just typing for the api
Jakub Kozłowski
@kubukoz
okay, I think I get you now
for sending just wrap in Sync[F].delay
Soren
@srnb_gitlab
Alright, cool
Jakub Kozłowski
@kubukoz
for closing (in your Resource's cleanup part) go with the Async[F].async[Unit]{ cb => ws.onclose = cb(Right(())); ws.close() }thing
Soren
@srnb_gitlab
Mhm!
Jakub Kozłowski
@kubukoz
val ws = new dom.WebSocket(s"wss://$endpoint:$port/")
ws.onopen = _ => cb(Right(ws))
this looks like an opportunity for a race condition
but I don't see a better way to do it...
Soren
@srnb_gitlab
How does a race condition happen there?
Jakub Kozłowski
@kubukoz
imagine open happens straight after new WebSocket
but maybe that's impossible given the nature of JS
Soren
@srnb_gitlab
Mhm
Jakub Kozłowski
@kubukoz
I have to run, I'll try to take a look later
Soren
@srnb_gitlab
I have to go as well :sweat_smile: The websocket also takes a while to connect due to handshake stuff and server latency. If I get a nonterminating F though, I'll know this is the place to look.
Jakub Kozłowski
@kubukoz
indeed. I'd add a timeout on top of that
Soren
@srnb_gitlab
Huh, what happens if the websocket doesn't error, but doesn't open, and then times out
I'll have to check semantics on that
Anton Semenov
@a7emenov

Hi there!

I'm trying to adapt Discipline's testing approach, but I'm experiencing issues with comparing values in effectful context F[_] like IO[_].

The source of the problem is in discipline package in cats laws - there is an implicit converter from IsEq[A] to Prop, requiring an Eq[A] and a prettifier A => Pretty.

When A is actually an IO[A], it means that to use Pretty I have to reevaluate the effects I've already evaluated with Eq or memoize them. I suppose I can come up with my own converter to Prop which runs all effects and remembers their values at the beginning, but maybe I'm missing something and someone here can point me in the right direction.

Garrett Kelsch
@gameslayer103
Hey all, I'm somewhat new to the cats side of Scala and I'm reading through the book "Herding Cats" and under the section regarding partialOrder, it says that PartialOrder also enables >, >=, <, and <= operators, but these are tricky to use because if you’re not careful you could end up using the built-in comparison operators.
Looking into it, I can see that PartialOrder does indeed implement the comparison operators, but why? There are already comparison operators in the standard library. What's the advantage of using these over the built-in ones?
Here is a link to the page: http://eed3si9n.com/herding-cats/PartialOrder.html
Andi Miller
@andimiller
along with Eq it's more type safe than the normal implementations
Gavin Bisesi
@Daenyth
@gameslayer103 It allows their use on values which are provided just as type parameters
and also what Andi says
Garrett Kelsch
@gameslayer103
Ok, that makes a lot of sense. Thanks!
Billzabob
@Billzabob
1.pure[Future] is the equivalent of Future.successful(1), what is the equivalent of Future.failed(new Exception("foo")? Guessing something with MonadError?
Gavin Bisesi
@Daenyth
(new Exception("foo")).raiseError[Future]
ApplicativeError
raiseError[F[_]](e: E) given ApplicativeError[F, E]
Billzabob
@Billzabob
@Daenyth Thanks!
Stephen Duncan Jr
@jrduncans
It’s def raiseError[F[_], A](implicit F: ApplicativeError[F, _ >: E]): F[A] so, you need (new Exception(“foo”)).raiseError[Future, Int], right?
Rob Norris
@tpolecat
Yes
Christopher Davenport
@ChristopherDavenport
Ooh, existential. Intriguing. I always write it F[_]: ApplicativeError[?[_], Throwable]
Rob Norris
@tpolecat
That kind of inference doesn't work very well. If you want foo.raiseError to widen foo you need to use a <:< to do it, as far as I can tell. I was messing with it yesterday.
Fabio Labella
@SystemFw
yeah most of the time it won't work, you have to. do (new Exception : Throwable).raiseError[F, Int]) at which point F.raiseError(new Exception) is more appealing
Gavin Bisesi
@Daenyth
I usually do the F.raise.. out of habit, didn't realize the inference was nicer
Stephen Duncan Jr
@jrduncans

Hmm. I didn’t see any cases of that problem in my usage.

On a related note: if you’re wirting tests and you need an ApplicativeError or MonadError, do you just jump to using IO (or, in my situation, StateT[IO, MyState, ?] because I need MonadState and MonadError)? Or something less powerful than IO? Try?

Gavin Bisesi
@Daenyth
Depends what I'm doing