quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Bugs-528736 ] building QuantLib CVS under Cygwin

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

Bugs item #528736, was opened at 2002-03-12 00:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=528736&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabor Liptak (gliptak)
Assigned to: Nobody/Anonymous (nobody)
Summary: building QuantLib CVS under Cygwin

Initial Comment:
As per the INSTALL.txt one should run configure in the
directory.

But there does not seem to be a configure in the directory:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quantlib/QuantLib/

When I run autoconf, I get these errors:

$ autoconf --version
autoconf (GNU Autoconf) 2.52
Written by David J. MacKenzie.
~/QuantLib
$ autoconf
configure.in:12: error: possibly undefined macro:
AM_CONFIG_HEADER
configure.in:13: error: possibly undefined macro:
AM_INIT_AUTOMAKE
configure.in:22: error: possibly undefined macro:
AM_PROG_LIBTOOL
configure.in:31: error: possibly undefined macro:
AM_CONDITIONAL

Do I need to have some more cygwin packages installed?

Thanks

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

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

[Quantlib-dev] interpolation and extrapolation

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

Hi

I'm working on the interpolation functions for QuantLib-Excel and I've 
added bilinear 2D interpolation to QuantLib (Luigi, thanks for the fix: I 
wasn't there yet, my problem was with the Excel interface ;-)

I was considering the extrapolation issue.
Up to now extrapolation is allowed by default by the interpolation classes, 
any check has to be at a higher level (e.g. in the term structure classes)

I think the extrapolation check should be in the interpolation classes, and 
I would like to add a boolean allowExtrapolation to their constructors.

Any counter argument?

ciao -- Nando

[Quantlib-dev] Re: [Quantlib-users] RQuantLib -- Interfacing QuantLib from R

[Dirk E. <ed...@de...>]

Hi Krishna

> I was happy to see the rquantlib interface, and would like
> to know how i could help in this?. is there a list of todo's?

Thanks for you offer to help. There is no list of TODOs as of yet. There is
a need a simply thinking through some of the issue of how QL represents
"things" and how R does it. 

Concretely, I was looking e.g. at the Swap example in QL and trying to see
how to make at least a simple version available for R. You quickly run into
all the calendar and convention issues, and the myriad ways of setting up a
swap. 

Another issue is how to represent "cacheable" things in R [e.g. have an
option recalculated if only the vol value changes]. Not sure if that is
doable

Also, it would be straightforward to take my existing code for European,
American and Binary Option and extend it to cover a few other exotics. Or
the ones with concrete dividend vectors.

I hope you don't mind if I CC this to the quantlib-dev list as the good
folks there might have comments too.

Cheers, Dirk

PS How's life at the OGI program? 

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

[Quantlib-dev] Re: QuantLib release

[Dirk E. <ed...@de...>]

Ciao Nando

On Fri, Mar 01, 2002 at 04:42:41PM +0100, Ferdinando Ametrano wrote:
> Dirk wrote:
> >Nando: Time for a new point release?
> Is a new 0.3.0a6 branch enough, or do you need a 0.2.2 release?

Doesn't matter to me. We can for now stick with your numbering scheme at
your end (0.3.0a6) which I transform into mine at my end (due to the sorting
requirement you're now fully aware of). I could stick with 0.2.1cvs20020301
or call it 0.2.2.  I just have to make sure it is higher (in dpkg sorting
terms) than the existing one.

> I would prefer to wait for 0.3.0 final, if possible.

Debian might realease soon. 0.3.0 might miss that, so a bug fix release
could help there.

We can still release 0.3.0 after that.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

[Quantlib-dev] QuantLib release

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

Dirk wrote:
>Nando: Time for a new point release?
Is a new 0.3.0a6 branch enough, or do you need a 0.2.2 release?

I would prefer to wait for 0.3.0 final, if possible.
Sad, I don't want to put any kind of pressure on you, but I'm only waiting 
for the documentation of your work to finalize 0.3.0
Any news from you?

ciao -- Nando

Re: [Quantlib-dev] Re: RQuantLib_0.1.0 in incoming

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

At 11:18 AM 2/26/02 -0600, Dirk Eddelbuettel wrote:
>Nando: Time for a new point release?
OK

>         -Wall -pendantic -06    same,some warnings on uninit. enum optionType
are these worth checking? Should we have -pedantic -06 as default?

ciao -- Nando

Re: [Quantlib-dev] Re: RQuantLib_0.1.0 in incoming

[Luigi B. <bal...@ma...>]

At 11:18 AM 2/26/02 -0600, Dirk Eddelbuettel wrote:
>On Tue, Feb 26, 2002 at 06:24:57PM +0000, Luigi Ballabio wrote:
> > Does it get better if you replace every occurrence with
> >
> > typename std::vector<Iterator>::iterator it = iteratorVector_.begin();
> >
> > ?
>
>Yes!  Good stuff! I am always afraid of people who actually understand their
>own code :)

Oh, but I don't understand. I just prophesy :)

I've checked the fix into CVS.

Bye,
         Luigi

Re: [Quantlib-dev] Re: RQuantLib_0.1.0 in incoming

[Dirk E. <ed...@de...>]

On Tue, Feb 26, 2002 at 06:24:57PM +0000, Luigi Ballabio wrote:
> At 10:47 AM 2/26/02 -0600, Dirk Eddelbuettel wrote:
> >Ok, I confirmed that on my 'Debain testing' laptop: The -pedantic switch
> >breaks building of RQuantLib, using the Jan 20 CVS snapshot of QL.
> 
> Dirk,
>         I didn't try it, but from your previous report, I see that 
> compilation fails on the instruction
> 
> std::vector<Iterator>::iterator it = iteratorVector_.begin();
> 
> which is replicated in a few methods.
> Does it get better if you replace every occurrence with
> 
> typename std::vector<Iterator>::iterator it = iteratorVector_.begin();
> 
> ?

Yes!  Good stuff! I am always afraid of people who actually understand their
own code :)

It now works:
	-Wall -pedantic		"clean", no warnings
	-Wall -pendantic -02	some warnings on uninit. enum optionType
	-Wall -pendantic -06	same,some warnings on uninit. enum optionType

Nando: Time for a new point release?

Thanks, Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] Re: RQuantLib_0.1.0 in incoming

[Luigi B. <bal...@ma...>]

At 10:47 AM 2/26/02 -0600, Dirk Eddelbuettel wrote:
>Ok, I confirmed that on my 'Debain testing' laptop: The -pedantic switch
>breaks building of RQuantLib, using the Jan 20 CVS snapshot of QL.

Dirk,
         I didn't try it, but from your previous report, I see that 
compilation fails on the instruction

std::vector<Iterator>::iterator it = iteratorVector_.begin();

which is replicated in a few methods.
Does it get better if you replace every occurrence with

typename std::vector<Iterator>::iterator it = iteratorVector_.begin();

?

Bye,
         Luigi

[Quantlib-dev] Re: RQuantLib_0.1.0 in incoming

[Dirk E. <ed...@de...>]

Ok, I confirmed that on my 'Debain testing' laptop: The -pedantic switch
breaks building of RQuantLib, using the Jan 20 CVS snapshot of QL.

Kurt et al: Is that no-no which will prevent it from CRAN inclusion?

QLers: g++-2.95 breaks with -pedantic, g++-3.0 breaks outright (with
-mieee-fp -fPIC).  Ideas?   Those C++ classes make my head spin.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

[Quantlib-dev] [Kurt.Hornik@wu-wien.ac.at: Re: RQuantLib_0.1.0 in incoming]

[Dirk E. <ed...@de...>]

Sorry to pester all of you with this, but it looks as if I have some egg
on my face. The package doesn't seem to compile on the R CRAN archive
maintainer's machine ... with the exact same Debian setup as mine. The one
difference I can think of is that I do not export -pedantic and -Wall. 

Could that make the difference?  If so, could you make it work :->  ?

Dirk

----- Forwarded message from Kurt Hornik <Kur...@wu...> -----

Envelope-to: ed...@ed...
Delivery-date: Tue, 26 Feb 2002 01:20:38 -0600
From: Kurt Hornik <Kur...@wu...>
To: Dirk Eddelbuettel <ed...@de...>
Cc: cr...@r-...
Subject: Re: RQuantLib_0.1.0 in incoming
Reply-To: Kur...@wu...

>>>>> Dirk Eddelbuettel writes:

> I just uploaded RQuantLib into incoming/.

> RQuantLib is an R [ http://www.r-project.org ] package to access the powerful
> QuantLib [ http://quantlib.org ] libraries for quantitative finance.

> The packages passes the R CMD check and build steps on my Debian testing
> systems with libquantlib0 and libquantlib0-dev packages installed.

> RQuantLib is at an early stage: I only defined two basic classes Option and
> ImpliedVolatility with print and summary methods, and European and American
> options on top of them. Binary Options are also available for the option
> calculator.  I opted for (named) lists as input and output types. These
> functions are "scalar" and operate on one option at a time.

> One other cute function is EuropeanOptionArrays which allows for vectors of
> any of the numeric input variables, and returns an appropriate
> multidimensional array of all possible valuation combinations. The example()
> function plots a few combinations.

> The package, and well as a little more documentation, is also at

>     http://dirk.eddelbuettel.com/code/rquantlib.html

Dirk,

I have

hornik@mithrandir:~/src/R/share/perl/R$ dpkg -l "*quantlib*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libquantlib0   0.2.1cvs200201 Quantitative Finance Library -- development 
ii  libquantlib0-d 0.2.1cvs200201 Quantitative Finance Library -- library pack
pn  quantlib-pytho <none>         (no description available)
ii  quantlib-refma 0.2.1-1        Quantitative Finance Library -- reference ma
pn  quantlib-ruby  <none>         (no description available)

and get

hornik@mithrandir:~/tmp/CRAN$ R CMD check RQuantLib
* checking for working latex ... OK
* using log directory `/home/Hornik/tmp/CRAN/RQuantLib.Rcheck'

Installing *source* package `RQuantLib' ...
loading site script /usr/local/etc/config.site
creating cache ./config.cache
checking for quantlib-config... yes
checking for c++... c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking how to run the C++ preprocessor... c++ -E
updating cache ./config.cache
creating ./config.status
creating src/Makevars
Completed configuration and ready to build.
 libs
g++ -I/usr/lib/R/include  -I/usr/local/include -mieee-fp -I/usr/include -fPIC  -
g -O2 -Wall -pedantic -c RQuantLib.cc -o RQuantLib.o
In file included from /usr/include/ql/quantlib.hpp:228,
                 from RQuantLib.cc:25:
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator ++()':
/usr/include/ql/Utilities/combiningiterator.hpp:119: parse error before `='
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator --()':
/usr/include/ql/Utilities/combiningiterator.hpp:135: parse error before `='
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator +=(typename iterator_traits<_Iterator>::diff
erence_type)':
/usr/include/ql/Utilities/combiningiterator.hpp:152: parse error before `='
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator -=(typename iterator_traits<_Iterator>::diff
erence_type)':
/usr/include/ql/Utilities/combiningiterator.hpp:160: parse error before `='
RQuantLib.cc: In function `struct SEXPREC * QL_EuropeanOption(SEXPREC *)':
RQuantLib.cc:79: warning: `enum QuantLib::Option::Type optionType' might be used
 uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_EuropeanOptionImpliedVolatility(S
EXPREC *)':
RQuantLib.cc:129: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_AmericanOption(SEXPREC *)':
RQuantLib.cc:171: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_AmericanOptionImpliedVolatility(S
EXPREC *)':
RQuantLib.cc:223: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_BinaryOption(SEXPREC *)':
RQuantLib.cc:270: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
make: *** [RQuantLib.o] Error 1
ERROR: compilation failed for package `RQuantLib'
 ERROR

???

----- End forwarded message -----

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] implied blows up for binary option

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

Two more warnings:
1) impliedVol usually fails when the option's value is not attainable with 
any volatility value (e.g. a value less than the intrinsic value for an 
american option)
2) even if a root exists with binary options you're not guaranteed 
impliedVol will find it. This is because contracts with a gamma that 
changes sign have values that are not monotonic in the volatility.

I'm going to add these 2 warning to the Doxygen documentation

ciao -- Nando


At 09:48 AM 2/26/02 +0000, Luigi Ballabio wrote:
>At 09:25 PM 2/25/02 -0600, Dirk Eddelbuettel wrote:
>>Playing with binaries, I noticed that implied Vol calculations abort:
>>I don't understand why. Should somebody comment?
>
>Well, between you and me and the other developers, BinaryOption is _so_ 
>smart (not) that it caches its value and doesn't change it even though its 
>volatility is changed. Of course this makes it kind of difficult to solve 
>for its implied volatility...
>
>I'm going to fix it this morning. Thanks for the report.
>
>Bye,
>         Luigi
>
>
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] implied blows up for binary option

[Luigi B. <bal...@ma...>]

At 09:25 PM 2/25/02 -0600, Dirk Eddelbuettel wrote:
>Playing with binaries, I noticed that implied Vol calculations abort:
>I don't understand why. Should somebody comment?

Well, between you and me and the other developers, BinaryOption is _so_ 
smart (not) that it caches its value and doesn't change it even though its 
volatility is changed. Of course this makes it kind of difficult to solve 
for its implied volatility...

I'm going to fix it this morning. Thanks for the report.

Bye,
         Luigi

[Quantlib-dev] implied blows up for binary option

[Dirk E. <ed...@de...>]

Playing with binaries, I noticed that implied Vol calculations abort:

edd@homebud:~/misc> cat binary_abrt.cc

#include <ql/quantlib.hpp>

int main(int argc, char* argv[])
{
  using namespace QuantLib;

  using QuantLib::Pricers::BinaryOption;

  try {
    double underlying = 102;
    double strike = 100;
    Spread dividendYield = 0.01;
    Rate riskFreeRate = 0.05;
    Time maturity = 1.0;
    double volatility = 0.60;
    BinaryOption BO = BinaryOption(Option::Call, underlying, strike,
                                   dividendYield, riskFreeRate, maturity,
                                   volatility);
    cout << "value is " << BO.value() << endl;
    double impliedVol = BO.impliedVolatility(1.1*BO.value());
    cout << "implied is " << impliedVol << endl;

  } catch (std::exception& e) {
    std::cout << e.what() << std::endl;

  } catch (...) {
    std::cout << "unknown error" << std::endl;
  }

  exit (0);
}
edd@homebud:~/misc> ./binary_abrt
value is 0.400098
root not bracketed: f[0.0001000000,4.0000000000] -> [0.20004910384016516556,0.20004910384016516556]

I don't understand why. Should somebody comment?

This is on Debian with the 0.3.0a5-20020120 packages.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[akira y. <ak...@de...>]

Hello,

>>>>> In <200...@se...> 
>>>>>	LaMont Jones <la...@hp...> wrote:
> > It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
> > done in the Ruby development branch (Ruby 1.7.something) but not in 
> > the current release (or at least not the one in Woody. I don't know 
> > which version of Ruby you have in... wait, what was the name of the 
> > character now? Well, unstable anyway)
> > It also needs a minor fix in SWIG which has been done in CVS but 
> > wasn't released either.
> > 
> > The bottom line is, we're out in the cold :(
> > Architectures with gcc 3.0.x are ruled out for the time being.
>
> ruby_1.6.6-5 is in sid (which will always be unstable)
>
> Depending on how invasive the fix is, I suppose the ruby maintainer
> could port the fix back to ruby 1.6.6-5, and thereby fix all these
> ruby-dependants.  Akira?

I made a back-port-patch based on results of diffs between 2001-03-27
and 2001-05-03 on *.h, and I attach the patch in this mail. How do you
think about it?  If it is O.K., I will make a new deb-package. (and
will send it to Mr.Matz if it is better to do it by me.)

Thank you.
-- 
 akira yamada <URL:http://arika.org/ruby/>
 (ak...@ar..., ak...@ru... or ak...@li...)


Index: intern.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/intern.h,v
retrieving revision 1.35.2.16
diff -u -r1.35.2.16 intern.h
--- intern.h	13 Feb 2002 09:02:15 -0000	1.35.2.16
+++ intern.h	16 Feb 2002 04:42:15 -0000
@@ -95,13 +95,13 @@
 VALUE rb_class_protected_instance_methods _((int, VALUE*, VALUE));
 VALUE rb_class_private_instance_methods _((int, VALUE*, VALUE));
 VALUE rb_obj_singleton_methods _((VALUE));
-void rb_define_method_id _((VALUE, ID, VALUE (*)(), int));
+void rb_define_method_id _((VALUE, ID, VALUE (*)(ANYARGS), int));
 void rb_frozen_class_p _((VALUE));
 void rb_undef _((VALUE, ID));
-void rb_define_protected_method _((VALUE, const char*, VALUE (*)(), int));
-void rb_define_private_method _((VALUE, const char*, VALUE (*)(), int));
-void rb_define_singleton_method _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_private_method _((VALUE,const char*,VALUE(*)(),int));
+void rb_define_protected_method _((VALUE, const char*, VALUE (*)(ANYARGS), int));
+void rb_define_private_method _((VALUE, const char*, VALUE (*)(ANYARGS), int));
+void rb_define_singleton_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_private_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
 VALUE rb_singleton_class _((VALUE));
 /* enum.c */
 VALUE rb_enum_length _((VALUE));
@@ -167,13 +167,13 @@
 VALUE rb_thread_stop _((void));
 VALUE rb_thread_wakeup _((VALUE));
 VALUE rb_thread_run _((VALUE));
-VALUE rb_thread_create _((VALUE (*)(), void*));
+VALUE rb_thread_create _((VALUE (*)(ANYARGS), void*));
 int rb_thread_scope_shared_p _((void));
 void rb_thread_interrupt _((void));
 void rb_thread_trap_eval _((VALUE, int));
 void rb_thread_signal_raise _((char*));
-int rb_thread_select();
-void rb_thread_wait_for();
+int rb_thread_select(ANYARGS);
+void rb_thread_wait_for(ANYARGS);
 VALUE rb_thread_current _((void));
 VALUE rb_thread_main _((void));
 VALUE rb_thread_local_aref _((VALUE, ID));
@@ -347,7 +347,7 @@
 VALUE rb_struct_aset _((VALUE, VALUE, VALUE));
 VALUE rb_struct_getmember _((VALUE, ID));
 /* time.c */
-VALUE rb_time_new();
+VALUE rb_time_new(ANYARGS);
 /* variable.c */
 VALUE rb_mod_name _((VALUE));
 VALUE rb_class_path _((VALUE));
Index: node.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/node.h,v
retrieving revision 1.18.2.2
diff -u -r1.18.2.2 node.h
--- node.h	6 Apr 2001 05:42:40 -0000	1.18.2.2
+++ node.h	16 Feb 2002 04:43:03 -0000
@@ -131,7 +131,7 @@
 	struct RNode *node;
 	ID id;
 	VALUE value;
-	VALUE (*cfunc)();
+	VALUE (*cfunc)(ANYARGS);
 	ID *tbl;
     } u1;
     union {
@@ -340,7 +340,7 @@
 NODE *rb_compile_file _((const char*, VALUE, int));
 
 void rb_add_method _((VALUE, ID, NODE *, int));
-NODE *rb_node_newnode();
+NODE *rb_node_newnode(ANYARGS);
 
 struct global_entry *rb_global_entry _((ID));
 VALUE rb_gvar_get _((struct global_entry *));
Index: ruby.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/ruby.h,v
retrieving revision 1.29.2.10
diff -u -r1.29.2.10 ruby.h
--- ruby.h	25 Dec 2001 15:09:05 -0000	1.29.2.10
+++ ruby.h	16 Feb 2002 04:27:48 -0000
@@ -74,6 +74,12 @@
 # define __(args) ()
 #endif
 
+#ifdef __cplusplus
+#define ANYARGS ...
+#else
+#define ANYARGS
+#endif
+ 
 #ifdef HAVE_ATTR_NORETURN
 # define NORETURN __attribute__ ((noreturn))
 #else
@@ -408,8 +414,8 @@
 #define MEMMOVE(p1,p2,type,n) memmove((p1), (p2), sizeof(type)*(n))
 #define MEMCMP(p1,p2,type,n) memcmp((p1), (p2), sizeof(type)*(n))
 
-void rb_glob _((char*,void(*)(),VALUE));
-void rb_globi _((char*,void(*)(),VALUE));
+void rb_glob _((char*,void(*)(const char*,VALUE),VALUE));
+void rb_iglob _((char*,void(*)(const char*,VALUE),VALUE));
 
 VALUE rb_define_class _((const char*,VALUE));
 VALUE rb_define_module _((const char*));
@@ -420,16 +426,16 @@
 void rb_extend_object _((VALUE,VALUE));
 
 void rb_define_variable _((const char*,VALUE*));
-void rb_define_virtual_variable _((const char*,VALUE(*)(),void(*)()));
-void rb_define_hooked_variable _((const char*,VALUE*,VALUE(*)(),void(*)()));
+void rb_define_virtual_variable _((const char*,VALUE(*)(ANYARGS),void(*)(ANYARGS)));
+void rb_define_hooked_variable _((const char*,VALUE*,VALUE(*)(ANYARGS),void(*)(ANYARGS)));
 void rb_define_readonly_variable _((const char*,VALUE*));
 void rb_define_const _((VALUE,const char*,VALUE));
 void rb_define_global_const _((const char*,VALUE));
 
-#define RUBY_METHOD_FUNC(func) ((VALUE (*)__((...)))func)
-void rb_define_method _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_module_function _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_global_function _((const char*,VALUE(*)(),int));
+#define RUBY_METHOD_FUNC(func) ((VALUE (*)(ANYARGS))func)
+void rb_define_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_module_function _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_global_function _((const char*,VALUE(*)(ANYARGS),int));
 
 void rb_undef_method _((VALUE,const char*));
 void rb_define_alias _((VALUE,const char*,const char*));
@@ -479,11 +485,11 @@
 VALUE rb_each _((VALUE));
 VALUE rb_yield _((VALUE));
 int rb_block_given_p _((void));
-VALUE rb_iterate _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_rescue _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_rescue2 __((VALUE(*)(),VALUE,VALUE(*)(),VALUE,...));
-VALUE rb_ensure _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_catch _((const char*,VALUE(*)(),VALUE));
+VALUE rb_iterate _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_rescue _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_rescue2 __((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE,...));
+VALUE rb_ensure _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_catch _((const char*,VALUE(*)(ANYARGS),VALUE));
 void rb_throw _((const char*,VALUE)) NORETURN;
 
 VALUE rb_require _((const char*));
Index: rubysig.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/rubysig.h,v
retrieving revision 1.6
diff -u -r1.6 rubysig.h
--- rubysig.h	16 Nov 2000 07:24:11 -0000	1.6
+++ rubysig.h	16 Feb 2002 04:43:34 -0000
@@ -57,7 +57,7 @@
 #define ALLOW_INTS {rb_prohibit_interrupt--; CHECK_INTS;}
 #define ENABLE_INTS {rb_prohibit_interrupt--;}
 
-VALUE rb_with_disable_interrupt _((VALUE(*)(),VALUE));
+VALUE rb_with_disable_interrupt _((VALUE(*)(ANYARGS),VALUE));
 
 EXTERN rb_atomic_t rb_trap_pending;
 void rb_trap_restore_mask _((void));

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[LaMont J. <la...@hp...>]

> LaMont:  In a situation like this, is it ok if I actually prevent building
> on hppa and ia64 via an explicit Architecture: tag in debian/control?

Better to leave it without the Architecture tag hack, since it _should_
build.  That way, when it does, you don't have to do anything special.
As it sits, uploading a new verison with the arch change will cause the
buildd to try it again, and, well....

The best thing might be to clone the defect over to ruby, and get the
headers fixed in ruby.  Just reassigning the bug is likely to get you
another bug report after I forget the details of _this_ package, and
that'll only get you annoyed... :-)

lamont

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[Dirk E. <ed...@de...>]

Luigi,

Thanks a big bunch for getting the nasty details out from under the carpet...

On Fri, Feb 15, 2002 at 09:31:06PM +0100, Luigi Ballabio wrote:
> At 7:49 AM -0600 2/15/02, Dirk Eddelbuettel wrote:
> >On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
> >> At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
> >> >Here is another g++-3.0 bug report regarding quantlib, or in particular 
> >> the
> > > >Ruby bindings. I'd appreciate any comments. Luigi?
> 
> Ok, here's the final word from the Ruby gurus.
> 
> It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
> done in the Ruby development branch (Ruby 1.7.something) but not in 
> the current release (or at least not the one in Woody. I don't know 
> which version of Ruby you have in... wait, what was the name of the 
> character now? Well, unstable anyway)

It's called "sid".  There is a ruby1.7_1.7.2.0cvs2002.01.18-1 package.
We could try that.

> It also needs a minor fix in SWIG which has been done in CVS but 
> wasn't released either.

Okay, but as we figured, I don't need, or should, re-run swig anyway. So if
you can get hands on a reworked version, we could try a new QL snapshort of
QuantLib-Ruby. If we want it that badly which maybe we don't.

> The bottom line is, we're out in the cold :(
> Architectures with gcc 3.0.x are ruled out for the time being.

That's probably ok, especially as the fix will be forthcoming.

LaMont:  In a situation like this, is it ok if I actually prevent building
on hppa and ia64 via an explicit Architecture: tag in debian/control?

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[LaMont J. <la...@hp...>]

> Ok, here's the final word from the Ruby gurus.
> 
> It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
> done in the Ruby development branch (Ruby 1.7.something) but not in 
> the current release (or at least not the one in Woody. I don't know 
> which version of Ruby you have in... wait, what was the name of the 
> character now? Well, unstable anyway)
> It also needs a minor fix in SWIG which has been done in CVS but 
> wasn't released either.
> 
> The bottom line is, we're out in the cold :(
> Architectures with gcc 3.0.x are ruled out for the time being.

ruby_1.6.6-5 is in sid (which will always be unstable)

Depending on how invasive the fix is, I suppose the ruby maintainer
could port the fix back to ruby 1.6.6-5, and thereby fix all these
ruby-dependants.  Akira?

lamont

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[Luigi B. <bal...@ma...>]

At 7:49 AM -0600 2/15/02, Dirk Eddelbuettel wrote:
>On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
>>  At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
>>  >Here is another g++-3.0 bug report regarding quantlib, or in particular the
>  > >Ruby bindings. I'd appreciate any comments. Luigi?

Ok, here's the final word from the Ruby gurus.

It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
done in the Ruby development branch (Ruby 1.7.something) but not in 
the current release (or at least not the one in Woody. I don't know 
which version of Ruby you have in... wait, what was the name of the 
character now? Well, unstable anyway)
It also needs a minor fix in SWIG which has been done in CVS but 
wasn't released either.

The bottom line is, we're out in the cold :(
Architectures with gcc 3.0.x are ruled out for the time being.

Sorry,
	Luigi

-- 

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[LaMont J. <la...@hp...>]

> IIRC, no. On ia64 we can choose between 2.95.* and 3.0.* but for a reason I
> always forget we prefer 3.0.*.

Minor nit: ia64 requires 2.96, not 2.95.

> On the hppa architecture, however, only 3.0.* is supported. 2.95.* simply
> does not exist.

Re: Bug#133913: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[LaMont J. <la...@hp...>]

> In the meantime, would it be possible to compile with 2.95.x on hppa?

hppa is not supported in gcc 2.x, gcc 3.0 is required.

lamont

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[Dirk E. <ed...@de...>]

On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
> At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
> >Here is another g++-3.0 bug report regarding quantlib, or in particular the
> >Ruby bindings. I'd appreciate any comments. Luigi?
> 
> Ouch.
> It's not just an hppa problem. It seems like SWIG/Ruby bindings have a big 
> problem with g++ 3.0 - I just reproduced it on i386. Unfortunately it's not 
> our code---it's either the Ruby API or the SWIG-generated wrappers. I just 
> sent a mail to the relevant mailing lists to ask for insight. We'll see.
> 
> In the meantime, would it be possible to compile with 2.95.x on hppa?

IIRC, no. On ia64 we can choose between 2.95.* and 3.0.* but for a reason I
always forget we prefer 3.0.*.

On the hppa architecture, however, only 3.0.* is supported. 2.95.* simply
does not exist.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[Luigi B. <bal...@ma...>]

At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
>Here is another g++-3.0 bug report regarding quantlib, or in particular the
>Ruby bindings. I'd appreciate any comments. Luigi?

Ouch.
It's not just an hppa problem. It seems like SWIG/Ruby bindings have a big 
problem with g++ 3.0 - I just reproduced it on i386. Unfortunately it's not 
our code---it's either the Ruby API or the SWIG-generated wrappers. I just 
sent a mail to the relevant mailing lists to ask for insight. We'll see.

In the meantime, would it be possible to compile with 2.95.x on hppa?

Bye,
         Luigi

P.S. Dirk: I sent my public key to James Troup for access to sarti about 10 
days ago, but I didn't have any answer. Could you check the thing? Thanks

[Quantlib-dev] [Debian Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)]

[Dirk E. <ed...@de...>]

Folks,

Here is another g++-3.0 bug report regarding quantlib, or in particular the
Ruby bindings. I'd appreciate any comments. Luigi?

Dirk

----- Forwarded message from LaMont Jones <la...@sm...> -----

Envelope-to: ed...@ed...
Delivery-date: Thu, 14 Feb 2002 10:33:09 -0600
Subject: Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)
Reply-To: LaMont Jones <la...@sm...>, 13...@bu...
From: LaMont Jones <la...@sm...>
To: su...@bu...

Package: quantlib-ruby
Version: 0.2.1cvs20020120-2
Severity: important

Build fails due to g++ 3.0 errors.  Full build log at:
    http://buildd.debian.org/fetch.php?&pkg=quantlib-ruby&ver=0.2.1cvs20020120-2&arch=hppa&stamp=1011978461&file=log&as=raw

g++ -fPIC -g -O2 -fPIC  -DHAVE_CONFIG_H -I. -I/usr/lib/ruby/1.6/hppa-linux -I. -I/usr/include    -I/usr/local/include -c -o quantlib_wrap.o quantlib_wrap.cpp
quantlib_wrap.cpp: In function `void Init_QuantLibc()':
quantlib_wrap.cpp:18130: cannot convert `VALUE (*)(...)' to `VALUE (*)()' for 
   argument `3' to `void rb_define_singleton_method(long unsigned int, const 
   char*, VALUE (*)(), int)'
...

-- System Information
Debian Release: 3.0
Kernel Version: Linux smallone 2.4.17-64 #1 Wed Jan 30 00:23:46 MST 2002 parisc64 unknown



----- End forwarded message -----

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

[Quantlib-dev] More quantlib-python failures on non-i386

[Dirk E. <ed...@de...>]

You might recall that Luigi debugged QL-Python on alpha.  Lots of other
architectures are still ailing, though.  As

	http://buildd.debian.org/build.php?&pkg=quantlib-python

shows, we currently fail on alpha, hppa, ia64, arm, m68k. As I read the build
logs, a quick summary is

alpha   wrong (0.2.1, not 0.2.1cvs) library installed, not attempted
hppa    needs -ffunction-sections compiler switch [ see below ]
ia64    some compiler warnings, survives few tests, then fails distributions
arm	too small a machine, aborts after 150 mins thinking it failed
m68k    idem, too small / too little memory to cope with the complex C++

I should get the alpha to attempt a recompilation [ though we currently have
hardware problems with our main Alpha box ], and get the timeout increased
for arm and m68k. [1]  That would leave hppa and ia64.  

I actually modified the build script for hppa earlier to add the
"-ffunction-sections" switch for gcc. It now builds, but then fails a few
tests (details below in [2]).  This is based on on the 0.3.0a5 branch from
CVS which I called 0.2.1cvs20020120 [ Debian needs to sort the version nb ]

Luigi: James Troup, who acts as Debian sysadmin for this hppa box, could
create an account for you if you send him your ssh public key.  Could you do
that, and then try to squash the bug there?

Cheers,  Dirk


[1] Or simply prevent it from being built, but that is considered sacrilege
within Debian as everything ought to build everywhere, something I personally
disagree with.

[2] On hppa, the following tests all fail:
american_option.py
barrier_option.py
binary_option.py
cliquet_option.py
distributions.py
european_with_dividends.py
finite_difference_european.py
forwardspreadedcurve.py
implied_volatility.py
montecarlo_pricers.py
old_european_option.py
old_implied_volatility.py
piecewiseflatforward.py
segmentintegral.py
swap.py

Whereas these work fine:
complexmarketelements.py
date.py
daycounters.py
european_option.py
get_covariance.py
mcmultifactorpricers.py
random_generators.py
risk_statistics.py
statistics.py

-- 
Good judgment comes from experience; experience comes from bad judgment. 
							    -- F. Brooks