Closed jagalindo closed 3 years ago
The pysat_metamodel requires the Microsoft Visual C++ 14.0 or greater. This dependency can be download from: https://visualstudio.microsoft.com/visual-cpp-build-tools/ You need to install at least:
However, another error raises and the pysat_metamodel plugin cannot be installed. See trace-windows.txt
Installation works fine, despite an error appears related to python-sat module, but it seems to be magically fixed. See trace-linux-setupb.txt
However, when running one of the entrypoints (main2.py) the error "Plugin not found" appears, but both plugins (fm_metamodel and pysat_metamodel) were installed. See linux-plugin-error.txt
The Relation class is a bit tricky: a feature can have one or more relations with other features. This is very flexible because it allows us to model two important things: (1) arbitrary group cardinalities (a..b), and (2) multiple decomposition type (e.g., a feature can have an "or-group" and a mandatory child).
However, it would desirable to directly access to the parent of a given a feature, but this is not possible with the current information in the feature class. In case a "get_parent()" method is required, I think the best solution for this is having a helper class to avoid modifying the core metamodel.
By the moment I only have worked in Linux, following the guide in the core repository and I found the same two problems as jmhorcas. The first problem related in python-sat module, also appear if you try to install the requirements.txt in core repository by the command "pip install -r requirements.txt" with other modules. The problem is in wheel dependence that is not installed in virtual environment, so that setup.py try to install the dependencies directly, this the reason for the magically fix. But this way is very inefficient instead of create a wheel by setup.py bdist_wheel. So the solution is install wheel by "pip install wheel" inside of the virtual environment, and command bdist_wheel must work fine. The second problem seems more complex and now I haven't any idea. I think that module famapy inside in core is being confused with famapy metamodels modules installed.
Is there a plan to include support for abstract features? Although it seems to be a trivial characteristic which can be implemented with a simple attribute in the feature class, it affects some analysis operations because abstract features bring up the differentiation between configurations (include abstract features) and products (only include concrete features). This will affect operations like valid product, valid configuration, #products, or #configurations, among maybe others.
Let us suppose we want to use an operation analysis (e.g., valid configuration) in a specific point of my application: with the current famapy architecture we instantiate the operation and use it directly at such code point of my appplication. However, there is some issues with that:
To solve both issues in my project, temporary, I've created a AAFMsHelper class with different analysis operations without relying on the pugling system. Check https://github.com/jmhorcas/fm_montecarlo/blob/main/famapy/metamodels/fm_metamodel/utils/aafms_helper.py
My two cents on the last comment. This is worth a meeting. We had that issue on a previous tool also. The solution I see is to have m2t transformation at the pysat level so we don't have to transform it anymore e.g. a cnf transformation. Also, we need to introduce the staged configurations and those should be applied to be applied or unapplied.
Howdy guys, @Virako made a great work with the development of a Makefile that will ease off introductory problems for devs. Now we move to python 3.9, and yes... by now, we are not taking into account windows devs for the automatic mode (see readme.md)
Generate notes on the issues that developers will face when dealing with the project to be later added to the documentation.