开云体育

> Oh wow, so this CMake builds a project with both pytorch and the TWS API in C++? Thank you so much Yes. You're very welcome. Just bear in mind that the process will be a little different for you

Juergen, your concern is certainly valid, I just meant to show how some limitations can be worked around. Admittedly, while LOC/MOC orders have their strong advantages and constitute perhaps some

Oh wow, so this CMake builds a project with both pytorch and the TWS API in C++? Thank you so much, if so. I will probably take the approach of making a whole new project with cmake then. I need to

Thanks Gordon for your detailed response.. I went off to test a few more things. Thought I post it here as it might be useful for others: 1) Getting VWAP from subscription of "reqRealTimeBars"

BTW, besides the symbolic links, here are the changes I needed to make to their _CMakeLists.txt_: ``` --- orig 2023-08-18 12:41:21.180000000 -0400 +++ CMakeLists.txt 2023-08-18 12:39:07.488000000

I think you're probably making a mountain out of a molehill. As Gordon suggests CMake offers a ton of options and LibTorch needs that power since it can be configured to use disparate and exotic

There are three ocaType options and only one of them allows MOC/MOO orders in the group. So I guess my concern is 67% valid :-) We don't use OCA groups a lot but when we do, (more) guaranteed overfill

You might want to check this post ( /g/twsapi/message/51396 ) and the topic for more information about the various market data connection messages. I don't want to repeat that post

Yes Out of scope of this forum Yes Cmake sound crazy as another language to generate a language to generate a language to interpret a language. But don't fight Cmake, it does exist because it's a pain

Ya I don't want to use Cmake if I don't have to. Especially, since I already have a fairly large project I built without it, which correctly implements the TWS C++ API. So, my problem is probably more

About Cmake: unfortunately allows to specify tons of option at generation time. You should look at linker error message and guess what could make Cmake happy. Cmake is only a "makefile" generator (or

I can only speculate. What was the file path of the log you show extract here ? Diag: There are various log avail (including the GW display windows but require a lot of time to be analyzed (Best is to

I've tried that section briefly to no avail, perhaps I will have to try again. I could try just mirroring the template project that link populates and copy the includes and linkers to my current TWS

Ok, thanks. Today I observed that it behaves like described. But yesterday it did not reactivate. The yesterdays client log contains this two times: id: 416904 | Error Code: 366 | Error Msg: No

I haven't worked with Windows in a while but I don't think using a library changes too much from platform to platform. So, anyway... I'd probably give

@Gonzalo Yes IMHO that's same issue (or non issue) a first call reactivate the connection as the message explain it. Once done and depending upon your TZ/Instrument TZ and RTH and ... your 'live'

Hi, I am trying to leverage Pytorch's C++ API with the TWS API in a single project. I have an existing project in Visual Studio that uses the TWS API. PyTorch for C++ really only supports a build

Hi, I’m not sure if it’s related. But I keep seen this warnings INFO:2023-08-17 15:38:03,286:Warning 2106, reqId -1: HMDS data farm connection is OK:ushmds.nj INFO:2023-08-17 15:39:26,379:Warning

I have a similar problem with losing IBGW connections at tick-by-tick data. The easiest way I found is to use the TWS API instead of the IBGW API. TWS seems to take care of a continuous connection,

1- no need, it happens on first call. Make a dummy APPL historical and 'voila' 2- see above. Understand that a service provider dislike having open connection doing nothing, so after a certain