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
    at least depending on what properties you want to preserve
    SO, your function: Have you tested opening/closing?
    e.g. what happens if an exception is thrown
    I'm just thinking through implications. It looks a hell of lot cleaner :)
    Yeah, actually yours is fine
    just had to think through the mutability and such
    If you'd like to deprecate the existing join in favor of that method
    I'd just call it ManagedResource.sequence though
    jpcooper
    @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 :)
    jpcooper
    @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
    jpcooper
    @jpcooper
    okay cool
    that looks nicer
    Josh Suereth
    @jsuereth
    Which should be true of the library generally :)
    jpcooper
    @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
    jpcooper
    @jpcooper
    because of stacking of acquireFors implied by flatMap, I suppose
    Josh Suereth
    @jsuereth
    yep
    jpcooper
    @jpcooper
    okay
    Josh Suereth
    @jsuereth
    SO yeah, the function looks better. Feel free to add it/deprecate the old one
    jpcooper
    @jpcooper
    will do
    Josh Suereth
    @jsuereth
    I need to push out 2.0 final soon, have you tried RC1?
    jpcooper
    @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
    jpcooper
    @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?
    jpcooper
    @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
    jpcooper
    @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?
    jpcooper
    @jpcooper
    Well, one problem is that ManagedResource doesn't expose the resource
    jpcooper
    @jpcooper
    I think what we're actually looking for is making ManagedResource Applicative without flatMap
    Josh Suereth
    @jsuereth_twitter
    yeah