I wonder, what would be there:
TO DO: What's so special about string and text processing?
trace:
http://pdos.csail.mit.edu/~engler/cool-people.html
http://pdos.csail.mit.edu/~engler/
http://www.stanford.edu/~engler/
big Q: where is Open Source of all that cool stuff?
?Or is it again:
---- Indeed, one of my major complaints about the computer field is that whereas Newton could say, "If I have seen a little farther than others, it is because I have stood on the shoulders of giants," I am forced to say, "Today we stand on each other's feet." Perhaps the central problem we face in all of computer science is how we are to get to the situation where we build on top of the work of others rather than redoing so much of it in a trivially different way. Science is supposed to be cumulative, not almost endless duplication of the same kind of things. R. W. Hamming One Man's View of Computer Science 1968 Turing Award Lecture ----
I acually started form my very first topic here, which has some new appearance in lkml:
http://article.gmane.org/gmane.linux.kernel/680465
Andi says, patches will have feedback. I want: developing tools to have feedback too. Or it's just another handcrafting "know how" and "gimme the patch or stfu" of kernel developers. Oh, well...
I try to develop not just analysis, but text transforming. Document it, make it be an easy tool to access (e.g. `sh` && `sed` script). Allow it to be re-usable and re-editable for further similar tasks. Nobody understands, as it seems...
____
strange system...
So, after years of granted academia work, they went commercial, still having research going on.
Strange system...
All so-called 'papers' are available to download -- also strange for most for-paper-research workers...
I want every source code base to have tools (syntax highlightng, simple semantic annotations by designer's for easy static analysis, easy call-chain walkers, etc.) for editors, IDEs to prevent programmer from making bugs (obvious, or most known mis-uses of interfaces, or context-specific security holes known for decades, etc.) to do it as interactively as possible using syntax highlighting and non stupid user interface.
They have set up firm to provide payed bug-killling.
Where's the right and where is the wrong end of the telescope?
> to do it as interactively
> to do it as interactively as possible using syntax
> highlighting and non stupid user interface.
for example, one types
spin_lock(&some_lock);, editor generates a checking template for allreturnto havespin_unlock(&same_lock).Cases, when unlocking is done in another function, simple annotation can be used:
What if many locks, functionality must be annotated? Gee...
As with sp@m, all can be done by
`sed`easily. But yet another editor must be invented for such interactity.Even more crazy. Use ordering of source as locking is done and preprocessor:
# define _some_lock_ spin_lock(&some_lock); ..../* same body */ spin_lock(&some_lock); # undef _some_lock_ ##### # define _some_lock_ret spin_lock(&some_lock); ..../* unlock is in another body */ spin_lock(&some_lock); # undef _some_lock_retPath Projection for User-Centered Static Analysis Tools
http://www.cs.umd.edu/~jfoster/path-proj.pdf
To address this problem, we present a new user interface toolkit called Path Projection that helps users visualize, navigate, and understand program paths|call stacks, control flow paths, or data flow paths -- which are a common component of many static analysis tools' error reports.
Again, why not in editors? Why to do not allow errors in the first place, using various policy applications while editing source?
____
contrary, what D. Knuth said, Massalin dreamed
After lwn's "Open Source Security Report".
Funny enough, that this "Coverity" thing and its autors are quite reverse, to what Knuth said:
I.e. they have research on self-modifying code `C compiler, middle-ground (not a micro, not monolitic) way of building OS kernel -- quite interesting and IMHO useful. But they turned to the universe of bugs, most of which is invisible one (-- dark matter -- dream of modern corrupted physicist).
Year, bugs, bugs, bugs. Worth to note, that Massalins's hope for hardware support of self-modifying code in the future
was nicely "supported" by hardware bugs, which causes self-modifying code to fail.
Oh, well...
I wonder what all non-food-producing, non-oil-pumping, non-energy-generating people are doing, including never-ending kernel and compiler "development" with enterprize products for barin-washed-end-users.
____