+1 888 340 6572
MultiCharts Project Management
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
feature_request_small.png
Open Feature request MC-755

Native support for global/static variables

action_vote_minus_faded.png
18
Votes
action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
Description

It would be great if MultiCharts could implement support for native PowerLanguage support of global or static variables. I'm currently using the GlobalVariables dll to share data across different charts, but it seems like a kludgy workaround at best.
 
In my opinion, there are several problems with using the GlobalVariables dll, or other DLLs like ADE:
 
1. This requires convoluted coding procedures. If I want to share data, I first have to include DefineDLLFunc statements. I then have to have several additional lines of code to manage the global variables. For example, I need multiple lines just to increment a global counter:
 
Variables:
Count( 0 ) ;
 
Count = GV_GetInteger( 1 ) ;
Count += 1 ;
Value1 = GV_SetInteger( 1, Count ) ;
 
This can quickly turn into spaghetti code if I have multiple global variables.
 
2. Since the data in the GlobalVariables dll is truly "global" -- i.e., is accessible to any indicator or signal that uses the GlobalVariables dll -- there's a chance of unintended bugs if another signal or indicator attempts to use the same variable slot. For example, if another signal or function also uses the "1" slot for integers, then two separate signals or indicators will attempt to read and write from the same memory slot, with unexpected results.
 
3. Related to no. 2, the GlobalVariables dll can't be used for optimizations with the Portfolio Backtester, as far as I can tell. This is because there will be multiple threads that are simultaneously running backtests against different optimization inputs, but all of the threads will be reading and writing from the same GlobalVariables memory space at the same time. For example, one thread might increment a counter in a signal, and then another thread will increment the same variable again. I.e., the contents of the GlobalVariables dll aren't isolated to any one thread, but are shared across all threads, so there are concurrency problems.
I would suggest an extension to the PowerLanguage language to provide native support for global variables, without the need for a DLL and the attendant problems. I'm sure that you don't want to fork the language to make it too different than EasyLanguage. However, you could make these changes while still retaining backwards compatibility with EasyLanguage.
 
First, there should be some syntax to indicate that a variable is a global variable, rather than a local variable. This could perhaps be something like the following:
 
Global Variables:
Count( 0 ) ;
 
Count += 1 ;
 
This way, the user wouldn't need DefineDLLFunc calls, along with the cumbersome GV_GetInteger, GV_SetInteger syntax. Instead, global variables would be natively supported and could be read or written to using a syntax that is similar to the syntax for local variables.
 
Alternatively, you could do the same through a compiler directive, like the following:
  
Variables:
[Global]
Count( 0 ) ;
 
Count += 1 ;
 
There should also similar syntax to allow global arrays. As explained below, you could perhaps use the phrase "Static" instead of "Global." 
 
Second, the global variables shouldn't be completely "global" in scope, but instead should be limited in scope to instances of the particular signal or indicator. I.e., it should be roughly comparable to the "static" keyword for variables in C++, C#, or Java, in which a static variable can be accessed by all instances of a class, but can't be accessed outside of that particular class. In other words, if two different signals or indicators happen to use the same name for global variables (like two signals or indicators that both use "Count"), then there wouldn't be collisions between the two -- each signal or indicator would have its own internal global variable, and there wouldn't be a conflict between the two.
 
Third, in keeping with the second proposal, the global or static variables should be "Portfolio Backtester safe." I.e., there should be separate memory spaces for global variables for each optimization that is being run in the Portfolio Backtester. That way, if the Portfolio Backtester is simulataneously runing four or eight optimizations in different threads, the different threads won't be trying th access the same memory space.
 
I hope this isn't too extravagent a request. However, it seems really surprising to me that a modern programming language would not provide native support for global/static variables. It would make it much easier to code signals that need to share data between different charts, such as for doing things like position sizing for a portfolio across multiple charts. Thanks in advance for considering this idea.

Steps to reproduce this issue

See above.

Comments (1)
#0
user-offline.png  Daenerys (Guest)
May 25, 2016 - 14:11

Has this issue been resolved. I do a LOT of optimizations in MC, and want to use Global Variables, mainly integers for an accessible control panel. 
Thanks,
Lew (interfool)

History
Issue basics
  • Type of issue
    Feature request
  • Category
    Usability
  • Targeted for
    Not determined
  • Status
    Under Review
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (3)
People involved
  • Posted by
    user-offline.png  Xyzzy (Xyzzy)
  • Owned by
    Not owned by anyone
  • Assigned to
    Not assigned to anyone
  • Subscribers
    1 subscriber(s)
    Click here to show the list of subscribers
Times and dates
  • Posted at
  • Last updated
Issue details
  • Resolution
    Not determined
  • Severity
    Normal
Attachments (0)
There is nothing attached to this issue
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates