Session Start/End Time give different result when optimizing

Questions about MultiCharts and user contributed studies.
RS
Posts: 39
Joined: 28 Sep 2007

Session Start/End Time give different result when optimizing

Postby RS » 09 Oct 2007

Marina,

The reserved words sessionstarttime and sessionendtime gives different results when running normal in a signal and when optimizing the same signal. I think this must be wrong.

The following simple signal code reproduces this:

Inputs: OnlyForOptimize(0);

print (date, " ", time, " ","sessionstarttime: ", sessionstarttime(1,1), " sessionendtime: ", sessionendtime(1,1));


With regards,
Rob.

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 10 Oct 2007

Hi Rob,

You are right, this is a known bug.

We are planning to fix it in the next MC version.

Thank you for reporting the issue.

Regards.

RS
Posts: 39
Joined: 28 Sep 2007

Postby RS » 10 Oct 2007

Marina,

Thanks for your answer!

Because it took me some time to figure out this bug -debugging in MC is not trivial- I want to know whether you have a list of known bugs/issues. That list will save me time.

Thanks,
Rob.

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 33 times

Postby MC_Prog » 10 Oct 2007

One approach that I've seen elsewhere is to allow registered users access to the 'Bugzilla' (or similar) database used by the developers so that they can report issues, see issues already reported, and have some idea (through the status tracking) when known issues might be addressed (or if they never will be!).

The modern technology available (and for free!) explicitly enables such user/developer partnership, and it is a policy decision on the part of a platform vendor whether or not to allow/encourage such interaction.

As one who has seen in real life the significant benefits that can come from this, I certainly would encourage MC to adopt this cooperation model for their own benefit, and the benefit of their customers.

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 10 Oct 2007

Hello,

Thank you for your suggestions. What you are saying does make a lot of sense. However, at the moment we cannot make the list of bugs publicly available for the simple reason that it's in Russian. In terms of time commitment it would take us much longer trying to translate the list into English than to respond to each particular customer whenever they suspect there is a bug.

Apart from that, the overwhelming majority of the reported 'bugs' stem from misunderstanding or misusing the program's features. This is another reason, why we prefer dealing with bugs reports on the individual basis - because usually these reports do not require fixes but explanations and advice instead.

denizen2
Posts: 125
Joined: 17 Jul 2005

Postby denizen2 » 16 Oct 2007

Hello,

Thank you for your suggestions. What you are saying does make a lot of sense. However, at the moment we cannot make the list of bugs publicly available for the simple reason that it's in Russian. In terms of time commitment it would take us much longer trying to translate the list into English than to respond to each particular customer whenever they suspect there is a bug.

Apart from that, the overwhelming majority of the reported 'bugs' stem from misunderstanding or misusing the program's features. This is another reason, why we prefer dealing with bugs reports on the individual basis - because usually these reports do not require fixes but explanations and advice instead.


With all due respect, I find it hard to understand your explaination for not implementing the very good suggestion made in this topic.

Here's why: How long does it take to translate just a short and succinct 'title' of a 'bug'? Most bugs can be summarized in one or two sentences, totalling less than 100 words, right? I understand how it could take a long time to translate these English posts into Russian, especially mine, right? :oops: But translating the Russian into simple English keywords would not take very much time, and would be much more useful and efficient than the current approach of no bug-list. A 'bug-list' would at least alert any of us wondering whether we should 'investigate' further on our own,or should we post and wait for feedback. or just ignore it?

Isn't it worth trying for a few months, then judge whether what you get back from the users is worth your time and effort? I for one, would be inclined to put more of my own personal time into identifying and reporting on bugs if there were some kind of bug-list that was tracking the 'progress'.

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 25 Oct 2007

Hello denizen2,

Well, in fact to make such a list available to the customers we would need to make more transformations than merely translate the list. The bug list that is used by our software engineers has a strictly defined format and is highly technical and meant for programmers. To rework such a list into a more or less understandable form several specialists will have to work together. For example, software engineers will have to work with the translator to explain every particular case, so that the translator could understand the issue and rework it. At the moment we cannot afford to have several specialists work on a task like that. Even so, we would go into all the trouble to make such a list if we were certain that it would really be useful.

It is also easier for us to create a list of fixed bugs. Such a list will be created once the new version of MC is released.


Return to “MultiCharts”