Shogun Integration

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Begin forwarded message:

From: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Date: 2010 December 10 04:19:14 GMT+01:00
To: Balázs Kégl <balazs.kegl@…>
Cc: Djalel Benbouzid <djalel.benbouzid@…>, Robert Busa-Fekete <busarobi@…>
Subject: Re: email

On Thu, 2010-12-09 at 20:46 +0100, Balázs Kégl wrote:
Soeren,

Here are the mails of people working on MultiBoost.

just a quick heads up:

I've spent the last hours getting multiboost (based on the .zip from the
website) to compile within the shogun hierarchy under
libshogun/classifier/boosting/.

Things work now, i.e. shogun still compiles including MB. However, I had
to change a couple of things. For examples SigmoidSingleStumpLearner
does in fact define DirechletSingleStumpLearner - so things were
breaking. In other classes, for some cases the base class' function
definition was float and you were using double in the derived classes
etc...

Anyway. To continue e.g. to get the python interface to work with MB I
need your help and I guess we also have to move MultiBoost in the
shogun namespace hierarchy so we need to decide about a couple of
things.

In general I would suggest we just keep MB as it is for now and only do
the interfacing (for now). Then we step by step merge file i/o / base
learners etc...

Gruss,
Soeren (off to the hot-tub...)
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Date: 2010 December 11 07:33:34 GMT+01:00
To: Balázs Kégl <balazs.kegl@…>
Subject: Merging SG & MB

Hi Balazs,

I am sending what I've written down. I think the first step should be
that a) your cmdline tool still works and b) that we get the
python_modular interfaces to work with MB.

1. to compile: include path prefix classifier/boosting/
2. to get swig-based (octave_modular,r_modular,python_modular):
   • derive objects from CSGObject (and implement get_name() function)
   • Foo* get_whatever() {

SG_REF(foo);
return foo;

}

• set_whatever(Foo* foo)

{

SG_REF(foo);
_foo = foo;

}

• in modular/Classifier.i include the .h file

3. introduce get/set functions for parameters of e.g. weaklearners
4. To get your cmdline interface to work, link main against libshogun

via g++ main.cpp -o mb -lshogun

I've did an experimental merge with MB here (read-only access)

svn co ​http://svn.tuebingen.mpg.de:/shogun/trunk

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Date: 2010 December 11 14:40:58 GMT+01:00
To: Balázs Kégl <balazs.kegl@…>
Subject: multiboost shogun merge again...

Hi Balazs,

I used my jetlag time to get main.cpp to compile with libshogun now and
have some AdaboostMH stronglearner now wrapped in python.

It really was not difficult:

1. I changed namespace MultiBoost to namespace shogun
2. I made the remaining includes relative to classifier/boosting
3. I derived AdaboostMH, Genericlearner and the Args class from

CSGObject and implemented a get_name() function.

4. I included your headerfiles in modular/Classifier.i

So it works in principle and there is good hope that you / your team can
do the further changes to get the other things to work.

Lets meet and discuss today. Maybe we can come up with some minimal
example and a long-term plan...

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Date: 2010 December 13 00:18:23 GMT+01:00
To: Balázs Kégl <balazs.kegl@…>, Djalel Benbouzid <djalel.benbouzid@…>, Robert Busa-Fekete <busarobi@…>
Subject: Question regarding REGISTER_LEARNER ...

and REGISTER_LEARNER_NAME.

Hi all,

(Apologies, I didn't know whom of you to contact)

These macros create some static variable of the objects. The problem is
that within shogun we cannot have static objects that are derived from
CSGObject (the shogun base class). That is a problem.since we have to
derive your objects from CSGObject for them to work for the other
interfaces.

So my question is, what do you need these REGISTER_LEARNER functions
for? Can we somehow convert the static variables into pointers?

The code is here...

​http://svn.tuebingen.mpg.de:/shogun/trunk/src

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Robert Busa-Fekete <busarobi@…>
Date: 2010 December 13 09:40:48 GMT+01:00
To: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Cc: Balázs Kégl <balazs.kegl@…>, Djalel Benbouzid <djalel.benbouzid@…>
Subject: Re: Question regarding REGISTER_LEARNER ...

Hi all,

unfortunately the REGISTER_LEARNER is an important ingredient of MB. One instance from all of the base learners which are available in the package is stored in a map in which the key is the name of the base learner and the value member is an instance of the base learner. The REGISTER_LEARNER macro does this at beginning of the run by using static functions. And when we need an instance from a base learner, we just create a copy using this map. In this way we can easily keep track the available base learner classes. (In java this would be easier because there is a base class for all classes and it does this auto registering process automatically. )

We can get rid of the static member variable but we would need static functions. Is it allowed to use static functions?

Cheers,
Robi

On Dec 13, 2010, at 12:18 AM, Soeren Sonnenburg wrote:

and REGISTER_LEARNER_NAME.

Hi all,

(Apologies, I didn't know whom of you to contact)

These macros create some static variable of the objects. The problem is
that within shogun we cannot have static objects that are derived from
CSGObject (the shogun base class). That is a problem.since we have to
derive your objects from CSGObject for them to work for the other
interfaces.

So my question is, what do you need these REGISTER_LEARNER functions
for? Can we somehow convert the static variables into pointers?

The code is here...

​http://svn.tuebingen.mpg.de:/shogun/trunk/src

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Robert Busa-Fekete <busarobi@…>
Date: 2010 December 13 09:40:48 GMT+01:00
To: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Cc: Balázs Kégl <balazs.kegl@…>, Djalel Benbouzid <djalel.benbouzid@…>
Subject: Re: Question regarding REGISTER_LEARNER ...

Hi all,

unfortunately the REGISTER_LEARNER is an important ingredient of MB. One instance from all of the base learners which are available in the package is stored in a map in which the key is the name of the base learner and the value member is an instance of the base learner. The REGISTER_LEARNER macro does this at beginning of the run by using static functions. And when we need an instance from a base learner, we just create a copy using this map. In this way we can easily keep track the available base learner classes. (In java this would be easier because there is a base class for all classes and it does this auto registering process automatically. )

We can get rid of the static member variable but we would need static functions. Is it allowed to use static functions?

Cheers,
Robi

On Dec 13, 2010, at 12:18 AM, Soeren Sonnenburg wrote:

and REGISTER_LEARNER_NAME.

Hi all,

(Apologies, I didn't know whom of you to contact)

These macros create some static variable of the objects. The problem is
that within shogun we cannot have static objects that are derived from
CSGObject (the shogun base class). That is a problem.since we have to
derive your objects from CSGObject for them to work for the other
interfaces.

So my question is, what do you need these REGISTER_LEARNER functions
for? Can we somehow convert the static variables into pointers?

The code is here...

​http://svn.tuebingen.mpg.de:/shogun/trunk/src

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Date: 2010 December 13 11:38:29 GMT+01:00
To: Robert Busa-Fekete <busarobi@…>
Cc: Balázs Kégl <balazs.kegl@…>,Djalel Benbouzid <djalel.benbouzid@…>
Subject: Re: Question regarding REGISTER_LEARNER ...

Yes sure static functions are fine. Just not static objects derived from Csgobject.

We might have a similar mechanism but I would first not want to make too intrusive changes in mb.

"Robert Busa-Fekete" <busarobi@…> wrote:

Hi all,

unfortunately the REGISTER_LEARNER is an important ingredient of MB.
One instance from all of the base learners which are available in the
package is stored in a map in which the key is the name of the base
learner and the value member is an instance of the base learner. The
REGISTER_LEARNER macro does this at beginning of the run by using
static functions. And when we need an instance from a base learner, we
just create a copy using this map. In this way we can easily keep track
the available base learner classes. (In java this would be easier
because there is a base class for all classes and it does this auto
registering process automatically. )

We can get rid of the static member variable but we would need static
functions. Is it allowed to use static functions?

Cheers,
Robi

On Dec 13, 2010, at 12:18 AM, Soeren Sonnenburg wrote:

and REGISTER_LEARNER_NAME.

Hi all,

(Apologies, I didn't know whom of you to contact)

These macros create some static variable of the objects. The problem
is
that within shogun we cannot have static objects that are derived
from
CSGObject (the shogun base class). That is a problem.since we have to
derive your objects from CSGObject for them to work for the other
interfaces.

So my question is, what do you need these REGISTER_LEARNER functions
for? Can we somehow convert the static variables into pointers?

The code is here...

​http://svn.tuebingen.mpg.de:/shogun/trunk/src

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Date: 2010 December 14 08:40:32 GMT+01:00
To: Robert Busa-Fekete <busarobi@…>
Cc: Balázs Kégl <balazs.kegl@…>, Djalel Benbouzid <djalel.benbouzid@…>
Subject: Re: Question regarding REGISTER_LEARNER ...

Hi Robi,

my suggestion would be that you svn checkout shogun, try to get it to
compile and then there within libshogun/classifier/boosting (the
location of multiboost) try to get rid of this particular static
variable and then send me a patch (until you have full svn r/w access).

BTW, did Andre already sent you the forms?

Best,
Soeren

On Mon, 2010-12-13 at 09:40 +0100, Robert Busa-Fekete wrote:
Hi all,

unfortunately the REGISTER_LEARNER is an important ingredient of MB.
One instance from all of the base learners which are available in the
package is stored in a map in which the key is the name of the base
learner and the value member is an instance of the base learner. The
REGISTER_LEARNER macro does this at beginning of the run by using
static functions. And when we need an instance from a base learner, we
just create a copy using this map. In this way we can easily keep
track the available base learner classes. (In java this would be
easier because there is a base class for all classes and it does this
auto registering process automatically. )

We can get rid of the static member variable but we would need static
functions. Is it allowed to use static functions?

Cheers,
Robi

On Dec 13, 2010, at 12:18 AM, Soeren Sonnenburg wrote:

and REGISTER_LEARNER_NAME.

Hi all,

(Apologies, I didn't know whom of you to contact)

These macros create some static variable of the objects. The problem is
that within shogun we cannot have static objects that are derived from
CSGObject (the shogun base class). That is a problem.since we have to
derive your objects from CSGObject for them to work for the other
interfaces.

So my question is, what do you need these REGISTER_LEARNER functions
for? Can we somehow convert the static variables into pointers?

The code is here...

​http://svn.tuebingen.mpg.de:/shogun/trunk/src

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Balázs Kégl <balazs.kegl@…>
Date: 2010 December 14 09:47:15 GMT+01:00
To: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Cc: Balázs Kégl <balazs.kegl@…>, Robert Busa-Fekete <busarobi@…>, Djalel Benbouzid <djalel.benbouzid@…>
Subject: Re: Question regarding REGISTER_LEARNER ...

Soeren,

Hi Robi,

my suggestion would be that you svn checkout shogun, try to get it to
compile and then there within libshogun/classifier/boosting (the
location of multiboost) try to get rid of this particular static
variable and then send me a patch (until you have full svn r/w access).

The problem is that this cannot be changed with a patch, eliminating statics means that we eliminate the class register which is an integral part of multiboost. I think this is just the top of the iceberg, there will be other problems, so I’m leaning towards factoring out reusable algorithms from multiboost but reimplementing the actual learners using shogun philosophy. This means two versions of boosting. We are thinking about adding a limited set: the strong learner, stumps, trees, products, maybe sparse stumps since shogun is used a lot with sparse data. Then we’ll have a message any time boosting is called that there is a more up-to-date but separate version at multiboost.org.

Balázs

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

From: Soeren Sonnenburg <Soeren.Sonnenburg@…>
Date: 2010 December 14 12:25:17 GMT+01:00
To: Balázs Kégl <balazs.kegl@…>
Cc: Robert Busa-Fekete <busarobi@…>, Djalel Benbouzid <djalel.benbouzid@…>
Subject: Re: Question regarding REGISTER_LEARNER ...

On Tue, 2010-12-14 at 09:47 +0100, Balázs Kégl wrote:
Soeren,

Hi Balazs,

Hi Robi,

my suggestion would be that you svn checkout shogun, try to get it to
compile and then there within libshogun/classifier/boosting (the
location of multiboost) try to get rid of this particular static
variable and then send me a patch (until you have full svn r/w access).

The problem is that this cannot be changed with a patch, eliminating
statics means that we eliminate the class register which is an
integral part of multiboost.

I think one could create a global variable via which you can do your
registration just fine. Before libshogun (so any of shogun/multiboost)
is called, one may assume that the function init_shogun() got called
(sitting in base/init.cpp ; exit_shogun() when no longer using it) - so
if you need some other initialization just do it there...

But maybe I don't fully understand what you are trying to do here.

I think this is just the top of the iceberg, there will be other
problems, so I’m leaning towards factoring out reusable algorithms
from multiboost but reimplementing the actual learners using shogun
philosophy. This means two versions of boosting. We are thinking about
adding a limited set: the strong learner, stumps, trees, products,
maybe sparse stumps since shogun is used a lot with sparse data. Then
we’ll have a message any time boosting is called that there is a more
up-to-date but separate version at multiboost.org.

Of course we could do that. However, I would not want to give up just
now. In particular because I think it will be more work to do what you
proposed, i.e. continue/merge two projects on the long run.

Please give it a try....

Gruss,
Soeren
--
Soeren Sonnenburg - ML Group, TU-Berlin Tel: +49 (0)30 314 78630
Franklinstr. 28/29, 10587 Berlin, Germany Fax: +49 (0)30 314 78622

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Hello,

Soeren, I'm adding you to the current trac ticket recipients about this issue, please respond directly on the trac interface.
I understand the need to get rid of static variable and the REGISTER_LEARNER_NAME macros. The problem we have there is that multiboost uses a class register mechanism to map baselearner string names specified from the command line to actual classes. I've triple checked this : this only could be done with a singleton factory pattern and there is absolutely no way to implement that without ONE private static variable. Does shogun already have a class register mechanism ? It seems you mentioned it. Otherwise we'll have to resort to hardcoding a big main switch over all baselearners class names.

Regards,
François-David

[Soeren.Sonnenburg@…]

Hi François-David,

indeed we have something similar in shogun to enable serialization of any class (including templated classes) derived from CSGObject: It is based on shell script magic though. See libshogun/base/class_list.cpp.sh, libshogun/base/class_list.cpp.templ and the generated libshogun/base/class_list.cpp.

What it does is extracting all (non-abstract) classes prefixed with 'C' from the header files and then create an array of class name and a pointer to create a new class, e.g. (slighlty simplified)

  static CSGObject* __new_CSVM() { return new CSVM()}

  static class_list_entry_t class_list[] = {
  {m_class_name: "SVM", m_new_sgserializable: __new_CSVM}
  { ... }
  }

On top of it sits a function

CSGObject* new_sgserializable(const char* sgserializable_name,
                                            EPrimitiveType generic);

(ignore the EPrimititveType that we need for templated classes)

So it is more or less like a automagically created switch / case thing... No idea if this could be considered 'elegant' though. Anyway, I think we could agree on one mechanism.

The reason why your private static variables are problematic (currently) is only this one:

In shogun we put all the machine learning related classes / functions into the library libshogun. Now anyone could use this library from C++ or from other languages (we have static language wrappers in libshogunui and modular much better object oriented ones using swig). So for each of these languages we call init_shogun() to initialize some global objects within shogun, like for example, io functions (e.g. printf) that simply use the one native to the interface etc. We currently assume that no object derived from CSGObject is created prior to a call to init_shogun. So the printf function pointer would be NULL and if some static class is initialized whose constructor calls some class derived from CSGObject (that potentially prints something) we would see crashes.

Since you do new SomeLearner() in the REGISTER_ macros this is exactly the case. So if you
would just register a function e.g.

 static BaseLearner* __new_SomeLearner() { return new SomeLearner() }

instead of directly calling new SomeLearner() in the REGISTER_LEARNER* macros
problems should be solved. Alternatively, we have to figure out if it is possible to not do anything in the default constructors of all the shogun classes or you could switch to our class registration scheme.

Let me know what you thing and what you would prefer.

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Hello Soeren,

Thanks for your answer, I'll look into it.

Regards,
--
François-David

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Hi Soeren,

Will it be a problem if we replace the REGISTER_LEARNER macros with a static realloc of the class_list array and fill it with the multiboost class mappings ?

Regards,
--
François-David

[anonymous]

Hi Francois,

that would be great. If you have an idea how I could modify the

static class_list_entry_t class_list[] = { ... }

to allow for dynamic registration of classes - I would be happy to convert to using that system too!

Best,
Soeren

[Soeren.Sonnenburg@…]

BTW, do what ever changes are needed directly in the shogun svn. Policy is that what is in there should compile but may otherwise be broken.

Soeren

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Hi Soeren,

I'm currently experiencing segfault while executing multiboost code in shogun. I see that shogun is firing some threads, but multiboost code isn't threadsafe. For the moment I can't figure why it is crashing, do you have an idea ?

I attach the diff for libshogun/classifier/boosting directory and the main.cpp I compile with :

g++ -fPIC -ggdb main.cpp -o mb -L/scratch/fradav/local/lib -I/scratch/fradav/local/include -lshogun

I run with :

mb --fileformat arff --traintest pendigitsTrain.arff pendigitsTest.arff 100 --verbose 3 --learnertype SingleStumpLearner --outputinfo resultsSingleStump.dta --shypname shypSingleStump.xml

where the .arff files are the one in the pendigits example files at ​http://www.multiboost.org/example/pendigits.zip?attredirects=0&d=1

It is crashing at BaseLearner::subCreate

Regards,
--
François-David

[Soeren.Sonnenburg@…]

The problem is simply that I commented out the

static Register_##X r_##X;

in lines 573 and 583 of ./libshogun/classifier/boosting/WeakLearners/BaseLearner.h

However, now you get the original symptom, which is

call init_shogun() before using the library, dying.

that is caused by the statically initialized classes.

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

I don't understand : even with the static Register lines commented out, there is still statically initialized classes ?
I'm using a simple class wrapper starting with a C in order to be detected and activated in the class_list.cpp file, and it is exactly the recommended procedure for shogun, right ? The subCreate method doesn't use any static variables, as far as I know, so why it is segfaulting ?

[Soeren.Sonnenburg@…]

No. Only when the static Register_##X r_##X; are in the code there are statically initialized classes causing problems.

Regarding the C prefixed class yes.

For the crash - I would recommend to have a look at the valgrind output. It is accessing unitialized memory. I suspect this is a result because of the static variables missing.

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Valgrind output isn't that much helpful :

Total: 3498 examples read.
==23540== Invalid read of size 8
==23540==    at 0x500A327: shogun::AdaBoostMHLearner::run(nor_utils::Args const&) (BaseLearner.h:243)
==23540==    by 0x409671: main (main.cpp:507)
==23540==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23540== 
==23540== 
==23540== Process terminating with default action of signal 11 (SIGSEGV)
==23540==  Access not within mapped region at address 0x0
==23540==    at 0x500A327: shogun::AdaBoostMHLearner::run(nor_utils::Args const&) (BaseLearner.h:243)
==23540==    by 0x409671: main (main.cpp:507)
==23540==  If you believe this happened as a result of a stack
==23540==  overflow in your program's main thread (unlikely but
==23540==  possible), you can try to increase the size of the
==23540==  main thread stack using the --main-stacksize= flag.
==23540==  The main thread stack size used in this run was 10485760.
==23540== 
==23540== HEAP SUMMARY:
==23540==     in use at exit: 5,952,605 bytes in 55,554 blocks
==23540==   total heap usage: 123,693 allocs, 68,139 frees, 7,265,073 bytes allocated
==23540== 
==23540== LEAK SUMMARY:
==23540==    definitely lost: 812 bytes in 9 blocks
==23540==    indirectly lost: 4,242,686 bytes in 37,590 blocks
==23540==      possibly lost: 12,531 bytes in 259 blocks
==23540==    still reachable: 1,696,576 bytes in 17,696 blocks
==23540==         suppressed: 0 bytes in 0 blocks
==23540== Rerun with --leak-check=full to see details of leaked memory
==23540== 
==23540== For counts of detected and suppressed errors, rerun with: -v
==23540== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
Segmentation fault

As you could see in the diff file I just overloaded the subCreate in the CSingleStumpLearner to explicitly return a new instance of the CSingleStumpLearner type.
What is wrong there ?

[Soeren.Sonnenburg@…]

Could we somehow chat, e.g. via jabber or skype? It is easier to resolve this way.

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Hi Soeren,

Of course we can do that. I'm a unavailable this afternoon but this evening between 10/12 pm or tomorrow as you want.
Jabber/gtalk : fradav@…
Skype : maisnan (nickname)

[/C=FR/O=CNRS/OU=UMR8607/CN=Francois-David Collin/emailAddress=Francois-David.Collin@…]

Seen with Soeren this afternoon : the crash was due to a missing initialization of ConstantLearner instance, itself related to a problem with an old version of the gnu sed binary used on my platform.
See the milestone description for the problem, it will probably takes some times before we come with a clean script for parsing includes and macro-integration of CSObject wrapper classes.

[Soeren.Sonnenburg@…]

I've rewritten the class_list.cpp.sh in python. Now ConstantLearner appears in the class list. Feel free to jabber me if you still see problems (but make sure to make distclean ; svn update; run configure first).