bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2017-10-24T05:02:23Zhttps://gitlab.idiap.ch/bob/bob.io.base/-/issues/4Can't write big one-element ndarray in HDF5 using set_attribute method2017-10-24T05:02:23ZAndré AnjosCan't write big one-element ndarray in HDF5 using set_attribute method*Created by: acostapazo*
When I try to write a single-element numpy.ndarray to HDF5File with certain size (e.g 10000)
e.g
```
import bob, numpy
f = bob.io.HDF5File("t.hdf5", "w")
a = numpy.random.rand(10000)
f.set_attribute("a", a...*Created by: acostapazo*
When I try to write a single-element numpy.ndarray to HDF5File with certain size (e.g 10000)
e.g
```
import bob, numpy
f = bob.io.HDF5File("t.hdf5", "w")
a = numpy.random.rand(10000)
f.set_attribute("a", a)
```
I get the following error:
RuntimeError: HDF5File - set_attribute ('t.hdf5'): C++ exception caught: 'call to HDF5 C-function H5Acreate() returned error -1. HDF5 error statck follows:
H5Acreate2() @ ../../../src/H5A.c+256: unable to create attribute
H5A_create() @ ../../../src/H5A.c+505: unable to create attribute in object header
H5O_attr_create() @ ../../../src/H5Oattribute.c+347: unable to create new attribute in header
H5O_msg_append_real() @ ../../../src/H5Omessage.c+224: unable to create new message
H5O_msg_alloc() @ ../../../src/H5Omessage.c+1945: unable to allocate space for message
H5O_alloc() @ ../../../src/H5Oalloc.c+1142: object header message is too large'
If I use set method instead set_attribute, it works fine.
e.g
```
import bob, numpy
f = bob.io.HDF5File("t.hdf5", "w")
a = numpy.random.rand(10000)
f.set("a", a)
```
Moreover, if I use a numpy with less size, I can use both methods without any problem.
e.g.
```
import bob, numpy
f = bob.io.HDF5File("t.hdf5", "w")
a = numpy.random.rand(1000)
f.set("a1", a)
f.set_attribute("a2", a)
```
The point is that it works well with small arrays and it exist some problem when the attribute it's bigger than certain value.https://gitlab.idiap.ch/bob/bob.io.base/-/issues/3HDF5 files for Machines and version numbering2017-10-24T05:02:23ZAndré AnjosHDF5 files for Machines and version numbering*Created by: tiagofrepereira2012*
Original issue here: https://github.com/idiap/bob/issues/142*Created by: tiagofrepereira2012*
Original issue here: https://github.com/idiap/bob/issues/142https://gitlab.idiap.ch/bob/bob.io.base/-/issues/2Can't write one-element ndarray in HDF52017-10-24T05:02:23ZAndré AnjosCan't write one-element ndarray in HDF5*Created by: tiagofrepereira2012*
Issue copied from here: https://github.com/idiap/bob/issues/165*Created by: tiagofrepereira2012*
Issue copied from here: https://github.com/idiap/bob/issues/165https://gitlab.idiap.ch/bob/bob.io.matlab/-/issues/2Fails to compile on mac on conda-forge2017-10-04T03:59:18ZAndré AnjosFails to compile on mac on conda-forge*Created by: 183amir*
Log: https://travis-ci.org/conda-forge/bob.io.matlab-feedstock/jobs/125958770
Pull: https://github.com/conda-forge/bob.io.matlab-feedstock/pull/1
Error:
```
gcc -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -Wno-s...*Created by: 183amir*
Log: https://travis-ci.org/conda-forge/bob.io.matlab-feedstock/jobs/125958770
Pull: https://github.com/conda-forge/bob.io.matlab-feedstock/pull/1
Error:
```
gcc -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -Wno-strict-aliasing -DBOB_EXT_MODULE_PREFIX="bob.io.matlab" -DBOB_EXT_MODULE_NAME="_library" -DBOB_EXT_ENTRY_NAME=PyInit__library -DBOB_EXT_MODULE_VERSION="2.0.4" -DHAVE_BOOST=1 -DBOOST_VERSION="1.60.0" -DHAVE_MATIO=1 -DMATIO_VERSION="1.5.6" -DHAVE_BLITZ=1 -DBLITZ_VERSION="0.10" -DPY_ARRAY_UNIQUE_SYMBOL=BOB_NUMPY_C_API -DNO_IMPORT_ARRAY=1 -DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION -I/Users/travis/miniconda3/envs/_build/lib/python3.5/site-packages/bob/blitz/include -I/Users/travis/miniconda3/envs/_build/lib/python3.5/site-packages/bob/extension/include -I/Users/travis/miniconda3/envs/_build/lib/python3.5/site-packages/bob/io/base/include -I/Users/travis/miniconda3/envs/_build/include -I/Users/travis/miniconda3/envs/_build/lib/python3.5/site-packages/bob/core/include -I/Users/travis/miniconda3/envs/_build/include/python3.5m -c bob/io/matlab/utils.cpp -o build/temp.macosx-10.5-x86_64-3.5/bob/io/matlab/utils.o -std=c++0x -Wno-#warnings -isystem /Users/travis/miniconda3/envs/_build/lib/python3.5/site-packages/numpy/core/include -isystem /Users/travis/miniconda3/envs/_build/include
In file included from bob/io/matlab/utils.cpp:11:
In file included from bob/io/matlab/utils.h:18:
In file included from /Users/travis/miniconda3/envs/_build/lib/python3.5/site-packages/bob/io/base/include/bob.io.base/array.h:18:
In file included from /Users/travis/miniconda3/envs/_build/include/blitz/array.h:37:
In file included from /Users/travis/miniconda3/envs/_build/include/blitz/array-impl.h:46:
/Users/travis/miniconda3/envs/_build/include/blitz/blitz.h:152:5: error: Blitz is configured with --enable-threadsafe, but no compiler thread support is found. Did you forget, e.g., "--pthread"?
#error Blitz is configured with --enable-threadsafe, but no compiler thread support is found. Did you forget, e.g., "--pthread"?
^
1 error generated.
```https://gitlab.idiap.ch/bob/bob.extension/-/issues/6bob_new_version.py misses a good "default" for version numbers2018-06-04T12:44:45ZAndré Anjosbob_new_version.py misses a good "default" for version numbers*Created by: anjos*
This is a **very** useful script. It would be an awesome addition if we could have either a flag (or the absence of any) to implement a "default" version releasing.
How would that work?
1. bob_new_version.py re...*Created by: anjos*
This is a **very** useful script. It would be an awesome addition if we could have either a flag (or the absence of any) to implement a "default" version releasing.
How would that work?
1. bob_new_version.py reads the file `version.txt` and figures out what is the "next" release.
2. It sets the stable version to that value (minus the `aX`, `bX` or `rcX` complements, of course).
3. It sets the latest version to be the value in item 2 above + one minor patch number. For example, if the value on `version.txt` was '2.0.5b0', then `stable = 2.0.5` and `latest = 2.0.6b0`.
This way it would be possible to issue something like:
```shell
$ ./bin/bob_new_version.py --default-release
```
And get the ball rolling. This would also allow us to batch release a number of packages at once, w/o taking into consideration differences between release numbers.
If a new API release is on the horizon, the developer must updated "version.txt" so that the file `version.txt` is correctly preset (e.g., to `2.1.0b0`). This way `bob_new_version.py --default-release` will do the right thing next time.
@siebenkopf: What do you think?https://gitlab.idiap.ch/bob/bob.io.base/-/issues/1check for float32 not working => creating "segmentation fault"2017-10-24T05:02:23ZAndré Anjoscheck for float32 not working => creating "segmentation fault"*Created by: khoury*
Hello,
I was getting "segmentation fault" lately while developing some code.
The reason is mainly because the check of the data format is not working properly.
Thank you,
Elie
*Created by: khoury*
Hello,
I was getting "segmentation fault" lately while developing some code.
The reason is mainly because the check of the data format is not working properly.
Thank you,
Elie
https://gitlab.idiap.ch/bob/bob.extension/-/issues/5Macports Portfiles generation2018-06-04T12:44:45ZAndré AnjosMacports Portfiles generation*Created by: tiagofrepereira2012*
Since Bob is already on macports, the update of each package in this repository is a bit painful.
Basically for each package update we are supposed regenerate the Portfile (the installation instructio...*Created by: tiagofrepereira2012*
Since Bob is already on macports, the update of each package in this repository is a bit painful.
Basically for each package update we are supposed regenerate the Portfile (the installation instructions for the macports) and open a ticket on macports attaching the ```diff``` between this new Portfile with the current.
Would be awesome to have a step on ```new_version.py``` script to the that for us
The steps are the following (I will use the package py-bob-blitz as a reference)
1 - Download the current Portfile from the macports official repository (http://svn.macports.org/repository/macports/trunk/dports/python/py-bob-
blitz/Portfile)
2 - Update the line that corresponds the version (line 11 in this example)
3 - Update the line that corresponds the github tag (line 27 in this example)
4 - Download the tarball (last tag) from github (bob.blitz in this case)
5 - Generate ```sha256``` and the ```rmd160``` checksums
6 - Update the line that corresponds with the checksums (lines 34 and 35 in this example)
7 - Save this Portfile in a new file
8 - Generate the ```diff``` of this new Portfile with the original one
I think it is doablehttps://gitlab.idiap.ch/bob/bob.extension/-/issues/4Out-of-source builds2018-06-04T12:44:45ZAndré AnjosOut-of-source builds*Created by: siebenkopf*
I lately (0b8cfa8a4e77ff36b5efa8cfe657fa7774930158) implemented an option for out-of-source builds, which is based on an environment variable ``BOB_BUILD_DIRECTORY``.
To be consistent, it would be nice to have...*Created by: siebenkopf*
I lately (0b8cfa8a4e77ff36b5efa8cfe657fa7774930158) implemented an option for out-of-source builds, which is based on an environment variable ``BOB_BUILD_DIRECTORY``.
To be consistent, it would be nice to have a flag in the ``buildout.cfg`` instead, but I am not familiar enough with the buildout system to do that myself.https://gitlab.idiap.ch/bob/bob.io.audio/-/issues/3ImportError: libpng12.so.0: cannot open shared object file: No such file or d...2018-09-10T18:00:19ZAndré AnjosImportError: libpng12.so.0: cannot open shared object file: No such file or directory*Created by: 183amir*
I am having a very strange error when building `bob.io.audio`:
```python
import: 'bob.io.audio'
Traceback (most recent call last):
File "/home/amir/miniconda3/conda-bld/test-tmp_dir/run_test.py", line 31, i...*Created by: 183amir*
I am having a very strange error when building `bob.io.audio`:
```python
import: 'bob.io.audio'
Traceback (most recent call last):
File "/home/amir/miniconda3/conda-bld/test-tmp_dir/run_test.py", line 31, in <module>
import bob.io.audio
File "/home/amir/miniconda3/envs/_test/lib/python3.5/site-packages/bob.io.audio-2.0.0-py3.5-linux-x86_64.egg/bob/io/audio/__init__.py", line 4, in <module>
from ._library import *
ImportError: libpng12.so.0: cannot open shared object file: No such file or directory
```
I have `libpng16.so.0` installed but why is it trying to import libpng?
Here is the full log:
[log.txt](https://github.com/bioidiap/bob.io.audio/files/161156/log.txt)
https://gitlab.idiap.ch/bob/bob.extension/-/issues/3CMake builds are always RELEASE builds2018-06-04T12:44:45ZAndré AnjosCMake builds are always RELEASE builds*Created by: siebenkopf*
Just to keep track: Currently, compiling a Library with CMake always uses -DCMAKE_BUILD_TYPE=RELEASE, even when debug option is set in the options. A check for these options need to be implemented.
Also, the ...*Created by: siebenkopf*
Just to keep track: Currently, compiling a Library with CMake always uses -DCMAKE_BUILD_TYPE=RELEASE, even when debug option is set in the options. A check for these options need to be implemented.
Also, the compiler between the Python extensions and the C++ libraries might differ. Maybe we should try to unify them. First trials showed that this might not be that easy...https://gitlab.idiap.ch/bob/bob.io.audio/-/issues/2Documentation of bound C++ classes does not use bob::extension documentation ...2018-09-10T18:00:19ZAndré AnjosDocumentation of bound C++ classes does not use bob::extension documentation style*Created by: siebenkopf*
I had a look through the documentation of ``bob.io.audio`` and I saw that the style differs from our defined default. When checking the source code, I found that it does not make use of the ``bob::extension::Fun...*Created by: siebenkopf*
I had a look through the documentation of ``bob.io.audio`` and I saw that the style differs from our defined default. When checking the source code, I found that it does not make use of the ``bob::extension::FunctionDoc`` and similar classes. So, why did I make the effort to create these classes, if you are not using them?Manuel Günthersiebenkopf@googlemail.comManuel Günthersiebenkopf@googlemail.comhttps://gitlab.idiap.ch/bob/bob.extension/-/issues/2Enabling debug mode2018-06-04T12:44:45ZAndré AnjosEnabling debug mode*Created by: siebenkopf*
When I write C++ code, I couldn't find an option to enable DEBUG mode. Specifically, I want to write some 'assert' statements, which should be checked in debug mode.
There is the option parameter "extra_compi...*Created by: siebenkopf*
When I write C++ code, I couldn't find an option to enable DEBUG mode. Specifically, I want to write some 'assert' statements, which should be checked in debug mode.
There is the option parameter "extra_compile_args" in the setup.py, but even after setting 'extra_compile_args = ["-ggdb"]', the assertion
assert (1 == 2);
passes. I think, this is due to the fact that by default the '-DNDEBUG' macro is enabled, which disables 'assert' to be evaluated.
https://gitlab.idiap.ch/bob/bob.extension/-/issues/1mr.developer is run before 'setup_requires' is evaluated2018-06-04T12:44:45ZAndré Anjosmr.developer is run before 'setup_requires' is evaluated*Created by: siebenkopf*
I created a package to implement functionality in C++. For this package (xbob.boosting) I used xbob.extension to enable the C++ compilation. This works fine.
Now, to use this package, I created another packag...*Created by: siebenkopf*
I created a package to implement functionality in C++. For this package (xbob.boosting) I used xbob.extension to enable the C++ compilation. This works fine.
Now, to use this package, I created another package that imports xbob.boosting using mr.developer. When I try to call 'bin/buildout', I get the error message:
from xbob.extension import Extension
ImportError: No module named extension
Obviously, it cannot find xbob.extension. So, I tried to put the 'setup_requires = ["xbob.extension"]' into the setup.py and the 'xbob.boosting' section into the buildout.cfg of my new package, but without success.
It seems that mr.developer is run and tries to update external packages BEFORE the setup.py is interpreted.
P.S. I had the same issue, when I put used the mr.developer in the original xbob.boosting package. Disabling mr.developer, the original package worked fine. https://gitlab.idiap.ch/bob/bob.io.audio/-/issues/1Cannot find pkg-package 'sox'2018-09-10T18:00:19ZAndré AnjosCannot find pkg-package 'sox'*Created by: siebenkopf*
When I build the package, I get the error that
```
RuntimeError: pkg-config package `sox' was not found
```
I tried to install the``sox`` package using
```
sudo apt-get install sox
```
which succeeded, b...*Created by: siebenkopf*
When I build the package, I get the error that
```
RuntimeError: pkg-config package `sox' was not found
```
I tried to install the``sox`` package using
```
sudo apt-get install sox
```
which succeeded, but the error remains.
Which is the correct package to install to get ``sox`` running? Should we add that to the installation instructions of this package, or even to the global Bob installation instructions?https://gitlab.idiap.ch/bob/bob.db.xm2vts/-/issues/3Biased protocol2017-08-27T02:22:00ZAndré AnjosBiased protocol*Created by: tiagofrepereira2012*
Hi,
I was using the XM2VTS interface and I just realized that all protocols are biased.
If you check the command below, it is possible to observe that the same client is in the world, dev and eval s...*Created by: tiagofrepereira2012*
Hi,
I was using the XM2VTS interface and I just realized that all protocols are biased.
If you check the command below, it is possible to observe that the same client is in the world, dev and eval sets.
Is that correct?
This is the original protocol or is it a bug?
```python
import bob.db.xm2vts; db = bob.db.xm2vts.Database();
print db.clients(groups="world")
print db.clients(groups="dev")
print db.clients(groups="eval")
```
Thanks
Tiago
https://gitlab.idiap.ch/bob/bob.db.xm2vts/-/issues/2The 'world' objects are a subset of the 'dev' objects2017-08-27T02:22:00ZAndré AnjosThe 'world' objects are a subset of the 'dev' objects*Created by: siebenkopf*
I guess I found a severe bug in the implementation of the XM2VTS database. I think this is related to the __group_replace_alias__ function.
The problem is that the 'world' objects:
> world = db.objects(group...*Created by: siebenkopf*
I guess I found a severe bug in the implementation of the XM2VTS database. I think this is related to the __group_replace_alias__ function.
The problem is that the 'world' objects:
> world = db.objects(groups='world')
seems to be a subset of the 'dev' objects:
> dev = db.objects(groups='dev')
> all(obj in dev for obj in world)
True
A related problem is that the clients for 'world', 'dev', and 'eval' groups are identical:
> len(db.clients())
295
> len(db.clients(groups='world'))
200
> len(db.clients(groups='dev'))
200
Having a closer look, one can see that the clients are actually identical. I guess that this should not be the case.
Cheers
Manuelhttps://gitlab.idiap.ch/bob/bob.db.xm2vts/-/issues/1Data organization2018-06-05T07:53:07ZAndré AnjosData organization*Created by: laurentes*
There are two distinct problems:
1. The current API only allows the user to deal with still images of the database.
2. The current API assumes that the data of the database is stored in subdirectories, one for ea...*Created by: laurentes*
There are two distinct problems:
1. The current API only allows the user to deal with still images of the database.
2. The current API assumes that the data of the database is stored in subdirectories, one for each identity. It would be better to organize data in the same way as it is currently shipped when you order the database.
To solve both problems, this would require me to have the original CDs/DVDs of the database or at least to know the directory structure and the files contained in each subdirectory. Unfortunately, this is not the case, as the data we have at Idiap have very likely been reorganized over the years.
Could anyone provides me the file hierarchy for both image and/or audio data, in order to fix this issue?
Thanks in advance.
https://gitlab.idiap.ch/bob/bob.db.voxforge/-/issues/4Aborting and resuming the download script2017-10-22T18:34:52ZAndré AnjosAborting and resuming the download script*Created by: 1kastner*
The download and untar script checks whether a directory already exists and in that case it skips it. So generally speaking the script is capable of being aborted and resumed at a later point. Only one problem exi...*Created by: 1kastner*
The download and untar script checks whether a directory already exists and in that case it skips it. So generally speaking the script is capable of being aborted and resumed at a later point. Only one problem exists: if you start to download the same file the second time, wget adds ".[number]" at the end of the file, so "file.tgz.1" for the second attempt and so on. That means, the script in its current implementation processes the first download attempt and hence the broken file.
One fix which is customized for my personal needs can be found at https://gist.github.com/1kastner/46a6e8510c47901cb55d - I am not that well in shell scripting. It should take the file name "name.tgz.[HIGHEST_NUMBER]" instead of the first download attempt.
I hope I could make my point clear.https://gitlab.idiap.ch/bob/bob.db.voxforge/-/issues/3script/download_and_untar.sh incompatible with zc.buildout installation2017-10-22T18:34:52ZAndré Anjosscript/download_and_untar.sh incompatible with zc.buildout installation*Created by: 1kastner*
Like this the shell script does not work in case you used zc.buildout. Even the shell script is not shipped. I could use it and modified it for my purpose like this:
https://gist.github.com/1kastner/587ec3b395be7...*Created by: 1kastner*
Like this the shell script does not work in case you used zc.buildout. Even the shell script is not shipped. I could use it and modified it for my purpose like this:
https://gist.github.com/1kastner/587ec3b395be715c3461
If it could be shipped in the normal bob buildout process and further adjusted for that, that could be great!https://gitlab.idiap.ch/bob/bob.db.voxforge/-/issues/2VoxForge data are expected in a subdirectory 'audio'2017-10-22T18:34:52ZAndré AnjosVoxForge data are expected in a subdirectory 'audio'*Created by: laurentes*
The original VoxForge data are currently expected in a subdirectory 'audio/'. This is not required and it would even be better not to have this. We just need to update the lists to fix this issue.*Created by: laurentes*
The original VoxForge data are currently expected in a subdirectory 'audio/'. This is not required and it would even be better not to have this. We just need to update the lists to fix this issue.