View Issue Details

IDProjectCategoryView StatusLast Update
0005764Multi Theft Auto : San AndreasServerpublic2011-12-27 18:12
ReporterTjongAssigned Toccw 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinux 32bitOSUbuntuOS Version10.04.1
Product Version 
Target Version1.1Fixed in Version1.2 
Summary0005764: tonumber on floats returns nil
Description

Since the latest nightly (revision 2288) the lua function "tonumber" returns nil on every string which represents a floating-point-number like "31.77", strings like "36" or "-700" convert fine.
In the version before (revision 2178) the tonumber-function worked also correctly.
It should also be mentioned that this bug is only appearing server-side, client-side, strings like "-37.1257" convert correctly to the number -37.1247
Although I didn't test if it is linux-related or if it happens on windows-servers too.
Marked as "major" as it breaks position parsing from .xml-files which is used in many resources (as in my case)

Steps To Reproduce

addEventHandler("onResourceStart", resourceRoot,
function ()
outputServerLog("Serverside:");
local string = "100";
outputServerLog("tonumber("..string..") = "..tostring(tonumber(string)));
string = "-100";
outputServerLog("tonumber("..string..") = "..tostring(tonumber(string)));
string = "100.1";
outputServerLog("tonumber("..string..") = "..tostring(tonumber(string)));
string = "-100.1";
outputServerLog("tonumber("..string..") = "..tostring(tonumber(string)));
end
);

addEventHandler("onClientResourceStart", resourceRoot,
function (startedResource)
outputConsole("Clientside:");
local string = "100";
outputConsole("tonumber("..string..") = "..tostring(tonumber(string)));
string = "-100";
outputConsole("tonumber("..string..") = "..tostring(tonumber(string)));
string = "100.1";
outputConsole("tonumber("..string..") = "..tostring(tonumber(string)));
string = "-100.1";
outputConsole("tonumber("..string..") = "..tostring(tonumber(string)));
end
);

TagsNo tags attached.

Activities

izstas

2011-01-08 14:28

developer   ~~0012502

Unable to reproduce on Windows (1.1 r2292)

impulze?

onestone

2011-01-08 15:25

viewer   ~~0012503

Works like it should here (1.1 custom)

impulze

2011-01-08 17:16

developer   ~~0012504

yup fails for me, will work on it

impulze

2011-01-09 04:24

developer   ~~0012512

Last edited: 2011-01-09 05:32

ok this is a bit complicated, i'll explain the situation:
recently code was added to make the curses server interface handle unicode (and other charsets) input correctly, that is '…' is one entity instead of a 3 byte char sequence reutrned individually.
if however the code persists and ncurses can correctly handle this input than the locales need to be set program wide as C cannot set locales for partial descriptors.
using locales will result in LUA not treating input like "12.34" as possible number in certain locales where the number separator is ','.
if we disable locales globally we get 3 individual chars returned by ncurses getch() which is fine but there's no chance that we could guess when a sequence is complete and can be converted to its unicode (other charset) counterpart. i was hoping to achieve that with c++ locales feature because they had a partial return value when converting but that didn't work out so well. another benefit of using c++ locales is the chance to work with locales individually and not program wide.
the current "fix" is to disable locales before every call to the lua interpreter, this is quite expensive as one can imagine and should not be a long term solution (this is what i will commit right after saving this).
i appreciate any advice on how to solve the current situation :)

editor thinks:
as a solution we could also probably let iostreams (not ncurses) with the specific locale read in another thread and communicate with that thread over a safe pipe or read from iostream with nonblocking sockets and a custom streambuf or similar, that's what i found on the net :)

Tjong

2011-12-19 01:46

viewer   ~~0015408

This broke again.
Same operating System (Ubuntu Linux x86)
Same way it appears (Serverside only).
Same way to reproduce.

arranTuna

2011-12-27 12:42

manager   ~~0015535

Isn't this fixed?

http://code.google.com/p/mtasa-blue/source/detail?r=3561

W

2011-12-27 18:10

viewer   ~~0015542

It is.

Issue History

Date Modified Username Field Change