forked from google/mtail
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
64 lines (46 loc) · 1.79 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
copy flag tests from mtail_test.sh
standard library, search path
refactor fs and notify into single interface
no trailing newline in parser test, requires changes to expr stmt
parse tree/ast testing?
mapping between progs and logs to reduce wasted processing
conversion in vm.compare() crashes on $var == "string" when $var is
float (logical.mtail, input line "12.8") --
Using a const pattern fragment as the first or only in a pattern expr is a
parse error.
{"concat expr 1", `
/bar/ + X {
}`},
{"concat expr 2", `
X {
}`},
// {"match expression 3", `
// $foo =~ X {
// }
// `},
Match against a variable requires simplifying binaryExpr grammar to elim the
concat_expr branch, fixing the id_expr problem above
{"match expr 2", `
/(?P<foo>.{6}) (?P<bar>.*)/ {
$foo =~ $bar {
}
}`},
bytecode like
[{push 1} {push 0} {cmp 1} {jm 6} {push 0} {jmp 7} {push 1} {jnm 13}
{setmatched false} {mload 0} {dload 0} {inc <nil>} {setmatched true}]
can be expressed as
[{push 1} {push 0} {cmp 1} {jm 9} {setmatched false} {mload 0} {dload 0} {inc
<nil>} {setmatched true}]
but jnm 13 is from the condExpr and the previous is from a comparison binary
expr; an optimizer is needed to collapse the bytecode to undersand that
cmp, jm, push, jump, push, jnm in sequence like so is the same as a cmp, jm
and we need to worry about the jump table too
count stack size and preallocate stack
-> counts of push/pop per instruction
-> test to keep p/p counts updated
Run and upload benchmarks to https://perfdata.golang.org/ from circleci
# Won't do
X Use capture group references to feed back to declaring regular expression,
X noting unused caprefs,
X possibly flipping back to noncapturing (and renumbering the caprefs?)
X -> unlikely to implement, probably won't impact regexp speed