Heh, interesting. I honestly hadn't considered the process-boundary, but that's also a problem. I'll check this out, thank you.
Let me ask a more direct question: if I wanted to test Frank, what language do you think I'd use? Right now Maru is looking attractive. One line of thinking is to test each DSL in itself, unless there's... maybe... a good language for testing things. Maybe it's just Lisp. Or maybe it's something I haven't thought of. In an environment, I'd like to be able to get a pulse on complexity without necessarily reading all of the code (you can't, there's 70,000,000 lines in there, and generally I'm lucky to read all of the *new* code, which only gives me a glimpse.) Of course in the future I do hope to have a system with many orders of magnitude less code jammed into it:) Most of the bugs seem to hang out around a) complexity, and b) integration points (which is likely a special case of a.) By test, I think what I have is a euphemism for automatically repeatable experimentation, but most of what I do doesn't get to be very scientific, which makes me sad. It's more like throwing dynamite into a lake to find out what's down there. Another term that might describe it well could be "executable specification" but in practice, there's never enough time to specify anything other than the things that we figure out we want to worry about, which is an entirely human/manual process in most cases. Anyway if we're going to have executable specs, I'm not sure we'd want to write two (one to represent, one to verify.) Seems like duplication of effort and I wish one could get both at once. C On Aug 19, 2011, at 8:09 PM, Monty Zukowski <[email protected]> wrote: > 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 _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
