-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracer and fix for LibraryImports #55
Conversation
When looking at the screenshot I think what's missing is some notion of what is being transformed, that probably means "which AST node". |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
- Fable plugin definitions
StatusMostly done. I've found a medium of output that I am happy with (attached below). Nodes that are considered as roots of elements are given unique IDs. When tracing nested nodes within themselves, they can create child tracers that have the parent ID mapped to the child. Tracers can A third static method is It's really verbose, but the output is pretty helpful. This doesn't have to be associated with a traced object, and it doesn't print the GUID. We can presume these are operations acting on the last printed GUID. This method also does not output the JSON since it is not associated with an AST node. The API I'm looking at is something along the lines of the following: Compiler directives are passed to activate and modify the behaviour of the debugger.
Minimal flag will not produce any JSON output. Debug flag will produce JSON to a maximum depth of 4 by default. Any number can be appended to this to modify the maximum depth (eg OXPECKER_SOLID_DEBUG_15). Trace flag will produce JSON without a maximum depth.
Usage:
Still playing with a few things, but I've also come to realise where some of the issues lie. Imported Tags only present their information in two places, where they are called by the builder, or nested within a series of Let and Calls.
Ideally this will all mean issue authors can provide trace files that can be used to identify the source of the issue |
Implement File capabilities
Apply fix for Lanayx#54
I'm opening this for review as I'm done with the Tracer Implementation (or at least I'm happy with how it goes) and I'm running through the issues. Won't be helpful if I fix the issues but the tracer implementation is rejected hahaha Update: |
Thank you for your work! I'll try to find time and test usability in few days. Once done I'll do the deeper code review. As for now just few things that have caught my eye
|
This is just preemptive - fable 5 will render self closing tags but I can remove it and stash it for later Thanks! |
I see, I think when Fable 5 is out, we'll take dependency on it and just update all the tests. |
@shayanhabibi I've managed to have a look and unfortunately at this point I didn't like it, meaning that it doesn't simplify debugging for me. When I'm debugging output currently I look at the code and the AST, I build some form of a map in my head, like |
Yeah fair, there's a lot of the refactoring I myself am not a fan of anymore after understanding the AST more hahaha. I do still prefer the JSON outputs and traces to map what's happening, and I'll keep a private fork that has that amongst other changes for one of my projects. I'll be away over the weekend, but I'll make the pull with the tests and issues when I'm back! Thanks for your honest feedback :) |
Tracer is type agnostic so we can pass it around everywhere.
STAGE
What does this Pull change
New Functionality
The tracer allows you to pass compiler directives to fable to induce the debugging behaviour.
--define OXPECKER_SOLID_MINIMAL
- this will emit the order of operations to std out--define OXPECKER_SOLID_DEBUG
- this will emit the order of operations and JSON for marked expressions in the plugin to a max depth of 4--define OXPECKER_SOLID_DEBUG_[n]
- where[n]
is any integer. This will emit the order of operations and JSON for marked expressions up to a max depth of[n]
--define OXPECKER_SOLID_TRACE
- Emits the order of operations and JSON without limit. This is best combined with the following directive:--define OXPECKER_SOLID_FILE
- This pipes the order of operations and JSON (or whatever the current configured behaviour is) to a timestamped txt file in the CWD. It will not print JSON to stdout, but it WILL still print the order of operations. This is because the order of operations have source code links that are useful for navigating the plugin while you're debugging.While adding code or new branches of logic in pattern matching, you can emit information to provide context to the flow of operations. This is done with
Tracer.ping()
with optional messagesTracer.ping("SingleField branch")
.You create a Tracer object (which is differentiated by the fact that it is associated with a GUID, which is useful if you want distinguish different 'collections' of operations or expressions in groups) by passing a value to
Tracer.create
.A tracer is a simple record:
You can emit the JSON and position of the tracer by pinging it, or tracing it
If you want to bind a new value to the tracer (and keep the GUID), use
Tracer.bind
. Similarly, there is aTracer.map
function for applying functions to the internal value.newExpr |> Tracer.bind tracer
The JsonConverters are automatically generated for Unions in a manner that I feel is the most helpful.
Any new unions added just have to be registered in the
PrettyPrint.fs
file in the JsonConverters module:The rest is taken care of.