From: elfring@users.sourceforge.net (SF Markus Elfring)
To: cocci@systeme.lip6.fr
Subject: [Cocci] release: 1.0.2: Software evolution around parallelisation support
Date: Tue, 25 Aug 2015 09:20:38 +0200 [thread overview]
Message-ID: <55DC1746.2020503@users.sourceforge.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1508250850490.2049@localhost6.localdomain6>
> The problem is that the scripting language environment is separate from the
> environment of Coccinelle itself. So there is no easy way to get the
> right values into the right variables.
I can also understand corresponding software development challennges to some degree.
> Coccinelle doesn't know anything about the variables of the ocaml or python scripts.
How do you think about possibilities to extend its knowledge?
Can an improved software design help to achieve the needed data exchange?
>> I propose to reactivate the support for the SmPL rules "initialize" and "finalize"
>> for all uses cases without unwanted software limitations.
>
> There is no way that Coccinelle can tell what is a "use case with an
> unwanted software limitation.
Can the exclusion of these rules be seen as a temporary software restriction
when the parameter "--jobs" to the program "spatch"?
> Coccinelle doesn't know what the scripting code does.
But you have still got control on the data which are transferred between
the involved subprocesses.
> I would prefer not to promise a behavior that is not implemented.
I hope that corresponding technical concerns can be improved.
> As I said before, if an unshared initialize and finalize are acceptable to you,
> then just use the preexisting parallelism solution, which is still supported.
I am using this approach with a make script for a while.
How do you think about variants for these actions at the "unshared" stage
and the task/subprocess level?
Regards,
Markus
next prev parent reply other threads:[~2015-08-25 7:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-22 14:09 [Cocci] 1.0.2 Julia Lawall
2015-08-23 17:47 ` [Cocci] release: 1.0.2: Better file selection SF Markus Elfring
2015-08-23 18:16 ` [Cocci] release: 1.0.2: Software evolution around parallelisation support SF Markus Elfring
2015-08-23 19:30 ` Julia Lawall
2015-08-23 20:20 ` SF Markus Elfring
2015-08-25 6:42 ` SF Markus Elfring
2015-08-25 6:54 ` Julia Lawall
2015-08-25 7:20 ` SF Markus Elfring [this message]
2015-08-26 5:50 ` SF Markus Elfring
2015-08-26 9:11 ` Julia Lawall
2015-08-26 10:43 ` SF Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55DC1746.2020503@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=cocci@systeme.lip6.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox