Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Josh Suereth
    @jsuereth
    If you'd like to deprecate the existing join in favor of that method
    I'd just call it ManagedResource.sequence though
    Justin Paston-Cooper
    @jpcooper
    I haven't made any tests, but I just imagined that it would be safe because I'm using flatMap
    Josh Suereth
    @jsuereth
    You're mutating a value inside the resource, so it's a matter of figuring out if anything will bypass normal resource cleanup
    and I think the answer here is no :)
    Justin Paston-Cooper
    @jpcooper
    I'm slightly confused. Is the answer no because it's inside a ManagedResource.map? Could you give an example where it might not be okay?
    Josh Suereth
    @jsuereth
    also, you can probably do:
    val finalManagedBuilder = managedResources.foldLeft(initialBuilderResource) { case (builderResource, managedR) ⇒
      for { 
        builder <- builderResource
        r <- managedR
      } yield builder +=r
    }
    The answer is no because it's flatMap+map, yeah
    Justin Paston-Cooper
    @jpcooper
    okay cool
    that looks nicer
    Josh Suereth
    @jsuereth
    Which should be true of the library generally :)
    Justin Paston-Cooper
    @jpcooper
    one would hope :)
    Josh Suereth
    @jsuereth
    I was also checking the failure property
    e.g. how many resources are opened if one throws an error when it's opened
    the answer is "N" where "N is the number of resources before you get to the exception
    i.e. it won't keep trying to open things
    BUT using map/flatMap means it's not an issue, I jsut remember I had other "clever" ways of doign that function, had to refresh my memory on what they were
    Justin Paston-Cooper
    @jpcooper
    because of stacking of acquireFors implied by flatMap, I suppose
    Josh Suereth
    @jsuereth
    yep
    Justin Paston-Cooper
    @jpcooper
    okay
    Josh Suereth
    @jsuereth
    SO yeah, the function looks better. Feel free to add it/deprecate the old one
    Justin Paston-Cooper
    @jpcooper
    will do
    Josh Suereth
    @jsuereth
    I need to push out 2.0 final soon, have you tried RC1?
    Justin Paston-Cooper
    @jpcooper
    I haven't yet
    Josh Suereth
    @jsuereth
    I can push a 2.0.1 with that change though, it won't be binary incompatible
    or a 2.1, I mean
    Justin Paston-Cooper
    @jpcooper
    which version should I fork?
    Josh Suereth
    @jsuereth
    2.0
    err master
    If you want we can release it on 1.x too
    Yang, Bo
    @Atry
    Hello @jsuereth , could you review my Pull Request jsuereth/scala-arm#46, please?
    Justin Paston-Cooper
    @jpcooper
    @jsuereth I'll make a PR to master either this evening or on Saturday
    @Atry nice
    Josh Suereth
    @jsuereth
    @Atry nice! Comments in line, I can merge when I'm not mobile
    Josh Suereth
    @jsuereth
    /all if someone could check my threading here: jsuereth/scala-arm#47
    Also, I'm a bit nervous about shared resources now that I've had a chance to think 'em through. Specifically not sure how to handle 'close after exception' or whether or not we need to notify ALL shared users of failure and "abandon" their usage
    Yang, Bo
    @Atry

    I find that you removed the lock in close function, which is good. I did not realize that the lock could be replace by a CAS.

    But I wonder if we can still use synchronized for open, instead of a spin lock, as JRE's synchronized also performs spin lock for a short time.

    Josh Suereth
    @jsuereth
    Yeah, synhronized may actually be the right thing to do here. we're not going to be talking between threads THAT often I think....
    But We still need to clean u pthe error handlign. I'll do that with synchronized and we can evaluate lockless later
    Justin Paston-Cooper
    @jpcooper
    @jsuereth Have you ever needed to work with a few hundred resource simultaneously? I've written a function that takes T[ManagedResource[U]] to ManagedResource[T[U]] for T <: Traversable. However, this method relies on foldLeft and flatMap. This leads to StackOverflowError if the input is too long. Do you know of any better way to do this?
    I was considering writing case class ManagedResourceSequence[a](resource: Seq[a]). Do you see any problems with this?
    Justin Paston-Cooper
    @jpcooper
    Well, one problem is that ManagedResource doesn't expose the resource
    Justin Paston-Cooper
    @jpcooper
    I think what we're actually looking for is making ManagedResource Applicative without flatMap
    Josh Suereth
    @jsuereth_twitter
    yeah
    SO
    1. Using flatMap is "ok" I think, if we trampoline
    1. I think having an applicative + traverse would be really nice. What do you need to make that happen?
    I'm thinking of non/cats extension
    Justin Paston-Cooper
    @jpcooper
    The problem right now as that ManagedResource doesn't have an open method like AbstractManagedResource does
    Josh Suereth
    @jsuereth_twitter
    right, so you need to assume things about it.....