GetHistory-from-streaming-chart

It probably does just the same as in a static chart.

That means WL7 doesn't offer a mechanism to access other symbol's current bar value?

What is the "current" bar - do you mean the partial bar (incomplete, "ghost" bar) which is not accessible in WL7?

I mean the complete bar value of another symbol in the streaming chart.

Can't see a reason why "yesterday's" bar (the last complete bar) of any instrument wouldn't be accessible in WL7 via GetHistory.

I'm talking about intra-day streaming chart (e.g. 1 Minute scale).

Does calling GetHistory access the last complete bar (e.g. the chart symbol just completed the last bar 100ms ago) of another symbol?

yes, it should result in a historical request for that data, which should return the most current data depending on the availability of that historical data at the server.

That means calling GetHistory from intra-day streaming chart would result several seconds delay due to the round-trip data request to the server?

In WL6.9, SetContext and GetExternalSymbol doesn't request data at the server but it comes from the local historical data, thus the bar data is delayed.

WL7's GetHistory actually requests a data to the server?

Does streaming data in Strategy Monitor expedite accessing the external symbol's bar data?

For example, a window streaming SPY at 1-minute scale. At the same time, a strategy in Strategy Monitor streaming DIA at 1-minute scale. When the window streaming SPY calls GetHistory("DIA"), it will return the "just completed" bar data faster with the strategy in Strategy Monitor streaming DIA than without the strategy in Strategy Monitor?

It should yes, because the new data has already been saved locally.

QUOTE:
It should yes, because the new data has already been saved locally.

That I thought in WL6.9 but it turned out WL6.9 gets the data from local without requesting new data to the server, thus the bar data for the external symbol gets one bar or two behind.

I was hoping WL7 has changed it for better.

I beg to differ with you. WL6.9 also generates a historic data request. The problem that we're going to run into again is that a streaming chart will create this request before the newest bar of data is available on a history server.

The workarounds were (and unfortunately still are) to delay the script a handful of seconds before requesting the secondary data, OR (better), stream the external symbol(s) in another script, update global memory with the latest bar, and retrieve it from a delay loop in the primary script.

Franky, I hate that this is still the case and wonder if Glitch can see a way to automate that delay loop workaround, streaming externally referenced symbols.

I'm open to suggestions. Adding what you describe, Robert, sounds klunky, and is it supposed to work with one symbol? What if you want to stream 10 external symbols, or 500?

QUOTE:
stream the external symbol(s) in another script, update global memory with the latest bar, and retrieve it from a delay loop in the primary script.

That's exactly I had to implement in my streaming strategy code.

QUOTE:
What if you want to stream 10 external symbols, or 500?

Other platform supports up to 50 symbols total so up to 49 external symbols per a streaming chart.

QUOTE:
What if you want to stream 10 external symbols, or 500?

IQFeed basic subscription supports 500 streams. IB supports 100.

The general use case, though, is pairs trading with one external symbol. That would be a good start, but also don't see why there need be a 1 external symbol limit.

It is not clear if there was a resolution on the discussion above?
I am still using wb6 workaround: stream the external symbols in SM and then utilize SetGlobal/GetGlobal for work around.

I thought of this solution:
Run a simple strategy before my main strategy to force external symbols to update:

CODE:
public override void BacktestBegin()
        {
                int time = DateTime.Now.Hour * 100 + DateTime.Now.Minute;
                if (time >= 0930 && time <= 1600)
                {
                    StrategyRunner sr = new StrategyRunner();
                    sr.DataSet = DataSetFactory.FindDataSet("Streamer");
                    sr.Scale = HistoryScale.Minute5;
                    sr.DataRange = new DataRange(DataRangeTypes.RecentDays, 2);
                    Backtester bt = sr.RunBacktest("Streamer");
                }
}

What do you think? bad or good work around?

I think it's a lot of overhead just get to the data for the last bar, and, it's likely to run into the same issue as requesting an external symbol from a history server before the bar is ready. I'd be more inclined to use one of the work-arounds - they work well once you have the process set up.

Probably we need a feature request and if it can gain some popularity, we might be able to dedicate resources to create a better solution.

I'm also using the scheme Cone outlined in #13

QUOTE:
The workarounds were (and unfortunately still are) to delay the script a handful of seconds before requesting the secondary data, OR (better), stream the external symbol(s) in another script, update global memory with the latest bar, and retrieve it from a delay loop in the primary script.

I'm using Iqfeed to stream about 200 symbols from the streaming script then set them to global memory then retrieve them from the primary script. I have a delay of approx 6 seconds in the primary script. Problem is the primary scripts' bar annotations (calculation results) are erratic. So, to be sure that the retrieving script has completed (successfully would be nice) before invoking the primary, is there a way to know when the retrieving script kicks off its Status = LoadingData event so I could block the primary until, say, the BacktestComplete() override completed? I can see no other way since the BacktestBegin() override doesn't start until Iqfeed has complete. Thanks

QUOTE:
is there a way to know when the retrieving script kicks off its Status = LoadingData

No.

Do we have a feature request for this yet?

For now, your receiving script should "spin" for at least 5 to 8 seconds looking for the update with the timestamp of the current bar. IQFeed will almost certainly have served the bar within 2 or 3 seconds after the end of interval.

I don't know what your application is, but the time out is needed because there's a chance that one (or some) of those symbols won't have traded for the interval. Your script could detect if that's the case and respond accordingly.

Feature requested.

The application looks for statistical clustering between symbols in the dataset.

I'm unclear as to how to determine the current bar has completed, does GetHistory provide that? How would I know from the primary script what symbols didn't complete in the streaming script?

QUOTE:
how to determine the current bar has completed, does GetHistory provide that?

Just save the timestamp of the bar with the data. Then it's easy to see if it's up-to-date with the timestamp of the last bar of the primary script.

Thanks