You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/source/vara-ts-api/data.rst
+6-6
Original file line number
Diff line number
Diff line change
@@ -98,7 +98,7 @@ Module: data_manager
98
98
Module: version_header
99
99
......................
100
100
101
-
.. automodule:: varats.data.version_header
101
+
.. automodule:: varats.base.version_header
102
102
:members:
103
103
:undoc-members:
104
104
:show-inheritance:
@@ -111,12 +111,12 @@ Data providers
111
111
Providers are a means to supply additional data for a :ref:`project<Projects>`.
112
112
For example, the :ref:`CVE provider` allows access to all CVEs that are related to a project.
113
113
114
-
You can implement your own provider by creating a subclass of :class:`~varats.data.provider.provider.Provider` in its own subdirectory of ``data/provider``.
114
+
You can implement your own provider by creating a subclass of :class:`~varats.provider.provider.Provider` in its own subdirectory of ``provider`` in varats-core.
115
115
There is no restriction on the format in which data has to be provided.
116
116
The ``Provider`` abstract class only requires you to specify how to create an instance of your provider for a specific project, as well as a fallback implementation (that most likely returns no data).
117
-
If your provider needs some project-specific implementation, create a class with the name ``<your_provider_class>Hook`` and make the projects inherit from it, similar to the :class:`~varats.data.provider.cve.cve_provider.CVEProviderHook`.
118
-
If a project does not inherit from that hook, your provider's :func:`~varats.data.provider.provider.Provider.create_provider_for_project` should return ``None``.
119
-
In that case, the :func:`provider factory method<varats.data.provider.provider.Provider.get_provider_for_project>` falls back to your default provider implementation and issues a warning.
117
+
If your provider needs some project-specific implementation, create a class with the name ``<your_provider_class>Hook`` and make the projects inherit from it, similar to the :class:`~varats.provider.cve.cve_provider.CVEProviderHook`.
118
+
If a project does not inherit from that hook, your provider's :func:`~varats.provider.provider.Provider.create_provider_for_project` should return ``None``.
119
+
In that case, the :func:`provider factory method<varats.provider.provider.Provider.get_provider_for_project>` falls back to your default provider implementation and issues a warning.
120
120
For an example provider implementation take a look at the :ref:`CVE provider`.
121
121
122
122
@@ -131,7 +131,7 @@ For an example provider implementation take a look at the :ref:`CVE provider`.
Copy file name to clipboardExpand all lines: docs/source/vara-ts-api/data_providers/cve_provider.rst
+4-4
Original file line number
Diff line number
Diff line change
@@ -2,19 +2,19 @@ CVE Provider
2
2
------------
3
3
4
4
This provider allows access to CVEs associated with a project.
5
-
It relies on a :class:`hook<varats.data.provider.cve.cve_provider.CVEProviderHook>` to know what CVEs belong to that project and uses heuristics to determine which revision fixed a certain CVE.
5
+
It relies on a :class:`hook<varats.provider.cve.cve_provider.CVEProviderHook>` to know what CVEs belong to that project and uses heuristics to determine which revision fixed a certain CVE.
Copy file name to clipboardExpand all lines: docs/source/vara-ts-api/experiments.rst
+3-3
Original file line number
Diff line number
Diff line change
@@ -11,12 +11,12 @@ For example, how a specific project is compiled is the responsibilitty of the pr
11
11
Designing a new ``Experiment`` is also quite simple.
12
12
13
13
* First, create a new python module in the ``experiments`` directory and add an experiment class which inherits from ``benchbuild.experiment.Experiment``.
14
-
If VaRA-TS should provide automatic support for analyzing different versions, i.e., different revisions of a git based project, use :class:`~varats.utils.experiment_util.VersionExperiment` as base class.
14
+
If VaRA-TS should provide automatic support for analyzing different versions, i.e., different revisions of a git based project, use :class:`~varats.utilss.experiment_util.VersionExperiment` as base class.
15
15
* Second, define two static variables for your experiment: ``NAME`` and ``REPORT_TYPE``
16
16
* Next, override the ``actions_for_project`` method.
17
17
This method should assign run-time/compile-time extensions and specify the list of actions that should be performed.
18
18
Each action the experiment does is called a ``Step`` and will be executed by BenchBuild in order.
19
-
* Last, add your experiment for testing to the BenchBuild config file `vara-root/benchbuild/.benchbuild.yml` under plugins/experiments/value. After testing, integrate them into the tool suite by adding it to the experiment list in ``varats.utils.settings.generate_benchbuild_config``, so it will be automatically added to the BenchBuild config in the future.
19
+
* Last, add your experiment for testing to the BenchBuild config file `vara-root/benchbuild/.benchbuild.yml` under plugins/experiments/value. After testing, integrate them into the tool suite by adding it to the experiment list in ``varats.utilss.settings.generate_benchbuild_config``, so it will be automatically added to the BenchBuild config in the future.
20
20
21
21
.. note::
22
22
For more information about ``Experiment``'s consider reading the BenchBuild `docs <https://pprof-study.readthedocs.io/en/master/>`_.
0 commit comments