Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:55
    lrytz commented #9770
  • 03:47
    SethTisue edited #787
  • 03:47
    SethTisue edited #787
  • 03:47
    SethTisue edited #785
  • 02:41

    xuwei-k on bundler

    (compare)

  • 02:41

    dependabot[bot] on bundler

    (compare)

  • 02:41

    xuwei-k on main

    Bump nokogiri from 1.11.4 to 1.… Merge pull request #2191 from s… (compare)

  • 02:41
    xuwei-k closed #2191
  • 02:41

    xuwei-k on main

    Bump nokogiri from 1.11.4 to 1.… Merge pull request #1283 from s… (compare)

  • 02:41
    xuwei-k closed #1283
  • 02:09
    SethTisue closed #1492
  • 02:09
    SethTisue commented #1492
  • 02:08
    SethTisue commented #1492
  • 02:04
    SethTisue commented #1492
  • 02:02
    SethTisue edited #1492
  • 02:01
    SethTisue edited #1492
  • 01:56
    SethTisue edited #1492
  • 01:54
    SethTisue edited #1492
  • 01:54
    SethTisue edited #1492
  • 01:53
    SethTisue edited #1492
Luis Miguel Mejía Suárez
@BalmungSan

@agaro1121 does:

lazy val otherModule=
  (project in file("foo"))
    .dependsOn(moduleWithResources % "compile->compile;test->test;provided->provided")

work?

Anthony Garo
@agaro1121
Let me try that
raymond95
@raymond95:minds.com
[m]
agaro1121 (Anthony Garo): are you interested
som-snytt
@som-snytt
@Sciss that is a bug, as it should warn if there is a value Void in scope, not the java type. Probably it's confused by internal representation of java things as companions. It needs a place for Void.TYPE.
som-snytt
@som-snytt
I think the nowarn works on the enclosing def, @nowarn def f = ....
Also charming notation:
scala> def f() = (s match { case "$Void" => }): @annotation.nowarn
def f(): Unit @scala.annotation.nowarn
Hanns Holger Rutz
@Sciss
thanks
raymond95
@raymond95:minds.com
[m]
hardlianotion (hardlianotion): hi
Sciss (Hanns Holger Rutz) how are you
zeroexcuses
@zeroexcuses
Machine A, B are two x86_64 linux machines with identical software and identical hardware. How complicated is it, while a server written in scala is running on machine A, to migrate it to machine B? (Assume open tcp connections, but no open files).
Hanns Holger Rutz
@Sciss

in current sbt which is very picky about version mismatches, is it possible to tell it to shut up while I work with locally pub lished snapshots? e.g.

incompatible:
[error]
[error]     * de.sciss:audiofile_2.13:2.4.0 (pvp) is selected over 2.4.0-SNAPSHOT
[error]         +- de.sciss:mellite-core_2.13:3.7.0-SNAPSHOT          (depends on 2.4.0)
[error]         +- de.sciss:scalacollider_2.13:2.7.1                  (depends on 2.4.0)
[error]         +- de.sciss:sonogramoverview_2.13:2.3.0               (depends on 2.4.0)
[error]         +- de.sciss:lucre-synth_2.13:4.9.0-SNAPSHOT           (depends on 2.4.0-SNAPSHOT)

?

Guillaume Martres
@smarter
I don't know, but if you're publishing the dependencies yourself you can also change their versionScheme to make sbt happy
Hanns Holger Rutz
@Sciss
oof
I prefer to temporarily set tyhe policy in the dependent project to treat x.y.z-SNAPSHOT same as x.y.* ?
Hanns Holger Rutz
@Sciss
tells me to look at evictionErrorLevel but sbt docs don't reveal anything about it
ThisBuild / evictionErrorLevel := Level.Info does the trick
ahad1234
@ahad1234
Hey All!
i am trying to mock one of the scala objects to test some functions,
can anyone of you tell me the possibilities with it?
With some tries I get this exception:
java.lang.NoSuchMethodError: org.mockito.internal.invocation.InterceptedInvocation.getRealMethod()Lorg/mockito/internal/invocation/RealMethod;
Matthias Berndt
@mberndt123
OK, so why does this not compile?
trait Foo {
  type A
  def f(ta: T[A] => Unit): Unit = ()
}

sealed trait T[A]
case object I extends T[Int]
case object S extends T[String]

trait Bar { self: Foo =>
  f {
    case I => println("Int")
    case S => println("String")
  }
}
[error] /tmp/test/src/main/scala/mberndt123/Main.scala:12:10: pattern type is incompatible with expected type;
[error]  found   : I.type
[error]  required: T[Bar.this.A]
[error]     case I => println("Int")
[error]          ^
[error] /tmp/test/src/main/scala/mberndt123/Main.scala:13:10: pattern type is incompatible with expected type;
[error]  found   : S.type
[error]  required: T[Bar.this.A]
[error]     case S => println("String")
[error]          ^
[error] two errors found
It says the pattern type is incompatible, but there's actually no way for it to know that.
Guillaume Martres
@smarter
it compiles in scala 3.
Matthias Berndt
@mberndt123
seems like I'll need to migrate then...
Matthias Berndt
@mberndt123
And of course I've got a bazillion dependencies with macros.
Seth Tisue
@SethTisue
@zeroexcuses not sure what you mean by "migrate". also it seems like a JVM question rather than a Scala question per se, if I understand correctly?
maybe even an OS-level question rather than a JVM question? I don't think a TCP connection can "migrate" like that, OS-wise? (if my guess by what you mean by "migrate" is correct)
Matthias Berndt
@mberndt123
So I have this trait:
private[wernicke] trait Foo[G[_]]:
  def apply[L, R]: PartialFunction[(G[L], G[R]), Result[G, L, R, ?]]
And I thought I'd be able to use Scala 3's polymorphic function literals:
val f: Foo[G] = [L, R] => { case (Bla, Blurb) => ??? }
Guillaume Martres
@smarter
Yeah that's not supported yet
Matthias Berndt
@mberndt123
And I get
[error] -- Error: /home/mbt/newp/src/test/scala/NewTest.scala:141:13 
[error] 141 |      [L, R] => {
[error]     |             ^
[error]     |Implementation restriction: polymorphic function literals must have a value parameter
that's disappointing :-(
Is that being worked on?
or is there some workaround?
Guillaume Martres
@smarter
Polymorphic SAM types support is something I'd like to work on but haven't found the time so far
Same for parameterless polymorphic functions
(you'd need both here)
Matthias Berndt
@mberndt123
I see…
Matthias Berndt
@mberndt123
That would be useful for what I'm working on right now.
I can work around it, but it's pretty ugly
type inference for PartialFunction also doesn't seem to work all that great, I need to annotate the type to make it work.
Matthias Berndt
@mberndt123
So here's how I work around the implementation restriction:
sealed trait T[A]
object T:
  case object I extends T[Int]
  case object S extends T[String]

trait Foo[G[_]]:
  def apply[L, R]: PartialFunction[(G[L], G[R]), Unit]

class FooPartiallyApplied[G[_]]:
  def apply(f: [L, R] => Unit => PartialFunction[(G[L], G[R]), Unit]) =
    new Foo:
      def apply[L, R] = f(())

object Foo:
  def apply[G[_]]: FooPartiallyApplied[G] = new FooPartiallyApplied[G]

val x =
  Foo[T] { [L, R] => (_: Unit) => ({
      case (T.I, T.S) => println("Int-String")
    }): PartialFunction[(T[L], T[R]), Unit]
  }
it's… not good
So I need this (_: Unit) thing because it wants a value parameter, and I need the Foo.applymethod to work around the fact that SAM types are not supported
and I need : PartialFunction[(T[L], T[R]), Unit] to convince the type checker
but I think at this point it's better to just give up on the polymorphic lambda syntax for now and just write an anonymous class instead. That's probably easier to understand.
Leif Warner
@LeifW
Is there a JRE-only Docker image available for Java 17 people like to use? The Oracle OpenJDK and Eclipse Temurin ones seem to be full JDK only.
raymond95
@raymond95:minds.com
[m]
LeifW (Leif Warner): yds
Yes LeifW (Leif Warner)
jodersky
@jodersky

Hi! I have a question regarding some recent-ish documentation changes to the Quotes API. Recently, this comment in Quotes.scala came to my attention, specifically the part that talks about symbol.tree.tpe being an antipattern:

Warning: avoid using this method in macros.

[...]

Anti-pattern: The following code is an anti-pattern:

 symbol.tree.tpe

It should be replaced by the following code:

 tp.memberType(symbol)

I don't understand the suggested alternative. What is tp in this example, and where would it come from?

I have to admit that I have actually used this pattern quite frequently in the past. The most prominent case being a macro which inspects the types of a method's parameters obtained via a symbol. It looks something like this:

for (paramsSyms <- method.paramSymss) {
  for (paramSym <- paramsSyms) {
    paramSym.tree.asInstanceOf[ValDef].tpt.tpe.asType match { // <---this is the antipattern, how could this be cleaned up?
      case '[t] =>
        // do something based on the param type...
    }
  }
}

This has always felt as a bit of a contortion, and now that I see that it is indeed considered an antipattern, I wonder what alternative there could be.

raymond95
@raymond95:minds.com
[m]
jodersky (jodersky): okay DM me I will help you out