Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Sep 05 2019 14:43
    @typelevel-bot banned @jdegoes
  • Jan 31 2019 21:17
    codecov-io commented #484
  • Jan 31 2019 21:08
    scala-steward opened #484
  • Jan 31 2019 18:19
    andywhite37 commented #189
  • Jan 31 2019 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 2019 00:01
    codecov-io commented #483
  • Jan 29 2019 23:51
    deniszjukow opened #483
  • Jan 29 2019 23:37
  • Jan 29 2019 23:22
  • Jan 29 2019 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 2019 18:01
    jdegoes commented #480
  • Jan 29 2019 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 2019 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 2019 07:12
    alexandru commented #480
  • Jan 28 2019 05:45
    codecov-io commented #482
  • Jan 28 2019 05:35
    daron666 opened #482
  • Jan 27 2019 13:56
    codecov-io commented #481
  • Jan 27 2019 13:46
    lrodero opened #481
  • Jan 27 2019 05:47
    codecov-io commented #460
  • Jan 27 2019 05:37
    codecov-io commented #460
Daniel Spiewak
There are some slightly tricky performance-related questions associated with efficiently disabling tracing in such a global way without creating memory barriers. That's all solvable though, just mechanics, really.

@Avasil Oh, one final bit of trickiness: you can't call getClass on a thunked value in Scala and expect to get the class of the thunk, which is what you need. For example, to trace delay or >>. So you're probably going to need to implement a tiny helper in Java that has the class metadata to trick scalac into passing the thunk along without evaluation. In other words, what scalac does when it sees the following:

def foo(s: => String) = bar(s)
def bar(s: => String) = ...

bar gets the raw thunk that was passed to foo, without re-wrapping. If you can define bar in Java, then you can take that thunk (which will be of type scala.Function0) and call getClass on it without forcing. You don't have that option in Scala, since calling s.getClass will force the thunk and give you the Class of its contents.

You used to be able to trick Scala into not forcing thunks (like, back in Scala 2.7), but they closed that loophole (because it was, in fact, a bug in the compiler)
Daniel Spiewak


is Simon Marlow's note on maskUninterruptable: every use should be viewed with extreme suspicion.

well, we can say: every use of uncancelable that ignores restore should be ....

Fair, though maskUninterruptable still has restore as well, and Simon suggests it be viewed with unconditional suspicion.

The "no special cases" thing is very appealing, and in a sense cancelable would create an unbounded number of special cases. I strongly suspect though that the only people who would use it would be authors of things like Deferred, and most code would just ignore it. That would certainly be the best practice.

Piotr Gawryś
Thank you Daniel
Hello, I'm looking for a structure that act as Semaphore , Defered and MVar but which is a state machine. Aka blocking while the state is not in the expected state.
I think I could do something like that with Ref but I'm not sure how I could make the wait part. Is there is that look like that which exists or is there good exemple that can help me to make this?
Fabio Labella
that's what Ref + Deferred allows you to do
Ok, I will reread them and see. I'm doing a kind of transaction where commit can be done if there is not more task running.
Fabio Labella
you can also use MVar and Semaphore directly ofc
@SystemFw there is no Ref.update(f : A=F[A]) for exemple if I try to open a transaction closed? Maybe I should encode the error in the State?
oh modify is enought in fact to know what happen inside the update !
Ryan Peters
@crakjie In addition -- modify letting you sidestep the issue lets you concurrently reason about pure data better. The function you pass in can be ran potentially more than once due to the implementation not synchronizing access.
So if there were a variant that took a function to F[A] that would be potentially problematic
Gavin Bisesi
This message was deleted
@rzeigler Could you explain what is a variant ?
@SystemFw I made that with your exemple https://gist.github.com/crakjie/7398a57124690f09a7e2037fc3112457 I still have to try it next week but I'm quite happy.
I was lucky that when looking for a state machine with Ref+ Deferred you actually already made one !
Ryan Zeigler
@crakjie I think you mentioned the wrong person
Indeed sorry :x
Paulius Imbrasas
I just noticed, IO.redeem was never added to the typeclasses for cats 2.0?
Rohde Fischer
@SystemFw heya, could I please have the link for your talk where you cover the niceness of referential transparancy? I got some colleagues who I think would appreciate it
(and if they don't too bad for them, I did appreciate it, so I'm gonna share it no matter if the do or don't xD )
Fabio Labella
I don't have a talk specifically on that, but I do cover it in a few talks (shared state in pure FP, my fs2 talk at klarna), I do have a long reddit post on it though. If you browse through https://systemfw.org/talks and https://systemfw.org/writings you should find all the links you need
the reddit posts are called "the benefits of IO"
Rohde Fischer
@SystemFw ah ok, if I recall correctly you linked it when I specifically asked a lot of IO questions, but then it's a question of which one that triggered the linking
I think it's the one from Italy, so Shared State in Pure FP :) thanks, mate
Fabio Labella
Yury Ankudinov
Hi. Does anybody knows by chance which cats-* library exposes the instance of Bracket for Either and if not what would be the reason?
Luka Jacobowitz
@stremlenye I’m curious, why would you need a Bracket instance for Either?
Yury Ankudinov
@LukaJCB I am using Resource to acquire and cleanup dependencies for my IT tests. And unfortunately some of them synchronous.
Luka Jacobowitz
You should use SyncIO :)
Yury Ankudinov
Think of the result they give as Either[Throwable, Assertion]
@LukaJCB I do, but in more up-to-date ones :)
Luka Jacobowitz
I don’t think Either is a great replacement for SyncIO
Yury Ankudinov
It's vice versa. We are slowly replacing Either. It's just it still a lot of the tests still implemented in an old way.
Luka Jacobowitz
That’s fair :) I think you
you’re best of just writing your own Bracket instance
Yury Ankudinov
Already done. Just was curious how comes there were none :)
Anyways thank you.
Daniel Spiewak
there definitely could be one
in fact there could be a Bracket for any MonadError
getting the prioritization right would be tricky though
Yury Ankudinov
@djspiewak Indeed. I'll take a look if I could make it this way.
Daniel Spiewak
I'd be interested to see what you come up with!
Michael Pilquist
(ResourceProxy stuff we’ve discussed a few times)
I would like to seek help refactoring this code. I don't know if should wrap the ValidatedNec to IO or what... I also wanted to have a logger on every validation.
type ValidationResult[A] = ValidatedNec[JobPostError, A]

override def createJobPost(
    newJobPost: JobPost
): IO[ValidatedNec[String, JobPost]] = {
  // TODO: Add logger here on every field validation
  val localValidation: ValidationResult[JobPost] = (
    validateEmptiness("Job post title".some, newJobPost.title),
    validateEmptiness("Job post description".some,

  val databaseValidations: IO[ValidationResult[JobPost]] = (for {
    _ <- Logger[ConnectionIO].info("Validating job title")
    title <- validateTitleExistence(newJobPost)
    _ <- Logger[ConnectionIO].info("Validating job description")
    description <- validateNoop(newJobPost.description).pure[ConnectionIO]
    createdAt <- validateNoop(newJobPost.createdAt).pure[ConnectionIO]
    modifiedAt <- validateNoop(newJobPost.modifiedAt).pure[ConnectionIO]
    id <- validateNoop(newJobPost.id).pure[ConnectionIO]
  } yield {
    (id, title, description, createdAt, modifiedAt).mapN(JobPost)

  val response: IO[ValidatedNec[String, JobPost]] =
    localValidation match {
      case Valid(_) => databaseValidations.map(_.leftMap(_.map(_.errorMessage)))
      case Invalid(e) => e.map(_.errorMessage).invalid[JobPost].pure[IO]
Oleg Pyzhcov
@underscore05 is noop always valid, and is it temporary or there to stay?
@oleg-py this one is just temporary since I don't have validation rules for them yet.
Or is there much better way to do this in case that I just want to validate some of the case class fields?