Comments on: DNA and RNA of Ruptured Computation https://www.dumpanalysis.org/blog/index.php/2009/10/23/dna-and-rna-of-ruptured-computation/ Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics Wed, 06 May 2026 21:04:18 +0000 http://wordpress.org/?v=2.3.3 By: Kyrie https://www.dumpanalysis.org/blog/index.php/2009/10/23/dna-and-rna-of-ruptured-computation/#comment-101922 Kyrie Sat, 31 Oct 2009 14:03:01 +0000 https://www.dumpanalysis.org/blog/index.php/2009/10/23/dna-and-rna-of-ruptured-computation/#comment-101922 You're welcome. : ) You’re welcome.
: )

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2009/10/23/dna-and-rna-of-ruptured-computation/#comment-100933 Dmitry Vostokov Tue, 27 Oct 2009 10:36:57 +0000 https://www.dumpanalysis.org/blog/index.php/2009/10/23/dna-and-rna-of-ruptured-computation/#comment-100933 Sounds interesting! Will think about it too Thank you, Dmitry Sounds interesting! Will think about it too
Thank you,
Dmitry

]]> By: Kyrie https://www.dumpanalysis.org/blog/index.php/2009/10/23/dna-and-rna-of-ruptured-computation/#comment-100407 Kyrie Sat, 24 Oct 2009 01:30:37 +0000 https://www.dumpanalysis.org/blog/index.php/2009/10/23/dna-and-rna-of-ruptured-computation/#comment-100407 I was thinking about something kinda similar to this today, and this post brings some toughts to me. By adding an abstract/semantical layer and simplyfying the inherent complexity of debuggers following the CHSL criteria that you wisely mentioned and reagrouping the most common anomalies in software functioning (crash, hang, spike and leak in this case) by some basic heuristic, I think there's a possibility to create a graphical debugging and analysis framework; just think about finding patterns in a software instructions flow, like EEELC (E stands for Expected result, L for Leak and C for Crash) by looking at a graph or any other data visualization method, i.e, among other possibilities. Just a thought, I hope I'd make my point clear. I was thinking about something kinda similar to this today, and this post brings some toughts to me. By adding an abstract/semantical layer and simplyfying the inherent complexity of debuggers following the CHSL criteria that you wisely mentioned and reagrouping the most common anomalies in software functioning (crash, hang, spike and leak in this case) by some basic heuristic, I think there’s a possibility to create a graphical debugging and analysis framework; just think about finding patterns in a software instructions flow, like EEELC (E stands for Expected result, L for Leak and C for Crash) by looking at a graph or any other data visualization method, i.e, among other possibilities.

Just a thought, I hope I’d make my point clear.

]]>