#5 Worldfile parser expecting float error

[Youssef]

Hi,

Tried to build polyworld on Linux Mint 14 like one of the reviewers who said it worked no problem but I get errors:

• first when trying to build I get an error on 'qtversion' not declared in the scope (lines 98 & 126)
• when I declare 'qtversion' and give it a value, build runs successfully. Then I try to launch polyworld with an empty worldfile (touch empty.wfs). I get errors like './etc/worldfile.wfs:2260: ERROR! Expecting float'.

2255 BarrierColor {
2256 type Color
2257 default {
2258 R 0.35
2259 G 0.25
2260 B 0.15
2261 }
2262 }

Wordfile parser doesn't recognize numbers with dots as float numbers. If I remove the dot the number becomes integer and I don't get the error.
I'm running all this on a Virtualbox VM over Windows. Do you think it might be related ?
I can't do otherwise but to run it in a VM so please help me solve this.

Thank you

[sean]

I encountered the same 'qtversion' problem as you. Looks like a change for Mac broke Linux. Glad you worked around it.

I can't recreate your problem, which is bad. My first suspicion is that this is an issue of memory corruption. Running with valgrind, I see tons of violations coming out of the Python interpreter, which is used for parsing the worldfile. I'll look into that.

[sean]

I don't know if all the errors reported by valgrind are a red herring or not. I've discovered that even the following simple program generates TONS of errors from valgrind:

#include <Python.h>

int main(int argc, char **argv) {
    Py_Initialize();

    PyRun_SimpleString( "print 'hi'" );

    return 0;
}

This wasn't the case in the past. I'll keep investigating, although, it'll have to wait until tomorrow.

[Larry Yaeger]

Youssef - Can you confirm that you have the latest version of the code? There was a problem with passing the result of a Python eval on the stack to other code that produced exactly this failure mode, but placing the results of the eval in a local variable solved the problem. That code was checked in quite a while ago (about a year), so I doubt this is what is causing your problems, but it sounded familiar enough I thought I'd check and make sure.

[Youssef]

Hello,

Thank you for replying so fast.

As for Larry's question I have checked out the code from the head branch using the command specified in the installation instructions: 'cvs -d:pserver:anonymous@polyworld.cvs.sf.net:/cvsroot/polyworld checkout -P polyworld' (from http://shinyverse.org/larryy/BuildingPolyworld.html#Linux). I tried with an older branch but it gave me some other errors so I didn't dive too much into it.

As for sean's comment: I am using python 2.7 and the last user review posted on 02/11/2013 suggests that it worked out of the box for him. Does it mean that some library has changed in python since ? I'll see if I can revert to an older python build. In the meantime has anything changed in polyworld's code ? I'm used to SVN and I find it much harder browsing through change history in CVS.

[Markus Moeller]

Hi all!

I've tried to build polyworld under Xubuntu 14.04 with german language settings and I ran into the same error like Youssef: ./etc/worldfile.wfs:1077: ERROR! Expecting float

After a long debugging session using eclipse and some web investigation, I found a solution that works for me.

In file proplib/dom.cp I've made a small change in method __ScalarProperty::toFloat():

added: char *saved_locale = setlocale(LC_NUMERIC, "C");
float result = (float)strtof( evaled.c_str(), &end );
added: setlocale(LC_NUMERIC, saved_locale);

Maybe Qt does some unexpected changes to the locale settings, if you run under a different language then english.

By the way: The linking stage always breaks with an error because two libraries are missing: pthread and dl.

[Larry Yaeger]

Thank you, Markus! And good sleuthing. I think you've nailed the underlying cause, and explained why Sean and I weren't able to reproduce this back in the States. This will get into the source base.

[Larry Yaeger]

I'ved checked in this change, to keep others from getting hit by this, but I think I'd rather remove this from here and set the locale to "C" soon after launch, as it will be safer and much more efficient. And we want to read and write the same files no matter where the code is run. I don't think we even need to save the current locale and set it back, since I suspect this is for this process only, though that should be confirmed. (If not, there would be issues associated with crashes between a change and a restore, but I'm pretty sure it's not a problem.)

[Larry Yaeger]

Markus - If you wouldn't mind testing something, could you please remove the changes you made to dom.cp and place a setlocale(LC_NUMERIC, "C") call after line 123 of main/main.cp? (Just before the "new TSimulation" line.) And let us know if this still fixes the problem for you?

I'm not sure exactly where Qt invokes the system locale, and can't test this easily here. Well, I can try changing the locale on my Mac and see if I can reproduce the problem and then test the fix. I'll do that if I don't hear anything back in a couple of days.

[Markus Moeller]

Hello Larry,

I've removed my changes from file dom.cp and added the line setlocale(LC_NUMERIC, "C") as you suggested. Polyworld now starts and everything works fine.

Best regards

[Larry Yaeger]

That is excellent news, Markus. Thanks verifying the fix, in addition to identifying and solving the problem in the first place!