Clarify dependencies #7
Comments
The more I think about this, the bigger of a problem it becomes. The CR dependency isn't really that heavy. jACT-R core uses it for clocks and a common format for processing percepts. Strictly decoupling jact-r from CR would require rewriting all of the perceptual modules to use yet another abstract representation - which is exactly what CR was designed for. The perceptual modules are no longer consider optional, and as such.. I'd like to keep the dep. What is the rationale behind the desire to decouple from CR? If you are not using PM modules, the cost of the dependency is negligible. |
One possibility:
|
Additionally..
|
My rationale is to use jACT-R without the existing perceptual motor modules and to embed it into an existing application that runs the jACT-R model in the application process instead of starting a separate process as is done when launching a jACT-R model in Eclipse. I'd use a custom visual module (REMMA) and compute activation values. I wouldn't need motor modules. To speed up installation it would be good if users didn't need to download commonreality and the perceptual-motor modules. (I leave this complication to the end: Eclipse would be the existing application.) Sorry for being unclear about this in the first place. Adding a layer of abstraction between CR and jactr would not be required. The proposals in your second to last comment fit my case. |
Let me address each of these as separate points.
I am still 100% in favor of cleaning up dependencies. I just want to make sure we are doing it for the right reasons, at the right time, and in the right way. |
1+2) Ok, if resource consumption is not an issue, we do not need to extract separate org.commonreality.time and org.jactr.modules.pm bundles. This would leave
|
To be able to use jactr without jactr-eclipse and commonreality when embedded without eclipse and commonreality:
(1) jactr should not depend on jactr-eclipse and commonreality,
(2) jactr-eclipse should only depend on jactr, and
(3) commonreality should not* depend on jactr. (* added in an edit)
Anthony:
" - we can remove the CR dependency, but it would require the following:
- a jactr runtime specific interface for the clock control mechanism
- a separate bundle to bridge jactr-cr"
The text was updated successfully, but these errors were encountered: