trace macro #413
trace macro #413
Conversation
|
I've added the
|
|
|
||
| "two params" in { | ||
| def test(a: Int, b: String)(using t: Trace) = t.snippet | ||
| assert(test(1, "hello") == "test(1, \"hello\")") |
There was a problem hiding this comment.
might be easier to maintain/read tests if we use triple quotes.
| object Test: | ||
| infix def test(v: Int)(using t: Trace) = t.snippet | ||
|
|
||
| assert((Test test 42) == "Test test 42") |
There was a problem hiding this comment.
How would this be serialized differently?
Maybe an extension infix method might be a good test as well.
There was a problem hiding this comment.
How would this be serialized differently?
Note that the test is pending. The macro is currently generating an empty string for this scenario.
Maybe an extension infix method might be a good test as well.
I'll add a pending test for it as well.
README.md
Outdated
| @@ -1076,7 +1077,7 @@ def example(db: Database): Int < IOs = | |||
| // Another 'Cut' implementation | |||
| val countTimesTen = | |||
| new Cut[Database, Int, IOs] { | |||
| def apply[S](v: Database < S)(f: Database => Int < IOs) = | |||
| def apply[S](v: Database < S)(f: Database => Int < IOs)(using Trace) = | |||
There was a problem hiding this comment.
Why does the readme need to mention Trace at all?
There was a problem hiding this comment.
I thought it'd be nice to ensure aspects propagate traces but, rethinking it now, it doesn't seem to make sense. We do want to show the trace based on the user's provided implementation for apply.
| class TraceTest extends KyoTest: | ||
|
|
||
| "show" in { | ||
| def test(i: Int)(using t: Trace) = t.show |
There was a problem hiding this comment.
Can you add a .show with several layers of nesting? I would like to see how the overall message appears.
There was a problem hiding this comment.
do you think it's still necessary after the clarifications in private? If not, can you provide an example of what you have in mind?
README.md
Outdated
| @@ -1,4 +1,4 @@ | |||
| ### Please visit https://getkyo.io for an indexed version of this documentation. | |||
| 1119### Please visit https://getkyo.io for an indexed version of this documentation. | |||
|
I should have clarified something: this change is only an initial step to address #213. The trace information is stored in all Kyo computations, but we still need to change the places where effects are evaluated ( Meanwhile, once this change is merged, we can already start showing frame information for example in the scheduler top. I imagine we'll find some other use cases as well. |
|
Changes LGTM, do you still want to hold off on merging for another release? |
|
@hearnadam I'm planning to merge this once the build passes since we've made the release already. Maintaining the branch generates extra work and I want to work on follow ups on top of this change. |
I'm working on #213. This PR introduces a macro to generate
Traces including a snippet of the method call. The macro isn't very robust because I couldn't find a way to obtain the snippet via the macro APIs.Position.ofMacroExpansionreturns the position of theTracemacro expansion, not the method call. The implementation uses a heuristic to extract the call directly from the source code string. Since the snippet is informative, I think it's a reasonable risk.