Some recent changes in the Gmp module seems to make it not load under certain circumstances:
| % pike 'werror("%O\n",84729847928734928374928374928347)' | Gmp.mpz conversion failed. | ./master.pike:251: | master()->compile_string("#define NOT(X) !(X)\n#define CHAR(X) 'X'\nmixed | run(int argc, array(string) argv,mapping(string:string) env){werror("%O\n",84729847928734928374928374928347);}",0,0)
| % pike 'werror("%O\n",Gmp.mpz);' | Gmp.mpz
I verified that the first never installs auto_bignum_program, but the forced module initiation in the second does.
Note: This is also broken in the pike previous to my INT_TYPE hacking.
/ Mirar
Previous text:
2003-01-26 23:54: Subject: INT_TYPE = INT64
Ah.
Benchmarks:
test 64-bit integers 32-bit integers Pike start overhead...... 0.000s 0.000s Ackermann................ 0.635s 0.610s Array & String Juggling.. 0.693s 0.654s Clone null-object........ 0.190s 22105263 0.181s 36482412/s Clone object............. 0.366s 7386018 0.396s 8325688/s Compile.................. 1.132s 85263 1.066s 113227 lines/s Compile & Exec........... -error- -error- GC....................... 0.580s 0.601s Matrix multiplication.... -error- -error- Loops Nested (local)..... 0.331s 506864532 0.316s 743967044 iters/s Loops Nested (global).... 0.537s 218639251 0.487s 310263584 iters/s Loops Recursed........... 1.045s 4013688 1.312s 3195660 iters/s
Both with 12-byte svalues (ie, double precision floats). Note that recursing loops seems to be faster (?!?) with 64-bit integers.
/ Mirar