- User Since
- May 8 2015, 2:41 AM (223 w, 4 d)
Jun 19 2017
@george.karpenkov thanks for your comments. I totally lost interest to continue this job, due to lack of feedback. Will use your catches, suggestions on my upstream repository. Thanks again!
Apr 26 2017
Apr 18 2017
Apr 8 2017
Realized that these changes are related to environment access simplification. I hope it can be merged together.
Apr 7 2017
Fixed review comments.
Apr 6 2017
I want to store Compilation in set to filter out duplicates. (That requires __hash__ and (__eq__ or __cmp__)) New objects will be created from files, so structural equality is needed. (No chance that reference equality would be enough.)
Thanks for the review, will upload a new diff soon.
Apr 4 2017
Any other comment guys? Would like to merge this week and continue with other PRs which depends on this.
Mar 27 2017
Mar 25 2017
Mar 22 2017
Mar 21 2017
All right, then everything stays the same. :)
Mar 20 2017
Gentle ping. (There are a couple of other change I would be based on this.)
Thanks for the review Devin!
Mar 19 2017
Implemented preprocessor flag filtering.
Mar 15 2017
Mar 11 2017
Mar 8 2017
Thanks Devin. I forgot to add the arguments.py module at the commit, so this does not show it. But made another commit which has it. Sorry.
fixed review comments.
Mar 6 2017
Thanks Devin for the comments. I'm happy to have your improvement suggestions crafted, scratched. It helps me to understand what part is debated... See my replies inlined.
Mar 5 2017
Looks good to me, although please update the comment to be prose and have proper capitalization.
Can I ask a temporary exemption on capitalization? Here's why I'm asking... Currently all pydoc comments are capitalized, but inline ones are not. So, it's kind of consistent this way. (I understand that's not what the project guidelines says.) And I would like to catch up with the changes I have on my github project. It will take 20-30 more patches like this. It's much easier to do this if I can diff the two source tree... And when I'm done with it, will make a patch on capitalization only, where we can fix my bad English, or reformulate comments when needed.
Mar 3 2017
change decorator to a simple higher order function. call is explicit now.
Feb 24 2017
Thanks Devin to clarify it in details. Before your comments were too high level, abstract to me. I prefer concrete code examples in reviews... So, thanks again, really appreciated.
Feb 23 2017
Thanks Devin your explanation. I think decorators are kind of higher-order functions. Functions which are taking one-or-more functions as argument. It's a pretty powerful abstraction. And I don't think it's hard to understand them... But let's say, they are complex and scan-build-py shall not have any!
Feb 19 2017
Feb 14 2017
Feb 6 2017
Jan 30 2017
What is the benefit of the declarative decorator syntax here vs. a more imperative "with ... as" or a generator? It seems to me that using decorators here obscures the key components of the actual behavior of the function (calling the compiler, calling the analyzer) and makes it much harder to understand what the function is supposed to do.
Jan 29 2017
Jan 28 2017
Is there an easy way to detect at run time whether the SELinux setup forbids library preload?
About the SELinux change. If the SELinux setup forbid the library preload, it won't work. But till now I have not met system which was configured like that. (Tested on Fedora 22-25.)
Jan 21 2017
Nov 15 2016
simplify intercept module
Nov 13 2016
fixed the issues i found and added tests too
Nov 9 2016
unfortunately this code still has major issues, which i just caught recently with tests. fix comes soon. sorry.
Nov 8 2016
Sep 23 2016
commited at r282317
Sep 13 2016
thanks Devin, i like smaller code, have no problem with this change. :)
Sep 2 2016
looks good to me. i like the test. :) but would keep the pep8 cleanness.
Aug 31 2016
Gyorgy and the ericsson team, thanks for doing this. very good job! good targeted functionality. i don't want to underestimate the complexity it requires, but to me this is a giant code. i do miss the explanation of the overall functional description what a module does and how it relates to other modules. i found a gap between the high level overview and the code comments.
generally speaking i found this code under documented and a bit verbose. the comments in the code is not really paint the picture that i need in order to fix a bug, or implement a feature. and it might only be my personal taste, but found that creating types (or classes this case) in a dynamically typed script language, it makes the code very verbose while it does not implement much.
was commented only on two random modules, but found the same patterns in many other ones.
found that this code is not pep8 conform. pylint found a lot of errors and warnings, and a couple of duplicate codes.
i hope we can fix these findings and that would make this code more solid and understood by others.
Jun 12 2016
hey Devin, thanks for looking to it.
Apr 19 2016
Apr 16 2016
thanks Devin for the review. your comments are addressed in the new commit.
Mar 20 2016
a gentle ping
Mar 13 2016
dear Devin and Anna,
Feb 23 2016
hey Anna, thanks for your reply!
Feb 21 2016
- -m* Perl implementation scan-build takes it in. i took it out, and got error reports that is actually needed for many cases.
- -W* Perl implementation scan-build takes only the warning suppress flags -Wno-*, but says " We don't care about extra warnings, but we should suppress ones that we don't want to see." in the comment.
Feb 20 2016
the semicolon at the end of line 39 is an issue for PEP8. please remove it.
thanks Anton, LGTM!
Feb 1 2016
to me it appears a more reasonable solution. (it does not require a separate method and unit test around it.) maybe the same effort could be focus to write a functional test for it... that's only my thoughts. Devin or Anna, could you share your opinion?
Jan 31 2016
sorry for it, but was thinking on the weekend and i have a lame question after the hard work: why not just append a -UNDEBUG to the end of the argument list? would not it make the same effect?
Jan 29 2016
Jan 28 2016
thanks Yury for the update.
Jan 21 2016
$ PATH=$(pwd)/bin:$PATH python -m unittest -v
I don't think so:
Jan 19 2016
Jan 12 2016
Thank you guys for your review and help! The latest patch is commited. Let's do the next steps too. ;)
Jan 5 2016
sorry for the delay, hard to get free time these days. ;)
Dec 14 2015
Dec 11 2015
previous upload is broken, sorry for that
Dec 10 2015
thanks for the comments.
Dec 9 2015
Also, what do you think about renaming intercept-build to "log-build" or some of the other alternatives I proposed above? I think it is important for the name of the executable to communicate its purpose.