Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Julien Richard-Foy
    @julienrf
    IIRC we had some issues with this design, that’s why we changed it afterwards. But maybe the issue was just that the signature of the force method was not correct, it should return this.type instead of a LazyList.Evaluated[A].
    Seth Tisue
    @SethTisue

    I almost think Stream should just be a copy-paste of the 2.12 one, with whatever changes are needed to fit it into the new design.

    me three, that it’s always made me nervous that Stream was reimplemented rather than just carried over

    Princess | April
    @NthPortal
    I will look into copying over 2.12's Stream, and simplifying LazyList then (unless you want to @hrhino)
    nafg
    @nafg
    @SethTisue weren't most things reimplemented?
    Princess | April
    @NthPortal
    @nafg not really. core types like List, Vector, etc. have pretty much the same underlying implementations
    nafg
    @nafg
    meaning the way data is modeled? So what was changed with Stream?
    Princess | April
    @NthPortal
    it and LazyList share an implementation via LazyListOps
    Harrison Houghton
    @hrhino
    @NthPortal I wanted to but I'm in a bit of an OSS slouch right now and you've got far more knowledge of the 2.13 collections than I; so if you want to pick it up, feel free (please!)
    Stefan Zeiger
    @szeiger
    Stream was reimplemented from scratch. We only had the new LazyList at first and because Stream is such a special case in the old collections due to the laziness it appeared easier to modify LazyList than to port the old code. I don't remember any particular difficulties doing that, it was indeed quite easy. If you want to replace LazyList with a completely new impementation I'd factor the shared parts in LazyListOps back into Stream and use that for 2.13.
    Princess | April
    @NthPortal
    my LazyList PR is getting close (though still has a few things to iron out). For those invested in the new LazyList design, I would love some initial feedback, so I can incorporate any needed changes as soon as possible, and we can get the lazier design in quickly
    Martijn Hoekstra
    @martijnhoekstra
    If I have a scala method that has a varargs parameter, and I want to pass through java varargs from a java method, what's a way to do that that's compatible with 2.12 and 2.13?
    IOW, how do I write a java varargs forwarder to a scala varargs methods that works for 2.12 and 2.13
    Harrison Houghton
    @hrhino
    does @varargs not work for you?
    Stefan Zeiger
    @szeiger
    Not sure I understand. Are you writing the forwarder in Java? If it's in Scala then how do you end up creating a Java-varargs method without an auto-generated forwarder? If you're implementing a Java interface in Scala you use Scala varargs and the compiler generates a bridge method.
    Martijn Hoekstra
    @martijnhoekstra
    I'm attempting to write a java wrapper class that I want to wrap (among other things) a scala method with varargs
    Matthew Rooney
    @javax-swing
    @martijnhoekstra IIRC scala var args compile into scala.collection.Seq. so you can use one of the methods on scala.collection.JavaConverters to convert your java varargs into a seq
    Sébastien Doeraene
    @sjrd
    @nafg I'm on vacation until August 12. I will have a look at the LazyList PR after that.
    nafg
    @nafg
    @sjrd was that intended for someone else?
    Julien Richard-Foy
    @julienrf
    @NthPortal I guess?
    Princess | April
    @NthPortal
    I would love the feedback. unfortunately, the deadline is August 10
    Sébastien Doeraene
    @sjrd
    Ah well, it's going to be without me, then.
    Stefan Zeiger
    @szeiger
    FYI: I'll be on vacation until September 2
    Ichoran
    @Ichoran
    Me too, but it matters much less :)
    Matthew de Detrich
    @mdedetrich
    @Ichoran @szeiger This may sound like a really dumb question, but it appears that .hashCode doesn’t respect equality as it should since it takes into account order
    This is wrt Map/VectorMap etc
    Actually nvm found it
    Ichoran
    @Ichoran
    Yeah, you have to use the (not very awesome) Map hash routine instead of the (pretty decent) Seq one.
    Princess | April
    @NthPortal
    why does LinearSeqOps#tail return LinearSeq and not C?
    Princess | April
    @NthPortal
    thoughts on the following unfoldLazy definition for the LazyList companion?
    def unfoldLazy[A, S](init: => S)(f: S => Option[(() => A, () => S)]): LazyList[A]
    Matthew Rooney
    @javax-swing
    @NthPortal is there much point in the state being returned from the unfold function being lazy? Is there an issue this is linked to? I can see the benefit of A.
    Since you need to S to evaluate the next tail
    Princess | April
    @NthPortal
    @javax-swing I don't know how valuable S being lazy is. But I don't see any reason to evaluate the next S if you never evaluate the next tail
    Matthew Rooney
    @javax-swing
    @NthPortal Ah yeah I guess so
    Harrison Houghton
    @hrhino
    Does init need to be by-name?
    Princess | April
    @NthPortal
    I don't know
    is there a reason for LazyList to have a fromIterator method, on top of from(IterableOnce)?
    Lukas Rytz
    @lrytz
    ArrayOps.sorted looks quite dubious to me, it probably performs really badly on primitive arrays. Should we really have that method?
    Stefan Zeiger
    @szeiger
    @lrytz It's probably better to use Sorting.sorted for primitive arrays
    Harrison Houghton
    @hrhino
    couldn't ArrayOps delegate to Sorting?
    Stefan Zeiger
    @szeiger
    Yes, that's what I meant
    Harrison Houghton
    @hrhino
    so not to be a wet blanket or anything, and scala/scala#3434 notwithstanding
    Welcome to Scala 2.13.0-M5 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_161).
    Type in expressions for evaluation. Or try :help.
    
    scala> val map = collection.mutable.AnyRefMap.empty[String, Int]
    map: scala.collection.mutable.AnyRefMap[String,Int] = AnyRefMap()
    
    scala> map.getOrElseUpdate("FB", { map.put("Ea", 1) ; 2 })
    res0: Int = 2
    
    scala> map.size
    res1: Int = 2
    
    scala> map.toList
    res2: List[(String, Int)] = List((FB,2))
    
    scala> map.get("Ea")
    res3: Option[Int] = None
    is there a reason we can't just say "modifying the map in the closure argument of getOrElseUpdate is not allowed"?
    The fix would basically come down to reducing getOrElseUpdate to get(key).getOrElse(put(key, default)), and my understanding of the point of getOrElseUpdate is that it's supposed to be faster than that (due to only having to find the entry once)
    (of course, that's not to discount someone cleverer knowing a cleverer fix)
    Harrison Houghton
    @hrhino
    A possible cleverer solution would be to have a modification count.
    Seth Tisue
    @SethTisue
    @hrhino I wouldn’t have been surprised (or disappointed) if scala/bug#8213 had simply been closed as “wontfix"
    Harrison Houghton
    @hrhino
    :+1: agreed. I guess, having fixed it, it's too late to unfix it in 2.13.