Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:50
    som-snytt synchronize #8598
  • 10:11
    som-snytt edited #8598
  • 10:09
    som-snytt synchronize #8598
  • 08:01
    som-snytt commented #8477
  • 07:14
    som-snytt synchronize #8598
  • 06:21
    som-snytt commented #8641
  • 04:25
    steven-barnes commented #11839
  • 03:30
    SethTisue demilestoned #11823
  • 03:30
    SethTisue milestoned #11823
  • 02:40

    SethTisue on 2.13.x

    unfreeze http4s (by adding cats… (compare)

  • 02:40
    SethTisue closed #1052
  • 02:39
    SethTisue commented #1052
  • 02:39

    SethTisue on 2.13.x

    2.11: new Scala SHA (#1037) 2.12: advance project SHAs (#10… bump sbt to 1.3.7 (was 1.3.6) (… and 7 more (compare)

  • 02:39
    SethTisue closed #1053
  • 02:39
    SethTisue commented #1053
  • 02:38

    SethTisue on 2.13.x

    run github4s tests again (#1054… (compare)

  • 02:38
    SethTisue closed #1054
  • 00:58
    som-snytt synchronize #8598
  • Jan 17 20:12
    joroKr21 commented #1047
  • Jan 17 19:30
    SethTisue demilestoned #9427
som-snytt
@som-snytt
I didn't follow American football until the 49ers started winning this season. Right now I'm like, what if the Titans actually beat the Ravens? But I love this line from Richard Sherman: I'm tired of hearing excuses for why I'm great. I wish the Scala team would start talking like that.
som-snytt
@som-snytt
That's Richard Sherman the 49er, not the songwriter of It's a Small World.
Steven Barnes
@steven-barnes
I'm trying to debug scaladoc, using 'sbt doc'. My println statements seem to do nothing.
som-snytt
@som-snytt
@steven-barnes maybe publishLocal, as when bootstrapping?
Steven Barnes
@steven-barnes
I do publishLocal, and I can set breakpoints on my modified code in Intellij, then attach the debugger to SBT
So scaladoc is not expected to eat println output...
I run like this: sbt -Dstarr.version=2.13.2-bin-SNAPSHOT -jvm-debug 5005
Harrison Houghton
@hrhino
sbt might. Have you considered running scaladoc directly?
sbt dist/mkPack in your Scala repo, and then ./build/pack/bin/scaladoc with appropriate arguments
Steven Barnes
@steven-barnes
@hrhino I can see my output, thanks!
Dale Wijnand
@dwijnand
dist/mkQuick to skip the unnecessary jar-ing.
Harrison Houghton
@hrhino
:eyes:
som-snytt
@som-snytt
There was a question in the other room about broken singleton None (due to deserialization, not multiple class loaders). Recently I noticed checking for NoSymbol in the cake looks cleaner as case _: NoSymbol rather than eq or ==. In the same spirit, case x if None.canEqual(x) => which is instanceof None$. It would be wild if there was pattern support: case _:? None => or if case _: None.type meant canEqual. Maybe it's because I'm fighting off a cold and feeling world-weary, but why do I care about ref eq of singletons again? None.synchronized might care. That should require an extra annotation, by analogy to thread safety of lazy.
som-snytt
@som-snytt
There was a question on SO about why { type X = Tuple2[Int, String] ; weakTypeTag[X] } but not { type X = Tuple2[Int, String] ; typeTag[X] }. What is a local type alias versus a type member? Maybe it is like a type param in the same way a local value is like a value parameter.
som-snytt
@som-snytt
TIL that lambdas _ => 42 incur boxing for non-specialized types.
Martijn Hoekstra
@martijnhoekstra
What's the plan with deprecated members and deprecated inheritance in the stdlib? These are now marked as slated for removal /making final in 2.14. But without a 2.14 and backwards compatibility throughout scala 3, it seems they can now be made final/removed in scala 4 at the earliest. Is that indeed the plan? Should deprecation messages be tweaked to reflect that?
Guillaume Martres
@smarter
let's not change things until we know what we're doing
there might or might no be a 2.14, there might or might no be binary-compatibility breakage in 3.1 or something
Dale Wijnand
@dwijnand
Maybe changing to "a future release" is a good change.
Paolo G. Giarrusso
@Blaisorblade
@martijnhoekstra I have heard of “binary compatibility throughout Scala 3”, but it doesn’t seem to be confirmed? In fact, Tasty avoids bincompat changes due to the compiler, but changes nothing about library versions per se.
I realized recently that Tasty might allow decoupling library and compiler version, instead: https://gitter.im/lampepfl/dotty?at=5e1b77c16f604152992cd2eb
Martijn Hoekstra
@martijnhoekstra
I may have misunderstood.
Paolo G. Giarrusso
@Blaisorblade
nah, I think that was needed by the initial pitch for Tasty
but that part of the design is pretty clearly ongoing work
s/is/seems/ — if there are public decisions, let me know!
Martijn Hoekstra
@martijnhoekstra
so what is the current understanding on stdlib compatibility requirements across scala3?
Dale Wijnand
@dwijnand
I think part of the confusion is some have used TASTy as opposed to bytecode as the new form of "binary". So by "binary compatibility" they mean "TASTy compatibility", which is the term I would much rather we used, keeping "binary compatibility" for bytecode. I think bytecode can and will break in feature releases (3.1, 3.2, 3.3, ...) of Scala, but TASTy compatibility won't, except maybe 3.0->3.1.
Martijn Hoekstra
@martijnhoekstra
Then is it indeed the plan (subject to change) that all deprecated members and all current members with deprecated overriding in the stdlib of 2.13.x will be preserved throughout scala 3 as TASTy backwards compatibility policy?
Dale Wijnand
@dwijnand
To the best of my knowledge, yes.
Paolo G. Giarrusso
@Blaisorblade
(That post was the first I know that explicitly allowed adding classes.)
Odd Möller
@odd
Does the recent Scala 2 Roadmap Update mean that Scala 3 will follow the Semantic Versioning scheme of MAJOR.MINOR.PATCH instead of the Scala 2 scheme of EPOC.MAJOR.MINOR?
Dale Wijnand
@dwijnand
Yes - if you're happy with the qualifier for "breaking" is TASTy. If you still reason in terms of bytecode, then it'll still be epoch.major.minor. Also, the forwards-compatibility guarantee will be dropped when the recompile-from-TASTy tooling is ready, (i.e. 3.1.1 can add a method to a class added in 3.1.0).
Odd Möller
@odd
@dwijnand Thanks, that is a major change indeed. Interesting to see how that will effect the timing and contents of future major versions…
Dale Wijnand
@dwijnand
Yeah, less disruptive breakages.
Odd Möller
@odd
Or perhaps it will lead to the opposite: any non tasty-compatible change considered neccessary will require a major version bump and since you are doing a new major version you might as well throw in all the other library/language changes at the same time :stuck_out_tongue_winking_eye:
Dale Wijnand
@dwijnand
Let's debate "necessary" :D
Tomasz Godzik
@tgodzik

Anyone knows why the Scala Presentation Compiler breaks on encoding utf-8:

Jan 16, 2020 3:45:53 PM scala.meta.internal.pc.CompilerAccess handleError
SEVERE: requirement failed: List(utf-8)
java.lang.IllegalArgumentException: requirement failed: List(utf-8)
    at scala.Predef$.require(Predef.scala:281)

is it because it only accepts utf8 ?

Hanns Holger Rutz
@Sciss
Is there a macro expert here? I'm getting an unspecific Error:scalac: Error while emitting MacroTest.scala message that doesn't make sense to me. I need more info to understand the macro problem. Some sbt switch?
Hanns Holger Rutz
@Sciss

I'm narrowing it down, but simply don't understand. This works inside reify:

      obj()             = Pattern.newConst[S](Graph[Any](body.splice))

but this doesn't:

      val out           = Graph[Any](body.splice)
      obj()             = Pattern.newConst[S](out)

???

where newConst is defined as def newConst[S <: Sys[S]](value: Pat[_])(implicit tx: S#Tx): Const[S].
so why would it matter if I use an intermediate variable?
Harrison Houghton
@hrhino
That's often because the locals map isn't initialized properly during codegen
Although the error is really quite useless
Can you put up the whole macro?
Hanns Holger Rutz
@Sciss
  def patternGraphWithSource[S <: Sys[S]](c: blackbox.Context)(body: c.Expr[Pat[Any]])(tx: c.Expr[S#Tx])
                                         (implicit tt: c.WeakTypeTag[S]): c.Expr[Unit] = { // yes, `tt` _is_ used
    import c.universe._
    reify {
      val ext           = c.prefix.splice.asInstanceOf[MacroImplicits.PatternMacroOps[S]]
      implicit val txc  = tx.splice // N.B.: don't annotate the type with `S#Tx`, it will break scalac
      val obj           = ext.`this`
      val out           = Graph(body.splice)
      obj()             = Pattern.newConst[S](out)
    }
  }
so if merge put the RHS of the val obj line directly into newConst, scalac is happy. But I need out actually in a variant of the macro.
I tried using different names, doesn't seem to matter.
Well, I managed to avoid the local variable now. Is this a known problem with macros that you cannot use local variables (or sometimes can and sometimes cannot)?