Login Page - Create Account

Support Board


Date/Time: Fri, 29 Mar 2024 14:06:51 +0000



[Locked] - Version 2151 Available: Foundation For Millisecond/Microsecond Timestamping

View Count: 12117

[2020-08-12 06:21:12]
Sierra_Chart Engineering - Posts: 13625
We have released version 2151 which contains a completely new implementation of the SCDateTime class within Sierra Chart which uses an integer rather than a double for the storage of Date-Time values.

This new implementation allows precise representation of microsecond timestamps without any floating-point error.

The epoch of this is not the standard UNIX epoch. It remains as December 31, 1899 so as to not cause confusion and potential issues with conversions between the old double format and the new integer format.


This version does not yet support true millisecond time stamping. We want to get this version out and ensure that there are no problems and then we will begin the changes to support millisecond time stamping and update all of our market data infrastructure. This second part should not take more than two weeks, once we begin which may not be for about 10 days or so.

Although extensive testing has already been done by us. We do not anticipate any issues.

We finally have gotten this major step completed.

You can install this version by following the procedure here:
Software Download: Fast Update

As of this writing, the current version is now 2156. So the current version now supports the updated date-time functionality.


The most important thing to understand is that this version breaks compatibility with existing compiled custom studies. Custom studies have to be rebuilt on 2155 or higher to use them with 2155 or higher. Although the change occurred at version 2151, there were subsequent changes and now ACSIL custom studies have to be recompiled using Sierra Chart version 2155 or higher.

This is nothing more than a simple recompile. Instructions:
How to Build an Advanced Custom Study from Source Code

However, this thread documents changes that may need to be made to a custom study:
Required SCDateTime Changes for ACSIL

If you have the source code for your custom studies you can do the recompile yourself. If you do not have the source code, then you need to contact the developer of the custom studies and ask them to recompile them on version 2155 or higher.

If you are providing custom studies to other users or you want to have two versions of your custom studies file supporting both 2151 and higher and 2148 and earlier, we have developed an easy strategy to support this.

The strategy to support this is that custom studies files that support 2151 or higher need to have this file format name:
[custom study file name]_2151.dll (32-bit)
[custom study file name]_2151_64.dll (64-bit)


The above format has been changed in version 2152 and now includes an _ character before the version number. Be sure to use the new above format.

This naming format is optional. It is not required.

Custom studies that support version 2148 and earlier just have the standard naming format without "_2151" in the filename.

----
If you are a custom studies developer providing studies to other users, then be sure to install this version and rebuild your custom studies and use _2151 in the file name (as shown above) and upload them here:
https://www.sierrachart.com/UserControlPanel.php?page=SetFileGroupsForCustomStudies

You will need to manually change the file name, _2151 is not going to be automatically added.

----

When updating to this version or higher it is a good idea that you are already running version 2110 or higher. If you go back to a prior version you will need to go back to a version greater or equal to 2110 because Date-Time values will be written as integers to files and you need that version or later for Sierra Chart to be able to read integer Date-Time values.

----

Finally we want to say that while this is very long overdue it did take a lot of work to make all the necessary changes in Sierra Chart and go through the testing especially with our very busy schedule, to support the new SCDateTime class which uses an integer.

The integer based class provides very stable and consistent Date-Time calculations and comparisons unlike when working with a double. Once we start getting into the microsecond resolution, we start running into issues and that was why it was difficult for us all of this time to support the true milliseconds which also required microsecond resolution in order to ensure there is always a unique timestamp per trade.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-25 06:12:47
[2020-08-12 20:56:32]
jomanos - Posts: 27
To be clear, if I have custom studies from third-party commercial developers, I will need to wait until they recompile their studies for 2149 and above, before installing any new release past 2148. Correct?

Thanks.
[2020-08-12 21:18:37]
Sierra Chart Engineering - Posts: 104368
Yes.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2020-08-12 22:58:38]
Sierra Chart Engineering - Posts: 104368
This version is now available as the main prerelease. So to update to this version simply use Help >> Download Prerelease:
Software Download: Fast Update
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-12 22:59:00
[2020-08-13 05:24:00]
Sierra Chart Engineering - Posts: 104368
We have released version 2150 as the main release but it does not include what we described in the first post. This is still only part of version 2149.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2020-08-13 06:32:46]
Ackin - Posts: 1863
We have released version 2150 as the main release but it does not include what we described in the first post. This is still only part of version 2149.

Could you please tell us in advance the time assumption of the next main release that will contain both (2149 + 2150)?
[2020-08-13 10:46:24]
Sierra Chart Engineering - Posts: 104368
We will do this tomorrow. We will release 2151 as the prerelease.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-13 10:46:56
[2020-08-13 11:53:13]
binaryduke - Posts: 351
We have just recompiled some custom studies against v2149 and tested with the new naming format:
[custom study file name]2149.dll (32-bit)
[custom study file name]2149_64.dll (64-bit)

The presence of files with these names in the /data folder causes Sierra Chart to unexpectedly exit while trying to Add Custom Study workflow. When the '2149' files are removed from the /data folder, there is no problem and the custom studies compiled with an earlier version are listed just fine (with a warning that they need to be recompiled).

For reference, the test custom study files were compiled using Visual Studio pulling in the v2149 sierrachart.h - compilation with Visual Studio is necessary for these files as they have external references, resources, etc., that cannot be handled by the remote compilation approach.
[2020-08-13 17:36:27]
Sierra Chart Engineering - Posts: 104368
Can you please privately attach these DLL files here and we will test. We do not know why there would be a problem like this. It does not make sense to us at all.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-13 17:36:34
[2020-08-13 17:46:46]
binaryduke - Posts: 351
Attached as requested. Perhaps because the original DLL name ends with a digit?
Private File
Private File
Attachment Deleted.
[2020-08-13 19:00:22]
Sierra Chart Engineering - Posts: 104368
There is a heap corruption occurring:
Critical error detected c0000374

We do not know why. We tested this kind of configuration using user contributed studies and there was not a problem. We had two versions of user contributed studies. One of them using this naming format:
[custom study file name]2149_64.dll (64-bit)
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-13 19:00:35
[2020-08-13 19:13:22]
binaryduke - Posts: 351
OK. What code in a custom study is called during the directory scan? Should I check something?
[2020-08-13 21:07:19]
Sierra Chart Engineering - Posts: 104368
Every study function is called with sc.SetDefaults set to 1 to find out the names.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-13 21:07:26
[2020-08-13 21:31:39]
Sierra Chart Engineering - Posts: 104368
Due to the fact, that we have released version 2050 as the main release and this prerelease is 2149, we now have set the starting version number for the integer based SCDateTime class, to be 2151 now. So the file names need to use that version. We apologize for this.

2151 is now available.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2020-08-14 06:55:48]
Ackin - Posts: 1863
This change only affects user studies. I see. May I ask what will be the compatibility with lower versions from the point of view saved collections and saved charts (when using the original Sierrachart studies)? Version 2093 caused problems for many SCH users.
Date Time Of Last Edit: 2020-08-14 06:59:26
[2020-08-14 07:17:17]
Sierra Chart Engineering - Posts: 104368
Saved Study Collections and saved Chartbooks from older versions are not affected by this change. Older versions are still fully compatible.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2020-08-14 07:22:33]
binaryduke - Posts: 351
Please can I 100% clarify post #16...

if a Study Collection references a Custom Study named "ABCDE",
...the platform will automatically determine whether to use the pre-/post-2151 version of this study if ABCDE.dll and ABCDE2151.dll (and their 64-bit equivalents) are present in the /data folder
...and therefore no change to the Study Collection is required?
[2020-08-14 08:18:46]
Ackin - Posts: 1863
to binaryduke)

Exactly the same thing interests me (my prior post). We have a large number of collections and saved charts on my forum. Any change and re-storage of all material is very time consuming.
[2020-08-14 09:47:46]
Sierra Chart Engineering - Posts: 104368
In response to post #17, yes, this is all automatic. Sierra Chart will know what DLL to use. This has been carefully thought through and also tested.

However, if someone updates to 2151 or higher and adds new instances of a custom study and then goes back to a prior version before 2149, then there potentially there can be a problem.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-14 09:49:01
[2020-08-15 11:05:57]
Sierra Chart Engineering - Posts: 104368
Update: We are underway, with the remaining work to support millisecond/microsecond time stamping.

So far no issues.

We do want to make one additional SierraChart.h header change related to strings which will require custom studies to be recompiled. This will be out we expect in 2152 but the DLL file naming will still remain the same.

This is a rare opportunity for us to improve the SierraChart.h header. So we want to take advantage of reasonable things we can do to clean up the header and improve performance.

The most significant performance improvement would be for us to remove most of the data members and just replace them with functions and to the extent that can be done without breaking any compatibility, we will do that.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2020-08-15 11:08:51
[2020-08-15 14:55:19]
binaryduke - Posts: 351
Triggered by post #20, we have been testing as regards our post #8.

Our studies create their inputs and subgraphs from core routines that are called during SetDefaults based upon the requirements of each study. This is to avoid duplication of code as we have many common Inputs and Subgraphs used by various studies.

We have noticed that we are getting exception errors during the assignment of an SCString (that we create) to a subgraph, e.g.


SCString ExampleName;
SCString ExampleSuffix;
int VariableNumber;

VariableNumber = 3;
ExampleSuffix = " Example";
ExampleName.Format("Subgraph %i %s", VariableNumber, ExampleSuffix.GetChars());

sc.Subgraph[0].Name = ExampleName;

This style causes an exception error. The Call Stack lists:

SCString::StringDelete(chart * String) Line 766
there seems to be an issue with m_DefaultString <Error reading characters of string.>

SCString::Initialize() Line 280

This style/functionality has been working fine prior to v2149/v2151. Should we await v2152?

As an aside, we do NOT use contiguous members of the sc.Subgraph array, e.g. we may use 0,1,2,3,4,58,59. We had an issue with this approach and the sc.Input array that we discussed with you here:
Strange behaviour when populating sc.Input array
and here:
Custom Studies has issue on windows 10 (post #24 relating to changes to the DisplayOrder member)
and modified our approach accordingly.

While I see that our use of non-contiguous members of the sc.Subgraph array could be causing the problem, the exception errors occur on the first call to our routine i.e. when populating sc.Subgraph[0]. We have also tested using contiguous members of the sc.Subgraph array by inserting code prior that sets the DrawStyle of all available subgraphs so that each member of the sc.Subgraph array is populated.
[2020-08-15 15:32:08]
binaryduke - Posts: 351
Further to #21, it seems anything we do now with strings during sc.SetDefaults for the sc.Input and sc.Subgraph array causes an exception error, e.g. sc.Input[1].SetCustomInuptStrings("ABC;DEF");

In Visual Studio we have the project character set as Unicode which has been fine up until now. Has something changed here?

...and running using the Visual Studio debugger does not produce any exception errors - we have a heisenbug here
Date Time Of Last Edit: 2020-08-15 16:02:00
[2020-08-15 23:23:15]
Sierra_Chart Engineering - Posts: 13625
Regarding post #21 and #22, there is no reason why there would be a problem. Nothing has changed in regards to ACSIL SCString or anything related up to this point with string processing and ACSIL or any string processing for that matter.

We cannot identify any problem in a debug or release build using Visual C++. What compiler are you using? Visual C++?
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
[2020-08-16 01:17:57]
Sierra Chart Engineering - Posts: 104368
One thing we are going to make sure of is when the same DLL is loaded but with two different names, related to the version number, that they are pointing to the same loaded DLL instance.

Perhaps the issue is related to there being two instances of the same DLL loaded.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service:
Sierra Chart Teton Futures Order Routing
[2020-08-16 11:02:57]
binaryduke - Posts: 351
I have a simple custom study that compares the current bar date/time to session times and also stores the last processed date/time value in PersistentSCDateTime variable.

This compiles and works just fine on v2138.

Compiling the same study on v2151 provides the following error during remote compilation:


-- Starting remote build of Custom Studies Source files: DATETIMESTUDY.cpp. 64-bit -- 11:54:42
Allow time for the server to compile the files and build the DLL.

The remote build did not succeed. Result:

In file included from scstructures.h:98:0,
from sierrachart.h:22,
from DATETIMESTUDY.cpp:1:
scdatetime.h: In function 'constexpr int64_t ADJUST(int64_t, int64_t)':
scdatetime.h:147:1: error: body of constexpr function 'constexpr int64_t ADJUST(int64_t, int64_t)' not a return-statement
}

^
scdatetime.h: In function 'constexpr double ADJUST(double, double)':
scdatetime.h:156:1: error: body of constexpr function 'constexpr double ADJUST(double, double)' not a return-statement
}

^

-- End of Build -- 11:54:44

Date Time Of Last Edit: 2020-08-16 11:03:42

To post a message in this thread, you need to log in with your Sierra Chart account:

Login

Login Page - Create Account