ObjectHandler, QuantLibAddin, and QuEPs

[Ferdinando M. Ametrano-3]

Hi Eric,

[I'm CCing QuantLib-dev and Jody Goldberg]

I've imported ObjectHandler as a separate module in the CVS. In order to
reflect this change we could split the QuEP you've submitted into two
separate QuEPs, one dedicated to ObjectHandler and the other to the rest.

I've added Borland, VC7, and Dev-C++MinGW support and/or project files for
ObjectHandler. I've added the copyright notice (please confirm that I've
spelled your name right) plus a couple of minor files and fixes.

It look like your ObjectHandler prototype is almost ready for a first
release. I might have introduced some problems with the *nix Makefile, but
you can check it out and fix them. Hopefully we could autoconf the project
before the release, add some Doxygen documentation, and I would provide a
Win32 installer.

As for the rest: I've renamed your ObjectClassLibrary as QuantLibAddin. The
CVS QuantLibAddin module includes the QuantLibAddin library plus all the
Addins and Clients (C++, Calc, and Excel). I've added Borland, VC7, and
Dev-C++MinGW (partial) support and/or project files, (some) copyright
notice, and some minor files and fixes. The code is updated to work with
the forthcoming 0.3.8 release and the current CVS trunk.
Once again I might have introduced some problems with the *nix Makefiles:
please check them.

I've already granted you write access to the CVS, so please use the CVS
code base for any further development. When we'll publish the QuEPs we will
be referring to QuantLib 0.3.8, and the latest version of your code will be
available in the CVS for public inspections.

BTW I'm going to add [hidden email] to the QuantLib-dev mailing list.
Is it ok for you? Would you prefer a different address?
How are you managing the QuantLib-cvs traffic ? ;-)

Jody: thank you for any help you can provide for Gnumeric. Are you
interested in joining the QuantLib-dev mailing list? Do you plan to
personally contribute to the Gnumeric version of the QuantLibAddin?

>What do you think about the autogeneration of code described under
>"Notes"?  Jody and I agree that autogeneration is the way forward, if
>you agree I'll do a design doc for that.
I do agree that autogeneration is the way forward. I'm not sure
Python+config_file is the best approach, but I'm not an expert. What about
IDL definition and IDL compilers?

thank you very much for your contribution

ciao -- Nando


Eric wrote:

>I've revised the design doc, and the URL has changed:
>
>http://www.ehlers.plus.com/quantlib/quep011.html
>
>Here are the html and other files:
>http://www.ehlers.plus.com/quantlib/quep011.zip
>http://www.ehlers.plus.com/quantlib/quep011.tar.gz
>
>Please let me know if any revisions are needed.  You're welcome to edit
>the doc directly if that's easier for you.
>
>Here's the code:
>http://www.ehlers.plus.com/quantlib/ObjectHandler.zip
>http://www.ehlers.plus.com/quantlib/ObjectHandler.tar.gz
>
>I'm new to QuantLib and Boost and I'm sure the code has much room for
>improvement - all feedback is welcome.
>
>Regards
>Eric

[erik-44]

Hi Nando, Hi All

Just a quick message as I'm running to catch a train.  In general I
agree with all of your points and I'll send more specific comments on
Monday, as well as a split QuEP11(/12?) and a draft design for the
automatic generation of code - I'll look at IDL.

Many thanks for your help, speak to you soon.

Regards
Eric


On Wed, 2004-10-27 at 17:18, Ferdinando Ametrano wrote:

> Hi Eric,
>
> [I'm CCing QuantLib-dev and Jody Goldberg]
>
> I've imported ObjectHandler as a separate module in the CVS. In order to
> reflect this change we could split the QuEP you've submitted into two
> separate QuEPs, one dedicated to ObjectHandler and the other to the rest.
>
> I've added Borland, VC7, and Dev-C++MinGW support and/or project files for
> ObjectHandler. I've added the copyright notice (please confirm that I've
> spelled your name right) plus a couple of minor files and fixes.
>
> It look like your ObjectHandler prototype is almost ready for a first
> release. I might have introduced some problems with the *nix Makefile, but
> you can check it out and fix them. Hopefully we could autoconf the project
> before the release, add some Doxygen documentation, and I would provide a
> Win32 installer.
>
> As for the rest: I've renamed your ObjectClassLibrary as QuantLibAddin. The
> CVS QuantLibAddin module includes the QuantLibAddin library plus all the
> Addins and Clients (C++, Calc, and Excel). I've added Borland, VC7, and
> Dev-C++MinGW (partial) support and/or project files, (some) copyright
> notice, and some minor files and fixes. The code is updated to work with
> the forthcoming 0.3.8 release and the current CVS trunk.
> Once again I might have introduced some problems with the *nix Makefiles:
> please check them.
>
> I've already granted you write access to the CVS, so please use the CVS
> code base for any further development. When we'll publish the QuEPs we will
> be referring to QuantLib 0.3.8, and the latest version of your code will be
> available in the CVS for public inspections.
>
> BTW I'm going to add [hidden email] to the QuantLib-dev mailing list.
> Is it ok for you? Would you prefer a different address?
> How are you managing the QuantLib-cvs traffic ? ;-)
>
> Jody: thank you for any help you can provide for Gnumeric. Are you
> interested in joining the QuantLib-dev mailing list? Do you plan to
> personally contribute to the Gnumeric version of the QuantLibAddin?
>
> >What do you think about the autogeneration of code described under
> >"Notes"?  Jody and I agree that autogeneration is the way forward, if
> >you agree I'll do a design doc for that.
> I do agree that autogeneration is the way forward. I'm not sure
> Python+config_file is the best approach, but I'm not an expert. What about
> IDL definition and IDL compilers?
>
> thank you very much for your contribution
>
> ciao -- Nando
>
>
> Eric wrote:
> >I've revised the design doc, and the URL has changed:
> >
> >http://www.ehlers.plus.com/quantlib/quep011.html
> >
> >Here are the html and other files:
> >http://www.ehlers.plus.com/quantlib/quep011.zip
> >http://www.ehlers.plus.com/quantlib/quep011.tar.gz
> >
> >Please let me know if any revisions are needed.  You're welcome to edit
> >the doc directly if that's easier for you.
> >
> >Here's the code:
> >http://www.ehlers.plus.com/quantlib/ObjectHandler.zip
> >http://www.ehlers.plus.com/quantlib/ObjectHandler.tar.gz
> >
> >I'm new to QuantLib and Boost and I'm sure the code has much room for
> >improvement - all feedback is welcome.
> >
> >Regards
> >Eric

[Jody Goldberg-2]

On Wed, Oct 27, 2004 at 06:18:49PM +0200, Ferdinando Ametrano wrote:
>
> Are you > interested in joining the QuantLib-dev mailing list?
I'm definitely already on some of the quantlib lists, possibly not
that one please add me.

> Do you plan to personally contribute to the Gnumeric version of
> the QuantLibAddin?
yes.  Gnumeric already has a significant set of financial analytics,
and I'd like to see that expanded to use quantlib.
 
> >What do you think about the autogeneration of code described under
> >"Notes"?  Jody and I agree that autogeneration is the way forward, if
> >you agree I'll do a design doc for that.
> I do agree that autogeneration is the way forward. I'm not sure
> Python+config_file is the best approach, but I'm not an expert. What about
> IDL definition and IDL compilers?

IDL is a non-starter.  It is nowhere near reach enough to supply the
amount of documentation and detail to generate the code I'd like to
see.  A config_file and some sort of script, possibly in python
seems like a reasonable approach.  I've seen it used successfully in
things like pygtk and gtk#.  By defining the api using a format we
control it's possible to get all the relevent information.
Something as simple as an xml based format would be fine.  The goal
is to provide things like
    - name
    - short func description
    - per argument name, description, type
    - Return type
    - long func description (algorithm, model, possible a url to
      more docs)
    - implementation status
    - testing status
    - version info (eg first created in QL v?)
    - Related functions
    - Possibly a ChangeLog ?
    - Translations ?
    - Keywords/Categories to classify function
    - Samples/Examples
    - Related functions

With that type of information a spreadsheet can provide a decent
interface for selecting a routine.  Gnumeric has on the order of
500+ functions right now.  That's everything in north american MS
Excel and 150 or extra.  Navigating through that is cumbersome.

[Ferdinando M. Ametrano-3]

Hi all

Jody Goldberg wrote:
>I'm definitely already on some of the quantlib lists, possibly not
>that one please add me.
I've added you and Eric to quantlib-dev

>Gnumeric already has a significant set of financial analytics,
>and I'd like to see that expanded to use quantlib.
this is great news.

>IDL is a non-starter.  It is nowhere near reach enough to supply the
>amount of documentation and detail to generate the code I'd like to
>see.  A config_file and some sort of script, possibly in python
>seems like a reasonable approach.  I've seen it used successfully in
>things like pygtk and gtk#.
I definitively trust you on such an issue.

>   By defining the api using a format we
>control it's possible to get all the relevent information.
>Something as simple as an xml based format would be fine.  The goal
>is to provide things like
>     - name
>     - short func description
>     - per argument name, description, type
>     - Return type
>     - long func description (algorithm, model, possible a url to
>       more docs)
>     - implementation status
>     - testing status
>     - version info (eg first created in QL v?)
>     - Related functions
>     - Possibly a ChangeLog ?
>     - Translations ?
>     - Keywords/Categories to classify function
>     - Samples/Examples
>     - Related functions

I agree with everything but translations. Not that we have to forbid them,
but imho the financial community doesn't really need them.

Eric wrote:
>I'll send more specific comments on Monday,
>as well as a split QuEP11(/12?) and a draft
>design for the automatic generation of code
I look forward to it.

ciao -- Nando

[erik-44]

> I've imported ObjectHandler as a separate module in the CVS. In order to
> reflect this change we could split the QuEP you've submitted into two
> separate QuEPs, one dedicated to ObjectHandler and the other to the rest.

Here are the revised docs:
http://www.ehlers.plus.com/quantlib/quep011.html
http://www.ehlers.plus.com/quantlib/quep012.html

The latter proposes an approach for automatic generation of source
code.  The doc needs further revision but should be enough to get our
discussion started.

> I've added Borland, VC7, and Dev-C++MinGW support and/or project files for
> ObjectHandler. I've added the copyright notice (please confirm that I've
> spelled your name right) plus a couple of minor files and fixes.

Great, and yes you got my name right.  Unfortunately as I don't have
Borland and VC7 I'll break these every time I add files etc., maybe it
will be easier for you to leave them, and fix them once last thing
before the release?

> It look like your ObjectHandler prototype is almost ready for a first
> release. I might have introduced some problems with the *nix Makefile, but
> you can check it out and fix them. Hopefully we could autoconf the project
> before the release, add some Doxygen documentation, and I would provide a
> Win32 installer.

OK, I'm happy to do the autoconf & documentation.  I'll fix all *nix
makefiles.

> I've already granted you write access to the CVS, so please use the CVS
> code base for any further development. When we'll publish the QuEPs we will
> be referring to QuantLib 0.3.8, and the latest version of your code will be
> available in the CVS for public inspections.

I'll edit the final drafts of the docs to refer to 0.3.8.  I've just
attempted to commit a load of changes to cvs, I'm not sure if they've
gone through.

> BTW I'm going to add [hidden email] to the QuantLib-dev mailing list.
> Is it ok for you? Would you prefer a different address?

That address is fine, thank you.

> How are you managing the QuantLib-cvs traffic ? ;-)

The team certainly does keep busy :)

Regards
Eric

[Ferdinando M. Ametrano-3]

At 12:36 AM 11/1/2004, eric wrote:
>Unfortunately as I don't have
>Borland and VC7 I'll break these every time I add files etc.,

don't worry about that. I'll catch up as soon as I can. I've just committed
fixes for Borland, VC7, and Dev-C++


>I've just
>attempted to commit a load of changes to cvs, I'm not sure if they've
>gone through.

They've gone through

I will check later your proposal about the automatic generation of addin
source code. Anyway for what I am concerned I could summarize this way: go
ahead...

ciao -- Nando

PS Eric and Jody are now QuantLib-dev subscribers