beat.core issueshttps://gitlab.idiap.ch/beat/beat.core/-/issues2014-09-22T14:36:49Zhttps://gitlab.idiap.ch/beat/beat.core/-/issues/6Support for enumerations (migrated from github)2014-09-22T14:36:49ZAndré AnjosSupport for enumerations (migrated from github)I have not seen how to declare an enumeration. Is this possible at all? We do have use cases where we could benefit from this. E.g., client data migth belong to the "train", "devel" or "test" datasets. These could be implemented as enume...I have not seen how to declare an enumeration. Is this possible at all? We do have use cases where we could benefit from this. E.g., client data migth belong to the "train", "devel" or "test" datasets. These could be implemented as enumerations. Currently, in the UBM-GMM, I implement this field as an unchecked string.
Biometrics Center Kickoff Meeting and BEAT ReviewPhilip ABBETPhilip ABBEThttps://gitlab.idiap.ch/beat/beat.core/-/issues/42[io] Execute externally currently requires twisted (async.run)2017-08-06T11:17:03ZLaurent EL SHAFEY[io] Execute externally currently requires twisted (async.run)With the introduction of the new I/O framework, the execution of a job requires to launch the I/O daemon (that will launch and control the user process). This daemon currently needs twisted (async.run) to be executed, while we would idea...With the introduction of the new I/O framework, the execution of a job requires to launch the I/O daemon (that will launch and control the user process). This daemon currently needs twisted (async.run) to be executed, while we would ideally prefer not to have such a dependency in beat.core.
To fix this, an optimal decapsulation of the communication via pipes from the I/O daemon would be required, as well as its integration into beat.core.BTAS TutorialAndré AnjosAndré Anjoshttps://gitlab.idiap.ch/beat/beat.core/-/issues/41[io] Optimization of I/O when using pipes2017-08-06T11:17:03ZLaurent EL SHAFEY[io] Optimization of I/O when using pipesWith the introduction of communication via pipes between the user process and the daemon, it may happen that a chunk of data is decoded from a baseformat and then re-encoded (into a baseformat) to send it through pipe. This is the case, ...With the introduction of communication via pipes between the user process and the daemon, it may happen that a chunk of data is decoded from a baseformat and then re-encoded (into a baseformat) to send it through pipe. This is the case, when next() is called: a chunk of data is then read using a CachedDataSource (that will decode from a baseformat) and then sent through a pipe (and hence will be re-encoded into a baseformat). This is of course suboptimal and may be fixed by specializing the CachedDataSource.BTAS TutorialAndré AnjosAndré Anjoshttps://gitlab.idiap.ch/beat/beat.core/-/issues/90Execute experiment in different environment2019-10-07T13:31:09ZSamuel GAISTExecute experiment in different environmentCurrently, when executing an experiment on a local machine, the current environment is used and therefor must contain all the packages needed.
This is sub-optimal as several different experiences might required different sets of package...Currently, when executing an experiment on a local machine, the current environment is used and therefor must contain all the packages needed.
This is sub-optimal as several different experiences might required different sets of packages.
While this can't be done with the local executor, it can be implemented using the subprocess executor.
The subprocess executor makes call to the scripts needed to run the algorithms/databases processes as would be with the docker executor. This fact can be used to run the scripts from another environment and thus will use the packages available there.
This will also simplify the creation of new execution environment and their transition do docker images.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/87Remove parameters from analyzer block2019-08-19T19:15:28ZSamuel GAISTRemove parameters from analyzer blockCurrently analyzer blocks are treated mostly like normal algorithm blocks except the handling of the output.
This means that they can also have parameters. After several discussions, it has been concluded that having the possibility to ...Currently analyzer blocks are treated mostly like normal algorithm blocks except the handling of the output.
This means that they can also have parameters. After several discussions, it has been concluded that having the possibility to parametrize an analyzer would bring an unwelcomed level of complexity especially when creating reports.
If an analyzer should provide different outputs, then it should come in several versions to make it clear from the start what it will provide and how the analysis is done.
The following decisions have been made:
- Keep the current few analyzers that do have parameters as they are
- Remove the parameters field from the V2 algorithm schema for the analyzer definitionSoft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/86Loop parts name2019-07-31T08:30:04ZSamuel GAISTLoop parts nameBased on experience and discussions, the loop parts name are not really clear.
They will be changed to the following to make things clearer:
- XXX_loop_user -> XXX_loop_processor
- XXX_loop -> XXX_loop_evaluator
This will require upda...Based on experience and discussions, the loop parts name are not really clear.
They will be changed to the following to make things clearer:
- XXX_loop_user -> XXX_loop_processor
- XXX_loop -> XXX_loop_evaluator
This will require updates to the corresponding algorithms.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/85Synchronised input for loop blocks2019-07-30T12:56:03ZSamuel GAISTSynchronised input for loop blocksCurrently the two algorithm making a loop macro block are not synchronized input wise.
This is required in sequential mode so the validating part of the loop knows it uses
the same data as the current processing part.
This issue tracks...Currently the two algorithm making a loop macro block are not synchronized input wise.
This is required in sequential mode so the validating part of the loop knows it uses
the same data as the current processing part.
This issue tracks that input synchronization.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/84Implement output for loop block2019-07-30T07:15:14ZSamuel GAISTImplement output for loop blockCurrently the loop blocks don't have any outputs.
This issue tracks the implementation of this feature in the loop block.
One requested constraint for these outputs is that the write to them should happen when a write occurs in the out...Currently the loop blocks don't have any outputs.
This issue tracks the implementation of this feature in the loop block.
One requested constraint for these outputs is that the write to them should happen when a write occurs in the output of a loop user block.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/82Improve duplicate key handling2019-06-19T05:13:48ZSamuel GAISTImprove duplicate key handlingThis issue tracks the implementation of duplicated key handling in JSON files used.
In normal situation, the files should be edited and stored using beat/beat.editor> or currently still beat/beat.web> however if one does edit the declar...This issue tracks the implementation of duplicated key handling in JSON files used.
In normal situation, the files should be edited and stored using beat/beat.editor> or currently still beat/beat.web> however if one does edit the declaration file by hand, errors like duplicated key might be introduced which won't be caught as loading a JSON file line by line will result in a dictionary with the last entry being used (which is normal behavior when dealing with dictionary type of containers).
In our case, the system will generate an error so that nothing will run with unexpected values.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/79Implement missing prototypes2019-05-07T10:47:47ZSamuel GAISTImplement missing prototypesSome assets currently don't have prototypes and therefor cannot be created from scratch.
This issue tracks the implementation for them.
Currently needed:
- [x] Database
- [x] Experiment
Note that experiment can't be created from scrat...Some assets currently don't have prototypes and therefor cannot be created from scratch.
This issue tracks the implementation for them.
Currently needed:
- [x] Database
- [x] Experiment
Note that experiment can't be created from scratch so this use case is unsupported and should properly triggers an exception.
An experiment is based on a toolchain. Therefor providing a "prototype" doesn't make sense as its content would depend on what is available in the prefix. Also the person getting that "prototype" would first have to clear everything before it can start configuring the experiment as they would like.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/106ROS specific needs2020-11-30T08:50:02ZSamuel GAISTROS specific needsRequirement
===========
In the scope of the learn-real project, ROS is one of the possible system used however it needs to write some files (pids, small logs, etc.) in order to run properly however these can be discarded when the run en...Requirement
===========
In the scope of the learn-real project, ROS is one of the possible system used however it needs to write some files (pids, small logs, etc.) in order to run properly however these can be discarded when the run ends.
The current estimation done by @cazinn for the space needed is about 10Mb.
The ROS main folder is `~.ros` by default and that can be changed using the [ROS_HOME environment variable](http://wiki.ros.org/ROS/EnvironmentVariables#System_Data_Environment_Variables).
Current situation
=================
For security reasons, our containers are run in read-only mode with two small read/write tmpfs mounted on the containers: /tmp and /var. Each of which is allocated 500kb which is enough for the use of BEAT.
We do have support for adding temporary volumes in place as well as setting custom environment variables.
Possible solutions
==================
In order to run Docker containers that can execute ROS, we have several possibilities:
1) Mount a tmpfs volume on the default ROS home folder
2) Make either the `/tmp` or `/var` volumes bigger and point `ROS_HOME` in a subfolder in them
3) Add a new tmpfs volume in a separated known folder and point `ROS_HOME` to it
`ROS_HOME` can either be hardcoded during the image creation process or dynamically set when running the container.
Main questions
==============
For solution 1, from where should the information about the size of the target folder come from as well as the target location ?
For solution 2, `ROS_HOME` can be hardcoded as part of the image creation
For solution 3, same questions as for solution 1 with the possibility of hardcoding the environment variable as in solution 2.André AnjosAndré Anjoshttps://gitlab.idiap.ch/beat/beat.core/-/issues/105Refactor database sharing2020-11-17T12:09:23ZSamuel GAISTRefactor database sharingFollowing discussion on beat/beat.web!410, the database sharing feature will be refactored with the following:
- Add a new `direct_rawdata_access` optional field to the database schema
- Use that in place of the optional "share_databases...Following discussion on beat/beat.web!410, the database sharing feature will be refactored with the following:
- Add a new `direct_rawdata_access` optional field to the database schema
- Use that in place of the optional "share_databases" external field
- The field will apply to both v1 and v2 Database schema
- Support for optional field allows to keep the current databases workingSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/103Allow mounting of datasets folder on the algorithm container.2020-11-12T16:47:35ZSamuel GAISTAllow mounting of datasets folder on the algorithm container.In the context of the learn-real project, the training of robot related models requires the use of a very high number of images which can only be optimally loaded using PyTorch iterators.
This cannot be done currently as all data goes t...In the context of the learn-real project, the training of robot related models requires the use of a very high number of images which can only be optimally loaded using PyTorch iterators.
This cannot be done currently as all data goes through the database paradigm which cannot be used directly by PyTorch iterators.
Using the standard BEAT approach would lead to overly complex and inefficient implementation.
The solution proposed is that a new property can be inserted in the block configuration so that the root path of the database is also mounted on the algorithm container.
This will only work on algorithm containers that are connected to a database.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/89Improve output error messages2019-10-04T08:44:08ZSamuel GAISTImprove output error messagesWhen not enough data is written on an output, the related cache will be cleaned.
An error message must be shown to the user so he knows what is happening.When not enough data is written on an output, the related cache will be cleaned.
An error message must be shown to the user so he knows what is happening.https://gitlab.idiap.ch/beat/beat.core/-/issues/75Add BEAT classifier to setup.py2019-04-11T07:39:47ZSamuel GAISTAdd BEAT classifier to setup.pyThe classifier has been added to Pypi so it now can be used.
See beat/beat.backend.python#19The classifier has been added to Pypi so it now can be used.
See beat/beat.backend.python#19https://gitlab.idiap.ch/beat/beat.core/-/issues/73simplejson VS python json2019-03-20T11:27:56ZSamuel GAISTsimplejson VS python jsonThere's currently a mix of use between the python official json module and simplejson.
One of the side effect seen is that the official json module handles less input types as simplejson until python 3.6.
This can be an issue when usin...There's currently a mix of use between the python official json module and simplejson.
One of the side effect seen is that the official json module handles less input types as simplejson until python 3.6.
This can be an issue when using the system provided Python 3 on Debian 9 which is currently 3.5
Example of such situation:
- Receiving data through the network -> bytes are returned in Python 3
- Loading data from disk using pkg_resources -> bytes are returned
From a backward compatible point of view, it would make more sense to use simplejson because of these use cases.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/72Assert usage cleanup2019-05-09T13:26:49ZSamuel GAISTAssert usage cleanupFollowing bandit warning about usage of assert in code, this issue is used to track down the cleanup of these statements found in beat.core.
Depending on how they are used, the following actions can be done:
1. Turn the statement into ...Following bandit warning about usage of assert in code, this issue is used to track down the cleanup of these statements found in beat.core.
Depending on how they are used, the following actions can be done:
1. Turn the statement into an exception
2. Handle the case gracefully
3. Mark as not to get worried about
The current state of the code base is usually 3 which should be cleaned up.
All tests in this repository have been cleaned to use the testing framework corresponding toolshttps://gitlab.idiap.ch/beat/beat.core/-/issues/68Refactor ZMQ architecture2019-03-13T07:55:39ZSamuel GAISTRefactor ZMQ architectureThe current architecture works well but connection with the scheduler may get lost after a long period of network inactivity.
The task here is to refactor the architecture so that adding and removing node as well as crashing nodes gets ...The current architecture works well but connection with the scheduler may get lost after a long period of network inactivity.
The task here is to refactor the architecture so that adding and removing node as well as crashing nodes gets improved handling and thus avoids as much as possible "blocked" experiments.ZMQ resilience improvementSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/50Add support for fetching available package info from docker containers2018-10-24T07:39:16ZJaden DIEFENBAUGHAdd support for fetching available package info from docker containersSince (basically?) all the packages in a processing environment are installed through conda, and `docker-py` has support for [getting files from containers](https://docker-py.readthedocs.io/en/stable/containers.html#docker.models.contain...Since (basically?) all the packages in a processing environment are installed through conda, and `docker-py` has support for [getting files from containers](https://docker-py.readthedocs.io/en/stable/containers.html#docker.models.containers.Container.get_archive), getting the conda info from the container will give us the package info.
The format should be a dict of packages names pointing to their versions.https://gitlab.idiap.ch/beat/beat.core/-/issues/49Update the plotterparameter schema to associate it to a plotter2018-04-17T07:55:49ZJaden DIEFENBAUGHUpdate the plotterparameter schema to associate it to a plotterRight now there's no way to tell via the naming scheme or the plotterparameter JSON which plotter the parameter is associated to. The easiest way would be to add a field, say "plotter", which has the associated plotter object's name. See...Right now there's no way to tell via the naming scheme or the plotterparameter JSON which plotter the parameter is associated to. The easiest way would be to add a field, say "plotter", which has the associated plotter object's name. See beat.cmdline#20 for the discussion that led up to this.
The idea could be something like what I suggested in the other thread:
```json
{
"plotter": "plot/bar/1",
"grid": true,
"title": "DET ISO/IEC 19795-1:2006",
"title-fontsize": 12,
"det": true,
"legend-loc": "best",
"width": 800,
"height": 600,
"dpi": 120,
"legend-fontsize": 8,
"xlim-left": 0,
"xlim-right": 40,
"ylim-bottom": 0,
"ylim-top": 40,
"axis-fontsize": 10
}
```
The "plotter" field stores the reference to the associated plotter.
However, it might be best to use a field name that the user couldn't accidentally use, such as `#plotter`.
@samuel.gaist @flavio.tarsetti @andre.anjos what do you all think? This is sorta blocking time-sensitive work so it'd be better to decide quickly.