Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 04:03
    scala-steward review_requested #1440
  • 04:03
    scala-steward review_requested #1440
  • 04:03
    scala-steward opened #1440
  • Apr 09 20:59
    pshirshov commented #1439
  • Apr 09 20:58
    pshirshov commented #1439
  • Apr 09 20:55
    pshirshov commented #1439
  • Apr 09 20:55
    pshirshov commented #1439
  • Apr 09 20:46
    neko-kai commented #1439
  • Apr 09 20:43
    neko-kai commented #1439
  • Apr 09 20:39
    neko-kai edited #1439
  • Apr 09 20:38
    neko-kai assigned #1439
  • Apr 09 20:38
    neko-kai opened #1439
  • Apr 09 19:04
    pshirshov synchronize #1438
  • Apr 09 18:56
    pshirshov synchronize #1438
  • Apr 09 18:45
    pshirshov synchronize #1438
  • Apr 09 18:43
    pshirshov synchronize #1438
  • Apr 09 16:48
    pshirshov synchronize #1438
  • Apr 09 16:10
    pshirshov synchronize #1438
  • Apr 09 15:53
    pshirshov synchronize #1438
  • Apr 09 14:01
    VladPodilnyk synchronize #1422
Stan Sobolev
@Jacke

Ops, I solved it by produceF

Injector().produceF[IO](myModules, Roots.Everything).unsafeGet().map(_.get[Module[IO]]).unsafeRunSync

works well, thanks

vonchav
@voonchav_gitlab
Hi @neko-kai , any plan to upgrade LogStage to ZIO RC21? :)
Kai
@neko-kai
@voonchav_gitlab Not sure, due to upstream regressions: zio/zio#3851 Did you check if there’s a binary compatiblity error with logstage & RC21? It may just work with the update if the binary breakage didn’t touch the methods used in logstage.
vonchav
@voonchav_gitlab
@neko-kai I haven't tried upgrading to zio rc21 cuz I'm waiting for other libs to upgrade. But I can definitely try upgrading to rc21 with current version of logstage. Thanks!
vonchav
@voonchav_gitlab
@neko-kai Looks like that issue has been fixed and a rc21-1 is on the way :)
Kai
@neko-kai
@voonchav_gitlab Yup, will release an update soon
vonchav
@voonchav_gitlab
Awesome, thanks!
Kai
@neko-kai
@voonchav_gitlab just tagged 0.10.16 for zio-rc21-2
vonchav
@voonchav_gitlab
Thank you, sir! :)
Anton Solovyev
@Rosteelton

Hi all! I would like to ask about logstage with logback configuration.
Now I have json log in %msg field with this setting: LogSinkLegacySlf4jImpl(LogstageCirceRenderingPolicy()).
Is there some way to convert other slf4j logs (from other libraries) to logstage format to work with logback?

Or maybe you can tell me another way to use logstage api for json rendering with logback template

Paul S.
@pshirshov

Is there some way to convert other slf4j logs (from other libraries) to logstage format to work with logback?

You mean a way to make slf4j messages structure? Nope

In case you just wish to forward slf4j messages into logstage queue - use slf4j adaptor

Or maybe you can tell me another way to use logstage api for json rendering with logback template

I'm not sure what exactly you want to do. We have logstage-sink-slf4j which dumps logstage messages into slf4j. You may use it as a reference and implement your own logstage -> logback adapter

We also have logstage-adapter-slf4j which works as an slf4j backend and forwards sl4j->logstage

You can't magically make slf4j messages structured
You may write logstage messages into logback, but you'll have to write some code. We didn't do that because we don't need that but we would welcome your contribution
@Rosteelton
truongio
@truongio
Hi! One of our projects is using LogStage for logging. I'm trying to find out if there is some easy way to make it work well with Google Cloud Logging (https://cloud.google.com/logging/docs/setup/java). In our other services we have a logback.xml file with the configuration structure. Does LogStage have any support for this?
Kai
@neko-kai
@truongio Hi, you can use logstage-sink-slf4j to redirect LogStage to Slf4j

  // Router from LogStage to Slf4J
  "io.7mind.izumi" %% "logstage-sink-slf4j " % "0.10.16",
slf4j is usually backed by logback.
You may also write a custom LogSink with google cloud logging APIs
Valentin Willscher
@valenterry

Hey guys - what is the easiest way to change the output of the default IzLogger?
E.g. say instead of

[info] I 2020-08-21T11:00:23.984 (Main.scala:17)foo.Main.runApplication [21:ioapp-compute-0] Pizza is great

I would like to have

[info] I 2020-08-21T11:00 (Main.scala:17) […foo.Main.runApplication] Pizza is great

How do do that?

Kai
@neko-kai
@valenterry The easiest is to create a new ConsoleSink with a custom rendering policy. You can make a new rendering policy by passing a log template as an argument to new StringRenderingPolicy
Anton Semenov
@a7emenov
Could someone please take a look at 7mind/izumi#1201 ? The fix is fairly simple and I'd be happy to provide it myself, just want to be sure I'm not missing anything.
Kai
@neko-kai
@a7emenov Fix merged. Thanks for reporting the bug and bringing attention to it!
Anton Semenov
@a7emenov
@neko-kai cool! Could you please provide an estimate of when to expect a release with this fix included?
Kai
@neko-kai
@a7emenov will try to get it out today
Kai
@neko-kai
@a7emenov Released 0.10.19, you can grab it once it gets on central https://dev.azure.com/7mind/izumi/_build/results?buildId=3089&view=results
Anton Semenov
@a7emenov
Works like a charm, thanks.
Anton Solovyev
@Rosteelton
Hi! is there some way to start using BIO if I have a lot legacy with F[_]. For example:
trait OldOps[F[_]] {
  //Monad Error
  def old: F[Unit]
  //....many methods
}

trait New[F[+_, +_]] {
  def a: F[Throwable, Unit]
}

class NewImpl[F[+_, +_]: BIOMonadError](oldOps: OldOps[F]) extends New[F] {
  def a: F[Throwable, Unit] = oldOps.old ???
}
Kai
@neko-kai
@Rosteelton
You can use kind-projector's type lambda syntax *, to turn F[, ] into F[_] by partially the first argument to F (e.g. to Throwable):
class NewImpl[F[+_, +_]: BIOMonadError](
  oldOps: OldOps[F[Throwable, *]]
) extends New[F] {
  def a: F[Throwable, Unit] = oldOps.old
}
You'll need to add kind-projector to sbt to use this syntax, with the following line:
addCompilerPlugin("org.typelevel" % "kind-projector" % "0.11.0" cross CrossVersion.full)
Dermot Haughey
@hderms
is there a way to inject some JSON into any log that goes through logstage?
i'm trying to inject datadog ids
unfortunately i'm also on 0.6
do I have to extend the LogstageCirceRenderingPolicy
Kai
@neko-kai

@hderms Do you mean to inject Some Specific JSON into ALL the log messages? You can attach context parameters to logger using IzLogger#apply/IzLogger#withCustomContext and all the messages from that logger will include these parameters (https://izumi.7mind.io/latest/release/doc/logstage/index.html#log-algebras):

val newLogger =  logger("id" -> 1)
newLogger.info(s"abc cba")
// id=1 abc cba

In JSON the context fields will be under @context key (https://izumi.7mind.io/latest/release/doc/logstage/index.html#overview)
And can be arbitrary JSON. You can customize the JSON for each type with LogstageCodec implicit instances besides the default output

michealhill
@micheal-hill
Is it possible to materialise an Izumi Tag at runtime from a fqn of a class? Alternatively, is there some mechanism that I can use to serialise/deserialise the tag info?
Kai
@neko-kai

@micheal-hill You could try Java Serialization on a LightTypeTag value. Alternatively, every monomorphic tag is representable as 2 strings + 2 ints, but there's no mechanism yet to recover it from an existing ParsedLightTypeTag instance (sorry just hadn't thought about that ahead of time).
https://github.com/zio/izumi-reflect/blob/develop/izumi-reflect/izumi-reflect/src/main/scala/izumi/reflect/macrortti/LightTypeTag.scala#L249

You could make a PR for that to allow for efficient serialization/deserialization in new library version.

michealhill
@micheal-hill
Thanks!
michealhill
@micheal-hill
It looks like I can get everything I need from LightTypeTag, so I’ll probably go with Java Serialization on that - I don’t care about the details of the serialized value, other than to be able to deserialize it later.
Kai
@neko-kai
@micheal-hill Please report if that succeeds. I think the non-case class in LightTypeTag are missing the Serializable inheritance, so it could fail to work with Java serialization
Andreas Gabor
@an-tex
Hi! Are there any major changes in 1.0? GitHub just tells me "<Release notes pending>" ;) https://github.com/7mind/izumi/releases/tag/v1.0.0
Kai
@neko-kai

@an-tex
A lot of major changes and new features, most of them with some docs in the following sections:

Full release notes are indeed still pending...

There is also a slide deck for 1.0, but it contains no technical documentation https://github.com/7mind/slides/blob/master/10-izumi-1.0-functional-scala-2020/izumi-1.0.pdf
Andreas Gabor
@an-tex
awesome thanks!
Vladimir
@vladimir-lu
Thanks for the awesome library :)
Vladimir
@vladimir-lu
I'm looking into logging performance and noticed that currently the logstage RenderingPolicy is outputting a String - were there any considerations in not having this be Array[Byte] or similar?
Kai
@neko-kai
@vladimir-lu Performance wasn't a significant consideration beyond just being comfortably faster than logback/slf4j. If you're looking into it improving it further that would be much appreciated though!
Edvin Lundberg
@Edvin-san

Hi! I'm upgrading to distage 1.0.0 and noticed some macro dependencies when extending RoleAppMain.LauncherBIO2[IO] and RoleDescriptor.
Undefined macro parameter product-group, add ``-Xmacro-settings:product-group=<value>`` into ``scalac`` options [error] object MyRole extends RoleDescriptor {
Undefined macro parameter product-group, add ``-Xmacro-settings:product-group=<value>`` into ``scalac`` options [error] sealed abstract class MainBase(activation: Activation) extends RoleAppMain.LauncherBIO2[IO] {

I get similar errors for other macros. Eventually I have to add the following options as well as the sbt-git plugin.

          s"-Xmacro-settings:product-name=${name.value}",
          s"-Xmacro-settings:product-version=${version.value}",
          s"-Xmacro-settings:product-group=${organization.value}",
          s"-Xmacro-settings:sbt-version=${sbtVersion.value}",
          s"-Xmacro-settings:git-repo-clean=${git.gitUncommittedChanges.value}",
          s"-Xmacro-settings:git-branch=${git.gitCurrentBranch.value}",
          s"-Xmacro-settings:git-head-commit=${git.gitHeadCommit.value.getOrElse("")}",

I'm using scala 2.13.3 and sbt 1.3.8.
Are these dependencies included by design or something that accidentally slipped in?