Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:04
    dsluo opened #2023
  • May 14 23:32
    erguven opened #2022
  • May 14 22:35
    dwijnand commented #9715
  • May 14 22:34
    dwijnand labeled #9715
  • May 14 22:28
    smarter commented #2672
  • May 14 22:25
    dwijnand commented #2672
  • May 14 21:53
    dwijnand labeled #9410
  • May 14 21:21
    dwijnand closed #6944
  • May 14 21:21
    dwijnand commented #6944
  • May 14 21:14
    dwijnand commented #8563
  • May 14 21:13
    dwijnand labeled #8563
  • May 14 18:50
    som-snytt commented #9630
  • May 14 18:36
    siddhant3s opened #2021
  • May 14 18:35
    SethTisue edited #1413
  • May 14 18:19
    siddhant3s opened #2020
  • May 14 18:11
    SethTisue synchronize #1413
  • May 14 18:07

    SethTisue on 2.13.x

    Restore SubstMap's public API (… Merge pull request #9630 from S… (compare)

  • May 14 18:07
    SethTisue closed #9630
  • May 14 16:48
    SethTisue commented #9630
  • May 14 16:48
    SethTisue commented #9630
Rob Norris
@tpolecat
[error] Multiple repositories are found:
[error] [orgtpolecat-1125] status:open, profile:org.tpolecat(23052d71604fff) description: Implicitly created (auto staging).
[error] [orgtpolecat-1126] status:open, profile:org.tpolecat(23052d71604fff) description: Implicitly created (auto staging).
[error] Specify one of the repository ids in the command line
[error] java.lang.IllegalStateException: Found multiple staging repositories
One of my builds started doing this when doing sonatypeReleaseAll. What have I done and how do I fix it?
I went in and dropped them in the Nexus UI and tried again and it did it again.
Seth Tisue
@SethTisue
fwiw: when we're publishing Scala modules we almost always end up with multiple staging repos, a nondeterministic number of them. usually we just release them all at once through the Sonatype web and it's fine. some percentage of time, the files for a single target end up split between two staging repos, which can then neither be closed or released, and we have to run that target (and any targets that ended up mixed up in the affected repos) again
if you're ending up with multiple staging repos when you didn't before, it might be timing related, like maybe your build crossed some sort of threshold on how long it takes between one target and the next
the good news is that it might be fine to just release the multiple repos via the web UI, and not use sonatypeReleaseAll
anyway, I have only very partial understanding of this stuff, so perhaps someone who understands it better will have better advice for you.
</fwiw></ihavenoideawhatimdoing>
Li Haoyi
@lihaoyi
the multiple staging repos thing is a sbt quirk. Mill creates one staging repo, and always releases just that, without races in the presence of concurrent workflows
not sure what SBT is doing; mill’s code was written just following the sonatype api docs and it seems to do what i’d expect
Rob Norris
@tpolecat
Hell. Ok. Is it sbt or sbt-sonatype?
The plugin surely.
Seth Tisue
@SethTisue
it seems the ticket of record is xerial/sbt-sonatype#83
that's with +publishSigned though. often the repos I work in aren't using +, they're using the Travis-CI matrix to do the different parts. so idk
Rob Norris
@tpolecat
Nexus is the JIRA of package repositories. We need our own, it’s just absolute hell.
OlegYch
@OlegYch
who's going to support our version of hell
Rob Norris
@tpolecat
Scala Center?
They’re looking for ideas!
This has worked fine for me for many prior releases. It just started happening.
I feel like I’m taking crazy pills. I had a different random automation failure yesterday.
Rob Norris
@tpolecat
I need to switch to a language nobody uses so I won’t have to worry about this stuff.
I guess I could try Mill. @lihaoyi is there a way to run paradox and push stuff to gh-pages?
Luis Miguel Mejía Suárez
@BalmungSan

Hi,

I have something like this:

trait Factory[F[_]] {
  type R[A]
  def create[A](a: => A): R[A]
}

object Factory {
  type Aux[F[_], _R[_]] = Factory[F] { type R[A] = _R[A] 

  type Id[A] = A

  implicit val FutureFactory: Factory.Aux[Future, Id] =
    new Factory[Future] {
      override final type R[A] = A
      override final def create[A](a: => A): A = a
    }
}

object Driver {
  def driver[F[_]]: DriverPartiallyApplied[F] = new DriverPartiallyApplied(dummy = true)

  private final class DriverPartiallyApplied[F[_]](private val dummy: Boolean) extends AnyVal {
    def apply[R[_]](uri: String)(implicit F: Factory.Aux[F, R]): R[Driver[F]] =
      F.create(...)
  }
}

Now, on another project I would like to do this:

val driver: Driver[Future] = Driver.driver[Future]("uri")

But that does not compile with this error:

found: [R[_]]R[neotypes.Driver[scala.concurrent.Future]]
required: neotypes.Driver[scala.concurrent.Future]

If I leave out the explicit type signature, it works as expected. The compiler is able to figure out latter that driver is a Driver[Future].

Anyone knows how can I fix that?

Hanns Holger Rutz
@Sciss

Is it possible to define "negative implicits", like

trait Ex[+A]
case class Const[A](value: A) extends Ex[A]

implicit def const[A](x: A): Ex[A] = Const(x)

such that const cannot be called when A <: Ex[_] ? I have no way to put an upper bound on A, e.g. it could be Int, String, java.io.File, ... types over which I have no control.

Luis Miguel Mejía Suárez
@BalmungSan
@Sciss Can not test it right now, but I believe you can use Shapeless =:!=.
Something like implicit def const[A](x: A)(implicit ev: A =:!= Ex[_]): Ex[A] = Const(x)
Hanns Holger Rutz
@Sciss
sounds good, I wonder how that's implemented. Of course can't google =:!=, any pointer to the relevant documentation?
must be a macro, I guess?

Perhaps easier solution would be if I have

   def runWith(map: Ex[Map[String, _]]) = ???

but I need to restrict the value types in the map, for example by coming with a type class; the problem being that the value types may vary (it's a heterogeneous map, Scala's arch enemy)

Hanns Holger Rutz
@Sciss
So I want a Map[String, Int] to be able to be lifted, but not Map[String, Ex[_]].
So perhaps a simpler question is, "how can I place constraints on the value types of a heterogeneous map", with emphasis on the user being able to type it with literals without the need to use type ascriptions etc.

For instance:

def title: Ex[String]

trait Runner {
  def runWith(attr: Ex[Map[String, _]]): Unit
}

def r: Runner

r.runWith(Map("foo" -> 123, "bar" -> title))

and what I need to enforce is the expansion

Map(Const("foo") -> Const(123), Const("bar") -> title)

and prevent

Const(Map("foo" -> 123, "bar" -> title /* bad */))
Hanns Holger Rutz
@Sciss
I have the hunch that I should introduce trait ExMap[K, V] extends Ex[Map[K, V]] so that I can restrict lifting from Map constructor.
Hanns Holger Rutz
@Sciss
Like how can I get rid of the : Ex[String] annotations here:
trait ExMapTest3 {
  trait Ex[+A]

  implicit def const[A](in: A): Ex[A]

  implicit def liftMap[K, V](m: Map[Ex[K], Ex[V]]): ExMap[K, V]

  trait ExMap[K, V] extends Ex[Map[K, V]]

  def runWith(m: ExMap[String, Any]): Unit

  def title: Ex[String]

  runWith(
    Map(("foo": Ex[String]) -> ("bar": Ex[String]))  // not nice
  )

  runWith(
    Map(("foo": Ex[String]) -> title)
  )
}
Hanns Holger Rutz
@Sciss

I guess the best would be to just surrender to

implicit def const[A: Permitted](in: A): Ex[A]

and give dozens of type classes for all primitives etc.; perhaps I could use marker trait scala.Immutable for types I control.

Hanns Holger Rutz
@Sciss

along these lines

  implicit def const[A: Value](x: A): Ex[A] = Const(x)

  object Value {
    implicit object anyVal    extends Value[AnyVal  ]
    implicit object string    extends Value[String  ]
    implicit object file      extends Value[File    ]
    implicit object spanLike  extends Value[SpanLike]

    implicit def tuple  [A: Value, B: Value]: Value[(A, B)] = null

    implicit def option [A: Value]: Value[Option[A]] = null
    implicit def seq    [A: Value]: Value[Seq   [A]] = null
  }
  trait Value[-A]

0: Ex[Int]  // ok
Some("foo"): Ex[Option[String]]  // ok
Some("foo": Ex[String]): Ex[Option[Ex[String]]]   // forbidden

Is there any issue with = null? Would like to avoid instantiations for throw away witnesses.

Luis Miguel Mejía Suárez
@BalmungSan
@Sciss Sorry, I had to go for a while. I am a little lost right now. What is your ultimate goal?
I think, at the end, you only want that the runWith method only be called with a Map[String, _] where you have a subset of what is valid for the values. Am I right?
Hanns Holger Rutz
@Sciss
Yes. I think I will try with the last approach, even if it means adding a lot of third-party dummy type class instances.
it's just annoying having to add lots of import statements after a while to bring them into scope. I think there is some plan to introduce export primitives or so into Scala in the future.
Luis Miguel Mejía Suárez
@BalmungSan
Do you expect the Map to always be a literal?
Hanns Holger Rutz
@Sciss
definitely not. There could be other sources producing Ex[Map] which are not constant.
Luis Miguel Mejía Suárez
@BalmungSan
Uhm, I was about to propose a Macro, but now it does not make sense.
Hanns Holger Rutz
@Sciss
yeah, I'd rather avoid them
Fabio Labella
@SystemFw

@Sciss

sounds good, I wonder how that's implemented. Of course can't google =:!=, any pointer to the relevant documentation?

In case you're still interested, this is the implementation for <:!< and =!:=

def unexpected : Nothing = sys.error("Unexpected invocation")

  // Type inequalities
  trait =:!=[A, B] extends Serializable

  implicit def neq[A, B] : A =:!= B = new =:!=[A, B] {}
  implicit def neqAmbig1[A] : A =:!= A = unexpected
  implicit def neqAmbig2[A] : A =:!= A = unexpected

  @scala.annotation.implicitNotFound("${A} must not be a subtype of ${B}")
  trait <:!<[A, B] extends Serializable

  implicit def nsub[A, B] : A <:!< B = new <:!<[A, B] {}
  implicit def nsubAmbig1[A, B >: A] : A <:!< B = unexpected
  implicit def nsubAmbig2[A, B >: A] : A <:!< B = unexpected

it basically encodes negation via absurd. Let's pick =:!= for example, <:!< works the same: instead of providing an implicit instance when type A is not equal to B, it provides an instance that is valid for any two A and B (neq), and then two instances that are valid when A == B (neqAmbig1 and neqAmbig2). So, if you ask for Int =!:= String , new is the only relevant instance, and things compile. If you ask for Int =!:= Int, the compile finds both neqAmbig1 and neqAmbig2 at higher specificity than neq, but same specificity wrt to each other, so compilation fails when two types are equal, which is the desired semantics

Hanns Holger Rutz
@Sciss
@SystemFw thanks for the explanation, good to know it works without macros
Rob Norris
@tpolecat
@ def notInt[A](a: A)(implicit ev: A =:!= Int): A = a 
defined function notInt

@ notInt("foo") 
res3: String = "foo"

@ notInt(3) 
cmd4.sc:1: ambiguous implicit values:
 both method neqAmbig1 in package shapeless of type [A]=> A =:!= A
 and method neqAmbig2 in package shapeless of type [A]=> A =:!= A
 match expected type Int =:!= Int
val res4 = notInt(3)
                 ^
Compilation Failed

@ def foo[A](a: A): A = notInt(a) 
defined function foo

@ foo(1) 
res5: Int = 1
It's really easy to defeat the type inequality constraint. Just FYI.
Hanns Holger Rutz
@Sciss
!
Jon Pretty
@propensive

@saifjsl I think @propensive still has Scala 2.6 in production somewhere. People are reluctant to destabilize codebases just for the sake of keeping up to date.

Confirmed. I have a Scala 2.6.1 web application which runs for about a month each year. My client keeps paying me more each year to keep it running. My biggest concern isn't so much the Scala 2.6.1 compiler but the shoddy coding practices I used extensively in about 2007.

Dale Wijnand
@dwijnand
It would be interesting to see that code. Maybe you can anonymise it and open-source it, somehow?