What's going on here?
| > for (int i=0; i<20; i++) werror((int)(((array(string))map(allocate(4,10000),random))*"")+"\n"); | 893854041314521p21222729747995344996322460933134167912308396922p465893192590510p409578404318720p249661099356465p9779173639706553527891623852799p763437599009880p923963626066665p195530491701805328348545865448 | 914429367511157p851488744731279p771291049428341p3407258449383175982468099614413597240422810389
Where did my linebreaks go and where did the p come from?
In a sidenote, why doesn't
| > random(10000000000000000); | (3) Result: 694383321
work as expected, when
| > random(100000000000000000000000000000); | (2) Result: 1637481850962819326860743609
does?
I can't reproduce this problem. What pike version, and what $TERM?
In a sidenote, why doesn't
| > random(10000000000000000); | (3) Result: 694383321
work as expected, when
| > random(100000000000000000000000000000); | (2) Result: 1637481850962819326860743609
does?
I expect it's because different code is used depending on whether the argument is a bignum or not. It seems like the code generating non-bignum random numbers is limited to generating 32 bits of random data (a bug).
i can reproduce both problems on debians pike 7.6.93, (only except for p i get _ or something that looks like | (but appears to actually be an something else because i can't copy it))
i don't get it on foresight with 7.6.66 or 7.6.123
greetings, martin.
with sprintf the debian 7.6.93 result is:
string out = ""; for (int i=0; i<20; i++) out += sprintf((int)(((array(string))map(allocate(4,10000),random))*"")+"\n");
Ok.
out;
(9) Result: "512414118028748\377\377""514320887889152\0""457842133200969\377\377""607690038740522\377\377""202488178683876\377\377""96477124435450\n773139628763742\377\377""255399511923228\0""254522951099188\0""802040014219508\377\377""803918081465792\377\377""998629206208493\377\377""304851165967488\377\377""880148392734681\377\377""846458511765800\377\377""996519023418148\377\377""672055517085323\377\377""313097474123368\377\377""24681413227467\n239985713637392\377\377"
greetings, martin.
I can't reproduce this with either 7.6.92 or 7.6.94 built manually on Ubuntu. So unless the problem both appeared and disappeard somewhere during the 7.6.93 development cycle, it has to be either A) due to a debian patch (seems unlikely since Mirar says his Pike was from CVS) or B) depending on the environment...
or depending on build-options? (32vs64bit integers could be related)
btw: i am on an AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
$ pike --features dynamic_modules threads out-of-band_data double_precision_float Nettle GL GLUT Gdbm Gmp Gz Image.FreeType Image.GIF Image.JPEG Image.TIFF Image.TTF Image.XFace Image.PNG Mysql Odbc Perl Postgres SANE SDL Yp
hmm, it does not say anything about 32vs64bit int, should it?
greetings, martin.
The first problem seems to be gone away in the latest 7.7, so I guess that's fine for the release. It still exist in 7.6.112 though:
| iris% pike-7.6 | Pike v7.6 release 112 running Hilfe v3.5 (Incremental Pike Frontend) | > array v=({}); for (int i=0; i<20; i++) v+=({sprintf("%O",(int)(((array(string))map(allocate(4,10000),random))*"")+"\n")}); v; | Ok. | (1) Result: ({ /* 20 elements */ | ""208176497569259=q"", | ""188681663108716\0\6"", | ""172266799098724\0"", | ""407912122940221\0\6"", | ""209810401836443 "", ... | ""8069752126687216"", | ""838151634002940\0\6"", | ""332053621899662\0\6"" | }) |
I doubt TERM has anything to do with it, it seems to be a sprintf problem. Pike is random from CVS at some point. I'm updating right now to see if I still can reproduce the problem.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Bähr
-
Mirar ＠ Pike developers forum