Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 05 00:28
    darkfrog26 opened #239
  • Dec 05 00:28

    darkfrog26 on youi-client-0.14.4

    Update youi-client to 0.14.4 (compare)

  • Dec 05 00:28

    darkfrog26 on profig-3.2.7

    (compare)

  • Dec 05 00:28
    darkfrog26 closed #236
  • Dec 05 00:28
    darkfrog26 commented #236
  • Dec 05 00:28
    darkfrog26 opened #238
  • Dec 05 00:28

    darkfrog26 on profig-3.2.8

    Update profig to 3.2.8 (compare)

  • Nov 14 00:26
    darkfrog26 opened #237
  • Nov 14 00:26

    darkfrog26 on scala-collection-compat-2.6.0

    Update scala-collection-compat … (compare)

  • Nov 14 00:26
    darkfrog26 opened #236
  • Nov 14 00:26

    darkfrog26 on profig-3.2.7

    Update profig to 3.2.7 (compare)

  • Nov 14 00:26
    darkfrog26 opened #235
  • Nov 14 00:26

    darkfrog26 on fabric-parse-1.1.1

    Update fabric-parse to 1.1.1 (compare)

  • Nov 07 00:27
    darkfrog26 opened #234
  • Nov 07 00:27

    darkfrog26 on sbt-scoverage-1.9.2

    Update sbt-scoverage to 1.9.2 (compare)

  • Nov 07 00:27
    darkfrog26 opened #233
  • Nov 07 00:27

    darkfrog26 on scala-library-2.13.7

    Update scala-library to 2.13.7 (compare)

  • Nov 03 00:21

    darkfrog26 on master

    Added Scala 2.11 support back (compare)

  • Oct 28 14:25

    darkfrog26 on 3.6.3

    (compare)

  • Oct 28 14:25

    darkfrog26 on master

    Release 3.6.3 (compare)

Maatary
@Maatary
I think i figured that it is a scribe issue, i double check the threading i am always on the same thread. I used the enhanced formatter just to give it a try, and in that scenario the problem never happens and it confirm the threading as well (everything on the same thread). I wonder if it is because there is a multi-line support missing. However, the enhanced formatter does not look like what i want at all, so i can't go with it. I'm not sure how the formatter works to be fair. I would like to keep the default, but have that multi-line support, or that thing that stop my debug and info log to be mixed up somehow. I would like to do so without creating orphan either. Do you think you could help with this ?
Maatary
@Maatary
I spoke super fast, and the multiLine addition to the formatter does not seem to solve it either. At least i tried to add to the enhanced for matter and it did not stop the original problem. Hence confused. How is it possible that a message is cut in the middle ? Do we use stderr for debug and stdout for info ? really confused on this. Hope you can guide :)
68747470733a2f2f66696c65732e6769747465722e696d2f3536613763326262653631303337383830396265353239332f586f4e472f7468756d622f53637265656e2d53686f742d323032312d31302d32352d61742d31392e31322e31302e706e67.png
Maatary
@Maatary

I have found the following comment in your code:

object SystemOutputWriter extends Writer {
  /**
    * If true, will always synchronize writing to the console to avoid interleaved text. Most native consoles will
    * handle this automatically, but IntelliJ and Eclipse are notorious about not properly handling this.
    * Defaults to true.
    */

Indeed I am working in Intellij. So not sure if there is anything i could do actually ....

Matt Hicks
@darkfrog26
this is very strange
@Maatary can you try running in a native terminal instead of IntelliJ to see if that makes a difference?
Matt Hicks
@darkfrog26
I believe the reason is that multiple threads are calling println, and even though the actual execution of the println is wrapped in a synchronized block, I think that because it's not being flushed between calls, it is asynchronously applying. I would say this is a bug in IntelliJ, but a solution might be to add flushing after each println.
I just pushed a commit that adds a new feature that may solve your problem.
@Maatary if you don't mind checking out from master and calling sbt publishLocal you can depend on 3.6.3-SNAPSHOT locally and set SystemOutputWriter.alwaysFlush = true and see if that resolves the issue
Maatary
@Maatary
@darkfrog26 Just saw this. I can confirm that outside of Intellij it works properly.
Sorry for the stupid question but How do I set that config SystemOutputWriter.alwaysFlush = true
Maatary
@Maatary
If you don't mind could provide me with the config lines root.withXXX( .... SystemOutputWriter.alwaysFlush = true .... ) not sure here
Matt Hicks
@darkfrog26
Just set that variable during the init of your app.
it's a var on an object, so a singleton
Maatary
@Maatary
ok will try it out and let you know
Maatary
@Maatary
Tried, and it does not make a difference with Intellij. Actually it is mostly in the SBT Shell. The normal terminal seems to work ok
So I guess i will just leave it as it is. U"nfortunate cause the sbt shell is cool. but we can't fix intellij stuff ....
Matt Hicks
@darkfrog26
oh, interesting
that's probably why I never saw it, I never use the SBT Shell, I just use the IntelliJ Terminal
it might be a worthwhile bug to post to IntelliJ Scala Plugin team
@Maatary if you can figure out any workaround, let me know and I'm happy to add it to Scribe
Maatary
@Maatary
Thank you
In the mean time, I would like to clarify some concept with you if you don't mind
What is the proper way to simply, set your entire application to info, and then a specific class to debug ?
is the following the right way:
Logger.root
    .withMinimumLevel(Level.Info)

  Logger(classOf[JenaRdfTgMessageTranslation.type].getName)
    .withMinimumLevel(Level.Debug)
    .replace()
Matt Hicks
@darkfrog26
you always must use replace() or it does nothing since all the .withX() methods just create a new instance of the immutable logger
@Maatary, so the second call is fine, but the first does nothing
Maatary
@Maatary

understood, however.
When I do

Logger.root
    .clearHandlers()
    .withHandler(minimumLevel = Some(Level.Info)).replace()


  Logger(classOf[JenaRdfTgMessageTranslation.type].getName)
    .withMinimumLevel(Level.Debug)
    .replace()

The debug in my object JenaRdfTgMessageTranslation from which i am setting the all thing by the way, does not work.

If instead i have

Logger.root
    .withMinimumLevel(Level.Info).replace()

  Logger(classOf[JenaRdfTgMessageTranslation.type].getName)
    .withMinimumLevel(Level.Debug)
    .replace()

Then it works. I can't explain the logic. So, I was wondering if you could help explain.

What is the diffence between withHandler(minimumLevel = Some(Level.Info)) and withMinimumLevel(Level.Info) I suspect that the later change the current handler, and the former add a new one. Hence it begs the question, why i can't modify the new one, in the specific logger for JenaRdfTgMessageTranslation.type
The App is ran like this
object JenaRdfTgMessageTranslation extends App {



  Logger.root
    .withMinimumLevel(Level.Info).replace()

  Logger(classOf[JenaRdfTgMessageTranslation.type].getName)
    .withMinimumLevel(Level.Debug)
    .replace()
Matt Hicks
@darkfrog26
If I recall, when you add a minimumLevel on a handler, it explicitly filters the content on that handler. However, when you use withMinimumLevel, it only applies the first level filter it finds. This is to allow certain handlers to filter explicitly.
Does that make sense?
Matt Hicks
@darkfrog26
@Maatary also, you can do Logger[JenaRdfTgMessageTranslation.type].withX... instead
or
import scribe._

JenaRdfTgMessageTranslation.logger.withX...
Maatary
@Maatary
Thank the tips

Meanwhile to be fair i don't get it:

If I recall, when you add a minimumLevel on a handler, it explicitly filters the content on that handler. However, when you use withMinimumLevel, it only applies the first level filter it finds. This is to allow certain handlers to filter explicitly.

In particular

it only applies the first level filter it finds.

I guess I need to have a better sense of how the filtering works in scribe. It is not in the doc.

Matt Hicks
@darkfrog26
okay, let me give an example:
if I have com.somecompany.Foo class that I'm logging in
if I do: Logger[Foo].withMinimumLevel(Level.Debug) and then do scribe.debug("Bar!") in Foo, the Logger on Foo applies the LevelFilter that "includes" that level, so it doesn't get filtered out.
However, there are no handlers on Foo, so nothing actually gets logged. It then propagates up to the com.somecompany Logger, which is empty, then up to com Logger, which is also empty.
Finally, it propagates up to root Logger that also has a LevelFilter of Level.Info, but because a LevelFilter was already evaluated against the this LogRecord (in Foo), it ignores this second LevelFilter.
However, a LevelFilter that is directly applied to a LogHandler is always evaluated because that is for explicitly filtering on that handler
So, in there are two places for LogModifiers (what a LevelFilter actually is) to be set: 1.) Logger itself, 2.) LogHandler
Matt Hicks
@darkfrog26
the Logger LogModifiers are hierarchical, so only the first of any type are applied taking priority over ones further up the hierarchical tree.
the LogHandler has no hierarchy, so the LogModifiers are always evaluated
this gives you the benefit of being able to add multiple LogHandlers to a Logger accepting different levels of logs (ex. a file for errors and a file for info)
Maatary
@Maatary
Thanks for this, I will need to let it sink in a little :)
Matt Hicks
@darkfrog26
@Maatary, no worries...I did my best to make it as simple as possible, but some of the complexity comes from making sure it can easily accomplish the same things as other logging libraries.
Maatary
@Maatary
Yeah, I will do my due diligence. Ultimately, my hope is that if i understand it well, at some point, i will contribute to the doc of your project.
Very helpful so far, and super thanks for the assitance.