Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 21:44

    danieldietrich on v1.0.0

    Fixes malformed .travis.yml (#2… (compare)

  • Jan 31 21:44
    danieldietrich closed #2369
  • Jan 31 21:31
    codecov-io commented #2369
  • Jan 31 21:31
    codecov-io commented #2369
  • Jan 31 21:31
    codecov-io commented #2369
  • Jan 31 21:18

    danieldietrich on v1.0.0

    Simplification (#2367) (compare)

  • Jan 31 21:18
    danieldietrich closed #2367
  • Jan 31 21:18
    danieldietrich closed #2368
  • Jan 31 21:18
    danieldietrich labeled #2368
  • Jan 31 21:14
    danieldietrich labeled #2369
  • Jan 31 21:14
    danieldietrich labeled #2369
  • Jan 31 21:14
    danieldietrich milestoned #2369
  • Jan 31 21:14
    danieldietrich opened #2369
  • Jan 31 21:14

    danieldietrich on travis-yml-fix

    Fixes malformed .travis.yml (compare)

  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 20:51
    danieldietrich opened #2368
Nándor Előd Fekete
@nfekete
If you're calculating something cheap, it's probably better to just recalculate it every time, as memoization is costly in terms of memory use and further iterations will be costly because of memory access, which might be much higher than just recalculating something cheap.
No, Iterator is not a lightweight implementation of Stream. Please try to be more precise with formulating these statements.
I use Iterator when I need to do one-shot calculation on a collection of elements. I usually collect the results if I need to reuse them later. I rarely use the memoizing vavr Stream or transformations on eager collections. But there are use cases for those as well, and they are good choices in some circumstances.
Gopal S Akshintala
@overfullstack
Sorry, I don’t mean Iterator is implementation of Stream… I see both have same intent (looping thorugh elements) but different implementations (in terms of how they do it)… I see Iterator is less costlier (light weight) than Stream (Both from VAVR), for one-shot calculation
Nándor Előd Fekete
@nfekete
Yes, Iterator is mostly for one-shot iterations. Stream is actually a lazy collection, so it has much more uses than just one-shot iterations. Remember that it actually stores your elements (lazily) and it's immutable. So you can reuse it as many times as you want.
Gopal S Akshintala
@overfullstack
Awesome! Thanks @nfekete alot :)
Nándor Előd Fekete
@nfekete
@overfullstack you're welcome
Mark Raynsford
@io7m
'ello. is there a sorted map/multimap structure in vavr that allows for efficient (as in not O(n)) range queries like java.util.NavigableMap's subMap methods?
i can't tell if i'm looking straight at them and not seeing them..
Mark Raynsford
@io7m
i see there's a PR vavr-io/vavr#1317 although i'm not entirely clear if the resolution of that meant that the commits made it into a 1.0.0 alpha...
Daniel Dietrich
@danieldietrich
Hi Mark, no, it did not made it into the lib. Adding the interfaces was trivial. But the change needs me to reworks Red/Black Tree a bit which did not take place, yet.
Mark Raynsford
@io7m
ok, thanks
Jakob Brünker
@JakobBruenker
Hey, quick question: With Value.toJavaOptional being deprecated, is there an alternative method that should be used to convert Option to Optional?
Jakob Brünker
@JakobBruenker
I suppose fold(Optional::empty, Optional::of) works
Daniel Dietrich
@danieldietrich
@JakobBruenker please stay tuned. We are still 1.0.0-alpha. The conversion methods will be moved to Try, Option, Either et al. Reworking isn‘t finished, yet.
Jakob Brünker
@JakobBruenker
Cool, thanks
Jakob Brünker
@JakobBruenker
One more thing, it looks like the vavr-match link on the website links to https://github.com/vavr-io/vavr instead of https://github.com/vavr-io/vavr-match
same with vavr-test, actually
Daniel Dietrich
@danieldietrich
thanks for the hint! I will fix that
Kaiyin Zhong
@kindlychung
Does vavr work well with graalvm's native-image?
Daniel Dietrich
@danieldietrich
@kindlychung We did not test it, yet. I see no reason it should not work. We have zero dependencies(!) and only use standard Java features in our implementation. Please share your insights with us!
Jakob Brünker
@JakobBruenker
I'm thinking of adding vavr to an existing, reasonably big springboot project - but it seems springboot automatically adjusts spring data methods to target vavr types if vavr is added as a maven dependency. Anyone know if there's a way to turn that off, so that I can leave existing code as is and only use vavr for new code?
(Admittedly this seems like it's more of a question for the spring community, but I thought someone here might know)
Bob Glamm
@glammr1
I think Spring Data uses the actual types in the repository interface's method signatures, not automatic conversion
We have Vavr in Spring Boot projects and none of the existing types are overridden
Jakob Brünker
@JakobBruenker
Hm, okay.. I get a bunch of Exceptions as soon as I add vavr as a dependency that say java.lang.IncompatibleClassChangeError: Method io.vavr.control.Option.none()Lio/vavr/control/Option; must be Methodref constant
It seems like that shouldn't be happening if that's true? Maybe I'm misunderstanding something though
I guess I should test with an empty project first anyway to see what's actually breaking it
Bob Glamm
@glammr1
That sounds like the wrong Java version is being used
sorry, let me rephrase: I think the Vavr dependency requires a specific minimum version of Java and the version of Java used is incompatible with it
Jakob Brünker
@JakobBruenker
Okay, I'll see if I can't figure out how to check which version of Java maven uses and how to change it (I'm not actually very familiar with maven)
it says it's using Java version: 11.0.4
I wouldn't expect vavr to require a newer version than that?
Nándor Előd Fekete
@nfekete
IncompatibleClassChangeError: Thrown when an incompatible class change has occurred to some class definition. The definition of some class, on which the currently executing method depends, has since changed.
do you have a clean build compiled against the vavr version that is being used at runtime?
Jakob Brünker
@JakobBruenker
Yes, the exceptions occur in the automated tests that are run after building
uh, it seems to work if I use an older version of vavr though, I think
I tried the newest 1.0.0 alpha before, now I'm using 0.9.0
Jakob Brünker
@JakobBruenker
And 0.10.2 works as well (I can successfully run System.out.println(Some.of("hello")) and then run the rest of the program without exceptions)
Nándor Előd Fekete
@nfekete
1.0.0 line is/was an incompatible experimental line for the future version of vavr, and it's in a pre-alpha stage, not intended to be used in pretty much any way
Jakob Brünker
@JakobBruenker
okay, fair enough
Nándor Előd Fekete
@nfekete
I think it was a mistake to even publish it
but nevertheless, you should have your code compiled against the same version that you'll be using at runtime
Jakob Brünker
@JakobBruenker
okay
Daniel Dietrich
@danieldietrich
The newest 1.0.0-alpha should be compatible to 0.10.x. However, we switched from Maven to Gradle. The tests target java 11, vavr targets java 8. The test target will be fixed to be java 8.
Jakob Brünker
@JakobBruenker
Are you saying that that is likely where the problem came from? (To be clear, when I was talking about tests I meant the tests of the project, not vavr tests)
Daniel Dietrich
@danieldietrich
okay, I confused it. please stick to 0.10.x until spring-data depends on vavr 1.0.0.
Jakob Brünker
@JakobBruenker
okay
While I'm here, another question: Is there a preferred choice between Option(c) and Option.some(c)if it's guaranteed that c is not null?
Daniel Dietrich
@danieldietrich
Option(c) is Scala-like syntax. Option.some(c) is more Java conform.
Jakob Brünker
@JakobBruenker
okay, that makes sense, though I suppose I was more thinking of the semantic difference between explicitly creating a some vs it. being implicitly a some because c is not null (as would also apply to Option.of)
I don't necessarily expect there to be a coding style recommendation here, but I thought I'd check