beat issueshttps://gitlab.idiap.ch/groups/beat/-/issues2019-10-04T15:12:54Zhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/190AssetType Unknown path spelling2019-10-04T15:12:54ZJaden DIEFENBAUGHAssetType Unknown path spellingSummary
The path for an "Unknown" AssetType is misspelled "unkown", which would probably lead to a weird bug months from now if we left it in.
Relevant logs and/or screenshots
https://gitlab.idiap.ch/beat/beat.editor/blob/31bd792c5bd4...Summary
The path for an "Unknown" AssetType is misspelled "unkown", which would probably lead to a weird bug months from now if we left it in.
Relevant logs and/or screenshots
https://gitlab.idiap.ch/beat/beat.editor/blob/31bd792c5bd450167fbf24f39666d86576e43a0b/beat/editor/backend/assetmodel.py#L44Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/189Package "pre-commit" doesn't exist in conda2019-10-04T15:12:54ZJaden DIEFENBAUGHPackage "pre-commit" doesn't exist in condaSummary
@samuel.gaist I've been setting up the v2 branch, following `contribute.rst`. It says to add "pre-commit" through conda. Did you mean "pre_commit"?Summary
@samuel.gaist I've been setting up the v2 branch, following `contribute.rst`. It says to add "pre-commit" through conda. Did you mean "pre_commit"?Samuel 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.cmdline/-/issues/49The necessary blocks are not properly checked before pushing an experiment to...2019-10-23T18:29:09ZZohreh MOSTAANIThe necessary blocks are not properly checked before pushing an experiment to the platformI tried to push an experiment to the platform but it was giving the error that certain algorithms do not exist. I had to push each algorithm manually. Also the version number of the algorithm in my local system was 2 but when it was uplo...I tried to push an experiment to the platform but it was giving the error that certain algorithms do not exist. I had to push each algorithm manually. Also the version number of the algorithm in my local system was 2 but when it was uploaded to the platform it changed to one, therefore I got error again and I had to edit my local experiment to use version one so that I be able to upload the whole experiment.https://gitlab.idiap.ch/beat/beat.cmdline/-/issues/50Pushing experiments to the platform is very tricky without informative warnin...2019-10-23T18:29:10ZZohreh MOSTAANIPushing experiments to the platform is very tricky without informative warnings or errors!The assumption is that you can pull an experiment from the platform, edit the necessary blocks (which means debugging the blocks without going through the pain of making new versions or forks for each block) and then push back to the pla...The assumption is that you can pull an experiment from the platform, edit the necessary blocks (which means debugging the blocks without going through the pain of making new versions or forks for each block) and then push back to the platform.
The issue is that in each experiment the user can use toolchains, or algorithms, etc that are public from other users and when they are pulled they are organized in folders with similar usernames in the user's local prefix folder.
With current setup if users want to edit some algorithm they **should** first copy them to their own name space.
If you do not make new algorithms under your own name space two scenarios may happen:
- You just edited the file from original user (not a good idea). `beat push` command in this situation does not push anything since it already exists on the platform.
- you made new version form the same algorithm which goes under the category of the original user. `beat push` command will create a new algorithm with the same name under your username with version number one without any warnings and it shows on the command line that the algorithm under the original username has been created.
The problem is since there is no error or warnings in such situations and nothing mentioned in the documentation it is tricky to find out where the problem comes from. It might be very confusing for the normal user to interact with beat.https://gitlab.idiap.ch/beat/beat.web/-/issues/512Documentation still mentions "Biometrics"2019-11-04T08:35:20ZAndré AnjosDocumentation still mentions "Biometrics"We should remove this from the docs.We should remove this from the docs.Zohreh MOSTAANIZohreh MOSTAANIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/249Nightlies are failing because of this package's tests2019-11-08T09:20:47ZAndré AnjosNightlies are failing because of this package's testsBoth linux builds are stuck and will stay like this until the timeout:
https://gitlab.idiap.ch/beat/beat.nightlies/pipelines/34701
@flavio.tarsetti: could you please check?Both linux builds are stuck and will stay like this until the timeout:
https://gitlab.idiap.ch/beat/beat.nightlies/pipelines/34701
@flavio.tarsetti: could you please check?Flavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.backend.python/-/issues/28License file location is wrong in conda recipe2019-11-14T15:58:26ZAndré AnjosLicense file location is wrong in conda recipeIt should read `LICENSE` instead of `../LICENSE`.
The same should be propagated to all relevant packages.It should read `LICENSE` instead of `../LICENSE`.
The same should be propagated to all relevant packages.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.cmdline/-/issues/63LICENSE file location in conda recipe is wrong2019-11-14T15:59:01ZAndré AnjosLICENSE file location in conda recipe is wrongIt should read `LICENSE` instead of `../LICENSE`.
The same should be propagated to all relevant packages.
See: bob/bob.devtools#44It should read `LICENSE` instead of `../LICENSE`.
The same should be propagated to all relevant packages.
See: bob/bob.devtools#44Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/91LICENSE file location in conda recipe is wrong2019-11-14T16:07:45ZAndré AnjosLICENSE file location in conda recipe is wrongIt should read `LICENSE` instead of `../LICENSE`.
The same should be propagated to all relevant packages.It should read `LICENSE` instead of `../LICENSE`.
The same should be propagated to all relevant packages.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/250LICENSE.AGPL file location is wrong in conda recipe2019-11-15T14:07:37ZAndré AnjosLICENSE.AGPL file location is wrong in conda recipeIt should read `LICENSE.AGPL` instead of `../LICENSE.AGPL`.
The same should be propagated to all relevant packages.
See: bob/bob.devtools#44It should read `LICENSE.AGPL` instead of `../LICENSE.AGPL`.
The same should be propagated to all relevant packages.
See: bob/bob.devtools#44Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/issues/92Simplifying toolchain connectivity2019-11-18T09:14:34ZAndré AnjosSimplifying toolchain connectivityThought about dumping this here, for tracking.
While discussing with @flavio.tarsetti on the toolchain editor and @tiago.pereira on snakemake and workflow definitions, a thought occurred that may simplify our lives and those of our user...Thought about dumping this here, for tracking.
While discussing with @flavio.tarsetti on the toolchain editor and @tiago.pereira on snakemake and workflow definitions, a thought occurred that may simplify our lives and those of our users a bit: why not avoiding this discrete port to port connection between blocks and accept "whole" block connections only?
The idea is to design toolchains only based on block connections instead of block input/outputs. As a result, a block that receives as an input data from another block, may access any of its outputs.
I'm not sure about the technical challenge(s) behind this, but that would definitely simplify the toolchain editor a bit.
My current understanding is that this does not affect block synchronization and may be relatively "easy" to implement.
@samuel.gaist: what do you think? Easy to roll out?Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/docs/-/issues/13Loop blocks are not described in the user guide2019-12-04T12:34:05ZAndré AnjosLoop blocks are not described in the user guideWe need to describe the loop blocks in a way that is similar to the current narrative.We need to describe the loop blocks in a way that is similar to the current narrative.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/245Improve error handling2019-12-11T09:57:48ZSamuel GAISTImprove error handlingSummary
Currently, there's lot of code triggering a RuntimeError which in turn will make beat.editor stop.
Most of these situations should be gracefully handled. If possible, a fix should be proposed to the user so he can continue work...Summary
Currently, there's lot of code triggering a RuntimeError which in turn will make beat.editor stop.
Most of these situations should be gracefully handled. If possible, a fix should be proposed to the user so he can continue working.
Steps to reproduce
1) Create a new Plotter
2) Load the plotter
This will make beat.editor crash as the new Plotter will be based on the prototype that contains an invalid entry.
This situation is already reported in #244
What is the current bug behavior?
beat.editor will end there
What is the expected correct behavior?
beat.editor should not stop
Possible fixes
The user should get a message about what is going wrong. If possible a fix should be proposed and applied if accepted.
In any case, the editor should continue working.[v2] 1 - Edition/Visualization for small editorsFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.web/-/issues/543Remove Google Analytics2020-01-16T08:51:02ZSamuel GAISTRemove Google AnalyticsCurrently Google Analytics is active on the website however, after discussion with @andre.anjos, the content it generates is not used at all and hasn't been for several years.
With new sets of laws like the GDPR (General Data Protection...Currently Google Analytics is active on the website however, after discussion with @andre.anjos, the content it generates is not used at all and hasn't been for several years.
With new sets of laws like the GDPR (General Data Protection Rugulation) or the CCPA (California Consumer Privacy Act), the platform must be update to either:
- Warn user of the use of this tool and provide them a way to disable it
- Remove the tool
The second solution has been chosen because it's the one that makes more sense and the less of work.Samuel 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.cmdline/-/issues/64Do not make the environment listing failed if platform is unavailable2020-01-29T13:16:11ZSamuel GAISTDo not make the environment listing failed if platform is unavailableAs implemented, the environment listing should not fail for local docker environment but it is currently not the case for listing the remote environment.
Both should behave the same. Therefore, if any error happens when contacting the p...As implemented, the environment listing should not fail for local docker environment but it is currently not the case for listing the remote environment.
Both should behave the same. Therefore, if any error happens when contacting the platform, it should be logged and the command continue showing an empty set of environment coming from there.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.backend.python/-/issues/30Error when waiting on a loop that wasn't started2020-02-06T17:36:09ZSamuel GAISTError when waiting on a loop that wasn't startedIf for some reason the loop, or database, `process` method was not called and `wait` is called, a runtime error will occur because the message handler was not started as expected by the current code.If for some reason the loop, or database, `process` method was not called and `wait` is called, a runtime error will occur because the message handler was not started as expected by the current code.Soft loopsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/33Copy/paste across tabs (via JSON copy/paste)2020-02-12T12:13:06ZJaden DIEFENBAUGHCopy/paste across tabs (via JSON copy/paste)https://gitlab.idiap.ch/beat/beat.editor/-/issues/37Segmented, editable connection lines2020-02-12T12:13:47ZJaden DIEFENBAUGHSegmented, editable connection lines