Trace task (constructing a function graph) - page 5

New comment
 
jartmailru:
Static code analysis... Execution is not required.

I was thinking about another option - parsing text. so to say, parsing MQL and creating a program structure.
But I don't even know where to start.

 
tara:

Why not, if you like.

Choosing the wrong means of implementation indicates unprofessionalism.
 
MetaDriver:

Is it not obvious that this problem is unsolvable? This way we could eliminate pairs of arithmetic () [] and operator {} brackets, and replace them with a single opening bracket. Is that too weak?

;)

Why.

After all, there are many unary operations too.


jartmailru:
Choosing the wrong means of implementation indicates unprofessionalism.

What difference does it make what you program in? What matters in any business is the solution matrix.
Everything else is irrelevant.
 
jartmailru:
Static code analysis... Execution is not required.
The code is broken into functions (blocks) and then it is analyzed who calls whom.

I have the same idea in mind. Only the whole program would have to be thoroughly parsed to separate the mountains from the pimples...

And it seems that the main character doesn't need it, if I'm guessing correctly, he needs to print the calls on the fact. Well, like if the conditions of the call took place.

 
sergeev:

I was thinking about another option - parsing the text. so to say, parsing MQL and creating a program structure.
But I don't even know where to start with its implementation.

It's elementary.
What is a function?
.
[ word space / it might not be ] word function name bracket "(", something there, bracket closing ")"
curly openers {
.
some code
curly braces {, }
.
curly closing }
.
The first part of the work is done.
 
sergeev:

:))

the task (if you read the first post) is to add just one service-function to each function of the source code - right after "{".

But in such a way to get all source code passages and build a call tree.

This does not change input parameters of source functions in any way, nor their results or code inside



It's not about pure trace. It's just about constructing a function graph.

Here's a snippet of the log: 

01:45:18 CTA0 USDCHF,H1: loaded successfully
01:45:18 CTA0 USDCHF,H1 inputs: BarsBeforeActivate=1; BarsBeforeConfirm=0; TraceIsAllowed=true; IsStaticMode=false; ClearAtFinish=true; ExcludeFirstBar=false; ExcludeLastBar=true; RasingLinesColor=(0,128,128); ReducingLinesColor=(255,0,255); 
01:45:18 CTA0 USDCHF,H1: Init
01:45:18 CTA0 USDCHF,H1: Init=>NewBar(DeadLine)
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>DeleteGroup(Init)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup=>ClearTrend
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup=>ClearTrend=>ClearTrace
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)=>ClearTrend
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)=>ClearTrend=>ClearTrace
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>SaveGroup(Empty)
01:45:18 CTA0 USDCHF,H1: Init=>PaintGroup(ClearScreen)
 
sergeev:

Why.

After all, there are not a few unary operations.

Well, this operation is clearly not unary. "Nesting state" in static text analysis is unary. In dynamic tracing it is binary. There is an INPUT and an OUTPUT.

Isn't there?

 
MetaDriver:

I have the same idea in mind. Only the whole program would have to be thoroughly parsed to separate the mountains from the pimples...

And it seems to me that's not what the starter needs, if I intuited correctly he needs to print out the calls on the fact. You know, if the conditions of the call are met.

When parsing, the actual calls will be detected by themselves. Who is with whom and from where...

so this is the only complete solution idea so far.

 
There is no "thorough" parsing as well as "mountains" and "pimples"...
.
By the way... I'll add:
.
- initially the program text is analysed by a "lexer".
The lexer beats the program text into "tokens".
In our case, the tokens are:
.
- whitespace - spaces, tabs, line ends, etc. -
since we don't write the formatter, we just ignore this stuff
- brackets ( / )
- brackets [ / ]
- brackets { / }
- operators + - / *
- wildcards ;,
all the rest are essentially identifiers
(numbers will also be in this group - but we don't care).
.
When parsing lexing, structures of the type
struct { typeToken, stringToken }
.
For parsing, I used an attachment of the type
struct Tocken { typeToken, stringToken, list<Token> list of nested tokens }
But you can think of a simpler way here.
.
And then do the grouping I mentioned above - trivial.
.
Actually lexer + parser combination is a classic of the genre.
About lex/flex/bison/ant-lr can not advise (I do not even know the name ;-D)-.
I wrote exactly hand-made.
 

OK. Thank you all for the debate.

123456789
New comment