[Cocci] Coccinelle vs Firefox

[Cocci] Coccinelle vs Firefox

[Perry Wagle]

Hi ?

I need to comprehend the huge Firefox source, excise the bookmark subsystem, turn it into an extension, hack on the extension to bring back the functionality I need, and drop in the new extension.  Then, I just need to replace the whole thing with something far more advanced than the toy they want to turn it into.

My workflow depends on bookmark tags working thus and so, and I anticipate that this yak shaving expedition will take me a year (since I want to develop tools to do it for me, instead of brute forcing it, which my ag?d brain doesn?t handle any more for programs of this size).  One of those tools involves my bookmark tags thing, so its a bootstrapping thing too (fun!).

So my question is whether you guys think Coccinelle would be useful to me in comprehending and doing MASS transformations of the firefox source?  I get the impression from lightly skimming that you concentrate on what I would describe as point fixes, which doesn?t seem the same.  But this couldn?t be it all, else you wouldn?t be interested?

The main problem is that firefox is written in a variety of programming languages.  How hard would it be to retarget Coccinelle to those languages?  And how useful for finding excision point for removing the existing bookmarks subsystem might it be?

At this point, I?m just trying to determine what order to do things in, and where learning Coccinelle fits in, if at all.

Is this enough information for you all to give me an idea, from 20,000 feet, of whether Coccinelle makes sense for me or not?  If not, I?ll return in a week with more details.

Thanks!

? Perry

[Cocci] Coccinelle vs Firefox

[Julia Lawall]

On Sat, 16 Jul 2016, Perry Wagle wrote:

> Hi ?
>
> I need to comprehend the huge Firefox source, excise the bookmark
> subsystem, turn it into an extension, hack on the extension to bring
> back the functionality I need, and drop in the new extension.  Then, I
> just need to replace the whole thing with something far more advanced
> than the toy they want to turn it into.
>
> My workflow depends on bookmark tags working thus and so, and I
> anticipate that this yak shaving expedition will take me a year (since I
> want to develop tools to do it for me, instead of brute forcing it,
> which my ag?d brain doesn?t handle any more for programs of this size).
> One of those tools involves my bookmark tags thing, so its a
> bootstrapping thing too (fun!).
>
> So my question is whether you guys think Coccinelle would be useful to
> me in comprehending and doing MASS transformations of the firefox
> source?  I get the impression from lightly skimming that you concentrate
> on what I would describe as point fixes, which doesn?t seem the same.
> But this couldn?t be it all, else you wouldn?t be interested?
>
> The main problem is that firefox is written in a variety of programming
> languages.  How hard would it be to retarget Coccinelle to those
> languages?  And how useful for finding excision point for removing the
> existing bookmarks subsystem might it be?

Coccinelle was originally designed for doing collateral evolutions.  Ie,
an interface changes, so how to automate the updating of the users of the
interface.  But it relies on the user to know what needs to be done.
There has been a little work on inferring changes from examples (spdiff,
http://www.diku.dk/~jespera/), but this tends to run "forever" on complex
cases, and anyway the user still needs to know what to do to make the
examples in the first place.

Coccinelle makes some effort to maintain type information, so it can be
useful for things like finding out where is the function in the probe
field of the platform_driver structure actually called.

If you want to know how a pair of functions is used together, then
Coccinelle could be useful in searching for such uses.  This could be
useful for counting how often a function is used when a lock is or is not
held, to decide whether locking is needed.

But I don't think that Coccinelle would be useful as the main tool in a
code understanding project.  It is more useful when you know what you want
to do, but don't want to go through and do it everywhere by hand.

Coccinelle only works for C, and the part of C++ code that looks pretty
much like C.  The implementation is based on an AST that is specific to C,
so retargeting it for java, python, javascript, ruby, perl, whatever would
probably require quite a bit of work.

julia

> At this point, I?m just trying to determine what order to do things in,
> and where learning Coccinelle fits in, if at all.
>
> Is this enough information for you all to give me an idea, from 20,000
> feet, of whether Coccinelle makes sense for me or not?  If not, I?ll
> return in a week with more details.
>
> Thanks!
>
> ? Perry
>
> _______________________________________________
> Cocci mailing list
> Cocci at systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>

[Cocci] Support for more programming languages?

[SF Markus Elfring]

> The main problem is that firefox is written in a variety of programming languages.

https://www.quora.com/What-programming-languages-are-web-browsers-like-Google-Chrome-Opera-and-Mozilla-Firefox-written-in


> How hard would it be to retarget Coccinelle to those languages?

The Coccinelle software is concentrating on source code transformations
for the programming language "C" so far.
For which languages do you look for improvements finally?

* How would you like to improve tools for context-dependant languages like "C++"?

* How ambitious are you to support further software development around such areas?

Regards,
Markus

[Cocci] Transformations for Firefox source files

[SF Markus Elfring]

> So my question is whether you guys think Coccinelle would be useful to me
> in comprehending and doing MASS transformations of the firefox source?

For which kind of source code transformations are you especially interested in?

With which search patterns would you like to achieve further software improvements?

Regards,
Markus

[Cocci] Coccinelle vs Firefox

[Perry Wagle]

If you took coccinelle and somehow retargeted it to ocaml, which I believe it?s implemented in, could you then turn around and use that version to automate excising/abstracting the AST out, and maybe automating the addition of a new/different AST?  In principle, I mean.  In practice, I can think of a few possible problems, but bootstrapping it might help.

This is the sort of transformation I?m looking to do, and, in any case, I want to do things to ocaml itself (and hence coq).

PS.  John Viega convinced me in 2001 (personal conversation) that trying to write your own C++ grammar was a PITA, and mostly futile to get perfect.  Since then, I?ve had the stance that using the compiler itself to do the parse was the way to go, but found that GCC was purposely designed not to allow you to do this.  The then new LLVM seemed the way to go, and now its finally matured.  What?s your take on using the compiler?s AST?  I did see a paper recently fly by about using approximation methods instead of full parsing with a compiler, but I can?t find it in my notes right now.  Anyone recognize what I?m talking about?



> On Jul 16, 2016, at 10:47 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> 
> 
> 
> On Sat, 16 Jul 2016, Perry Wagle wrote:
> 
>> Hi ?
>> 
>> I need to comprehend the huge Firefox source, excise the bookmark
>> subsystem, turn it into an extension, hack on the extension to bring
>> back the functionality I need, and drop in the new extension.  Then, I
>> just need to replace the whole thing with something far more advanced
>> than the toy they want to turn it into.
>> 
>> My workflow depends on bookmark tags working thus and so, and I
>> anticipate that this yak shaving expedition will take me a year (since I
>> want to develop tools to do it for me, instead of brute forcing it,
>> which my ag?d brain doesn?t handle any more for programs of this size).
>> One of those tools involves my bookmark tags thing, so its a
>> bootstrapping thing too (fun!).
>> 
>> So my question is whether you guys think Coccinelle would be useful to
>> me in comprehending and doing MASS transformations of the firefox
>> source?  I get the impression from lightly skimming that you concentrate
>> on what I would describe as point fixes, which doesn?t seem the same.
>> But this couldn?t be it all, else you wouldn?t be interested?
>> 
>> The main problem is that firefox is written in a variety of programming
>> languages.  How hard would it be to retarget Coccinelle to those
>> languages?  And how useful for finding excision point for removing the
>> existing bookmarks subsystem might it be?
> 
> Coccinelle was originally designed for doing collateral evolutions.  Ie,
> an interface changes, so how to automate the updating of the users of the
> interface.  But it relies on the user to know what needs to be done.
> There has been a little work on inferring changes from examples (spdiff,
> http://www.diku.dk/~jespera/ <http://www.diku.dk/~jespera/>), but this tends to run "forever" on complex
> cases, and anyway the user still needs to know what to do to make the
> examples in the first place.
> 
> Coccinelle makes some effort to maintain type information, so it can be
> useful for things like finding out where is the function in the probe
> field of the platform_driver structure actually called.
> 
> If you want to know how a pair of functions is used together, then
> Coccinelle could be useful in searching for such uses.  This could be
> useful for counting how often a function is used when a lock is or is not
> held, to decide whether locking is needed.
> 
> But I don't think that Coccinelle would be useful as the main tool in a
> code understanding project.  It is more useful when you know what you want
> to do, but don't want to go through and do it everywhere by hand.
> 
> Coccinelle only works for C, and the part of C++ code that looks pretty
> much like C.  The implementation is based on an AST that is specific to C,
> so retargeting it for java, python, javascript, ruby, perl, whatever would
> probably require quite a bit of work.
> 
> julia
> 
>> At this point, I?m just trying to determine what order to do things in,
>> and where learning Coccinelle fits in, if at all.
>> 
>> Is this enough information for you all to give me an idea, from 20,000
>> feet, of whether Coccinelle makes sense for me or not?  If not, I?ll
>> return in a week with more details.
>> 
>> Thanks!
>> 
>> ? Perry
>> 
>> _______________________________________________
>> Cocci mailing list
>> Cocci at systeme.lip6.fr <mailto:Cocci@systeme.lip6.fr>
>> https://systeme.lip6.fr/mailman/listinfo/cocci <https://systeme.lip6.fr/mailman/listinfo/cocci>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20160717/be24781c/attachment-0001.html>

[Cocci] Support for more programming languages?

[Perry Wagle]

> On Jul 16, 2016, at 11:48 PM, SF Markus Elfring <elfring@users.sourceforge.net> wrote:
> 
>> The main problem is that firefox is written in a variety of programming languages.
> 
> https://www.quora.com/What-programming-languages-are-web-browsers-like-Google-Chrome-Opera-and-Mozilla-Firefox-written-in
> 
> 
>> How hard would it be to retarget Coccinelle to those languages?
> 
> The Coccinelle software is concentrating on source code transformations
> for the programming language "C" so far.
> For which languages do you look for improvements finally?
> 
> * How would you like to improve tools for context-dependant languages like "C++??

Well, to use a general term, I want to comprehend LLVM and GCC for various reasons.  LLVM has been C++ from the beginning, and GCC is being rewritten in C++, though maybe with enough of a C flavor to be amenable to Coccinelle.

> * How ambitious are you to support further software development around such areas?

Julia was underwhelmed, but I?m still looking for a use for Coccinelle just in case.  See my response to her response. 


> Regards,
> Markus

[Cocci] Transformations for Firefox source files

[Perry Wagle]

> On Jul 17, 2016, at 12:14 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote:
> 
>> So my question is whether you guys think Coccinelle would be useful to me
>> in comprehending and doing MASS transformations of the firefox source?
> 
> For which kind of source code transformations are you especially interested in?

With Firefox, it the excision of the bookmarks subsystem from a current (moving target) source tree and replacing it with my own.  I might want to turn it into an extension first, and to turn my extension into a subsystem.

> With which search patterns would you like to achieve further software improvements?

I don?t know yet.  Depends on what I can do.  II?m just skimmed some of the documentation, checking to see if I should dive in.

> Regards,
> Markus

[Cocci] Coccinelle vs Firefox

[Perry Wagle]

> On Jul 17, 2016, at 3:44 PM, Perry Wagle <wagle@mac.com> wrote:
> 
> PS.  ...  I did see a paper recently fly by about using approximation methods instead of full parsing with a compiler, but I can?t find it in my notes right now.  Anyone recognize what I?m talking about?

Found it: How to Build Static Checking Systems Using Orders of Magnitude?Less Code <http://dl.acm.org/citation.cfm?id=2872364> at ASPLOS?16.  See some reactions (now that I waited for them) at: Lambda the Ultimate <http://lambda-the-ultimate.org/node/5348>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20160717/4ffde529/attachment.html>

[Cocci] Coccinelle vs Firefox

[Julia Lawall]

On Sun, 17 Jul 2016, Perry Wagle wrote:

> If you took coccinelle and somehow retargeted it to ocaml, which I believe
> it?s implemented in, could you then turn around and use that version to
> automate excising/abstracting the AST out, and maybe automating the addition
> of a new/different AST? ?In principle, I mean. ?In practice, I can think of
> a few possible problems, but bootstrapping it might help.

I guess.  I would imagine that reimplementing the whole thing in a more
generic way would be easier.  But neither is a priority for us.

> This is the sort of transformation I?m looking to do, and, in any case, I
> want to do things to ocaml itself (and hence coq).

This person:

Th?ophane Hufschmitt <theophane.hufschmitt@polytechnique.org>

worked on something like Coccinelle for OCaml. It was just a summer
project, but he may have come up with something usable.

> PS. ?John Viega convinced me in 2001 (personal conversation) that trying to
> write your own C++ grammar was a PITA, and mostly futile to get perfect.

The nice part of Coccinele is that we have no need for the grammar to be
perfect.  Our goal is to convert the source code to an AST, not to be sure
that the source code is correctly formed.

> ?Since then, I?ve had the stance that using the compiler itself to do the
> parse was the way to go, but found that GCC was purposely designed not to
> allow you to do this. ?The then new LLVM seemed the way to go, and now its
> finally matured. ?What?s your take on using the compiler?s AST?

If you use someone else's AST, then you have to live with the information
that they thought was useful.  Coccinelle needs information about the
whitespace and commas around each token so that it is able to perform
transformation, ie rebuild the code exactly as it was outside of the
transformed parts.  Coccinelle also has the goal of parsing individual
source code files without expanding macros, to limit the code size, to
avoid the need to interpret make files, and so that the user can express
transformations in terms of the code that he sees, ie macro uses.  I don't
know if LLVM would support that.

>?I did see a
> paper recently fly by about using approximation methods instead of full
> parsing with a compiler, but I can?t find it in my notes right now. ?Anyone
> recognize what I?m talking about?

The concept of island grammars comes to mind:

https://en.wikipedia.org/wiki/Island_grammar

There was also recently a paper from the group of Dawson Engler about
doing program analysis for lots of languages using approximate parsing.
I'm not sure if either is connected to a compiler though.

Fraser Brown, Andres N?tzli, Dawson R. Engler:
How to Build Static Checking Systems Using Orders of Magnitude Less Code.
ASPLOS 2016: 143-157

julia

[Cocci] Coccinelle vs Firefox

[Perry Wagle]

> On Jul 17, 2016, at 10:11 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> 
> On Sun, 17 Jul 2016, Perry Wagle wrote:
> 
>> If you took coccinelle and somehow retargeted it to ocaml, which I believe
>> it?s implemented in, could you then turn around and use that version to
>> automate excising/abstracting the AST out, and maybe automating the addition
>> of a new/different AST?  In principle, I mean.  In practice, I can think of
>> a few possible problems, but bootstrapping it might help.
> 
> I guess.  I would imagine that reimplementing the whole thing in a more
> generic way would be easier.  But neither is a priority for us.

By ?somehow?, I sorta left out who would do it (probably me).  Was curious as to whether you thought it a cool idea or not.  Appears to be not.  

But my main question was whether extracting and replacing the AST representation was something Coccinelle would help automate for a series of evolving source trees, such as Coccinelle, for this example, or Firefox, for my problem(s).  I?m hoping for a general purpose tool.

I was also wondering if object orientation threw Coccinelle off.  Probably not if you found a way to chase function pointers statically.  Oh wait, Buck Krasic did that for Synthetix.

I need Firefox bookmark tags to index my 2000 page wiki (aka research journal).  Firefox broke tags.  So, because of the way my brain does programming now, I?m stuck having to fix Firefox somehow to make progress on my real projects.

>> This is the sort of transformation I?m looking to do, and, in any case, I
>> want to do things to ocaml itself (and hence coq).
> 
> This person:
> 
> Th?ophane Hufschmitt <theophane.hufschmitt@polytechnique.org>
> 
> worked on something like Coccinelle for OCaml. It was just a summer
> project, but he may have come up with something usable.

Ok, will get in contact with him if I decide to do it this way.

>> PS.  John Viega convinced me in 2001 (personal conversation) that trying to
>> write your own C++ grammar was a PITA, and mostly futile to get perfect.
> 
> The nice part of Coccinele is that we have no need for the grammar to be
> perfect.  Our goal is to convert the source code to an AST, not to be sure
> that the source code is correctly formed.
> 
>>  Since then, I?ve had the stance that using the compiler itself to do the
>> parse was the way to go, but found that GCC was purposely designed not to
>> allow you to do this.  The then new LLVM seemed the way to go, and now its
>> finally matured.  What?s your take on using the compiler?s AST?
> 
> If you use someone else's AST, then you have to live with the information
> that they thought was useful.  Coccinelle needs information about the
> whitespace and commas around each token so that it is able to perform
> transformation, ie rebuild the code exactly as it was outside of the
> transformed parts.  Coccinelle also has the goal of parsing individual
> source code files without expanding macros, to limit the code size, to
> avoid the need to interpret make files, and so that the user can express
> transformations in terms of the code that he sees, ie macro uses.  I don't
> know if LLVM would support that.

I heard something out there tracked whitespace, but I?m not finding it on google.  My impression is that it was LLVM.  Also, there?s an LLVMLinux project <http://llvm.linuxfoundation.org/index.php/Main_Page> that might be interesting to you.  There?s a literature surrounding including documentation in AST?s etc that Andrew Black was surveying around 2003-2004, maybe he published something.

I guess I assume I?m strapping the compiler to a hybrid structure/program-text editor, so maintaining whitespace and comments isn?t an issue.  The trick is to ?connect? the editor?s AST to the compiler?s.  I has wild (probably intractable) notions of how to do that, lemme try that out before confusing people.

>>  I did see a
>> paper recently fly by about using approximation methods instead of full
>> parsing with a compiler, but I can?t find it in my notes right now.  Anyone
>> recognize what I?m talking about?
> 
> The concept of island grammars comes to mind:
> 
> https://en.wikipedia.org/wiki/Island_grammar <https://en.wikipedia.org/wiki/Island_grammar>
Wow..  $177 paywall there.  Darn.

> There was also recently a paper from the group of Dawson Engler about
> doing program analysis for lots of languages using approximate parsing.
> I'm not sure if either is connected to a compiler though.
> 
> Fraser Brown, Andres N?tzli, Dawson R. Engler:
> How to Build Static Checking Systems Using Orders of Magnitude Less Code.
> ASPLOS 2016: 143-157

Ah yeah, that?s the one.  Not finding actual code though.

> julia

? Perry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20160718/d8856f7e/attachment.html>

[Cocci] Support for more programming languages?

[SF Markus Elfring]

> LLVM has been C++ from the beginning, and GCC is being rewritten in C++,

I guess that there are still various software development challenges evolving.


> though maybe with enough of a C flavor to be amenable to Coccinelle.

How do you think about common properties in the discussed programming
language mixture?

Do you find a feature request like "Exclusion of unsupported source code parts"
interesting for further consideration?
https://github.com/coccinelle/coccinelle/issues/20

Regards,
Markus

[Cocci] Transformations for Firefox source files

[SF Markus Elfring]

> With Firefox, it the excision of the bookmarks subsystem from a current (moving target)
> source tree and replacing it with my own.

Have you got any ideas already on the ways you would like to filter involved
software components?

Regards,
Markus

[Cocci] Coccinelle vs Firefox

[Julia Lawall]

On Mon, 18 Jul 2016, Perry Wagle wrote:

>
>       On Jul 17, 2016, at 10:11 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
> On Sun, 17 Jul 2016, Perry Wagle wrote:
>
>       If you took coccinelle and somehow retargeted it to ocaml, which I believe
>       it?s implemented in, could you then turn around and use that version to
>       automate excising/abstracting the AST out, and maybe automating the addition
>       of a new/different AST? ?In principle, I mean. ?In practice, I can think of
>       a few possible problems, but bootstrapping it might help.
>
>
> I guess. ?I would imagine that reimplementing the whole thing in a more
> generic way would be easier. ?But neither is a priority for us.
>
>
> By ?somehow?, I sorta left out who would do it (probably me). ?Was curious as to whether you thought it a cool idea or not. ?Appears to be not. ?

Well, don't let me discourage you :)  I'm more interested in what can be
done with the Linux kernel than what can be done with Coccinelle in
general, so it's more just my perspective than anything else.

> But my main question was whether extracting and replacing the AST representation was something Coccinelle would help automate for a series of evolving source trees, such as Coccinelle, for this example, or Firefox, for my problem(s).
> ?I?m hoping for a general purpose tool.
>
> I was also wondering if object orientation threw Coccinelle off. ?Probably not if you found a way to chase function pointers statically. ?Oh wait, Buck Krasic did that for Synthetix.

No, we don't chase function pointers, or anything else.  Coccinelle
doesn't do any static analysis internally beyond type inference.  The rest
you have to express yourself.  The idea is to favor predictability and it
is hard for a user to predict what results an arbitrary program analysis
will give.  However, if you have analysis information available
externally, it should be possible to use it, although I don't know the
exact status of that feature.

>       If you use someone else's AST, then you have to live with the information
>       that they thought was useful. ?Coccinelle needs information about the
>       whitespace and commas around each token so that it is able to perform
>       transformation, ie rebuild the code exactly as it was outside of the
>       transformed parts. ?Coccinelle also has the goal of parsing individual
>       source code files without expanding macros, to limit the code size, to
>       avoid the need to interpret make files, and so that the user can express
>       transformations in terms of the code that he sees, ie macro uses. ?I don't
>       know if LLVM would support that.
>
>
> I heard something out there tracked whitespace, but I?m not finding it on google. ?My impression is that it was LLVM.

Probably LLVM indeed.  I had a student once who looked into whether the
analysis information maintained by LLVM could be used by Coccinelle, and
he found that the overall AST design strategy was too different for it to
be useful.  But that was quite a number of years ago, and he time was
somewhat limited.

>?Also, there?s an?LLVMLinux project?that might be interesting to you.
>?There?s a literature surrounding including
> documentation in AST?s etc that Andrew Black was surveying around 2003-2004, maybe he published something.
>
> I guess I assume I?m strapping the compiler to a hybrid structure/program-text editor, so maintaining whitespace and comments isn?t an issue. ?The trick is to ?connect? the editor?s AST to the compiler?s. ?I has wild (probably
> intractable) notions of how to do that, lemme try that out before confusing people.
>
>             ?I did see a
>             paper recently fly by about using approximation methods instead of full
>             parsing with a compiler, but I can?t find it in my notes right now. ?Anyone
>             recognize what I?m talking about?
>
>
>       The concept of island grammars comes to mind:
>
>       https://en.wikipedia.org/wiki/Island_grammar
>
>
> Wow.. ?$177 paywall there. ?Darn.

Strange.  Googling for island grammars gives me several pdfs from citeseer
that are immediately accessible.  I think I read this one:

Robust Multilingual Parsing Using Island Grammars. Nikita Synytskyy, James
R. Cordy

julia

>       There was also recently a paper from the group of Dawson Engler about
>       doing program analysis for lots of languages using approximate parsing.
>       I'm not sure if either is connected to a compiler though.
>
>       Fraser Brown, Andres N?tzli, Dawson R. Engler:
>       How to Build Static Checking Systems Using Orders of Magnitude Less Code.
>       ASPLOS 2016: 143-157
>
>
> Ah yeah, that?s the one. ?Not finding actual code though.
>
>       julia
>
>
> ? Perry
>
>
>

[Cocci] Coccinelle vs Firefox

[SF Markus Elfring]

> By ?somehow?, I sorta left out who would do it (probably me).
> Was curious as to whether you thought it a cool idea or not.

Your idea might be "cool". But I imagine that you might not like some
of the remaining software development efforts.

Can such concerns be reduced?

Regards,
Markus

[Cocci] Object-orientation with SmPL?

[SF Markus Elfring]

> I was also wondering if object orientation threw Coccinelle off.

This software provides also a few classes for the programming languages
"OCaml" and "Python". Are you thinking about further extensions?

Would you like to give the topic "Class libraries for software components"
another look?
https://github.com/coccinelle/coccinelle/issues/22


> Probably not if you found a way to chase function pointers statically.

How will pointers matter for your source code search pattern?

Regards,
Markus

[Cocci] Coccinelle vs Firefox

[Perry Wagle]

>>      The concept of island grammars comes to mind:
>> 
>>      https://en.wikipedia.org/wiki/Island_grammar
>> 
>> 
>> Wow..  $177 paywall there.  Darn.
> 
> Strange.  Googling for island grammars gives me several pdfs from citeseer
> that are immediately accessible.  I think I read this one:
> 
> Robust Multilingual Parsing Using Island Grammars. Nikita Synytskyy, James
> R. Cordy

Oh cool, thanks!  I should have thought to google for it instead of blindly following the URL in the wikipedia article.


I?m going to think for a while about the rest.   Thanks!

? Perry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20160718/3bee6026/attachment.html>

[Cocci] Coccinelle vs Firefox

[Perry Wagle]

> On Jul 18, 2016, at 8:57 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote:
> 
>> By ?somehow?, I sorta left out who would do it (probably me).
>> Was curious as to whether you thought it a cool idea or not.
> 
> Your idea might be "cool". But I imagine that you might not like some
> of the remaining software development efforts.
> 
> Can such concerns be reduced?

I?m not sure I understand your question.

But, I have far too many projects to do to take on more.  Instead, I?m looking for ways to reduce the time and effort required by doing a little extra work ahead of time.  Above, I was trying to ascertain both whether my idea was the sensible way to do it, and whether I would also get a tool for transforming ocaml itself while getting something more language agnostic.  I like to have 15 reasons for doing anything.

? Perry

[Cocci] Object-orientation with SmPL?

[Perry Wagle]

> On Jul 18, 2016, at 9:19 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote:
> 
>> I was also wondering if object orientation threw Coccinelle off.
> 
> This software provides also a few classes for the programming languages
> "OCaml" and "Python". Are you thinking about further extensions?
> 
> Would you like to give the topic "Class libraries for software components"
> another look?
> https://github.com/coccinelle/coccinelle/issues/22
> 
> 
>> Probably not if you found a way to chase function pointers statically.
> 
> How will pointers matter for your source code search pattern?

In comprehending Linux Kernel source in the past, I?ve been stymied by not knowing where all a function pointer in a struct of function pointers might go during manual call graphing.  Automating this would be nice.

[Cocci] Support for more programming languages?

[Perry Wagle]

> On Jul 18, 2016, at 8:20 AM, SF Markus Elfring <elfring@users.sourceforge.net> wrote:
> 
>> LLVM has been C++ from the beginning, and GCC is being rewritten in C++,
> 
> I guess that there are still various software development challenges evolving.
> 
> 
>> though maybe with enough of a C flavor to be amenable to Coccinelle.
> 
> How do you think about common properties in the discussed programming
> language mixture?
> 
> Do you find a feature request like "Exclusion of unsupported source code parts"
> interesting for further consideration?
> https://github.com/coccinelle/coccinelle/issues/20

I?m uncomfortable with excluding anything.  When I did StackGuard GCC compiler(three times, yeesh), I used it to recompile all the code that gcc compiles in the Redhat distribution.  Every single procedure (except one).  The result was both fast and virtually bug free (one bug).  This was proof of concept.

[Cocci] Support for more programming languages?

[SF Markus Elfring]

> > https://github.com/coccinelle/coccinelle/issues/20
> 
> I?m uncomfortable with excluding anything.

Would you like to achieve automatic source code transformations
also for template classes in the programming language "C++" (or OCaml)?

Regards,
Markus