Active Topics
-
Error after installing Leste on sdcard (13)
to Maemo 7 / Leste by Maemish - 14 hrs, 49 mins ago -
TLS 1.2 for N9 is ready (29)
to MeeGo / Harmattan by smatkovi - 23 hrs, 38 mins ago -
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 4 days, 8 hrs ago -
Maemo repository (3)
to Community by torsen - 5 days, 1 hr ago - more...
|
2010-04-05
, 23:27
|
|
Posts: 49 |
Thanked: 41 times |
Joined on Apr 2010
|
#2
|
It would be a big bug in libc if that really happened without any problems in the source code. Most probably, it's just a bad code. Do you have a small example of the fscanf call and a file on which it fails?
|
|
2010-04-05
, 23:34
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#3
|
Originally Posted by viraptor
I was thinking it could have something to do with floating points on the N900, but I don't if that's an issue at all?
It would be a big bug in libc if that really happened without any problems in the source code. Most probably, it's just a bad code. Do you have a small example of the fscanf call and a file on which it fails?
The relevant part of the code which does the reading is this:
Code:
while(fscanf(file, "%s", buf) != EOF) {
switch(buf[0]) {
case '#': /* comment */
/* eat up rest of line */
fgets(buf, sizeof(buf), file);
break;
case 'v': /* v, vn, vt */
switch(buf[1]) {
case '\0': /* vertex */
fscanf(file, "%f %f %f",
&vertices[3 * numvertices + X],
&vertices[3 * numvertices + Y],
&vertices[3 * numvertices + Z]);
numvertices++;
break;
// ...
Code:
v 0.956776 2.407918 1.846345 v -1.020031 2.407918 1.846345 v 1.097976 2.223070 1.697290 v -1.161232 2.223070 1.697290 v 1.203877 2.096724 1.467326 v -1.267132 2.096724 1.467326 v 0.762625 1.936465 1.582468 v -0.825880 1.936465 1.582468 v 0.762625 2.094863 1.789404 v -0.825880 2.094863 1.789404 v 0.762625 2.343815 1.892402 v -0.825880 2.343815 1.892402 v 0.586125 2.419122 1.916050 v -0.649380 2.419122 1.916050 v 0.427274 2.242678 1.819275 v -0.490529 2.242678 1.819275
http://www.cs.jhu.edu/~subodh/457/code/gltutor/glm.h
http://www.cs.jhu.edu/~subodh/457/code/gltutor/glm.c
In addition I'm printing the values to the console using this loop:
Code:
for(int i = 0; i < numvertices; i++) {
qDebug() << "out" << vertices[i];
}
|
|
2010-04-06
, 01:39
|
|
Posts: 49 |
Thanked: 41 times |
Joined on Apr 2010
|
#4
|
A quick check (scanf("%f", &blah); printf("%f", blah);) shows that it should work. Maybe you can try your app with valgrind to make sure there are no strange overflows?
Are you printing the values out after the whole loop, or right after the scanf?
Are you printing the values out after the whole loop, or right after the scanf?
 |
|
2010-04-06
, 09:06
|
|
Posts: 1,637 |
Thanked: 4,424 times |
Joined on Apr 2009
@ Germany
|
#5
|
Hello,
as far as I know, scanf uses the current locale setting to determine
which char is used as "decimal_point".
You can view your locale settings with the command "locale".
With locale settings for germany for example:
nicolai
as far as I know, scanf uses the current locale setting to determine
which char is used as "decimal_point".
You can view your locale settings with the command "locale".
With locale settings for germany for example:
Code:
~$ locale LANG=de_DE LC_CTYPE="de_DE" LC_NUMERIC=de_DE LC_TIME=de_DE ....
Code:
~ $ locale -ck decimal_point LC_NUMERIC decimal_point =","
|
|
2010-04-06
, 19:50
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#6
|
@viraptor: Thanks for checking! You pointed me in the direction of the solution, which is the one nicolai mentions. I printed out the values with printf instead of qDebug() and I figured that printed it out with commas instead of dots.
@nicolai: Thanks a bunch for pointing that out
My locale uses commas as decimal points, so that's exactly why it couldn't read the file. I'm using
to set the locale to dots now.
Is this a good way to do this?
@nicolai: Thanks a bunch for pointing that out
My locale uses commas as decimal points, so that's exactly why it couldn't read the file. I'm usingCode:
setlocale(LC_NUMERIC, "en_US");
Is this a good way to do this?
Running an application using the library on a Ubuntu desktop works flawlessly, but when running on a real N900 device it reads out only the integers -1, 0 and 1 - which are not even the rounded equivalents of the floating point numbers in the file!
I could of course dive into reading the file using Qt instead, with hope that it would fix the problem, but I'm wondering if this is a common issue or whether it could be fixed in some other way?