Issue building latest Rblpapi on Windows 64

[joel23888]

I just pulled the latest Rblpapi and tried to build on Windows 64, with the following errors:

'versionIdentifier' is not a member of 'BloombergLP::blpapi::VersionInfo'
'headerVersion' is not a member of 'BloombergLP::blpapi::VersionInfo'
'runtimeVersion' is not a member of 'BloombergLP::blpapi::VersionInfo'

I can still build from an old commit (fc07aca) without issues.

I checked the Windows 64 header files in https://github.com/Rblp/blp/tree/master/win64 and these member functions are not in blpapi_versioninfo.h. @eddelbuettel would you mind updating them, or let me know how I could attempt this?

I did try manually updating these files locally by copying in the headers/DLL from v3.8.18.1 (https://bloomberg.bintray.com/BLPAPI-Stable-Generic/blpapi_cpp_3.8.18.1-windows.zip) but encountered some more errors (happy to paste them in here if relevant).

[eddelbuettel]

About to hit the sack here -- see this file and if the symbols are really missing for your build and headers we may have to #ifdef this.

[eddelbuettel]

Looks like then Windows header file is 3.7.9.1. Maybe we need to update.

As you actually are on Windows, could you run some local tests?

[joel23888]

Yes, happy to help.

[eddelbuettel]

Great. Ball in my court, and I will try to bring the windows headers and tarball forward to at least 3.8.8.1 to match the other side.

[eddelbuettel]

Done with this commit so if you try to rebuild from a clean directory (so that the headers tarball gets downloaded again) you should be good. I will try win-builder as well.

[eddelbuettel]

And it appears to fail. Damn.

[joel23888]

Thank you for updating this. I will have to wait until Monday to try building this on Windows (if that will make a difference).

[eddelbuettel]

Well it looks like I just broke it. I will have to revert the recent commit to the blp repo.

[eddelbuettel]

Ok @joel23888 -- new branch, new pull request and even new dev version tarball 0.3.3.3 in this drat repo.

It once again builds on Windows -- so thanks for the bug report. That was really helpful.

Turns out that Windows headers appear to be behind, but moving them forward creates a new impasse with long long. If you could help with working towards a new header and library tarball / zipfile I would really appreciate it.

[eddelbuettel]

Bah. Had the wrong close tag in the PR. #164 just closed this, with thanks to @armstrtw for merging.

[joel23888]

I can confirm the latest Rblpapi built correctly on my Windows 7 PC:

> library(Rblpapi)
Rblpapi version 0.3.3.3 using Blpapi headers 3.7.9.1 and run-time 3.8.8.1.
Please respect the Bloomberg licensing agreement and terms of service.
> blpConnect()
> bdh("SPX Index", "PX_LAST", as.Date("2016-04-14"))
as.Date("2016-04-14"))
        date PX_LAST
1 2016-04-14 2082.78
2 2016-04-15 2080.73

I am happy to help with work towards a new header and library tarball/zipfile. I am tied up on other projects this week, when were you thinking of getting this done by @eddelbuettel?

[eddelbuettel]

I was hoping to get it done sooner -- but we may as well pivot and release an update first and then deal with this.

[joel23888]

Following from my previous comment, I then replaced the v3.7.9.1 Windows headers with v.3.8.18.1 and rebuilt with several errors, all seemingly related to a type mismatch. The first two errors are:

../inst/include/blpapi_timepoint.h:117:12: error: operands to ?: have different types 'long long int (*)(const blpapi_TimePoint_t*, const blpapi_TimePoint_t*) {aka long long int (*)(const blpapi_TimePoint*, const blpapi_TimePoint*)}' and 'int'

and

../inst/include/blpapi_datetime.h:2063:5: error: operands to ?: have different types 'int (*)(blpapi_HighPrecisionDatetime_t*, const blpapi_TimePoint_t*, short int) {aka int (*)(blpapi_HighPrecisionDatetime_tag*, const blpapi_TimePoint*, short int)}' and 'int'

It seems this is not a long long problem per se, but related to BBG's use of the ?: operator. Should we raise this to BBG or is there something we can change in Rblpapi's code?

[eddelbuettel]

It may have to do with us using MinGW on Windows whereas they may only see Visual Studio.

Do you have a way to escalate this? If so I'd really appreciate it. Not sure whom I would talk to besides @wmorgan85 ...

[eddelbuettel]

Something goes amiss with the BLPAPI_CALL_actual_function_here macros but I don't see how to fix.

So with that it is the old headers I fear...

[wmorgan85]

I'll have a chat with the development support team in the morning.
@joel23888 did you get a reference when you spoke with the helpdesk before?
I can try and trace down where it went and who might have been involved.

On Mon, 18 Apr 2016 at 18:45 Dirk Eddelbuettel [email protected]
wrote:

Something goes amiss with the BLPAPI_CALL_actual_function_here macros but
I don't see how to fix.

So with that it is the old headers I fear...

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#164 (comment)

[joel23888]

I manually traced through the first error and can see the likely reason why it is happening. I will point out the code later (mobile now).

@wmorgan85 I have not raised this one with BBG yet (raised #163 this other day).

[joel23888]

For the first error:

../inst/include/blpapi_timepoint.h:117:12: error: operands to ?: have different types 'long long int (*)(const blpapi_TimePoint_t*, const blpapi_TimePoint_t*) {aka long long int (*)(const blpapi_TimePoint*, const blpapi_TimePoint*)}' and 'int'

Here is a (manual) trace from the error through the macro layers:

blpapi_timepoint.h:114-118:

long long TimePointUtil::nanosecondsBetween(const TimePoint& start,
                                            const TimePoint& end)
{
    return BLPAPI_CALL_TIMEPOINTUTIL_NANOSECONDSBETWEEN(&start, &end);
}

blpapi_call.h:289-90:

#define BLPAPI_CALL_TIMEPOINTUTIL_NANOSECONDSBETWEEN(a1, a2)                  \
    (BLPAPI_TABLE_CALL(blpapi_TimePointUtil_nanosecondsBetween)(a1, a2))

blpapi_call.h:44-47:

#define BLPAPI_TABLE_CALL(FUNCNAME)                                           \
    (BLPAPI_TABLE_CHECK(FUNCNAME)                                             \
        ? (g_blpapiFunctionEntries.FUNCNAME)                                  \
        : BLPAPI_UNSUPPORTED_CALL(FUNCNAME))

blpapi_call.h:52-53:

#define BLPAPI_UNSUPPORTED_CALL(FUNCNAME)                                     \
    (throw UnsupportedOperationException(#FUNCNAME " not supported"), 0)

In the extract from blpapi_call.h:52-53, removing that 0 at the end actually stops the compiler throwing the first three errors, presumably because it is no longer returning int when the conditional operator is expecting another type such as long long.

[eddelbuettel]

Nice work! We could possibly overcome the error by redefining the macros if on Windows.

[joel23888]

Yes, I think for that one we can try redefining BLPAPI_UNSUPPORTED_CALL if on Windows. There would still be two errors, I will follow up on these later. They also appear to be type mismatches.

[joel23888]

Here are the two remaining errors:

In file included from ../inst/include/blpapi_session.h:65:0,
                 from authenticate.cpp:25:
../inst/include/blpapi_sessionoptions.h: In member function 'void BloombergLP::blpapi::SessionOptions::setMaxEventQueueSize(size_t)':
../inst/include/blpapi_sessionoptions.h:725:5: error: second operand to the conditional operator is of type 'void', but the third operand is neither a throw-expression nor of type 'void'

../inst/include/blpapi_sessionoptions.h: In member function 'void BloombergLP::blpapi::SessionOptions::setRecordSubscriptionDataReceiveTimes(bool)':
../inst/include/blpapi_sessionoptions.h:776:5: error: second operand to the conditional operator is of type 'void', but the third operand is neither a throw-expression nor of type 'void'

Tracing the first error manually:

blpapi_sessionoptions.h:723-728:

void SessionOptions::setMaxEventQueueSize(size_t eventQueueSize)
{
    BLPAPI_CALL_SESSIONOPTIONS_SETMAXEVENTQUEUESIZE(
            d_handle_p,
            eventQueueSize);
}

blpapi_call.h:73-77

#define BLPAPI_CALL_SESSIONOPTIONS_SETMAXEVENTQUEUESIZE(a1, a2)               \
    (BLPAPI_TABLE_CHECK(blpapi_SessionOptions_setMaxEventQueueSize)           \
    ? g_blpapiFunctionEntries.                                                \
                      blpapi_SessionOptions_setMaxEventQueueSize(a1, a2)      \
    : 0)

In the extract blpapi_call.h:73-77 for the first error (and in blpapi_call.h:274-280 for the second error) changing that 0 at the end to (void) 0 actually stops the compiler throwing these errors, because the conditional operator now returns type void in both cases.

I can now get Rblpapi to build on Win64 by making the above two edits:

Restarting R session...

> library(Rblpapi)
Rblpapi version 0.3.3.3 using Blpapi headers 3.8.18.1 and run-time 3.8.8.1.
Please respect the Bloomberg licensing agreement and terms of service.
> blpConnect()
> bdh("SPX Index", "PX_LAST", as.Date("2016-04-18"), as.Date("2016-04-18"))
        date PX_LAST
1 2016-04-18 2094.34
> 

What is the best way to proceed here? While redefining the macros as implied from my comments lets us build Rblpapi on Win64 now, from a cursory look through BBG's header files we will possibly encounter similar issues later depending on which features of the BBG API we use or other conditions.

Maybe we should redefine these macros to get it working, and raise to BBG as well?

[eddelbuettel]

Yes, my thought would be to either alter blpapi_utils.h or to create a new file Rblapi.h with the include for Rcpp.h. That would then also be one place to redefine these macros. If we include the file last, we should be able to work around this.

And of course we can (should ?) also talk to Bloomberg to see if/how they might fix this at their side.

[joel23888]

I tend to prefer the Rblpapi.h idea to centralize any of these changes now or in the future.

I am happy to raise this with BBG to see if there is any chance of a fix on their side.

[wmorgan85]

Hey guys, update from my side. I have sent this issue link over to the
developers internally. They should come back to me tomorrow.

On Tue, 19 Apr 2016 at 12:08 joel23888 [email protected] wrote:

I tend to prefer the Rblpapi.h idea to centralize any of these changes now
or in the future.

I am happy to raise this with BBG to see if there is any chance of a fix
on their side.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#164 (comment)

[joel23888]

OK, thanks. If I need to raise it let me know and I'll do so.

[joel23888]

From my perspective, I am happy to do some coding on this. However, as I said before I am tied up on other projects at the moment.

[eddelbuettel]

Great -- would be happy to work with you on this.

So how about the following:

• Rblpapi 0.3.4 has been mostly ready; we wrap up what we have now and ship
• things to address in the next cycle include
  • this header/library update, particularly on Windows
  • the other current issue bdh function: include.non.trading.days not working in conjunction with other options. #167
  • whatever else needs fixing :)

and we get to that for 0.3.5.

Deal?

[joel23888]

Yes, happy to help on that first one and any others, time permitting.

[Dhiraj96]

@joel23888 Just started playing with the API today and had a lot of issues getting it up and running. Thank you so much for this information and saving me long, hard sweat-filled hours grinding my teeth!

[eddelbuettel]

@Dhiraj96 In case you were unaware there are binaries at CRAN