Open monochromata opened 9 years ago
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. 1) The CR dependency is only adds 1.2Megs (excluding source), and that's with all available bundles (CR core is only 700k). That's smaller that jactr.io. It's file footprint is negligible. And since only the classes needed are ever loaded, it has no performance overhead. 2) Similarly, is install time really an issue? I'm all for a streamlined user experience, but unless you are installing as frequently as you run the model, it seems like a non-issue. 3) Most importantly, the intent you describe is not prohibited at all with the current structure.
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. 3) I'll have a look at org.jactr.embed (and also org.jactr.launching).
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: