[Subversion] / Contextual / context_tests.txt |
No default branch
Bookmark a link to HEAD:
(view)
(download)
Bug fixes for state initialization and registry wildcard lookups.
Fix Service class definition failing if ClassAddOns are used in the class body (or any other non-string keys).
More tests, API tweaks, add a bit of docs.
Overhaul front-end API to "setting", "resource", "registry", and "resource_registry" (not tested/available yet). This is the absolute minimum number of elements to express the full possible generality, at the cost of having to use fixed parameter names to denote the nature of a setting (or resource's) input. A parameter of 'expr' means that the configuration will be lazy, and 'value' means it will be eager. There is no other real effect. The system now allows full generality in how input values are transformed to outputs (and/or validated). This pretty much nails the front-end API to something usable, and I intend to actually begin using it now. Everything should now be in place to implement configuration files, too, although for now I plan to just use Python code.
Added context.new() and context.empty(), along with a "root" state that holds only rules, not results (analagous to the old Config.root object). More "namespace" tests. ``.*`` rules still need some work before config files can be implemented, but most of the needed infrastructure is now in place.
Get rid of ``namespace``, and make all settings namespaces. Settings are now objects that pretend to be functions, instead of actually being functions. This is slightly slower, but the simplification and extended syntax capabilities are worth it. This thing is getting really close to being usable now.
Implement better scoping, by allowing states to be context managers. Also, renamed setting->value and parameter->expression. Expressions scan be scoped to services, such that a "resource" is just an "Action.expression" (i.e. an expression scoped to the nearest Action service). Instead of using 'with service_instance:', you now use 'with service_class.new():' to replace a service. The next refactoring will change keys from being functions, to being objects, allowing them to be set to either values or expressions dynamically. As a side-effect, this will drop the dependencies to both the SymbolType and ProxyTypes packages, although that's not the reason for doing it. The real reason is that it will allow things like this:: with context.new(): some_var << some_value other_var <<= lambda:some_expression # code that uses these variables as the canonical way to set variables in a context.
Another major refactoring -- merged Config and App into State, and implemented dynamic state propagation that eliminates the need to explicitly define ServiceAreas the way the PEAK core does. This new system is 100% lock-free and thread-safe (assuming that your own code is, too!) and has a smaller, friendlier API than the previous half-dozen attempts. The core state management system is now rock-solid, but there are a few minor areas where protocol changes may occur. See the "TODO" section in README.txt for details.
Draft implementation of Source and Line types to support compiling configuration file expressions such that tracebacks and pdb will be able to reference the configuration file contents for error messages or source listings. Adding encoding support would probably be a good idea, but is mostly orthogonal to other parsing issues at the moment. Universal configuration files, here we come!
Implemented EigenValue-style write-until-read immutability for Config objects. This new algorithm is actually thread-safe without needing any locks, by using the atomic properties of dictionaries, and by detecting conflicts *after* a write attempt is made. In the event of a race between two or more threads, it's nondeterministic who will "win", but there will be exactly one winner and all other writers will fail. Proof (informal): writes are copied into buffer[key] snapshot[key] is never modified except via setdefault -- therefore it can only ever have *one* value when snapshot[key] is set, its value comes from buffer[key]; thus, snapshot[key] is always *some* (indeterminately chosen) setting that was set by writing to the mapping, or by computing a default value. once a write is completed, snapshot.get(key, value_written) is used to verify that snapshot[key] is either *empty* OR a value that is the same as or equal to the value written. If the value is different, some other writer's value was read first, and our write is in conflict. If the value is the same, then our write was "successful", in that there is a *chance* it will be the end value of the setting. In other words, a succesful write does *not* necessarily mean that the written value is or will be "the" value. It is still possible to have non-deterministic behavior if multiple threads are simultaneously writing to the same Config, but it will not corrupt the Config or violate the "only one value is ever seen by readers" invariant. If precedence of an individual setting value matters, you must serialze the writes, but unserialized writes will not cause inconsistent behavior. This is a sufficient guarantee to allow e.g. configuration file loaders to be written.
Simplified App-switching API, added App[] delegation to its config, and add more docs.
Misc. cleanups, more API doc and tests
Major API overhaul. Service classes now act like peak.binding.Singletons, in that the class itself is a proxy for the current instance. This eliminates the need for two names to refer to the "same" object. Settings are now created with decorators, the module is peak.context instead of peak.util.context, and many many other changes. And there are still more to come, but mostly additions and some tweaks to how the App context works.
Begin re-org of tests/doc
Make README testable, add new files that 'context.txt' will be refactored into. Add 'context.replaces()' class decorator to make it easier to define an alternative service implementation.
cvs-admin@eby-sarna.com Powered by ViewCVS 1.0-dev |
ViewCVS and CVS Help |