bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2016-08-04T09:30:47Zhttps://gitlab.idiap.ch/bob/bob/-/issues/119Proper definition and usage of the abstract Trainer template class2016-08-04T09:30:47ZAndré AnjosProper definition and usage of the abstract Trainer template class*Created by: laurentes*
For the major release 1.2.0, I would be in favour of consolidating the abstract Trainer class. There are trainer class that do not inherit from it. In this case, inheritance might help us to uniformise the API.*Created by: laurentes*
For the major release 1.2.0, I would be in favour of consolidating the abstract Trainer class. There are trainer class that do not inherit from it. In this case, inheritance might help us to uniformise the API.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/118Proper definition of the abstract Machine template class2016-08-04T09:30:45ZAndré AnjosProper definition of the abstract Machine template class*Created by: laurentes*
For the major release 1.2.0, I would be in favour of clearly:
1. Defining what a machine is: To my mind, it is something that can be trained (like the term 'machine' in 'machine learning'), and that ouputs somet...*Created by: laurentes*
For the major release 1.2.0, I would be in favour of clearly:
1. Defining what a machine is: To my mind, it is something that can be trained (like the term 'machine' in 'machine learning'), and that ouputs something given some input.
2. Updating the current abstract class API. To my mind, a machine should have:
- forward's methods
- load/save methods
- copy constructor, assignment operator, and comparison operators (==, != and is_similar_to)
Once done, we should update the 'machine' module accordingly. In addition, for each template, the generic Machine can be bound into python, which will help us to have a more consistent API.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/117"hides overloaded virtual function [-Woverloaded-virtual]" warnings with llvm...2019-02-13T14:33:28ZAndré Anjos"hides overloaded virtual function [-Woverloaded-virtual]" warnings with llvm/clang*Created by: laurentes*
I've noticed the following warnings when we use the llvm/clang compiler (only on OS X):
```
/Users/buildbot/work/buildbot/macosx-10.8-x86_64-incremental+master/build/include/bob/trainer/IVectorTrainer.h:122:10:...*Created by: laurentes*
I've noticed the following warnings when we use the llvm/clang compiler (only on OS X):
```
/Users/buildbot/work/buildbot/macosx-10.8-x86_64-incremental+master/build/include/bob/trainer/IVectorTrainer.h:122:10: warning: 'bob::trainer::IVectorTrainer::is_similar_to' hides overloaded virtual function [-Woverloaded-virtual]
1 warning generated.
/Users/buildbot/work/buildbot/macosx-10.8-x86_64-incremental+master/build/include/bob/trainer/IVectorTrainer.h:122:10: warning: 'bob::trainer::IVectorTrainer::is_similar_to' hides overloaded virtual function [-Woverloaded-virtual]
1 warning generated.
```
cf. [here](https://www.idiap.ch/software/bob/buildbot/builders/0-macosx-10.8-x86_64-incremental%2Bmaster/builds/465/steps/compile/logs/warnings%20%2819%29)
I don't understand why this is occuring. Does anyone have a clue? The recipe to get rid of them is to change the inline definition in the templated class EMTrainer
```c++
virtual bool is_similar_to(const EMTrainer& b, const double r_epsilon=1e-5, const double a_epsilon=1e-8) const
{
return m_compute_likelihood == b.m_compute_likelihood &&
bob::core::isClose(m_convergence_threshold, b.m_convergence_threshold, r_epsilon, a_epsilon) &&
m_max_iterations == b.m_max_iterations;
}
```
into a single declaration within the EMTrainer class definition
```c++
bool is_similar_to(const IVectorTrainer& b, const double r_epsilon=1e-5, const double a_epsilon=1e-8) const;
```
and a definition of this method outside the class as follows
```c++
template<class T_machine, class T_sampler>
bool bob::trainer::EMTrainer<T_machine,T_sampler>::is_similar_to(const bob::trainer::EMTrainer<T_machine,T_sampler>& b,
const double r_epsilon, const double a_epsilon) const
{
return m_compute_likelihood == b.m_compute_likelihood &&
bob::core::isClose(m_convergence_threshold, b.m_convergence_threshold, r_epsilon, a_epsilon) &&
m_max_iterations == b.m_max_iterations;
}
```
This only happens for is_similar_to method and not for operator==(), which means that the default/optional arguments might be the cause of the problem.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/115Logistic Regression does not implement regularization2016-08-04T09:30:38ZAndré AnjosLogistic Regression does not implement regularization*Created by: anjos*
This is a must when you start using LLR seriously, so I'd +1 this feature request.
More info and implementation details on Sebastien's lectures: http://www.idiap.ch/~marcel/lectures/lectures/epfl2013/FSPR_lecture4...*Created by: anjos*
This is a must when you start using LLR seriously, so I'd +1 this feature request.
More info and implementation details on Sebastien's lectures: http://www.idiap.ch/~marcel/lectures/lectures/epfl2013/FSPR_lecture4.pdfv1.2https://gitlab.idiap.ch/bob/bob/-/issues/114Publication for BOB hidden :-(2013-04-05T11:05:11ZAndré AnjosPublication for BOB hidden :-(*Created by: smarcel*
Hi guys
I suggest to copy the reference for BOB which is currently here:
https://github.com/idiap/bob/wiki/Publications
upfront on the website.
Either on the main page http://idiap.github.com/bob/
and/o...*Created by: smarcel*
Hi guys
I suggest to copy the reference for BOB which is currently here:
https://github.com/idiap/bob/wiki/Publications
upfront on the website.
Either on the main page http://idiap.github.com/bob/
and/or the most visited pages:
https://github.com/idiap/bob/wiki/Releases
http://www.idiap.ch/software/bob/docs/releases/last/sphinx/html/
v1.2https://gitlab.idiap.ch/bob/bob/-/issues/113Merging bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError2013-03-13T17:28:51ZAndré AnjosMerging bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError*Created by: laurentes*
The following two exceptions bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError have the exact same purpose. They should be merged.*Created by: laurentes*
The following two exceptions bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError have the exact same purpose. They should be merged.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/110IP bug for rgb_to_hsl: returns NaNs2016-08-04T09:30:30ZAndré AnjosIP bug for rgb_to_hsl: returns NaNs*Created by: csmccool*
The floating point implementations of "rgb_to_hsl" return NaNs if you pass an RGB array of ones (1.,1.,1.), however, the integer based methods don't seem to have this issue. Below are some examples of the problem ...*Created by: csmccool*
The floating point implementations of "rgb_to_hsl" return NaNs if you pass an RGB array of ones (1.,1.,1.), however, the integer based methods don't seem to have this issue. Below are some examples of the problem using the python interface:
```python
import bob;
import scipy;
bob.ip.rgb_to_hsl(scipy.array([[[1.]],[[1.]],[[1.]]])) # Using a scipy array or numpy array
```
RETURNS
```python
array([[[ nan]],
[[ nan]],
[[ 1.]]])
```
While
```python
bob.ip.rgb_to_hsl_f(1.,1.,1.)
```
RETURNS
```python
(nan, nan, 1.0)
```
The integer based methods seem to be ok as can be seen below:
```python
bob.ip.rgb_to_hsl_u8(255,255,255)
RETURNS
(0, 0, 255)
bob.ip.rgb_to_hsl_u16(65535,65535,65535)
RETURNS
(0, 0, 65535)
```
Cheers,
Chris.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/109libsvm 3.15 and 3.16 potential crash on svm_free_model_content()2019-07-16T14:50:50ZAndré Anjoslibsvm 3.15 and 3.16 potential crash on svm_free_model_content()*Created by: anjos*
The [following bug](https://trac.macports.org/ticket/37862) must be closed before we can properly release bob-1.2.0. The MacPort will be crippled without this.
The patch (to libsvm) is easy:
```patch
--- svm.c...*Created by: anjos*
The [following bug](https://trac.macports.org/ticket/37862) must be closed before we can properly release bob-1.2.0. The MacPort will be crippled without this.
The patch (to libsvm) is easy:
```patch
--- svm.cpp.orig 2013-01-31 12:03:51.000000000 +0100
+++ svm.cpp 2013-01-31 11:58:02.000000000 +0100
@@ -2747,6 +2747,7 @@
model->probB = NULL;
model->label = NULL;
model->nSV = NULL;
+ model->sv_indices = NULL;
char cmd[81];
while(1)
```
If you have problems using our libsvm bindings under MacPorts, please verify if you are not using one of the two versions of libsvm indicated in this bug report. If so, downgrade it to 3.14. or re-build it with the fix applied.
The author of libsvm has been informed of this problem and also the MacPorts maintainer. Both received the same patch instructions.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/107Warnings in bash scripts caused by CYGWIN check2016-08-04T09:30:24ZAndré AnjosWarnings in bash scripts caused by CYGWIN check*Created by: laurentes*
Recently, we introduced a specific test to set the PATH properly for CYGWIN in the following bash scripts:
- python/bin/gdbpy.in
- python/bin/ipython.in
- python/bin/python.in
This generates the following k...*Created by: laurentes*
Recently, we introduced a specific test to set the PATH properly for CYGWIN in the following bash scripts:
- python/bin/gdbpy.in
- python/bin/ipython.in
- python/bin/python.in
This generates the following kind of warnings under Ubuntu
```sh
./bin/python: 5: [: unexpected operator
```v1.2https://gitlab.idiap.ch/bob/bob/-/issues/106Blitz++ misdetection does not stop the build2013-03-07T11:10:47ZAndré AnjosBlitz++ misdetection does not stop the build*Created by: anjos*
Testing this unexpected feature of our build system on Arch Linux's buggy Blitz++ installation (no pkg-config for Blitz++ was available), made me realize that, at no times, we have a provision for a failed Bltiz++ de...*Created by: anjos*
Testing this unexpected feature of our build system on Arch Linux's buggy Blitz++ installation (no pkg-config for Blitz++ was available), made me realize that, at no times, we have a provision for a failed Bltiz++ detection or that it is not working adequately. A fix must be inserted before the next release.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/105Distance in KMeansMachine is square Euclidean2016-08-04T09:30:21ZAndré AnjosDistance in KMeansMachine is square Euclidean*Created by: laurentes*
Preparing the Bob tutorial, I've just noticed that the distance returned by the getDistanceFromMean() method of the KMeansMachine class is not the Euclidean distance, but the square Euclidean distance. This is no...*Created by: laurentes*
Preparing the Bob tutorial, I've just noticed that the distance returned by the getDistanceFromMean() method of the KMeansMachine class is not the Euclidean distance, but the square Euclidean distance. This is not a real problem because of the bijection between these two, but to my mind, this needs to be updated.
For this purpose, we need to update/add tests, and make sure that it does not affect our baseline results.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/104Wishes for the next major release (1.2.0)2019-02-13T14:33:28ZAndré AnjosWishes for the next major release (1.2.0)*Created by: laurentes*
I've decided to create a thread to help us to converge towards a better Bob for the next major release. I doubt we will have the time to deal with everything shortly, but there will be at least a trace of it. Fee...*Created by: laurentes*
I've decided to create a thread to help us to converge towards a better Bob for the next major release. I doubt we will have the time to deal with everything shortly, but there will be at least a trace of it. Feel free to update this thread with your thoughts/wishes.
## To consolidate what is already there
1. The user guide is already fairly good. I would not say the same about the documentation of the python bindings that show up when using the `help()` function of python. For many functions/classes, this documentation is very limited and unhelpful.
2. The library is becoming larger. We should have stricter rule when defining class methods that refers to the same concept. For instance, very often, we have a variable related to the input/feature dimensionality. Depending on the class, it might be obtained using a 'getDimD()', 'inputDims()', or whatsoever. I think this is very annoying from a user perspective. Same for the API of the trainers.
3. For many functions, we have two different kinds of python bindings: one kind which follows the C++ API (e.g. void f(const BA& input, BA& output)), and one which is more
'pythonic' (e.g. BA f(const BA& input)). These two bindings often share the same python function name. I don't think this is a good strategy, as these sometimes leads to impossible cases when the C++ API has many overloaded functions. I think the function name should reflect this difference. OpenCV strategy was roughly to used two different namespaces (cv for the C like functions, and cv2 for the pythonic one). We could do something slightly different such as appending the function name with something like '_c' or '_cc' to clearly highlight this fact.
4. ~~As previously discussed, the LBP code could be refactored in a single more generic but parametrized class.~~ (Already done by Manuel)
5. Learning from our previous experiences, I would be in favour of making mandatory a version number to any class that provides a 'save_to_hdf5' method.
6. ~~Add a tutorial for the Audio Processing module~~ (Already done by Elie)
7. Provide is_similar_to(const Object& b, const double epsilon=1e-8) functions for all C++ classes that have double members. The default "==" and "!=" operators are largely useless when we want to provide code that runs on several platforms (i.e., 32 and 64 bit machines).
8. ~~Whenever a C++ class uses some random initialization, make sure that you can seed this randomness.~~ (cf. issue #121 )
## To integrate new features
A. I would be nice that the combination of NumPy/SciPy/Bob roughly provides the same functionalities as the Matlab built-in functions. It would also be good to use similar function names such that it is easy for a user to move accross these platforms. A (too exhaustive) list can be found here: http://www.mathworks.ch/ch/help/matlab/functionlist.html
B. More Machine Learning algorithms:
B.1 In particular to add a Hidden Markov Model implementation, as there was one in late Torch 3.
B.2. To add a deformable and parts-based object recognition system (Felzenszwalb-like)
~~B.3 Integration of the i-vector framework~~ (Already done by Laurent)
C. More Audio Processing features:
C.1 Possibility to ~~compute and~~ plot spectrograms (Already done)
C.2 Audio codec to deal with wav and sphere files
C.3 Provide a bridge to HTK
C.4 Boosted Binary Features (cf. Anindya's thesis)
D. Image Processing Tools
~~D.1 GLCM features (Grey-Level Co-occurence Matrix)~~ (Already done by Ivana)
E. ~~Make compiling C++ bindings on satellite packages easier - we can move most of the functionality currently implemented on those packages like https://github/com/bioidiap/xbob.optflow.liu to the core of Bob.~~ (done by André)
F. New metrics: F1-score, precision and recall; cost versus training set size - This should be simple and an excellent coding exercise. If anyone wants to give it a go, please let me know. More info: http://en.wikipedia.org/wiki/F1_score
G. Better use of optimization library (L-BFGS-B) for NNet backprop implementation - this is a somewhat larger piece of work that goes around revisiting the NNet implementation to separate the optimizer from the trainer.
## To be more widely supported
1. ~~To make the Windows/Cygwin port functional~~ (cf. issue #82 )
2. To generate RPM like package:
* For Fedora: http://koji.fedoraproject.org/koji/
* For Suse: https://build.opensuse.org/
3. To generate a package for the TinyCore distribution: http://distro.ibiblio.org/tinycorelinux/downloads.html
In particular, it would be nice to automatize the process of generating a VirtualBox VDI with bob install, potentially based on the tiny linux distribution TinyCore.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/103Cepstral features finalization2016-08-04T09:30:16ZAndré AnjosCepstral features finalization*Created by: laurentes*
In order to finalize the Cepstral features extraction, there is a need to:
- Add default values in constructor (+python bindings) (done by @laurentes but please check default values)
- Make parameters names c...*Created by: laurentes*
In order to finalize the Cepstral features extraction, there is a need to:
- Add default values in constructor (+python bindings) (done by @laurentes but please check default values)
- Make parameters names comparable to the ones from existing software such as HTK
- Document methods in header and add inline comments directly in the code when required
- Add more tests with various parameters
- Add copy constructor, assignment operator, comparison operatorsv1.2https://gitlab.idiap.ch/bob/bob/-/issues/94Some mismatch in EER between bob and Bosaris2016-08-04T09:29:50ZAndré AnjosSome mismatch in EER between bob and Bosaris*Created by: khoury*
The EER computed by bob_compute_perf.py is little bit higher than the one using Bosaris Toolkit.
Here is the link for Bosaris Toolkit:
https://sites.google.com/site/bosaristoolkit/*Created by: khoury*
The EER computed by bob_compute_perf.py is little bit higher than the one using Bosaris Toolkit.
Here is the link for Bosaris Toolkit:
https://sites.google.com/site/bosaristoolkit/v1.2https://gitlab.idiap.ch/bob/bob/-/issues/90Version of Bob at configuration time is not trasmitted to setup.py2012-10-09T20:56:56ZAndré AnjosVersion of Bob at configuration time is not trasmitted to setup.py*Created by: anjos*
If I start Idiap's Bob:
```python
>>> import pkg_resources
>>> pkg_resources.require('bob')[0]
bob 1.1.0a0 (/usr/lib/pymodules/python2.6)
```
This needs fixing before release 1.1.1.*Created by: anjos*
If I start Idiap's Bob:
```python
>>> import pkg_resources
>>> pkg_resources.require('bob')[0]
bob 1.1.0a0 (/usr/lib/pymodules/python2.6)
```
This needs fixing before release 1.1.1.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/88Bob opportunistically links against Qt42016-08-04T09:29:40ZAndré AnjosBob opportunistically links against Qt4*Created by: anjos*
The current way the build is structured, there is no flag that allows us switching off ~~OpenCV and~~ Qt4 dependences. If they are available on the target system, they are compiled and linked into the final binaries....*Created by: anjos*
The current way the build is structured, there is no flag that allows us switching off ~~OpenCV and~~ Qt4 dependences. If they are available on the target system, they are compiled and linked into the final binaries.
This behavior is incompatible with packaging tools in which you can describe to which packages another package may depend on. If Bob opportunistically links against what is available, the packaging system will not detect real dependences and avoid, for example, OpenCV to be removed without Bob being removed first.
For the time being, a solution would be to make the build systems always install all dependencies.
This bug was triggered by a bug reported to us on MacPorts: https://trac.macports.org/ticket/36491v1.2https://gitlab.idiap.ch/bob/bob/-/issues/86Arrayset new features and improvements2016-08-04T09:29:36ZAndré AnjosArrayset new features and improvements*Created by: laurentes*
There are two new features that would be nice for the bob.io.Arrayset class.
1. There is currently no way to clear the content of an arrayset. The two options are a. to iterate over and delete the elements one b...*Created by: laurentes*
There are two new features that would be nice for the bob.io.Arrayset class.
1. There is currently no way to clear the content of an arrayset. The two options are a. to iterate over and delete the elements one by one or b. to delete the python object. It would be nice to introduce a clear() method.
2. There are only two possible states for an Arrayset:
* ``external`` where the content is in a file
* ``inlined`` where the content is stored in a set of bob.io.Arrays (as many as the number of samples in the Arrayset).
The ``inlined`` version might introduce a significant overhead when the Arraysets consists of many small Arrays, as in this case, there are as many Array headers as samples.
One solution would be to have a third state which stores the sample in a single Array, and where samples are obtained by slicing this Array over the third dimension.
Below is an example to highlight the problem:
Firstly, we allocate 50 samples of dimensions 1024*1024 double's, that is 400MBytes overall.
```python
import numpy, bob
A=bob.io.Arrayset(numpy.random.rand(50,1024*1024))
```
The memory usage reported (using command line tool "top") is roughly 400MB.
Secondly, we allocate 1024*1024 samples of dimensions 50 double's, that is 400MBytes overall as well.
```python
import numpy, bob
A=bob.io.Arrayset(numpy.random.rand(1024*1024,50))
```
The memory usage reported is about 800MB, which means an overhead of 100%. In particular, this occurs in common UBM/GMM experiments. Furthermore, it would be nice to find a fix.
Any suggestion is welcome.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/82No Windows port2019-06-24T13:44:12ZAndré AnjosNo Windows port*Created by: anjos*
Currently, we have no Windows port of Bob. This is a major problem as most researchers still use Windows. Let's put here information on how to create one and close this once a port is available.
Current status:
> T...*Created by: anjos*
Currently, we have no Windows port of Bob. This is a major problem as most researchers still use Windows. Let's put here information on how to create one and close this once a port is available.
Current status:
> The most promising solution for a *quicker* porting is to use [cygwin](http://www.cygwin.com/).v2.0https://gitlab.idiap.ch/bob/bob/-/issues/27Usage of abbreviations in namespaces2016-08-04T09:27:37ZAndré AnjosUsage of abbreviations in namespaces*Created by: siebenkopf*
When I try to read some C++ code of Bob, I often step over an abbreviated namespace (like tp for bob::python). Also in the python code, sometimes packages are abbreviated or, even worse, "from xxx import yyy as ...*Created by: siebenkopf*
When I try to read some C++ code of Bob, I often step over an abbreviated namespace (like tp for bob::python). Also in the python code, sometimes packages are abbreviated or, even worse, "from xxx import yyy as zzz" is used. This makes the code really hard to read since I always have to scroll up to the definition of abbreviation to understand, what is actually called.
I definitely would go for removing all these abbreviations and using the fully qualified names. I know that writing code this way may take a little longer, but I think it is worth the time. And most of the editors provide automatic source completion, that speeds up the typing.
What do you think about this?v1.2https://gitlab.idiap.ch/bob/bob.learn.em/-/issues/17Segmentation fault when importing bob.learn.em2017-08-12T07:46:06ZAndré AnjosSegmentation fault when importing bob.learn.em*Created by: 183amir*
Backtrace:
```
gdb -ex r --args /opt/conda/envs/_test/bin/python -c "import bob.learn.em"
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: G...*Created by: 183amir*
Backtrace:
```
gdb -ex r --args /opt/conda/envs/_test/bin/python -c "import bob.learn.em"
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/conda/envs/_test/bin/python...done.
Starting program: /opt/conda/envs/_test/bin/python -c import\ bob.learn.em
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 73.
Missing separate debuginfo for /opt/conda/envs/_test/lib/python2.7/site-packages/numpy/core/../../../.././libgfortran.so.3
[New Thread 0x7ffff0176700 (LWP 75)]
[New Thread 0x7fffef975700 (LWP 76)]
[New Thread 0x7fffed174700 (LWP 77)]
warning: Source file is more recent than executable.
Program received signal SIGSEGV, Segmentation fault.
bob::extension::FunctionDoc::doc(unsigned int, unsigned int) const () at /opt/conda/envs/_build/lib/python2.7/site-packages/bob/extension/include/bob.extension/documentation.h:580
580 if (description.empty()){
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.166.el6_7.7.x86_64
(gdb) bt
#0 bob::extension::FunctionDoc::doc(unsigned int, unsigned int) const () at /opt/conda/envs/_build/lib/python2.7/site-packages/bob/extension/include/bob.extension/documentation.h:580
#1 0x00007fffe441477b in _GLOBAL__sub_I_main.cpp () at bob/learn/em/main.cpp:18
#2 0x00007fffe4414826 in __do_global_ctors_aux () from /opt/conda/envs/_test/lib/python2.7/site-packages/bob/learn/em/_library.so
#3 0x00007fffe4391d03 in _init () from /opt/conda/envs/_test/lib/python2.7/site-packages/bob/learn/em/_library.so
#4 0x00007fff00000000 in ?? ()
#5 0x00007ffff7deb625 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7defe95 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#7 0x00007ffff7deb286 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff7def63a in _dl_open () from /lib64/ld-linux-x86-64.so.2
#9 0x00007ffff75d5f66 in dlopen_doit () from /lib64/libdl.so.2
#10 0x00007ffff7deb286 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff75d629c in _dlerror_run () from /lib64/libdl.so.2
#12 0x00007ffff75d5ee1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#13 0x00007ffff7b25dde in _PyImport_GetDynLoadFunc (fqname=<value optimized out>, shortname=<value optimized out>, pathname=0xd34c60 "/opt/conda/envs/_test/lib/python2.7/site-packages/bob/learn/em/_library.so", fp=0xd39730) at Python/dynload_shlib.c:130
#14 0x00007ffff7b0a8d8 in _PyImport_LoadDynamicModule (name=0xcf9fb0 "bob.learn.em._library", pathname=0xd34c60 "/opt/conda/envs/_test/lib/python2.7/site-packages/bob/learn/em/_library.so", fp=0xd39730) at ./Python/importdl.c:42
#15 0x00007ffff7b08f81 in import_submodule (mod=0x7ffff7eaada8, subname=0xcf9fbd "_library", fullname=0xcf9fb0 "bob.learn.em._library") at Python/import.c:2704
#16 0x00007ffff7b091f4 in load_next (mod=0x7ffff7eaada8, altmod=0x7ffff7eaada8, p_name=<value optimized out>, buf=0xcf9fb0 "bob.learn.em._library", p_buflen=0x7fffffffe120) at Python/import.c:2519
#17 0x00007ffff7b09820 in import_module_level (name=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>, fromlist=0x7ffff7ef69d0, level=<value optimized out>) at Python/import.c:2228
#18 PyImport_ImportModuleLevel (name=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>, fromlist=0x7ffff7ef69d0, level=<value optimized out>) at Python/import.c:2292
#19 0x00007ffff7ae914f in builtin___import__ (self=<value optimized out>, args=<value optimized out>, kwds=<value optimized out>) at Python/bltinmodule.c:49
#20 0x00007ffff7a3fd23 in PyObject_Call (func=0x7ffff7fdffc8, arg=<value optimized out>, kw=<value optimized out>) at Objects/abstract.c:2546
#21 0x00007ffff7ae9633 in PyEval_CallObjectWithKeywords (func=0x7ffff7fdffc8, arg=0x7ffff7e935f0, kw=<value optimized out>) at Python/ceval.c:4219
#22 0x00007ffff7aee29e in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2622
#23 0x00007ffff7af3a2e in PyEval_EvalCodeEx (co=0x7ffff7eb08b0, globals=<value optimized out>, locals=<value optimized out>, args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3582
#24 0x00007ffff7af3b42 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>) at Python/ceval.c:669
#25 0x00007ffff7b05a82 in PyImport_ExecCodeModuleEx (name=0x6b61b0 "bob.learn.em", co=0x7ffff7eb08b0, pathname=0x6b91e0 "/opt/conda/envs/_test/lib/python2.7/site-packages/bob/learn/em/__init__.pyc") at Python/import.c:713
#26 0x00007ffff7b081ce in load_source_module (name=0x6b61b0 "bob.learn.em", pathname=0x6b91e0 "/opt/conda/envs/_test/lib/python2.7/site-packages/bob/learn/em/__init__.pyc", fp=<value optimized out>) at Python/import.c:1103
#27 0x00007ffff7b08a2a in load_package (name=0x6b61b0 "bob.learn.em", pathname=<value optimized out>) at Python/import.c:1170
#28 0x00007ffff7b08f81 in import_submodule (mod=0x7ffff7eaad38, subname=0x6b61ba "em", fullname=0x6b61b0 "bob.learn.em") at Python/import.c:2704
#29 0x00007ffff7b091f4 in load_next (mod=0x7ffff7eaad38, altmod=0x7ffff7eaad38, p_name=<value optimized out>, buf=0x6b61b0 "bob.learn.em", p_buflen=0x7fffffffe710) at Python/import.c:2519
#30 0x00007ffff7b09860 in import_module_level (name=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>, fromlist=0x7ffff7da6cd0, level=<value optimized out>) at Python/import.c:2236
#31 PyImport_ImportModuleLevel (name=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>, fromlist=0x7ffff7da6cd0, level=<value optimized out>) at Python/import.c:2292
#32 0x00007ffff7ae914f in builtin___import__ (self=<value optimized out>, args=<value optimized out>, kwds=<value optimized out>) at Python/bltinmodule.c:49
#33 0x00007ffff7a3fd23 in PyObject_Call (func=0x7ffff7fdffc8, arg=<value optimized out>, kw=<value optimized out>) at Objects/abstract.c:2546
#34 0x00007ffff7ae9633 in PyEval_CallObjectWithKeywords (func=0x7ffff7fdffc8, arg=0x7ffff7ed15d0, kw=<value optimized out>) at Python/ceval.c:4219
#35 0x00007ffff7aee29e in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2622
#36 0x00007ffff7af3a2e in PyEval_EvalCodeEx (co=0x7ffff7edde30, globals=<value optimized out>, locals=<value optimized out>, args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3582
#37 0x00007ffff7af3b42 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>) at Python/ceval.c:669
#38 0x00007ffff7b125cc in run_mod (str=0x601010 "import bob.learn.em\n", start=257, globals=0x7ffff7f81168, locals=0x7ffff7f81168, flags=<value optimized out>) at Python/pythonrun.c:1370
#39 PyRun_StringFlags (str=0x601010 "import bob.learn.em\n", start=257, globals=0x7ffff7f81168, locals=0x7ffff7f81168, flags=<value optimized out>) at Python/pythonrun.c:1333
#40 0x00007ffff7b138f0 in PyRun_SimpleStringFlags (command=0x601010 "import bob.learn.em\n", flags=0x7fffffffebc0) at Python/pythonrun.c:974
#41 0x00007ffff7b29457 in Py_Main (argc=<value optimized out>, argv=<value optimized out>) at Modules/main.c:589
#42 0x00007ffff6dd8d5d in __libc_start_main () from /lib64/libc.so.6
#43 0x0000000000400649 in _start ()
```
conda-forge pull request:
https://github.com/conda-forge/staged-recipes/pull/4092.0.9