Re: subdivide large .ttcn files for faster dev cycle

My vague idea for subdivision was to group by meaningful themes, for example, putting all the "cnpool" tests in a separate file, all segfault triggering tests in another; somesuch could even help readability... Hm, for me, usually the test runs I do are very rapid. Well, it may be subjective, but the CPU running hot so much is annoying to me, and the wait always feels just a bit too long. For me it's an itch that could be scratched, slight bummer that you still disagree =) Oh, I didn't know that! I thought the implicit division in multiple compilation units is pretty cool, and every now and then also hits ccache well, too, but often I wish it could be sub-dividing more intelligently, to favor that as many sub-units as possible remain identical. Currently, often just a small change in some function that happens to be at the top of the .ttcn file causes all sub-parts to be recompiled, instead of just, say, part 2. Sometimes when tweaking I try to cheat so that the line numbers don't change further down in the file. (Maybe I'm naive there, I have no knowledge how the subdivision is done.) interesting! In Java .. To gain speed ... My past experience with Java is that it feels slow, like you can watch it think, like a train station departure info board settling to a new frame. Compilation of .class files is NOT fast in my xp. And always the Classpath and jar files and weird build systems... I'm frowning a bit, I had hoped that I had left the Java world behind for good. I wonder if it could be feasible to write an interpreter for ttcn, instead of generating code from it that is then again compiled before running... Even if the interpreter is not lightning fast, it would completely eliminate that wait time from .ttcn to running the test. There is usually plenty of idle time during test runs, anyway, seems silly to optimize the execution speed. Thanks for the cool feedback! ~N