MC's (Beta) PLEditor/Compiler Confused by Changing Inputs

Questions about MultiCharts and user contributed studies.
denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

MC's (Beta) PLEditor/Compiler Confused by Changing Inputs

Postby denizen2 » 09 Dec 2006

I just discovered that the compiler can be 'confused' when an existing (and working) indicator is edited & compiled with a the input-list re-organized.

Specifically, I added a new named-parameter, eliminated a couple, and re-arranged most of them. The resulting file compiled ok with no errors reported, BUT the indicator plotted with a wrong color, 'BLACK', that neither existed before, or after, any of my changes to the input-list. The input list contained 9 inputs, and four of them were color-names.

It looks to me like one of the color variables-input was somehow made to be the number number zero (BLACK). I eventually, 'fixed' the indicator by breaking up the input statements into two inputs statements, and re-compiling, thus forcing it (perhaps) to completely ignore any previous compiled code?

User avatar
Stanley Miller
Posts: 556
Joined: 26 Jul 2005
Has thanked: 3 times

Postby Stanley Miller » 09 Dec 2006

Is it possible to reproduce the issue? Could you please post here a sample code which plots a wrong color after recompilation? It would be really helpful.

Guest

Postby Guest » 11 Dec 2006

Is it possible to reproduce the issue? Could you please post here a sample code which plots a wrong color after recompilation? It would be really helpful.
Sorry, but there is no edit 'trail' available, and I doubt that I could reconstruct it from memory :( .

But we can say the following: It is about indicators, not functions. And Indicators have user-setable parameters, and the labels for these indicator-parameters seem to be 'remembered' from one edit-compile-display cycle to the next, so that if user makes simple enough changes to the definition of the indicator's parameters, e.g., re-arranges them, or changes the label-name, or default values, then there is some kind of mechanism built-in (with rules I don't really know) for making sense of what has to be changed, and what can stay the same. That logic got confused somehow, and it manifested as displaying parts of the indicator in a color (BLACK) that was never specified in the parameter list. Since Black color is just the numeric value of zero (0), I would suspect that the color-variable never got initialized by my specified non-black color. If this can happen for a color parameter, it might also happen for any other kind of parameter, but not be so visiable :roll: .

I would suggest that the developers could revisit the code in that area and attempt to verify the logic by inspection and/or random-change-testing to parameter list and see what happens :roll: . It defininately was 'broken' in my case, until I just changed the one long input-statement into two input-statements (consisting of exactly the same parameters in total, but just divided between the two statements). In otherwords, using two input statements, seems to have forced the whole list to be completely re-evaluated, without any sticky-confused memory of the previous parameter list.

User avatar
Kate
Posts: 758
Joined: 08 Dec 2006

Postby Kate » 11 Dec 2006

Our developers failed to reproduce the situation without a sample code. Moreover, we have never noticed such a strange behavior of the indicators after changing their parameters.

denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

Postby denizen2 » 15 Dec 2006

Our developers failed to reproduce the situation without a sample code. Moreover, we have never noticed such a strange behavior of the indicators after changing their parameters.
I understand that this is not likely to be a 'typical' occurence, and furthermore, the developers might have not changed the parameters in the same way that I did. I should add that the parameter changes that I made were like this: Nine parameters (Maybe more than normal?), parameters #2 and #3 were removed entirely (and not color-code type parameters), but at the SAME time (in the edit cycle), I moved another parameter from the 'end' of the list and inserted where the two were removed. That parameter was not a color-param. There were four color-type param after that, and I might have changed the name of one of the color params too. When this was compiled, the chart displayed the appropriate (specificied) colors, except for just one condition (colorDN), where as the 'colorUP', and the other two in between UP and DN were also correct. The one incorrect color was plotted as BLACK (or zero-color). Being a programmer too :wink: , I suspected that something was wrong with how those changes of names, or changes in location of some parameters mangled something, so I forced the compiler to ignore all previous parameter lists by breaking up the input params list into two separate lists. Nothing else was changed. Then ...by 'magic' the correct colors were plotted. :roll:

This might be difficult to re-create there in the 'lab' testing environment, but it should be taken as a 'red flag' that something is amiss, and it could go unnoticed for a long time except for the fact that it happen to occur with color parameters. A number type parameter would not likely have even been noticed by most users, but a color change was very obvious, especially when it is the difference of BLACK and WHITE, right? So please add these extra notes to your file of 'to be investigated' as a potential compiler-parameters 'bug'. In summary: It is related to some combination of removing some params (early in the list), and then 'moving' (from later in the list) ONE param into the slot where the two params were removed, and changing the name of one of the params in the list. Granted, a rare combination of changes, but it did break the logic, and 'should' not be entirely dismissed, in my opinion.


Return to “MultiCharts”