Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:39
    diesalbla labeled #8594
  • 02:06
    diesalbla labeled #8588
  • 02:06
    diesalbla labeled #8587
  • 02:06
    diesalbla labeled #8589
  • Dec 12 23:37
    SethTisue assigned #11824
  • Dec 12 22:54
    SethTisue closed #1097
  • Dec 12 22:54
    SethTisue commented #1097
  • Dec 12 21:42
    hrhino commented #8591
  • Dec 12 19:50
    SethTisue demilestoned #8276
  • Dec 12 19:50

    SethTisue on 2.11.x

    Add JDK 9 constant types to the… Merge pull request #8595 from n… (compare)

  • Dec 12 19:50
    SethTisue closed #8595
  • Dec 12 19:49
    SethTisue commented #8595
  • Dec 12 19:49
    SethTisue labeled #8595
  • Dec 12 17:37

    szeiger on 2.12.x

    faster equals for HashSet Merge pull request #8583 from r… (compare)

  • Dec 12 17:37
    szeiger closed #8583
  • Dec 12 17:37

    szeiger on 2.13.x

    s.c.i.Queue optimizations for Q… Merge pull request #8565 from j… (compare)

  • Dec 12 17:37
    szeiger closed #8565
  • Dec 12 16:13
    som-snytt commented #11556
  • Dec 12 15:50
    SethTisue labeled #8591
  • Dec 12 15:47
    SethTisue review_requested #8595
Andrew Valencik
@valencik

a PR bringing the SIP in line with the implementation would be welcome; so would a PR merging the whole SIP into the spec

For example, the second point here about .type does not work as described (the type is still widened). Should I just delete this section?

Martijn Hoekstra
@martijnhoekstra
I'm almost certain there was a recent PR that brought something about SIP 23 in line in terms of SIP/Spec/Implementation
what a glorious day it would be if we can bring all three in alignment
Andrew Valencik
@valencik
Perhaps this? scala/docs.scala-lang#1570 :D
Eric K Richardson
@ekrich
@SethTisue scala-collection-compat for Scala.js 1.0.0-RC1 please, pretty please?
som-snytt
@som-snytt
I just saw wade through a bunch of 'SIPs' on scala/bug#9838
darjutak
@darjutak
SIP November 2019 minutes published here: https://docs.scala-lang.org/sips/minutes-list.html
SIP June 2019 minutes also added to the list
Next SIP meeting 18th December 2019 at 5 PM CET
Oron Port
@soronpo
:+1:
Seth Tisue
@SethTisue
@ekrich thanks for the reminder. working on it at scala/scala-collection-compat#276 . (I started with scala/scala-collection-compat#275 but it turned into something of a rabbit hole, so I've set that one aside)
Eric K Richardson
@ekrich
I have been watching, didn’t know there was that much to do.
Eric K Richardson
@ekrich
@SethTisue There is talk about a Scala.js RC2 but don’t know any details. Not sure if you would want to wait depending on the timeline.
Seth Tisue
@SethTisue
nah, I'd like to get this sorted out now. once it's sorted out, then it should be easy to turn the cranks for RC2
Eric K Richardson
@ekrich
Ok cool!
som-snytt
@som-snytt
On Akka, they call out "OK TO TEST". It's like you're on the shop floor and they're about to bring some heavy equipment to bear.
On Scala, they whisper "rebuild" very softly until Jenkins is roused from his gentle slumber.
som-snytt
@som-snytt
Now that I'm caught up on Crisis on Infinite Earths, I'm watching Kevin Smith's Aftermath show. I hope they do a show like that for the Scala 3 transition. I'm guessing tpolecat would host. Right now Kevin Smith is saying, "but this beyond bonkers, man." I can't believe I have to wait until January for the conclusion to Crisis on Infinite Earths, June for Wonder Woman 1984, and Q4 for Dotty official.
som-snytt
@som-snytt
I hope the Dotty Aftermath show, or "Aftermaths" for our UK friends, also has an "In Memoriam" segment for the Scala 2 features we have lost. Sniff.
Mateusz Błażejewski
@mblaze

Hi, it was suggested to me by @tpolecat to come here with my question:

Hi, I'm looking for a hint as to what could cause a compiler error: macro has not been expanded
Has anybody got any idea why a macro would not get expanded?
To be more specific I'm looking for a solution to propensive/contextual#54 which I encountered when using this library with Scala 2.13

Eric K Richardson
@ekrich
@SethTisue I am only seeing scala-collection-compat 2.1.3-RC2 only in Sonatype staging not releases. Is that correct?
Seth Tisue
@SethTisue
@mblaze to my knowledge that isn't a common/standard error or issue. I think it's likely to be specific to that library
@ekrich I just hit "release" on the staging repos, so the artifacts should reach Maven Central before long
Eric K Richardson
@ekrich
@SethTisue Thanks, I'll let you know how it goes.
Mateusz Błażejewski
@mblaze
@SethTisue I hoped I could get some hints on what could possibly prevent macro expansion.
som-snytt
@som-snytt
@mblaze do you have a repo for a quick look? The error is a test in refchecks: !t.isDef && t.hasSymbolField && t.symbol.isTermMacro. There are some verbose options for macros that may help.
-Vmacro in 2.13.0, those new flags are so easy on the gray cells.
som-snytt
@som-snytt
@mblaze Also see my earlier joke that I'll call myself Blaze, but pronounced blasé like Beyonce.
Now I will need a different superhero name.
Eric K Richardson
@ekrich
@SethTisue I was able to use scala-collection-compat, 2.1.3-RC2 just fine. Having problems with Scala.js 1.0.0-RC1 but this is my first attempt with the 1.0.0-x series. Could be anything!?
som-snytt
@som-snytt

This looks like a positive change in verbiage:

[warn] there was one deprecation warning (since 2.11.0)
[warn] there were 14 deprecation warnings (since 2.13.0)
[warn] there were 15 deprecation warnings in total; re-run with -deprecation for details
[warn] there were 5 inliner warnings; re-run enabling -opt-warnings for details, or try -help
[warn] four warnings found
[warn] there were 15 deprecation warnings (since 2.13.0); re-run with -deprecation for details
[warn] one warning found

to

[warn] 1 deprecation (since 2.11.0)
[warn] 15 deprecations (since 2.13.0)
[warn] 16 deprecations in total; re-run with -deprecation for details
[warn] 5 inliner warnings; re-run enabling -opt-warnings for details, or try -help
[warn] four warnings found
[warn] 15 deprecations (since 2.13.0); re-run with -deprecation for details
[warn] one warning found

I think the unchanged text comes from sbt? Not actually sure why the build isn't run with -deprecation -opt-warnings.

Li Haoyi
@lihaoyi-databricks
@som-snytt you can call yourself Bazel
som-snytt
@som-snytt
@lihaoyi-databricks if I strive to be the sort of superhero like the Monitor/Anti-Monitor who controls everyone's lives as he leads them to certain doom, but then at the end you kind of like him, which comes as a surprise.
I don't have a name for the bug tracker I'll code in my spare time, but its tag line will be: "Issues for people with issues." That just occurred to me while visiting a propensive project.
Seth Tisue
@SethTisue
@ekrich thx
Mateusz Błażejewski
@mblaze
@som-snytt Thanks for getting interested in that issue. I don't know that much about macros in Scala so I did not really understand your comment in propensive/contextual#54 but I'll try to take a deeper look into it after I finish work today.
@som-snytt Regarding the name, I had a different nickname on git that I was more used to but it had some digits next to it because the variant without them was taken so I decided to think of somthing new to avoid having a lame nickname with digits.
Greg Zoller
@gzoller
G'day folks. Hope this is the right channel. The new 2.13 String.toIntOption, and related "Option" flavors, should return None IMO if a string-typed value is set to null. Currently a NPE is thrown. Bullet-proof code will always need to do the null-check, so does it make sense to make it pre-baked into the behavior of the toXOption functions? Semantically it feels correct: an Int could not be created, hence None.
Andrew Valencik
@valencik

While I agree that would probably be most people's expected behaviour, it seems like the current NPE behaviour is in line with the spec (https://scala-lang.org/files/archive/spec/2.13/06-expressions.html#the-null-value)

A reference to any other member of the "null" object causes a NullPointerException to be thrown.

Seth Tisue
@SethTisue
changing the behavior wouldn't be consistent with the rest of the Scala standard library. in Scala the standard practice is to assume we don't have nulls, so we only null-check at Java interop boundaries. admittedly String is a Java type, but regardless, for a String reference to be null is a situation that isn't supposed to arise in the first place in Scala, so if it does arise, we want to fail fast
(and yes, this is the right channel to discuss possible changes to the standard library, assuming you're seriously considering PR'ing the change yourself, and not just asking "on background")
Greg Zoller
@gzoller
This explanation makes sense--the current behavior is consistent with other Scala functionality regarding nulls.
Paolo G. Giarrusso
@Blaisorblade
@valencik technically, that spec doesn't apply, because that's not an actual member but only pretends to be; however, it makes sense to be consistent.
(but that only makes a difference if there's a stronger argument for changing behavior)
Andrew Valencik
@valencik

that's not an actual member but only pretends to be

I'm not sure I follow what you mean by "pretends to be"

You're calling a toIntOption method on String and passing it a null? As opposed to calling a member method directly on the null object?
I suppose I should have just looked. ^^^ that's not quite it either.
https://github.com/scala/scala/blob/v2.13.1/src/library/scala/collection/StringOps.scala#L896
Martijn Hoekstra
@martijnhoekstra
scala/scala#6538 is the context where it was introduced. Nobody had the heart to bikeshed over null, which I admit in that PR is a somewhat arbitrary choice. My thinking at the time was that 1. scala expects non-null values in many cases without warning, and 2. these methods return None is not a string at all (so not an invalid one either)
Option(nullablestring).flatMap(_.toIntOption) has the semantics you are looking for
the JDK versions of parseFloat and parseDouble also throw on null arguments
som-snytt
@som-snytt
I was just wondering idly again about the old sym != NoSymbol versus sym ne NoSymbol, where the equals check includes a null check. But actually the answer is sym match { case _: NoSymbol => }, which is a simple isInstanceOf, and also avoids a few indirections to go fetch NoSymbol the value. (Avoid case NoSymbol and case _: NoSymbol.type as equality checks.)