Allows logging in a tree structure so that comprehensive logging does not become incomprehensible
@koshelev ^
@channingwalton Would it make sense to have something like
```
trait LogTreeSyntax[Annotation, Error: Show] {
type LogTree = Tree[LogTreeLabel[Annotation]]
type LogTreeWriter[Value] = Writer[LogTree, Value]
type DescribedComputation[Value] = EitherT[LogTreeWriter, Error, Value]
```?
'Stare'
@lancewalton what do you think?
but then
type DescribedComputation[Value] doesn't work out
Is it that we need methods like
def failure[V](description: String)to be def failure[V, Err: Show](description: Err)
I'll keep trying :)
I think we need @lancewalton to come back from holiday
yep.
Now i have ugly combination of
case class FutureDescribedComputation[A](run: Future[DescribedComputation[A]]) {
def flatMap[B](f : A => FutureDescribedComputation[B])
(implicit exec: ExecutionContext) : FutureDescribedComputation[B] =
FutureDescribedComputation(
run.flatMap { dca : DescribedComputation[A] =>
dca.run.value.fold(
s => Future.successful( EitherT.left[LogTreeWriter, String, B]( dca.run.map(_ => s) ) ),
(a : A) => f(a).run.map { x => dca.flatMap { _ => x } } )
}
)
def map[B](f : A => B)(implicit exec: ExecutionContext) : FutureDescribedComputation[B] =
FutureDescribedComputation( run.map { x => x.map { f } } )
}and future.recover{ case t => failure("Client lookup”) ~~ t}
But I do belive there should be a better way :)
@koshelev - I've used annotations to mark out sections of a large log tree as being relevant to different downstream consumers - the idea is to prune the log tree into simpler trees by annotation, then route each simplified tree to SLF4J using the annotation as an SLF4J context, as well as routing the original unpruned tree to a 'tell-me-everything' logger. Given this is in production at a client site, I think they would very much like to keep the notion of annotations. My point is that annotations allow a single log tree to carry multiple contexts that coexist in the same tree with the same type of description - and that these annotations can be applied at a root node of a tree, distinct from the nodes where the descriptions were produced (in case you were thinking of encoding the annotation in the description via case classes / shapeless). Not that I'm against the idea of generalising the description to an arbitrary showable, though...
@koshelev - BTW, regarding Future[DescribedComputation[V]] - have you taken a look at EMM? We had a similar problem, wherein we had a 'ManagedResource[Process[Task, DescribedComputation[X]]]' - the plan (shelved for the time being last time I checked) was to try to use EMM to at least fuse 'Process' and 'DescribedComputation' into a stacked monad...
@lancewalton I don't know how to recover from failure:
which print out
is it possible (or how to) make the
val rec = "test" ~< {
val dc = "compute".left[Int] ~>? (l => l, r => r.toString)
dc.handleError { x => 1 ~> "recoveried" }
}
println(rec.run.written.show)which print out
Failed: test
Failed: compute
recoveriedis it possible (or how to) make the
test tag success because it is recoveried from errors? thanks. nice lib by the way
@chenharryhua You could just pattern match against rec.run.value. If I do this:
import scalaz.std.string._
import treelog.LogTreeSyntaxWithoutAnnotations
import treelog.LogTreeSyntaxWithoutAnnotations._
import scalaz.syntax.plus._
import scalaz.syntax.show._
import scalaz.syntax.monadError._
val planAThatDoesntWork: LogTreeSyntaxWithoutAnnotations.DescribedComputation[Int] = failure[Int]("Oh dear....")
val backupPlan: LogTreeSyntaxWithoutAnnotations.DescribedComputation[Int] = 42 ~> "This one works"
val putThemTogether = planAThatDoesntWork <+> backupPlan
putThemTogether.run.value // Yields a value, 42.
putThemTogether.run.written.shows // Shows that there *was* a failure, and that we recover.
val anotherWay = planAThatDoesntWork.handleError(_ => backupPlan)
anotherWay.run.value
anotherWay.run.written.shows, I see values (along with the failure in the log).
my attempt to enhance tree-log : https://gist.github.com/chenharryhua/d19607287fb1f8dfa198609f7f20eb92
"com.casualmiracles" %% "treelog-cats" % "1.4.1-SNAPSHOT"
If all goes well I'll publish a full release version
actually I suspect that becuase
LogTreeWriter is not WriterT but just WriterT[Id, _]. I think handling monadic values with treelog would be not so rare demand.