User loginNavigation |
DryadLINQ
I don't think this project was mentioned here before. By Ehud Lamm at 2008-05-09 00:19 | Parallel/Distributed | login or register to post comments | other blogs | 422 reads
History of Logic Programming: What went wrong, What was done about it, and What it might mean for the futureCarl Hewitt is speaking tomorrow at Stanford's CSLI CogLunch on the history of logic programming. A paper is here, so LtU readers can offer their perspectives on the argument. By Ehud Lamm at 2008-05-07 23:03 | History | Logic/Declarative | 17 comments | other blogs | 2132 reads
Language geek at the Maker FaireMaker Faire was fun, but you can read all about it on numerous web sites and blogs. While I enjoyed the Coke + Mentos demonstration like everyone else, some things caught my eye in particular and may also amuse LtU readers. Talking to the guys demoing the CNC machines I discovered G Code which turns out to be the main machine languages used to control the CNC machines. It was cool to meet people who actually wrote their own software to emit or/consume G codes (the styrofoam CNC machine was way cool). I also enjoyed The Art of Motion Control sculpture, since the text said "Path designs using custom LISP routines running within AutoCAD." I think that was the only one explicitly mentioning Lisp. At least, that was the only one I saw... Any cool language references I missed? Automatic Generation of Peephole SuperoptimizersAutomatic Generation of Peephole Superoptimizers, Sorav Bansal and Alex Aiken, ASPLOS 2006.
It's always fun to see a method that ought to be intractable rendered tractable through a combination of cleverness and strategically applied brute force. I found their performance measurements suggestive but perplexing. Their results on their kernels are really astoundingly good, which they claim that is because they make use of the x86's SIMD instructions. But there is very little change in the SPEC benchmarks, and they subsequently suggest that their peephole optimizer catches many things that other compilers get via dataflow optimization. As a result, I don't feel like I have a clear picture of what their optimizer does and doesn't do, or where it does and doesn't overlaps with existing optimizations. But they definitely have enough to convince me that this is worth further study, so I really hope Bonsal and Aiken publish some more about this -- a tech report or journal paper with more systematic measurements and in-depth analysis would be really illuminating. Arrows generalise monads and idioms
Two fresh papers from the Edinburgh theory stable:
A located lambda calculusA located lambda calculus. Ezra Cooper and Philip Wadler. Submitted to ICFP 2008.
This paper is technical, and I assume most LtU members will mainly read sections 1, 5 & 6. Figure 5 is definition of the located LC. By Ehud Lamm at 2008-05-04 19:25 | Lambda Calculus | Parallel/Distributed | 6 comments | other blogs | 1519 reads
COLA BrainfuckFrom the Software Architecture Group at the Hasso Plattner Institut:
Previously: COLA and Open, extensible object models; via neuraxon77. By msimoni at 2008-05-01 07:58 | DSL | Implementation | Meta-Programming | 3 comments | other blogs | 2394 reads
Automatic Patch-Based Exploit Generation
Brumley, Poosankam, Song & Zheng, 2008. Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications:
The automatic patch-based exploit generation problem is: given a program P and a patched version of the program P′, automatically generate an exploit for the potentially unknown vulnerability present in P but fixed in P'. In this paper, we propose techniques for automatic patch-based exploit generation, and show that our techniques can automatically generate exploits for 5 Microsoft programs based upon patches provided via Windows Update. Although our techniques may not work in all cases, a fundamental tenet of security is to conservatively estimate the capabilities of attackers. Thus, our results indicate that automatic patch-based exploit generation should be considered practical. One important security implication of our results is that current patch distribution schemes which stagger patch distribution over long time periods, such as Windows Update, may allow attackers who receive the patch first to compromise the significant fraction of vulnerable hosts who have not yet received the patch.The technique is based on flow analysis, to test code that gets changed for boundaries where safety properties fail. The limitations of the technique they have developed automatically generate vulnerabilities for only a small fraction of propagated updates. Nonetheless I find it astonishing that such a simple analysis can provide such a payoff. Via Bruce Schneier. Species: making analytic functors practical for functional programmingSpecies: making analytic functors practical for functional programming, Jacques Carette and Gordon Uszkay. Submitted to MSFP 2008.
Learning more about the theory of species and working out its implications for programming has been on my to-do list for several years now. It really seems like the natural way to more tightly integrate combinatoric ideas into the functional programming style. (For an example of how fruitful this connection can be, consider how datatype differentiation explains zippers/functional pointers.) However, there's been this whole "graduation" and "primary research focus" stuff that's kept getting in the way, so I'm happy to see that Carette and Uszkay are figuring it out so I can just crib from them. :) program verification: the very ideaJames H. Fetzer's Program Verification: The Very Idea (1988) is one of the two most frequently cited position papers on the subject of program verification. The other one is Social Processes and Proofs by De Millo, Lipton, and Perlis (1979), previously discussed on LtU. Fetzer's paper generated a lot of heated discussion, both in the subsequent issues of CACM and on Usenet. It's not clear to me what all the fuss is about. Fetzer's main thesis seems pretty uncontroversial: The notion of program verification appears to trade upon an equivocation. Algorithms, as logical structures, are appropriate subjects for deductive verification. Programs, as causal models of those structures, are not. The success of program verification as a generally applicable and completely reliable method for guaranteeing program performance is not even a theoretical possibility. |
Browse archivesActive forum topics |