beat.core issueshttps://gitlab.idiap.ch/beat/beat.core/-/issues2019-05-06T13:35:08Zhttps://gitlab.idiap.ch/beat/beat.core/-/issues/78Plotterparameter saving is not operational2019-05-06T13:35:08ZSamuel GAISTPlotterparameter saving is not operationalCurrently the implementation of the writing of a Plotterparameter can succeed.
The implementation is wrong and there are elements of the class that are missing.Currently the implementation of the writing of a Plotterparameter can succeed.
The implementation is wrong and there are elements of the class that are missing.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/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/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/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/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/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/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/93New environment descovery does not respect the raise on error property2020-01-29T13:15:19ZSamuel GAISTNew environment descovery does not respect the raise on error propertyIf the discovery process using image labels is run on a machine without docker running or if the daemon is not running, it will fail as expected however the error handling does not follow the raise on error property.
To reproduce, call ...If the discovery process using image labels is run on a machine without docker running or if the daemon is not running, it will fail as expected however the error handling does not follow the raise on error property.
To reproduce, call `beat editor refresh-env` on a machine without docker or with the daemon stopped.
A current workaround is to create the `.environments.json` file in the prefix with `{}` as its content.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/101Add tmpfs when running a container2020-07-29T09:18:53ZSamuel GAISTAdd tmpfs when running a containerDespite the tests run in the various aspects of the BEAT code base which showed that having the container start read-only was successful, actual run on the platform started to unsuccessfully fail with an error related to temporary file c...Despite the tests run in the various aspects of the BEAT code base which showed that having the container start read-only was successful, actual run on the platform started to unsuccessfully fail with an error related to temporary file creation coming from the entrypoint script loading the correct conda environment.
"Unsuccessfully failed" here means that the full experiment run was marked as good despite that error happening which in fact did not even allow for a proper start of the execution procedure.
The fix for this situation is to add a minimal writable tmpfs for /tmp in order to have the space necessary for that file to be created.
It might also be useful to have one for /run even if it does not look like it is being used currently (at least in the same way as /tmp seemed to not be used).Soft loopsSamuel GAISTSamuel GAIST