Miva Merchant Empresa Bugs?

[Julie Wilber]

This thread is for pointing out bugs you might have found with MIVA Empresa.

Please include as much information as possible, including if it can be duplicated and under what conditions.

Before posting anything, please run a search of the forums to see if something has already been posted.

Thanks!

[sebenza]

5.04 Gives you:

Access denied for user 'user'@'localhost' to database 'dbname''

When clicking the finish button on setup.mvc

[aGorilla]

This code:

<MvFILTER NAME="{l.table}" FILTER_TYPE="variable" FILTER="l.this:filter">
Give's me this (rather cryptic) error message:
C:\...\Temp\\mva00000001:1017: AE_311: Duplicate string identifier "s_0"

Delete the ':' in 'l.this:filter', and it works. A minor bug, but an annoying one.

[aGorilla]

Trying to include a javascript file:
<script src="somescript.js" type="text/javascript"></script>

I've had two cases where I've wasted time tracking down Javascript errors locally, but they magically disappeared when uploaded to a server.

In one of those cases, the problem with Miva Mia was solved by putting the contents of the javascript file into the mivascript file.

[Kent Multer]

Actually, I seem to recall reading about this before. It's been a known bug for some time, but I don't know if anyone's pointed out that it's still happening in 5.04. The EIN and ECIN operators still don't work; they apparently return the same values as IN and CIN.

[benwalsh]

Several interesting issues working with local and global variables:

The function miva_getvarlist(scope) ignores the scope. For example, miva_getvarlist('g') returns ALL local, global and system variables.

Also if I assign a local variable it can be referenced using a global variable. And therefore, you can't assign a local and global variable with the same name. For instance:

<MvASSIGN NAME = "l.test" VALUE = 1>
<MvASSIGN NAME = "g.test" VALUE = 2>
<MvEVAL EXPR = "{ g.test }">
<MvEVAL EXPR = "{ l.test }">


This returns 22. Both g.test and l.test have the value of 2 since the g.test overwrote l.test.

No big deal to work around this, but it can really throw you for a loop when debugging.

[Claudiu]

Compiler error:

C:\DOCUME~1\Claudiu\LOCALS~1\Temp\\mva00000001:325 3: AE_333: Label L_start_17 not defined

I'll try to understand why I have that error when I compile my file and I'll post the result. For the moment I'm still searching :s

[Claudiu]

.. ok found it.. When you have omitted an </mvif> in some function on the top of your file and you have an extra </mvif> in another function in the bottom of the file, the compiler will give you the error above (so.. search or <mvif> loops if you have that error :) )

Best regards

[mvmarkus]

Actually, this isn't entirely new, but obviously hasn't been fixed:

Using the code below, when deserializing large structures with more than 12406 members, Empresa crashes. This only seems to happen on Windows Servers, on FreeBSD the same code performs flawlessly.

Example:
(simply raise g.max when calling the script)

// CREATE STRUCTURE

<MvASSIGN NAME = "l.a" VALUE = "1" >
<MvWHILE EXPR = "{ l.a LE g.max }">
<MvASSIGN NAME = "l.object" VALUE = "{ l.a }" >
<MvASSIGN NAME = "l.struc" MEMBER="{l.object}" VALUE = "{ l.object }" >
<MvASSIGN NAME = "l.a" VALUE = "{ l.a+1 }" >
</MvWHILE>


<BR> STRUC:
<BR><MvEVAL EXPR = "{ l.struc }" >
<BR>
<MvASSIGN NAME = "l.serialized" VALUE = "{ miva_array_serialize( l.struc) }" >
<BR>SERIALIZED: <MvEVAL EXPR = "{ l.serialized }" >
<BR>
<MvASSIGN NAME = "l.deserialized" VALUE = "{ miva_array_deserialize( l.serialized) }" >
<BR>DESERIALIZED <MvEVAL EXPR = "{ l.deserialized }" >
<BR>


Another variation is that structures with longer member names and values, the deserialized result may even be truncated or completely bogus, even when the member count is lower than in the example above.

Markus

[takeover]

5.04 Gives you:

Access denied for user 'user'@'localhost' to database 'dbname''

When clicking the finish button on setup.mvc

currently having this problem, tried empresa 5.06, 5.04, miva 5 pl2, pl3

can't get it installed

[Claudiu]

With this code:

<mvfilter name="{l.alias}" filter_type="variable" filter="{ g.datec CIN miva_variable_value(l.alias$'.d.datec') }">

you have this error when you compile it:

C:\DOCUME~1\Claudiu\LOCALS~1\Temp\\mva00000001:292 7: AE_311: Duplicate string identifier "s_0"
Same problem like aGorilla, you have to assign the dynamic variable to a normal variable to make it works:

<mvassign name="l.aliaz" value="{miva_variable_value(l.alias$'.d.datec')}">

<mvfilter name="{l.alias}" filter_type="variable" filter="{ g.datec CIN l.aliaz }">

PS: Is it me or the server is very slow?

[Vic - WolfPaw Computers]

This is not likely a bug, but rather a user permissions issue with your database permissions. Check from the shell if you can, that you can login to the MySQL database. If you can, then perhaps this is a bug.

I've never encountered it with any of the installs of v5.02, v5.03, or v5.06 with PR1, PR2 or PR3.

currently having this problem, tried empresa 5.06, 5.04, miva 5 pl2, pl3

can't get it installed

[Claudiu]

hm.. I guess there is a major BUG in the new version of the compiler. Almost everything you want to pass in the Filter with the type Variable, you have a compiler exception:

<mvfilter name="{l.alias}" filter_type="variable" filter="{ toupper(g.recherche) CIN l.aliaz }">

C:\DOCUME~1\Claudiu\LOCALS~1\Temp\\mva00000001:295 6: AE_311: Duplicate string identifier "s_0"
it is working like this:

<mvassign name="l.rech" value="{toupper(g.recherche)}">
<mvfilter name="{l.alias}" filter_type="variable" filter="{ l.rech CIN l.aliaz }">

[aGorilla]

Two bugs on Mia, not confirmed on Empressa.

file_create(l.file, 'data', somedb.d.field) Kills Mia
Assigning the db field to a local variable, and then using the local variable in the file_create solves the problem.

using bf_encrypt on an empty string kills Mia.

[wcw]

<MvEVAL EXPR = "{'<br>Debug1: ' $ rnd((.5 * 1),0)}">
<MvEVAL EXPR = "{'<br>Debug2: ' $ rnd((.51 * 1),0)}">
<MvEVAL EXPR = "{'<br>Debug3: ' $ rnd((1.5 * 1),0)}">

yields

Debug1: 0
Debug2: 1
Debug3: 2

The .5 when rounded 0 decimals will round down. But 1.5 rounded with 0 decimals will round up. Can we get this math error fixed?

[mvmarkus]

Hi Bill,

On Windows/Empresa 5.06 this seems to be working correctly, yielding 1,1,2 .

Markus

[wcw]

The server I am on is not running Windows. I didn't test on Mia, but was told by the person who originally told me of the bug that their Mia 5.03 was reporting it correctly. It was just their 5.06 on the server that was messed up.

[wcw]

This bug is apparently much worse. Expanding the test you get

0.5 rounds to 0
1.5 rounds to 2
2.5 rounds to 2
3.5 rounds to 4
4.5 rounds to 4
5.5 rounds to 6
6.5 rounds to 6
7.5 rounds to 8
8.5 rounds to 8

Even numbers round down and odd numbers round up. This has nothing to do with banker rounding. Anybody have any thoughts on it?

Rick - can we get this fixed soon? I realize updating empresa is a major undertaking, but you have to be able to trust a program's math.

[Rick Wilson]

Mark, our new VP of Development, will be posting about this shortly.

[Mark Johnson]

Bill,

Your test is showing the expected output from the rnd function, i.e. a number ending in .5 rounds towards the even number. Here is a simple C test program:

#include "stdio.h"

double d1 = 0.5;
double d2 = 0.51;
double d3 = 1.5;

int main () {
printf( "%.0f %.0f %.0f\n", d1, d2, d3 );
}

It produces the output: "0 1 2"

What you want to use is either int( number + 0.5 ) or floor( number + 0.5 ) depending on what you want to happen with negative numbers.

int( -3.2 ) is -3 but floor( -3.2 ) is -4.


This bug is apparently much worse. Expanding the test you get

0.5 rounds to 0
1.5 rounds to 2
2.5 rounds to 2
3.5 rounds to 4
4.5 rounds to 4
5.5 rounds to 6
6.5 rounds to 6
7.5 rounds to 8
8.5 rounds to 8

Even numbers round down and odd numbers round up. This has nothing to do with banker rounding. Anybody have any thoughts on it?

Rick - can we get this fixed soon? I realize updating empresa is a major undertaking, but you have to be able to trust a program's math.

[wcw]

That is not logical. .5 should be expected to round up in every case. Why is Markus finding on Windows Empresa that it works differently, ie .5 rounds up to 1?

[Mark Johnson]

That is not logical. .5 should be expected to round up in every case. Why is Markus finding on Windows Empresa that it works differently, ie .5 rounds up to 1?


I'm sorry that you don't find it logical, but it is the accepted standard for rounding. That is, since 2.5 is exactly half way between 2 and 3, the choice of which way to round is arbitrary. Someone long ago established the "round towards the even number" rule. The accepted standard in computing is the C language printf function which is why I used it in my example. It is also the reason that it is implemented that way in the MivaScript engine.

I agree with you that if it behaves differently on Windows, that is a problem. I am investigating that now.

[wcw]

Please keep us posted. If that is the accepted method, I can live with that. Course it should work the same way on Windows (and Mia) the same way.

[SpaceMoose]

deleted. ..........
posted in wrong place

[SpaceMoose]

When they find that there are versions of Empressa that give different
results, which version are they going to 'fix'? The useful one?

[Brandon MUS]

http://en.wikipedia.org/wiki/Rounding#Round-to-even_method I think I learn something from Wiki every day :D

PHP does not use the round-to-even method.
<?php printf( "%.0f %.0f %.0f\n", 0.5, 0.51, 1.5); //prints: 1 1 2 ?>

[Mark Johnson]

I have done some research on this issue. Here's what I came up with. The Miva Engine uses the C sprintf function to implement its rnd function and ROUND operator. This is considered a standard way to do rounding. On UNIX systems the sprintf function does the "round to even" method. Unfortuneately on Windows the same function does the "round up" method.

So I decided to look around and see how it's done elsewhere. Brandon MUS posted that PHP uses "round up". Perl uses "round to even". Python uses "round to even". Ruby uses "round up".

I even looked at Microsoft Excel. It has three functions: ROUND, ROUNDUP and ROUNDDOWN. The last two do exactly what you'd expect, but ROUND behaves identically to ROUNDUP.

There is good reason to use the "round to even" method. In calculations on a lot of numbers it avoids the tendency to bias the results in the direction of the rouding. That is going up half the time tends to balance out with the going down half the time.

My inclination is to have Miva behave the same on all platforms and use the "round to even" method. I would also be favorable to the Excel idea and add a "round up" and "round down" function.

Being new here, we thought we would take an informal poll of the developers. So if you hava an opinion, let us know.

[wcw]

In the past I think there has been an issue with the tax getting rounded inconsistently so that one of the payment modules was messing up on rare occasions. I don't know if it was paylink or which one; maybe someone else knows. But that is a consideration on how to do it. Will it mess up a payment module? Apparently this is bankers rounding and since the major reason for mivascript is a shopping cart that deals with money, the round to even might be the way to go.

On the other hand, I vote for the Excel method, ie three different functions, ie rnd(), rndeven(), rndup(). rnd() would stay as it is now, for legacy reasons even though it is not consistant. Those who want to use rndup() function could do it that way. rndeven() would round even on all platforms (windows and unix). The downside is that there is tons of code that are using rnd() and thus inconsistant. So over time, those systems would get changed to the intended rounding system.

Thank you very much for getting back to us.

[dotCOM_host]

I even looked at Microsoft Excel. It has three functions: ROUND, ROUNDUP and ROUNDDOWN. The last two do exactly what you'd expect, but ROUND behaves identically to ROUNDUP.

There is good reason to use the "round to even" method. In calculations on a lot of numbers it avoids the tendency to bias the results in the direction of the rouding. That is going up half the time tends to balance out with the going down half the time.
While that does make things more fair in the long run, it has been a common practice in all fields involving monetary exchanges that you round up - every time. I've seen the "round to even number" before, but that's mostly used in programming areas where you do not necessarily involve money exchanging hands. If you check with your local bank or supermarket or gas station, they always round up to the closest penny. Right or wrong, that's how "everyone in the world" does it in retail and financial businesses.

[Greg B]

In the past I think there has been an issue with the tax getting rounded inconsistently so that one of the payment modules was messing up on rare occasions.

It is still a problem with sales tax and the LinkPoint payment module.

[BillBuilt]

Not sure if this is an Empressa bug or not, but i cannot use MvSMTP at all with my current host. Returns:

Runtime error in test.mvc @ [00000000:0000004c]: D:! My DocumentsMy Web Sitestest.mv: Line 3: MvSMTP: Syntax error - your mail software violates RFC 821.

Raw mail log:

Aug 24 09:16:36 server courieresmtpd: started,ip=[::ffff:69.36.5.142]
Aug 24 09:16:36 server courieresmtpd: HELO server.billbuilt.com
Aug 24 09:16:36 server courieresmtpd: MAIL FROM:bill@billbuilt.com
Aug 24 09:16:36 server courieresmtpd: error,relay=::ffff:69.36.5.142,msg="554 Syntax error - your mail software violates RFC 821.",cmd: MAIL FROM:bill@billbuilt.com

Of course my host tells me its Empressa. Its running linux and using the Courier mail server. I have to resort to calling a php script to do emails, which can be argued is better, and i agree if your wanting to do complex emailing, esp BCC and such, but for very simple text only emailing, this is quite a hassle.

PHP via mail() or using the PEAR mail class works just fine so i am leaning towards some incompatibility in Empressa.

Any help would be appreciated, as i have no idea where to even start with tracking this down. :confused:

Thanks,
Bill M.

[BillBuilt]

Ok i think i got it. Waiting 48 hrs to get my post posted must have forced me to stop trying for a bit and walk away from it, i realized that the server requires the addresses to be surrounded by < >. Simple solution that was being overlooked out of frustration i suppose.


Bill M.

[leslienord]

Sorry for the delay, Bill sometimes I step away.

[BillBuilt]

N/P Sorry if i was rude.... one of those awful "work, work, work and get nothing done" days.

[leslienord]

Naw - I have one of those long laundry lists of work work work too.

[truXoft]

Empresa and Mia v5.06 parse simple arithmetic functions wrong and inconsistently which may lead to completely false results in simple calculations. This happens when an expression is passed through MvDO, and possibly in other MIVA Script tags too. Below there is a sample code demonstrating the fatal bug. Compile it and run to see the illogical results for the simple expression A - B - C. In old versions such expressions worked well; currently it is necessary to transcribe them into logically identical equivalent of A - (B + C) :
<h3>Plain expression</h3>
<MvASSIGN NAME="l.res1" VALUE="{5 - 1 - 3}">
<MvASSIGN NAME="l.res2" VALUE="{5 - (1 + 3)}">
<MvEVAL EXPR="{result(l.res1,l.res2)}">

<h3>Expression in a function argument in MvDO</h3>
<MvDO FILE="test.mvc" NAME="l.res1" VALUE="{test(5 - 1 - 3)}">
<MvDO FILE="test.mvc" NAME="l.res2" VALUE="{test(5 - (1 + 3))}">
<MvEVAL EXPR="{result(l.res1,l.res2)}">

<h3>Expression directly in MvDO</h3>
<MvDO FILE="test.mvc" NAME="l.res1" VALUE="{5 - 1 - 3}">
<MvDO FILE="test.mvc" NAME="l.res2" VALUE="{5 - (1 + 3)}">
<MvEVAL EXPR="{result(l.res1,l.res2)}">

<MvFUNCTION NAME="test" PARAMETERS="val">
<MVFUNCRETURN VALUE="{l.val}">
</MVFUNCTION>

<MvFUNCTION NAME="result" PARAMETERS="val1 VAR, val2 VAR">
<MvIF EXPR="{l.val1 NE l.val2}">
<MVFUNCRETURN VALUE="{'<span style="color:red">' $ l.val1 $ ' != ' $ l.val2 $ '</span>'}">
<MvELSE>
<MVFUNCRETURN VALUE="{l.val1 $ ' == ' $ l.val2}">
</MvIF>
</MVFUNCTION>

The test program should show three times 1 == 1 but instead it shows the incorrect result 7 != 1 for the last two calculations passing the expression through MvDO. MvASSIGN and MvEVAL work correctly, but I suspect the same problem may pop up in other commands too (such as MvFILTER, index expressions, etc).

[Mark Johnson]

Ivo,

Thanks for catching this one. As it is potentially quite serious we have begun looking into it already. I will post when we find a cause and when we expect to have a fix in place.

[Claudiu]

Hello everyone....

Create a file with " <) " inside. Try to call it from another file.. and you'll get:
Runtime error in /yourfile.mvc @ [00000000:0000002c]: W:yourfile.mv: Line 1: MvCALL: Unexpected EOF in tag

Is there any workaround for that problem?

Thanks in advance
Claudiu

[timeshifting]

Hi,
Another bug seems to be XHR POST's from Firefox 3 fail because the XMLHTTPRequest adds the charset to the mime type. It looks like Empressa is doing a literal string match and chokes on the "; charset=UTF=8" part, returning a 500 Internal Server Error on Apache/Linux, and a blank body 200 OK on Mia/Win32.

Normal Post:
Content-Type: application/x-www-form-urlencodedXHR Post:
Content-Type: application/x-www-form-urlencoded; charset=UTF-8It would be good if Empressa could parse the headers correctly as per RFC.

Matt.