typelevel/cats

Welcome! Got a question? Do you have -Ypartial-unification turned on? Other FAQs: http://typelevel.org/cats/faq.html

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!

https://mystb.in/zamunuzeza.scala

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

@J0kerPanda

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

Either is a pretty easy one

I usually factor typeclass dependencies to be precise for code isolation and semantic information to the reader, rather than so I can actually use non-IO in tests

Billzabob

@Billzabob

Why does Free in cats have Pure, Suspend, and FlatMapped but in Haskell it just has Pure a and Free (f ( Free f a))?

Gavin Bisesi

@Daenyth

Probably because haskell is always lazy

Where communities thrive

People

Repo info

Activity