quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Visual C++ settings

[<enr...@ri...>]

>>>>> "Gigi" == Luigi Ballabio <lui...@fa...> writes:

    Gigi> Hi all, could anyone remind me why we have two "On the edge"
    Gigi> configurations in the VC project which are indistinguishable
    Gigi> from the ordinary "Release" and "Debug"?

for historical reason? I remember Nando liked this configuration a
lot, he used it to distinguish between "current" and "stable"
releases. IMO this should be done using different workspaces.

    Gigi> Secondly: why not having a configuration with
    Gigi> "Multithreaded" and another for "Multithreaded DLL", instead
    Gigi> of arguing about which should be used?

I completely agree with you. By the way, I also completely agree with
the three proposals you posted some time ago (boost smart pointers,
flattening name spaces - how about shortening it too? QL:: or ql::
seems nice, and template lattice framework).
ciao,
enrico
-- 
Enrico Sirola <enr...@ri...>

RE: [Quantlib-dev] Visual C++ settings

[Jens T. <Je...@Th...>]

Hi Luigi,

the "On the edge" settings were introduced by Nando: they use the =
project
output of QuantLib, while the original Debug and Release configurations =
use
the installed binaries. This way you can build depending projects either
with the installed release, or a more recent (possible CVS) version.

Jens.

-----Original Message-----
From: qua...@li...
[mailto:qua...@li...] On Behalf Of Luigi
Ballabio
Sent: Tuesday, October 21, 2003 7:41 PM
To: QuantLib developers
Subject: [Quantlib-dev] Visual C++ settings


Hi all,
	could anyone remind me why we have two "On the edge" =20
configurations in the VC project which are indistinguishable from the =20
ordinary "Release" and "Debug"?

Secondly: why not having a configuration with "Multithreaded" and =20
another for "Multithreaded DLL", instead of arguing about which should =20
be used?

Thanks,
	Luigi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your
chance to show off your extensive product knowledge We want to know what =
you
know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quantlib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Visual C++ settings

[Luigi B. <lui...@fa...>]

Hi all,
	could anyone remind me why we have two "On the edge"  
configurations in the VC project which are indistinguishable from the  
ordinary "Release" and "Debug"?

Secondly: why not having a configuration with "Multithreaded" and  
another for "Multithreaded DLL", instead of arguing about which should  
be used?

Thanks,
	Luigi

[Quantlib-dev] [ quantlib-Feature Requests-824364 ] The Real typedef should be used throughout

[SourceForge.net <no...@so...>]

Feature Requests item #824364, was opened at 2003-10-15 13:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=824364&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Dann Corbit (danncorbit)
Assigned to: Nobody/Anonymous (nobody)
Summary: The Real typedef should be used throughout

Initial Comment:
You have a typedef of real like so:

typedef double Real;

but throughout the code, you use ordinary doubles all 
over the place.  Hence, the typedef is basically useless.

If (on the other hand) throughout the code you used 
Real parameters and Real automatic variables, then I 
would be able to use the system with other data types 
such as Moshier's Qfloat, Scott's MIRACL, etc. by making 
my own typedef as follows:

typedef qfloat Real;

or similar to that.

We need to compute with 100 digits of accuracy, so a 
double simply won't do.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=824364&group_id=12740

Re: [Quantlib-dev] Feedback requests

[Ferdinando A. <na...@am...>]

Boost:
>the powers that be have selected a few features for inclusion in a future 
>addendum to the C++ standard, mostly borrowed with minor modifications 
>from the Boost library (<http://www.boost.org>). Most notably, a 
>shared_ptr class was accepted which supersedes our Handle [...] should we 
>start using boost?
as Luigi knows, I've already advocated the boost usage a few times in 
private discussions. boost also includes a unit test framework which might 
replace cppunit, in order to limit the external library dependencies.

>  I'm not advocating a fast switch---personally I'd make the full 
> migration in as much as three releases (one using boost if available and 
> falling back to our thing if not, one requiring boost but still providing 
> typedefs for the old names, one removing the last traces of our once 
> beloved classes.)
I cannot disagree, especially considering that much of the burden of this 
transition will be on your shoulder :)

---------------------

Namespaces:
>sub-namespaces such as QuantLib::Instruments or QuantLib::PricingEngines 
>tend to get a lot in my way. Have they ever been useful?
QuantLib::Instruments and QuantLib::Pricers are currently guarding against 
few name clashes: BinaryOption and BarrierOption comes to mind

>  How about ditching them and flattening the thing to the single QuantLib 
> namespace?
It's OK for me.

>  We can do it in a conservative way in a couple of releases (in the 
> first, we flatten the namespace, we leave aliases to the old 
> sub-namespaces around so that it's not an error if one uses them, and we 
> deprecate them; in the second, we kill them.)
see above :)

-------------

templated lattices:
>Following the thread we had in July about the merits of template code 
>against more classical polymorphism, I experimented with some of the code 
>for binomial trees and reimplemented it with template techniques. [...]
>
>Have a look, and let me know what you think.
I've realized it is not a 10 minutes task :(


>Now, my dilemma is: on the one hand, the new code is more heavily 
>templated and might be more difficult to use [...] On the other hand [...] 
>it is 300 % faster.
I think we should take care to present an easy to use interface to our 
end-users (me included :)
I'm not against extra complexity in the inner QuantLib code, especially if 
it is documented. I mean I would appreciate if you could ease in some way 
the burden of understanding such starting points as
class NumericalMethod2 : public Patterns::CuriouslyRecurringTemplate<Impl>

>  I have no idea what the savings could be on Windows---frankly, I don't 
> even know if the thing compiles :)
It might be worth checking this out before moving to the new template approach

------------------------

Luigi: after the quantlib-dev feedback will you present these issues to the 
quantlib-users mailing-list?

ciao -- Nando 

[Quantlib-dev] [ quantlib-Bugs-823501 ] MC engine tests fail with Borland

[SourceForge.net <no...@so...>]

Bugs item #823501, was opened at 2003-10-14 17:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=823501&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ferdinando Ametrano (nando)
Assigned to: Nobody/Anonymous (nobody)
Summary: MC engine tests fail with Borland

Initial Comment:
European and Binary MC engine tests fails with Borland 
compiler

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=823501&group_id=12740

[Quantlib-dev] [ quantlib-Bugs-823500 ] doc generation with Borland make

[SourceForge.net <no...@so...>]

Bugs item #823500, was opened at 2003-10-14 17:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=823500&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ferdinando Ametrano (nando)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc generation with Borland make

Initial Comment:
The doc generation fails using Borland make

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=823500&group_id=12740

[Quantlib-dev] [ quantlib-Feature Requests-823497 ] merge NesQuant SVJD models

[SourceForge.net <no...@so...>]

Feature Requests item #823497, was opened at 2003-10-14 17:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=823497&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Ferdinando Ametrano (nando)
Assigned to: Nobody/Anonymous (nobody)
Summary: merge NesQuant SVJD models

Initial Comment:
Consider including NesQuant 
(http://www.nielses.dk/quantlib/nesquant/) SVJD models 
into QuantLib

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=823497&group_id=12740

[Quantlib-dev] Feedback request 3 - Namespaces

[Luigi B. <lui...@fa...>]

Hi all,
     part 3 of 3 in a feedback-request frenzy:

               Calvera:  No, come on, tell me why.
               Vin:      It's like this fellow I knew in El Paso. One day, he
                         just took all his clothes off and jumped in a mess of
                         cactus. I asked him that same question, "Why?"
               Calvera:  And?
               Vin:      He said, "It seemed like a good idea at the time."

                                                     --- The Magnificent Seven

Now that I'm older and wiser and more often cross-coding between different 
directories (typically, one writes an instrument, its pricing engine, and 
possibly a path pricer, and uses stuff from some other place in the 
repository) sub-namespaces such as QuantLib::Instruments or 
QuantLib::PricingEngines tend to get a lot in my way. Have they ever been 
useful? How about ditching them and flattening the thing to the single 
QuantLib namespace? We can do it in a conservative way in a couple of 
releases (in the first, we flatten the namespace, we leave aliases to the 
old sub-namespaces around so that it's not an error if one uses them, and 
we deprecate them; in the second, we kill them.)

Note: I'm not proposing to reorganize the directory structure of the 
repository, even though they reflect each other at this time. We do need 
the organization at the file level---we just don't need it to get in the 
way while coding.

Let me know what you think.

Later,
	Luigi

[Quantlib-dev] Feedback request 2 - Boost

[Luigi B. <lui...@fa...>]

Hi all,
     part 2 of 3 in a feedback-request frenzy:

as reported e.g. in <http://www.cuj.com/documents/s=8890/cujexp0310sutter/> 
the powers that be have selected a few features for inclusion in a future 
addendum to the C++ standard, mostly borrowed with minor modifications from 
the Boost library (<http://www.boost.org>). Most notably, a shared_ptr 
class was accepted which supersedes our Handle---but also other nice toys 
which we could put to good use. Now, in the most optimistic case, it will 
take years before this is fully standardized. However, eventually we'll be 
wanting to eighty-six our homegrown solutions and replace them with the 
hallowed and standard ones. And honestly, I'd rather do it sooner than 
later---hopefully the number of our users will increase and make it more 
and more difficult to make such changes.

Hence the question: should we start using boost? I'm not advocating a fast 
switch---personally I'd make the full migration in as much as three 
releases (one using boost if available and falling back to our thing if 
not, one requiring boost but still providing typedefs for the old names, 
one removing the last traces of our once beloved classes.)

Let me know what you think.

Later,
	Luigi

[Quantlib-dev] Feedback request 1 - templated lattices

[Luigi B. <lui...@fa...>]

Hi all,
     part 1 of 3 in a feedback-request frenzy:

in August---when I probably had too much time on my hands---I made some 
tentative development. Following the thread we had in July about the merits 
of template code against more classical polymorphism, I experimented with 
some of the code for binomial trees and reimplemented it with template 
techniques. The result is available for review at 
<http://quantlib.org/review/> where I uploaded a QuantLib tarball which 
includes the new code. Unfortunately, the tarball is kind of outdated (it 
is based on a pre-0.3.3 snapshot) but you can pretty much get the idea by 
looking at files called *2.hpp and *2.cpp. I also uploaded two test files 
at the same location. The test with the number 1 in its filename uses the 
old code, while the one with the 2 uses the new template classes.

Now, my dilemma is: on the one hand, the new code is more heavily templated 
and might be more difficult to use---more so if all the lattice framework 
were to be converted (right now it's just the binomial option engines.) On 
the other hand, on my Linux box and with gcc 3.2 fully optimizing the code, 
it is 300 % faster. I have no idea what the savings could be on 
Windows---frankly, I don't even know if the thing compiles :)

Have a look, and let me know what you think.

Later,
         Luigi

[Quantlib-dev] [ quantlib-Feature Requests-804600 ] Getting maturity date for a swap

[SourceForge.net <no...@so...>]

Feature Requests item #804600, was opened at 2003-09-11 19:49
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=804600&group_id=12740

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: navin mehta (navin_mehta)
Assigned to: Luigi Ballabio (lballabio)
Summary: Getting maturity date for a swap

Initial Comment:
There is not an easy way to get the start date of a 
swap,given a swap object.

It will be highly appreciated if you can please provide a 
public method for the same in the Swap/Simpleswap 
object.

Thanks!

BTW, I use a temporary workaround macro for this:
#define SWAPSTARTDATE(swap) ((const 
CashFlows::Coupon*)&(*(swap->fixedLeg())[0]))-
>accrualStartDate()

where swap is a Swap object.


Other method as suggested by Luigi:
--------------------------------

#include <ql/Instruments/swap.hpp>
#include <ql/CashFlows/coupon.hpp>

namespace QuantLib {

     namespace Instruments {

         /* This class below inherits from Swap in order to 
gain access
            to its protected members.
            Don't try this kind of hacks at home.

            Oh, and did I mention this isn't tested?
         */
         class SwapInspector : public Swap {
           private:
             // we don't really want to instantiate this
             SwapInspector()
             : Swap(std::vector<Handle<CashFlow> >(),
                    std::vector<Handle<CashFlow> >(),
                    RelinkableHandle<TermStructure>()) {}
           public:
             // return the start date of the first coupon
             static Date startDate(const Swap& swap) {
                 // get the first cash flow
                 Handle<CashFlow> firstCF = 
swap.firstLeg_.front();
                 try {
                     // is this a coupon?
                     Handle<CashFlows::Coupon> coupon = 
firstCF;
                     // ok, return its start date
                     return coupon.accrualStartDate();
                 } catch (Error&) {
                     // it was not a coupon. We'll doctor the
                     // error message to make it more 
readable.
                     throw Error("The swap coupons did not 
provide "
                                 "enough information");
                 }
             }
             // return the end date of the last coupon
             static Date endDate(const Swap& swap) {
                 Handle<CashFlow> lastCF = 
swap.firstLeg_.back();
                 try {
                     Handle<CashFlows::Coupon> coupon = 
lastCF;
                     return coupon.accrualEndDate();
                 } catch (Error&) {
                     throw Error("The swap coupons did not 
provide "
                                 "enough information");
                 }
             }
         };

     }

}





Given a swap object, how can I get the start date and 
length 

----------------------------------------------------------------------

>Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-13 18:23

Message:
Logged In: YES 
user_id=75450

Hi,
    Swap::startDate() and Swap::maturity() are now 
implemented in CVS and will be available in next release.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=804600&group_id=12740

[Quantlib-dev] [ quantlib-Feature Requests-822568 ] "Getting started" page

[SourceForge.net <no...@so...>]

Feature Requests item #822568, was opened at 2003-10-13 10:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=822568&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Luigi Ballabio (lballabio)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Getting started" page

Initial Comment:
We need a page on the site to which we can refer people 
asking "Where should I start to tackle QuantLib? What to 
read first? Where to go next?" and so on. Once we have 
it, the above can be the first item in a FAQ.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=822568&group_id=12740

[Quantlib-dev] [ quantlib-Feature Requests-820783 ] Add method for getting implied volatility in caplet

[SourceForge.net <no...@so...>]

Feature Requests item #820783, was opened at 2003-10-09 18:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=820783&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: amar singh (asd2003)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add method for getting implied volatility in caplet

Initial Comment:
To add a method 'impliedvolatility' in the cap or 
associated classes, to be able to calculate implied 
volatility for a caplet.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=820783&group_id=12740

[Quantlib-dev] [ quantlib-Patches-811713 ] Wrong lambda in BermudanSwaption example

[SourceForge.net <no...@so...>]

Patches item #811713, was opened at 2003-09-24 14:09
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=811713&group_id=12740

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Francesco Perissin (fperissin)
>Assigned to: Luigi Ballabio (lballabio)
Summary: Wrong lambda in BermudanSwaption example

Initial Comment:
The lambda of 0.25 used in BermudanSwaption example 
is too high compared to the carachteristic length of the 
parameters to fit. This may lead to unsuccesful 
calibrations in some particular situations, like the 
calibration of a 1-dim HullWhite model with the alpha 
being constant.
A better value is 0.05.
Appearently, there are no cases of wrong calibrations 
with the "official" HullWhite model (but... who knows?)


----------------------------------------------------------------------

Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-09 16:25

Message:
Logged In: YES 
user_id=75450

The patch was applied to the code in the cvs repository.
It will be included in next release.
Thank you.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=811713&group_id=12740

[Quantlib-dev] [ quantlib-Patches-811296 ] European Swaption Excercise time

[SourceForge.net <no...@so...>]

Patches item #811296, was opened at 2003-09-23 19:33
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=811296&group_id=12740

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: European Swaption Excercise time

Initial Comment:
In ql/Pricers/blackswaption.cpp the BlackSwaption 
pricer is assuming the excercise date of the option is 
the start date of the swap.
Line 29:
 'Time start = arguments_.floatingResetTimes[0];'
In order to use the excercise times present this needs 
to be changed to:
 'Time start = arguments_.exerciseTimes[0];'

And of course you might want to change the name of 
the variable to something other than 'start'

Bi...@ci...

----------------------------------------------------------------------

>Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-09 13:56

Message:
Logged In: YES 
user_id=75450

Patch applied.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=811296&group_id=12740

[Quantlib-dev] [ quantlib-Bugs-804303 ] division by zero in TermStructure::zeroCoupon

[SourceForge.net <no...@so...>]

Bugs item #804303, was opened at 2003-09-11 12:55
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=804303&group_id=12740

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Luigi Ballabio (lballabio)
>Assigned to: Luigi Ballabio (lballabio)
Summary: division by zero in TermStructure::zeroCoupon

Initial Comment:

When compiled with Borland, the TermStructure::
zeroCoupon method fails with a division by zero if t == 0.
0 and f > 0



----------------------------------------------------------------------

>Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-09 10:43

Message:
Logged In: YES 
user_id=75450

The division by zero is now removed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=804303&group_id=12740

Re: [Quantlib-dev] QuantLib-0.3.3 documentation RPM package available.

[Ferdinando A. <na...@am...>]

At 07:17 AM 10/5/2003 -0500, Liguo Song wrote:
> > I'm not sure about re-releasing RPM 0.3.3 packages, do you think we should?
>I would think this as adding components (docs here) rather than
>re-releasing. Also, RPM has a release number after the version number,
>which is designed for the patches between versions. So, it wouldn't be
>unconventional to do release before 0.3.4 here.

Ok, I got it. I will upload the files later today.

ciao -- Nando

Re: [Quantlib-dev] QuantLib-0.3.3 documentation RPM package available.

[Liguo S. <lig...@va...>]

> I'm not sure about re-releasing RPM 0.3.3 packages, do you think we should?
I would think this as adding components (docs here) rather than
re-releasing. Also, RPM has a release number after the version number,
which is designed for the patches between versions. So, it wouldn't be
unconventional to do release before 0.3.4 here.
 
> The work you've done could be used for the 0.3.4 which we might plan for 
> mid-December.
That sounds great. I will begin to make sure my spec files will work
on the CVS tree.

> 
> >BTW, if anyone needs another sub-package, such as python, ruby, guile and 
> >MzScheme (what is this?), please let me know. So I can move it up on the 
> >list of things todo here.
> That would be appreciated. It would be nice to have them for 0.3.4
> 
> What about freezing a release candidate early December in order to release 
> the 0.3.4 by December 17?
I would vote for it, if it counts. :)

Later.


Liguo

Re: [Quantlib-dev] QuantLib-0.3.3 documentation RPM package available.

[Luigi B. <lui...@fa...>]

At 12:07 PM +0200 10/5/03, Ferdinando Ametrano wrote:
>What about freezing a release candidate early December in order to 
>release the 0.3.4 by December 17?

Sounds good. We can gift-wrap it and add a Xmas card...

Ho-ho-ho,
	Luigi

Re: [Quantlib-dev] QuantLib-0.3.3 documentation RPM package available.

[Ferdinando A. <na...@am...>]

Liguo Song:
>I finally put the documentation for QuantLib-0.3.3 into a rpm package. 
>Also, the source package is updated, so it will generate doc pacage. And 
>both of these packages should show up on SourceForge soon.
??? where? when?

I'm not sure about re-releasing RPM 0.3.3 packages, do you think we should?

The work you've done could be used for the 0.3.4 which we might plan for 
mid-December.

>BTW, if anyone needs another sub-package, such as python, ruby, guile and 
>MzScheme (what is this?), please let me know. So I can move it up on the 
>list of things todo here.
That would be appreciated. It would be nice to have them for 0.3.4

What about freezing a release candidate early December in order to release 
the 0.3.4 by December 17?

ciao -- Nando 

Re: [Quantlib-dev] QuantLib-0.3.3 documentation RPM package available.

[Luigi B. <lui...@fa...>]

Liguo,

At 1:05 PM -0500 10/3/03, Liguo Song wrote:
>After some unexpected extra work,

is there anything I should change upstream so that it's less work next time?

>I finally put the documentation for QuantLib-0.3.3 into a rpm package.

Thanks,
	Luigi

Re: [Quantlib-dev] Compile Docs on RH 8.0

[Luigi B. <lui...@fa...>]

At 1:20 PM -0500 10/3/03, Liguo Song wrote:
>Another thing that I noticed when compiling the documentation of 
>QuantLib-0.3.3 is that doxygen-1.3.4 (1.3.3 is required) will 
>complain about obsolete tags, such as:
>   Warning: Tag `CGI_NAME' at line 220 of file .quantlib.doxy has 
>become obsolete.
>   To avoid this warning please update your configuration file using 
>"doxygen -u"
>
>Using "doxygen -u .quantlib.doxy" before "doxygen .quantlib.doxy" 
>seems solve this problem. Maybe we should also put this into the 
>Makefile of Docs.
>
>I am not familiar with doxygen. Any suggestion from people with more 
>experienced with doxygen?

Well, it's just that tags sometimes change between Doxygen releases. 
Usually tags get added, and newer versions of Doxygen don't complain 
upon processing older doxyfiles. This time, tags were removed, so 
that the latest Doxygen issues obsolescence warnings. But: 1) this is 
seldom the case; 2) they were only warnings, and the docs would have 
been made succesfully anyway; 3) the doxyfile needs to be changed 
only once per Doxygen release, and 4) the version in CVS is already 
updated for 1.3.4, so I don't think a Makefile rule is needed...

Later,
	Luigi

Re: [Quantlib-dev] Compile Docs on RH 8.0

[Liguo S. <Lig...@va...>]

Another thing that I noticed when compiling the documentation of QuantLib-0.3.3 
is that doxygen-1.3.4 (1.3.3 is required) will complain about obsolete tags, 
such as:
   Warning: Tag `CGI_NAME' at line 220 of file .quantlib.doxy has become obsolete.
   To avoid this warning please update your configuration file using "doxygen -u"

Using "doxygen -u .quantlib.doxy" before "doxygen .quantlib.doxy" seems solve 
this problem. Maybe we should also put this into the Makefile of Docs.

I am not familiar with doxygen. Any suggestion from people with more experienced 
with doxygen?

Have a nice weekend.


Liguo (Leo)



Luigi Ballabio wrote:
> At 12:16 AM 10/3/03, Liguo Song wrote:
> 
>> if no option is given, the output of dvips will go to a printer.
>> One solution to avoid this problem is to invoke dvips with "-o file.ps".
>> Should we use this in our make files? If so, can anyone commit this 
>> change?
> 
> 
> Yes, we should. I just committed the change.
> 
> Thanks,
>         Luigi
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] QuantLib-0.3.3 documentation RPM package available.

[Liguo S. <Lig...@va...>]

After some unexpected extra work, I finally put the documentation for 
QuantLib-0.3.3 into a rpm package. Also, the source package is updated, so it 
will generate doc pacage. And both of these packages should show up on 
SourceForge soon. Please check it out if you prefer the RPM format.

BTW, if anyone needs another sub-package, such as python, ruby, guile and 
MzScheme (what is this?), please let me know. So I can move it up on the list of 
things todo here.

Thanks.


Liguo (Leo)