Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 11 20:01
    neko-kai closed #1482
  • May 11 16:03
    scala-steward opened #1482
  • May 11 16:03
    scala-steward review_requested #1482
  • May 11 16:03
    scala-steward review_requested #1482
  • May 11 07:56
    neko-kai closed #1481
  • May 10 22:03
    scala-steward review_requested #1481
  • May 10 22:03
    scala-steward review_requested #1481
  • May 10 22:03
    scala-steward opened #1481
  • May 10 18:55
    pshirshov synchronize #1466
  • May 10 17:57
    pshirshov synchronize #1466
  • May 10 08:59
    neko-kai closed #1480
  • May 10 06:05
    scala-steward review_requested #1480
  • May 10 06:05
    scala-steward review_requested #1480
  • May 10 06:05
    scala-steward opened #1480
  • May 09 18:44
    neko-kai edited #1479
  • May 09 18:43
    neko-kai edited #1479
  • May 09 00:02
    neko-kai synchronize #1479
  • May 07 16:58
    neko-kai edited #1479
  • May 07 16:57
    neko-kai edited #1479
  • May 07 16:57
    neko-kai review_requested #1479
vonchav
@voonchav_gitlab
Also, I don't think logstage-config has 0.10.2-M8 on Maven. I only see 0.9.17. sbt fails downloading 0.10.2-M8 either.
vonchav
@voonchav_gitlab
Getting this exception when trying to initialize with withFiberId. I'm using ZIO RC18. I think it is because of the binary incompatibility.
Exception in thread "main" java.lang.NoSuchMethodError: zio.ZIO$.succeed(Ljava/lang/Object;)Lzio/ZIO; at izumi.functional.bio.impl.BIOZio.pure(BIOZio.scala:20) at izumi.functional.bio.impl.BIOZio.pure(BIOZio.scala:17) at izumi.functional.bio.package$BIOApplicative.$init$(package.scala:83) at izumi.functional.bio.impl.BIOZio.<init>(BIOZio.scala:17) at izumi.functional.bio.impl.BIOZio$.<init>(BIOZio.scala:15) at izumi.functional.bio.impl.BIOZio$.<clinit>(BIOZio.scala:15) at logstage.LogstageZIO$$anon$1.<init>(LogstageZIO.scala:13) at logstage.LogstageZIO$.withFiberId(LogstageZIO.scala:13)
Kai
@neko-kai
@voonchav_gitlab There’s now no logstage-config artifact, so that’s correct. There will be a release for ZIO RC18-2 once it’s out, which should be about today-tomorrow (https://github.com/zio/zio/releases/tag/untagged-9c897cd6b002dd43fa73)
There are some issues in 18-1 that can cause deadlocks if you’re using cats, so I’d wait for 18-2 anyway
vonchav
@voonchav_gitlab
Got it. I'm waiting on RC18-2 too :) Thanks @neko-kai
Kai
@neko-kai
@voonchav_gitlab If you’re looking for alternative to logstage-config, there’s configuration from HOCON in distage-framework, it’s also a good first issue to extract it out of there into a separate module - 7mind/izumi#868
vonchav
@voonchav_gitlab
Thanks, I will check it out.
vonchav
@voonchav_gitlab
@neko-kai Is update (using zio rc18-2) coming soon? :)
Kai
@neko-kai
@voonchav_gitlab I think tomorrow. I’m going to finish a macro to support zio.Has today, add the docker bugfixes on milestone https://github.com/7mind/izumi/milestone/11 and then ship
vonchav
@voonchav_gitlab
no rush. was just wondering. really want to switch to logstage :)
thanks!!!
Kai
@neko-kai
@voonchav_gitlab got delayed, but it’s happening soon: 7mind/izumi#960 ...
vonchav
@voonchav_gitlab
thanks for the update. much appreciated.
vonchav
@voonchav_gitlab
Thanks Kai. I just upgraded to 0.10.2. Now zioLogger works!
Kai
@neko-kai
:+1:
vonchav
@voonchav_gitlab
Hi @neko-kai , is there a doc/md that describes how to customize log format, similar to pattern in logback: %date{ISO8601} [%thread] %-5level %logger{72} - %msg%n%ex?
Kai
@neko-kai
@voonchav_gitlab You need to create your own StringRenderingPolicy in code - see izumi.logstage.sink.ConsoleSink for an example - there are two bundled policies - ColoredConsoleSink - the default & SimpleConsoleSink for terminals without color
vonchav
@voonchav_gitlab
Got it. I'll look into it. I'm more interested in the format, rather than the colors, which is fine by me :)
Kai
@neko-kai
Yeah, the policy specifies both (colours are just special characters added to the text, interpreted by the terminal)
vonchav
@voonchav_gitlab
cool cool. will dig into it. thank you.
vonchav
@voonchav_gitlab
Hi @neko-kai I suppose, if I declare a val for my message outside of the logger call, the logStage macro wouldn't do the intended interpolation in that case. Can you confirm?
val message = s"A is $a; B is $b"
logger.info(message)
Kai
@neko-kai
@voonchav_gitlab Yes. If you want to assemble a message before-hand use Message:
import logstage.Log.Message
import logstage.Info

val message = Message(s"A is $a; B is $b”)
logger.log(Info)(message)
vonchav
@voonchav_gitlab
Nice. @neko-kai It'd be nice that Message be added to the docs... well, if I get a chance, I'll submit a PR.
Kai
@neko-kai
@voonchav_gitlab That would be much appreciated! Thanks :+1:
andres-pipicello
@andres-pipicello
Hi! I want to use the plugins from the Izumi SBT toolkit. I see that it has moved to the sbtgen repo, but it seems that the style described in the documentation is deprecated. Is that right?
Kai
@neko-kai
@andres-pipicello Yeah, basically, they’re not used much except for the BOM part and IzumiResolverPlugin. Instead we’ve moved to describing builds with sbtgen’s DSL. You can still add & use them with:
addSbtPlugin("io.7mind.izumi.sbt" % "sbt-izumi" % "0.0.53")
Adriani Furtado
@Adriani277

Hi all, I am currently trying izumi-fundamentals, I have something like this

import izumi.functional.bio.{BIOMonadError, F}
case class MyClass[F[+_, +_]: BIOMonadError](){
    F.fail("Some Error")
}

From looking at the izumi BIO page, I am lead to believe the code above should give me back an F however I am getting back a ZIO.
Is there something I may be missing here? There is no ZIO imports in scope

Adriani Furtado
@Adriani277
On a separate note, is there something similar to cats.Parallel in BIO? I have a BIOMonadError in scope and would like to perform 2 operations in parallel but the ap2/map2 instance is Monadic
Kai
@neko-kai
@Adriani277
Enable -Ypartial-unification scalac option or update to Scala 2.13 - this will fix the issue
@Adriani277 BIOAsync provides race & parTraverse
Adriani Furtado
@Adriani277

@neko-kai thanks for the info. I am trying to basically achieve a zipPar
I currently have the following simple/naive implementation

  def zip2Par[F[+_, +_]: BIOFork: BIOMonadError, E, A0, A1](
      a: F[E, A0],
      b: F[E, A1]
  ): F[E, (A0, A1)] =
    for {
      f0 <- a.fork
      f1 <- b.fork
      j0 <- f0.join.catchAll ( e =>
             f1.interrupt *> BIOMonadError[F].fail(e)
           )
      j1 <- f1.join
    } yield (j0, j1)

Is this functionality something that already exists in BIO?

Kai
@neko-kai
@Adriani277 Nope, zipPar is not exposed currently, it would be great if you could submit a pull request adding it to BIOAsync. (Or you could even add BIOParallel sub-hierarchy, if you got a a grip of how subhierarchies such as BIOAsk, BIOBifunctor and BIOProfunctor are implemented)
Adriani Furtado
@Adriani277
@neko-kai awesome. I will have a go at it
Kai
@neko-kai
@Adriani277 Thanks! :+1:
Adriani Furtado
@Adriani277
@neko-kai, I have raised a PR 7mind/izumi#1029
Adriani Furtado
@Adriani277
@neko-kai I have been looking at adding cats instance for Parallel but I am not really sure how it can be done. Parallel needs a Monad and an Applicative but I don't quite see what we can provide for both values although we now have BIOParallel. Any ideas?
Kai
@neko-kai

@Adriani277 Assuming you’re inheriting a new class BIOCatsParallel from BIOCatsSync, where:

class BIOCatsSync[F[+_, +_]](override val F: BIO[F]) extends BIOCatsBracket[F](F) with cats.effect.Sync[F[Throwable, ?]]

Then the Monad[M] is fulfilled by thisoverride val monad: Monad[F[Throwable, ?]] = this
The Parallel.applicative field is the parallel applicative - aka an applicative where zip is implemented by zipPar. So you’d override type F[A] = F[Throwable, A] and implement the applicative inline:

override lazy val applicative: Applicative[F] = new Applicative[F] {
  def zip = zipPar
  def traverse = parTraverse
  def ap = ...
}
The parallel typeclass witnesses a two-way conversion between this M and some kind of parallel variant of M, F. In this case the parallel variant is the same type, we just use different functions to implement the parallel applicative.
Adriani Furtado
@Adriani277
Ahh I see, thanks for the help
Kai
@neko-kai
:+1:
Adriani Furtado
@Adriani277
@neko-kai I believe I have most of the code for cats.Parallel I have come across an issue which I am not sure what the best way to resolve it is
Kai
@neko-kai
@Adriani277 Answered you in the review
Didac
@umbreak
Hi everyone!
Is there a way to use with the distage testing framework something like the scalaTest BeforeAndAfterAll, where I can have access to the injected Resources?
I want to do some sort of health checks into an endpoint where the docker container is running before starting my tests
Paul S.
@pshirshov
You may create shared ("memoized") resources to get behaviour identical to Before/After hooks. Though you don't have to do that manually, distage-testkit can perform integration checks (including checks on docker containers) for you
  override protected def config: TestConfig = {
    super.config.copy(
      memoizationRoots = Set(DIKey.get[PgSvcExample]),
...
That's how you declare a dependency to be shared across all the tests
PgSvcExample may be a resource, in that case it would be created before all the tests and finalized after all the tests
Kai
@neko-kai
@umbreak The above suggestion is correct, the way to do this currently is to create a DIResource with acquire/release actions that are your before/afterAll actions. Then you can pin the resource to be global via memoizationRoots AND pin the resource to be a dependency of all tests such that it doesn’t need to be summoned manually as a parameter for its acquire/release actions to execute.
final class MyTransactor[F[_]] extends DIResourceBase[F, MyTransactor[F]] {
   def acquire = waitForPostgres
   def release = deleteAllTables
}

trait MyTest extends DistageAbstractScalatestSpec[IO] {
  override def config = super.config.copy(
    memoizationRoots = super.config.memoizationRoots ++ Set(
      DIKey.get[MyTransactor[F]], // force MyTransactor to be acquired/released only once per test-run 
    ),
    forcedRoots = super.config.forcedRoots ++ Set(
      DIKey.get[MyTransactor[F]], // force MyTransactor to be acquired/released always, no matter if the running tests declare it as a parameter
    )
  ) 
}
Paul S.
@pshirshov
Technically we have basic support for 'await until ready' semantic. I think we may improve the docker layer to support your scenario too (by the way, P/Rs are welcomed)