|Title:||Error in timeline (armv5tel-linux) showing events|
|Last Modified:||2011-05-13 16:08:19|
|Version Found In:||[cf178577ec]|
This comes from further investigating of the problem quite bad reported at [f1c75f3844687].
I got confused again when I said it was about time (I missed one unsynched local 'fossil ui' with the server).
So, as said, you can clone that repository: http://vicerveza.homeunix.net/~viric/cgi-bin/nanonixos You will see in the timeline of the server that the event related to the artifact 4d12cabdeca86a71190c39b1e458faae4fad0faf does not appear in the timeline. But I imagine it will appear in your local fossil timeline.
I've investigated a bit...
That server (vicerveza.homeunix.net) running fossil as a cgi is an armv5tel-linux. I tried there fossil [cf178577ec] 2010-11-17 and fossil [12a79e5b93] 2010-10-05). Both show the same behaviour: the event of that artifact is not shown in the timeline. I've tried in all the cases a 'rebuild'.
Nevertheless, if I clone that in an x86_64-linux, I don't have any problem in the local 'fossil ui', using the [cf178577ec] 2010-11-17 version.
The server, to give more details, has gcc 4.5.1, glibc 2.12.1, and all fossil tests passed after building.
anonymous claiming to be viric added on 2010-11-30 19:40:51:
sqlite> SELECT * from event WHERE event.type='e'; e|2455530.46353009|168|19||||viric||The malta keyboard does not work still| e|2455530.49096065|169|20||||viric||links2 not working in graphics mode|
anonymous claiming to be viric added on 2010-11-30 20:06:55:
282,283c285,288 < SELECT rid FROM tagxref WHERE tagid=11 AND mtime<2455525.422407407 ORDER BY mtime DESC; < SELECT rid FROM tagxref WHERE tagid=11 AND mtime>2455525.422407407 ORDER BY mtime; --- > SELECT rid FROM tagxref WHERE tagid=11 AND mtime<2455525.422407408 ORDER BY mtime DESC; > DELETE FROM event WHERE type='e' AND tagid=11 AND objid IN (SELECT rid FROM tagxref WHERE tagid=11); > SELECT rid FROM tagxref WHERE tagid=11 AND mtime>2455525.422407408 ORDER BY mtime; > REPLACE INTO event(type,mtime,objid,tagid,user,comment,bgcolor)VALUES('e',2455525.421157408,74,11,'viric','Nanonote boot', (SELECT value FROM tagxref WHERE tagid=1 AND rid=74));
I think there may be a problem on floating point precision / algorithms. The armv5tel cpu does not have a FPU, and it uses gcc's -msoft-float.
anonymous claiming to be viric added on 2010-11-30 20:33:57:
p->rDate = db_double(0.0, "SELECT julianday(%Q)", next_token(&x,0));
While the tag_insert called in manifest_crosslink() does:
db_prepare(&s, "REPLACE INTO tagxref(tagid,tagtype,srcId,origid,value,mtime,rid)" " VALUES(%d,%d,%d,%d,%Q,:mtime,%d)", tagid, tagtype, srcId, rid, zValue, rid ); db_bind_double(&s, ":mtime", mtime);
While the call at manifest_crosslink() does:
prior = db_int(0, "SELECT rid FROM tagxref" " WHERE tagid=%d AND mtime<%.17g" " ORDER BY mtime DESC", tagid, p->rDate );
I think that the %.17g printf kind of prompt should be moved into db_bind_double, as before. Otherwise there may be rounding problems, like those I am experiencing.
Notice that the tag_insert resulted, in both computers, in:
REPLACE INTO tagxref(tagid,tagtype,srcId,origid,value,mtime,rid) VALUES(11,1,74,74,'365',2455525.42240741,74);
While the printf-style SQL queries with %.17g had different results in the two computers.
anonymous claiming to be viric added on 2011-01-10 08:20:18 UTC:
viriketo added on 2011-05-13 16:08:19 UTC: