I am using JESS to write a program which eliminates some elements in the deftemplate for each rule that is fired.
I want to print out the results to a file after all rules have been fired.
I have put all the rules which effect the deftemplate in a defmodule, and made two seperate modules for reporting the results. but the point is the reporting modules are executed in between and therefore there rules will be fired,
I want to have the report modules executed at the end,
Can I use the defadvice after halt?
shall I add another rule saying that when all other rules from MAIN module are fired, then (focus Report1 Report2)?
Any assist will be appreciated,
Ali
You could put all the changing rules into a named module and
(focus Changes Report1 Report2)
Related
I'm using reagent to build several alternate root components, only one of which will be mounted on any given page; definitely either/or. These have a degree of commonality in their makeup, hence it will be convenient to move what is common among them to a common namespace.
What would be ideal is if in the file for each of these components I had the option to switch namespace into common, and add defs particular to the component, then switch back, thus avoiding circular dependencies nor needing any kind of inheritance.
I recalled this being possible in common lisp, how wonderful it was, and it also seems possible in clojure.
From Clojurescript docs: ns must be the first form and can only be used once, and in-ns is only usable from the repl.
I'm wondering if there's a way to achieve this kind of thing in clojurescript which is still eluding me.
If not I may need to reconsider my assumptions behind multiple alternate root components; the "many builds within one build" kind of idea, if that makes sense.
Update after some futher experimentation and confusion:
another option might be to split a single namespace across multiple files (is this possible?). Not sure what direction to turn in here.
The fact that in reagent I am using atoms in the global namespace is what's creating the need for circular dependencies if I use a separate namespace for common. Hence, wonder about one global namespace, in which case multiple files might help. Or is the way forward one giant file and one namespace??
Update: I've realised there is a great tension between keeping all app state globally (in my current case, multiple atoms), and passing app state around. My pattern currently is everything global, don't pass any of it around. Passing the necessary state as parameters to fns in the common namespace would solve the problem here (duh!), but then there's the question of what principles are being followed here regarding app state. If I just added a param whenever I needed one, but started with the idea that everything was global, there'd be no real principle to it...
In ClojureScript, everything is pre-compiled into a single static JavaScript "executable", so there is nothing like the repl you are used to in Clojure. Indeed, in CLJS the "Var" concept doesn't really after the compiler, they are just static (constant) variables and cannot be rebound.
Having said that, CLJS does emulate the behavior of Clojure dynamic variables via the binding form, so that may help you to reach your goal. As in CLJ, it creates what amounts to a (thread-local) global variable. This is a degenerate case in CLJS since there is only one thread. However, the source code looks identical to the CLJ case.
Another way to accomplish this is to just use a plain atom as a global variable so you don't have to pass a parameter around.
As always, when using a global variable, it reduces the number of parameters in function call trees, but it creates invisible dependencies between different parts of the code. Somethimes convenient, but usually a bad tradeoff.
It seems that the ClojureScript compiler compiles files in src in alphabetical order. Is there a way to make it start with the main target instead? I currently include a file aaa_init.cljs in my projects which just happens to allow me to ensure certain things happen first... but this feels like an awkward solution.
It is useful to control the order that files are processed in so that I can ensure (enable-console-print!) happens before printing, and I can use conveniences like defonce, and re-frames dispatch to set initial values.
Your question talks about two phases: compilation, and runtime. As far as I know, the order that you compile namespaces in will have no effect on runtime behaviour.
If you want (enable-console-print!) to be called before printing, or to dispatch initial values to re-frame, then those should happen in the :main function that you specify to the compiler. ClojureScript also has the ability to set :preloads which run before your main function. These are typically more for development time tooling that you want compiled out of your production build, but could possibly be used for what you're asking.
Using Om, it seems like passing relevant parts of the app state to child components is effectively the same thing as not passing any app state but using ref-cursors. What is the use case for ref-cursors over passing pieces of the app state down the chain?
I've read through all three of the tutorials and conceptual overview on the Om github repository but I cant really find an answer to this question. It seems like one could use either one or the other and accomplish the same thing (one either defines a component with (defn blah [_ owner] ...) and uses ref cursors or defines a component with (defn blah [relevent-state owner] ...)
Can someone clarify when I would want to use a ref cursor inside a component as opposed to simply passing part of the app state into that component?
This question is pretty old, but I'll give it a shot.
I believe the main use-case for ref-cursors is to promote modularity and decoupling of the global application state from components. It limits the scope of components to just the data that they depend on, and nothing else.
Normally, you'd pass application state and any change callbacks down the component tree via props, as you say. A consequence is that the component hierarchy becomes tightly coupled with the "shape" of the application state. The components hierarchy will have to match the state 1:1, or else many components will receive big blobs of data and callbacks that only a few subcomponents depend on, which they themselves may never actually use -i.e you might find yourself passing down parts of the global state down the component chain just so that components further down can have access to it. These components are being used as a channel for passing down state, which is not ideal because it exposes them to application state that they have no business knowing about. You run the risk of coupling and lose modularity.
With cursors, component dependencies are explicitly specified by each component upon mounting. The cursors are a black box into the application state -the component itself never has to know where inside the application it is situated. You have the full flexibility of stating a component's dependencies from anywhere in the application state without having to worry about all the transient data being passed around. You get one-way data flow without having to pass update callbacks down arbitrarily deep hierarchies. The end result is excellent component compartmentalization and modularity. As a bonus, you now have a single point into the application state that you can observe for changes!
I used it because when you update it, all of the observers get called.
recently, i ran into a problem where i needed to access the List object from the List's custom cell renderer class.
there were 2 options:
listen for and dispatch a custom event to communicate between the 2 classes.
reference the List from the cell renderer class with the parent property: List(parent.parent.parent)
while it's much easier to choose the second option, i feel that dispatching and listening for a custom event would result in code that's more inline with the design of AVM2, offers greater control for communication and, as it's expected AS3, should be less difficult to debug or maintain within new hands.
however, i also feel that using an event is more expensive, requires attention to resource management perhaps making it more difficult to debug and maintain and could be generally overkill.
is this simply a matter of needs or taste? should dispatching/listening for custom events be avoided if they can be?
Don't forget that you can't see the control flow of event listeners from single glances at the code.
While I'm not against event listeners completely, if you use them, you should try to use them in the most self-documenting and simple way possible. If you have clever stuff, like adding/removing event listeners, and it goes wrong, then it can be a nightmare to debug because you cannot see what dispatchEvent is going to do.
If owner gets you the right object, then I would just go with that, myself.
I would look at it from another angle. If the other option ends up creating more dependency between the two classes, I would definitely opt for event dispatching.
In that regard , I'm not sure why you think that an event driven application would be harder to debug & maintain. It would seem to be the opposite, but it would of course depends on how one implements the event dispatching in the application. But saying this and re-reading your question I realize you seem to contradict yourself! Of course , I tend to agree with the first statement.
...offers greater control for communication and, as it's expected AS3,
should be less difficult to debug or maintain...
...perhaps making it more difficult to debug and maintain and
could be generally overkill.
we use FxCop in current project. Warning CA1822 appears for every unit test method in test projects. So I would like to disable it for test projects.
Is it possible to suppress it for whole assembly?
In VS2005 & 2008, go to the Code Analysis tab in Project Properties and uncheck that rule.
In VS2010, create a custom ruleset with that rule disabled, then select it in the Code Analysis tab in Project Properties.
If you're using stand-alone FxCop with multiple assemblies in a .fxcop project then, no, there's no way to disable specific rules for only a subset of the analysis properties. Because of CA1822, I usually create two separte .fxcop projects: one to contain all the "real" code assemblies, and a separate one for the test assemblies in which CA1822 is disabled entirely.