On Mon, 9 May 2011, Derek M Jones wrote:
> Julia,
>
> > > Thanks for the -use_cache suggestion. I will try it
> > > out on the next script.
>
> I tried it out on a small sample:
>
> as-was 19m 12s
> 1st -use_cache 19m 18s
> 2nd -use_cache 16m 21s
> 3rd -use_cache 16m 15s
>
> 2nd/3rd was just to double check.
>
> A 16% improvement is worth having :-)
>
> Bug: Specifying -use_cache results in a spurious TODO being sent
> to stderr.
I don't think it's a bug. Perhaps the message is not ideal, but the point
is that use_cache is not sensitive to eg the include options that are
used. If you change eg the argument to -I or -no_includes to
-all_includes, it will use the preparsed file if one exists, even though
the preparsed file was no parsed according to the information you have now
requested.
> > > I did wonder about what information Coccinelle might be able to
> > > provide for 'free', ie information it always collects when
> > > processing code but does not provide a means to access.
> > > For instance, the number of definitions and statements in a
> > > function definition,
> >
> > It's not clear what this means, because statements can be nested.
>
> Whatever can be made available can be of use.
>
> > > or the code matched by ... .
> >
> > It doesn't know this. The implementation of ... keeps track of what is
> > reachable from what, but not how it is reachable. How it is reachable
> > would be difficult to calculate in the presence of loops. It would be
> > conceptually possible to keep track of the set of control-flow graph nodes
> > matched, but that is not currently expressible.
>
> I was hoping that it might be possible to internally figure out
> something like: if we start here and end here the code involved must
> be foo___bar
>
> > > The obvious script has the problem that it does not supply
> > > parameter number information:
> >
> > You just need a parameter list metavariable:
> >
> > parameter list[n] ps;
> >
> > Afterwards, you can use either n or ps. ps can be empty/n can be 0.
>
> I don't see a way this would enable me to match the 1st/2nd parameter
> of a function containing just two parameters or the 1st/2nd/3rd
> parameter of a function containing just three parameters.
OK, I wasn't sure on what you wanted.
Perhaps the following would be useful (untested):
@r@
identifier f;
identifier x;
parameter list[n1] ps1;
parameter list[n2] ps2;
position p;
type T;
@@
f(ps1,T x@p,ps2) { ... }
@script:ocaml@
n1 << r.n1;
n2 << r.n2;
size << virtual.size;
@@
(* the same could be done in python, with more string->int conversions *)
if (not(n1 + n2 + 1 = int_of_string size))
then Coccilib.include_match(false)
@s@
position r.p;
identifier f,x;
@@
f(...,T x@p,...) { ... when != x
}
@script:python@
f << s.f;
x << s.x;
@@
print f
print x
Then when you run spatch, you can give it the argument -D size=6, or
whatever size is wanted.
julia
> At the time looking for differences based on how many parameters
> a function was defined with sounded like a good idea.
>
> > When you inherit n into python it is a string (although when you inherit n
> > into ocaml, it is an integer).
> >
> > julia
> >
> >> @ fn_p_any @
> > > type ret_T, pany_T;
> > > identifier fn, p_any;
> >> @@
> > >
> > > ret_T fn(..., pany_T p_any, ...)
> > > {
> > > ... when != p_any
> >> }
> > >
> >> @script:python @
> > > param_any<< fn_p_any.p_any;
> > > func<< fn_p_any.fn;
> >> @@
> > > print "unused", func, param_any
> > >
> > > so I wrote lots of patterns like:
> > >
> >> @ fn_no_p1 @
> > > type ret_T, p1_T;
> > > identifier fn, p1;
> >> @@
> > >
> > > ret_T fn(p1_T p1)
> > > {
> > > ... when != p1
> >> }
> > >
> >> @script:python @
> > > param_1<< fn_no_p1.p1;
> > > func<< fn_no_p1.fn;
> >> @@
> > > print "1_1", func, param_1
> > >
> > > to match particular instances.
> > >
> > > >
> > > > julia
> > > >
> > > >
> > > > > Trying out a new idea with something that takes 300+ hours to run is a
> > > > > bit
> > > > > impractical.
> > > > >
> > > > > Does anybody have any thoughts on:
> > > > >
> > > > > o converting the source to some intermediate form that will
> > > > > speed up Coccinelle processing,
> > > > >
> > > > > o using Coccinelle in the cloud, eg Amazon,
> > > > >
> > > > > o speeding up Coccinelle.
> > > > >
> > > > > --
> > > > > Derek M. Jones tel: +44 (0) 1252 520 667
> > > > > Knowledge Software Ltd mailto:[email protected]
> > > > > Source code analysis http://www.knosof.co.uk
> > > > > _______________________________________________
> > > > > Cocci mailing list
> > > > > [email protected]
> > > > > http://lists.diku.dk/mailman/listinfo/cocci
> > > > > (Web access from inside DIKUs LAN only)
> > > > >
> > > > >
> > > >
> > >
> > > --
> > > Derek M. Jones tel: +44 (0) 1252 520 667
> > > Knowledge Software Ltd mailto:[email protected]
> > > Source code analysis http://www.knosof.co.uk
> > > _______________________________________________
> > > Cocci mailing list
> > > [email protected]
> > > http://lists.diku.dk/mailman/listinfo/cocci
> > > (Web access from inside DIKUs LAN only)
> > >
> >
>
> --
> Derek M. Jones tel: +44 (0) 1252 520 667
> Knowledge Software Ltd mailto:[email protected]
> Source code analysis http://www.knosof.co.uk
> _______________________________________________
> Cocci mailing list
> [email protected]
> http://lists.diku.dk/mailman/listinfo/cocci
> (Web access from inside DIKUs LAN only)
>
>
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
