ruby wrapper issues

[mrtreibe]

Two quick questions about the ruby compilation.

1). When I'm compiling the ruby wrapper under darwin I get a lot of
warnings like:

rwin -I.  -I/sw/include -I/sw/include -Wno-uninitialized -Wno-
unused-function  -c quantlib_wrap.cpp
In file included from /sw/include/ql/qldefines.hpp:54,
                  from /sw/include/ql/quantlib.hpp:22,
                  from quantlib_wrap.cpp:909:
/sw/include/ql/config.hpp:101:1: warning:
"PACKAGE_BUGREPORT" redefined

where "PACKAGE_BUGREPORT" is defined in ruby.h but set to "".  I'm
assuming this is normal right?  Will this affect ruby in any way?

2). When "setup.rb install" is passed --prefix, the wrapper is
installed in the ruby lib directory (with the new prefix) but when the
--prefix is excluded, the wrapper is installed into the ruby site lib
directory.  I'm assuming this is a bug so I made a quick patch (made
against the current cvs version) to correct this so that when --prefix
is passed, the wrapper is installed into the site lib directory.  
(although I probably made the diff incorrectly since I really don't
know cvs' diff command)

Mark.

[Luigi Ballabio-2]

On 2004.05.21 04:16, Mark Treiber wrote:
> Two quick questions about the ruby compilation.

And two much less quick answers. My apologies.

> 1). When I'm compiling the ruby wrapper under darwin I get a lot of  
> warnings like:
>
> /sw/include/ql/config.hpp:101:1: warning:
> "PACKAGE_BUGREPORT" redefined
>
> where "PACKAGE_BUGREPORT" is defined in ruby.h but set to "".  I'm  
> assuming this is normal right?  Will this affect ruby in any way?

It's ok. The macro is defined by autoconf, which I guess is used by  
both Ruby and QuantLib. There's no harm in redefining it.

> 2). When "setup.rb install" is passed --prefix, the wrapper is  
> installed in the ruby lib directory (with the new prefix) but when  
> the --prefix is excluded, the wrapper is installed into the ruby site  
> lib directory.

Oh, yes, I remember. The asymmetry was introduced by me in order to  
make the life easier for the Debian maintainer, who wanted the module  
to be installed in the ruby lib. It's fixed now---and Dirk, if you're  
reading this, from now on you'll have to install by using

ruby setup.rb install --prefix=/whatever --debian

If --debian is not used, the "correct" behavior (that is, that  
suggested by Mark) is triggered.

Thanks,
        Luigi

[Dirk Eddelbuettel]

On Wed, May 26, 2004 at 05:25:58PM +0200, Luigi Ballabio wrote:
> to be installed in the ruby lib. It's fixed now---and Dirk, if you're  
> reading this, from now on you'll have to install by using
>
> ruby setup.rb install --prefix=/whatever --debian
>
> If --debian is not used, the "correct" behavior (that is, that  
> suggested by Mark) is triggered.

Got it -- debian/rules edited accordingly.

Thanks as always for being so accomdating!

[ OT: I was at useR! 2004 last week, where I had helped to put some Finance
content together. Lots of visibility of QL, and in particular the fellow who
did www.rmetrics.org (which we will make Unix/Linux compatible, currently
Windoze only) is quite interested and aware of QL.  Not sure how reciprocal
that can get from the QL community as R is presumably seen as a bit of
fringe language. For empirically minded souls, the R system is heavenly...
But I digress :) ]

Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[Luigi Ballabio-2]

On 2004.05.26 17:42, Dirk Eddelbuettel wrote:
> > If --debian is not used, the "correct" behavior (that is, that
> > suggested by Mark) is triggered.
>
> Got it -- debian/rules edited accordingly.
>
> Thanks as always for being so accomdating!

You're welcome.

> [ OT: I was at useR! 2004 last week, where I had helped to put some
> Finance content together. Lots of visibility of QL, and in particular  
> the fellow who did www.rmetrics.org (which we will make Unix/Linux  
> compatible, currently Windoze only) is quite interested and aware of  
> QL.  Not sure how reciprocal that can get from the QL community as R  
> is presumably seen as a bit of fringe language. For empirically  
> minded souls, the R system is heavenly...
> But I digress :) ]

Cool. R is on the long list of things I'd like to take a good look at  
if I had time...

Later,
        Luigi

[Ferdinando M. Ametrano-3]

Hi Dirk,

>[ OT: I was at useR! 2004 last week, where I had helped to put some Finance
>content together. Lots of visibility of QL, and in particular the fellow who
>did www.rmetrics.org (which we will make Unix/Linux compatible, currently
>Windoze only) is quite interested and aware of QL.  Not sure how reciprocal
>that can get from the QL community as R is presumably seen as a bit of
>fringe language. For empirically minded souls, the R system is heavenly...
>But I digress :) ]

a quite interesting digression.

Next week I will take charge of a new project for my employer. The project
is aimed to developing an implementation of the Black-Litterman asset
allocation model (and more). I will work with Hannu Kahra, an associate
professor from Finland: he should lead the modeling and he plans to use R.
[I'm CC'ing him, but he will access his mailbox next Tuesday]

While I'm not sure if my employer will allow us to do the project as
free-software/open-source, I'm quite sure there will be some positive fall out.

What is worrying me these days is that both Rmetrics and RQuantLib are GPL:
one of the project's goal is to be able to re-distribute our work so this
might rule out the usage of these GNU packages unless my company accept a
GPL approach.

It would be too good to leverage QuantLib/RQuantLib/Rmetrics for this
project and contribute to them. Throw in the chance RiskMap/StatPro would
join the effort open-sourcing its asset allocation code base...

Too good to be true.

ciao -- Nando