On 05/12/2013, at 9:40 AM, srean wrote: > I see, so yes there is lot more to it than I thought. What I was really > asking but posing it badly was whether there is an easy way to isolate the > randomness in the execution environment of Felix. The motivation was to > explore the possibility to debug a complex system such as a web server by > debugging the functional parts in isolation, by giving it 'test' input. Now > its clear this is not easy. >
For most of the parts, actually it is. The webserver is using plugins to "pretty" print each "language" eg Felix, C++, fdoc, Ocaml, Python. And fdoc formatter uses plugins to make the pretty frame with navigation bar, to make the collapsible sections, etc. The plugins are separately compiled and linked shared libraries which could be tested either in isolation from the other parts, or dependent only on the other plugins that plugin itself uses. The reasons for doing this are your traditional arguments for OO: (a) separate compile and link for build performance (b) upgrade implementation without changing interface (c) enforced decoupling by the ultimate abstraction enforcer (dynamic loading is extremely good at enforcing explicit coupling) (d) reusability of the components in other programs and a few other things. As usually the problem here is a simple one: it takes time and effort to write a test harness and that has to be compared to other demands on my time. Other components are also separated. Felix is highly modular in construction. Look in build/release/host/lib/rtl and you'll see separately compiled shared libraries for many function blocks. For example the Garbage Collector depends on Judy, but otherwise is a separate binary. So the GC can be tested in isolation if necessary. Its not easy! The easiest way is actually just to use it. Felix test codes are the best because part of the mechanism depends on Felix compiler generated RTTI. SImilarly the Async I/O system which handles the sockets is isolated. In fact flx_run doesn't have any async I/O, flx_arun does: the same program with the async I/O removed. Its hooked by a single pointer. This system, however is tricky to test :) Especially as it uses a different demuxer (event polling thread) on every OS. Gotta run. But the system has been designed *properly*. Like, in all this code INCLUDING even the mainline drivers there are NO global variables. Even the debugging switches are passed around in structs. The whole system is entirely re-entrant. The only exceptions are badly design libraries I have to bind to, including in particular signal handling and C/C++ standard I/O and other badly designed software .. which unfortunately is a LOT of it. in particular is means two pthreads running felix spawned from a high enough level are as independent as two processes (share file handles etc but no memory). -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
