Have you seen Causeway? Sounds like it might be a start toward what you desire.
http://www.erights.org/elang/tools/causeway/ Causeway is an open source postmortem distributed debugger for examining the behavior of distributed programs built as communicating event loops. Its message-oriented approach follows the flow of messages across process and machine boundaries. http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html An increasing number of developers face the difficult task of debugging distributed asynchronous programs. This trend has outpaced the development of adequate debugging tools and currently, the best option for many is an ad hoc patchwork of sequential tools and printf debugging. This paper presents Causeway, a postmortem distributed debugger that demonstrates a novel approach to understanding the behavior of a distributed program. Our message-oriented approach borrows an effective strategy from sequential debugging: To find the source of unintended side- effects, start with the chain of expressed intentions. We show how Causeway's integrated views - describing both distributed and sequential computation - help users navigate causal pathways as they pursue suspicions. We highlight Causeway's innovative features which include adaptive, customizable event abstraction mechanisms and graphical views that follow message flow across process and machine boundaries. Monty On Fri, Aug 19, 2011 at 3:26 PM, Casey Ransberger <[email protected]> wrote: > At work there are generally a small pile of languages in play: a "backend" > language (Perl and Java seem common here,) sometimes a separate language for > the web "front end," this has often been Ruby of late, a relational language > (thus far always a SQL variant,) and the now ubiquitous Javascript. > I test big web apps, usually. When I'm doing automation, I'm often > frustrated by a "language barrier." Sometimes I can get a lot of mileage out > of a meta-object protocol in languages which have one. But as the > application under test is regularly written in multiple languages, the > places where different subcomponents connect are problematic, I lose this > leverage here, because these languages don't share a MOP. > In the future, I want to be able to have this cake and eat it too. I'm not > sure what that looks like or even what to call it. Maybe it's a domain > specific language for test automation, or perhaps more interestingly, a > meta-meta-object protocol (TM!) > I note that when my backend is written in Java, it still makes some sense to > choose (of the "company approved languages") e.g. Ruby to do the automation. > More and more I just wish they'd let me use Lisp. This is partly because I'm > typically outnumbered by line developers by a wide margin and want all of > the leverage I can get. > I wonder what people here would think about these ideas. Alex Warth > mentioned an "omnidebugger" and I almost wonder if whatever approach works > for that might work for this. Maybe a common intermediate representation is > all I need to do it. > -- > Casey Ransberger > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
