Announcement

#2 · 04-21-05, 04:40 PM

RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01

I've been contacted by Miva and it was explained to me that if the result of
the expression 100*(1-0.9) - 10 was equal to zero in Empresa v3, it was in
fact a bug. Whatever illogically it may sound, 100*(1-0.9) - 10 won't never
more return zero, and no programmer should expect it. Same goes for many
other similar expressions, and also for the use of the functions int() and
floor() - int(100*(1-0.9)) or floor(100*(1-0.9)) will never return the
expected 10, but rather just 9.

Told in other words, the illogical results are not considered a bug, but
rather an improvement of the engine. The results now better match similarly
"correct" results in other languages (PHP, C).

The consequence for Miva Script developers: double check all expression
using int(), floor() and all conditions checking for zero values - as long
as they handle non-integer values, you'll have to use ROUND or another
similar technique to receive the expected effect.

The behaviour is not considered "bug". It is a "bug fix".

I sincerely apologize to Miva Co. for incorrectly asking to pull the engine
off any server. Developers, please change your scripts and your logic
instead.

Ivo Truxa

| http://miva.truxoft.com
| Advanced Miva Merchant modules

-----Original Message-----
From: Ivo Truxa

MmDIAG (<A HREF ="http://www.mivacentral.com/truxoft/?product=TRUXOFT-MMDIAG) reports">http://www.mivacentral.com/truxoft/?...TRUXOFT-MMDIAG) reports</A>
that the old fatal arithmetic rounding bug is still kicking in the freshly
announced Empresa v5.01. See my report from 2004 below. It still has the
same effect in v5.01 too.

The results from ME v5.01 (FreeBSD):
10 / -0.00000000000000177636 / 9 / 9

Should be:
10 / 0 / 10 / 10

I am afraid that the engine should be immediately pulled off any server - I
can easily imagine that such a huge error can completely wreck some stores,
and cause big damage if wrong amounts are billed through payment gateways.

Ivo
http://mivo.truxoft.com

-----Original Message-----
From: Ivo Truxa [mailto:[email protected]]
Sent: Sunday, June 20, 2004 7:58 PM
To: '[email protected]'
Cc: '[email protected]'
Subject: RE: [MVM:BUG] fatal arithemtic bug

Almost a year ago I reported a bug giving completely wrong results at simple
arithmetic operations. This bug was supposedly fixed in the following VM
version.

Unfortunately, I just found that only a secondary cosmetic effect of the bug
was resolved, but the serious bug itself is still causing fatally wrong
results in many arithmetic calculations.

The original bug was as follows: the code <MvEVAL EXPR="{100*(1-0.9)}">
displayed "1" instead of the correct "10" as the result. Current engine
versions display correctly "10", but the value itself, and any further
operations with the values, still give wrong results. Try this code:

<MvEVAL EXPR="{100*(1-0.9)}"> /
<MvEVAL EXPR="{100*(1-0.9) - 10}"> /
<MvEVAL EXPR="{int(100*(1-0.9))}"> /
<MvEVAL EXPR="{floor(100*(1-0.9))}">

Correctly it should return: 10 / 0 / 10 / 10
Older VM version return: 1 / -0.00000000000000177636 / 9 / 9
Current VM returns: 10 / -0.00000000000000177636 / 9 / 9

It means only the cosmetic MvEVAL was fixed, but further handling of the
value still results in completely wrong values.

Like at many other bugs, this one is also being detected and reported by the
MmDIAG/TxDIAG v2.00 diagnostic tool.

Ivo
http://mivo.truxoft.com

-----Original Message-----
From: Ivo Truxa
Sent: Monday, August 18, 2003 5:40 PM

Unlike what expected and what v3.9 correctly returns, in MVM the expression
<MvEVAL EXPR="{100*(1-0.9)}"> returns "1" instead of "10"

Example:

<MvEVAL EXPR="{100*(1-0.9)}"> /
<MvEVAL EXPR="{100 * (1 - 0.9)}"> /
<MvEVAL EXPR="{100.00 * (1 - 0.9)}"> /
<MvEVAL EXPR="{100.00 * (1.00 - 0.90)}"> /
<MvEVAL EXPR="{100.00 * ((1 - 0.9) ROUND 2)}"> /
<MvEVAL EXPR="{100-100*0.9}">

Results in v3.xx (correct):
10 / 10 / 10 / 10 / 10 / 10

Results in MVM v4.07 and v4.09 (wrong except of the last two):
1 / 1 / 1 / 1 / 10 / 10

I wonder that nobody experienced any problems with it yet. It must often
return wrong results even in Miva Merchant!

Ivo
http://mivo.truxoft.com

#3 · 04-21-05, 05:56 PM

RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01

> ...and it was explained to me that
> if the result of the expression 100*(1-0.9) - 10 was equal
> to zero in Empresa v3, it was in fact a bug.

HAHAHA
Sorry, I was just picturing myself explaining this to my high school math
teachers.....

> Told in other words, the illogical results are not considered
> a bug, but rather an improvement of the engine. The results
> now better match similarly "correct" results in other
> languages (PHP, C).

Ummmmmm, ok.

Bill M.

#4 · 04-21-05, 06:18 PM

RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01

And in other news...

* Microsoft announces that the many thousands of "so-called holes" in its
Windows operating system software were actually placed there intentionally in
an attempt to "keep our users on their toes."

* Intel rescinds their acknowledgement of the infamous "Pentium rounding
error", now claiming that, "nobody understands 'new math' better than Intel."

* NASA now denies that loss of the Mars Climate Orbiter was due to mixing
metric and imperial units, stating, "Nobody really knows what measurement
system is used on Mars, so our use of multiple measurement systems in no way
contributed to the loss of [the orbiter]. The blame rests entirely on Mars."

* Miva Corp denies responsibility for "programming errors" that cause their
software users and developers to "waste countless hours finding the true
meaning of zero". Points out that "one plus one equals three for sufficiently
large values of one and most values of two".

* Scientists discover that lemmings, once thought to have leapt en masse from
cliffs and dashed to death on rocks below, are much smarter than previously
thought. "We previously believed they simply jumped from cliffs, one after
another, because all the other lemmings were doing it," says a spokesman.
"Now, after intensive research, we know it's just an urban legend. No creature
would harm itself intentionally -- it's not in their programming."

Okay, not really. Except that lemmings really don't jump off cliffs (it's
really an urban legend).

BTW, Ivo, I don't know what language my Windows calc.exe program was written
in... I keep getting an answer of zero when I plug in your equation:

100 * (1 - 0.9) - 10

I get the same answer with Excel, 4DOS (a very old program from the early
90's), and pencil/paper (a very, very old program I picked up in grade
school). All I can say is, "cut it out". It's really confusing me and makes me
want to drink beer. Hmmm, beer sounds like a good idea. I'll go have a few
dozen and see if I can get the answer to come out the "right" way. :)

Tom

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Ivo Truxa
> Sent: Thursday, April 21, 2005 7:40 PM
> To: [email protected]; [email protected]
> Subject: [meu] RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01
>
>
> I've been contacted by Miva and it was explained to me that if the result of
> the expression 100*(1-0.9) - 10 was equal to zero in Empresa v3, it was in
> fact a bug. Whatever illogically it may sound, 100*(1-0.9) - 10 won't never
> more return zero, and no programmer should expect it. Same goes for many
> other similar expressions, and also for the use of the functions int() and
> floor() - int(100*(1-0.9)) or floor(100*(1-0.9)) will never return the
> expected 10, but rather just 9.
>
> Told in other words, the illogical results are not considered a bug, but
> rather an improvement of the engine. The results now better match similarly
> "correct" results in other languages (PHP, C).
>
> The consequence for Miva Script developers: double check all expression
> using int(), floor() and all conditions checking for zero values - as long
> as they handle non-integer values, you'll have to use ROUND or another
> similar technique to receive the expected effect.
>
> The behaviour is not considered "bug". It is a "bug fix".
>
> I sincerely apologize to Miva Co. for incorrectly asking to pull the engine
> off any server. Developers, please change your scripts and your logic
> instead.
>
> Ivo Truxa
>
> | http://miva.truxoft.com
> | Advanced Miva Merchant modules
>
>
>
>
>
>
>
> -----Original Message-----
> From: Ivo Truxa
>
> MmDIAG (<A HREF ="http://www.mivacentral.com/truxoft/?product=TRUXOFT-MMDIAG) reports">http://www.mivacentral.com/truxoft/?...TRUXOFT-MMDIAG) reports</A>
> that the old fatal arithmetic rounding bug is still kicking in the freshly
> announced Empresa v5.01. See my report from 2004 below. It still has the
> same effect in v5.01 too.
>
> The results from ME v5.01 (FreeBSD):
> 10 / -0.00000000000000177636 / 9 / 9
>
> Should be:
> 10 / 0 / 10 / 10
>
> I am afraid that the engine should be immediately pulled off any server - I
> can easily imagine that such a huge error can completely wreck some stores,
> and cause big damage if wrong amounts are billed through payment gateways.
>
> Ivo
> http://mivo.truxoft.com
>
>
> -----Original Message-----
> From: Ivo Truxa [mailto:[email protected]]
> Sent: Sunday, June 20, 2004 7:58 PM
> To: '[email protected]'
> Cc: '[email protected]'
> Subject: RE: [MVM:BUG] fatal arithemtic bug
>
> Almost a year ago I reported a bug giving completely wrong results at simple
> arithmetic operations. This bug was supposedly fixed in the following VM
> version.
>
> Unfortunately, I just found that only a secondary cosmetic effect of the bug
> was resolved, but the serious bug itself is still causing fatally wrong
> results in many arithmetic calculations.
>
> The original bug was as follows: the code <MvEVAL EXPR="{100*(1-0.9)}">
> displayed "1" instead of the correct "10" as the result. Current engine
> versions display correctly "10", but the value itself, and any further
> operations with the values, still give wrong results. Try this code:
>
> <MvEVAL EXPR="{100*(1-0.9)}"> /
> <MvEVAL EXPR="{100*(1-0.9) - 10}"> /
> <MvEVAL EXPR="{int(100*(1-0.9))}"> /
> <MvEVAL EXPR="{floor(100*(1-0.9))}">
>
> Correctly it should return: 10 / 0 / 10 / 10
> Older VM version return: 1 / -0.00000000000000177636 / 9 / 9
> Current VM returns: 10 / -0.00000000000000177636 / 9 / 9
>
> It means only the cosmetic MvEVAL was fixed, but further handling of the
> value still results in completely wrong values.
>
> Like at many other bugs, this one is also being detected and reported by the
> MmDIAG/TxDIAG v2.00 diagnostic tool.
>
> Ivo
> http://mivo.truxoft.com
>
>
>
> -----Original Message-----
> From: Ivo Truxa
> Sent: Monday, August 18, 2003 5:40 PM
>
> Unlike what expected and what v3.9 correctly returns, in MVM the expression
> <MvEVAL EXPR="{100*(1-0.9)}"> returns "1" instead of "10"
>
> Example:
>
> <MvEVAL EXPR="{100*(1-0.9)}"> /
> <MvEVAL EXPR="{100 * (1 - 0.9)}"> /
> <MvEVAL EXPR="{100.00 * (1 - 0.9)}"> /
> <MvEVAL EXPR="{100.00 * (1.00 - 0.90)}"> /
> <MvEVAL EXPR="{100.00 * ((1 - 0.9) ROUND 2)}"> /
> <MvEVAL EXPR="{100-100*0.9}">
>
> Results in v3.xx (correct):
> 10 / 10 / 10 / 10 / 10 / 10
>
> Results in MVM v4.07 and v4.09 (wrong except of the last two):
> 1 / 1 / 1 / 1 / 10 / 10
>
> I wonder that nobody experienced any problems with it yet. It must often
> return wrong results even in Miva Merchant!
>
> Ivo
> http://mivo.truxoft.com
>
>
>
>

#5 · 04-21-05, 11:14 PM

RE: [mru] [MVM:BUG] fatal arithmetic bug still in v5.01

Hi all,

A few thoughts on the Miva Math issue.

If you try and simulate the Miva code under discussion in Perl,
and PHP here is what happens.

In Perl this code:

use POSIX qw(ceil floor);
print( (100*(1-0.9))=20
. '/' . (100*(1-0.9)-10)=20
. '/' . int(100*(1-0.9))=20
. '/' . floor(100*(1-0.9))
);

Returns this:
10/-1.77635683940025e-15/9/9

In PHP, this code:
<?PHP
echo( (100*(1-0.9))=20
. '/' . (100*(1-0.9)-10)=20
. '/' . intval(100*(1-0.9))=20
. '/' . floor(100*(1-0.9))
);
?>

Returns this:
10/-1.7763568394E-015/9/9

So this lends some strength to the supposed claims made by Miva
that the Math problems aren't Miva's fault and they are at the
mercy of the limitations of the C Libraries just like we are at
the Mercy of Miva script.

Well, I don't care if the floating point libraries have issues
regarding certain numbers, and I don't think it matters a bit
that PHP or Perl produce similarly wrong results as Miva script,
because with both those languages you have lots of other ways you
can use math and with Miva you don't.

In PHP for example you can use the BC arbitrary precisions math
functions and rewrite that code just a bit like this:

<?PHP
echo( (100*(1-0.9))=20
. '/' . ( bcmul(100,(1-0.9)) - 10 )
. '/' . intval(100*(1-0.9))=20
. '/' . floor(100*(1-0.9))
);
?>

Which results in the proper values:
10/0/9/9

In both Perl and PHP, and certainly lots of other languages as
well, you might have a dozen different ways to resolve the issue,
using lots of different tools at your disposal to do so. But in
Miva script we don't have access to such things. Miva is a high
level language that often trades power and control away for
simplicity and that is in general a good thing, but that still
doesn't change the fact that we can't do accurate Math with Miva
and you can with Perl, PHP, etc.=20

So if Miva is really claiming that Miva script developers need to
change the way they code to overcome the math problems in Miva
script, then that would be reasonable if they would give us the
tools to do the job.=20

Note that I say "if Miva is really claiming" not because I
disbelieve Ivo, but merely to make it clear that Miva didn't to
my personal knowledge make that statement.=20

But if they aren't going to give us those tools then it seems
reasonable that they need to make the only Math options open to
us operate in a way that removes the need for those other tools.

Of course there is one other fact here that if looked at does
sort of give Miva a possible get out of jail free card on this
issue and that is the fact that they have given us all the
ability to extend the Miva script language in the form of the
external function libraries. New math libraries can be written in
C and exposed via functions to Miva script.

But of course the 4.x API docs for building the external function
libraries are pretty horrible. But if for 5.x Miva decides to
have some good API docs for the external function libraries then
maybe we could get a solution fairly soon because there is tons
of GPL math code out there that could probably be quickly made
into a series of useful external function libraries for the VM.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ivo Truxa
Sent: Thursday, April 21, 2005 5:40 PM
To: [email protected]; [email protected]
Subject: [meu] RE: [mru] [MVM:BUG] fatal arithmetic bug still in
v5.01

I've been contacted by Miva and it was explained to me that if
the result of
the expression 100*(1-0.9) - 10 was equal to zero in Empresa
v3, it was in
fact a bug. Whatever illogically it may sound, 100*(1-0.9) - 10
won't never
more return zero, and no programmer should expect it. Same goes
for many
other similar expressions, and also for the use of the functions
int() and
floor() - int(100*(1-0.9)) or floor(100*(1-0.9)) will never
return the
expected 10, but rather just 9.

Told in other words, the illogical results are not considered a
bug, but
rather an improvement of the engine. The results now better match
similarly
"correct" results in other languages (PHP, C).

The consequence for Miva Script developers: double check all
expression
using int(), floor() and all conditions checking for zero values
- as long
as they handle non-integer values, you'll have to use ROUND or
another
similar technique to receive the expected effect.

The behaviour is not considered "bug". It is a "bug fix".

I sincerely apologize to Miva Co. for incorrectly asking to pull
the engine
off any server. Developers, please change your scripts and your
logic
instead.

Ivo Truxa

| http://miva.truxoft.com
| Advanced Miva Merchant modules

-----Original Message-----
From: Ivo Truxa

MmDIAG
(<A HREF ="http://www.mivacentral.com/truxoft/?product=3DTRUXOFT-MMDIAG)">http://www.mivacentral.com/truxoft/?...TRUXOFT-MMDIAG)</A>
reports
that the old fatal arithmetic rounding bug is still kicking in
the freshly
announced Empresa v5.01. See my report from 2004 below. It still
has the
same effect in v5.01 too.

The results from ME v5.01 (FreeBSD):
10 / -0.00000000000000177636 / 9 / 9

Should be:
10 / 0 / 10 / 10

I am afraid that the engine should be immediately pulled off any
server - I
can easily imagine that such a huge error can completely wreck
some stores,
and cause big damage if wrong amounts are billed through payment
gateways.

Ivo
http://mivo.truxoft.com=20

-----Original Message-----
From: Ivo Truxa [mailto:[email protected]]=20
Sent: Sunday, June 20, 2004 7:58 PM
To: '[email protected]'
Cc: '[email protected]'
Subject: RE: [MVM:BUG] fatal arithemtic bug

Almost a year ago I reported a bug giving completely wrong
results at simple
arithmetic operations. This bug was supposedly fixed in the
following VM
version.=20

Unfortunately, I just found that only a secondary cosmetic effect
of the bug
was resolved, but the serious bug itself is still causing fatally
wrong
results in many arithmetic calculations.

The original bug was as follows: the code <MvEVAL
EXPR=3D"{100*(1-0.9)}">
displayed "1" instead of the correct "10" as the result. Current
engine
versions display correctly "10", but the value itself, and any
further
operations with the values, still give wrong results. Try this
code:

<MvEVAL EXPR=3D"{100*(1-0.9)}"> /
<MvEVAL EXPR=3D"{100*(1-0.9) - 10}"> / =20
<MvEVAL EXPR=3D"{int(100*(1-0.9))}"> /=20
<MvEVAL EXPR=3D"{floor(100*(1-0.9))}">

Correctly it should return: 10 / 0 / 10 / 10
Older VM version return: 1 / -0.00000000000000177636 / 9 / 9
Current VM returns: 10 / -0.00000000000000177636 / 9 / 9

It means only the cosmetic MvEVAL was fixed, but further handling
of the
value still results in completely wrong values.

Like at many other bugs, this one is also being detected and
reported by the
MmDIAG/TxDIAG v2.00 diagnostic tool.

Ivo
http://mivo.truxoft.com=20

-----Original Message-----
From: Ivo Truxa
Sent: Monday, August 18, 2003 5:40 PM

Unlike what expected and what v3.9 correctly returns, in MVM the
expression
<MvEVAL EXPR=3D"{100*(1-0.9)}"> returns "1" instead of "10"

Example:

<MvEVAL EXPR=3D"{100*(1-0.9)}"> /
<MvEVAL EXPR=3D"{100 * (1 - 0.9)}"> /
<MvEVAL EXPR=3D"{100.00 * (1 - 0.9)}"> /
<MvEVAL EXPR=3D"{100.00 * (1.00 - 0.90)}"> /
<MvEVAL EXPR=3D"{100.00 * ((1 - 0.9) ROUND 2)}"> /
<MvEVAL EXPR=3D"{100-100*0.9}">

Results in v3.xx (correct):=20
10 / 10 / 10 / 10 / 10 / 10

Results in MVM v4.07 and v4.09 (wrong except of the last two):
1 / 1 / 1 / 1 / 10 / 10

I wonder that nobody experienced any problems with it yet. It
must often
return wrong results even in Miva Merchant!

Ivo
http://mivo.truxoft.com=20

#6 · 04-22-05, 03:40 AM

RE: [MVM:BUG] fatal arithmetic bug still in v5.01

-----Original Message-----
From: Jeff Huber - Listmail

> ...
> <?PHP
> echo( (100*(1-0.9))
> . '/' . ( bcmul(100,(1-0.9)) - 10 )
> . '/' . intval(100*(1-0.9))
> . '/' . floor(100*(1-0.9))
> );
> ?
> Which results in the proper values:
> 10/0/9/9

Not that it is important, but 10/0/9/9 is wrong too. Mathematically correct
is only 10/0/10/10 and that's what Empresa v3.xx always returned. The old
correct result is now considered bug, and the new wrong result is considered
improvement because it returns as wrong values as the examples in other
languages you and Miva Co mentioned.

> ...
> So if Miva is really claiming that Miva script developers need to
> change the way they code to overcome the math problems in Miva
> script, then that would be reasonable if they would give us the
> tools to do the job.
>
> Note that I say "if Miva is really claiming" not because I
> disbelieve Ivo, but merely to make it clear that Miva didn't to
> my personal knowledge make that statement.

That's absolutely correct. Miva does not care about the code of 3rd party
developers at all, and does not care if we change the code or not. It was me
who told that you have to double-check your scripts that work uncompiled,
because they can now easily return diametrically different results if they
use some mathematical or logical expressions (i.e. checking for zero)
similar to those in my examples. This is also the way I discovered the
"improvement" - in extremely rare situations, an old module started to
return unexpected results, although it always worked just fine before.

However, as was told to me, although backwards compatibility is intended, it
is not guaranteed. I can certainly understand it, and that's why I
apologized, and retracted my demand to pull out the engine, and asked
developers to change their scripts and programming habits instead (if
needed, of course). The workarounds are pretty easy. What may be more
difficult is finding such critical code in your old scripts, since it may
hit only in rare occurrences and at rare real-time value combinations only.

Practically, the best way to avoid troubles is always rounding arithmetic
results before using in logical expressions, or before converting to
integers. Some other mathematical expressions may be also critical, so it is
wise trying to first figure out what the result of such operation may be if
the values are not exactly what you expect.

Ivo
http://mivo.truxoft.com

#7 · 04-22-05, 07:17 AM

RE: [MVM:BUG] fatal arithmetic bug still in v5.01

Sorry Ivo,

I was only paying attention to the second expression because that
was the one I was demonstrating the use of the BC tools for PHP.

- Jeff Huber
President, 4TheBest eCommerce Solutions
http://4TheBest.com
[email protected]
Office: 760-742-1469
Cell: 760-445-8454
=20

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ivo Truxa
Sent: Friday, April 22, 2005 4:40 AM
To: [email protected]; [email protected]
Subject: [meu] RE: [MVM:BUG] fatal arithmetic bug still in v5.01

-----Original Message-----
From: Jeff Huber - Listmail

> ...
> <?PHP
> echo( (100*(1-0.9))=20
> . '/' . ( bcmul(100,(1-0.9)) - 10 )
> . '/' . intval(100*(1-0.9))
> . '/' . floor(100*(1-0.9))
> );
> ?
> Which results in the proper values:
> 10/0/9/9

Not that it is important, but 10/0/9/9 is wrong too.
Mathematically correct
is only 10/0/10/10 and that's what Empresa v3.xx always returned.
The old
correct result is now considered bug, and the new wrong result is
considered
improvement because it returns as wrong values as the examples in
other
languages you and Miva Co mentioned.

> ...
> So if Miva is really claiming that Miva script developers need
to
> change the way they code to overcome the math problems in Miva
> script, then that would be reasonable if they would give us the
> tools to do the job.=20
>
> Note that I say "if Miva is really claiming" not because I
> disbelieve Ivo, but merely to make it clear that Miva didn't to
> my personal knowledge make that statement.=20

That's absolutely correct. Miva does not care about the code of
3rd party
developers at all, and does not care if we change the code or
not. It was me
who told that you have to double-check your scripts that work
uncompiled,
because they can now easily return diametrically different
results if they
use some mathematical or logical expressions (i.e. checking for
zero)
similar to those in my examples. This is also the way I
discovered the
"improvement" - in extremely rare situations, an old module
started to
return unexpected results, although it always worked just fine
before.=20

However, as was told to me, although backwards compatibility is
intended, it
is not guaranteed. I can certainly understand it, and that's why
I
apologized, and retracted my demand to pull out the engine, and
asked
developers to change their scripts and programming habits instead
(if
needed, of course). The workarounds are pretty easy. What may be
more
difficult is finding such critical code in your old scripts,
since it may
hit only in rare occurrences and at rare real-time value
combinations only.=20

Practically, the best way to avoid troubles is always rounding
arithmetic
results before using in logical expressions, or before converting
to
integers. Some other mathematical expressions may be also
critical, so it is
wise trying to first figure out what the result of such operation
may be if
the values are not exactly what you expect.

Ivo
http://mivo.truxoft.com=20

Announcement

[MVM:BUG] fatal arithmetic bug still in v5.01

[MVM:BUG] fatal arithmetic bug still in v5.01

Comment

Comment

Comment

Comment

Comment

Comment