Parus
Parus copied to clipboard
Add debug description for generated constraints
@DAlOG @AndreyMoskvin any ideas on how it should look or work?
Here some example.
Each construct try to recreate itself in string and attach this string to constraint.
Or
Common debug object attached to each constraint. But debug performed via array or view debugging.
Also we can add accessibility support for view naming.
Îòïðàâëåíî ñ iPhone
6 èþëÿ 2014, â 09:22, Kostya [email protected] íàïèñàë(à):
@DAlOG @AndreyMoskvin any ideas on how it should look or work?
— Reply to this email directly or view it on GitHub.
We discussed several options for debugging so far:
- for VFL constraints attach full VFL string to each generated constraint;
- we can somehow attach position of where it is created (as an option we can try to use
[Thread callStackSymbols]
, but it will work only in debug mode, where all the symbolicate information is available). We can also investigate C extensions:__PRETTY_FUNCTION__, __FILE__, __LINE__, __func__
;_cmd
. - we can add some additional user defined chain parameter, which will be mantioned with debug information as an identifier of a constraint (as Masonry:MASConstraint.h#133 did);
- quick look constraint visualisation;
- also we can create some LLDB commands extensions (Chisel like).
Guys you are welcome to discuss/investigate these or to propose something more. :cactus:
I want to work in direction of direct debug context
idea. With ability no nest and investigate this contexts.
In real we have several contexts. Source code, runtime and structure.
We need to investigate our ability to capture information from any of this.
Lets start from single constraints.
Also we need to think about view naming. Named views - great way to simplify debug itself.