1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266 5267 5268 5269 5270 5271 5272 5273 5274 5275 5276 5277 5278 5279 5280 5281 5282 5283 5284 5285 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 5306 5307 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 5325 5326 5327 5328 5329 5330 5331 5332 5333 5334 5335 5336 5337 5338 5339 5340 5341 5342 5343 5344 5345 5346 5347 5348 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5439 5440 5441 5442 5443 5444 5445 5446 5447 5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 5721 5722 5723 5724 5725 5726 5727 5728 5729 5730 5731 5732 5733 5734 5735 5736 5737 5738 5739 5740 5741 5742 5743 5744 5745 5746 5747 5748 5749 5750 5751 5752 5753 5754 5755 5756 5757 5758 5759 5760 5761 5762 5763 5764 5765 5766 5767 5768 5769 5770 5771 5772 5773 5774 5775 5776 5777 5778 5779 5780 5781 5782 5783 5784 5785 5786 5787 5788 5789 5790 5791 5792 5793 5794 5795 5796 5797 5798 5799 5800 5801 5802 5803 5804 5805 5806 5807 5808 5809 5810 5811 5812 5813 5814 5815 5816 5817 5818 5819 5820 5821 5822 5823 5824 5825 5826 5827 5828 5829 5830 5831 5832 5833 5834 5835 5836 5837 5838 5839 5840 5841 5842 5843 5844 5845 5846 5847 5848 5849 5850 5851 5852 5853 5854 5855 5856 5857 5858 5859 5860 5861 5862 5863 5864 5865 5866 5867 5868 5869 5870 5871 5872 5873 5874 5875 5876 5877 5878 5879 5880 5881 5882 5883 5884 5885 5886 5887 5888 5889 5890 5891 5892 5893 5894 5895 5896 5897 5898 5899 5900 5901 5902 5903 5904 5905 5906 5907 5908 5909 5910 5911 5912 5913 5914 5915 5916 5917 5918 5919 5920 5921 5922 5923 5924 5925 5926 5927 5928 5929 5930 5931 5932 5933 5934 5935 5936 5937 5938 5939 5940 5941 5942 5943 5944 5945 5946 5947 5948 5949 5950 5951 5952 5953 5954 5955 5956 5957 5958 5959 5960 5961 5962 5963 5964 5965 5966 5967 5968 5969 5970 5971 5972 5973 5974 5975 5976 5977 5978 5979 5980 5981 5982 5983 5984 5985 5986 5987 5988 5989 5990 5991 5992 5993 5994 5995 5996 5997 5998 5999 6000 6001 6002 6003 6004 6005 6006 6007 6008 6009 6010 6011 6012 6013 6014 6015 6016 6017 6018 6019 6020 6021 6022 6023 6024 6025 6026 6027 6028 6029 6030 6031 6032 6033 6034 6035 6036 6037 6038 6039 6040 6041 6042 6043 6044 6045 6046 6047 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6061 6062 6063 6064 6065 6066 6067 6068 6069 6070 6071 6072 6073 6074 6075 6076 6077 6078 6079 6080 6081 6082 6083 6084 6085 6086 6087 6088 6089 6090 6091 6092 6093 6094 6095 6096 6097 6098 6099 6100 6101 6102 6103 6104 6105 6106 6107 6108 6109 6110 6111 6112 6113 6114 6115 6116 6117 6118 6119 6120 6121 6122 6123 6124 6125 6126 6127 6128 6129 6130 6131 6132 6133 6134 6135 6136 6137 6138 6139 6140 6141 6142 6143 6144 6145 6146 6147 6148 6149 6150 6151 6152 6153 6154 6155 6156 6157 6158 6159 6160 6161 6162 6163 6164 6165 6166 6167 6168 6169 6170 6171 6172 6173 6174 6175 6176 6177 6178 6179 6180 6181 6182 6183 6184 6185 6186 6187 6188 6189 6190 6191 6192 6193 6194 6195 6196 6197 6198 6199 6200 6201 6202 6203 6204 6205 6206 6207 6208 6209 6210 6211 6212 6213 6214 6215 6216 6217 6218 6219 6220 6221 6222 6223 6224 6225 6226 6227 6228 6229 6230 6231 6232 6233 6234 6235 6236 6237 6238 6239 6240 6241 6242 6243 6244 6245 6246 6247 6248 6249 6250 6251 6252 6253 6254 6255 6256 6257 6258 6259 6260 6261 6262 6263 6264 6265 6266 6267 6268 6269 6270 6271 6272 6273 6274 6275 6276 6277 6278 6279 6280 6281 6282 6283 6284 6285 6286 6287 6288 6289 6290 6291 6292 6293 6294 6295 6296 6297 6298 6299 6300 6301 6302 6303 6304 6305 6306 6307 6308 6309 6310 6311 6312 6313 6314 6315 6316 6317 6318 6319 6320 6321 6322 6323 6324 6325 6326 6327 6328 6329 6330 6331 6332 6333 6334 6335 6336 6337 6338 6339 6340 6341 6342 6343 6344 6345 6346 6347 6348 6349 6350 6351 6352 6353 6354 6355 6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367 6368 6369 6370 6371 6372 6373 6374 6375 6376 6377 6378 6379 6380 6381 6382 6383 6384 6385 6386 6387 6388 6389 6390 6391 6392 6393 6394 6395 6396 6397 6398 6399 6400 6401 6402 6403 6404 6405 6406 6407 6408 6409 6410 6411 6412 6413 6414 6415 6416 6417 6418 6419 6420 6421 6422 6423 6424 6425 6426 6427 6428 6429 6430 6431 6432 6433 6434 6435 6436 6437 6438 6439 6440 6441 6442 6443 6444 6445 6446 6447 6448 6449 6450 6451 6452 6453 6454 6455 6456 6457 6458 6459 6460 6461 6462 6463 6464 6465 6466 6467 6468 6469 6470 6471 6472 6473 6474 6475 6476 6477 6478 6479 6480 6481 6482 6483 6484 6485 6486 6487 6488 6489 6490 6491 6492 6493 6494 6495 6496 6497 6498 6499 6500 6501 6502 6503 6504 6505 6506 6507 6508 6509 6510 6511 6512 6513 6514 6515 6516 6517 6518 6519 6520 6521 6522 6523 6524 6525 6526 6527 6528 6529 6530 6531 6532 6533 6534 6535 6536 6537 6538 6539 6540 6541 6542 6543 6544 6545 6546 6547 6548 6549 6550 6551 6552 6553 6554 6555 6556 6557 6558 6559 6560 6561 6562 6563 6564 6565 6566 6567 6568 6569 6570 6571 6572 6573 6574 6575 6576 6577 6578 6579 6580 6581 6582 6583 6584 6585 6586 6587 6588 6589 6590 6591 6592 6593 6594 6595 6596 6597 6598 6599 6600 6601 6602 6603 6604 6605 6606 6607 6608 6609 6610 6611 6612 6613 6614 6615 6616 6617 6618 6619 6620 6621 6622 6623 6624 6625 6626 6627 6628 6629 6630 6631 6632 6633 6634 6635 6636 6637 6638 6639 6640 6641 6642 6643 6644 6645 6646 6647 6648 6649 6650 6651 6652 6653 6654 6655 6656 6657 6658 6659 6660 6661 6662 6663 6664 6665 6666 6667 6668 6669 6670 6671 6672 6673 6674 6675 6676 6677 6678 6679 6680 6681 6682 6683 6684 6685 6686 6687 6688 6689 6690 6691 6692 6693 6694 6695 6696 6697 6698 6699 6700 6701 6702 6703 6704 6705 6706 6707 6708 6709 6710 6711 6712 6713 6714 6715 6716 6717 6718 6719 6720 6721 6722 6723 6724 6725 6726 6727 6728 6729 6730 6731 6732 6733 6734 6735 6736 6737 6738 6739 6740 6741 6742 6743 6744 6745 6746 6747 6748 6749 6750 6751 6752 6753 6754 6755 6756 6757 6758 6759 6760 6761 6762 6763 6764 6765 6766 6767 6768 6769 6770 6771 6772 6773 6774 6775 6776 6777 6778 6779 6780 6781 6782 6783 6784 6785 6786 6787 6788 6789 6790 6791 6792 6793 6794 6795 6796 6797 6798 6799 6800 6801 6802 6803 6804 6805 6806 6807 6808 6809 6810 6811 6812 6813 6814 6815 6816 6817 6818 6819 6820 6821 6822 6823 6824 6825 6826 6827 6828 6829 6830 6831 6832 6833 6834 6835 6836 6837 6838 6839 6840 6841 6842 6843 6844 6845 6846 6847 6848 6849 6850 6851 6852 6853 6854 6855 6856 6857 6858 6859 6860 6861 6862 6863 6864 6865 6866 6867 6868 6869 6870 6871 6872 6873 6874 6875 6876 6877 6878 6879 6880 6881 6882 6883 6884 6885 6886 6887 6888 6889 6890 6891 6892 6893 6894 6895 6896 6897 6898 6899 6900 6901 6902 6903 6904 6905 6906 6907 6908 6909 6910 6911 6912 6913 6914 6915 6916 6917 6918 6919 6920 6921 6922 6923 6924 6925 6926 6927 6928 6929 6930 6931 6932 6933 6934 6935 6936 6937 6938 6939 6940 6941 6942 6943 6944 6945 6946 6947 6948 6949 6950 6951 6952 6953 6954 6955 6956 6957 6958 6959 6960 6961 6962 6963 6964 6965 6966 6967 6968 6969 6970 6971 6972 6973 6974 6975 6976 6977 6978 6979 6980 6981 6982 6983 6984 6985 6986 6987 6988 6989 6990 6991 6992 6993 6994 6995 6996 6997 6998 6999 7000 7001 7002 7003 7004 7005 7006 7007 7008 7009 7010 7011 7012 7013 7014 7015 7016 7017 7018 7019 7020 7021 7022 7023 7024 7025 7026 7027 7028 7029 7030 7031 7032 7033 7034 7035 7036 7037 7038 7039 7040 7041 7042 7043 7044 7045 7046 7047 7048 7049 7050 7051 7052 7053 7054 7055 7056 7057 7058 7059 7060 7061 7062 7063 7064 7065 7066 7067 7068 7069 7070 7071 7072 7073 7074 7075 7076 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7097 7098 7099 7100 7101 7102 7103 7104 7105 7106 7107 7108 7109 7110 7111 7112 7113 7114 7115 7116 7117 7118 7119 7120 7121 7122 7123 7124 7125 7126 7127 7128 7129 7130 7131 7132 7133 7134 7135 7136 7137 7138 7139 7140 7141 7142 7143 7144 7145 7146 7147 7148 7149 7150 7151 7152 7153 7154 7155 7156 7157 7158 7159 7160 7161 7162 7163 7164 7165 7166 7167 7168 7169 7170 7171 7172 7173 7174 7175 7176 7177 7178 7179 7180 7181 7182 7183 7184 7185 7186 7187 7188 7189 7190 7191 7192 7193 7194 7195 7196 7197 7198 7199 7200 7201 7202 7203 7204 7205 7206 7207 7208 7209 7210 7211 7212 7213 7214 7215 7216 7217 7218 7219 7220 7221 7222 7223 7224 7225 7226 7227 7228 7229 7230 7231 7232 7233 7234 7235 7236 7237 7238 7239 7240 7241 7242 7243 7244 7245 7246 7247 7248 7249 7250 7251 7252 7253 7254 7255 7256 7257 7258 7259 7260 7261 7262 7263 7264 7265 7266 7267 7268 7269 7270 7271 7272 7273 7274 7275 7276 7277 7278 7279 7280 7281 7282 7283 7284 7285 7286 7287 7288 7289 7290 7291 7292 7293 7294 7295 7296 7297 7298 7299 7300 7301 7302 7303 7304 7305 7306 7307 7308 7309 7310 7311 7312 7313 7314 7315 7316 7317 7318 7319 7320 7321 7322 7323 7324 7325 7326 7327 7328 7329 7330 7331 7332 7333 7334 7335 7336 7337 7338 7339 7340 7341 7342 7343 7344 7345 7346 7347 7348 7349 7350 7351 7352 7353 7354 7355 7356 7357 7358 7359 7360 7361 7362 7363 7364 7365 7366 7367 7368 7369 7370 7371 7372 7373 7374 7375 7376 7377 7378 7379 7380 7381 7382 7383 7384 7385 7386 7387 7388 7389 7390 7391 7392 7393 7394 7395 7396 7397 7398 7399 7400 7401 7402 7403 7404 7405 7406 7407 7408 7409 7410 7411 7412 7413 7414 7415 7416 7417 7418 7419 7420 7421 7422 7423 7424 7425 7426 7427 7428 7429 7430 7431 7432 7433 7434 7435 7436 7437 7438 7439 7440 7441 7442 7443 7444 7445 7446 7447 7448 7449 7450 7451 7452 7453 7454 7455 7456 7457 7458 7459 7460 7461 7462 7463 7464 7465 7466 7467 7468 7469 7470 7471 7472 7473 7474 7475 7476 7477 7478 7479 7480 7481 7482 7483 7484 7485 7486 7487 7488 7489 7490 7491 7492 7493 7494 7495 7496 7497 7498 7499 7500 7501 7502 7503 7504 7505 7506 7507 7508 7509 7510 7511 7512 7513 7514 7515 7516 7517 7518 7519 7520 7521 7522 7523 7524 7525 7526 7527 7528 7529 7530 7531 7532 7533 7534 7535 7536 7537 7538 7539 7540 7541 7542 7543 7544 7545 7546 7547 7548 7549 7550 7551 7552 7553 7554 7555 7556 7557 7558 7559 7560 7561 7562 7563 7564 7565 7566 7567 7568 7569 7570 7571 7572 7573 7574 7575 7576 7577 7578 7579 7580 7581 7582 7583 7584 7585 7586 7587 7588 7589 7590 7591 7592 7593 7594 7595 7596 7597 7598 7599 7600 7601 7602 7603 7604 7605 7606 7607 7608 7609 7610 7611 7612 7613 7614 7615 7616 7617 7618 7619 7620 7621 7622 7623 7624 7625 7626 7627 7628 7629 7630 7631 7632 7633 7634 7635 7636 7637 7638 7639 7640 7641 7642 7643 7644 7645 7646 7647 7648 7649 7650 7651 7652 7653 7654 7655 7656 7657 7658 7659 7660 7661 7662 7663 7664 7665 7666 7667 7668 7669 7670 7671 7672 7673 7674 7675 7676 7677 7678 7679 7680 7681 7682 7683 7684 7685 7686 7687 7688 7689 7690 7691 7692 7693 7694 7695 7696 7697 7698 7699 7700 7701 7702 7703 7704 7705 7706 7707 7708 7709 7710 7711 7712 7713 7714 7715 7716 7717 7718 7719 7720 7721 7722 7723 7724 7725 7726 7727 7728 7729 7730 7731 7732 7733 7734 7735 7736 7737 7738 7739 7740 7741 7742 7743 7744 7745 7746 7747 7748 7749 7750 7751 7752 7753 7754 7755 7756 7757 7758 7759 7760 7761 7762 7763 7764 7765 7766 7767 7768 7769 7770 7771 7772 7773 7774 7775 7776 7777 7778 7779 7780 7781 7782 7783 7784 7785 7786 7787 7788 7789 7790 7791 7792 7793 7794 7795 7796 7797 7798 7799 7800 7801 7802 7803 7804 7805 7806 7807 7808 7809 7810 7811 7812 7813 7814 7815 7816 7817 7818 7819 7820 7821 7822 7823 7824 7825 7826 7827 7828 7829 7830 7831 7832 7833 7834 7835 7836 7837 7838 7839 7840 7841 7842 7843 7844 7845 7846 7847 7848 7849 7850 7851 7852 7853 7854 7855 7856 7857 7858 7859 7860 7861 7862 7863 7864 7865 7866 7867 7868 7869 7870 7871 7872 7873 7874 7875 7876 7877 7878 7879 7880 7881 7882 7883 7884 7885 7886 7887 7888 7889 7890 7891 7892 7893 7894 7895 7896 7897 7898 7899 7900 7901 7902 7903 7904 7905 7906 7907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 7921 7922 7923 7924 7925 7926 7927 7928 7929 7930 7931 7932 7933 7934 7935 7936 7937 7938 7939 7940 7941 7942 7943 7944 7945 7946 7947 7948 7949 7950 7951 7952 7953 7954 7955 7956 7957 7958 7959 7960 7961 7962 7963 7964 7965 7966 7967 7968 7969 7970 7971 7972 7973 7974 7975 7976 7977 7978 7979 7980 7981 7982 7983 7984 7985 7986 7987 7988 7989 7990 7991 7992 7993 7994 7995 7996 7997 7998 7999 8000 8001 8002 8003 8004 8005 8006 8007 8008 8009 8010 8011 8012 8013 8014 8015 8016 8017 8018 8019 8020 8021 8022 8023 8024 8025 8026 8027 8028 8029 8030 8031 8032 8033 8034 8035 8036 8037 8038 8039 8040 8041 8042 8043 8044 8045 8046 8047 8048 8049 8050 8051 8052 8053 8054 8055 8056 8057 8058 8059 8060 8061 8062 8063 8064 8065 8066 8067 8068 8069 8070 8071 8072 8073 8074 8075 8076 8077 8078 8079 8080 8081 8082 8083 8084 8085 8086 8087 8088 8089 8090 8091 8092 8093 8094 8095 8096 8097 8098 8099 8100 8101 8102 8103 8104 8105 8106 8107 8108 8109 8110 8111 8112 8113 8114 8115 8116 8117 8118 8119 8120 8121 8122 8123 8124 8125 8126 8127 8128 8129 8130 8131 8132 8133 8134 8135 8136 8137 8138 8139 8140 8141 8142 8143 8144 8145 8146 8147 8148 8149 8150 8151 8152 8153 8154 8155 8156 8157 8158 8159 8160 8161 8162 8163 8164 8165 8166 8167 8168 8169 8170 8171 8172 8173 8174 8175 8176 8177 8178 8179 8180 8181 8182 8183 8184 8185 8186 8187 8188 8189 8190 8191 8192 8193 8194 8195 8196 8197 8198 8199 8200 8201 8202 8203 8204 8205 8206 8207 8208 8209 8210 8211 8212 8213 8214 8215 8216 8217 8218 8219 8220 8221 8222 8223 8224 8225 8226 8227 8228 8229 8230 8231 8232 8233 8234 8235 8236 8237 8238 8239 8240 8241 8242 8243 8244 8245 8246 8247 8248 8249 8250 8251 8252 8253 8254 8255 8256 8257 8258 8259 8260 8261 8262 8263 8264 8265 8266 8267 8268 8269 8270 8271 8272 8273 8274 8275 8276 8277 8278 8279 8280 8281 8282 8283 8284 8285 8286 8287 8288 8289 8290 8291 8292 8293 8294 8295 8296 8297 8298 8299 8300 8301 8302 8303 8304 8305 8306 8307 8308 8309 8310 8311 8312 8313 8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8327 8328 8329 8330 8331 8332 8333 8334 8335 8336 8337 8338 8339 8340 8341 8342 8343 8344 8345 8346 8347 8348 8349 8350 8351 8352 8353 8354 8355 8356 8357 8358 8359 8360 8361 8362 8363 8364 8365 8366 8367 8368 8369 8370 8371 8372 8373 8374 8375 8376 8377 8378 8379 8380 8381 8382 8383 8384 8385 8386 8387 8388 8389 8390 8391 8392 8393 8394 8395 8396 8397 8398 8399 8400 8401 8402 8403 8404 8405 8406 8407 8408 8409 8410 8411 8412 8413 8414 8415 8416 8417 8418 8419 8420 8421 8422 8423 8424 8425 8426 8427 8428 8429 8430 8431 8432 8433 8434 8435 8436 8437 8438 8439 8440 8441 8442 8443 8444 8445 8446 8447 8448 8449 8450 8451 8452 8453 8454 8455 8456 8457 8458 8459 8460 8461 8462 8463 8464 8465 8466 8467 8468 8469 8470 8471 8472 8473 8474 8475 8476 8477 8478 8479 8480 8481 8482 8483 8484 8485 8486 8487 8488 8489 8490 8491 8492 8493 8494 8495 8496 8497 8498 8499 8500 8501 8502 8503 8504 8505 8506 8507 8508 8509 8510 8511 8512 8513 8514 8515 8516 8517 8518 8519 8520 8521 8522 8523 8524 8525 8526 8527 8528 8529 8530 8531 8532 8533 8534 8535 8536 8537 8538 8539 8540 8541 8542 8543 8544 8545 8546 8547 8548 8549 8550 8551 8552 8553 8554 8555 8556 8557 8558 8559 8560 8561 8562 8563 8564 8565 8566 8567 8568 8569 8570 8571 8572 8573 8574 8575 8576 8577 8578 8579 8580 8581 8582 8583 8584 8585 8586 8587 8588 8589 8590 8591 8592 8593 8594 8595 8596 8597 8598 8599 8600 8601 8602 8603 8604 8605 8606 8607 8608 8609 8610 8611 8612 8613 8614 8615 8616 8617 8618 8619 8620 8621 8622 8623 8624 8625 8626 8627 8628 8629 8630 8631 8632 8633 8634 8635 8636 8637 8638 8639 8640 8641 8642 8643 8644 8645 8646 8647 8648 8649 8650 8651 8652 8653 8654 8655 8656 8657 8658 8659 8660 8661 8662 8663 8664 8665 8666 8667 8668 8669 8670 8671 8672 8673 8674 8675 8676 8677 8678 8679 8680 8681 8682 8683 8684 8685 8686 8687 8688 8689 8690 8691 8692 8693 8694 8695 8696 8697 8698 8699 8700 8701 8702 8703 8704 8705 8706 8707 8708 8709 8710 8711 8712 8713 8714 8715 8716 8717 8718 8719 8720 8721 8722 8723 8724 8725 8726 8727 8728 8729 8730 8731 8732 8733 8734 8735 8736 8737 8738 8739 8740 8741 8742 8743 8744 8745 8746 8747 8748 8749 8750 8751 8752 8753 8754 8755 8756 8757 8758 8759 8760 8761 8762 8763 8764 8765 8766 8767 8768 8769 8770 8771 8772 8773 8774 8775 8776 8777 8778 8779 8780 8781 8782 8783 8784 8785 8786 8787 8788 8789 8790 8791 8792 8793 8794 8795 8796 8797 8798 8799 8800 8801 8802 8803 8804 8805 8806 8807 8808 8809 8810 8811 8812 8813 8814 8815 8816 8817 8818 8819 8820 8821 8822 8823 8824 8825 8826 8827 8828 8829 8830 8831 8832 8833 8834 8835 8836 8837 8838 8839 8840 8841 8842 8843 8844 8845 8846 8847 8848 8849 8850 8851 8852 8853 8854 8855 8856 8857 8858 8859 8860 8861 8862 8863 8864 8865 8866 8867 8868 8869 8870 8871 8872 8873 8874 8875 8876 8877 8878 8879 8880 8881 8882 8883 8884 8885 8886 8887 8888 8889 8890 8891 8892 8893 8894 8895 8896 8897 8898 8899 8900 8901 8902 8903 8904 8905 8906 8907 8908 8909 8910 8911 8912 8913 8914 8915 8916 8917 8918 8919 8920 8921 8922 8923 8924 8925 8926 8927 8928 8929 8930 8931 8932 8933 8934 8935 8936 8937 8938 8939 8940 8941 8942 8943 8944 8945 8946 8947 8948 8949 8950 8951 8952 8953 8954 8955 8956 8957 8958 8959 8960 8961 8962 8963 8964 8965 8966 8967 8968 8969 8970 8971 8972 8973 8974 8975 8976 8977 8978 8979 8980 8981 8982 8983 8984 8985 8986 8987 8988 8989 8990 8991 8992 8993 8994 8995 8996 8997 8998 8999 9000 9001 9002 9003 9004 9005 9006 9007 9008 9009 9010 9011 9012 9013 9014 9015 9016 9017 9018 9019 9020 9021 9022 9023 9024 9025 9026 9027 9028 9029 9030 9031 9032 9033 9034 9035 9036 9037 9038 9039 9040 9041 9042 9043 9044 9045 9046 9047 9048 9049 9050 9051 9052 9053 9054 9055 9056 9057 9058 9059 9060 9061 9062 9063 9064 9065 9066 9067 9068 9069 9070 9071 9072 9073 9074 9075 9076 9077 9078 9079 9080 9081 9082 9083 9084 9085 9086 9087 9088 9089 9090 9091 9092 9093 9094 9095 9096 9097 9098 9099 9100 9101 9102 9103 9104 9105 9106 9107 9108 9109 9110 9111 9112 9113 9114 9115 9116 9117 9118 9119 9120 9121 9122 9123 9124 9125 9126 9127 9128 9129 9130 9131 9132 9133 9134 9135 9136 9137 9138 9139 9140 9141 9142 9143 9144 9145 9146 9147 9148 9149 9150 9151 9152 9153 9154 9155 9156 9157 9158 9159 9160 9161 9162 9163 9164 9165 9166 9167 9168 9169 9170 9171 9172 9173 9174 9175 9176 9177 9178 9179 9180 9181 9182 9183 9184 9185 9186 9187 9188 9189 9190 9191 9192 9193 9194 9195 9196 9197 9198 9199 9200 9201 9202 9203 9204 9205 9206 9207 9208 9209 9210 9211 9212 9213 9214 9215 9216 9217 9218 9219 9220 9221 9222 9223 9224 9225 9226 9227 9228 9229 9230 9231 9232 9233 9234 9235 9236 9237 9238 9239 9240 9241 9242 9243 9244 9245 9246 9247 9248 9249 9250 9251 9252 9253 9254 9255 9256 9257 9258 9259 9260 9261 9262 9263 9264 9265 9266 9267 9268 9269 9270 9271 9272 9273 9274 9275 9276 9277 9278 9279 9280 9281 9282 9283 9284 9285 9286 9287 9288 9289 9290 9291 9292 9293 9294 9295 9296 9297 9298 9299 9300 9301 9302 9303 9304 9305 9306 9307 9308 9309 9310 9311 9312 9313 9314 9315 9316 9317 9318 9319 9320 9321 9322 9323 9324 9325 9326 9327 9328 9329 9330 9331 9332 9333 9334 9335 9336 9337 9338 9339 9340 9341 9342 9343 9344 9345 9346 9347 9348 9349 9350 9351 9352 9353 9354 9355 9356 9357 9358 9359 9360 9361 9362 9363 9364 9365 9366 9367 9368 9369 9370 9371 9372 9373 9374 9375 9376 9377 9378 9379 9380 9381 9382 9383 9384 9385 9386 9387 9388 9389 9390 9391 9392 9393 9394 9395 9396 9397 9398 9399 9400 9401 9402 9403 9404 9405 9406 9407 9408 9409 9410 9411 9412 9413 9414 9415 9416 9417 9418 9419 9420 9421 9422 9423 9424 9425 9426 9427 9428 9429 9430 9431 9432 9433 9434 9435 9436 9437 9438 9439 9440 9441 9442 9443 9444 9445 9446 9447 9448 9449 9450 9451 9452 9453 9454 9455 9456 9457 9458 9459 9460 9461 9462 9463 9464 9465 9466 9467 9468 9469 9470 9471 9472 9473 9474 9475 9476 9477 9478 9479 9480 9481 9482 9483 9484 9485 9486 9487 9488 9489 9490 9491 9492 9493 9494 9495 9496 9497 9498 9499 9500 9501 9502 9503 9504 9505 9506 9507 9508 9509 9510 9511 9512 9513 9514 9515 9516 9517 9518 9519 9520 9521 9522 9523 9524 9525 9526 9527 9528 9529 9530 9531 9532 9533 9534 9535 9536 9537 9538 9539 9540 9541 9542 9543 9544 9545 9546 9547 9548 9549 9550 9551 9552 9553 9554 9555 9556 9557 9558 9559 9560 9561 9562 9563 9564 9565 9566 9567 9568 9569 9570 9571 9572 9573 9574 9575 9576 9577 9578 9579 9580 9581 9582 9583 9584 9585 9586 9587 9588 9589 9590 9591 9592 9593 9594 9595 9596 9597 9598 9599 9600 9601 9602 9603 9604 9605 9606 9607 9608 9609 9610 9611 9612 9613 9614 9615 9616 9617 9618 9619 9620 9621 9622 9623 9624 9625 9626 9627 9628 9629 9630 9631 9632 9633 9634 9635 9636 9637 9638 9639 9640 9641 9642 9643 9644 9645 9646 9647 9648 9649 9650 9651 9652 9653 9654 9655 9656 9657 9658 9659 9660 9661 9662 9663 9664 9665 9666 9667 9668 9669 9670 9671 9672 9673 9674 9675 9676 9677 9678 9679 9680 9681 9682 9683 9684 9685 9686 9687 9688 9689 9690 9691 9692 9693 9694 9695 9696 9697 9698 9699 9700 9701 9702 9703 9704 9705 9706 9707 9708 9709 9710 9711 9712 9713 9714 9715 9716 9717 9718 9719 9720 9721 9722 9723 9724 9725 9726 9727 9728 9729 9730 9731 9732 9733 9734 9735 9736 9737 9738 9739 9740 9741 9742 9743 9744 9745 9746 9747 9748 9749 9750 9751 9752 9753 9754 9755 9756 9757 9758 9759 9760 9761 9762 9763 9764 9765 9766 9767 9768 9769 9770 9771 9772 9773 9774 9775 9776 9777 9778 9779 9780 9781 9782 9783 9784 9785 9786 9787 9788 9789 9790 9791 9792 9793 9794 9795 9796 9797 9798 9799 9800 9801 9802 9803 9804 9805 9806 9807 9808 9809 9810 9811 9812 9813 9814 9815 9816 9817 9818 9819 9820 9821 9822 9823 9824 9825 9826 9827 9828 9829 9830 9831 9832 9833 9834 9835 9836 9837 9838 9839 9840 9841 9842 9843 9844 9845 9846 9847 9848 9849 9850 9851 9852 9853 9854 9855 9856 9857 9858 9859 9860 9861 9862 9863 9864 9865 9866 9867 9868 9869 9870 9871 9872 9873 9874 9875 9876 9877 9878 9879 9880 9881 9882 9883 9884 9885 9886 9887 9888 9889 9890 9891 9892 9893 9894 9895 9896 9897 9898 9899 9900 9901 9902 9903 9904 9905 9906 9907 9908 9909 9910 9911 9912 9913 9914 9915 9916 9917 9918 9919 9920 9921 9922 9923 9924 9925 9926 9927 9928 9929 9930 9931 9932 9933 9934 9935 9936 9937 9938 9939 9940 9941 9942 9943 9944 9945 9946 9947 9948 9949 9950 9951 9952 9953 9954 9955 9956 9957 9958 9959 9960 9961 9962 9963 9964 9965 9966 9967 9968 9969 9970 9971 9972 9973 9974 9975 9976 9977 9978 9979 9980 9981 9982 9983 9984 9985 9986 9987 9988 9989 9990 9991 9992 9993 9994 9995 9996 9997 9998 9999 10000 10001 10002 10003 10004 10005 10006 10007 10008 10009 10010 10011 10012 10013 10014 10015 10016 10017 10018 10019 10020 10021 10022 10023 10024 10025 10026 10027 10028 10029 10030 10031 10032 10033 10034 10035 10036 10037 10038 10039 10040 10041 10042 10043 10044 10045 10046 10047 10048 10049 10050 10051 10052 10053 10054 10055 10056 10057 10058 10059 10060 10061 10062 10063 10064 10065 10066 10067 10068 10069 10070 10071 10072 10073 10074 10075 10076 10077 10078 10079 10080 10081 10082 10083 10084 10085 10086 10087 10088 10089 10090 10091 10092 10093 10094 10095 10096 10097 10098 10099 10100 10101 10102 10103 10104 10105 10106 10107 10108 10109 10110 10111 10112 10113 10114 10115 10116 10117 10118 10119 10120 10121 10122 10123 10124 10125 10126 10127 10128 10129 10130 10131 10132 10133 10134 10135 10136 10137 10138 10139 10140 10141 10142 10143 10144 10145 10146 10147 10148 10149 10150 10151 10152 10153 10154 10155 10156 10157 10158 10159 10160 10161 10162 10163 10164 10165 10166 10167 10168 10169 10170 10171 10172 10173 10174 10175 10176 10177 10178 10179 10180 10181 10182 10183 10184 10185 10186 10187 10188 10189 10190 10191 10192 10193 10194 10195 10196 10197 10198 10199 10200 10201 10202 10203 10204 10205 10206 10207 10208 10209 10210 10211 10212 10213 10214 10215 10216 10217 10218 10219 10220 10221 10222 10223 10224 10225 10226 10227 10228 10229 10230 10231 10232 10233 10234 10235 10236 10237 10238 10239 10240 10241 10242 10243 10244 10245 10246 10247 10248 10249 10250 10251 10252 10253 10254 10255 10256 10257 10258 10259 10260 10261 10262 10263 10264 10265 10266 10267 10268 10269 10270 10271 10272 10273 10274 10275 10276 10277 10278 10279 10280 10281 10282 10283 10284 10285 10286 10287 10288 10289 10290 10291 10292 10293 10294 10295 10296 10297 10298 10299 10300 10301 10302 10303 10304 10305 10306 10307 10308 10309 10310 10311 10312 10313 10314 10315 10316 10317 10318 10319 10320 10321 10322 10323 10324 10325 10326 10327 10328 10329 10330 10331 10332 10333 10334 10335 10336 10337 10338 10339 10340 10341 10342 10343 10344 10345 10346 10347 10348 10349 10350 10351 10352 10353 10354 10355 10356 10357 10358 10359 10360 10361 10362 10363 10364 10365 10366 10367 10368 10369 10370 10371 10372 10373 10374 10375 10376 10377 10378 10379 10380 10381 10382 10383 10384 10385 10386 10387 10388 10389 10390 10391 10392 10393 10394 10395 10396 10397 10398 10399 10400 10401 10402 10403 10404 10405 10406 10407 10408 10409 10410 10411 10412 10413 10414 10415 10416 10417 10418 10419 10420 10421 10422 10423 10424 10425 10426 10427 10428 10429 10430 10431 10432 10433 10434 10435 10436 10437 10438 10439 10440 10441 10442 10443 10444 10445 10446 10447 10448 10449 10450 10451 10452 10453 10454 10455 10456 10457 10458 10459 10460 10461 10462 10463 10464 10465 10466 10467 10468 10469 10470 10471 10472 10473 10474 10475 10476 10477 10478 10479 10480 10481 10482 10483 10484 10485 10486 10487 10488 10489 10490 10491 10492 10493 10494 10495 10496 10497 10498 10499 10500 10501 10502 10503 10504 10505 10506 10507 10508 10509 10510 10511 10512 10513 10514 10515 10516 10517 10518 10519 10520 10521 10522 10523 10524 10525 10526 10527 10528 10529 10530 10531 10532 10533 10534 10535 10536 10537 10538 10539 10540 10541 10542 10543 10544 10545 10546 10547 10548 10549 10550 10551 10552 10553 10554 10555 10556 10557 10558 10559 10560 10561 10562 10563 10564 10565 10566 10567 10568 10569 10570 10571 10572 10573 10574 10575 10576 10577 10578 10579 10580 10581 10582 10583 10584 10585 10586 10587 10588 10589 10590 10591 10592 10593 10594 10595 10596 10597 10598 10599 10600 10601 10602 10603 10604 10605 10606 10607 10608 10609 10610 10611 10612 10613 10614 10615 10616 10617 10618 10619 10620 10621 10622 10623 10624 10625 10626 10627 10628 10629 10630 10631 10632 10633 10634 10635 10636 10637 10638 10639 10640 10641 10642 10643 10644 10645 10646 10647 10648 10649 10650 10651 10652 10653 10654 10655 10656 10657 10658 10659 10660 10661 10662 10663 10664 10665 10666 10667 10668 10669 10670 10671 10672 10673 10674 10675 10676 10677 10678 10679 10680 10681 10682 10683 10684 10685 10686 10687 10688 10689 10690 10691 10692 10693 10694 10695 10696 10697 10698 10699 10700 10701 10702 10703 10704 10705 10706 10707 10708 10709 10710 10711 10712 10713 10714 10715 10716 10717 10718 10719 10720 10721 10722 10723 10724 10725 10726 10727 10728 10729 10730 10731 10732 10733 10734 10735 10736 10737 10738 10739 10740 10741 10742 10743 10744 10745 10746 10747 10748 10749 10750 10751 10752 10753 10754 10755 10756 10757 10758 10759 10760 10761 10762 10763 10764 10765 10766 10767 10768 10769 10770 10771 10772 10773 10774 10775 10776 10777 10778 10779 10780 10781 10782 10783 10784 10785 10786 10787 10788 10789 10790 10791 10792 10793 10794 10795 10796 10797 10798 10799 10800 10801 10802 10803 10804 10805 10806 10807 10808 10809 10810 10811 10812 10813 10814 10815 10816 10817 10818 10819 10820 10821 10822 10823 10824 10825 10826 10827 10828 10829 10830 10831 10832 10833 10834 10835 10836 10837 10838 10839 10840 10841 10842 10843 10844 10845 10846 10847 10848 10849 10850 10851 10852 10853 10854 10855 10856 10857 10858 10859 10860 10861 10862 10863 10864 10865 10866 10867 10868 10869 10870 10871 10872 10873 10874 10875 10876 10877 10878 10879 10880 10881 10882 10883 10884 10885 10886 10887 10888 10889 10890 10891 10892 10893 10894 10895 10896 10897 10898 10899 10900 10901 10902 10903 10904 10905 10906 10907 10908 10909 10910 10911 10912 10913 10914 10915 10916 10917 10918 10919 10920 10921 10922 10923 10924 10925 10926 10927 10928 10929 10930 10931 10932 10933 10934 10935 10936 10937 10938 10939 10940 10941 10942 10943 10944 10945 10946 10947 10948 10949 10950 10951 10952 10953 10954 10955 10956 10957 10958 10959 10960 10961 10962 10963 10964 10965 10966 10967 10968 10969 10970 10971 10972 10973 10974 10975 10976 10977 10978 10979 10980 10981 10982 10983 10984 10985 10986 10987 10988 10989 10990 10991 10992 10993 10994 10995 10996 10997 10998 10999 11000 11001 11002 11003 11004 11005 11006 11007 11008 11009 11010 11011 11012 11013 11014 11015 11016 11017 11018 11019 11020 11021 11022 11023 11024 11025 11026 11027 11028 11029 11030 11031 11032 11033 11034 11035 11036 11037 11038 11039 11040 11041 11042 11043 11044 11045 11046 11047 11048 11049 11050 11051 11052 11053 11054 11055 11056 11057 11058 11059 11060 11061 11062 11063 11064 11065 11066 11067 11068 11069 11070 11071 11072 11073 11074 11075 11076 11077 11078 11079 11080 11081 11082 11083 11084 11085 11086 11087 11088 11089 11090 11091 11092 11093 11094 11095 11096 11097 11098 11099 11100 11101 11102 11103 11104 11105 11106 11107 11108 11109 11110 11111 11112 11113 11114 11115 11116 11117 11118 11119 11120 11121 11122 11123 11124 11125 11126 11127 11128 11129 11130 11131 11132 11133 11134 11135 11136 11137 11138 11139 11140 11141 11142 11143 11144 11145 11146 11147 11148 11149 11150 11151 11152 11153 11154 11155 11156 11157 11158 11159 11160 11161 11162 11163 11164 11165 11166 11167 11168 11169 11170 11171 11172 11173 11174 11175 11176 11177 11178 11179 11180 11181 11182 11183 11184 11185 11186 11187 11188 11189 11190 11191 11192 11193 11194 11195 11196 11197 11198 11199 11200 11201 11202 11203 11204 11205 11206 11207 11208 11209 11210 11211 11212 11213 11214 11215 11216 11217 11218 11219 11220 11221 11222 11223 11224 11225 11226 11227 11228 11229 11230 11231 11232 11233 11234 11235 11236 11237 11238 11239 11240 11241 11242 11243 11244 11245 11246 11247 11248 11249 11250 11251 11252 11253 11254 11255 11256 11257 11258 11259 11260 11261 11262 11263 11264 11265 11266 11267 11268 11269 11270 11271 11272 11273 11274 11275 11276 11277 11278 11279 11280 11281 11282 11283 11284 11285 11286 11287 11288 11289 11290 11291 11292 11293 11294 11295 11296 11297 11298 11299 11300 11301 11302 11303 11304 11305 11306 11307 11308 11309 11310 11311 11312 11313 11314 11315 11316 11317 11318 11319 11320 11321 11322 11323 11324 11325 11326 11327 11328 11329 11330 11331 11332 11333 11334 11335 11336 11337 11338 11339 11340 11341 11342 11343 11344 11345 11346 11347 11348 11349 11350 11351 11352 11353 11354 11355 11356 11357 11358 11359 11360 11361 11362 11363 11364 11365 11366 11367 11368 11369 11370 11371 11372 11373 11374 11375 11376 11377 11378 11379 11380 11381 11382 11383 11384 11385 11386 11387 11388 11389 11390 11391 11392 11393 11394 11395 11396 11397 11398 11399 11400 11401 11402 11403 11404 11405 11406 11407 11408 11409 11410 11411 11412 11413 11414 11415 11416 11417 11418 11419 11420 11421 11422 11423 11424 11425 11426 11427 11428 11429 11430 11431 11432 11433 11434 11435 11436 11437 11438 11439 11440 11441 11442 11443 11444 11445 11446 11447 11448 11449 11450 11451 11452 11453 11454 11455 11456 11457 11458 11459 11460 11461 11462 11463 11464 11465 11466 11467 11468 11469 11470 11471 11472 11473 11474 11475 11476 11477 11478 11479 11480 11481 11482 11483 11484 11485 11486 11487 11488 11489 11490 11491 11492 11493 11494 11495 11496 11497 11498 11499 11500 11501 11502 11503 11504 11505 11506 11507 11508 11509 11510 11511 11512 11513 11514 11515 11516 11517 11518 11519 11520 11521 11522 11523 11524 11525 11526 11527 11528 11529 11530 11531 11532 11533 11534 11535 11536 11537 11538 11539 11540 11541 11542 11543 11544 11545 11546 11547 11548 11549 11550 11551 11552 11553 11554 11555 11556 11557 11558 11559 11560 11561 11562 11563 11564 11565 11566 11567 11568 11569 11570 11571 11572 11573 11574 11575 11576 11577 11578 11579 11580 11581 11582 11583 11584 11585 11586 11587 11588 11589 11590 11591 11592 11593 11594 11595 11596 11597 11598 11599 11600 11601 11602 11603 11604 11605 11606 11607 11608 11609 11610 11611 11612 11613 11614 11615 11616 11617 11618 11619 11620 11621 11622 11623 11624 11625 11626 11627 11628 11629 11630 11631 11632 11633 11634 11635 11636 11637 11638 11639 11640 11641 11642 11643 11644 11645 11646 11647 11648 11649 11650 11651 11652 11653 11654 11655 11656 11657 11658 11659 11660 11661 11662 11663 11664 11665 11666 11667 11668 11669 11670 11671 11672 11673 11674 11675 11676 11677 11678 11679 11680 11681 11682 11683 11684 11685 11686 11687 11688 11689 11690 11691 11692 11693 11694 11695 11696 11697 11698 11699 11700 11701 11702 11703 11704 11705 11706 11707 11708 11709 11710 11711 11712 11713 11714 11715 11716 11717 11718 11719 11720 11721 11722 11723 11724 11725 11726 11727 11728 11729 11730 11731 11732 11733 11734 11735 11736 11737 11738 11739 11740 11741 11742 11743 11744 11745 11746 11747 11748 11749 11750 11751 11752 11753 11754 11755 11756 11757 11758 11759 11760 11761 11762 11763 11764 11765 11766 11767 11768 11769 11770 11771 11772 11773 11774 11775 11776 11777 11778 11779 11780 11781 11782 11783 11784 11785 11786 11787 11788 11789 11790 11791 11792 11793 11794 11795 11796 11797 11798 11799 11800 11801 11802 11803 11804 11805 11806 11807 11808 11809 11810 11811 11812 11813 11814 11815 11816 11817 11818 11819 11820 11821 11822 11823 11824 11825 11826 11827 11828 11829 11830 11831 11832 11833 11834 11835 11836 11837 11838 11839 11840 11841 11842 11843 11844 11845 11846 11847 11848 11849 11850 11851 11852 11853 11854 11855 11856 11857 11858 11859 11860 11861 11862 11863 11864 11865 11866 11867 11868 11869 11870 11871 11872 11873 11874 11875 11876 11877 11878 11879 11880 11881 11882 11883 11884 11885 11886 11887 11888 11889 11890 11891 11892 11893 11894 11895 11896 11897 11898 11899 11900 11901 11902 11903 11904 11905 11906 11907 11908 11909 11910 11911 11912 11913 11914 11915 11916 11917 11918 11919 11920 11921 11922 11923 11924 11925 11926 11927 11928 11929 11930 11931 11932 11933 11934 11935 11936 11937 11938 11939 11940 11941 11942 11943 11944 11945 11946 11947 11948 11949 11950 11951 11952 11953 11954 11955 11956 11957 11958 11959 11960 11961 11962 11963 11964 11965 11966 11967 11968 11969 11970 11971 11972 11973 11974 11975 11976 11977 11978 11979 11980 11981 11982 11983 11984 11985 11986 11987 11988 11989 11990 11991 11992 11993 11994 11995 11996 11997 11998 11999 12000 12001 12002 12003 12004 12005 12006 12007 12008 12009 12010 12011 12012 12013 12014 12015 12016 12017 12018 12019 12020 12021 12022 12023 12024 12025 12026 12027 12028 12029 12030 12031 12032 12033 12034 12035 12036 12037 12038 12039 12040 12041 12042 12043 12044 12045 12046 12047 12048 12049 12050 12051 12052 12053 12054 12055 12056 12057 12058 12059 12060 12061 12062 12063 12064 12065 12066 12067 12068 12069 12070 12071 12072 12073 12074 12075 12076 12077 12078 12079 12080 12081 12082 12083 12084 12085 12086 12087 12088 12089 12090 12091 12092 12093 12094 12095 12096 12097 12098 12099 12100 12101 12102 12103 12104 12105 12106 12107 12108 12109 12110 12111 12112 12113 12114 12115 12116 12117 12118 12119 12120 12121 12122 12123 12124 12125 12126 12127 12128 12129 12130 12131 12132 12133 12134 12135 12136 12137 12138 12139 12140 12141 12142 12143 12144 12145 12146 12147 12148 12149 12150 12151 12152 12153 12154 12155 12156 12157 12158 12159 12160 12161 12162 12163 12164 12165 12166 12167 12168 12169 12170 12171 12172 12173 12174 12175 12176 12177 12178 12179 12180 12181 12182 12183 12184 12185 12186 12187 12188 12189 12190 12191 12192 12193 12194 12195 12196 12197 12198 12199 12200 12201 12202 12203 12204 12205 12206 12207 12208 12209 12210 12211 12212 12213 12214 12215 12216 12217 12218 12219 12220 12221 12222 12223 12224 12225 12226 12227 12228 12229 12230 12231 12232 12233 12234 12235 12236 12237 12238 12239 12240 12241 12242 12243 12244 12245 12246 12247 12248 12249 12250 12251 12252 12253 12254 12255 12256 12257 12258 12259 12260 12261 12262 12263 12264 12265 12266 12267 12268 12269 12270 12271 12272 12273 12274 12275 12276 12277 12278 12279 12280 12281 12282 12283 12284 12285 12286 12287 12288 12289 12290 12291 12292 12293 12294 12295 12296 12297 12298 12299 12300 12301 12302 12303 12304 12305 12306 12307 12308 12309 12310 12311 12312 12313 12314 12315 12316 12317 12318 12319 12320 12321 12322 12323 12324 12325 12326 12327 12328 12329 12330 12331 12332 12333 12334 12335 12336 12337 12338 12339 12340 12341 12342 12343 12344 12345 12346 12347 12348 12349 12350 12351 12352 12353 12354 12355 12356 12357 12358 12359 12360 12361 12362 12363 12364 12365 12366 12367 12368 12369 12370 12371 12372 12373 12374 12375 12376 12377 12378 12379 12380 12381 12382 12383 12384 12385 12386 12387 12388 12389 12390 12391 12392 12393 12394 12395 12396 12397 12398 12399 12400 12401 12402 12403 12404 12405 12406 12407 12408 12409 12410 12411 12412 12413 12414 12415 12416 12417 12418 12419 12420 12421 12422 12423 12424 12425 12426 12427 12428 12429 12430 12431 12432 12433 12434 12435 12436 12437 12438 12439 12440 12441 12442 12443 12444 12445 12446 12447 12448 12449 12450 12451 12452 12453 12454 12455 12456 12457 12458 12459 12460 12461 12462 12463 12464 12465 12466 12467 12468 12469 12470 12471 12472 12473 12474 12475 12476 12477 12478 12479 12480 12481 12482 12483 12484 12485 12486 12487 12488 12489 12490 12491 12492 12493 12494 12495 12496 12497 12498 12499 12500 12501 12502 12503 12504 12505 12506 12507 12508 12509 12510 12511 12512 12513 12514 12515 12516 12517 12518 12519 12520 12521 12522 12523 12524 12525 12526 12527 12528 12529 12530 12531 12532 12533 12534 12535 12536 12537 12538 12539 12540 12541 12542 12543 12544 12545 12546 12547 12548 12549 12550 12551 12552 12553 12554 12555 12556 12557 12558 12559 12560 12561 12562 12563 12564 12565 12566 12567 12568 12569 12570 12571 12572 12573 12574 12575 12576 12577 12578 12579 12580 12581 12582 12583 12584 12585 12586 12587 12588 12589 12590 12591 12592 12593 12594 12595 12596 12597 12598 12599 12600 12601 12602 12603 12604 12605 12606 12607 12608 12609 12610 12611 12612 12613 12614 12615 12616 12617 12618 12619 12620 12621 12622 12623 12624 12625 12626 12627 12628 12629 12630 12631 12632 12633 12634 12635 12636 12637 12638 12639 12640 12641 12642 12643 12644 12645 12646 12647 12648 12649 12650 12651 12652 12653 12654 12655 12656 12657 12658 12659 12660 12661 12662 12663 12664 12665 12666 12667 12668 12669 12670 12671 12672 12673 12674 12675 12676 12677 12678 12679 12680 12681 12682 12683 12684 12685 12686 12687 12688 12689 12690 12691 12692 12693 12694 12695 12696 12697 12698 12699 12700 12701 12702 12703 12704 12705 12706 12707 12708 12709 12710 12711 12712 12713 12714 12715 12716 12717 12718 12719 12720 12721 12722 12723 12724 12725 12726 12727 12728 12729 12730 12731 12732 12733 12734 12735 12736 12737 12738 12739 12740 12741 12742 12743 12744 12745 12746 12747 12748 12749 12750 12751 12752 12753 12754 12755 12756 12757 12758 12759 12760 12761 12762 12763 12764 12765 12766 12767 12768 12769 12770 12771 12772 12773 12774 12775 12776 12777 12778 12779 12780 12781 12782 12783 12784 12785 12786 12787 12788 12789 12790 12791 12792 12793 12794 12795 12796 12797 12798 12799 12800 12801 12802 12803 12804 12805 12806 12807 12808 12809 12810 12811 12812 12813 12814 12815 12816 12817 12818 12819 12820 12821 12822 12823 12824 12825 12826 12827 12828 12829 12830 12831 12832 12833 12834 12835 12836 12837 12838 12839 12840 12841 12842 12843 12844 12845 12846 12847 12848 12849 12850 12851 12852 12853 12854 12855 12856 12857 12858 12859 12860 12861 12862 12863 12864 12865 12866 12867 12868 12869 12870 12871 12872 12873 12874 12875 12876 12877 12878 12879 12880 12881 12882 12883 12884 12885 12886 12887 12888 12889 12890 12891 12892 12893 12894 12895 12896 12897 12898 12899 12900 12901 12902 12903 12904 12905 12906 12907 12908 12909 12910 12911 12912 12913 12914 12915 12916 12917 12918 12919 12920 12921 12922 12923 12924 12925 12926 12927 12928 12929 12930 12931 12932 12933 12934 12935 12936 12937 12938 12939 12940 12941 12942 12943 12944 12945 12946 12947 12948 12949 12950 12951 12952 12953 12954 12955 12956 12957 12958 12959 12960 12961 12962 12963 12964 12965 12966 12967 12968 12969 12970 12971 12972 12973 12974 12975 12976 12977 12978 12979 12980 12981 12982 12983 12984 12985 12986 12987 12988 12989 12990 12991 12992 12993 12994 12995 12996 12997 12998 12999 13000 13001 13002 13003 13004 13005 13006 13007 13008 13009 13010 13011 13012 13013 13014 13015 13016 13017 13018 13019 13020 13021 13022 13023 13024 13025 13026 13027 13028 13029 13030 13031 13032 13033 13034 13035 13036 13037 13038 13039 13040 13041 13042 13043 13044 13045 13046 13047 13048 13049 13050 13051 13052 13053 13054 13055 13056 13057 13058 13059 13060 13061 13062 13063 13064 13065 13066 13067 13068 13069 13070 13071 13072 13073 13074 13075 13076 13077 13078 13079 13080 13081 13082 13083 13084 13085 13086 13087 13088 13089 13090 13091 13092 13093 13094 13095 13096 13097 13098 13099 13100 13101 13102 13103 13104 13105 13106 13107 13108 13109 13110 13111 13112 13113 13114 13115 13116 13117 13118 13119 13120 13121 13122 13123 13124 13125 13126 13127 13128 13129 13130 13131 13132 13133 13134 13135 13136 13137 13138 13139 13140 13141 13142 13143 13144 13145 13146 13147 13148 13149 13150 13151 13152 13153 13154 13155 13156 13157 13158 13159 13160 13161 13162 13163 13164 13165 13166 13167 13168 13169 13170 13171 13172 13173 13174 13175 13176 13177 13178 13179 13180 13181 13182 13183 13184 13185 13186 13187 13188 13189 13190 13191 13192 13193 13194 13195 13196 13197 13198 13199 13200 13201 13202 13203 13204 13205 13206 13207 13208 13209 13210 13211 13212 13213 13214 13215 13216 13217 13218 13219 13220 13221 13222 13223 13224 13225 13226 13227 13228 13229 13230 13231 13232 13233 13234 13235 13236 13237 13238 13239 13240 13241 13242 13243 13244 13245 13246 13247 13248 13249 13250 13251 13252 13253 13254 13255 13256 13257 13258 13259 13260 13261 13262 13263 13264 13265 13266 13267 13268 13269 13270 13271 13272 13273 13274 13275 13276 13277 13278 13279 13280 13281 13282 13283 13284 13285 13286 13287 13288 13289 13290 13291 13292 13293 13294 13295 13296 13297 13298 13299 13300 13301 13302 13303 13304 13305 13306 13307 13308 13309 13310 13311 13312 13313 13314 13315 13316 13317 13318 13319 13320 13321 13322 13323 13324 13325 13326 13327 13328 13329 13330 13331 13332 13333 13334 13335 13336 13337 13338 13339 13340 13341 13342 13343 13344 13345 13346 13347 13348 13349 13350 13351 13352 13353 13354 13355 13356 13357 13358 13359 13360 13361 13362 13363 13364 13365 13366 13367 13368 13369 13370 13371 13372 13373 13374 13375 13376 13377 13378 13379 13380 13381 13382 13383 13384 13385 13386 13387 13388 13389 13390 13391 13392 13393 13394 13395 13396 13397 13398 13399 13400 13401 13402 13403 13404 13405 13406 13407 13408 13409 13410 13411 13412 13413 13414 13415 13416 13417 13418 13419 13420 13421 13422 13423 13424 13425 13426 13427 13428 13429 13430 13431 13432 13433 13434 13435 13436 13437 13438 13439 13440 13441 13442 13443 13444 13445 13446 13447 13448 13449 13450 13451 13452 13453 13454 13455 13456 13457 13458 13459 13460 13461 13462 13463 13464 13465 13466 13467 13468 13469 13470 13471 13472 13473 13474 13475 13476 13477 13478 13479 13480 13481 13482 13483 13484 13485 13486 13487 13488 13489 13490 13491 13492 13493 13494 13495 13496 13497 13498 13499 13500 13501 13502 13503 13504 13505 13506 13507 13508 13509 13510 13511 13512 13513 13514 13515 13516 13517 13518 13519 13520 13521 13522 13523 13524 13525 13526 13527 13528 13529 13530 13531 13532 13533 13534 13535 13536 13537 13538 13539 13540 13541 13542 13543 13544 13545 13546 13547 13548 13549 13550 13551 13552 13553 13554 13555 13556 13557 13558 13559 13560 13561 13562 13563 13564 13565 13566 13567 13568 13569 13570 13571 13572 13573 13574 13575 13576 13577 13578 13579 13580 13581 13582 13583 13584 13585 13586 13587 13588 13589 13590 13591 13592 13593 13594 13595 13596 13597 13598 13599 13600 13601 13602 13603 13604 13605 13606 13607 13608 13609 13610 13611 13612 13613 13614 13615 13616 13617 13618 13619 13620 13621 13622 13623 13624 13625 13626 13627 13628 13629 13630 13631 13632 13633 13634 13635 13636 13637 13638 13639 13640 13641 13642 13643 13644 13645 13646 13647 13648 13649 13650 13651 13652 13653 13654 13655 13656 13657 13658 13659 13660 13661 13662 13663 13664 13665 13666 13667 13668 13669 13670 13671 13672 13673 13674 13675 13676 13677 13678 13679 13680 13681 13682 13683 13684 13685 13686 13687 13688 13689 13690 13691 13692 13693 13694 13695 13696 13697 13698 13699 13700 13701 13702 13703 13704 13705 13706 13707 13708 13709 13710 13711 13712 13713 13714 13715 13716 13717 13718 13719 13720 13721 13722 13723 13724 13725 13726 13727 13728 13729 13730 13731 13732 13733 13734 13735 13736 13737 13738 13739 13740 13741 13742 13743 13744 13745 13746 13747 13748 13749 13750 13751 13752 13753 13754 13755 13756 13757 13758 13759 13760 13761 13762 13763 13764 13765 13766 13767 13768 13769 13770 13771 13772 13773 13774 13775 13776 13777 13778 13779 13780 13781 13782 13783 13784 13785 13786 13787 13788 13789 13790 13791 13792 13793 13794 13795 13796 13797 13798 13799 13800 13801 13802 13803 13804 13805 13806 13807 13808 13809 13810 13811 13812 13813 13814 13815 13816 13817 13818 13819 13820 13821 13822 13823 13824 13825 13826 13827 13828 13829 13830 13831 13832 13833 13834 13835 13836 13837 13838 13839 13840 13841 13842 13843 13844 13845 13846 13847 13848 13849 13850 13851 13852 13853 13854 13855 13856 13857 13858 13859 13860 13861 13862 13863 13864 13865 13866 13867 13868 13869 13870 13871 13872 13873 13874 13875 13876 13877 13878 13879 13880 13881 13882 13883 13884 13885 13886 13887 13888 13889 13890 13891 13892 13893 13894 13895 13896 13897 13898 13899 13900 13901 13902 13903 13904 13905 13906 13907 13908 13909 13910 13911 13912 13913 13914 13915 13916 13917 13918 13919 13920 13921 13922 13923 13924 13925 13926 13927 13928 13929 13930 13931 13932 13933 13934 13935 13936 13937 13938 13939 13940 13941 13942 13943 13944 13945 13946 13947 13948 13949 13950 13951 13952 13953 13954 13955 13956 13957 13958 13959 13960 13961 13962 13963 13964 13965 13966 13967 13968 13969 13970 13971 13972 13973 13974 13975 13976 13977 13978 13979 13980 13981 13982 13983 13984 13985 13986 13987 13988 13989 13990 13991 13992 13993 13994 13995 13996 13997 13998 13999 14000 14001 14002 14003 14004 14005 14006 14007 14008 14009 14010 14011 14012 14013 14014 14015 14016 14017 14018 14019 14020 14021 14022 14023 14024 14025 14026 14027 14028 14029 14030 14031 14032 14033 14034 14035 14036 14037 14038 14039 14040 14041 14042 14043 14044 14045 14046 14047 14048 14049 14050 14051 14052 14053 14054 14055 14056 14057 14058 14059 14060 14061 14062 14063 14064 14065 14066 14067 14068 14069 14070 14071 14072 14073 14074 14075 14076 14077 14078 14079 14080 14081 14082 14083 14084 14085 14086 14087 14088 14089 14090 14091 14092 14093 14094 14095 14096 14097 14098 14099 14100 14101 14102 14103 14104 14105 14106 14107 14108 14109 14110 14111 14112 14113 14114 14115 14116 14117 14118 14119 14120 14121 14122 14123 14124 14125 14126 14127 14128 14129 14130 14131 14132 14133 14134 14135 14136 14137 14138 14139 14140 14141 14142 14143 14144 14145 14146 14147 14148 14149 14150 14151 14152 14153 14154 14155 14156 14157 14158 14159 14160 14161 14162 14163 14164 14165 14166 14167 14168 14169 14170 14171 14172 14173 14174 14175 14176 14177 14178 14179 14180 14181 14182 14183 14184 14185 14186 14187 14188 14189 14190 14191 14192 14193 14194 14195 14196 14197 14198 14199 14200 14201 14202 14203 14204 14205 14206 14207 14208 14209 14210 14211 14212 14213 14214 14215 14216 14217 14218 14219 14220 14221 14222 14223 14224 14225 14226 14227 14228 14229 14230 14231 14232 14233 14234 14235 14236 14237 14238 14239 14240 14241 14242 14243 14244 14245 14246 14247 14248 14249 14250 14251 14252 14253 14254 14255 14256 14257 14258 14259 14260 14261 14262 14263 14264 14265 14266 14267 14268 14269 14270 14271 14272 14273 14274 14275 14276 14277 14278 14279 14280 14281 14282 14283 14284 14285 14286 14287 14288 14289 14290 14291 14292 14293 14294 14295 14296 14297 14298 14299 14300 14301 14302 14303 14304 14305 14306 14307 14308 14309 14310 14311 14312 14313 14314 14315 14316 14317 14318 14319 14320 14321 14322 14323 14324 14325 14326 14327 14328 14329 14330 14331 14332 14333 14334 14335 14336 14337 14338 14339 14340 14341 14342 14343 14344 14345 14346 14347 14348 14349 14350 14351 14352 14353 14354 14355 14356 14357 14358 14359 14360 14361 14362 14363 14364 14365 14366 14367 14368 14369 14370 14371 14372 14373 14374 14375 14376 14377 14378 14379 14380 14381 14382 14383 14384 14385 14386 14387 14388 14389 14390 14391 14392 14393 14394 14395 14396 14397 14398 14399 14400 14401 14402 14403 14404 14405 14406 14407 14408 14409 14410 14411 14412 14413 14414 14415 14416 14417 14418 14419 14420 14421 14422 14423 14424 14425 14426 14427 14428 14429 14430 14431 14432 14433 14434 14435 14436 14437 14438 14439 14440 14441 14442 14443 14444 14445 14446 14447 14448 14449 14450 14451 14452 14453 14454 14455 14456 14457 14458 14459 14460 14461 14462 14463 14464 14465 14466 14467 14468 14469 14470 14471 14472 14473 14474 14475 14476 14477 14478 14479 14480 14481 14482 14483 14484 14485 14486 14487 14488 14489 14490 14491 14492 14493 14494 14495 14496 14497 14498 14499 14500 14501 14502 14503 14504 14505 14506 14507 14508 14509 14510 14511 14512 14513 14514 14515 14516 14517 14518 14519 14520 14521 14522 14523 14524 14525 14526 14527 14528 14529 14530 14531 14532 14533 14534 14535 14536 14537 14538 14539 14540 14541 14542 14543 14544 14545 14546 14547 14548 14549 14550 14551 14552 14553 14554 14555 14556 14557 14558 14559 14560 14561 14562 14563 14564 14565 14566 14567 14568 14569 14570 14571 14572 14573 14574 14575 14576 14577 14578 14579 14580 14581 14582 14583 14584 14585 14586 14587 14588 14589 14590 14591 14592 14593 14594 14595 14596 14597 14598 14599 14600 14601 14602 14603 14604 14605 14606 14607 14608 14609 14610 14611 14612 14613 14614 14615 14616 14617 14618 14619 14620 14621 14622 14623 14624 14625 14626 14627 14628 14629 14630 14631 14632 14633 14634 14635 14636 14637 14638 14639 14640 14641 14642 14643 14644 14645 14646 14647 14648 14649 14650 14651 14652 14653 14654 14655 14656 14657 14658 14659 14660 14661 14662 14663 14664 14665 14666 14667 14668 14669 14670 14671 14672 14673 14674 14675 14676 14677 14678 14679 14680 14681 14682 14683 14684 14685 14686 14687 14688 14689 14690 14691 14692 14693 14694 14695 14696 14697 14698 14699 14700 14701 14702 14703 14704 14705 14706 14707 14708 14709 14710 14711 14712 14713 14714 14715 14716 14717 14718 14719 14720 14721 14722 14723 14724 14725 14726 14727 14728 14729 14730 14731 14732 14733 14734 14735 14736 14737 14738 14739 14740 14741 14742 14743 14744 14745 14746 14747 14748 14749 14750 14751 14752 14753 14754 14755 14756 14757 14758 14759 14760 14761 14762 14763 14764 14765 14766 14767 14768 14769 14770 14771 14772 14773 14774 14775 14776 14777 14778 14779 14780 14781 14782 14783 14784 14785 14786 14787 14788 14789 14790 14791 14792 14793 14794 14795 14796 14797 14798 14799 14800 14801 14802 14803 14804 14805 14806 14807 14808 14809 14810 14811 14812 14813 14814 14815 14816 14817 14818 14819 14820 14821 14822 14823 14824 14825 14826 14827 14828 14829 14830 14831 14832 14833 14834 14835 14836 14837 14838 14839 14840 14841 14842 14843 14844 14845 14846 14847 14848 14849 14850 14851 14852 14853 14854 14855 14856 14857 14858 14859 14860 14861 14862 14863 14864 14865 14866 14867 14868 14869 14870 14871 14872 14873 14874 14875 14876 14877 14878 14879 14880 14881 14882 14883 14884 14885 14886 14887 14888 14889 14890 14891 14892 14893 14894 14895 14896 14897 14898 14899 14900 14901 14902 14903 14904 14905 14906 14907 14908 14909 14910 14911 14912 14913 14914 14915 14916 14917 14918 14919 14920 14921 14922 14923 14924 14925 14926 14927 14928 14929 14930 14931 14932 14933 14934 14935 14936 14937 14938 14939 14940 14941 14942 14943 14944 14945 14946 14947 14948 14949 14950 14951 14952 14953 14954 14955 14956 14957 14958 14959 14960 14961 14962 14963 14964 14965 14966 14967 14968 14969 14970 14971 14972 14973 14974 14975 14976 14977 14978 14979 14980 14981 14982 14983 14984 14985 14986 14987 14988 14989 14990 14991 14992 14993 14994 14995 14996 14997 14998 14999 15000 15001 15002 15003 15004 15005 15006 15007 15008 15009 15010 15011 15012 15013 15014 15015 15016 15017 15018 15019 15020 15021 15022 15023 15024 15025 15026 15027 15028 15029 15030 15031 15032 15033 15034 15035 15036 15037 15038 15039 15040 15041 15042 15043 15044 15045 15046 15047 15048 15049 15050 15051 15052 15053 15054 15055 15056 15057 15058 15059 15060 15061 15062 15063 15064 15065 15066 15067 15068 15069 15070 15071 15072 15073 15074 15075 15076 15077 15078 15079 15080 15081 15082 15083 15084 15085 15086 15087 15088 15089 15090 15091 15092 15093 15094 15095 15096 15097 15098 15099 15100 15101 15102 15103 15104 15105 15106 15107 15108 15109 15110 15111 15112 15113 15114 15115 15116 15117 15118 15119 15120 15121 15122 15123 15124 15125 15126 15127 15128 15129 15130 15131 15132 15133 15134 15135 15136 15137 15138 15139 15140 15141 15142 15143 15144 15145 15146 15147 15148 15149 15150 15151 15152 15153 15154 15155 15156 15157 15158 15159 15160 15161 15162 15163 15164 15165 15166 15167 15168 15169 15170 15171 15172 15173 15174 15175 15176 15177 15178 15179 15180 15181 15182 15183 15184 15185 15186 15187 15188 15189 15190 15191 15192 15193 15194 15195 15196 15197 15198 15199 15200 15201 15202 15203 15204 15205 15206 15207 15208 15209 15210 15211 15212 15213 15214 15215 15216 15217 15218 15219 15220 15221 15222 15223 15224 15225 15226 15227 15228 15229 15230 15231 15232 15233 15234 15235 15236 15237 15238 15239 15240 15241 15242 15243 15244 15245 15246 15247 15248 15249 15250 15251 15252 15253 15254 15255 15256 15257 15258 15259 15260 15261 15262 15263 15264 15265 15266 15267 15268 15269 15270 15271 15272 15273 15274 15275 15276 15277 15278 15279 15280 15281 15282 15283 15284 15285 15286 15287 15288 15289 15290 15291 15292 15293 15294 15295 15296 15297 15298 15299 15300 15301 15302 15303 15304 15305 15306 15307 15308 15309 15310 15311 15312 15313 15314 15315 15316 15317 15318 15319 15320 15321 15322 15323 15324 15325 15326 15327 15328 15329 15330 15331 15332 15333 15334 15335 15336 15337 15338 15339 15340 15341 15342 15343 15344 15345 15346 15347 15348 15349 15350 15351 15352 15353 15354 15355 15356 15357 15358 15359 15360 15361 15362 15363 15364 15365 15366 15367 15368 15369 15370 15371 15372 15373 15374 15375 15376 15377 15378 15379 15380 15381 15382 15383 15384 15385 15386 15387 15388 15389 15390 15391 15392 15393 15394 15395 15396 15397 15398 15399 15400 15401 15402 15403 15404 15405 15406 15407 15408 15409 15410 15411 15412 15413 15414 15415 15416 15417 15418 15419 15420 15421 15422 15423 15424 15425 15426 15427 15428 15429 15430 15431 15432 15433 15434 15435 15436 15437 15438 15439 15440 15441 15442 15443 15444 15445 15446 15447 15448 15449 15450 15451 15452 15453 15454 15455 15456 15457 15458 15459 15460 15461 15462 15463 15464 15465 15466 15467 15468 15469 15470 15471 15472 15473 15474 15475 15476 15477 15478 15479 15480 15481 15482 15483 15484 15485 15486 15487 15488 15489 15490 15491 15492 15493 15494 15495 15496 15497 15498 15499 15500 15501 15502 15503 15504 15505 15506 15507 15508 15509 15510 15511 15512 15513 15514 15515 15516 15517 15518 15519 15520 15521 15522 15523 15524 15525 15526 15527 15528 15529 15530 15531 15532 15533 15534 15535 15536 15537 15538 15539 15540 15541 15542 15543 15544 15545 15546 15547 15548 15549 15550 15551 15552 15553 15554 15555 15556 15557 15558 15559 15560 15561 15562 15563 15564 15565 15566 15567 15568 15569 15570 15571 15572 15573 15574 15575 15576 15577 15578 15579 15580 15581 15582 15583 15584 15585 15586 15587 15588 15589 15590 15591 15592 15593 15594 15595 15596 15597 15598 15599 15600 15601 15602 15603 15604 15605 15606 15607 15608 15609 15610 15611 15612 15613 15614 15615 15616 15617 15618 15619 15620 15621 15622 15623 15624 15625 15626 15627 15628 15629 15630 15631 15632 15633 15634 15635 15636 15637 15638 15639 15640 15641 15642 15643 15644 15645 15646 15647 15648 15649 15650 15651 15652 15653 15654 15655 15656 15657 15658 15659 15660 15661 15662 15663 15664 15665 15666 15667 15668 15669 15670 15671 15672 15673 15674 15675 15676 15677 15678 15679 15680 15681 15682 15683 15684 15685 15686 15687 15688 15689 15690 15691 15692 15693 15694 15695 15696 15697 15698 15699 15700 15701 15702 15703 15704 15705 15706 15707 15708 15709 15710 15711 15712 15713 15714 15715 15716 15717 15718 15719 15720 15721 15722 15723 15724 15725 15726 15727 15728 15729 15730 15731 15732 15733 15734 15735 15736 15737 15738 15739 15740 15741 15742 15743 15744 15745 15746 15747 15748 15749 15750 15751 15752 15753 15754 15755 15756 15757 15758 15759 15760 15761 15762 15763 15764 15765 15766 15767 15768 15769 15770 15771 15772 15773 15774 15775 15776 15777 15778 15779 15780 15781 15782 15783 15784 15785 15786 15787 15788 15789 15790 15791 15792 15793 15794 15795 15796 15797 15798 15799 15800 15801 15802 15803 15804 15805 15806 15807 15808 15809 15810 15811 15812 15813 15814 15815 15816 15817 15818 15819 15820 15821 15822 15823 15824 15825 15826 15827 15828 15829 15830 15831 15832 15833 15834 15835 15836 15837 15838 15839 15840 15841 15842 15843 15844 15845 15846 15847 15848 15849 15850 15851 15852 15853 15854 15855 15856 15857 15858 15859 15860 15861 15862 15863 15864 15865 15866 15867 15868 15869 15870 15871 15872 15873 15874 15875 15876 15877 15878 15879 15880 15881 15882 15883 15884 15885 15886 15887 15888 15889 15890 15891 15892 15893 15894 15895 15896 15897 15898 15899 15900 15901 15902 15903 15904 15905 15906 15907 15908 15909 15910 15911 15912 15913 15914 15915 15916 15917 15918 15919 15920 15921 15922 15923 15924 15925 15926 15927 15928 15929 15930 15931 15932 15933 15934 15935 15936 15937 15938 15939 15940 15941 15942 15943 15944 15945 15946 15947 15948 15949 15950 15951 15952 15953 15954 15955 15956 15957 15958 15959 15960 15961 15962 15963 15964 15965 15966 15967 15968 15969 15970 15971 15972 15973 15974 15975 15976 15977 15978 15979 15980 15981 15982 15983 15984 15985 15986 15987 15988 15989 15990 15991 15992 15993 15994 15995 15996 15997 15998 15999 16000 16001 16002 16003 16004 16005 16006 16007 16008 16009 16010 16011 16012 16013 16014 16015 16016 16017 16018 16019 16020 16021 16022 16023 16024 16025 16026 16027 16028 16029 16030 16031 16032 16033 16034 16035 16036 16037 16038 16039 16040 16041 16042 16043 16044 16045 16046 16047 16048 16049 16050 16051 16052 16053 16054 16055 16056 16057 16058 16059 16060 16061 16062 16063 16064 16065 16066 16067 16068 16069 16070 16071 16072 16073 16074 16075 16076 16077 16078 16079 16080 16081 16082 16083 16084 16085 16086 16087 16088 16089 16090 16091 16092 16093 16094 16095 16096 16097 16098 16099 16100 16101 16102 16103 16104 16105 16106 16107 16108 16109 16110 16111 16112 16113 16114 16115 16116 16117 16118 16119 16120 16121 16122 16123 16124 16125 16126 16127 16128 16129 16130 16131 16132 16133 16134 16135 16136 16137 16138 16139 16140 16141 16142 16143 16144 16145 16146 16147 16148 16149 16150 16151 16152 16153 16154 16155 16156 16157 16158 16159 16160 16161 16162 16163 16164 16165 16166 16167 16168 16169 16170 16171 16172 16173 16174 16175 16176 16177 16178 16179 16180 16181 16182 16183 16184 16185 16186 16187 16188 16189 16190 16191 16192 16193 16194 16195 16196 16197 16198 16199 16200 16201 16202 16203 16204 16205 16206 16207 16208 16209 16210 16211 16212 16213 16214 16215 16216 16217 16218 16219 16220 16221 16222 16223 16224 16225 16226 16227 16228 16229 16230 16231 16232 16233 16234 16235 16236 16237 16238 16239 16240 16241 16242 16243 16244 16245 16246 16247 16248 16249 16250 16251 16252 16253 16254 16255 16256 16257 16258 16259 16260 16261 16262 16263 16264 16265 16266 16267 16268 16269 16270 16271 16272 16273 16274 16275 16276 16277 16278 16279 16280 16281 16282 16283 16284 16285 16286 16287 16288 16289 16290 16291 16292 16293 16294 16295 16296 16297 16298 16299 16300 16301 16302 16303 16304 16305 16306 16307 16308 16309 16310 16311 16312 16313 16314 16315 16316 16317 16318 16319 16320 16321 16322 16323 16324 16325 16326 16327 16328 16329 16330 16331 16332 16333 16334 16335 16336 16337 16338 16339 16340 16341 16342 16343 16344 16345 16346 16347 16348 16349 16350 16351 16352 16353 16354 16355 16356 16357 16358 16359 16360 16361 16362 16363 16364 16365 16366 16367 16368 16369 16370 16371 16372 16373 16374 16375 16376 16377 16378 16379 16380 16381 16382 16383 16384 16385 16386 16387 16388 16389 16390 16391 16392 16393 16394 16395 16396 16397 16398 16399 16400 16401 16402 16403 16404 16405 16406 16407 16408 16409 16410 16411 16412 16413 16414 16415 16416 16417 16418 16419 16420 16421 16422 16423 16424 16425 16426 16427 16428 16429 16430 16431 16432 16433 16434 16435 16436 16437 16438 16439 16440 16441 16442 16443 16444 16445 16446 16447 16448 16449 16450 16451 16452 16453 16454 16455 16456 16457 16458 16459 16460 16461 16462 16463 16464 16465 16466 16467 16468 16469 16470 16471 16472 16473 16474 16475 16476 16477 16478 16479 16480 16481 16482 16483 16484 16485 16486 16487 16488 16489 16490 16491 16492 16493 16494 16495 16496 16497 16498 16499 16500 16501 16502 16503 16504 16505 16506 16507 16508 16509 16510 16511 16512 16513 16514 16515 16516 16517 16518 16519 16520 16521 16522 16523 16524 16525 16526 16527 16528 16529 16530 16531 16532 16533 16534 16535 16536 16537 16538 16539 16540 16541 16542 16543 16544 16545 16546 16547 16548 16549 16550 16551 16552 16553 16554 16555 16556 16557 16558 16559 16560 16561 16562 16563 16564 16565 16566 16567 16568 16569 16570 16571 16572 16573 16574 16575 16576 16577 16578 16579 16580 16581 16582 16583 16584 16585 16586 16587 16588 16589 16590 16591 16592 16593 16594 16595 16596 16597 16598 16599 16600 16601 16602 16603 16604 16605 16606 16607 16608 16609 16610 16611 16612 16613 16614 16615 16616 16617 16618 16619 16620 16621 16622 16623 16624 16625 16626 16627 16628 16629 16630 16631 16632 16633 16634 16635 16636 16637 16638 16639 16640 16641 16642 16643 16644 16645 16646 16647 16648 16649 16650 16651 16652 16653 16654 16655 16656 16657 16658 16659 16660 16661 16662 16663 16664 16665 16666 16667 16668 16669 16670 16671 16672 16673 16674 16675 16676 16677 16678 16679 16680 16681 16682 16683 16684 16685 16686 16687 16688 16689 16690 16691 16692 16693 16694 16695 16696 16697 16698 16699 16700 16701 16702 16703 16704 16705 16706 16707 16708 16709 16710 16711 16712 16713 16714 16715 16716 16717 16718 16719 16720 16721 16722 16723 16724 16725 16726 16727 16728 16729 16730 16731 16732 16733 16734 16735 16736 16737 16738 16739 16740 16741 16742 16743 16744 16745 16746 16747 16748 16749 16750 16751 16752 16753 16754 16755 16756 16757 16758 16759 16760 16761 16762 16763 16764 16765 16766 16767 16768 16769 16770 16771 16772 16773 16774 16775 16776 16777 16778 16779 16780 16781 16782 16783 16784 16785 16786 16787 16788 16789 16790 16791 16792 16793 16794 16795 16796 16797 16798 16799 16800 16801 16802 16803 16804 16805 16806 16807 16808 16809 16810 16811 16812 16813 16814 16815 16816 16817 16818 16819 16820 16821 16822 16823 16824 16825 16826 16827 16828 16829 16830 16831 16832 16833 16834 16835 16836 16837 16838 16839 16840 16841 16842 16843 16844 16845 16846 16847 16848 16849 16850 16851 16852 16853 16854 16855 16856 16857 16858 16859 16860 16861 16862 16863 16864 16865 16866 16867 16868 16869 16870 16871 16872 16873 16874 16875 16876 16877 16878 16879 16880 16881 16882 16883 16884 16885 16886 16887 16888 16889 16890 16891 16892 16893 16894 16895 16896 16897 16898 16899 16900 16901 16902 16903 16904 16905 16906 16907 16908 16909 16910 16911 16912 16913 16914 16915 16916 16917 16918 16919 16920 16921 16922 16923 16924 16925 16926 16927 16928 16929 16930 16931 16932 16933 16934 16935 16936 16937 16938 16939 16940 16941 16942 16943 16944 16945 16946 16947 16948 16949 16950 16951 16952 16953 16954 16955 16956 16957 16958 16959 16960 16961 16962 16963 16964 16965 16966 16967 16968 16969 16970 16971 16972 16973 16974 16975 16976 16977 16978 16979 16980 16981 16982 16983 16984 16985 16986 16987 16988 16989 16990 16991 16992 16993 16994 16995 16996 16997
|
\start
Date: Thu, 1 Feb 2007 06:15:50 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Asq rewritten
There were many plans to rewrite various parts of Axiom. I decided
to actually rewrite one part: the asq program :).
Actually my reasons for rewrite were:
1) Old asq was broken by trivial changes to database format (like
turning off compression, or pretty printing databases), the
new one should be more resistant.
2) Old asq was longish, verbose and used very unusal coding style.
3) Some people (Bill Page ???) hoped to use asq as a base for
browser access to Axiom databases, the new one hopefully is
easier to adapt/change than the old one.
Since the output of old asq was rather irregular, I have taken
liberty to change output formatting and command line options.
I hope that such change will cause no troubles.
Since the old asq documentation mostly duplicated daase.lisp.pamphlet,
I have written also completly new (short) documentation.
P.S. I just commited the new asq to wh-sandbox.
\start
Date: 01 Feb 2007 09:23:22 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Asq rewritten
Dear Waldek,
Waldek Hebisch writes:
> There were many plans to rewrite various parts of Axiom. I decided
> to actually rewrite one part: the asq program :).
Did you see the mail where I set a price? Well, I repeat the relevant bit here
anyway, slightly modified to make the intention clearer:
(Modifications in [...])
**OLD MAIL*********************************************************************
I think it's time to set a price again. I'll pay 100$ anyone who writes a new,
or modifies an existing program, that displays [in a standard webbrowser] the
documentation of a +++ environment (and only this bit of documentation) as
generated by ALLPROSE, on demand, i.e., using a web interface similar to that
Tim provided.
To get started, do the following
----------------------------------------------------------------------
svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
cd combinat/trunk/combinat
notangle -t8 Makefile.nw > Makefile
make VARIANTSTOBUILD=axiom
cd lib
for f in $(ar t libcombinatax.al); do ar x libcombinatax.al $f; done
for f in $(ar t libcombinatax.al); do echo ")lib $f" >> combinat.input; done
cd ../src
axiom
-- now everything of combinat is available. To generate a libdb.text say
)se co args "-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra -i ../include"
)co csseries
----------------------------------------------------------------------
(very likely, there is an easier way to generate the libdb file.)
To explain the process a bit: (Ralf, please correct me if I'm wrong)
make VARIANTSTOBUILD=axiom
extracts using noweb documentation and code from the source files, for example
series.as.nw. All of the code and the api description (i.e., everything between
\begin{+++} ... \end{+++} ) is put into a file csseries.as.
")co csseries" is one way to extract the +++ strings and write them into
libdb.text.
The best thing would be, of course, if one could simply call tex4ht on the
individual +++ strings. One would have to write a suitable LaTeX preamble, of
course, that \usepackages the appropriate style files. However, I do not know
how hyperlinking will work then. (In fact, I don't even understand hyperlinking
within ALLPROSE, and Ralf begs me to read the documentation since a few
months...)
Maybe it also makes sense to run a preprocessor over the literate
program. I.e., to modify ALLPROSE so that preprocecessed LaTeX (for example
html) is put into a database. But I would like the other solution better.
It would already be a great thing if doc could be displayed without
hyperlinks. That shouldn't be too hard, I believe.
**END OLD MAIL*****************************************************************
Here is a bit of the generated libdb.text:
dDataStream`1`x`(CoercibleTo(OutputForm))->etc`(T)`DATASTR`\begin{adusage} T == Integer s: \adthistype{} T := \adname{stream: T -> %} 0; s := \adname{stream: Generator T -> %}(generator [1, 3]); g: \adtype{Generator} T == generate for i in 2.. repeat yield i; s := \adname{stream: Generator T -> %} g; \end{adusage} \begin{addescription}{Implements an infinite array.} The domain \adthistype{} can be abstractly seen as an infinite array. However, to make thi----s data structure finite, it is more appropriate to view it as a pair $(a, g)$ of an \adcode$\adtype{Array}(T)$ and a \adcode$\adtype{Generator}(T)$. Like \adtype{Array}, \adthistype{} is 0-based. \end{addescription}
Non-standard environments and commands:
adusage and addescription are environments, adname, adthisname, adtype,
adthistype commands defined in combinat/trunc/allprose/aldordoc.sty.nw.
Below is a very short description, to see the full thing say
-------------------------------------------------------------------------------
cd combinat/trunk/combinat
make include-allprose-documentation colored html
konqueror doc/combinat.html
-------------------------------------------------------------------------------
and go to Section 33.
The short description:
adusage: explains how to use the constructor/operation by example
addescription: the argument of the environment is a one-line description, the
body a more detailed one
\adname: markup for a constant or operation. Should be hyperlinked to the
appropriate constant, operation.
\adtype: markup for a type constructor. Should be hyperlinked to the
appropriate type constructor.
\adthisname: expands to the constant or operation we are currently looking
at. (should not occur if we are just defining a type...)
\adthisname: expands to the constructor we are currently looking at, or, if we
we are just defining a constant or an operation, the constructor it
belongs to. In the example above, it expands to DataStream.
You can find the DataStream example properly typeset in Section 22.1.
To see an operation, look at stream: Generator T -> % (roughly five pages below
the definition of DataStream, which, in libdb.text reads as follows:
ostream`1`x`(Generator(T))->_$`dDataStream(T)``\begin{adusage} T == Integer; g: \adtype{Generator} T := generator [2,4,6,7]; s: \adthistype{} T := \adthisname{} g; \end{adusage} \begin{adparameters} \adparameter{g: Generator Integer} A (finite or infinite) generator that computes the next values of the stream. \end{adparameters} \begin{addescription}{Construct a stream.} The function constructs the stream \begin{gather} (g_1, g_2, g_3, \ldots----) \end{gather} or (informally) the infinite array \begin{adsnippet} [x for x in g] \end{adsnippet} where $g_i$ is the $i$-th element generated by the generator $g$. In case the stream $g$ is finite and generates $n$ elements then the result is \begin{gather} (g_1,...,g_{n-1}, g_n, g_n, g_n, \ldots). \end{gather} \end{addescription} \begin{adremarks} It is allowed to call \adthisname{} with a generator that does not --ge--nerate any element, but the resulting stream may not be ask to reveal any of its entries, since there are none. It is basically the same to say \adcode$\adthisname(generate)$ and \adcode$\adname{new}()$. \end{adremarks}
It is a mystery to me how Ralf did the linking magic. Maybe he or the
combinat.aux file can help...
\start
Date: Thu, 01 Feb 2007 10:10:37 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Asq rewritten
I think I have to reply to Martin's mail.
I don't have experience with the database, but slightly different from
what Martin wants, my intensions would go into another direction (which
are as a first approximation completely independent of ALLPROSE).
The Aldor compiler puts the ++ comments into the .ao files. Using
aldor -fasy file.ao
one basically gets all the information that is relevant, ie, code and ++
comments at the right place. Furthermore if one includes
-lalgebra -laldor
on the above command line, the compiler extracts exports from the
libraries and puts them into some place of domains in file.ao. That
would give a list of *all* the exports of a domain/category in file.ao.
Anyway, an .asy file basically is a LISP file, if I am not completely
wrong. So for a LISP expert that should be not too difficult to make
sense of it.
My current plans (no time for actually writing some code) would be to
take that .asy file and produce a .tex file which could be compiled into
.html via tex4ht. Actually, I go only via .tex because ALLPROSE uses the
convention to write a LaTeX-like syntax into the ++ comments.
Actually, ALLPROSE already contains the API, but not in an API-only
form. And I would very much like that one could fold and unfold the
*complete* list of exports of a domain and to have references from
categories to domains that use that category.
Ralf
On 02/01/2007 09:23 AM, Martin Rubey wrote:
> Dear Waldek,
>
> Waldek Hebisch writes:
>
>> There were many plans to rewrite various parts of Axiom. I decided
>> to actually rewrite one part: the asq program :).
>
> Did you see the mail where I set a price? Well, I repeat the relevant bit here
> anyway, slightly modified to make the intention clearer:
>
> (Modifications in [...])
>
>
> **OLD MAIL*********************************************************************
> I think it's time to set a price again. I'll pay 100$ anyone who writes a new,
> or modifies an existing program, that displays [in a standard webbrowser] the
> documentation of a +++ environment (and only this bit of documentation) as
> generated by ALLPROSE, on demand, i.e., using a web interface similar to that
> Tim provided.
[snip]
> It is a mystery to me how Ralf did the linking magic. Maybe he or the
> combinat.aux file can help...
Come on, Martin, there is no mystery. Since ALLPROSE introduced some
conventions of how to write domain and category definitions, it is quite
easy to extract their names from the code and put them into
\addefinetype{...}. When you use \adtype{...} it links to the place
where \addefinetype is. The definition of \addefinetype and \adtype
basically use commands from the hyperref LaTeX package and add some
indexing and color information. That is not too much magic.
\start
Date: Thu, 1 Feb 2007 04:39:39 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
On Wed, 31 Jan 2007 Waldek Hebisch wrote:
[...]
| Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
| ===================================================================
| --- branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-01-27 16:50:57 UTC (rev 425)
| +++ branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-02-01 05:09:31 UTC (rev 426)
| @@ -2,1559 +2,929 @@
| \usepackage{axiom}
| \begin{document}
| \title{\$SPAD/etc asq.c}
| -\author{Timothy Daly}
| +\author{Waldek Hebisch}
I believe the conventional wisdom would suggest that you add your name
as co-author as opposed to replacing the existing author, even if you
have rewritten it. If this were a separate new program not building on
previous ideas, I would that it is OK.
\start
Date: 01 Feb 2007 04:55:07 -0600
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Asq rewritten
Ralf Hemmecke writes:
| I think I have to reply to Martin's mail.
|
| I don't have experience with the database, but slightly different from
| what Martin wants, my intensions would go into another direction
| (which are as a first approximation completely independent of
| ALLPROSE).
|
| The Aldor compiler puts the ++ comments into the .ao files. Using
The old parser (used by the compiler) almost ignores comment -- you
don't see them directly in the parse tree; they are recorded
elsewhere. The new parser (used by the interpreter) has documentation
as part of the parse tree.
We have made some progress, here in the Parasol Lab, in terms of
understanding the Axiom compiler infrastructure. We plan to have
Axiom store algebras in formats that are close to the source trees.
Something betwen the "parse forms" and the internal AST that is fed to
compTopLevel for example, but that retained just about anything. The
new format is of course in addition to the existing ones.
\start
Date: Thu, 1 Feb 2007 14:34:53 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
Gabriel Dos Reis wrote:
> On Wed, 31 Jan 2007 Waldek Hebisch wrote:
>
> [...]
>
> | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
> | ===================================================================
> | --- branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-01-27 16:50:57 UTC (rev 425)
> | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-02-01 05:09:31 UTC (rev 426)
> | @@ -2,1559 +2,929 @@
> | \usepackage{axiom}
> | \begin{document}
> | \title{\$SPAD/etc asq.c}
> | -\author{Timothy Daly}
> | +\author{Waldek Hebisch}
>
> I believe the conventional wisdom would suggest that you add your name
> as co-author as opposed to replacing the existing author, even if you
> have rewritten it. If this were a separate new program not building on
> previous ideas, I would that it is OK.
>
Hmm, I undersand that conventional wisdom is to err on side of giving
more credit for work than too little credit, but I find this suggestion
a little extreme.
Gaby, did you look at both programs: the new asq is a _new_ program.
Re-used from the old program is starting Latex boilerplate, Latex
footer and AXIOM variable (assignment and a test). On the level of
ideas of course I re-used the very idea of having such a program
and tried to make it compatible (in particular I re-used most of
the option names). Also the general approach (using linear search)
is common. But that is basically all.
About 70% of the new program is a start of generic S-expression handling
library which has no couterpart in the old program. The rest is also
very different (in particular much simpler) due to use of S-expressions
and table driven option handling.
I think it is proper to have acknowledgement line like:
This program replaces an older one written by Tim Daly.
(the exact wording may be different).
\start
Date: Thu, 01 Feb 2007 16:11:14 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
Cc: Gabriel Dos Reis
>> I believe the conventional wisdom would suggest that you add your name
>> as co-author as opposed to replacing the existing author, even if you
>> have rewritten it. If this were a separate new program not building on
>> previous ideas, I would that it is OK.
>>
>
> Hmm, I undersand that conventional wisdom is to err on side of giving
> more credit for work than too little credit, but I find this suggestion
> a little extreme.
>
> Gaby, did you look at both programs: the new asq is a _new_ program.
> Re-used from the old program is starting Latex boilerplate, Latex
> footer and AXIOM variable (assignment and a test). On the level of
> ideas of course I re-used the very idea of having such a program
> and tried to make it compatible (in particular I re-used most of
> the option names). Also the general approach (using linear search)
> is common. But that is basically all.
>
> About 70% of the new program is a start of generic S-expression handling
> library which has no couterpart in the old program. The rest is also
> very different (in particular much simpler) due to use of S-expressions
> and table driven option handling.
>
> I think it is proper to have acknowledgement line like:
> This program replaces an older one written by Tim Daly. (*)
> (the exact wording may be different).
If the program is more or less completely new then it is OK if Waldek
just puts himself as an author. But removing Tim completely is, of
course, no option.
Waldek, what about including the above information of what you took over
and what you simplified in addition to the line (*)? You probably also
took over the interface since otherwise your program cannot simply
replace Tim's asq.
I think that Tim has already stated it before: respect.
\start
Date: Thu, 1 Feb 2007 09:54:15 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
On Thu, 1 Feb 2007, Waldek Hebisch wrote:
| Gabriel Dos Reis wrote:
| > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
| >
| > [...]
| >
| > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
| > | ===================================================================
| > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-01-27 16:50:57 UTC (rev 425)
| > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-02-01 05:09:31 UTC (rev 426)
| > | @@ -2,1559 +2,929 @@
| > | \usepackage{axiom}
| > | \begin{document}
| > | \title{\$SPAD/etc asq.c}
| > | -\author{Timothy Daly}
| > | +\author{Waldek Hebisch}
| >
| > I believe the conventional wisdom would suggest that you add your name
| > as co-author as opposed to replacing the existing author, even if you
| > have rewritten it. If this were a separate new program not building on
| > previous ideas, I would that it is OK.
| >
|
| Hmm, I undersand that conventional wisdom is to err on side of giving
| more credit for work than too little credit, but I find this suggestion
| a little extreme.
I'm not so sure.
| Gaby, did you look at both programs: the new asq is a _new_ program.
I read over your new "asq" and the old asq and followed your
explanation, *before* I sent my mail.
My opinion is that your name should be added co-author, not replace
the original author. Or, call the program something else and
acknowledge that this new program greatly benefited from the existing
one, in particular from its documentation and its errors. But having
two proram doing almost the same thing will be very confusing. So, I
believe the conventional wisdom is good here.
A ways to kepp a project attractice and collegial is to be cautious
with credit.
Look at GCC for example. Most parts of it have nothing common with
the GCC from 1996 or 1997. In particular, look at the C preprocessor;
it has been *completely* rewritten from scratch, with readically
different ideas. Nonetheless, the authorship displays the people who
did not "directly" contribute to the new program in any form.
\start
Date: Thu, 1 Feb 2007 20:04:50 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
> On Thu, 1 Feb 2007, Waldek Hebisch wrote:
>
> | Gabriel Dos Reis wrote:
> | > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
> | >
> | > [...]
> | >
> | > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
> | > | ===================================================================
> | > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-01-27 16:50:57 UTC (rev 425)
> | > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-02-01 05:09:31 UTC (rev 426)
> | > | @@ -2,1559 +2,929 @@
> | > | \usepackage{axiom}
> | > | \begin{document}
> | > | \title{\$SPAD/etc asq.c}
> | > | -\author{Timothy Daly}
> | > | +\author{Waldek Hebisch}
> | >
> | > I believe the conventional wisdom would suggest that you add your name
> | > as co-author as opposed to replacing the existing author, even if you
> | > have rewritten it. If this were a separate new program not building on
> | > previous ideas, I would that it is OK.
> | >
> |
> | Hmm, I undersand that conventional wisdom is to err on side of giving
> | more credit for work than too little credit, but I find this suggestion
> | a little extreme.
>
> I'm not so sure.
>
> | Gaby, did you look at both programs: the new asq is a _new_ program.
>
> I read over your new "asq" and the old asq and followed your
> explanation, *before* I sent my mail.
>
> My opinion is that your name should be added co-author, not replace
> the original author. Or, call the program something else and
> acknowledge that this new program greatly benefited from the existing
> one, in particular from its documentation and its errors. But having
> two proram doing almost the same thing will be very confusing. So, I
> believe the conventional wisdom is good here.
>
I fail to see how filename affects authorship status of a file. FYI
I developed under different name outside of Axiom tree. I started
copying a few lines from old asq but quickly realized that old code
do not fit into my design. So I wrote the program essentially from
scratch. <heresy> After the program was finished I have put literate
wrapper around it and dropped it into the source tree </heresy>.
IMHO the few copied lines are not more significant than a few declarations
that I copied form man pages.
Note that I do not claim any credit for the old asq program. And
I think that we should prominently state that previous version was
due to Tim Daly. But the \authors{} construct seem too limited
to correctly express such information.
AFAICS changing file name limits possibilty for
misunderstanding authorship, but is an inconvenience for users
(still, if you guys think that renaming is a way to go I will do
it). I do not consider keeping the old program as an option:
main reason to write the new one was that the old one does not
work with other changes that I am making.
> A ways to kepp a project attractice and collegial is to be cautious
> with credit.
>
> Look at GCC for example. Most parts of it have nothing common with
> the GCC from 1996 or 1997. In particular, look at the C preprocessor;
> it has been *completely* rewritten from scratch, with readically
> different ideas. Nonetheless, the authorship displays the people who
> did not "directly" contribute to the new program in any form.
>
I do not see information about authors in preprocessor program files,
only note like:
Copyright (C) 1986, 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
Free Software Foundation, Inc.
Contributed by Per Bothner, 1994-95.
Based on CCCP program by Paul Rubin, June 1986
Adapted to ANSI C, Richard Stallman, Jan 1987
IMHO such note is misleading by ommision, but at least dates allow
to infer that this information is highly incomplete. I see
Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
a few passages are taken almost verbatim from the old version.
I would guess that careful examination would show more connections.
So I consider it reasonable to state that Stallman is a coauthor
(assuming he did wrote version contained in gcc-1.35).
Concering programs: I did not look at preprocessor files. But I did
found surprising similarities between some parts of gcc-1.35 and
parts of gcc-4.1.1 -- after many edits code looks very different,
but clearly is still the same code.
\start
Date: Thu, 1 Feb 2007 13:24:16 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
On Thu, 1 Feb 2007, Waldek Hebisch wrote:
| > On Thu, 1 Feb 2007, Waldek Hebisch wrote:
| >
| > | Gabriel Dos Reis wrote:
| > | > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
| > | >
| > | > [...]
| > | >
| > | > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
| > | > | ===================================================================
| > | > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-01-27 16:50:57 UTC (rev 425)
| > | > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-02-01 05:09:31 UTC (rev 426)
| > | > | @@ -2,1559 +2,929 @@
| > | > | \usepackage{axiom}
| > | > | \begin{document}
| > | > | \title{\$SPAD/etc asq.c}
| > | > | -\author{Timothy Daly}
| > | > | +\author{Waldek Hebisch}
| > | >
| > | > I believe the conventional wisdom would suggest that you add your name
| > | > as co-author as opposed to replacing the existing author, even if you
| > | > have rewritten it. If this were a separate new program not building on
| > | > previous ideas, I would that it is OK.
| > | >
| > |
| > | Hmm, I undersand that conventional wisdom is to err on side of giving
| > | more credit for work than too little credit, but I find this suggestion
| > | a little extreme.
| >
| > I'm not so sure.
| >
| > | Gaby, did you look at both programs: the new asq is a _new_ program.
| >
| > I read over your new "asq" and the old asq and followed your
| > explanation, *before* I sent my mail.
| >
| > My opinion is that your name should be added co-author, not replace
| > the original author. Or, call the program something else and
| > acknowledge that this new program greatly benefited from the existing
| > one, in particular from its documentation and its errors. But having
| > two proram doing almost the same thing will be very confusing. So, I
| > believe the conventional wisdom is good here.
| >
|
| I fail to see how filename affects authorship status of a file.
Me enither. Why do you think it has anything to do with this?
[...]
| Note that I do not claim any credit for the old asq program.
Yes, and listing only your name as author implies claiming credits.
| > A ways to kepp a project attractice and collegial is to be cautious
| > with credit.
| >
| > Look at GCC for example. Most parts of it have nothing common with
| > the GCC from 1996 or 1997. In particular, look at the C preprocessor;
| > it has been *completely* rewritten from scratch, with readically
| > different ideas. Nonetheless, the authorship displays the people who
| > did not "directly" contribute to the new program in any form.
| >
|
| I do not see information about authors in preprocessor program files,
| only note like:
|
| Copyright (C) 1986, 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
| 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
| Free Software Foundation, Inc.
| Contributed by Per Bothner, 1994-95.
| Based on CCCP program by Paul Rubin, June 1986
| Adapted to ANSI C, Richard Stallman, Jan 1987
|
| IMHO such note is misleading by ommision, but at least dates allow
| to infer that this information is highly incomplete.
The prominent omission is the name of the second author you found in
cpp.texi to which we should add that of Neil Booth. You can cross
check those assertions either by looking the ChangeLog or digging the
archives (don't look at the ChangeLog in libcpp/, look at those in gcc/).
The original CPP worked on strings (contrary to ISO C specification),
and was an external program. The new CPP works on tokens and is
integrated to the C-family front-ends. There are very signficant
differences. The authors took the pain to preserve the old behaviour
through within the new, correct, implementation.
Put blunt, I think you did a grave act of violence by replacing
the existing asq.c with the new one witout explicit acknowlegement as
co-author (which I believe is the correct thing), and acknowledgment
section that traces the history of asq.c.
| I see
| Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
| cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
| a few passages are taken almost verbatim from the old version.
| I would guess that careful examination would show more connections.
| So I consider it reasonable to state that Stallman is a coauthor
| (assuming he did wrote version contained in gcc-1.35).
|
| Concering programs: I did not look at preprocessor files. But I did
| found surprising similarities between some parts of gcc-1.35 and
| parts of gcc-4.1.1 -- after many edits code looks very different,
| but clearly is still the same code.
It would be very interesting to see which portions of which files you
look at.
\start
Date: Thu, 1 Feb 2007 22:20:40 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
> On Thu, 1 Feb 2007, Waldek Hebisch wrote:
>
> | > On Thu, 1 Feb 2007, Waldek Hebisch wrote:
> | >
> | > | Gabriel Dos Reis wrote:
> | > | > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
> | > | >
> | > | > [...]
> | > | >
> | > | > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
> | > | > | ===================================================================
> | > | > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-01-27 16:50:57 UTC (rev 425)
> | > | > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet 2007-02-01 05:09:31 UTC (rev 426)
> | > | > | @@ -2,1559 +2,929 @@
> | > | > | \usepackage{axiom}
> | > | > | \begin{document}
> | > | > | \title{\$SPAD/etc asq.c}
> | > | > | -\author{Timothy Daly}
> | > | > | +\author{Waldek Hebisch}
> | > | >
> | > | > I believe the conventional wisdom would suggest that you add your name
> | > | > as co-author as opposed to replacing the existing author, even if you
> | > | > have rewritten it. If this were a separate new program not building on
> | > | > previous ideas, I would that it is OK.
> | > | >
> | > |
> | > | Hmm, I undersand that conventional wisdom is to err on side of giving
> | > | more credit for work than too little credit, but I find this suggestion
> | > | a little extreme.
> | >
> | > I'm not so sure.
> | >
> | > | Gaby, did you look at both programs: the new asq is a _new_ program.
> | >
> | > I read over your new "asq" and the old asq and followed your
> | > explanation, *before* I sent my mail.
> | >
> | > My opinion is that your name should be added co-author, not replace
> | > the original author. Or, call the program something else and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | > acknowledge that this new program greatly benefited from the existing
> | > one, in particular from its documentation and its errors. But having
> | > two proram doing almost the same thing will be very confusing. So, I
> | > believe the conventional wisdom is good here.
> | >
> |
> | I fail to see how filename affects authorship status of a file.
>
> Me enither. Why do you think it has anything to do with this?
>
How should I read what you wrote above? (I the place marked by ^ signs).
> [...]
>
> | Note that I do not claim any credit for the old asq program.
>
> Yes, and listing only your name as author implies claiming credits.
>
I do claim credit for the new file.
> Put blunt, I think you did a grave act of violence by replacing
> the existing asq.c with the new one witout explicit acknowlegement as
> co-author (which I believe is the correct thing), and acknowledgment
> section that traces the history of asq.c.
>
I am shocked by your words. For me "author" has clear meaning:
somebody who wrote the work or nontrivial part of it or at least had
significant influence on the shape of the work. I somebody replaced
something that I wrote by new thing but kept my name as an author
I would probably ask to romove my name -- taking credit for something
taht I did not would only devaluate credits due for things that I
really did. However, if Tim Daly feels as a coauthor of new asq
I will add his name. But I will not do this without his explicit
permission.
Concerning acknowledgment: I did a mistake here -- I was concetrating
on technical details and forgot about it. I would like to correct
this problem but opinions I hear from you (Gaby) and Ralph are
widely different.
> | I see
> | Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
> | cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
> | a few passages are taken almost verbatim from the old version.
> | I would guess that careful examination would show more connections.
> | So I consider it reasonable to state that Stallman is a coauthor
> | (assuming he did wrote version contained in gcc-1.35).
> |
> | Concering programs: I did not look at preprocessor files. But I did
> | found surprising similarities between some parts of gcc-1.35 and
> | parts of gcc-4.1.1 -- after many edits code looks very different,
> | but clearly is still the same code.
>
> It would be very interesting to see which portions of which files you
> look at.
>
IIRC this was in the C front end. But I am not sure if disscusing
gcc authorship is relevant here (what you wrote above only strengthened
my impression that gcc is not a good model to follow).
The point I wanted to make is: even if evolved text/code looks quite
different from the original its form is usually significantly
influenced by original author (and in many cases this influence
can be seen). I feel that "start from scratch" rewrite is quite
different.
\start
Date: Thu, 1 Feb 2007 16:03:47 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
On Thu, 1 Feb 2007, Waldek Hebisch wrote:
| > | > | Gaby, did you look at both programs: the new asq is a _new_ program.
| > | >
| > | > I read over your new "asq" and the old asq and followed your
| > | > explanation, *before* I sent my mail.
| > | >
| > | > My opinion is that your name should be added co-author, not replace
| > | > the original author. Or, call the program something else and
|
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| > | > acknowledge that this new program greatly benefited from the existing
| > | > one, in particular from its documentation and its errors. But having
| > | > two proram doing almost the same thing will be very confusing. So, I
| > | > believe the conventional wisdom is good here.
| > | >
| > |
| > | I fail to see how filename affects authorship status of a file.
| >
| > Me enither. Why do you think it has anything to do with this?
| >
|
| How should I read what you wrote above? (I the place marked by ^ signs).
Well, calling a program something else is not a matter of file-name.
You could very well put your codes in the *same* file asq.c, while
retaining the previous. But, that is not what is not. You have
*replaced* the existing one.
[...]
| I am shocked by your words. For me "author" has clear meaning:
| somebody who wrote the work or nontrivial part of it or at least had
| significant influence on the shape of the work. I somebody replaced
| something that I wrote by new thing but kept my name as an author
| I would probably ask to romove my name
yes, but I had not seen you putting Tim's name as co-author and he
asking for taking his name out. And in this case, I do believe that
Tim's initial effort and continued documentation (even not perfet,
e.g. duplication) does contribute substantially to the new code.
I just think we should not refrain for giving enough credits if we
ever want the place to be collegial and attracts more people.
This is my last word on this; I've said where I stand.
[...]
| > | I see
| > | Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
| > | cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
| > | a few passages are taken almost verbatim from the old version.
| > | I would guess that careful examination would show more connections.
| > | So I consider it reasonable to state that Stallman is a coauthor
| > | (assuming he did wrote version contained in gcc-1.35).
| > |
| > | Concering programs: I did not look at preprocessor files. But I did
| > | found surprising similarities between some parts of gcc-1.35 and
| > | parts of gcc-4.1.1 -- after many edits code looks very different,
| > | but clearly is still the same code.
| >
| > It would be very interesting to see which portions of which files you
| > look at.
| >
|
| IIRC this was in the C front end.
As I said, the C preproprocessor is a different component now,
separate from the C-family front-ends, with the integration done with
the parser -- instead of through temporary files as in the past.
Look at libcpp/.
| But I am not sure if disscusing
| gcc authorship is relevant here (what you wrote above only strengthened
| my impression that gcc is not a good model to follow).
I'm not sure. People contributing new components get their names in.
Others, such as Richard Henderson, are so universally recognized that
they don't think they need to put down their names :-)
\start
Date: Thu, 1 Feb 2007 14:12:26 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis, Waldek Hebisch
Subject: Re: axiom: [426] branches/wh-sandbox
--- Gabriel Dos Reis wrote:
> Put blunt, I think you did a grave act of violence by replacing
> the existing asq.c with the new one witout explicit acknowlegement as
> co-author (which I believe is the correct thing), and acknowledgment
> section that traces the history of asq.c.
In the interests of keeping this discussion productive, can anyone
point to an established (and insofar as is possible objective) standard
for evaluating when co-authorship credit should be awarded and when an
effort is sufficiently new to warrant sole authorship with a history?
I don't suppose simply diffing the files and looking for some minimum %
changed would be enough, but is there some relatively objective
criteria that can be established here to avoid friction?
I understand credit is something people feel strongly about,
particularly in an academic and open source enviornment, so I think it
would be beneficial to have some policy in this regard. I suspect this
situation is a bit unique - normally academic papers are not
sufficently direct in lineage to provoke a discussion on whether
authors of previous work should have co-authorship credit in the new.
If we treat Axiom in this fasion (literate programming and whatnot), I
would say the old pamphlet should be cited in appropriate places in the
new one in academic style (after all, if you want to re-use a graph
from an old paper, say in a thesis, you get and include permission and
then cite the source). An Axiom journal would be a major asset in this
respect, as new versions of pamphlets could be published in one section
of it and become true citable papers.
It's actually a bit of an interesting problem, because we don't want to
dilute authorship credits to the point of not being useful (which
author do you contact if a work lists twenty, and it turns out sixteen
of them worked only on previous versions and don't know anything about
the new one?) Even in regular computer science channels, there tends
to be a paper published that doesn't directly involve the source code -
really using the literate programming paradigm (where a paper building
on previous work to produce a better result will not just reference
other work but actually include it as part of the foundation on which
they are building subsequent work, as in this case) seems to introduce
some rather unique problems and deserves some careful consideration
about what practices should be used.
One thought might be to include certain "metadata" in the chunck
structure which could be used to automatically add citations and
credits - if we make an emacs mode (say) that when it reads an Axiom
pamphlet parses the metadata and tracks what is changed - then each
chunck knows who changed it and who didn't, and can automatically
produce citation links on that basis (for example, a code block that
survives unchanged through 4 major pamphlet revisions need only refer
to the original, since that is where it came from.) Maybe one of the
many source code management systems we have available could even
automate this feature based on commit diffs and who is commiting? Then
the question of "who wrote what" can be quickly and definitively
answered. If desirable there could be some "primary authorship"
decided based on how much of the current code is new compared to
previous versions. Peer review could be used to override abuses of the
system (for example, making unnecessary and trivial changes in enough
parts of the code to claim primary authorship.)
Imperfect ideas I'm sure, but maybe someone else has something better
to suggest?
\start
Date: Thu, 1 Feb 2007 18:18:43 -0500
From: Alfredo Portes
To: Cliff Yapp
Subject: Re: axiom: [426] branches/wh-sandbox
Cc: Gabriel Dos Reis
> One thought might be to include certain "metadata" in the chunck
> structure which could be used to automatically add citations and
> credits - if we make an emacs mode (say) that when it reads an Axiom
> pamphlet parses the metadata and tracks what is changed - then each
> chunck knows who changed it and who didn't, and can automatically
> produce citation links on that basis (for example, a code block that
> survives unchanged through 4 major pamphlet revisions need only refer
> to the original, since that is where it came from.) Maybe one of the
> many source code management systems we have available could even
> automate this feature based on commit diffs and who is commiting? Then
> the question of "who wrote what" can be quickly and definitively
> answered. If desirable there could be some "primary authorship"
> decided based on how much of the current code is new compared to
> previous versions. Peer review could be used to override abuses of the
> system (for example, making unnecessary and trivial changes in enough
> parts of the code to claim primary authorship.)
I know that this is not the current development process, but I think
Tim has explained before that in the pamphlet, when you correct
errors, modify or add, you should leave the old code as not used chunk
and add the new code explaining how it improves the old code, and it
serves like Gaby said to keep a history of the changes.
\start
Date: Thu, 1 Feb 2007 19:31:29 -0600
From: Tim Daly
To: list
Subject: authorship
I really hate to enter this debate because, apparently I'm at the
center of it. But there has been a policy of authorship and credit
in Axiom, although I probably never stated it clearly in one place.
I've held forth on the subject of authorship and/or credit in
Axiom before, for instance,
<http://lists.gnu.org/archive/html/axiom-developer/2003-08/msg00058.html>
Being a second-string academic all my life I've had a great deal
of experience with the topic, not all good.
I spent 19 years at IBM Research where "credit" is the coin of the
realm, so to speak. I remember spending years on a project, having
written a reasonable portion of the software, most of the tools, and a
large portion of a user's guide with 3 other people. The copy of the
guide I still have has 4 names on the cover. The DAY after I left the
project the guide was changed to exclude my name. I have a copy of the
"new" guide which is character-by-character the same except for my
name on the cover.
I also worked on a patent, which my notes (prior to joining IBM) show
as my idea only to have my name excluded from the patent application.
I also generated an idea, did the background research and wrote the
code to demonstrate the idea but when the paper was written and
submitted my name was nowhere to be found. (Names and identifying
details withheld, despite my policy of "liberal credit sharing" :-) ).
I spent years on another project which I rewrote in common lisp despite
protest (worse, a reprimand). The final project was shipped as common
lisp. The project generated a couple awards of $20,000 each. My name
was not mentioned in the announcement and I did not see a single
dollar of the cash.
Such events, no matter how well rationalized, always feel wrong.
I joined the scratchpad project and a few years later it was to
be sold. I spent time over several months trying to dig up the name
of everyone associated with the project. I put their name on the
documentation and I added a )credit function to the top level command
line of Axiom. I'm certain you don't know most of these people and
you do not know the roles they played in Axiom's history.
When Axiom was released as free software and I rewrote it into the
current literate form I originally claimed that the author of every
work was Nicolas Bourbaki, thinking that was a clever reference to
a mythical mathematician. I was later informed that this is an official
society in France and changed every author to "The Axiom Team".
<html://lists.gnu.org/archive/html/axiom-developer/2003-08/msg00062.html>
Later the "Axiom Team" idea bothered me as there were files for which
I clearly knew the author(s). Their names should be on the work.
I spent time trying to discover or guess the probable author
of each of the nearly 400 files.
Volume 1, the Tutorial book, includes a page that has the name of
everyone who contributed to Axiom up to that time, as far as I know.
The role is not important, it's the effort that counts. There are
people who are listed as contributors and/or authors where the current
work no longer contains a single line of code or documentation. But
they were the original authors.
I've just gotten permission to use portions of Joel Moses' work
as part of the documentation effort I'm doing for integration.
It may be that after reformating/editing/rewriting/rethinking
the whole effort there may not be a single line of text that
comes from his original contribution. Yet clearly Joel will be
listed as an author. Authorship is ideas as well as text. And
it is important. So important, in fact, that credit was the ONLY
request made in exchange for his generous contribution.
When considering the issue of authorship and credit ask yourself what
happens when, in 30 years, Axiom contains not a single line of code or
text that you wrote. Are you still an author? Should you still be in
the credit list? Is it meaningful for co-authorship to exist between
people who are 30 years apart in time? Does it hurt to share
authorship or credit? Is ``diff'' the golden standard?
As a matter of (my) policy it has been the case that the most liberal
guidelines were used for authorship and credit. I believe this tradition
should continue.
\start
Date: Thu, 1 Feb 2007 22:25:18 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: Tests of sage.
Francois,
Thank you for testing this.
I have been able to reproduce this problem. The same thing
happens to me. I am looking into the problem and I will let
you know a solution soon.
Regards,
Bill Page.
On January 31, 2007 9:31 AM Francois Maltey wrote:
>
> Many thanks for your pretty mail, Bill :
>
> > Please see the examples at:
> >
> > http://sage-notebook.axiom-developer.org/axiom
> >
> > I would be happy to answer any questions you have.
>
> So I download sage (a 130 MB file), untar and make the system.
>
What version of Sage did you download? As far as I can see the
most recent version of Sage (version 2.0) is "only" about 88 Mb.
http://modular.math.washington.edu/sage/dist/src/index.html
or
http://sage.scipy.org/sage/dist/src/index.html
I just finished downloading, untar and make of Sage-2.0 on a
OpenSuSE 10.2 linux system.
> As root I add axiom binary in the $PATH,
> and add also the main sage directory in the $PATH.
>
> I can run axiom -nox -nocle in a root-xterm.
>
On my system I have Axiom built from a recent version of the
build-improvements branch.
> As root I can run sage everywhere
> run install_scripts('/usr/local/bin') in sage,
> and lauch notebook()
>
> In x11 I open http://localhost:8000 with firefox.
> I get the screen of the sage system.
> I can type commands in bluebox.
>
> But I almost never obtain any results.
Make sure to press Shift+Enter to execute the contents of
the bluebox.
> Neither without system when I test 2*3
> neither for axiom when I type in two lines %axiom \\ 2+3.
>
I have very similar problems. But if I only enter Sage
commands, everything seems to work. If I try Axiom commands
then it fails. I see an error traceback in the Sage session
log. These same commands work properly on the Sage server
which is apparently running the same version of Sage but a
different version of Axiom.
> Return adds a break-line.
Use Shift+Enter to execute a cell.
> Evaluate rerun the session but result remains green box.
>
> What I forget ?
>
I think you are doing everything correct. There seems to be
some problem with Sage and/or Axiom. I recall that I had some
problem with readline when I first tested this and I am quite
sure that the 'axiom4sage-0.1.spkg' that is used on the Sage
server was built using gcl with readline disabled. I will
check this and get back to you.
\start
Date: Fri, 2 Feb 2007 15:03:29 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: authorship
Tim Daly wrote:
> When considering the issue of authorship and credit ask yourself what
> happens when, in 30 years, Axiom contains not a single line of code or
> text that you wrote. Are you still an author? Should you still be in
> the credit list? Is it meaningful for co-authorship to exist between
> people who are 30 years apart in time? Does it hurt to share
> authorship or credit? Is ``diff'' the golden standard?
>
I distinguish authorship and credit: calculus texbooks develop build
on ideas of Newton and Leibnitz (and many have structure similar to
19-century French texts) -- they acknowledge the intelectual acnestors,
but the authors of previous works are not authors of new ones.
Diff is not "the golden standard": it can be easily fooled by reformatting
or trivial changes, IMHO it is importat if structure of original work
remains (translation into another language may change every word, but
preserves structure).
I think that authors should be comfortable with the idea that work
that at one time was useful/important gets replaced by newer works.
If part that I wrote is replaced by something new I am no longer
author of the new part, when the whole work changes enough I am no
longer author of the new work. That does not diminsh credit for past
work. In the mailing list archive (close to the links you gave)
I found the following passage written by Matt Kaufmann:
----
The Boyer-Moore theorem prover, also called Nqthm, is indeed a product of Bob
Boyer and J Moore. ACL2 is authored by me (Matt Kaufmann) and J Moore, albeit
with significant early contributions from Boyer, who however is no longer
involved (by his choice).
----
So now authors of ACL2 are Kaufmann and Moore, while Boyer contribution
is acknowledged, but he is no longer considered as an author -- that
looks right for me.
> As a matter of (my) policy it has been the case that the most liberal
> guidelines were used for authorship and credit. I believe this tradition
> should continue.
>
I wrote (in response to Gaby, cc-ed to you):
| For me "author" has clear meaning:
| somebody who wrote the work or nontrivial part of it or at least had
| significant influence on the shape of the work. I somebody replaced
| something that I wrote by new thing but kept my name as an author
| I would probably ask to romove my name -- taking credit for something
| that I did not would only devaluate credits due for things that I
| really did. However, if Tim Daly feels as a coauthor of new asq
| I will add his name. But I will not do this without his explicit
| permission.
Tim, you have indirectly answered my question. But I have to
ask you explicitly: Do you agree to have your name in \author
field (as opposed to being mentioned in credits/acknowledments
section) of the asq.c.pamplet file commited to wh-sandbox
branch. If you want to know more about this file I described
how this file took current shape in:
http://lists.gnu.org/archive/html/axiom-developer/2007-02/msg00005.html
and
http://lists.gnu.org/archive/html/axiom-developer/2007-02/msg00008.html
\start
Date: Fri, 2 Feb 2007 15:23:09 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [427] branches/wh-sandbox
> On Thu, 1 Feb 2007 Waldek Hebisch wrote:
>
> | + * src/interp/setq.lisp.pamphlet: Turn on pretty printing.
>
> I think this should go on build-improvements too.
> There is no single day, here, where I haven't set *print-pretty* when
> dumping.
>
Do you want just setq part (this is one-liner) below, or do you
also want nicely printed databases? Database part needs my older
change '*do-not-compress-databases*' variable and would brake asq
(asq in wh-sandbox tolerates uncompressed/prettyprinted databases).
diff -ru --exclude=.svn wh-sandbox2/src/interp/setq.lisp.pamphlet ../wh-sandbox2/src/interp/setq.lisp.pamphlet
--- wh-sandbox2/src/interp/setq.lisp.pamphlet 2006-12-03 04:23:54.000000000 +0100
+++ ../wh-sandbox2/src/interp/setq.lisp.pamphlet 2007-01-30 23:11:50.000000000 +0100
@@ -185,7 +185,7 @@
;; Common lisp control variables
;;(setq *load-verbose* nil)
(setq *print-array* nil)
-(setq *print-pretty* nil)
+(setq *print-pretty* t)
(setq *print-circle* nil)
;; $SYSCOMMANDS is now defined at the top of i-syscmd.boot
\start
Date: 02 Feb 2007 10:13:28 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: authorship
Waldek Hebisch writes:
[...]
| Tim, you have indirectly answered my question. But I have to
| ask you explicitly: Do you agree to have your name in \author
| field (as opposed to being mentioned in credits/acknowledments
| section) of the asq.c.pamplet file commited to wh-sandbox
| branch.
I'm sorry to say it this way: this is getting insane.
\start
Date: Fri, 2 Feb 2007 12:57:04 -0600
From: Tim Daly
To: Waldek Hebisch
Subject: authorship
Well, I've been reasonably clear about what I believe the Axiom
policy should be and my opinion of what is a reasonable course.
Since I do all merges by hand, when I got to the line that does
the \author merge I would jointly list the authorship of all of
the prior people with all of the new people, quite independent
of the fact that my name is involved.
You chose to "modify" the file rather than replace the file
so in the main line merge I'd have over-ridden your choice
of \author line and changed it to read (in alphabetical order):
\author{Timothy Daly and Waldek Hebisch}
If you, or anyone feels, that they should have sole authorship
the simple solution is to create a new source filename and then
modify the build script to drop the old file and use the new one.
The build script could compile "newasq.pamphlet" into the bin/asq
function and all would still work. When merging the new file the
issue would not arise and the new file would retain sole authorship.
I have no feelings either way about asq. Indeed, I hadn't noticed
anything until it was mentioned. I do my best not to "own" programs or
keep emotional attachments to them, both of which tend to cause friction
in the open source model.
\start
Date: Fri, 2 Feb 2007 20:40:24 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: authorship
> Well, I've been reasonably clear about what I believe the Axiom
> policy should be and my opinion of what is a reasonable course.
>
> Since I do all merges by hand, when I got to the line that does
> the \author merge I would jointly list the authorship of all of
> the prior people with all of the new people, quite independent
> of the fact that my name is involved.
>
> You chose to "modify" the file rather than replace the file
> so in the main line merge I'd have over-ridden your choice
> of \author line and changed it to read (in alphabetical order):
>
> \author{Timothy Daly and Waldek Hebisch}
>
OK, so I am now putting the above in wh-sandbox version.
\start
Date: Sat, 03 Feb 2007 15:13:58 +0100
From: Gregory Vanuxem
To: list
Subject: series2.output
Hello,
Can someone send me the generated output of the input file
series2.input, which is in src/input ? I have a problem with GCL, so I
tested under Windows where this problem doesn't seem present but I need
to be sure of these results.
\start
Date: Sat, 03 Feb 2007 16:22:24 +0100
From: Gregory Vanuxem
To: list
Subject: Re: series2.output
Forget my request... There is MathAction :-)
\start
Date: Sat, 03 Feb 2007 16:37:40 +0100
From: Gregory Vanuxem
To: list
Subject: Re: series2.output
There is a apparently a problem in the Build-improvements branch or may
be in GCL, I have no idea (I can reproduce the following on MathAction
(build-improvements)):
=======================================================================
Gold:
(2) -> f:=taylor(1-x^2)
2
(2) 1 - x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(3) -> sin asin f
2 11
(3) 1 - x + O(x )
========================================================================
Build-improvements:
========================================================================
(11) -> f:=taylor(1-x^2)
2
(11) 1 - x
Type: UnivariateTaylorSeries(Expression Integer,x,0)
(12) -> sin asin f
1 4 1 6 7 8 5 10 11
(12) 1 - - x - -- x - --- x - ---- x + O(x )
4 16 768 3072
Type: UnivariateTaylorSeries(Expression Integer,x,0)
========================================================================
etc... (see series2.input)
\start
Date: Sat, 3 Feb 2007 18:05:52 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: series2.output
> There is a apparently a problem in the Build-improvements branch or may
> be in GCL, I have no idea (I can reproduce the following on MathAction
> (build-improvements)):
>
> =======================================================================
> Gold:
>
> (2) -> f:=taylor(1-x^2)
>
> 2
> (2) 1 - x
> Type: UnivariateTaylorSeries(Expression Integer,x,0)
> (3) -> sin asin f
>
> 2 11
> (3) 1 - x + O(x )
> ========================================================================
> Build-improvements:
> ========================================================================
> (11) -> f:=taylor(1-x^2)
>
> 2
> (11) 1 - x
> Type: UnivariateTaylorSeries(Expression Integer,x,0)
>
> (12) -> sin asin f
>
> 1 4 1 6 7 8 5 10 11
> (12) 1 - - x - -- x - --- x - ---- x + O(x )
> 4 16 768 3072
> Type: UnivariateTaylorSeries(Expression Integer,x,0)
> ========================================================================
>
AFAICS this is bug 312 in action. This bug appeared as a byproduct
of fix for bug 63. Igor Khavkine found the wrong place and proposed
a fix, wh-sandbox contains slightly different fix.
\start
Date: Sat, 03 Feb 2007 18:31:53 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: series2.output
Le samedi 03 f=E9vrier 2007 =E0 18:05 +0100, Waldek Hebisch a =E9crit :
> > There is a apparently a problem in the Build-improvements branch or m=
ay
> > be in GCL, I have no idea (I can reproduce the following on MathActio=
n
> > (build-improvements)):
> >
> > ========================
==========================
=======================
> > Gold:
> >
> > (2) -> f:=taylor(1-x^2)
> >
> > 2
> > (2) 1 - x
> > Type: UnivariateTaylorSeries(Expression Integer,x,=
0)
> > (3) -> sin asin f
> >
> > 2 11
> > (3) 1 - x + O(x )
> > ========================
==========================
========================
> > Build-improvements:
> > ========================
==========================
========================
> > (11) -> f:=taylor(1-x^2)
> >
> > 2
> > (11) 1 - x
> > Type: UnivariateTaylorSeries(Expression Integer,x,0=
)
> >
> > (12) -> sin asin f
> >
> > 1 4 1 6 7 8 5 10 11
> > (12) 1 - - x - -- x - --- x - ---- x + O(x )
> > 4 16 768 3072
> > Type: UnivariateTaylorSeries(Expression Integer,x,0=
)
> > ========================
==========================
========================
> >
>
> AFAICS this is bug 312 in action. This bug appeared as a byproduct
> of fix for bug 63. Igor Khavkine found the wrong place and proposed
> a fix, wh-sandbox contains slightly different fix.
Yes you're right, my version of Gold contains the Igor Kahvkine's patch.
Will look in your patches (on my BIG TODO list).
\start
Date: Sat, 03 Feb 2007 15:41:57 -0500
From: William Sit
To: list
Subject: How to allocate more space for Axiom on Windows
I was trying to solve a homogeneous parametric linear system
(9 by 9) with 18 parameters that Dhagash Mehta
<dhagash.mehta@adelaide.edu.au> recently sent me. The
coefficient matrix is:
(1) -> )library PLEQN
ParametricLinearEquations is now explicitly exposed in
frame initial
ParametricLinearEquations will be automatically loaded
when needed
(2) -> amat := [[-a[1, 2, 1, 1] - a[2, 1, 1, 1] - b[1, 1, 1,
3] - b[1, 1, 3, 1],
a[1, 2, 1, 1], -b[1, 1, 1, 3], a[2, 1, 1, 1], 0, 0, -b[1,
1, 3, 1], 0, 0],_
[a[1, 2, 1, 1], -a[1, 2, 1, 1] - a[1, 3, 1, 2] - a[2, 2,
1, 2] - b[1, 2, 3,2],
a[1, 3, 1, 2], 0, a[2, 2, 1, 2], 0, 0, -b[1, 2, 3, 2], 0],_
[-b[1, 1, 1, 3], a[1, 3, 1, 2], -a[1, 3, 1, 2] - a[2, 3,
1, 3] - b[1, 1, 1, 3]
- b[1, 3, 3, 3], 0, 0, a[2, 3, 1, 3], 0, 0, -b[1, 3, 3,
3]],_
[a[2, 1, 1, 1], 0, 0, -a[2, 1, 1, 1] - a[2, 2, 2, 1] -
a[3, 1, 2, 1] - b[2, 1,
2, 3], a[2, 2, 2, 1], -b[2, 1, 2, 3], a[3, 1, 2, 1], 0, 0],_
[0, a[2, 2, 1, 2], 0, a[2, 2, 2, 1], -a[2, 2, 1, 2] - a[2,
2, 2, 1] - a[2, 3,2
, 2] - a[3, 2, 2, 2], a[2, 3, 2, 2], 0, a[3, 2, 2, 2], 0],_
[0, 0, a[2, 3, 1, 3], -b[2, 1, 2, 3], a[2, 3, 2, 2], -a[2,
3, 1, 3] - a[2, 3,2
, 2] - a[3, 3, 2, 3] - b[2, 1, 2, 3], 0, 0, a[3, 3, 2, 3]],_
[-b[1, 1, 3, 1], 0, 0, a[3, 1, 2, 1], 0, 0, -a[3, 1, 2, 1]
- a[3, 2, 3, 1] -b[
1, 1, 3, 1] - b[3, 1, 3, 3], a[3, 2, 3, 1], -b[3, 1, 3,
3]],_
[0, -b[1, 2, 3, 2], 0, 0, a[3, 2, 2, 2], 0, a[3, 2, 3, 1],
-a[3, 2, 2, 2] -a[3
, 2, 3, 1] - a[3, 3, 3, 2] - b[1, 2, 3, 2], a[3, 3, 3, 2]],_
[0, 0, -b[1, 3, 3, 3], 0, 0, a[3, 3, 2, 3], -b[3, 1, 3,
3], a[3, 3, 3, 2],-a[3
, 3, 2, 3] - a[3, 3, 3, 2] - b[1, 3, 3, 3] - b[3, 1, 3,
3]]];
(2) -> psolve(amat)
>> System error:
The storage for CONS is exhausted.
Currently, 82689 pages are allocated.
Use ALLOCATE to expand the space.
Can any one tell me how to increase the space? Exactly how
big is one page? I have 2GB RAM. Is it possible to allocate
the max to Axiom (under Windows XP)?
\start
Date: Sat, 03 Feb 2007 16:02:13 -0500
From: William Sit
To: list
Subject: Re: How to allocate more space for Axiom on Windows
On Sat, 03 Feb 2007 15:41:57 -0500
William Sit wrote:
> >> System error:
> The storage for CONS is exhausted.
>Currently, 82689 pages are allocated.
>Use ALLOCATE to expand the space.
>
>Can any one tell me how to increase the space? Exactly
>how
>big is one page? I have 2GB RAM. Is it possible to
>allocate
>the max to Axiom (under Windows XP)?
>
Let me add that on my system, the XP OS normally used
about under 800 MB with multiple programs open. When Axiom
started the CPU monitor shows 770MB and when the command
psolve(amat) started, the memory usage rose all the way to
about 1.20 GB and then quit. So there is plenty of
physical RAM left (not to mention virtual RAM). I repeated
this and Axiom aborted with:
>> System error:
The storage for CONS is exhausted.
Currently, 97956 pages are allocated.
Use ALLOCATE to expand the space.
protected-symbol-warn called with (NIL)
\start
Date: Sat, 3 Feb 2007 22:25:47 +0100 (CET)
From: Waldek Hebisch
To: William Sit
Subject: Re: How to allocate more space for Axiom on Windows
William Sit wrote:
> >> System error:
> The storage for CONS is exhausted.
> Currently, 82689 pages are allocated.
> Use ALLOCATE to expand the space.
>
> Can any one tell me how to increase the space? Exactly how
> big is one page? I have 2GB RAM. Is it possible to allocate
> the max to Axiom (under Windows XP)?
>
Have you tried to follow the advice:
)lisp (allocate 'cons 200000 t)
(Or some bigger number instead of 200000). Using gcl 2.6.7 I can
maximally give 110000 (120000 is refused, few numbers between crashed
gcl). Using gcl 2.6.8 I can give bigger values. Typically page
means 4 kilobytes, that would agree with process size (empty Axiom
about 80 Mb, around 900 Mb after allocating 200000 pages).
\start
Date: Sat, 03 Feb 2007 22:39:05 +0100
From: Gregory Vanuxem
To: William Sit
Subject: Re: How to allocate more space for Axiom on Windows
Le samedi 03 f=E9vrier 2007 =E0 16:02 -0500, William Sit a =E9crit :
> On Sat, 03 Feb 2007 15:41:57 -0500
> William Sit wrote:
> > >> System error:
> > The storage for CONS is exhausted.
> >Currently, 82689 pages are allocated.
> >Use ALLOCATE to expand the space.
> >
> >Can any one tell me how to increase the space? Exactly
> >how
> >big is one page?
4096 bytes (1 << 12)
)lis (room) will tell you the number of page availables. This is fixed
at compile time so if you have compiled with the default options you'll
be limited to 512Mo (and I don't know exactly the memory organisation,
Camm could tell you, but you'll not be able I think to allocate all the
space for cons since there are contiguous pages, relocatable pages ...).
You can use the function allocate:
-- Function: ALLOCATE (type number &optional (really-allocate nil))
Package:LISP
GCL specific: Sets the maximum number of pages for the type class
of the GCL implementation type TYPE to NUMBER. If REALLY-ALLOCATE
is given a non-NIL value, then the specified number of pages will
be allocated immediately.
>(room)
434/434 47.5% CONS BIGNUM RATIO COMPLEX STRUCTURE
7/45 76.9% FIXNUM SHORT-FLOAT LONG-FLOAT CHARACTER
RANDOM-STATE READTABLE SPICE
154/736 85.6% SYMBOL STREAM PATHNAME CCLOSURE CLOSURE
1/2 23.9% PACKAGE
2/59 21.2% ARRAY HASH-TABLE VECTOR BIT-VECTOR
21/33 97.9% CFUN CFDATA
45/59 99.1% SFUN STRING GFUN VFUN AFUN
805/2215 contiguous (125 blocks)
26214 hole
10485 0.0% relocatable
664 pages for cells
38168 total pages
202532 pages available
21444 pages in heap but not gc'd + pages needed for gc marking
262144 maximum pages
>(allocate 'cons 512)
T
>(room)
434/512 48.8% CONS BIGNUM RATIO COMPLEX STRUCTURE
7/45 81.7% FIXNUM SHORT-FLOAT LONG-FLOAT CHARACTER
RANDOM-STATE READTABLE SPICE
154/736 85.6% SYMBOL STREAM PATHNAME CCLOSURE CLOSURE
1/2 23.9% PACKAGE
2/59 21.2% ARRAY HASH-TABLE VECTOR BIT-VECTOR
21/33 97.9% CFUN CFDATA
45/59 99.4% SFUN STRING GFUN VFUN AFUN
805/2215 contiguous (120 blocks)
26214 hole
10485 0.0% relocatable
664 pages for cells
38168 total pages
202532 pages available
21444 pages in heap but not gc'd + pages needed for gc marking
262144 maximum pages
Greg
----------------------------------------------------------------------
Random documentation (under LGPL I think):
-- Variable: *IGNORE-MAXIMUM-PAGES*
Package:SI GCL specific: Tells the GCL memory manager whether
(non-NIL) or not (NIL) it should expand memory whenever the
maximum allocatable pages have been used up.
-- Variable: *OPTIMIZE-MAXIMUM-PAGES*
Package:SI
GCL specific: Tells the GCL memory manager whether to attempt to
adjust the maximum allowable pages for each type to approximately
optimize the garbage collection load in the current process.
Defaults to T. Set to NIL if you care more about memory usage
than runtime.
-- Function: GBC (x)
Package:LISP
GCL specific: Invokes the garbage collector (GC) with the
collection level specified by X. NIL as the argument causes GC to
collect cells only. T as the argument causes GC to collect
everything.
-- Function: MAXIMUM-CONTIGUOUS-PAGES ()
Package:SI
GCL specific: Returns the current maximum number of pages for
contiguous blocks.
-- Function: GET-HOLE-SIZE ()
Package:SI
GCL specific: Returns as a fixnum the size of the memory hole (in
pages).
-- Function: ALLOCATE-CONTIGUOUS-PAGES (number &optional
(really-allocate nil))
Package:SI
GCL specific: Sets the maximum number of pages for contiguous
blocks to NUMBER. If REALLY-ALLOCATE is non-NIL, then the
specified number of pages will be allocated immediately.
-- Function: MAXIMUM-ALLOCATABLE-PAGES (type)
Package:SI
GCL specific: Returns the current maximum number of pages for the
type class of the GCL implementation type TYPE.
-- Function: ALLOCATED-RELOCATABLE-PAGES ()
Package:SI
GCL specific: Returns the number of pages currently allocated for
relocatable blocks.
-- Function: MAXIMUM-CONTIGUOUS-PAGES ()
Package:SI
GCL specific: Returns the current maximum number of pages for
contiguous blocks.
-- Function: GET-HOLE-SIZE ()
Package:SI
GCL specific: Returns as a fixnum the size of the memory hole (in
pages).
-- Function: SET-HOLE-SIZE (fixnum)
Package:SI
GCL specific: Sets the size of the memory hole (in pages).
-- Funcition: ALLOCATED (type)
Package:SI
Returns 6 values:
nfree
number free
npages
number of pages
maxpage
number of pages to grow to
nppage
number per page
gbccount
number of gc's due to running out of items of this size
nused
number of items used
Note that all items of the same size are stored on similar pages.
Thus for example on a 486 under linux the following basic types are
all the same size and so will share the same allocated information:
CONS BIGNUM RATIO COMPLEX STRUCTURE.
-- Variable: *LISP-MAXPAGES*
Package:SI GCL specific: Holds the maximum number of pages (1 page
= 2048 bytes) for the GCL process. The result of changing the
value of SI:*LISP-MAXPAGES* is unpredictable.
-- Variable: *MULTIPLY-STACKS*
Package:SI
If this variable is set to a positive fixnum, then the next time
through the TOP-LEVEL loop, the loop will be exited. The size of
the stacks will be multiplied by the value of *multiply-stacks*,
and the TOP-LEVEL will be called again. Thus to double the size
of the stacks:
>(setq si::*multiply-stacks* 2) [exits top level and reinvokes it,
with the new stacks in place] >
We must exit TOP-LEVEL, because it and any other lisp functions
maintain many pointers into the stacks, which would be incorrect
when the stacks have been moved. Interrupting the process of
growing the stacks, can leave you in an inconsistent state.
-- Function: ALLOCATE-GROWTH (type min max percent percent-free)
Package:SI
The next time after a garbage collection for TYPE, if PERCENT-FREE
of the objects of this TYPE are not actually free, and if the
maximum number of pages for this type has already been allocated,
then the maximum number will be increased by PERCENT of the old
maximum, subject to the condition that this increment be at least
MIN pages and at most MAX pages. A list of the previous values
for min, max, percent, and percent-free for the type TYPE is
returned. A value of 0 means use the system default, and if an
argument is out of range then the current values are returned with
no change made.
Examples: (si::allocate-growth 'cons 1 10 50 10) would insist that
after a garbage collection for cons, there be at least 10% cons's
free. If not the number of cons pages would be grown by 50% or
10 pages which ever was smaller. This might be reasonable if you
were trying to build an image which was `full', ie had few free
objects of this type.
(si::allocate-growth 'fixnum 0 10000 30 40) would grow space till
there were normally 40% free fixnums, usually growing by 30% per
time.
(si::allocate-growth 'cons 0 0 0 40) would require 40% free conses
after garbage collection for conses, and would use system defaults
for the the rate to grow towards this goal.
(si::allocate-growth 'cons -1 0 0 0) would return the current
values, but not make any changes.
> I have 2GB RAM. Is it possible to
> >allocate
> >the max to Axiom (under Windows XP)?
> >
> Let me add that on my system, the XP OS normally used
> about under 800 MB with multiple programs open. When Axiom
> started the CPU monitor shows 770MB and when the command
> psolve(amat) started, the memory usage rose all the way to
> about 1.20 GB and then quit. So there is plenty of
> physical RAM left (not to mention virtual RAM). I repeated
> this and Axiom aborted with:
>
> >> System error:
> The storage for CONS is exhausted.
> Currently, 97956 pages are allocated.
> Use ALLOCATE to expand the space.
>
> protected-symbol-warn called with (NIL)
\start
Date: Sun, 04 Feb 2007 04:08:03 -0500
From: William Sit
To: Waldek Hebisch
Subject: Re: How to allocate more space for Axiom on Windows
Thanks, Waldek. I tried as you suggested; the allocate produces a system
error unless I use a very small number. Nonetheless, the CONS type space
seems to have 200000 even though there is an error message.
However, when I run the computation, it stops again. So I am not sure if
I got any extra space that way (the max page is still the same) or it is
some other type of memory that needs to be increased. I am limited to
131072 pages (using (room), as suggested by Gregory Vanuxem -- Greg,
thanks for the docs). So it looks like 512MB. I am using a precompiled
version on Windows. I have no idea what gcl I am using.
I also tried the commands from SI but the run always quit after using up
the pages (but there is still plenty of physical memory).
William
----- transcript from trials
(2) -> )lisp (ALLOCATE 'cons 200000 t))
>> System error:
Can't allocate 200000 pages for CONS.
protected-symbol-warn called with (NIL)
(2) -> )lisp (room)
52815/200000 1.3% 115CONS RATIO COMPLEX STRUCTURE
73/200 42.9% FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABLE
NIL
224/500 97.4% SYMBOL STREAM
1/8 23.1% PACKAGE
3651/5114 0.4% 12 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSURE
FAT-STRING
125/500 69.7% STRING
100/100 12.6% 1 CFUN BIGNUM LONG-FLOAT
34/89 99.4% SFUN GFUN CFDATA SPICE NIL
4293/5347 2 contiguous (234 blocks)
2000 hole
9161 0.6% 38 relocatable
57023 pages for cells
72477 total pages
45060 pages available
13535 pages in heap but not gc'd + pages needed for gc marking
131072 maximum pages
Value = NIL
(2) -> psolve(amat,9)
>> System error:
The storage for CONS is exhausted.
Currently, 82872 pages are allocated.
Use ALLOCATE to expand the space.
protected-symbol-warn called with (NIL)
(2) -> )lisp (room)
82872/200000 71.5% 143CONS RATIO COMPLEX STRUCTURE
73/200 41.8% FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABLE
NIL
224/500 97.3% SYMBOL STREAM
1/8 23.1% PACKAGE
5114/5114 0.3% 27 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSURE
FAT-STRING
125/500 68.9% STRING
100/100 12.2% 2 CFUN BIGNUM LONG-FLOAT
34/89 99.4% SFUN GFUN CFDATA SPICE NIL
4293/5347 2 contiguous (234 blocks)
2000 hole
15931 30.3% 59 relocatable
88543 pages for cells
110767 total pages
0 pages available
20305 pages in heap but not gc'd + pages needed for gc marking
131072 maximum pages
Value = NIL
(2) -> )lisp (si::allocate-growth 'cons 1 10 50 10)
Value = (0 0 0 0)
(2) -> )lisp (room)
82872/200000 71.6% 143CONS RATIO COMPLEX STRUCTURE
73/200 42.1% FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABLE
NIL
224/500 97.3% SYMBOL STREAM
1/8 23.1% PACKAGE
5114/5114 0.3% 27 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSURE
FAT-STRING
125/500 69.3% STRING
100/100 12.3% 2 CFUN BIGNUM LONG-FLOAT
34/89 99.4% SFUN GFUN CFDATA SPICE NIL
4293/5347 2 contiguous (234 blocks)
2000 hole
15931 30.3% 59 relocatable
88543 pages for cells
110767 total pages
0 pages available
20305 pages in heap but not gc'd + pages needed for gc marking
131072 maximum pages
Value = NIL
(2) -> psolve(amat,9)
>> System error:
The storage for CONS is exhausted.
Currently, 82872 pages are allocated.
Use ALLOCATE to expand the space.
protected-symbol-warn called with (NIL)
(2) -> )lisp (setq *ignore-maximum-pages* t)
Value = T
(2) -> )lisp (si::allocate-contiguous-pages 10000 t)
>> System error:
Can't allocate 10000 pages for contiguous blocks.
protected-symbol-warn called with (NIL)
(2) -> )lisp (room)
82872/200000 0.8% 185CONS RATIO COMPLEX STRUCTURE
73/200 42.1% FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABL
NIL
224/500 97.3% SYMBOL STREAM
1/8 23.1% PACKAGE
5114/5114 0.3% 50 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSU
FAT-STRING
125/500 69.3% STRING
100/100 12.3% 2 CFUN BIGNUM LONG-FLOAT
34/89 99.4% SFUN GFUN CFDATA SPICE NIL
4293/10000 3 contiguous (234 blocks)
2000 hole
15931 0.3% 66 relocatable
88543 pages for cells
110767 total pages
0 pages available
20305 pages in heap but not gc'd + pages needed for gc marking
131072 maximum pages
Value = NIL
(2) -> psolve(amat,9)
>> System error:
The storage for CONS is exhausted.
Currently, 82872 pages are allocated.
Use ALLOCATE to expand the space.
protected-symbol-warn called with (NIL)
-------
Waldek Hebisch wrote:
> William Sit wrote:
> > >> System error:
> > The storage for CONS is exhausted.
> > Currently, 82689 pages are allocated.
> > Use ALLOCATE to expand the space.
> >
> > Can any one tell me how to increase the space? Exactly how
> > big is one page? I have 2GB RAM. Is it possible to allocate
> > the max to Axiom (under Windows XP)?
> >
>
> Have you tried to follow the advice:
>
> )lisp (allocate 'cons 200000 t)
>
> (Or some bigger number instead of 200000). Using gcl 2.6.7 I can
> maximally give 110000 (120000 is refused, few numbers between crashed
> gcl). Using gcl 2.6.8 I can give bigger values. Typically page
> means 4 kilobytes, that would agree with process size (empty Axiom
> about 80 Mb, around 900 Mb after allocating 200000 pages).
\start
Date: Sun, 4 Feb 2007 07:04:40 -0600
From: Tim Daly
To: list
Subject: Can you depend on it?
It's 5 a.m. on a sunday morning and I can't sleep because I'm
suffering from flaming asshole syndrome. The person suffering from
this disease feels they know what they are talking about and needs to
enlighten the rest of the world. Today I've got it bad.
I've been programming for nearly 36 years. I'm obsessive about it. I'm
writing a program for work that translates bit streams into mathematics
(in lisp). And for a hobby, I write Axiom programs that translate
mathematics into bit streams (in lisp). When I leave work (whatever
that means, since I work from home and have no fixed hours) I swap
machines and work on Axiom. When I'm not programming, I'm reading
about programming. Of course, I don't read programs, which in some
sense makes me illiterate in my own field. But I do write them. And I
do think about how and why I write them. And how to do it right.
Especially when it concerns Axiom.
In the last 6 years I've given a lot of thought to Axiom. Where can it
go? What can it do? Will it survive? Is it worth keeping? Can people
depend on it?
Ah, that's the question for today...."Can people depend on it?".
And if they can't know the results are correct, what's the point?
I'm re-reading the Mythical Man-Month, which I do every couple years.
And I've recently read "Dreaming in Code", a book about constructing
Chandler, an open-source Personal Information Manager. I watched a
video of destructive testing of the new Boeing aircraft wing. And I'm
remembering Bill Perzley, a guy I used to work for who knew what it
meant to write quality software.
I'll take each of these unrelated components and try to tie them
together.
If you haven't read the Mythical Man-Month I cannot recommend it
enough. It brings up so many good points, like the tarpit problem,
that you need to be able to recognize. Among the many points he makes,
one key "take-away" lesson stands out for me. "Nobody knows how to
schedule software". NOBODY. Even Knuth admits it. So next time your
boss asks you for a schedule don't give him one. Because you don't
know. You can't even guess. Another take-away lesson is that
programming is a lot more than writing code. And that's what concerns
us here. More about this later.
The "Dreaming in Code" book is about a paid project pretending to be
an open source project. It is never going to complete. And it will
fail to do anything worth doing. And no-one can learn from or build
upon the results, good or bad. It's another long, drawn out software
disaster. I've been there and I've done that. I've written whole
shelves worth of software. Some of it died because the robots that it
drove no longer exist. Some of it died because the company no longer
exists. Some of it died because .... well, because it was crap code,
which nobody but me understood and nobody could maintain. More about
this later.
Which brings me to my third reference point, the destructive testing
of Boeing's new aircraft wing. The video is on youtube and it's really
impressive to watch. The engineering team, dozens of people, is
standing around watching the bending of the wings of a brand new
Boeing aircraft until they snap. The design spec calls for surviving
150 percent of the design load. Both wings finally broke, exactly in
the wing location expected with exactly the kind of failure they
expected.... at 154% of design load. The engineering team went wild
with joy. Except for one guy. He was clearly annoyed and when asked
why he said that they were wrong by about 2.7 percent. (That's the
kind of engineer I want designing airplanes I fly.) Think about that
test. They busted up a perfectly good, multimillion dollar airplane to
test it. And they knew the answer to the test before they ran it. You
could look up the analysis, read the documentation and rely on the
answer before they ran the test.
Which brings me to my last reference point, Bill Perzley. When I first
started working in robotics I worked on a 3 man research team. Bill
was an old man, in his mid 50s (:-) ) and was the research lead. We
had a robot that could move 200kg at several hundred inches per second
and stop within 1 encoder bit of the target location repeatably. This
was a very big, very fast, and when you made a programming mistake, a
very dangerous machine. The robot had 6 different joints and 16
kilobytes of plated-wire memory. That's 131072 bits.
We had to teach the robot how to weld the fender of a car using a 30kg
spot welding gun while the fender was stationary. Then we had to
convert the stationary points into moving points so the robot would
weld the fender as it slid by on the assembly line. During our initial
testing a single bit value caused the robot to reach upward while the
weld gun was inside the fender. The robot lifted the weld gun, the
fender, the iron trolley, and 6 meters of steel I-beam up to the
ceiling before we could even think to hit the emergency stop button.
Fast, obedient, and dangerous.
So, Bill spends 4 MONTHS in his office smoking cigars like they were
free, banging away on a 4 function hand calculator. After 4 months he
comes out with a huge pile of A4 paper covered in zeros and ones,
131072 of them to be exact. He hands them to me, along with a pile of
mathematics. He asked me to check it over. And when I'm done to use our
memory store interface (a set of switches to choose a memory location,
set its value, and toggle a "write") to "program" the robot. He had
worked out the final location of every weld as it would appear while
the fender moved past the robot. If his calculations were correct the
robot should spot weld the fender in 24 places in real time
coordinated with the varying speed of the cart along the I-beam.
He had me "program" all 131072 bits into the robot so we could run
this test case. He wanted to see the exact results of his test and the
only way to do that was to stick his head into the wheel well of the
fender, inches from the robot and WELL within the robot's
reach. Needless to say, I was a bit nervous as a single bit mistake in
keying in the "program" could kill Bill before anybody could react.
Being the engineer that he was he stuck his head in the wheel well and
told me to start the robot. I argued with him....
ME: Bill, if this is wrong it could kill you.
BILL: It's right
ME: Bill, how do you know you didn't make a mistake?"
BILL: I checked it.
ME: Suppose the math is wrong?
BILL: Did you check it?
ME: Yes.
ME: Suppose I made a mistake keying in the program.
BILL: Did you check it?
ME: Several times.
BILL: Good. Then it works. Start the robot.
I watched the robot swing a weld gun within inches of his cigar all
along the 6 meters. And it worked, just exactly as Bill said it would.
And he KNEW it would work. Why? Because everything he did was
absolutely the best he could make it. This test, like the Boeing wing
test, was a foregone conclusion. He knew the answer before he ever
gave me the program. And I understood everything he did because he
wrote it all down in detail. You could bet your life on the result.
Now, what's this all got to do with Axiom?
Ah, that's the question for today...."Can people depend on it?".
And if they can't know the results are correct, what's the point?
I believe that Axiom could be the foundation for the next few hundred
years of computational mathematics. Oh, not the program we have
now. But the one it could evolve into if we do it right. Axiom is the
only program I've ever worked on that has that potential. The
mathematics doesn't change and, if correctly implemented, Axiom should
always give you an answer you can depend on. In fact, you should be
able to look at the final result of an Axiom computation and KNOW it
is right. And after that time, you and everyone else can depend on it.
Like an aircraft wing, only better because this is mathematics.
But I also find it frustrating because I don't see any Bill Perzley's
in the game. Bill not only learned the mathematics (we both took the
same course from Lou Paul), he understood it. He "programmed" it (we
didn't have anything but calculators and switches for programming but
it was still programming). He wrote it up so *I* could understand it.
And when he wrote programs they worked and *I* could check them. You
could bet your life on his work. And Bill often did.
Is this the level of quality we see in Axiom? Nope. Is this the level
of quality we can achieve? Yes. So, why don't we achieve it? Why don't
we write Axiom software as if our life depended on it? Why are we
still writing software like the Chandler project? Why can't we say
that this WILL work and it WILL give you the correct answer? What does
it take to get Perzley kind of quality?
After much thought I believe that we need to deeply improve the way
Axiom is written. Consider the latest dust-up that just flew by on the
mailing list (this isn't intended to cast blame, just to illustrate).
The issue is an apparent bug that was in the original Axiom
code. Apparently the computation of:
f:=taylor(1-x^2)
sin asin f
gave a wrong answer. A "fix" was applied that gives the answer:
1 - x^2 + O(x^11)
This was considered wrong and a new "fix" was applied giving the
answer:
1 - 1/4 x^4 - 1/16 x^6 - 7/768 x^8 - 5/3072 x^10 + O(x^11)
Lets apply Bill Perzley's eyes to this bug. I don't know if the
original Axiom answer was correct, the first "fix" was correct, or the
latest "fix" was correct. That's a problem. And it's a very deep
problem. Much deeper than this one bug. Bill's approach to this would
be to start at the bottom, namely subtraction in (1-x^2) and work his
way up, understanding all he could about each piece. At the end of
several months he's announce the fix. And I'd be willing to bet my
life he was right. Because he understood the problem, he understood
the answer, and he documented it so *I* could understand it.
How hard is this? Really, really hard. Because almost nobody knows
about subtraction in Axiom. Nonsense? Well subtraction is a very
widely implemented operator in many domains such as quaternions. It
occurs everywhere. Is the definition right? Does it work everywhere?
Does axiom implement subtraction properly for all domains? Once we
feel confident of that we can look at the "1" portion of the initial
expression. What does "1" mean in Axiom? Does it properly implement
the concept of "1" in mathematics? Can we depend on it?
So that's one of the key questions. "Can we depend on it?". We may be
a domain experts in robotics and implement DHMatrices in Axiom. But did
we write it up in depth so the next person can understand it?
By the time we've reached the level of documentation of things like
UnivariateTaylorSeries(Expression Integer,x,0)
we, and everyone who reads our documentation, should be able to say
with life-depending certainty that our answer is correct. Someone 30
years from now should be able to read what we wrote and be as certain
as we are that our answer is correct.
Because we're doing mathematics.
Because we're doing it for people to understand.
Because Axiom's life depends on it.
\start
Date: 04 Feb 2007 14:43:26 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: Can you depend on it?
I agree with many things you write, save two:
1) I think that it is not worth dying for some robot or mathematics or
anything. And it is certainly not the case that you can rely ("depend") on
anything. I'd say, that both Bill and Boing team were just lucky.
Important note: I do believe that various efforts and tools can improve on
the likelihood of success, literate programming, unit testing are certainly
two of them (the latter still missing in Axiom, because nobody finds the
time to make AldorUnit work with libaxiom. Should be quite trivial, though).
But it won't help you if you "died", even if the probability of dying was
very very very low.
2) The history
> f:=taylor(1-x^2)
> sin asin f
>
> gave a wrong answer. A "fix" was applied that gives the answer:
>
> 1 - x^2 + O(x^11)
>
> This was considered wrong and a new "fix" was applied giving the
> answer:
>
> 1 - 1/4 x^4 - 1/16 x^6 - 7/768 x^8 - 5/3072 x^10 + O(x^11)
does not seem entirely correct to me. Since I believe that you have some
versions of axiom around, could you please double check?
In any case, Ralf Hemmecke has (in the framework of our species project) a well
documented and unit-tested powerseries implementation, albeit only a partial
implementation, currently. Looking at the code of Axiom, I'm quite convinced
that *all* of it should go away. It can be done much better, if you look at
Joris van der Hoeven's and Dominik Gruntz papers.
(On Computing Limits in a Symbolic Manipulation System; Dominik Gruntz. ETH
Diss 11432, 1996. http://www.gruntz.ch/publications2.html)
By the way, I think that most code in axiom is crap. It is a mere coincidence
that it works roughly. If you want to see a well engineered system, look at the
MuPAD sources. (I'm not saying that it couldn't be done better. But it's quite
incredible how well it works. It's a pity that MuPAD is non-free now.)
Martin
PS: does anybody happen to know how many initial values one needs to single out
a specific Taylor series solution of an algebraic equation? To get a feel for
the problem:
There need not be a Taylor solution at all:
f(x)^2-x=0
There can be several branches with equal constant term:
map(e+->series(e, x=0), zerosOf((x^2-1)*z^2-2*(x^4-1)*z+(x^2-1),z))
+-+ +-+
+-+ 2 \|2 3 4 +-+ 2 \|2 3 4
(160) [1 - \|2 x + x - ---- x + O(x ),1 + \|2 x + x + ---- x + O(x )]
4 4
I'd guess that the first d terms are enough, when the equation has degree d in
z, but I don't know and in general less should be sufficient.
Some problem for ADE's, i.e., equations of the form
p(1, z(x), z'(x), z''(x), ...) = 0, p polynomial with coefficients in K[x]?
\start
Date: Sun, 4 Feb 2007 06:28:49 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Re: Can you depend on it?
> Ah, that's the question for today...."Can people depend on it?".
>
> And if they can't know the results are correct, what's the point?
That combination of questions might be the most common objection I have
heard to using CAS software in science and mathematical research. One
I happen to agree with. Oh, there are others, such as the tendency of
lazy humans to substitute computer software for understanding, and that
has its valid points, but the most serious one I think is being able to
know the results are correct.
> I believe that Axiom could be the foundation for the next few hundred
> years of computational mathematics. Oh, not the program we have
> now. But the one it could evolve into if we do it right. Axiom is the
> only program I've ever worked on that has that potential. The
> mathematics doesn't change and, if correctly implemented, Axiom
> should always give you an answer you can depend on. In fact, you
> should be able to look at the final result of an Axiom computation
> and KNOW it is right. And after that time, you and everyone else can
> depend on it. Like an aircraft wing, only better because this is
> mathematics.
This is why I think it is important to pursue proof checkers (things
like Isabelle, HOL, COQ, ACL2, etc.) as a starting point, not as
something to tack on later. KNOWING a result is correct when a
computer produces it is very very complex. It is unambiguous when a
wing breaks, and fairly easy to measure (given the right equipment).
Predicting it is fairly hard, but doable. Ditto for the robot - if
something goes wrong, lots of equipment starts flying that shouldn't be
moving. Or, in the less spectacular case, the wrong thing gets welded.
A computer has many subtle points of possible failure. Is it a weird
CPU bug, a mishandling of information in some subtle, unexpected way, a
1/1,000,000,000 failure condition of the operating system (think the
blackout that hit most of the northeastern US a while back - they
traced that back to a software error condition with a very small
window: http://www.securityfocus.com/news/8412) If the systems running
such a major portion of the national energy grid can't be completely
trusted, why should anyone trust CAS software?
> But I also find it frustrating because I don't see any Bill Perzley's
> in the game. Bill not only learned the mathematics (we both took the
> same course from Lou Paul), he understood it. He "programmed" it (we
> didn't have anything but calculators and switches for programming but
> it was still programming). He wrote it up so *I* could understand it.
> And when he wrote programs they worked and *I* could check them. You
> could bet your life on his work. And Bill often did.
In this instance, it sounds like both the hardware and software were
special purpose, very well engineered, and he had a fair amount of
time/money to commit to the project. While authors of CAS systems
might be able to make sure the software they write is solid (although
that goal still seems a ways off) they must rely on both the operating
environment and the hardware underneath it to work correctly. Neither
of those components is under the control of the author, since the
software will be installed in as many environments as it can be made to
run. It will work most of the time, but who knows when some subtle
difference will trigger a northeast blackout in the results? How can
it be prevented?
> Is this the level of quality we see in Axiom? Nope. Is this the level
> of quality we can achieve? Yes. So, why don't we achieve it? Why
> don't we write Axiom software as if our life depended on it? Why are
> we still writing software like the Chandler project? Why can't we say
> that this WILL work and it WILL give you the correct answer?
Because, among other reasons, we don't have the tools that will let us
make that assertion and back it up. I doubt Perzley would have been
willing to do what he did if the robot was being operated by Windows XP
and was just taking instructions he had fed it - I know I sure wouldn't
- because every element of the system which MIGHT cause failure isn't
guaranteed.
> What does it take to get Perzley kind of quality?
This is the type of problem I would like to do research in, someday. I
have a ways to go first (as you mentioned earlier, you must know both
the mathematics and how to program, and I am working on increasing my
basic knowledge before making another run at Axiom level problems) but
the question is a worthy one.
Science magazine had a rather interesting article (I suppose it's not
the full story since it's a specialty topic in a general magazine, but
I found it good food for thought) about the difficulties that have
begun to appear in the form of proofs that cannot be checked by human
reviewers:
http://www.sciencemag.org/cgi/content/summary/307/5714/1402a In that
article, the point was made that there are two aspects to proof
checking:
1. Knowing it is correct
2. Understanding why it is correct (human understanding)
If you only use human beings to check proofs, these two components are
not separable. A human being must understand the proof in order to
know if it is correct. An automated proof checker, correctly done,
should be able to mechanically verify that the proof is sound. In
theory, a human being dogged enough to follow the computer through the
steps should arrive at the exact same conclusion, although the
experience is unlikely to build much insight into how to make "good"
proofs. What needs to be human understandable is a) the proof checking
system and b) the logic converting human CAS style inputs into proof
statements. Once the correct proof statements are generated, the proof
checker will take it from there.
I think the distinction is important for what we are trying to do here,
because for a CAS it is less important to produce elegant/beautiful
proofs and more important to know the result is correct. Proof
software may never generate the "optimal" proof for a given result, but
so long as it generates a CORRECT proof that can be evaluated in
reasonable time it has done what is needed for us to rely on it. In
our case the proofs are a means to an end - if people can rely on
Axiom's results as having come from components that have proof backing,
and can at need (say for a particularly critical result for a paper)
have Axiom generate the full proof validation for a result to be
verified by any of several systems, I think we will have achieved a
level of confidence that will permit more general use of the systems.
We will be able to say "yes it is correct, and here's the proof, to be
checked however you care to check it."
Now the details of that system, and whether it is even possible, are
the subject of many years of fascinating research and may even require
defining as unambiguously as possible what it means to prove something.
But I think this is going to be essential for the long term viability
of any such system - it must be "so good" that using anything else
becomes a liability.
CAS systems are currently used in science - Mathematica + Feyncalc was
a common tool at my undergrad physics department - and those systems
have become usable through a sort of prolonged process of evaluation by
many scientists. However, if asked to show proof that a feyncalc
derived result was correct, pencil and paper work would be needed to
verify the system was correct. Making a system that WOULDN'T need such
work is going to be a hard sell, and some good answers to the question
of why any new system is any better than Mathematica + Feyncalc would
be needed.
But to make that system, one must know not just programming and
mathematics but proof logic as well (plus high energy physics, for this
problem domain), and how to make all of them interact. Which reminds
me, I have some reading to do...
\start
Date: 04 Feb 2007 19:13:49 +0100
From: Martin Rubey
To: Bill Page,
Subject: MathAction down - mirror not up to date?
Dear Bill,
unfortunately, it seems that mathaction is currently down.
furthermore, it seems that the mirror at risc is not really up to date. By the
way, if I make changes at the mirror at risc, I guess they are not applied to
the main site, are they? I.e., after one update, they get lost?
\start
Date: Sun, 4 Feb 2007 14:17:15 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: MathAction down - mirror not up to date?
Martin,
On February 4, 2007 1:14 PM you wrote:
>
> unfortunately, it seems that mathaction is currently down.
I am looking at the problem. Something has gone with the configuration
of Apache on the axiom-developer.org server however I have not made
any recent changes. The backend Zope web server however is still working.
So in the mean time you can bypass Apache by accessing the Axiom wiki
site from the following url:
http://axiom-developer.org:8080/mathaction/FrontPage
I will let you know when the problem with Apache is fixed.
>
> furthermore, it seems that the mirror at risc is not really
> up to date. By the way, if I make changes at the mirror at risc,
> I guess they are not applied to the main site, are they? I.e.,
> after one update, they get lost?
>
It is true that the risc mirror site is not up to date. I have
not gotten around to update for over a month. Changes you make
at the risc site are not automatically applied at the main site
but there is a simple process to transfer pages from one site
to another.
\start
Date: Sun, 4 Feb 2007 14:32:27 -0500
From: Bill Page
To: Martin Rubey
Subject: re: MathAction down - mirror not up to date?
Ok, problem solved.
http://wiki.axiom-developer.org
and
http://portal.axiom-developer.org
are working again. The problem was that one of the user directories
on axiom-developer.org was deleted without removing the entries
for that user's web site from the apache configuration files. Apache
refused to restart.
Tim has been making an effort to clean up the file space on
axiom-developer.org in order to reduce the monthly cost of operating
this server (Over $250/month which Tim is contributing from his own
pocket! I think we need to discuss how to share the cost of this
server.) On his request I recently cleaned up the mathaction development
directories but I am quite sure that I did not delete any /home user
directories.
Anyway, the Apache configuration file has now been updated and
everything appears to be fine again.
I will now put some priority on updating the risc mirror site in
case this or something more serious happens again.
Regards,
Bill Page.
On February 4, 2007 2:17 PM I wrote:
>
> On February 4, 2007 1:14 PM Martin wrote:
>
> >
> > unfortunately, it seems that mathaction is currently down.
>
> I am looking at the problem. Something has gone with the configuration
> of Apache on the axiom-developer.org server however I have not made
> any recent changes. The backend Zope web server however is still
> working.
>
> So in the mean time you can bypass Apache by accessing the Axiom wiki
> site from the following url:
>
> http://axiom-developer.org:8080/mathaction/FrontPage
>
> I will let you know when the problem with Apache is fixed.
\start
Date: 04 Feb 2007 20:54:16 +0100
From: Martin Rubey
To: Bill Page
Subject: re: MathAction down - mirror not up to date? / money
Bill Page writes:
> Ok, problem solved.
>
> http://wiki.axiom-developer.org
>
> and
>
> http://portal.axiom-developer.org
>
> are working again.
Great! Thank you!
> Tim has been making an effort to clean up the file space on
> axiom-developer.org in order to reduce the monthly cost of operating this
> server (Over $250/month which Tim is contributing from his own pocket! I
> think we need to discuss how to share the cost of this server.)
Definitively. I'll keep it in mind.
\start
Date: 04 Feb 2007 21:28:08 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: messages in wh-sandbox
Dear Waldek,
is there a way to turn of messages like
BasicLookup coerce: ((OutputForm) $)
Lookup coerce ((OutputForm) $)
Lookup coerce ((OutputForm) $)
BasicLookup coerce: ((OutputForm) $)
Lookup coerce ((OutputForm) $)
in wh-sandbox?
\start
Date: Sun, 04 Feb 2007 16:03:17 -0500
From: Bill Page
To: list
Subject: building wh-sandbox on SuSE 10.2
Cc: Bill Page
Waldek, et al.
I just tried to build wh-sandbox on a SuSE 10.2 linux system. Everything se=
ems
to compile normally up to the point of building hyperdoc and ends with the =
error
message:
No rule to make target `all-ax'.
Does anyone have an idea about what might cause this error? Suggestions?
What reports do we have of successful builds of wh-sandbox? What
platforms?
Regards,
Bill Page.
wspage@suse-linux:~/axiom-sandbox> tail -100 build.log
process3d.c:857: warning: =E2=80=98linearMouseXY.x=E2=80=99 may be used uni=
nitialized in
this function
process3d.c:857: warning: =E2=80=98linearMouseXY.y=E2=80=99 may be used uni=
nitialized in
this function
process3d.c:857: warning: =E2=80=98mouseXY.x=E2=80=99 may be used uninitial=
ized in this
function
process3d.c:857: warning: =E2=80=98mouseXY.y=E2=80=99 may be used uninitial=
ized in this
function
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=project3d.c
./../../../wh-sandbox/src/graph/view3D/project3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o project3=
d.o
project3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=quitbut3d.c
./../../../wh-sandbox/src/graph/view3D/quitbut3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o quitbut3=
d.o
quitbut3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=quit3d.c
./../../../wh-sandbox/src/graph/view3D/quit3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o quit3d.o
quit3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=save3d.c
./../../../wh-sandbox/src/graph/view3D/save3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o save3d.o
save3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=savebut3d.c
./../../../wh-sandbox/src/graph/view3D/savebut3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o savebut3=
d.o
savebut3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=smoothShade3d.c
./../../../wh-sandbox/src/graph/view3D/smoothShade3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o
smoothShade3d.o smoothShade3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=spadAction3d.c
./../../../wh-sandbox/src/graph/view3D/spadAction3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o
spadAction3d.o spadAction3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=stuff3d.c
./../../../wh-sandbox/src/graph/view3D/stuff3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o stuff3d.=
o
stuff3d.c
stuff3d.c: In function =E2=80=98norm_dist=E2=80=99:
stuff3d.c:128: warning: =E2=80=98pert.z=E2=80=99 is used uninitialized in t=
his function
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=surface3d.c
./../../../wh-sandbox/src/graph/view3D/surface3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o surface3=
d.o
surface3d.c
surface3d.c: In function =E2=80=98drawRenderedPolygon=E2=80=99:
surface3d.c:394: warning: =E2=80=98col_rgb.r=E2=80=99 may be used uninitial=
ized in this
function
surface3d.c:394: warning: =E2=80=98col_rgb.g=E2=80=99 may be used uninitial=
ized in this
function
surface3d.c:394: warning: =E2=80=98col_rgb.b=E2=80=99 may be used uninitial=
ized in this
function
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=transform3d.c
./../../../wh-sandbox/src/graph/view3D/transform3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o
transform3d.o transform3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=viewport3d.c
./../../../wh-sandbox/src/graph/view3D/viewport3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o viewport=
3d.o
viewport3d.c
/home/wspage/wh-sandbox/src/graph/view3D/static.h:42: warning: =E2=80=98lab=
els=E2=80=99
defined but not used
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=volume3d.c
./../../../wh-sandbox/src/graph/view3D/volume3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o volume3d=
.o
volume3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=write3d.c
./../../../wh-sandbox/src/graph/view3D/write3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o write3d.=
o
write3d.c
gcc ./buttons3d.o ./closeView3d.o ./component3d.o ./control3d.o ./illuminat=
e3d.o
./lightbut3d.o ./lighting3d.o ./main3d.o ./mesh3d.o ./msort3d.o ./pot3d.o
./process3d.o ./project3d.o ./quitbut3d.o ./quit3d.o ./save3d.o ./savebut3d=
.o
./smoothShade3d.o ./spadAction3d.o ./stuff3d.o ./surface3d.o ./transform3d.=
o
./viewport3d.o ./volume3d.o ./write3d.o ../Gdraws/Gfun.o -o
/home/wspage/axiom-sandbox/target/i686-suse-linux/lib/view3D \
-L/home/wspage/axiom-sandbox/src/graph/view3D/../../.././sr=
c/lib
-lspad -lXpm -lSM -lICE -lX11 -lm
./Gdraws/Gfun.o: In function `PSInit':
/home/wspage/axiom-sandbox/src/graph/Gdraws/Gfun.c:811: warning: the use of
`tmpnam' is dangerous, better use `mkstemp'
./Gdraws/Gfun.o: In function `PSGlobalInit':
/home/wspage/axiom-sandbox/src/graph/Gdraws/Gfun.c:686: warning: the use of
`tempnam' is dangerous, better use `mkstemp'
rm -f stamp
echo timestamp > stamp
finished ../../../../wh-sandbox/src/graph/view3D
make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/graph/view3D'
cd viewAlone && SPAD=/home/wspage/axiom-sandbox/target/i686-suse-linux SR=
C=/src
INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sandbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
make[3]: Entering directory `/home/wspage/axiom-sandbox/src/graph/viewAlone=
'
/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././build/scripts/doc=
ument
--tangle --output=viewAlone.c
./../../../wh-sandbox/src/graph/viewAlone/viewAlone.c.pamphlet
gcc -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I../../../../wh-sandbox/src/graph/viewAlone
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include -I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././config -c -o
viewAlone.o viewAlone.c
/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././build/scripts/doc=
ument
--tangle --output=spoonComp.c
./../../../wh-sandbox/src/graph/viewAlone/spoonComp.c.pamphlet
gcc -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I../../../../wh-sandbox/src/graph/viewAlone
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include -I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././config -c -o
spoonComp.o spoonComp.c
/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././build/scripts/doc=
ument
--tangle --output=spoon2D.c
./../../../wh-sandbox/src/graph/viewAlone/spoon2D.c.pamphlet
gcc -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I../../../../wh-sandbox/src/graph/viewAlone
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include -I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././config -c -o
spoon2D.o spoon2D.c
gcc viewAlone.o spoonComp.o spoon2D.o -o
/home/wspage/axiom-sandbox/target/i686-suse-linux/bin/viewAlone
-L/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././src/lib -lspad =
\
-lXpm -lSM -lICE -lX11
rm -f stamp
echo timestamp > stamp
finished .
make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/graph/viewAlone'
/home/wspage/axiom-sandbox/src/graph/../.././build/scripts/document
--tangle=`basename parabola/data` --output=parabola/data
./../../wh-sandbox/src/graph/fileformats.pamphlet
/home/wspage/axiom-sandbox/src/graph/../.././build/scripts/document
--tangle=`basename parabola/graph0` --output=parabola/graph0
./../../wh-sandbox/src/graph/fileformats.pamphlet
echo timestamp > stamp
24 finished
make[2]: Leaving directory `/home/wspage/axiom-sandbox/src/graph'
./../wh-sandbox/config/mkinstalldirs
/home/wspage/axiom-sandbox/target/i686-suse-linux/bin
./../wh-sandbox/config/mkinstalldirs
/home/wspage/axiom-sandbox/target/i686-suse-linux/share
cd hyper && SPAD=/home/wspage/axiom-sandbox/target/i686-suse-linux SRC==
/src
INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sandbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
make[2]: Entering directory `/home/wspage/axiom-sandbox/src/hyper'
failcmd='exit 1'; \
for f in $MAKEFLAGS; do \
case $f in \
*=* | --[!k]*) ;; \
*k*) failcmd='fail=yes';; \
esac; \
done; \
dot_seen=no; \
target=`echo all-recursive | sed s/-recursive//`; list=''; \
for subdir in $list; do \
echo "Making $target in $subdir"; \
if test "$subdir" = "."; then \
dot_seen=yes; \
local_target="$target-ax"; \
else \
local_target="$target"; \
fi; \
(cd $subdir && SPAD=/home/wspage/axiom-sandbox/target/i686-sus=
e-linux
SRC=/src INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sa=
ndbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make $local=
_target)
|| eval $failcmd; \
done; \
if test "$dot_seen" = "no"; then \
SPAD=/home/wspage/axiom-sandbox/target/i686-suse-linux SRC=/=
src
INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sandbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make "$targ=
et-ax"
|| exit 1; \
fi; test -z "$fail"
make[3]: Entering directory `/home/wspage/axiom-sandbox/src/hyper'
make[3]: *** No rule to make target `all-ax'. Stop.
make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
make[1]: *** [all-hyper] Error 2
make[1]: Leaving directory `/home/wspage/axiom-sandbox/src'
make: *** [all-src] Error 2
wspage@suse-linux:~/axiom-sandbox>
\start
Date: 04 Feb 2007 22:18:23 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: building wh-sandbox on SuSE 10.2
Bill Page writes:
> What reports do we have of successful builds of wh-sandbox? What
> platforms?
I just re-built wh-sandbox, although not from scratch but only after a svn up,
on kubuntu dapper without a problem.
\start
Date: Sun, 4 Feb 2007 22:29:48 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on SuSE 10.2
> Waldek, et al.
>
> I just tried to build wh-sandbox on a SuSE 10.2 linux system. Everything seems
> to compile normally up to the point of building hyperdoc and ends with the error
> message:
>
> No rule to make target `all-ax'.
>
> Does anyone have an idea about what might cause this error? Suggestions?
>
> What reports do we have of successful builds of wh-sandbox? What
> platforms?
>
> Regards,
> Bill Page.
>
> wspage@suse-linux:~/axiom-sandbox> tail -100 build.log
<snip>
> make[3]: Entering directory `/home/wspage/axiom-sandbox/src/hyper'
> make[3]: *** No rule to make target `all-ax'. Stop.
> make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
> make[1]: *** [all-hyper] Error 2
> make[1]: Leaving directory `/home/wspage/axiom-sandbox/src'
> make: *** [all-src] Error 2
> wspage@suse-linux:~/axiom-sandbox>
>
Thanks for the report. I build regularly on prerelase Debian and on
Mandrake 9.2. Your log looks different than my build log -- I will
investigate what is the reason for the difference.
\start
Date: Sun, 4 Feb 2007 22:39:28 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: messages in wh-sandbox
Martin Rubey wrote:
> is there a way to turn of messages like
>
> BasicLookup coerce: ((OutputForm) $)
> Lookup coerce ((OutputForm) $)
> Lookup coerce ((OutputForm) $)
> BasicLookup coerce: ((OutputForm) $)
> Lookup coerce ((OutputForm) $)
>
> in wh-sandbox?
>
When do you see them? They look like debugging messages I use, but
they should not get into public version. ATM I do not not them,
and quick search did not found them in current svn.
Later you wrote:
> I just re-built wh-sandbox, although not from scratch but only after a svn up,
> on kubuntu dapper without a problem.
Do the messages appear in the freshly re-built version?
\start
Date: 04 Feb 2007 22:44:41 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: messages in wh-sandbox
Waldek Hebisch writes:
> Martin Rubey wrote:
> > is there a way to turn of messages like
> >
> > BasicLookup coerce: ((OutputForm) $)
> > Lookup coerce ((OutputForm) $)
> > Lookup coerce ((OutputForm) $)
> > BasicLookup coerce: ((OutputForm) $)
> > Lookup coerce ((OutputForm) $)
> >
> > in wh-sandbox?
> >
>
> When do you see them? They look like debugging messages I use, but
> they should not get into public version. ATM I do not not them,
> and quick search did not found them in current svn.
>
> Later you wrote:
> > I just re-built wh-sandbox, although not from scratch but only after a svn up,
> > on kubuntu dapper without a problem.
>
> Do the messages appear in the freshly re-built version?
yes. Unfortunately, I have thrown the log away. Ah, I see, I just ran a svn
diff and some files are modified. Very likely, this is because of an
experimental patch of Peter Broadbery to enable aldor extend. Sorry about
taking away your time...
\start
Date: Sun, 4 Feb 2007 20:35:29 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: [Axiom-math] [ANN] New version of Guessing Package on MathAction
Martin,
On February 4, 2007 6:59 PM you wrote:
>
> It has now become obvious that the code in
>
> > http://wiki.axiom-developer.org/MantepseSpad2
>
> did not compile properly: guessExpRat(q) does not work, look for
>
>
> For Sequence (5), we enter
>
> Would be great if you could fix that...
>
I am not sure if I can fix anything, but you are right that
MantepseSpad2 did not compile in the 1 minute CPU time limit
on MathAction. I increased the limit to 60 minutes - in fact
the compile took almost 12 minutes of CPU time! That is one
long hard program to compile!!!
Maybe it is alright now? It seems to have compiled. You have
to wait for about 15 minutes. The browser times out and does
not display the result but when you refresh the page after 15
minutes the compile is complete and the page looks ok.
Let me know if this works now. I will leave the limit at 60
minutes for now.
\start
Date: 05 Feb 2007 04:12:37 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: [Axiom-math] [ANN] New version of Guessing Package on MathAction
Dear Bill,
Bill Page writes:
> I am not sure if I can fix anything, but you are right that
> MantepseSpad2 did not compile in the 1 minute CPU time limit
> on MathAction. I increased the limit to 60 minutes - in fact
> the compile took almost 12 minutes of CPU time! That is one
> long hard program to compile!!!
Yes, it is quite big. Even though I factored out many many things already...
> Maybe it is alright now? It seems to have compiled.
Unfortunately, no. In fact, if you unfold the spad button, it says
>> System error:
Unexpected end of #<input stream "/var/zope/var/LatexWiki/GUESS.NRLIB/index.KAF">.
I have never seen such a message before... Well, I'm trying again and see
whether it's a one time only. However, I have to go to bed then, it's alreade
10 past 4...
Thanks for all your help!
Martin
PS: Neil Sloane will be looking at the program next week, and possibly include
it in SuperSeeker. That'd be nice!
\start
Date: 05 Feb 2007 04:55:06 +0100
From: Martin Rubey
To: Martin Rubey
Subject: Re: [Axiom-math] [ANN] New version of Guessing Package on MathAction
Martin Rubey writes:
> Dear Bill,
It's working now! Super! Good night!
\start
Date: Mon, 05 Feb 2007 23:38:19 -0500
From: Bill Page
To: list
Subject: wh-sandbox: error in hyperdoc - uncompress is obsolete
While testing Hyperdoc in the current version wh-sandbox on OpenSuSE 10.2 I
encountered the following problem while run some example graphics:
Hyperdoc processed crashed (window disappeared) and the following message
appeared in the Axiom console session:
(2) -> XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 40603 requests (40235 known processed) with 0 events remaining.
read_pixmap_file: unable to open
/home/wspage/axiom-sandbox/target/i686-suse-linux/share/viewports/AssortedGraphicsExamplePage6.VIEW/image.xpm
uncompress: No such file or directory
-------
My understanding is that 'uncompress' is an obselete name for 'gzip -d'. Is that
correct?
\start
Date: Mon, 05 Feb 2007 23:45:49 -0500
From: Bill Page
To: list
Subject: Re: building wh-sandbox on SuSE 10.2
Quoting Bill Page:
> ...
> I just tried to build wh-sandbox on a SuSE 10.2 linux system.
> Everything seems to compile normally up to the point of building
> hyperdoc and ends with the error message:
>
> No rule to make target `all-ax'.
> ...
After investigating this a little more I found that the file
src/hyper/Makefile
in my out-of-source build directory was incomplete. It seemed
to contain only the standard header stanzas but none of the
contents of
src/hyper/Makefile.in
from the source directory.
I do not know the exact cause, however after re-running configure
in the build directory the problem was corrected and I was able to
complete the build by simply re-starting 'make'.
The only difference that I am aware of between the first time I
ran 'configure' and the second time was that previously I had
not yet installed 'latex'. I am not sure if this might have triggered
the problem.
In any case, I can now report a successful build on OpenSuSE 10.2.
\start
Date: 06 Feb 2007 04:59:03 -0600
From: Gabriel Dos Reis
To: Bill Page
Subject: re: building wh-sandbox on SuSE 10.2
Bill Page writes:
| Quoting Bill Page:
|
| > ...
| > I just tried to build wh-sandbox on a SuSE 10.2 linux
| > system. Everything seems to compile normally up to the point of
| > building
| > hyperdoc and ends with the error message:
| >
| > No rule to make target `all-ax'.
| > ...
|
| After investigating this a little more I found that the file
|
| src/hyper/Makefile
|
| in my out-of-source build directory was incomplete. It seemed
| to contain only the standard header stanzas but none of the
| contents of
|
| src/hyper/Makefile.in
|
| from the source directory.
|
| I do not know the exact cause, however after re-running configure
| in the build directory the problem was corrected and I was able to
| complete the build by simply re-starting 'make'.
|
| The only difference that I am aware of between the first time I
| ran 'configure' and the second time was that previously I had
| not yet installed 'latex'. I am not sure if this might have triggered
| the problem.
I don't know. But, it is curious. I've seen a similar behaviour in
build-improvement once, but it happened at the toplevel. At the time,
I found that it was because noweave/notangle was missing so the
build-setup.sh script overwrote complete information with partial
information.
\start
Date: Tue, 6 Feb 2007 14:20:37 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Algebra bootstrap
I would like to share with you recent progress I made. Namely, I was
able to bootstrap Axiom algebra using no cached Lisp (that means no
Lisp for algebra files, boot and interpreter are different story).
How doeas it work? I looked once again at 'Loading' messages appearing
in Axiom trace. I have noticed that only 263 different thing get
leaded. Of them there is 199 categories, 44 domains associated
with categories (those domains give default implementations for
some functions) and 20 core domains:
AssociationList Boolean Character DoubleFloat Fraction
IndexedList IndexedOneDimensionalArray IndexedString
IndexedVector Integer List NonNegativeInteger OutputForm
PositiveInteger PrimitiveArray Reference SingleInteger
String Symbol Vector
Main bootstrap problems are due to core domains: if we forget about
Reference the other are all mutually dependent. Also, they depend
on many categories and it turn many categories depend on core
domains.
AFAICS bootstrap layer used by Tim includes almast all core domains
and categories with associated domains. Once we have compiled
all categories and domains loaded by Axiom we can proceed essentially
in any order.
I spent some time trying to find pattern deciding wether a file
gets loaded during given compilation or not. There are obvious
reasons to load categories: Axiom implements Join as runtime
operation, so in order to compute Join it must first load all
categories involved in Join. Also, it seems that Axiom loads
categories of arguments of constructors. However, loading of
domains looked almost random. After some effort I have tracked
this to the optDeltaEntry in nruncomp.boot.pamphlet: appearently
this functions tries to avoid lookups in domain vectors and redirect
calls to final destination. To do this optDeltaEntry must have
domain vectors available, so it load corresponding domains.
After disabling optimisation done by optDeltaEntry _no_ domains
are loaded during compilarion.
So, it remains to bootstrap categories. There is still a little
cyclic dependencies between categories, due to constructor
arguments. But $bootStrapMode switch resolves this dependency,
and it is enough to topologically sort categories based on
ancestor fields.
The final process looks as follows. The compiler is modified to
have extra switch $bootstrapDomains, which if set to true disables
optimisation in optDeltaEntry. In the first pass I use topologically
sorted list of categories and compile in $bootStrapMode. In the
second pass I use $bootstrapDomains switch and compile categories
plus core domains. In the thired pass I recompile categories
and core domains in normal mode. Finally, I compile the rest
of algebra in alphabetical order (in fact, I let make choose the
oreder, but the list I give is sorted alphabetically, and make
processes it in order).
There is still problem of databases: the process I outlined above
uses pre-built databases. Most of the typechecking uses information
form databases, so in order to modify algebra one has to generate
databases first and only later can use bootstrap procedure. I made
some progress trying to bootstrap with empty databases. I am able
to compile categories and about 50 domains in $bootStrapMode starting
from empty databases, but the resulting databases still contain too
little (or possibly incorrect) information, so normal bootstrap using
such databases fails relatively early.
\start
Date: 06 Feb 2007 08:04:51 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Algebra bootstrap
I think we need to have a basic interpreter, and a basic compiler
in the sense that they are almost like the interpreter and compiler,
but they "know" only
* simple types: Boolean, Integer, Float
* constructed types: List(T), Vector(T)
* fundamental structure: Category
Form that, we must separate and rationalize the database construction.
We must also be able to process a file without first having to split
it into several chunks. We have been able to process SPAD files that
way; making )abbrev a no-op.
\start
Date: Tue, 6 Feb 2007 17:00:47 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: wh-sandbox: error in hyperdoc - uncompress is obsolete
> While testing Hyperdoc in the current version wh-sandbox on OpenSuSE 10.2 I
> encountered the following problem while run some example graphics:
>
> Hyperdoc processed crashed (window disappeared) and the following message
> appeared in the Axiom console session:
>
> (2) -> XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
> after 40603 requests (40235 known processed) with 0 events remaining.
> read_pixmap_file: unable to open
> /home/wspage/axiom-sandbox/target/i686-suse-linux/share/viewports/AssortedGraphicsExamplePage6.VIEW/image.xpm
> uncompress: No such file or directory
>
> -------
>
> My understanding is that 'uncompress' is an obselete name for 'gzip -d'. Is that
> correct?
>
Not exactly, 'uncompress' the program to decompress .Z (LZW compressed)
files. Later 'gzip' was created and to large degree reduced need to
use 'compress' and 'uncompress'. And yes, 'gzip -d' can do the job
of 'uncompress' (and more).
I have met similar (or maybe exactly this) problem. 'uncompress'
program is uses by Xpm library -- to see any images at all you
must have 'uncompress' program (shell script passing work to 'gzip -d'
may serve as a replacement). But on some machines there are problems
even if 'uncompress' is present. In fact on dual core Pentums running
Debian prerelease most of the time I get error trying to see images
(but sometimes images work). I have traced my problem to Xpm library
-- it looked that 'uncompress' was nicely decompressing images,
but for unknown reasons Xpm library decided that 'uncompress' was
not working and returned error indication. I am not sure where the
real error is: it may be bug in this version of Xpm library, it may
be that Hyperdoc is messing with process control in ways which
confilct with Xpm. All machines where I was able to reproduce the
problem run the same version of Debian on the same hardware, so it
looked likely that this is a bug in Debian provided Xpm library.
There is a workaroud: in wh-sandbox Hyperdoc will uncompressed files
if they are present (or 'gzip' compressed ones, but AFAIK 'gzip -d'
has the same problem as 'uncompress'). At least in my case reading
uncompressed images never failed. So you can try uncomressing
all .xpm.Z files (wastefull on space, but should work ...).
In the future we want to replace Xpm library by a different (portable)
image library, so the problem should automatically go away. If the
problem affects more poeple I will probably look again at it to
find quicker solutuion.
\start
Date: 06 Feb 2007 21:50:14 +0100
From: Francois Maltey
To: list
Subject: axiom in windows xp for an user who isn't root.
Hello,
I have installed axiom and msys as root in windows xp for some students.
It's all right !
But I don't want theses students are root in windows xp.
So I create an other login.
I change rights of the axiom directory and the msys directory.
Now they are read/write/and others for all users.
When I run axiom in this login I get a boot error.
Axiom is looking for a file in a very long path in msys
inside 8 or 10 sub-sub-directory. This file isn't in the msys directory.
This computer is at work and my mail at home... So I can't be more precise.
May you help me ?
\start
Date: Tue, 6 Feb 2007 17:35:53 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: axiom in windows xp for an user who isn't root.
On February 6, 2007 3:50 PM Francois Maltey wrote:
>
> I have installed axiom and msys as root in windows xp for
> some students. It's all right !
msys is not necessary to use Axiom on windows - only if you
need to build Axiom from source.
>
> But I don't want theses students are root in windows xp.
> So I create an other login.
>
How did you install Axiom in Windows? From the binary install
program or from source?
> I change rights of the axiom directory and the msys directory.
> Now they are read/write/and others for all users.
>
> When I run axiom in this login I get a boot error.
> Axiom is looking for a file in a very long path in msys
> inside 8 or 10 sub-sub-directory. This file isn't in the msys
> directory.
>
It sounds like the AXIOM environment variable is not set.
> This computer is at work and my mail at home... So I can't be
> more precise.
>
> May you help me ?
>
To check the AXIOM variable go to:
Start/ControlPanel/System/Advanced/EnvironmentVariables
and check that the 'System variables' table includes
Variable Name: AXIOM
Variable Value: c:/Program Files/axiom/mnt/windows
It is possible that Axiom was originally installed for a single
user only, in which case the AXIOM variable may only be defined
for that specific user in the 'Users varaibles for ...'.
\start
Date: Wed, 7 Feb 2007 00:32:55 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Algebra bootstrap
I have commited new algebra bootstrap to wh-sandbox. This code is
subject to change. I belive that the code I commited should work
well for the intended purpose (that is bootstraping Axiom),
however:
- I am still investigating bootstrap problems (especially database
bootstrap) and the whole process is likely to change
- I find the code ugly, partially due to tools used (make nad shell)
and consider moving it to Lisp
- the code uses hardcoded lists of files, we should generate them
automatically.
I have commited it so that:
- others can see details of bootstrap process
- I can kill Lisp embedded in algebra pamphlets
\start
Date: Wed, 7 Feb 2007 01:17:02 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Algebra bootstrap
>
> I think we need to have a basic interpreter, and a basic compiler
> in the sense that they are almost like the interpreter and compiler,
> but they "know" only
>
> * simple types: Boolean, Integer, Float
> * constructed types: List(T), Vector(T)
> * fundamental structure: Category
>
> Form that, we must separate and rationalize the database construction.
>
Current compiler (before algebra bootstrap) does not know about Integer.
And Integer depends on large part of algebra. So I would say that such
basic compiler while a noble goal would require substantial algebra
rewrite. Such rewrite in turn need something like Aldor post facto
extension.
As an excercise I tried to make a minimal algebra. I compiled
about 20 very simple domains and categories and generated corresponding
databses, but resulting interpreter was non-functional. More effort
would probably give functional system, but ATM I am not sure if such
system is useful for bootstrap.
> We must also be able to process a file without first having to split
> it into several chunks. We have been able to process SPAD files that
> way; making )abbrev a no-op.
>
In longer run sure. ATM I am using quite different method: I dumped
parse trees of the whole Axiom algebra into a file. So now I can load
the whole algebra just as a single S-expression. I am loading this
S-expression into sbcl running various analyses on it. The idea is to
write (in Lisp) a simple compiler capable of extracting type declarations
and generating from them Axiom databases. ATM I have a semi-reasonable
macro expander (there is one macro that the expander misess, but I
hope that it correctly expands all declarations that I need). I have
also a simple transformer that eliminates 'where' construct. Together
macro expander + 'where' transformer allow me to separate implementation
form interface (the assumption beeing that in databases we need only
information from interface).
Concerning abbrev declaration: I am not sure how to find out wether
something is a package or a domain without using information from
abbrevs.
\start
Date: 06 Feb 2007 19:19:57 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Algebra bootstrap
Waldek Hebisch writes:
| >
| > I think we need to have a basic interpreter, and a basic compiler
| > in the sense that they are almost like the interpreter and compiler,
| > but they "know" only
| >
| > * simple types: Boolean, Integer, Float
| > * constructed types: List(T), Vector(T)
| > * fundamental structure: Category
| >
| > Form that, we must separate and rationalize the database construction.
| >
|
| Current compiler (before algebra bootstrap) does not know about Integer.
I don't think so.
The internal AST that eventually reaches the type analyzer and the
semantic analyzer, starting from compTopLelve, already contain mention
of Integer (and the other basic types).
| And Integer depends on large part of algebra. So I would say that such
| basic compiler while a noble goal would require substantial algebra
| rewrite. Such rewrite in turn need something like Aldor post facto
| extension.
By "simple type", I don't expect the basic type to understand beyond
simple operations defined on their domains.
The glorious version of Integer is not needed wholesale when starting
the boostrap process. The glorification is a set that needs to come
after. Yes, post facto extensions are ways to achieve late
glorification -- and if you look at the practice, this is not fancy;
just think "type classes" (Haskell), which Axiom would have invented
two decades ago if it had post facto extensions.
| As an excercise I tried to make a minimal algebra. I compiled
| about 20 very simple domains and categories and generated corresponding
| databses, but resulting interpreter was non-functional. More effort
| would probably give functional system, but ATM I am not sure if such
| system is useful for bootstrap.
I don't think the interpreter is a good way tp arrive to the
bootstrap. We must be in "type checking" mode, not "type inferencing"
mode where we will be trying to infer and load things. No, that way
lies madness.
| > We must also be able to process a file without first having to split
| > it into several chunks. We have been able to process SPAD files that
| > way; making )abbrev a no-op.
| >
|
| In longer run sure.
Well, Axiom has 25-year horizon; so not sure what you mean by
"longer run" :-)
| ATM I am using quite different method: I dumped
| parse trees of the whole Axiom algebra into a file. So now I can load
| the whole algebra just as a single S-expression.
Well, (almost) everything is an S-expression; so I must ask which
"form" do you save an load? The parse tree? the parse form? The
internal AST? or the generated Lisp code?
What other thing we have been doing, we have found both the parse form
(not the parse tree) and the internal AST useful to save and load later.
A third form, not conveniently present in Axiom at the moment, is one
where either the parse form or the internal AST is completely typed
(just before code generation).
| I am loading this
| S-expression into sbcl running various analyses on it. The idea is to
| write (in Lisp) a simple compiler capable of extracting type declarations
| and generating from them Axiom databases.
Oh, that is simply done in Boot and I do hope you don't go to Lisp for
that. Just catch the parse form from postTranform or parseTransform.
I do sincerely hope, we don't end up multiplying parsers, analyzers,
type checkers, macro expanders, each with its own share of bugs, and
mix all those in form or Axiom!
[...]
| Concerning abbrev declaration: I am not sure how to find out wether
| something is a package or a domain without using information from
| abbrevs.
We should get to a poing where we don't need to distinsguish that!
Now, if you look at a capsule, it tells your whether something "is"
for a domain or not by the presence or absence of 'domain in the
category declaration. Again look at the the internal AST produced by
parseTransform.
I'm sorry the whole documentation is not online yet, but many things
are happening and I need to petition for 48h in a day.
Th algebra interface to the parser is very simple minded. There is
work going on to define different levels of fully typed ASTs.
-- Gaby
--=-=-=
-- Written by Gabriel Dos Reis (gdr AT cs DOT tamu DOT edu)
-- Last modified on Jan 15, 2007.
--
-- This file contains a low-level code for parsing
-- a Spad source file into an internal AST. The
-- AST, for the entire file, is presented as a list of
-- toplevel statements (mostly definitions).
-- Since this is low-level code, I don't expect people
-- to get here, and you cannot directly use it. If you think,
-- you need to get to here, then something is already wrong.
-- There is a higher-level interface, written in SPAD, to this
-- code. See gdr-spad-parser.spad.
--
-- To use this file:
-- (1) translate it to Common Lisp, with bootsys:
-- bootsys -batch -eval '(boottran::boottoclc "gdr-reader.boot")'
--
-- (2) compile gdr-spad-parser.spad
--
--
gdrParseSpadFile sourceFile ==
$SPAD : local := true -- we are parsing Spad,
$BOOT : local := false -- not Boot.
OUT_-STREAM := _*STANDARD_-OUTPUT_* -- spit any noise to
-- the standard output
-- we need to tell the post-parsing transformers that we're compiling;
-- few parse forms have slightly different representations
-- depending on whether we are in interpreter mode or compiler mode.
savedInteractiveMode := $InteractiveMode
$InteractiveMode := false
oldParserAutoloadOnceTrigger() -- load parsing functions
oldCompilerAutoloadOnceTrigger()
INIT_-BOOT_/SPAD_-READER()
savedInStream := IN_-STREAM -- we need to restore the
-- global input stream state
-- after we finished messing
-- with it
IN_-STREAM := MAKE_-INSTREAM sourceFile
INITIALIZE_-PREPARSE IN_-STREAM
asts := [] -- accumulates parse trees
-- for all definitions in
-- sourceFile.
while ^(_*EOF_* or FILE_-CLOSED) repeat
BOOT_-LINE_-STACK := PREPARSE IN_-STREAM
LINE := CDAR BOOT_-LINE_-STACK
PARSE_-NewExpr()
pt := POP_-STACK_-1() -- get the parse tree
pf := postTransform pt -- turn it into a parse form
ast := parseTransform pf -- finally into an AST
asts := cons([pf, ast], asts)
IOCLEAR(IN_-STREAM, OUT_-STREAM)
SHUT IN_-STREAM
IN_-STREAM := savedInStream
$InteractiveMode := savedInteractiveMode
-- we accumulated the parse trees in reverse order
-- of declarations.
reverse asts
--=-=-=
Pair(T) ==> Record(first: T, second: T)
AST ==> SExpression
)abbrev package SPADPRSR SpadParser
++ This package provides a simple minded interface to the SPAD parser.
++ Over time, we will add belts and whistles.
SpadParser(): Public == Private where
Public == with
parse: String -> List AST ++ parse(f) parses the source file f
++ and returns the result as a list of
++ pair of ASTs. The first component
++ of a pair is a parse form, and
++ the second compoenent is the internal AST.
++ Each pair on the list represents a
++ toplevel definition.
Private == add
spadReaderInitialized : Boolean := false
-- guards against multiple parser
-- definitions.
parse(source: String) : List AST ==
if not spadReaderInitialized then
LOAD("gdr-reader.clisp")$Lisp
spadReaderInitialized := true
ast : List SExpression := gdrParseSpadFile(source)$Lisp
ast
\start
Date: Wed, 7 Feb 2007 04:40:00 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Algebra bootstrap
Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
>
> | Current compiler (before algebra bootstrap) does not know about Integer.
>
> I don't think so.
>
> The internal AST that eventually reaches the type analyzer and the
> semantic analyzer, starting from compTopLelve, already contain mention
> of Integer (and the other basic types).
>
Try starting with minimal databases. You will get messages as:
Integer is not a known type
or
Boolean is not a known type
Compiler do have _some_ knowledge: Record, Union, Mapping and
Enumeration are built-in. There are some more or less random
pieces of information hardcoded in various parts of the compiler.
But Integer, Boolean and List are recognized only if present in
databeses.
Note that already postTransform uses semantic information:
postAtom x ==
$BOOT => x
x=0 => '(Zero)
x=1 => '(One)
EQ(x,'T) => 'T_$ -- rename T in spad code to T$
IDENTP x and GETDATABASE(x,'NILADIC) => LIST x
x
^^^^^^^^^^^^^^^^^^^^^^^
and parseTransform (more precisely parseHas) again preforms database
lookup.
> | And Integer depends on large part of algebra. So I would say that such
> | basic compiler while a noble goal would require substantial algebra
> | rewrite. Such rewrite in turn need something like Aldor post facto
> | extension.
>
> By "simple type", I don't expect the basic type to understand beyond
> simple operations defined on their domains.
>
> The glorious version of Integer is not needed wholesale when starting
> the boostrap process. The glorification is a set that needs to come
> after. Yes, post facto extensions are ways to achieve late
> glorification -- and if you look at the practice, this is not fancy;
> just think "type classes" (Haskell), which Axiom would have invented
> two decades ago if it had post facto extensions.
>
I use the following Integer for bootstrap:
)abbrev category INS IntegerNumberSystem
IntegerNumberSystem(): Category == with nil
)abbrev domain INT Integer
Integer: IntegerNumberSystem with
FakeIdentityToAppeaseSpad: % -> %
== add
FakeIdentityToAppeaseSpad(x) == x
This is enough to convince compiler that Integer is a valid type. I do
not see how better Integer will help in bootstrap. More precisely to
bootstrap you need to resolve forward references. And the problem is
that in _last_ bootstrap pass there is a lot of forward references.
I do not think that will help resolve those references.
I guess that you think about something like classic compiler bootstrap,
where you need to get translator for small language running and than
you can use it to translate rest of the compiler. In particular such
set of basic domains would allow to write large part of compiler in
Spad. But current bootstrap problem is really all about databases,
we do not care if during database bootstrap we get correct code (or
any code at all), we just want to collect type declaration. And
we need a lot of declarations in databases to start compiling
current Axiom algebra.
> | As an excercise I tried to make a minimal algebra. I compiled
> | about 20 very simple domains and categories and generated corresponding
> | databses, but resulting interpreter was non-functional. More effort
> | would probably give functional system, but ATM I am not sure if such
> | system is useful for bootstrap.
>
> I don't think the interpreter is a good way tp arrive to the
> bootstrap. We must be in "type checking" mode, not "type inferencing"
> mode where we will be trying to infer and load things. No, that way
> lies madness.
>
That was just a sanity check of what I did. All I am saying here is
that my attempt to create small system failed (it does not mean that
other will fail -- I certainly did not try hard and gave up early).
> | > We must also be able to process a file without first having to split
> | > it into several chunks. We have been able to process SPAD files that
> | > way; making )abbrev a no-op.
> | >
> |
> | In longer run sure.
>
> Well, Axiom has 25-year horizon; so not sure what you mean by
> "longer run" :-)
>
Few months and longer.
> | ATM I am using quite different method: I dumped
> | parse trees of the whole Axiom algebra into a file. So now I can load
> | the whole algebra just as a single S-expression.
>
> Well, (almost) everything is an S-expression; so I must ask which
> "form" do you save an load? The parse tree? the parse form? The
> internal AST? or the generated Lisp code?
>
I wrote: parse tree. More precisely I took output of Meta parser, just
before call to postTransform. I replaced call to postTransform by
call to a simple flattener (to replace nested trees having semicolon
as operator by lists) and pretty-printed the result of flattener
(without flattening the expression had too much nesting and
pretty-printer could not print it correctly).
> What other thing we have been doing, we have found both the parse form
> (not the parse tree) and the internal AST useful to save and load later.
> A third form, not conveniently present in Axiom at the moment, is one
> where either the parse form or the internal AST is completely typed
> (just before code generation).
>
> | I am loading this
> | S-expression into sbcl running various analyses on it. The idea is to
> | write (in Lisp) a simple compiler capable of extracting type declarations
> | and generating from them Axiom databases.
>
> Oh, that is simply done in Boot and I do hope you don't go to Lisp for
> that. Just catch the parse form from postTranform or parseTransform.
>
> I do sincerely hope, we don't end up multiplying parsers, analyzers,
> type checkers, macro expanders, each with its own share of bugs, and
> mix all those in form or Axiom!
>
My Lisp code is throw-away code (or research if you prefer such name).
The basic thing is that I am getting better turnaroud with sbcl.
I can load the algebra tree into sbcl in about half of second (I am
loading it from a fasl). Tree walk trough this tree takes small part
of second. If I have large output most of the time is spent pretty-printing
the results, which may take few seconds. If results are small the
whole run may finish in a second. I do not see how I could get
such turnaroud working inside Axiom tree. FYI, Axiom needed about
70 seconds to parse algebra -- I certainly do not want to loose
70 seconds each time I try something.
> [...]
>
> | Concerning abbrev declaration: I am not sure how to find out wether
> | something is a package or a domain without using information from
> | abbrevs.
>
> We should get to a poing where we don't need to distinsguish that!
>
> Now, if you look at a capsule, it tells your whether something "is"
> for a domain or not by the presence or absence of 'domain in the
> category declaration. Again look at the the internal AST produced by
> parseTransform.
>
I do not want to use output of parseTransform because it depends on
databases. If databases miss some information the resulting tree
is incorrect (sometimes the compiler will later fix such a tree, but
many cases lead to errors).
I think that currect Axiom apprach to compilation has serious flaw.
Namely postTransform and parseTransform are dane _before_ macro
expansion. This means that they have only limited syntactic
information and some transformations just work blindly. Both
parseTransform and postTransform compensate this lack of syntactic
data by use of semantic informations from databases.
I think that macro expansion should be done just after initial parse
(before any semantic transformations), that is why I have written
my macro expander. BTW: current Axiom way allow pretty weird
macro tricks, but it seems that algebra uses only small, well
behaved subset.
P.S. Thanks for the attached code.
\start
Date: Tue, 6 Feb 2007 23:11:24 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: Algebra bootstrap
On February 6, 2007 6:33 PM Waldek Hebisch wrote:
>
> I have commited new algebra bootstrap to wh-sandbox.
> ...
Fantastic.
>
> I have commited it so that:
> - others can see details of bootstrap process
Thank you very much for providing this work so quickly.
> - I can kill Lisp embedded in algebra pamphlets
>
Waldek,
Wy jeste=B6cie moimi bohaterem!
(You are my hero!)
\start
Date: 06 Feb 2007 23:00:27 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Algebra bootstrap
Waldek Hebisch writes:
| Gabriel Dos Reis wrote:
| > Waldek Hebisch writes:
| >
| > | Current compiler (before algebra bootstrap) does not know about Integer.
| >
| > I don't think so.
| >
| > The internal AST that eventually reaches the type analyzer and the
| > semantic analyzer, starting from compTopLelve, already contain mention
| > of Integer (and the other basic types).
| >
|
| Try starting with minimal databases. You will get messages as:
|
| Integer is not a known type
|
| or
|
| Boolean is not a known type
Yes, that adds evidence to my claim that the compiler knows about
Integer and other basic types: they are gotten through the databases,
and the compiler (in its current state) cannot do anything meaningful
without that knowledge. That is what I meant.
| Compiler do have _some_ knowledge: Record, Union, Mapping and
| Enumeration are built-in.
Yes. Record, Union, and MApping are necessary.
For Enumerations, I have not make my mind yet. Som built-in support
is needed, but it is not clear to me that level of built-in is needed.
| There are some more or less random
| pieces of information hardcoded in various parts of the compiler.
Yes, a systematic approach for restructuring the compiler (as well as
the interpreter) is needed. No doubt. My primary concern is about
laying down precisely the rules. That needs some kind of basic "first
principles". That is what I'm aiming at. I largely regard the
current setting as a defective departure that needs correction. The
question is what to correct? And in which directions?
| But Integer, Boolean and List are recognized only if present in
| databeses.
and if they are not, the compilation is screwed! You cannot really
define them as "secondary", because they come as annotation for
constants,a nd they parser knows they must mean something. They
really are "primary" from the compiler point of view. The compiler
needs to query the database because, it believes that Integer has more
properties (e.g. Euclidean domain) than it assumes. That is not the
case for a Record for example, neither for Mapping. The case of List
is a bit curious. However, my *guessing* from reading the code for
List is that it was realized that List can be assumed a basic domain,
but later enriched in an algebra file -- embryonic ideas for "post
facto extensions".
| Note that already postTransform uses semantic information:
|
| postAtom x ==
| $BOOT => x
| x=0 => '(Zero)
| x=1 => '(One)
| EQ(x,'T) => 'T_$ -- rename T in spad code to T$
| IDENTP x and GETDATABASE(x,'NILADIC) => LIST x
| x
| ^^^^^^^^^^^^^^^^^^^^^^^
But that really is not semantic information -- you don't need to
evaluate "x" to know what it means. That information is
purely syntactic, because you can infer it from purely syntactic
considerations looking at the parse form of a definition.
Now, if your point is that the post-parser transformer should be fixed
to clearly delimit the phase, the answer is yes. As the key is
approach this from the angle of "what it ideally should do?"; then you
look at the current approximation and see where the defect is.
| and parseTransform (more precisely parseHas) again preforms database
| lookup.
Much less than the interpreter. Still before and during the type
checking phase, we don't need to consult the databas, except, except,
when we have an "import" statement. But, even there I'm not sure
looking at the database is the right answer.
|
| > | And Integer depends on large part of algebra. So I would say that such
| > | basic compiler while a noble goal would require substantial algebra
| > | rewrite. Such rewrite in turn need something like Aldor post facto
| > | extension.
| >
| > By "simple type", I don't expect the basic type to understand beyond
| > simple operations defined on their domains.
| >
| > The glorious version of Integer is not needed wholesale when starting
| > the boostrap process. The glorification is a set that needs to come
| > after. Yes, post facto extensions are ways to achieve late
| > glorification -- and if you look at the practice, this is not fancy;
| > just think "type classes" (Haskell), which Axiom would have invented
| > two decades ago if it had post facto extensions.
| >
|
| I use the following Integer for bootstrap:
|
| )abbrev category INS IntegerNumberSystem
| IntegerNumberSystem(): Category == with nil
| )abbrev domain INT Integer
| Integer: IntegerNumberSystem with
| FakeIdentityToAppeaseSpad: % -> %
| == add
| FakeIdentityToAppeaseSpad(x) == x
|
| This is enough to convince compiler that Integer is a valid type. I do
| not see how better Integer will help in bootstrap. More precisely to
| bootstrap you need to resolve forward references. And the problem is
| that in _last_ bootstrap pass there is a lot of forward references.
| I do not think that will help resolve those references.
No, but you're looking at a much higher level and you don't see the
trees.
The question, for each individual uses of Integer is what is needed?
If you use "+", then the above fake is insufficient.
Where the "post factor" extensions helps is that you can add those
required operations as you go. This process is very diffrent from
asserting that Integer belongs to a given caterogy.
| I guess that you think about something like classic compiler bootstrap,
| where you need to get translator for small language running and than
| you can use it to translate rest of the compiler.
Yes, but there is nothing un-classic here, except that the runtime
support is a Lisp system. And precisely, we should take advantage of
that. You extend the small think and load it, and have an improved
version. That is much simpler that the "classic" compiler bootstrap.
Remember, they bootstrapped Lisp before they bootstrapped C, so if
sometrhing is classic, it certainly is Lsip bootstrapping :-)
| In particular such
| set of basic domains would allow to write large part of compiler in
| Spad.
YES!
I believe, I already stated that many times in the past.
I evene recalled Bill saying that from his point of view Boot was
conceived as a mini-SPAD, but I would have to disagree with him on
several technical points :-)
| But current bootstrap problem is really all about databases,
Get rid of the databases, or said differently look at the database as
the final thing with the belts and whistles. Don't design the
bootstrap process around it. It is what you build as wrap up. Think
of it as the .so or .a you ship to user. You don't build your
compiler to depend on it for its own bootstrap. You design your
compiler so that it can produce the library and use it. Shift
perspective.
| we do not care if during database bootstrap we get correct code (or
| any code at all),
We should care that we get correct code. Compiler miscompilation is a
nightmarre to debug.
| we just want to collect type declaration.
And most of this can be done at the abstract syntax level -- given the
relatively simple syntax.
| And
| we need a lot of declarations in databases to start compiling
| current Axiom algebra.
If we get to the point that the compiler can handle a unit
(e.g. source file) at a time, then you can rely on mutually recursive
definition to sort out the initial problem.
[...]
| > | > We must also be able to process a file without first having to split
| > | > it into several chunks. We have been able to process SPAD files that
| > | > way; making )abbrev a no-op.
| > | >
| > |
| > | In longer run sure.
| >
| > Well, Axiom has 25-year horizon; so not sure what you mean by
| > "longer run" :-)
| >
|
| Few months and longer.
OK, that is nothing then :-)
| > | ATM I am using quite different method: I dumped
| > | parse trees of the whole Axiom algebra into a file. So now I can load
| > | the whole algebra just as a single S-expression.
| >
| > Well, (almost) everything is an S-expression; so I must ask which
| > "form" do you save an load? The parse tree? the parse form? The
| > internal AST? or the generated Lisp code?
| >
|
| I wrote: parse tree. More precisely I took output of Meta parser, just
| before call to postTransform. I replaced call to postTransform by
| call to a simple flattener (to replace nested trees having semicolon
| as operator by lists) and pretty-printed the result of flattener
| (without flattening the expression had too much nesting and
| pretty-printer could not print it correctly).
OK. I'm nervous about having to duplicate the work of the post-parser
transformer. It should be fixed so that you don't have to outsource
its job.
[...]
| My Lisp code is throw-away code (or research if you prefer such name).
| The basic thing is that I am getting better turnaroud with sbcl.
| I can load the algebra tree into sbcl in about half of second (I am
| loading it from a fasl). Tree walk trough this tree takes small part
| of second. If I have large output most of the time is spent pretty-printing
| the results, which may take few seconds. If results are small the
| whole run may finish in a second. I do not see how I could get
| such turnaroud working inside Axiom tree. FYI, Axiom needed about
| 70 seconds to parse algebra -- I certainly do not want to loose
| 70 seconds each time I try something.
Now, the question is whether it is an inherent inefficient in Axiom,
or its runtime system (GCL). I know that some long time GCL users
have complained about GCL spending too much time doing unnecessary
work (mostly done on its behalf by GCC).
If it is an inherent deficiency in Axiom, we must know.
For example, there are many places in where an a-list is used, and
that a-list may induce in some places linear search -- when a
hash-table or just a good tree would have been better. The
the Environment (third slot of the triplet) is a horrible mess of
a-lists.
| > [...]
| >
| > | Concerning abbrev declaration: I am not sure how to find out wether
| > | something is a package or a domain without using information from
| > | abbrevs.
| >
| > We should get to a poing where we don't need to distinsguish that!
| >
| > Now, if you look at a capsule, it tells your whether something "is"
| > for a domain or not by the presence or absence of 'domain in the
| > category declaration. Again look at the the internal AST produced by
| > parseTransform.
| >
|
| I do not want to use output of parseTransform because it depends on
| databases.
yes but the uses of the databases at that particular point are not
necessary. If you fix that, do you still need to duplicate the job?
| If databases miss some information the resulting tree
| is incorrect (sometimes the compiler will later fix such a tree, but
| many cases lead to errors).
IF you can process a file in a whole -- which you can with the
skeleton I posted earlier -- you don't need to consult the databases.
|
| I think that currect Axiom apprach to compilation has serious flaw.
| Namely postTransform and parseTransform are dane _before_ macro
| expansion. This means that they have only limited syntactic
| information and some transformations just work blindly. Both
| parseTransform and postTransform compensate this lack of syntactic
| data by use of semantic informations from databases.
|
| I think that macro expansion should be done just after initial parse
| (before any semantic transformations), that is why I have written
| my macro expander. BTW: current Axiom way allow pretty weird
| macro tricks, but it seems that algebra uses only small, well
| behaved subset.
I believe I don't understand why the macro expansion *needs* to be
done before postTransform and parseTransform. I'm not saying you're
wrong; I'm saying "can you elaborate?".
\start
Date: Thu, 8 Feb 2007 00:53:55 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Algebra bootstrap
Bill Page wrote:
> Waldek,
>
> Wy jeste=B6cie moimi bohaterem!
>
> (You are my hero!)
>
You are welcome. I hope my work will be useful.
\start
Date: 08 Feb 2007 22:48:38 +0100
From: Francois Maltey
To: Bill Page
Subject: Re: axiom in windows xp for an user who isn't root.
Dear Bill,
> msys is not necessary to use Axiom on windows - only if you
> need to build Axiom from source.
>
I install Axiom in Windows from the binary install.
> > I change rights of the axiom directory and the msys directory.
> > Now they are read/write/and others for all users.
> >
> It sounds like the AXIOM environment variable is not set.
>
> To check the AXIOM variable go to:
>
> Start/ControlPanel/System/Advanced/EnvironmentVariables
Many thanks ! This variable was set for root, not for the other user.
> and check that the 'System variables' table includes
>
> Variable Name: AXIOM
> Variable Value: c:/Program Files/axiom/mnt/windows
\start
Date: Fri, 09 Feb 2007 19:30:44 +0000
From: Vladimir Bondarenko
To: list
Subject: Most recent AXIOM release(s)?
Hello *,
I am wondering what is the latest AXIOM release for Linux?
When the next release for Windows is planned (at least approximately)?
Thanks in advance.
\start
Date: Fri, 9 Feb 2007 23:28:15 -0800
From: Brent Fulgham
To: list
Subject: Building Axiom
Trying to get Axiom to build on the Mac is pretty frustrating, mainly
because the build fails on GCL. Since I already have access to at
least two (and possibly more) excellent Lisp implementations I
regularly use, it would be great to use one of them instead. (Or at
least, use a precompiled GCL, if I have one on my system).
Has anyone made any progress working with Axiom in a non-GCL
environment?
\start
Date: 10 Feb 2007 02:32:25 -0600
From: Gabriel Dos Reis
To: Brent Fulgham
Subject: Re: Building Axiom
Brent Fulgham writes:
| Trying to get Axiom to build on the Mac is pretty frustrating, mainly
| because the build fails on GCL.
There have been documented successful build reports on Mac OS/PowerPC. So,
could you be more specific?
\start
Date: 10 Feb 2007 09:50:07 +0100
From: Martin Rubey
To: Vladimir Bondarenko
Subject: Re: Most recent AXIOM release(s)?
Dear Vladimir,
Vladimir Bondarenko writes:
> I am wondering what is the latest AXIOM release for Linux?
there haven't been any "official" releases for quite a while. I recommend
checking out wh-sandbox, which seems to be quite good currently.
> When the next release for Windows is planned (at least approximately)?
Sorry, no windows. Bill?
Vladimir, did you consider taking the price for porting AldorUnit to Axiom?
Would be really nice!
\start
Date: 10 Feb 2007 12:17:26 +0100
From: Martin Rubey
To: Tim Daly
Subject: new AXIOM release(s)
Cc: Igor Khavkine
Dear Tim, *,
Tim Daly writes:
> So I'm resuming my role as "Lead Developer" and will generate a new release
> in the near future.
This is great news, Tim!
I believe, in fact, that this is one of your major strenghts!
> I'll try to pick up and merge some of the changes but not the whole new build
> system as it is still experimental.
Good luck!
I'll try to document the Taylor series patch provided by Igor Khakvine, so that
it is not only included in wh-sandbox, but also in trunk. (Although I accept
help, of course)
There are quite a few "fix proposed" issues on IssueTracker. If you find time
could you walk through them and send me mail like "please send documentation
for #xxx", I'll try to make an effort.
I have also documented parts of ystream.spad, find it attached below.
Martin
\documentclass{article}
\begin{document}
\title{ssolve.spad}
\author{Martin Rubey}
\maketitle
\begin{abstract}
\end{abstract}
\tableofcontents
<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>=
)abbrev package YSTREAM ParadoxicalCombinatorsForStreams
++ Computation of fixed points of mappings on streams
++ Author: Burge, Watt (revised by Williamson)
++ Date Created: 1986
++ Date Last Updated: 21 October 1989
++ Keywords: stream, fixed point
++ Examples:
++ References:
ParadoxicalCombinatorsForStreams(A):Exports == Implementation where
++ This package implements fixed-point computations on streams.
A : Type
ST ==> Stream
L ==> List
I ==> Integer
Exports ==> with
Y: (ST A -> ST A) -> ST A
++ Y(f) computes a fixed point of the function f.
Y: (L ST A -> L ST A,I) -> L ST A
++ Y(g,n) computes a fixed point of the function g, where g takes
++ a list of n streams and returns a list of n streams.
Implementation ==> add
This package uses the internal representation of [[Stream]]. There we read:
\begin{verbatim}
-- This description of the rep is not quite true.
-- The Rep is a pair of one of three forms:
-- [value: S, rest: %]
-- [nullstream: Magic, NIL ]
-- [nonnullstream: Magic, fun: () -> %]
-- Could use a record of unions if we could guarantee no tags.
NullStream: S := _$NullStream$Lisp pretend S
NonNullStream: S := _$NonNullStream$Lisp pretend S
Rep := Record(firstElt: S, restOfStream: %)
\end{verbatim}
<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>=
Y f ==
y : ST A := CONS(0$I,0$I)$Lisp
j := f y
RPLACA(y,frst j)$Lisp
RPLACD(y,rst j)$Lisp
y
@
Let [[f: ST -> ST]]. We create a new stream [[y]], which we leave
uninitialized. For the moment, I cannot explain why the compiler accepts
[[CONS(0$I,0$I)$Lisp]] as a stream. However, since [[Stream]]s are lazy, %
[[f y]] doesn't compute any elements of the stream. However, if [[f]] really
depends on its input, this dependence is then captured in the [[restOfStream]]
part of the record representing the stream. The next two lines replace
[[frstElt]] and [[restOfStream]] of [[y]] by those of [[j]], thus, now
[[restofStream]] of [[y]] depends on itself.
It seems that the $n$\textsuperscript{th} element of [[f y]] should only depend
on the first $n-1$ elements of [[y]]. For example, let us simulate the
computation of the first two elements of [[Y f]]: calling [[fun()]] returns the
first element $c_1$ of [[f y]]. Thus, [[Y f]] now equals $[c_1,\dots]$. Calling
[[fun()]] again, we have to get the second element of $f [c_1,\dots]$. Suppose
this equals $c_2$, and [[Y f]] now equals $[c_1,c_2,\dots]$.
<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>=
Y(g,n) ==
x : L ST A := [CONS(0$I,0$I)$Lisp for i in 1..n]
j := g x
for xi in x for ji in j repeat
RPLACA(xi,frst ji)$Lisp
RPLACD(xi,rst ji)$Lisp
x
\section{License}
<<license>>=
--Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
--All rights reserved.
--
--Redistribution and use in source and binary forms, with or without
--modification, are permitted provided that the following conditions are
--met:
--
-- - Redistributions of source code must retain the above copyright
-- notice, this list of conditions and the following disclaimer.
--
-- - Redistributions in binary form must reproduce the above copyright
-- notice, this list of conditions and the following disclaimer in
-- the documentation and/or other materials provided with the
-- distribution.
--
-- - Neither the name of The Numerical ALgorithms Group Ltd. nor the
-- names of its contributors may be used to endorse or promote products
-- derived from this software without specific prior written permission.
--
--THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
--IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
--TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
--PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
--OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
--EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
--PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
--PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
--LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
--NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
--SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
@
<<*>>=
<<license>>
<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>
@
\end{document}
\start
Date: Sat, 10 Feb 2007 18:56:49 +0600 (NOVT)
From: Andrey G. Grozin
To: list
Subject: build-improvements without external noweb: is it supposed to work?
Hello *,
I've just checked out build-improvements, ./configured it and started make:
grozin@gandalf ~/build-improvements $ make
Making in noweb
make[1]: Entering directory `/home/grozin/build-improvements/noweb/src'
cd c; make "CC=gcc -ansi -pedantic" "CFLAGS=" all
make[2]: Entering directory `/home/grozin/build-improvements/noweb/src/c'
notangle -Rheader errors.nw > errors.h
/bin/sh: notangle: command not found
make[2]: *** [errors.h] Error 127
make[2]: Leaving directory `/home/grozin/build-improvements/noweb/src/c'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/grozin/build-improvements/noweb/src'
make: *** [build/i686-pc-linux/bin/notangle] Error 2
I'll install noweb and try again. I just wonder: there is directory noweb,
and, if external noweb is not found, it should be build? Or am I wrong?
While I'm at it, one more question. I have gcl 2.6.7 installed. It is in
ansi mode (I need it for maxima). Will build-improvements build gcl in
traditional mode from the sources in the gcl directory? Or it will simply
fail? I'll see shortly, I just want to ask what it is supposed to do.
By the way, I use Gentoo current (very current, updated today :-).
Build-improvements seems the best bet for constructing a reasonable
ebuild, because it is distro-packager friendly. What do you think, is this
branch ready for packaging? (I mean not the main portage tree, but an
experimental overlay.) If not, when will it be ready for such wider
testing by the Gentoo community?
\start
Date: 10 Feb 2007 11:28:53 -0600
From: Gabriel Dos Reis
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb: is it supposed to work?
Andrey G. Grozin writes:
| Hello *,
|
| I've just checked out build-improvements, ./configured it and started make:
|
| grozin@gandalf ~/build-improvements $ make
| Making in noweb
| make[1]: Entering directory `/home/grozin/build-improvements/noweb/src'
| cd c; make "CC=gcc -ansi -pedantic" "CFLAGS=" all
| make[2]: Entering directory `/home/grozin/build-improvements/noweb/src/c'
| notangle -Rheader errors.nw > errors.h
| /bin/sh: notangle: command not found
| make[2]: *** [errors.h] Error 127
| make[2]: Leaving directory `/home/grozin/build-improvements/noweb/src/c'
| make[1]: *** [all] Error 2
| make[1]: Leaving directory `/home/grozin/build-improvements/noweb/src'
| make: *** [build/i686-pc-linux/bin/notangle] Error 2
|
| I'll install noweb and try again. I just wonder: there is directory
| noweb, and, if external noweb is not found, it should be build? Or am
| I wrong?
You're not doing anything wrong.
This is a timestampe issue introduced recently when noweb was
unpackage in the source tree. I should really fix that.
Here is how you can work around that:
# from the top directory of the Axiom build-improvements branch
# bring the timestamp up to date
% (cd noweb/src/c/ && touch *.h *.c)
# now issue make as usual
% make
| While I'm at it, one more question. I have gcl 2.6.7 installed. It is
| in ansi mode (I need it for maxima). Will build-improvements build gcl
| in traditional mode from the sources in the gcl directory? Or it will
| simply fail? I'll see shortly, I just want to ask what it is supposed
| to do.
If gcl is visible from your PATH, then configure will pick it by
default and use it. I have not tried gcl in ansi mode yet.
But, you can also convince Axiom's configure NOT to use the gcl from
your path (even if it found it): add --without-gcl to your configure
command line.
| By the way, I use Gentoo current (very current, updated today
| :-). Build-improvements seems the best bet for constructing a
| reasonable ebuild, because it is distro-packager friendly. What do you
| think, is this branch ready for packaging?
one of the reasons why this branch was created was to make it
"distro-package friendly". At the moment, I believe it supports the
traditional "./configure && make && make install", so it should be
ready for packaging. However, it does not support cross-compilation
for deeper reasons.
| (I mean not the main
| portage tree, but an experimental overlay.) If not, when will it be
| ready for such wider testing by the Gentoo community?
It would be great if you could help in that regard!
\start
Date: Sat, 10 Feb 2007 12:49:20 -0800
From: Brent Fulgham
To: Gabriel Dos Reis
Subject: Re: Building Axiom
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 10, 2007, at 12:32 AM, Gabriel Dos Reis wrote:
> Brent Fulgham writes:
>
> | Trying to get Axiom to build on the Mac is pretty frustrating,
> mainly
> | because the build fails on GCL.
>
> There have been documented successful build reports on Mac OS/
> PowerPC. So,
> could you be more specific?
I have not tried the Gold branch, but working from the "build
improvements" branch (following the instructions shown on http://
wiki.axiom-developer.org/BuildAxiom):
Chaz:~/Projects/Lisp/Axiom/build-improvements brent$ ./configure
checking build system type... powerpc-apple-darwin8.8.0
checking host system type... powerpc-apple-darwin8.8.0
checking target system type... powerpc-apple-darwin8.8.0
checking for gmake... no
[...]
config.status: creating src/doc/Makefile
config.status: creating build/scripts/document
config.status: creating config/axiom-c-macros.h
config.status: config/axiom-c-macros.h is unchanged
building list of Algebra bootstrap files...done
extracting list of SPAD type definitions...done
Chaz:~/Projects/Lisp/Axiom/build-improvements brent$ make
if test "." != "." -a ! -d gcl; then \
cp -r ./gcl .; \
fi; cd gcl; \
./configure --prefix=/Users/brent/Projects/Lisp/Axiom/build-
improvements/build/powerpc-apple-darwin8.8.0 --disable-statsysbfd
--enable-machine=powerpc-macosx --
enable-vssize=65536*2 --disable-tkconfig --disable-x --disable-xgcl && \
make && make install
loading cache ./config.cache
checking host system type... powerpc-apple-darwin8.8.0
host=powerpc-apple-darwin8.8.0
enable_machine=powerpc-macosx
use=powerpc-macosx
checking for gcc... (cached) gcc
[...]
So far, so good. But then terror strikes!
checking emacs info/dir... /Users/brent/Projects/Lisp/Axiom/build-
improvements/build/powerpc-apple-darwin8.8.0/share/info/
checking for tcl/tk... checking for tclsh... (cached) tclsh
checking for main in -llieee... (cached) no
not found
checking alloca... yes
checking Checking for buggy gcc version from redhat... no
creating ./config.status
creating makedefc
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating windows/gcl.iss
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating windows/sysdir.bat
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating windows/install.lsp
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating h/gclincl.h
makedefc
add-defs1 powerpc-macosx
using powerpc-macosx.defs
The sed stuff is failing due to some kind of line-ending problem.
Perhaps a UNIX/WINDOWS/MAC EOL issue? Looking in a text editor
doesn't show anything helpful. Of course, once the autogeneration
phase fails, everything else is broken after that point:
echo "ECHO start %1\lib\gcl-`cat majvers`.`cat minvers`\unixport\.exe
- -dir %1\lib\gcl-`cat majvers`.`cat minvers`\unixport -libdir %1\lib
\gcl-`cat majvers`.`cat minvers` -eval \"(setq si::*allow-gzipped-
file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9 >> gcli.bat" ) > /Users/brent/
Projects/Lisp/Axiom/build-improvements/gcl/bin/gclfinal.bat ; fi
(cd xbin ; cp ../bin/gcl .)
cd cmpnew && make gcl_collectfn.o
../unixport/saved_pre_gcl ../unixport/ -compile gcl_collectfn.lsp
make[2]: ../unixport/saved_pre_gcl: Command not found
make[2]: *** [gcl_collectfn.o] Error 127
make[1]: *** [cmpnew/gcl_collectfn.o] Error 2
make: *** [build/powerpc-apple-darwin8.8.0/bin/gcl] Error 2
Chaz:~/Projects/Lisp/Axiom/build-improvements brent$
Grr!
Waldek's version is no better for this error.
I could diff the 'official' GCL and Axiom GCL directories to see
what's wrong, if that might be helpful.
If anyone has successfully built on Mac, please let me know if you
had to do anything fancy. I already tried adjusting my pathing to
exclude my MacPorts stuff, but that didn't seem to help (using or not
using it resulted in the same problem).
\start
Date: Sat, 10 Feb 2007 16:34:58 -0500
From: Bill Page
To: Martin Rubey, Vladimir Bondarenko
Subject: RE: Most recent AXIOM release(s)?
On February 10, 2007 3:50 AM Martin Rubey wrote:
> ...
>
> Vladimir Bondarenko writes:
>
> > When the next release for Windows is planned (at least
> > approximately)?
>
> Sorry, no windows. Bill?
>
The build-improvements branch of Axiom builds on Windows.
\start
Date: Sat, 10 Feb 2007 18:50:45 -0800
From: Arthur Ralfs
To: list
Subject: )set output mathml on
This posting is in response to Andrey Grozin's questions here
http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00076.html
which were recently referenced by CY.
I wanted to get my mathml package delivering output. Here's what I did.
1. created output mathml section in src/interp/setvars.boot.pamphlet by
copying
and modifying the tex section. Remember to add "<<outputmathmlCode>>" at
end.
Copied setvars.boot.pamphlet and ran notangle on it.
From inside axiom ran )lisp (boottran::boottocl "tmp/setvars.boot")
which put setvars.clisp into int/interp/setvars.clisp and then replaced
the lisp in setvars.boot.pamphlet with that in setvars.clisp.
code chunks:
<<outputmathmlCode>>
<<setOutputMathml>>
<<describeSetOutputMathml>>
variables:
setOutputMathml
$mathmlOutputStream
$mathmlOutputFile
$mathmlFormat
describeSetOutputMathml
2. create output mathml section in setvart.boot.pamphlet.
Added line
mathml create output in MathML style Off:CONSOLE
to \section{output} table
Added <<outputmathml>> to code chunk <<output>> in \section{output}
code chunks:
<<outputmathml>>
variables:
setOutputMathml
$mathmlFormat
$mathmlOutputFile
3. Added
${OUT}/MMLFORM.o to Layer 17 of Makefile.pamphlet
So far I've eliminated the analog of TEX1, doesn't seem to be needed.
I added the line
"mathml.spad.pamphlet (MMLFORM)" to layer 17 completed spad files.
I added a dependency in my package so it needs to be in layer 17 rather
than layer 14 where TEX appears.
Incidentally why does TEX1 appear in layer 4 when it seems to depend
on TEX which appears in layer 14?
Added lines to SPADFILES and DOCFILES.
4. Added
(|MathMLFormat| . MMLFORM)
to exposed.lsp.pamphlet
5. Added
DONE mathml.spad.pamphlet
DONE )abbrev package MMLFORM MathMLFormat
to Lattice.pamphlet.
Stepped through Lattice.pamphlet by searching for "TEX" and
mimiced everthing for MMLFORM however I can't see that
Lattice.pamphlet is actually used anymore.
6. Added mathml.spad subsection to src/doc/axiom.bib.pamphlet.
7. Added
mathmlFormat expr ==
mml := '(MathMLFormat)
mmlrep := '(String)
formatFn := getFunctionFromDomain("coerce",mml,[$OutputForm])
displayFn := getFunctionFromDomain("display",mml,[mmlrep])
SPADCALL(SPADCALL(expr,formatFn),displayFn)
TERPRI $mathmlOutputStream
FORCE_-OUTPUT $mathmlOutputStream
NIL
to interp/i-output.boot.pamphlet
To function "output(expr,domain)" add lines for mathml,e.g.
"if $mathmlFormat then mathmlFormat expr".
After all this I successfully compile axiom (using gold branch) so
now I can do this:
(1) -> )set messages autoload off
(1) -> )set output tex on
(1) -> )set output mathml on
(1) -> (x+y)**2
2 2
(1) y + 2x y + x
$$
{y \sp 2}+{2 \ x \ y}+{x \sp 2}
\leqno(1)
$$
<math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big"
display="block">
<mrow><msup><mrow><mi>y</mi></mrow><mrow><mn>2</mn></mrow></msup></mrow><mo>+</mo><mrow><mn>2</mn><mo>⁢</mo><mi>x</mi><mo>⁢</mo><mi>y</mi></mrow><mo>+</mo><mrow><msup><mrow><mi>x</mi></mrow><mrow><mn>2</mn></mrow></msup></mrow>
</math>
Type: Polynomial
Integer
\start
Date: Sat, 10 Feb 2007 21:37:43 -0600
From: Tim Daly
To: Arthur Ralfs
Subject: )set output mathml on
> I wanted to get my mathml package delivering output....
Excellent. This seems to be a simple enough change that we could
pick it up quite quickly. There is a browser plugin by Sam Dooley,
a previous Axiom author, that handles MathML. I can't remember the
name though.
In order to pick up this work into the mainstream axiom it still
lacks a few pieces:
1) DOCUMENTATION. besides modifying the pamphlet files it would
be useful if you could write down any understanding you gained
about how the current code works and why you needed to change
what you did. It's the 'WHY' that is most important to future
people trying to follow your changes. Assume some other person
is trying to understand and change your code 30 years later.
Plus, if you made the effort to understand how Axiom works in
some small piece, it is worth capturing that understanding so
others can build on it. For instance, why does TEX1 appear
useless? What did you depend on that moved your code up the
layer chain? Is there a 1-to-1 correspondence between MathML
constructs and Axiom-Tex constructs? Does your code cover all
the cases?
2) MORE DOCUMENTATION. I, and many others, do not know the details
of MathML. Perhaps finding/referencing/writing some overview as
well as adding bibliographic references would be useful. Look at
dhmatrix.spad.pamphlet for an example of possible documentation.
A discussion of the possible forms of equation output in Axiom
and their generation by your code would make the whole change
much easier to maintain and modify once they come out the MATHML 2.0
3) TESTS. MathML works for your example. But a reasonable test suite
is needed to check the range of coverage and to make sure it doesn't
get broken in the future. One of two approaches seem reasonable to
me, although any reasonable test strategy is fine. You could either
collect a large number of axiom input syntax expressions into a
single file and run your code against this set, thus testing the
robustness on "random" input you didn't create. You could also give
some thought to a "coverage" test suite to show that you handle
things like summation symbols, equation numbering, various bracing
styles, tables, as well as the usual things like exponentiation, etc.
This kind of testing really won't cover the "format" issues for
output and I'm not sure how we could do that. But it will test for
code-breakage on random and constructed input. Axiom users can
create their own output formats for their domains which is not
constrained to follow "standard math".
Please add your test files to the src/input/Makefile.
4) PATCH FILES. Run
diff -Naur axiomfile.pamphlet yourfile.pamphlet >axiomfile.pamphlet.patch
so we can see exactly what changed in each file. The "-Naur" option is
the standard way to create axiom patch files.
This is really the only way to "get it off your desk" and into the
distribution. I try to pick up changes I understand "in the small"
which I can test but more glorious changes really require your effort.
Packaging changes to "get it off your desk" is three times more work.
I'd like to be able to pick things up that seem "simple" but since I'm
not the author I have no real ability to debug it when the merge breaks.
\start
Date: Sun, 11 Feb 2007 19:07:38 +0300
From: Vadim V. Zhytnikov
To: list
Subject: Re: new AXIOM release(s)
> Tim Daly writes:
>
>> So I'm resuming my role as "Lead Developer" and will generate a new release
>> in the near future.
>
This is really good news!
But maybe you find it possible to change the way
how Axiom releases are actually released.
1) IMHO publish release as CVS tree on SorceForge
is bad practice. To make sure whether something
have changed or I still have some old release
I have to check all hundreds of files in CVS tree.
Publishing release as a single file (tarball)
is common practice and is much better IMHO.
2) I'd like to see some consistent version
numbering scheme for Axiom releases which
will last more than one year. It will be
of great help for maintainers of .rpm and
.deb packages who package Axiom for
various Linux distributions and users
who use these packages.
Try to find axiom on www.rpmfind.com and
you'll see that now each packager invents
his own package numbering scheme - all
different.
I understand that both issues are purely
technical but I think they are important
enough from practical point of view.
After all this is question of identity.
\start
Date: 11 Feb 2007 10:21:50 -0600
From: Gabriel Dos Reis
To: Vadim V. Zhytnikov
Subject: Re: new AXIOM release(s)
Vadim V. Zhytnikov writes:
[...]
| 1) IMHO publish release as CVS tree on SorceForge
| is bad practice. To make sure whether something
| have changed or I still have some old release
| I have to check all hundreds of files in CVS tree.
| Publishing release as a single file (tarball)
| is common practice and is much better IMHO.
Fully agreed.
|
| 2) I'd like to see some consistent version
| numbering scheme for Axiom releases which
| will last more than one year. It will be
| of great help for maintainers of .rpm and
| .deb packages who package Axiom for
| various Linux distributions and users
| who use these packages.
I propose the numbering X.Y.Z, with
* X == major release number
* Y == minor release number
* Z == patch level release number
I propose that the next version be 3.5.0, with subsequent bug fix
releases, be 3.5.x.
When we merge build-improvements to trunk, I would suggest we bump it
to 4.0.0.
I also propose that on a regular bases (e.e.g 3 months), we make
either a patch release or a minor release; we make a major release
every year. The latter assumes we have enough momentum.
[...]
| After all this is question of identity.
\start
Date: Sun, 11 Feb 2007 11:59:58 -0600
From: Tim Daly
To: Vadim V. Zhytnikov
Subject: new AXIOM release(s)
> 1) IMHO publish release as CVS tree on SorceForge is bad practice...
That's unlikely to change, at least by me. I'm only trying to maintain
the source tree, not the release of binaries. The sources also live at
savannah.nongnu.org (CVS), axiom-developer.org (arch), and
sourceforge.net (SVN), as well as on google.
I could create a tarball and store it on these sites except for one
problem, ... time. I simply don't have the time. I'm not a company.
I'm one guy sitting in a room working on this at night and on weekends
as a hobby. However, if you have the interest you could maintain
tarballs on these sites. Advocacy is volunteering.
I put together a web page showing a grid of binaries and their
platforms (<http://daly.axiom-developer.org/axiombinary>) which was
mentioned on this list a while ago and, I believe, was picked up by
<http://wiki.axiom-developer.org> (I don't see it there now). However,
no one has contributed any binaries.
> 2) I'd like to see some consistent version numbering scheme....
Check the mailing list archives. We've had this discussion and
several schemes were proposed, such as the usual Major.Minor.Patch
schemes. We settled on a version scheme, which is consistent,
which is machine checkable, and which has been used for years.
There is a VERSION variable in the top level Makefile.
This variable is changed with every new release of the source code.
This version is printed in the banner when Axiom starts:
AXIOM Computer Algebra System
Version: Axiom (September 2006)
Timestamp: Thursday December 14, 2006 at 20:11:24
The Version: says what source release was used for the build.
The Timestamp: says what date and time the binary build occurred.
The VERSION variable is: boot::*build-version* which you can access:
-> _*BUILD_-VERSION_*$Lisp
(1) Axiom (September 2006)
Type: SExpression
-> )lisp *build-version*
Value = "Axiom (September 2006)"
Since source releases occur (on a best-effort) basis every two months
there is no ambiguity to the Month-Year format.
The TIMESTAMP variable is: boot::*yearweek* which you can access:
-> _*YEARWEEK_*$Lisp
(2) Thursday December 14, 2006 at 20:11:24
Type: SExpression
-> )lisp *yearweek*
Value = "Thursday December 14, 2006 at 20:11:24 "
The variable name "yearweek" comes from the fact that I used to release
Axiom on a weekly basis when I was at IBM and it was my primary job.
Tim
\start
Date: Sun, 11 Feb 2007 19:21:52 +0100
From: Gregory Vanuxem
To: list
Subject: Request for testing (Win32 users)
Hello,
I have uploaded a version of Axiom built on top of SBCL for Windows (32
bits).
So if you are a Windows user, you already know Axiom and you can spent some
time
for testing and reporting bugs I would really be happy.
Things that you have to know:
* You must know Axiom,
* You have an official version of Axiom (built on top of GCL) for Windows,
* You must know that this version comes with absolutely no warranty of any
kind,
* "How to use it" is not supported,
* Bug (that is, bug in this version not present in the official one) MUST be
reported to vanuxemg at yahoo dot fr and not to the official Axiom bug
tracking systems,
* This is not the same version than the official one (the code differs),
* This is not a fork (code in this version is destined to be included in the
official version),
* The source code is NOT available (sorry, not yet),
* Do not discuss issues related to this version on the official Axiom
mailing lists unless
this is explicitely permitted,
* This version contains a LOT of bugs,
* This version is based on an "experimental" version of SBCL so you'll
contribute to SBCL
too if you find SBCL bugs, but do know that all of this is experimental,
* Do not trust its results.
It can be downloaded from:
http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
To use it, untar/unbzip2 it in a directory without space in its name (full
path without space).
Export the environment variable AXIOM, it must point to the directory that
contains
the algebra, bin etc... directories.
So for example:
set AXIOM=c:\somewhere\axiom-sbcl-win
and you can start it with
c:\somewhere\axiom-sbcl-win\bin\interpsys
One of the the most important thing to know is that this work is based on
the
work of Juergen Weiss (among others of course), he "ported" parts of Axiom
to the CMU Common Lisp system.
Many, many thanks to you, Juergen Weiss.
\start
Date: Sun, 11 Feb 2007 12:36:12 -0600
From: Tim Daly
To: Gregory Vanuxem
Subject: request for testing (Win32 users)
"Do not discuss issues related to this version on the official Axiom
mailing lists unless explicitly permitted"
Well, it's axiom. it's in development. this is the most likely place
to discuss it. you don't need permission to discuss anything on this
list (although some topics, like legal topics which have their own
list, can generate some pushback).
But if you want permission, you have mine for what that's worth.
It seems perfectly reasonable to discuss the SBCL effort here.
Tim
\start
Date: 11 Feb 2007 13:32:00 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: new AXIOM release(s)
Tim Daly writes:
[...]
| > 2) I'd like to see some consistent version numbering scheme....
|
| Check the mailing list archives. We've had this discussion and
| several schemes were proposed, such as the usual Major.Minor.Patch
| schemes. We settled on a version scheme, which is consistent,
| which is machine checkable, and which has been used for years.
The "machine checkable" thing is a non-argument.
There are other meaningful machine checkable alternative as well.
% gcc -v
[...]
gcc version 4.3.0 20070210 (experimental)
% /usr/bin/gcc -v ~
[...]
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
% ld --version
GNU ld version 2.15.94.0.2.2 20041220 (SuSE Linux)
\start
Date: Sun, 11 Feb 2007 14:40:44 -0500
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: new AXIOM release(s)
Hi Gaby,
> I propose the numbering X.Y.Z, with
>
> * X == major release number
> * Y == minor release number
> * Z == patch level release number
>
> I propose that the next version be 3.5.0, with subsequent bug fix
> releases, be 3.5.x.
> When we merge build-improvements to trunk, I would suggest we bump it
> to 4.0.0.
>
> I also propose that on a regular bases (e.e.g 3 months), we make
> either a patch release or a minor release; we make a major release
> every year. The latter assumes we have enough momentum.
With a 3 months cycles, I think a schema like the ones used by Gentoo or Ubuntu
makes sense: 2007.3, 2007.6.....or 7.03, 7.06....where is clearly
visible when it was
released.
I say this because maybe there is no that many changes for the X.Y.Z
schema, even when I am aware that this is usually the standard.
Just my 0.005 cents.
\start
Date: Sun, 11 Feb 2007 22:46:11 +0300
From: Vadim V. Zhytnikov
To: Tim Daly
Subject: Re: new AXIOM release(s)
Tim Daly writes:
>> 1) IMHO publish release as CVS tree on SorceForge is bad practice...
>
> That's unlikely to change, at least by me. I'm only trying to maintain
> the source tree, not the release of binaries.
I mean only source release tarball not any binaries.
\start
Date: Sun, 11 Feb 2007 13:50:58 -0600 (CST)
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: new AXIOM release(s)
On Sun, 11 Feb 2007, Alfredo Portes wrote:
| Hi Gaby,
|
| > I propose the numbering X.Y.Z, with
| >
| > * X == major release number
| > * Y == minor release number
| > * Z == patch level release number
| >
| > I propose that the next version be 3.5.0, with subsequent bug fix
| > releases, be 3.5.x.
| > When we merge build-improvements to trunk, I would suggest we bump it
| > to 4.0.0.
| >
| > I also propose that on a regular bases (e.e.g 3 months), we make
| > either a patch release or a minor release; we make a major release
| > every year. The latter assumes we have enough momentum.
|
| With a 3 months cycles, I think a schema like the ones used by Gentoo or Ubuntu
| makes sense: 2007.3, 2007.6.....or 7.03, 7.06....where is clearly
| visible when it was
| released.
That also makes sense.
\start
Date: Sun, 11 Feb 2007 15:38:54 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)
On February 11, 2007 1:22 PM Vanuxem Gr=E9gory wrote:
>
> I have uploaded a version of Axiom built on top of SBCL for
> Windows (32 bits). So if you are a Windows user, you already
> know Axiom and you can spent some time for testing and reporting
> bugs I would really be happy.
Great! I am very glad you are working on this.
>
> Things that you have to know:
>
> * You must know Axiom,
> * You have an official version of Axiom (built on top of GCL)
> for Windows,
I do, I do. :-)
> * You must know that this version comes with absolutely no
> warranty of any kind,
> * "How to use it" is not supported,
Isn't that already obvious and clear? I think this applies to
all open source projects including the open source version(s)
of Axiom.
> * Bug (that is, bug in this version not present in the
> official one) MUST be reported to vanuxemg at yahoo dot fr
> and not to the official Axiom bug tracking systems,
Do you prefer this for your own personal reasons? I do not see
why your work should not be included along with the other current
and experimental version of Axiom. It is possible to make special
provision (i.e. new categories) in the Axiom wiki IssueTracker
system to refer to your new version so that we can easily
distinguish to which version the issue applies.
> * This is not the same version than the official one (the
> code differs),
I do not know what is really "official" any more. Juergen Weiss'
experimental version of Axiom on CMUCL has been discussed before
on this list and his original source code has been distributed.
Some of his changes have been incorporated into the "official"
sources in available via CVS and at SourceForge.
> * This is not a fork (code in this version is destined to be
> included in the official version),
> * The source code is NOT available (sorry, not yet),
I think it would be perfect if you would make this source available
as a branch in SVN at SourceForge.
> * Do not discuss issues related to this version on the official
> Axiom mailing lists unless this is explicitly permitted,
As Tim Daly has already pointed out: no permission is required
to discuss any Axiom related issue on the "official" Axiom mailing
lists. In fact, discussing Axiom any other way seems rather
pointless to me.
> * This version contains a LOT of bugs,
I think that this is not a surprise and does not differ from other
current experimental versions of Axiom.
> * This version is based on an "experimental" version of SBCL so
> you'll contribute to SBCL too if you find SBCL bugs, but do
> know that all of this is experimental,
Great. I am very glad that someone has finally begun to work
publicly with Axiom on another version of Lisp.
> * Do not trust its results.
>
That applies to ALL computer algebra systems - even the expensive
commercial ones.
>
> It can be downloaded from:
> http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
>
> To use it, untar/unbzip2 it in a directory without space in its
> name (full path without space). Export the environment variable
> AXIOM, it must point to the directory that contains the algebra,
> bin etc... directories.
>
> So for example:
>
> set AXIOM=c:\somewhere\axiom-sbcl-win
>
> and you can start it with
>
> c:\somewhere\axiom-sbcl-win\bin\interpsys
>
Thank very much for making this available.
>
> One of the most important thing to know is that this work
> is based on the work of Juergen Weiss (among others of course),
> he "ported" parts of Axiom to the CMU Common Lisp system.
>
> Many, many thanks to you, Juergen Weiss.
>
Yes, as I have said before: Juergen's work on the CMU version
was (and still is) critically important to the current open
source version of Axiom. I think it would be great if someone
would take on the job of making the source for the CMU version
available in the SourceForge SVN repository. I think there may
be some people who would be willing to test it further and to
contribute changes and improvements.
I don't think we should be afraid to work on several different
versions of Axiom in parallel, especially when one of the stated
goals is to of the Axiom project is to support Axiom on a number
of different Common Lisp environments.
Thanks again, Greg, for making your work available!
\start
Date: Sun, 11 Feb 2007 16:24:54 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)
You wrote:
> ...
> To use it, untar/unbzip2 it in a directory without space in its
> name (full path without space).
> Export the environment variable AXIOM, it must point to the
> directory that contains the algebra, bin etc... directories.
>
> So for example:
>
> set AXIOM=c:\somewhere\axiom-sbcl-win
>
> and you can start it with
>
> c:\somewhere\axiom-sbcl-win\bin\interpsys
> ...
I get the following result on by Windows XP SP2 system while
running under Cygwin, using 'wget ...' and 'tar xjvf' to
extract the binary and setting the AXIOM variable:
$ echo $AXIOM
/home/Administrator/axiom-sbcl-win
Administrator@asus ~/axiom-sbcl-win
$ /home/Administrator/axiom-sbcl-win/bin/interpsys
This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
This is experimental prerelease support for the Windows platform: use
at your own risk. "Your Kitten of Death awaits!"
>> System error:
The file ".\\" does not exist.
debugger invoked on a SB-INT:SIMPLE-CONTROL-ERROR:
attempt to THROW to a tag that does not exist: |top_level|
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
(no restarts: If you didn't do this on purpose, please report it as a bug.)
("no debug information for frame")
0]
---------
Any idea what might be wrong?
\start
Date: Sun, 11 Feb 2007 22:53:03 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Request for testing (Win32 users)
> -----Message d'origine-----
> Greg,
>
> You wrote:
>
> > ...
> > To use it, untar/unbzip2 it in a directory without space in its
> > name (full path without space).
> > Export the environment variable AXIOM, it must point to the
> > directory that contains the algebra, bin etc... directories.
> >
> > So for example:
> >
> > set AXIOM=c:\somewhere\axiom-sbcl-win
> >
> > and you can start it with
> >
> > c:\somewhere\axiom-sbcl-win\bin\interpsys
> > ...
>
> I get the following result on by Windows XP SP2 system while
> running under Cygwin, using 'wget ...' and 'tar xjvf' to
> extract the binary and setting the AXIOM variable:
>
> $ echo $AXIOM
> /home/Administrator/axiom-sbcl-win
This is a native Windows application so SBCL does not
understand the path used (Cygwin specific).
\start
Date: Sun, 11 Feb 2007 19:31:57 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)
Greg,
On February 11, 2007 4:53 PM you wrote:
> ...
> I wrote:
> > I get the following result on by Windows XP SP2 system while
> > running under Cygwin, using 'wget ...' and 'tar xjvf' to
> > extract the binary and setting the AXIOM variable:
> >
> > $ echo $AXIOM
> > /home/Administrator/axiom-sbcl-win
>
> This is a native Windows application so SBCL does not
> understand the path used (Cygwin specific).
>
Duh! I should have realized ... thanks.
You it works. Great job. I think this is a great step forward
for a fully ANSI-compliant common lisp implementation of Axiom.
I can't resist to ask: Have you tried building this version of
Axiom with GCL in ANSI mode?
Regards,
Bill Page.
PS. Could you explain the phrase: "Kitten of Death" :-)
Example output of axiom-sbcl-win on my Windows system:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Administrator.ASUS>set
AXIOM=C:\cygwin\home\Administrator\axiom-sbcl-win
C:\Documents and
Settings\Administrator.ASUS>C:\cygwin\home\Administrator\axiom-sbcl-win/b=
in/
interpsys
This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
This is experimental prerelease support for the Windows platform: use
at your own risk. "Your Kitten of Death awaits!"
-------------------------------------------------------------------------=
---
-
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-
(1) -> integrate(1/sqrt(1-x^2),x)
Loading
...
+--------+
| 2
\|- x + 1 - 1
(1) - 2atan(---------------)
x
Type: Union(Expression
Integer,...)
(2) ->
\start
Date: Sun, 11 Feb 2007 22:29:12 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)
Greg,
So far I have two problems with axiom-sbcl-win to report:
1) The )cd command does not work as expected. Here is an
example with my comments marked --->
-------
C:\Documents and Settings\Administrator.ASUS\Desktop>set
AXIOM=C:\cygwin\home\Administrator\axiom-sbcl-win
C:\Documents and Settings\Administrator.ASUS\Desktop>cd "c:\Documents =
and
Settings\Administrator.ASUS\My Documents"
C:\Documents and Settings\Administrator.ASUS\My
Documents>C:\cygwin\home\Administrator\axiom-sbcl-win\bin\interpsys
This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
This is experimental prerelease support for the Windows platform: use
at your own risk. "Your Kitten of Death awaits!"
-------------------------------------------------------------------------=
---
-
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-
(1) -> )sys cd
C:\Documents and Settings\Administrator.ASUS\My Documents
---> The current system path is correct.
(1) -> )cd
The current AXIOM default directory is
C:\Documents and Settings\Administrator.ASUS\
---> This current directory is wrong. So this file is not found.
(1) -> )co FOO.spad
The file FOO.spad is needed but does not exist.
---> But we can set it explicitly
(1) -> )cd "C:\Documents and Settings\Administrator.ASUS\My Documents"
The current AXIOM default directory is
C:\Documents and Settings\Administrator.ASUS\My Documents\
---> Now it works.
(1) -> )co FOO.spad
Compiling AXIOM source code from file
C:\Documents and Settings\Administrator.ASUS\My Documents\FOO.spad
using old system compiler.
...
---> The package is compiled (FASL) and loaded and executes as
expected. Great!
---------
Note: This problem occurs even if the path does not contain any
spaces.
But here is the second problem.
2) If I compile the same file twice, the existing compiler output is
not replaced:
(1) -> )co FOO.spad
...
finalizing NRLIB FOO
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the path specified.
The system cannot find the path specified.
>> System error:
Win32 Error [MoveFileW@8] - 183
Cannot create a file when that file already exists.
-----------
Note: This re-compile problem does *not* occur if the current
directory is set to a path that contains no spaces.
\start
Date: Mon, 12 Feb 2007 02:14:06 -0500
From: Cliff Yapp
To: list
Subject: SBCL and Axiom
Vanuxem Grgory wrote:
> Hello,
>
> I have uploaded a version of Axiom built on top of SBCL for Windows (32
> bits).
Interesting! Not being a Windows user I can't check this out directly,
but it is good news.
I have a couple of questions concerning how this has been accomplished,
although they may be premature:
1. You mentioned Juergen Weiss's CMUCL port - did you alter that code
to run on SBCL or use the techniques there as a guide and convert one of
the other trees?
2. Did you change the boot/SPAD compilers to output SBCL compliant lisp
code, or hand tweak the lisp code produced by the "regular" compile?
Back when I took a run at SBCL + Axiom, one of the points that became
quickly clear was that short of carrying through with a complete
conversion of all boot code to lisp (a long term goal at the moment) or
simply living with hand tweaked translator output for a large number of
files at least the boot compiler and possibly the spad compiler would
need to be adjusted to output ANSI lisp. I was able to just about load
the stand-alone bootstrap boot->lisp system after some tweaking, but I
didn't carry much further than that.
Gaby has proceeded much deeper into the BOOT world than I was ever able
to and the presence of old and new BOOT (shoe?) adds a rather unexpected
twist. The prospect of fixing BOTH variations to output correct code is
not a particularly enjoyable one. My hope was that the new BOOT (shoe)
was the stand alone code in the boot directory, which I suspect would be
somewhat simpler to get working as the first step in getting sbcl to
support the complete build chain as it exists today in GCL.
Gaby, did SHOE ever reach a point where it could convert all of the
Axiom BOOT code to lisp? I recall there being a couple of different
conventions between BOOT and SHOE but I don't remember the conclusion -
can the conversion be made?
\start
Date: 12 Feb 2007 08:14:41 -0600
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: SBCL and Axiom
Cliff Yapp writes:
[...]
| Gaby has proceeded much deeper into the BOOT world than I was ever
| able to and the presence of old and new BOOT (shoe?) adds a rather
| unexpected twist. The prospect of fixing BOTH variations to output
| correct code is not a particularly enjoyable one.
It is wrong to have both variations around. Old Boot should go away.
That is non negotiable.
| My hope was that
| the new BOOT (shoe) was the stand alone code in the boot directory,
| which I suspect would be somewhat simpler to get working as the first
| step in getting sbcl to support the complete build chain as it exists
| today in GCL.
That is my understanding too.
| Gaby, did SHOE ever reach a point where it could convert all of the
| Axiom BOOT code to lisp?
We are almost there. I've found that the new Boot is much simpler,
and more comfortable to work with.
\start
Date: Mon, 12 Feb 2007 06:45:35 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: SBCL and Axiom
--- Gabriel Dos Reis wrote:
> Cliff Yapp writes:
>
> [...]
>
> | Gaby has proceeded much deeper into the BOOT world than I was ever
> | able to and the presence of old and new BOOT (shoe?) adds a rather
> | unexpected twist. The prospect of fixing BOTH variations to output
> | correct code is not a particularly enjoyable one.
>
> It is wrong to have both variations around. Old Boot should go away.
> That is non negotiable.
Agreed.
> | Gaby, did SHOE ever reach a point where it could convert all of the
> | Axiom BOOT code to lisp?
>
> We are almost there. I've found that the new Boot is much simpler,
> and more comfortable to work with.
Excellent news. Is there anything I/we can do to help that process
along? When we have that, I would like to take another run at getting
the complete bootstrap process working on sbcl. Roughly, I think it
will work something like:
1. Get boottocl working and compare the generated output to the
current output, and identify any differences. Once we can generate the
same output, in theory Boot/Shoe should be functional. I don't
anticipate any tremendous difficulty here based on my earlier
experiences.
2. Once it is working, start tracking down gotchas that prevent the
generated lisp code from working in SBCL, and start tweaking BOOT to
generate correct results. In one sense I would prefer to work directly
with the lisp code but I think that is too large a project to start
with - fixing BOOT to generate legal ANSI code should (hopefully) be a
relatively straightforward change.
3. Once we can load the generated files from BOOT successfully, see if
the SPAD compiler also needs fixing. If the translation is
SPAD->Boot->Lisp we should be OK, but I'm guessing it's SPAD->Lisp and
so more tweaking will be needed. Hopefully the changes to BOOT will
map fairly readily to SPAD as well.
The completion of that process should leave us with a functional Axiom
on sbcl using the existing process and no hand tweaked lisp files other
than the ones that are lisp now, which I think is where we want to
start when merging portability changes back into the main tree given
the current build situation. Hand tweaked lisp files that are supposed
to be autogenerated will work in specific cases but will be hard to
maintain, so I think we need to bite the bullet and go back to the
source. Once we are running in sbcl using the existing bootstrap
process we can try many things (like asdf) without being forced to step
carefully around the build issues, which I think will help speed things
up.
\start
Date: Mon, 12 Feb 2007 08:58:11 -0600 (CST)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: SBCL and Axiom
On Mon, 12 Feb 2007, C Y wrote:
|
| --- Gabriel Dos Reis wrote:
|
| > Cliff Yapp writes:
| >
| > [...]
| >
| > | Gaby has proceeded much deeper into the BOOT world than I was ever
| > | able to and the presence of old and new BOOT (shoe?) adds a rather
| > | unexpected twist. The prospect of fixing BOTH variations to output
| > | correct code is not a particularly enjoyable one.
| >
| > It is wrong to have both variations around. Old Boot should go away.
| > That is non negotiable.
|
| Agreed.
|
| > | Gaby, did SHOE ever reach a point where it could convert all of the
| > | Axiom BOOT code to lisp?
| >
| > We are almost there. I've found that the new Boot is much simpler,
| > and more comfortable to work with.
|
| Excellent news. Is there anything I/we can do to help that process
| along? When we have that, I would like to take another run at getting
| the complete bootstrap process working on sbcl. Roughly, I think it
| will work something like:
|
| 1. Get boottocl working and compare the generated output to the
| current output, and identify any differences. Once we can generate the
| same output, in theory Boot/Shoe should be functional. I don't
| anticipate any tremendous difficulty here based on my earlier
| experiences.
The New Boot translator has the command boottran::boottoclc (no the
ending 'c') that includes the definitions being translated as comments
in the CL output.
I have to make a list of reserved words or "library" functions that
both Old Boot and New Boot use. That should help you quickly focuse
on the "interesting" bits.
| 2. Once it is working, start tracking down gotchas that prevent the
| generated lisp code from working in SBCL, and start tweaking BOOT to
| generate correct results. In one sense I would prefer to work directly
| with the lisp code but I think that is too large a project to start
| with - fixing BOOT to generate legal ANSI code should (hopefully) be a
| relatively straightforward change.
Agreed. I believe the Boot "language" shields us from many low-level
details and quickly move to the real issue. I acknowledge that the
state we are now where it has been neglected is unfortunate. I'll try
to do as much as I can.
| 3. Once we can load the generated files from BOOT successfully, see if
| the SPAD compiler also needs fixing. If the translation is
| SPAD->Boot->Lisp we should be OK, but I'm guessing it's SPAD->Lisp and
| so more tweaking will be needed. Hopefully the changes to BOOT will
| map fairly readily to SPAD as well.
Yes. Note also that the New Boot translator has the framework to
generate machine code (when told where the CL compiler is) from Boot
and load it in the running image at a go.
| The completion of that process should leave us with a functional Axiom
| on sbcl using the existing process and no hand tweaked lisp files other
| than the ones that are lisp now, which I think is where we want to
| start when merging portability changes back into the main tree given
| the current build situation. Hand tweaked lisp files that are supposed
| to be autogenerated will work in specific cases but will be hard to
| maintain, so I think we need to bite the bullet and go back to the
| source. Once we are running in sbcl using the existing bootstrap
| process we can try many things (like asdf) without being forced to step
| carefully around the build issues, which I think will help speed things
| up.
There are still some GCL-isms deeply embedded in Axiom.
\start
Date: Mon, 12 Feb 2007 17:24:43 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Request for testing (Win32 users)
Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
> Greg,
>
> On February 11, 2007 4:53 PM you wrote:
> > ...
> > I wrote:
> > > I get the following result on by Windows XP SP2 system while
> > > running under Cygwin, using 'wget ...' and 'tar xjvf' to
> > > extract the binary and setting the AXIOM variable:
> > >
> > > $ echo $AXIOM
> > > /home/Administrator/axiom-sbcl-win
> >
> > This is a native Windows application so SBCL does not
> > understand the path used (Cygwin specific).
> >
>
> Duh! I should have realized ... thanks.
>
> You it works. Great job. I think this is a great step forward
> for a fully ANSI-compliant common lisp implementation of Axiom.
> I can't resist to ask: Have you tried building this version of
> Axiom with GCL in ANSI mode?
No, I dropped support of GCL because of spurious bugs: (cond ...)
handled strangely (a runtime problem apparently). But I added some
modifications to allow it to run on the "ANSI" version of GCL. They are
not tested of course.
> Regards,
> Bill Page.
>
> PS. Could you explain the phrase: "Kitten of Death" :-)
No :-) It comes from the SBCL banner (on Windows only).
\start
Date: Mon, 12 Feb 2007 11:40:11 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)
Cc: Camm Maguire
Earlier Gregory Vanuxem wrote:
> I have uploaded a version of Axiom built on top of SBCL for
> Windows (32 bits).
>
> It can be downloaded from:
> http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
> ...
On February 12, 2007 11:25 AM Gregory Vanuxem wrote:
> ...
> Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
> >
> > It works. Great job. I think this is a great step forward
> > for a fully ANSI-compliant common lisp implementation of Axiom.
> > I can't resist to ask: Have you tried building this version of
> > Axiom with GCL in ANSI mode?
>
> No, I dropped support of GCL because of spurious bugs: (cond ...)
> handled strangely (a runtime problem apparently). But I added
> some modifications to allow it to run on the "ANSI" version of
> GCL. They are not tested of course.
>
Thanks. I think the GCL main developer Camm Maquire would be
strongly motivated to help with ensuring that an ANSI version
of Axiom works with GCL, especially as a means to test and
improve GCL's support for ANSI. As I recall he is away for a
few more weeks but we should expect some comment from him on
this when he returns.
\start
Date: Mon, 12 Feb 2007 17:30:31 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Request for testing (Win32 users)
Le dimanche 11 f=E9vrier 2007 =E0 22:29 -0500, Bill Page a =E9crit :
> Greg,
>
> So far I have two problems with axiom-sbcl-win to report:
>
> 1) The )cd command does not work as expected. Here is an
> example with my comments marked --->
Thanks for reporting these problems, they are added on my TODO list and
in fact the problem is more complex, we need some functions that
generate correct (portable) pathname. I have modified some functions in
this regards but I do not always use them. I (or we) will use them later
but these type of things (and a lot of other from my point of view) need
to be "uniformized" and well defined (the API and it's _REAL_
conformance to ANSI CL).
\start
Date: 12 Feb 2007 11:26:06 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Request for testing (Win32 users)
Gregory Vanuxem writes:
| Le dimanche 11 f=E9vrier 2007 =E0 22:29 -0500, Bill Page a =E9crit :
| > Greg,
| >
| > So far I have two problems with axiom-sbcl-win to report:
| >
| > 1) The )cd command does not work as expected. Here is an
| > example with my comments marked --->
|
| Thanks for reporting these problems, they are added on my TODO list and
| in fact the problem is more complex, we need some functions that
| generate correct (portable) pathname.
Aim for POSIX -- they already have done the work -- and have tools
that convert non-POSIX to POSIX. In essence, that is what MinGW does
with the path names.
\start
Date: 12 Feb 2007 11:26:50 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Request for testing (Win32 users)
Gregory Vanuxem writes:
| Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
| > Greg,
| >
| > On February 11, 2007 4:53 PM you wrote:
| > > ...
| > > I wrote:
| > > > I get the following result on by Windows XP SP2 system while
| > > > running under Cygwin, using 'wget ...' and 'tar xjvf' to
| > > > extract the binary and setting the AXIOM variable:
| > > >
| > > > $ echo $AXIOM
| > > > /home/Administrator/axiom-sbcl-win
| > >
| > > This is a native Windows application so SBCL does not
| > > understand the path used (Cygwin specific).
| > >
| >
| > Duh! I should have realized ... thanks.
| >
| > You it works. Great job. I think this is a great step forward
| > for a fully ANSI-compliant common lisp implementation of Axiom.
| > I can't resist to ask: Have you tried building this version of
| > Axiom with GCL in ANSI mode?
|
| No, I dropped support of GCL because of spurious bugs: (cond ...)
| handled strangely (a runtime problem apparently).
Are those known to GCL developers?
\start
Date: Mon, 12 Feb 2007 18:27:48 +0100
From: Gregory Vanuxem
To: Cliff Yapp
Subject: Re: SBCL and Axiom
Le lundi 12 f=E9vrier 2007 =E0 02:14 -0500, C Y a =E9crit :
> Vanuxem Gr=E9gory wrote:
> > Hello,
> >
> > I have uploaded a version of Axiom built on top of SBCL for Windows (32
> > bits).
>
> Interesting! Not being a Windows user I can't check this out directly,
> but it is good news.
>
> I have a couple of questions concerning how this has been accomplished,
> although they may be premature:
>
> 1. You mentioned Juergen Weiss's CMUCL port - did you alter that code
> to run on SBCL or use the techniques there as a guide and convert one of
> the other trees?
I completely based this work on the version of Juergen Weiss. My work
was essentially the one of an ant. I grepped the code for "cmu" added
support of SBCL and Clisp. After that I added some files and modified
bootsys so that it can be compiled on GCL, SBCL, Clisp and (for the fun)
Allegro CL. Finally I tried to fix as much as can bugs.
Juergen Weiss did an amazing work...
Of course there are some GLC'ish things in the boot code, as Gaby said
previously, that needed to be fixed. I must point out that what I have
done will need to be checked by Lisp specialists. The version that I'll
share will not be the one I'm working on. I added to this "shareable"
version a tons of things from the official Axiom such that it'll be easy
to diff it. But I intimately think that we have to reorganise, simplify,
factorise, develop and document the code when we will merge changes. I
already began to reorganise the code, this is a pain to work on, say
stream for example, when the code is disseminated everywhere...
>
> 2. Did you change the boot/SPAD compilers to output SBCL compliant lisp
> code, or hand tweak the lisp code produced by the "regular" compile?
No the code (from spad, bootsys boot and old boot) produced by the version
on which I'm working (presumably the same than the official Axiom))
is compilable and "runnable" by SBCL, CMU [1] and Clisp.
>
> Back when I took a run at SBCL + Axiom, one of the points that became
> quickly clear was that short of carrying through with a complete
> conversion of all boot code to lisp (a long term goal at the moment) or
> simply living with hand tweaked translator output for a large number of
> files at least the boot compiler and possibly the spad compiler would
> need to be adjusted to output ANSI lisp. I was able to just about load
> the stand-alone bootstrap boot->lisp system after some tweaking, but I
> didn't carry much further than that.
>
> Gaby has proceeded much deeper into the BOOT world than I was ever able
> to and the presence of old and new BOOT (shoe?) adds a rather unexpected
> twist. The prospect of fixing BOTH variations to output correct code is
> not a particularly enjoyable one. My hope was that the new BOOT (shoe)
> was the stand alone code in the boot directory, which I suspect would be
> somewhat simpler to get working as the first step in getting sbcl to
> support the complete build chain as it exists today in GCL.
Spad, bootsys boot and old boot can be compiled without problem
:-). It's really simple to add support of SBCL, Clisp, CMU and Allegro
(though I'm pretty sure some bugs remain) to bootsys.
I forgot to say one thing, I have not "ported" the socket code. I need
first to better understand some parts of Axiom relative to this.
Greg
PS : I have a couple of problems with CMU CL, it can not compile some
functions and I don't know why as of now.
\start
Date: Mon, 12 Feb 2007 18:29:45 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Re: TR: Request for testing (Win32 users)
>From Bill Page:
> >
> > > * Bug (that is, bug in this version not present in the
> > > official one) MUST be reported to vanuxemg at yahoo dot fr
> > > and not to the official Axiom bug tracking systems,
> >
> > Do you prefer this for your own personal reasons? I do not see
> > why your work should not be included along with the other current
> > and experimental version of Axiom. It is possible to make special
> > provision (i.e. new categories) in the Axiom wiki IssueTracker
> > system to refer to your new version so that we can easily
> > distinguish to which version the issue applies.
Nothing personal. But for now the code is not public so this is
problematic. I prefer to not pollute official Axiom bugs tracker.
> > > * This is not the same version than the official one (the
> > > code differs),
> >
> > I do not know what is really "official" any more. Juergen Weiss'
> > experimental version of Axiom on CMUCL has been discussed before
> > on this list and his original source code has been distributed.
> > Some of his changes have been incorporated into the "official"
> > sources in available via CVS and at SourceForge.
> >
> > > * This is not a fork (code in this version is destined to be
> > > included in the official version),
> > > * The source code is NOT available (sorry, not yet),
> >
> > I think it would be perfect if you would make this source available
> > as a branch in SVN at SourceForge.
> >
> > > * Do not discuss issues related to this version on the official
> > > Axiom mailing lists unless this is explicitly permitted,
> >
> > As Tim Daly has already pointed out: no permission is required
> > to discuss any Axiom related issue on the "official" Axiom mailing
> > lists. In fact, discussing Axiom any other way seems rather
> > pointless to me.
> >
> > > * This version contains a LOT of bugs,
> >
> > I think that this is not a surprise and does not differ from other
> > current experimental versions of Axiom.
> >
> > > * This version is based on an "experimental" version of SBCL so
> > > you'll contribute to SBCL too if you find SBCL bugs, but do
> > > know that all of this is experimental,
> >
> > Great. I am very glad that someone has finally begun to work
> > publicly with Axiom on another version of Lisp.
> >
> > > * Do not trust its results.
> > >
> >
> > That applies to ALL computer algebra systems - even the expensive
> > commercial ones.
> >
> > >
> > > It can be downloaded from:
> > > http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
> > >
> > > To use it, untar/unbzip2 it in a directory without space in its
> > > name (full path without space). Export the environment variable
> > > AXIOM, it must point to the directory that contains the algebra,
> > > bin etc... directories.
> > >
> > > So for example:
> > >
> > > set AXIOM=c:\somewhere\axiom-sbcl-win
> > >
> > > and you can start it with
> > >
> > > c:\somewhere\axiom-sbcl-win\bin\interpsys
> > >
> >
> > Thank very much for making this available.
> >
> > >
> > > One of the most important thing to know is that this work
> > > is based on the work of Juergen Weiss (among others of course),
> > > he "ported" parts of Axiom to the CMU Common Lisp system.
> > >
> > > Many, many thanks to you, Juergen Weiss.
> > >
> >
> > Yes, as I have said before: Juergen's work on the CMU version
> > was (and still is) critically important to the current open
> > source version of Axiom. I think it would be great if someone
> > would take on the job of making the source for the CMU version
> > available in the SourceForge SVN repository. I think there may
> > be some people who would be willing to test it further and to
> > contribute changes and improvements.
There are, already, a lot of versions of Axiom (gold, silver,
build-improvements, wh-sandbox...), I do not want to add yet another
one. Don't know how this has to be handled.
\start
Date: 12 Feb 2007 11:45:40 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: SBCL and Axiom
Gregory Vanuxem writes:
[...]
| Juergen Weiss did an amazing work...
Yup.
| Of course there are some GLC'ish things in the boot code, as Gaby said
| previously, that needed to be fixed. I must point out that what I have
| done will need to be checked by Lisp specialists. The version that I'll
| share will not be the one I'm working on. I added to this "shareable"
| version a tons of things from the official Axiom such that it'll be easy
| to diff it. But I intimately think that we have to reorganise, simplify,
| factorise, develop and document the code when we will merge changes. I
| already began to reorganise the code, this is a pain to work on, say
| stream for example, when the code is disseminated everywhere...
It would be nice it your work (or the shareable version of it) could
be put on a branch...
[...]
| I forgot to say one thing, I have not "ported" the socket code.
Ah, that one! :-) don't worry about it -- as long as you don't fire
up sman and friends.
\start
Date: Mon, 12 Feb 2007 18:58:03 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Request for testing (Win32 users)
Le lundi 12 f=E9vrier 2007 =E0 11:26 -0600, Gabriel Dos Reis a =E9crit :
> Gregory Vanuxem writes:
>
> | Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
> | > Greg,
> | >
> | > On February 11, 2007 4:53 PM you wrote:
> | > > ...
> | > > I wrote:
> | > > > I get the following result on by Windows XP SP2 system while
> | > > > running under Cygwin, using 'wget ...' and 'tar xjvf' to
> | > > > extract the binary and setting the AXIOM variable:
> | > > >
> | > > > $ echo $AXIOM
> | > > > /home/Administrator/axiom-sbcl-win
> | > >
> | > > This is a native Windows application so SBCL does not
> | > > understand the path used (Cygwin specific).
> | > >
> | >
> | > Duh! I should have realized ... thanks.
> | >
> | > You it works. Great job. I think this is a great step forward
> | > for a fully ANSI-compliant common lisp implementation of Axiom.
> | > I can't resist to ask: Have you tried building this version of
> | > Axiom with GCL in ANSI mode?
> |
> | No, I dropped support of GCL because of spurious bugs: (cond ...)
> | handled strangely (a runtime problem apparently).
>
> Are those known to GCL developers?
The big problem is to find a simple way to reproduce it, I haven't one.
I have sent a bug report (for GCL-2.7) to Camm ("Disparition of a
condition ?") and it may be similar to the one in gcl-2.6.8pre so... The
big problem is that I'm alone with this bug, Bill and Waldek does not
have this bug. The bug is (on 2.6.8):
(1) -> )set br query
(1) -> 1/0
>> Error detected within library code:
division by zero
You have two options. Enter:
top to return to top level, or
break to enter a LISP break loop.
Please enter your choice now:
Normally we have three choices... (and the code looks correct, I don't
understand).
I dropped support of GCL, but that does not mean I don't want to support
GCL. The code on which I'm working is destined to be included on a
version that supports GCL.
\start
Date: Mon, 12 Feb 2007 20:18:47 +0100 (CET)
From: Waldek Hebisch
To: Brent Fulgham
Subject: Re: Building Axiom
Brent Fulgham wrote:
> Trying to get Axiom to build on the Mac is pretty frustrating, mainly
> because the build fails on GCL. Since I already have access to at
> least two (and possibly more) excellent Lisp implementations I
> regularly use, it would be great to use one of them instead. (Or at
> least, use a precompiled GCL, if I have one on my system).
>
Have you tried to use precompiled GCL? On Linux I regulary use
such method:
GCL=/path/to/gcl ../wh-sandbox/configure
There is a little catch: last time I chcecked build did not work
with ANSI version of GCL. But gcl-2.6.7 and 2.6.8 worked fine.
\start
Date: Mon, 12 Feb 2007 21:43:39 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Bug 312
I would like here to make some remarks concering bug 312. First,
this bug is really in 'powern' function defined in
'sttaylor.spad.pamphlet'. Below is (corrected) version contained
in wh-sandbox:
powern(rn,x) ==
order : I := 0
for n in 0.. repeat
empty? x => return zro()
not zero? frst x => (order := n; leave x)
x := rst x
n = 1000 =>
error "**: series with many leading zero coefficients"
(ord := (order exquo denom(rn))) case "failed" =>
error "**: rational power does not exist"
co := frst x
if ord > 0 and rn < 0 then
error "**: negative power does not exist"
(invCo := recip co) case "failed" =>
error "** rational power of coefficient undefined"
-- This error message is misleading, isn't it? see sups.spad/cRationalPower
power :=
-- one? co => YS(powerrn(rn,x,#1))
(co = 1) => YS(powerrn(rn,x,#1))
(denom rn) = 1 =>
not negative?(num := numer rn) =>
-- It seems that this cannot happen, but I don't know why
(co**num::NNI) * YS(powerrn(rn,(invCo :: A) * x,#1))
(invCo :: A)**((-num)::NNI) * YS(powerrn(rn,(invCo :: A) * x,#1))
RATPOWERS => co**rn * YS(powerrn(rn,(invCo :: A) * x,#1))
error "** rational power of coefficient undefined"
monom(1,(ord :: I) * numer(rn)) * power
-------------------------
At first glance this function looks cryptic. But look at documentation:
powern : (RN,ST A) -> ST A
++ powern(r,f) raises power series f to the power r.
So 'powern' is supposed to raises Taylor series to a rational power.
How one can to such thing? If Taylor series has form f=1+c_1*x+...
(the lowest order term is zero) one can recursively compute coefficients
using the fact that:
(f+a*x^n)^r = f^r+r*a*x^n mod x^(n+1)
Axiom code uses YS operator to solve this reccurence: this is done
in assignment to 'power' variable.
If the series has non-zero, non one lowest order term, that is
f = c_0*(1+c_1*x+...),
we just have to divide f by c_0 and multiply the result by
c_0^r (this is also handled in the assignment to power).
So the remaining case is when the lowest order term is 0. In this
case
f = x^a*f_1
where f_1 has non-zero lowest order term. We handle f_1 by earlier
method while (x^a)^r = x^(a*r). However, we want a Taylor series
as a result, so we must require that a*r is a natural number.
Now, the first part of 'powern' handles splitting this power of x:
order : I := 0
for n in 0.. repeat
empty? x => return zro()
not zero? frst x => (order := n; leave x)
x := rst x
n = 1000 =>
error "**: series with many leading zero coefficients"
(note that 'x' in the code is what I call 'f' above, while my 'a' is
called 'order' in the code). Next, we check that order*r is an
integer:
(ord := (order exquo denom(rn))) case "failed" =>
error "**: rational power does not exist"
Remember first nonzero coefficient:
co := frst x
Check that we get nonnegative order*r:
if ord > 0 and rn < 0 then
error "**: negative power does not exist"
I skip assignment to power (explained eariler). Finally we have
to multiply the result by correct power of 'x':
monom(1,(ord :: I) * numer(rn)) * power
(note that ord = order/denom(rn), so ord * numer(rn) = order*rn).
Checking in SVN archive shows that the last line was omitted in
revision 19. The change in revision 19 added support for negative
integer powers, it is clear that omission of last line was
unintentional.
\start
Date: 12 Feb 2007 15:59:31 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: TR: Request for testing (Win32 users)
[...]
| > > Yes, as I have said before: Juergen's work on the CMU version
| > > was (and still is) critically important to the current open
| > > source version of Axiom. I think it would be great if someone
| > > would take on the job of making the source for the CMU version
| > > available in the SourceForge SVN repository. I think there may
| > > be some people who would be willing to test it further and to
| > > contribute changes and improvements.
|
| There are, already, a lot of versions of Axiom (gold, silver,
| build-improvements, wh-sandbox...), I do not want to add yet another
| one. Don't know how this has to be handled.
The more the merrier.
\start
Date: Mon, 12 Feb 2007 14:20:27 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis, regory Vanuxem
Subject: Re: TR: Request for testing (Win32 users)
--- Gabriel Dos Reis wrote:
> | There are, already, a lot of versions of Axiom (gold, silver,
> | build-improvements, wh-sandbox...), I do not want to add yet
> | another one. Don't know how this has to be handled.
>
> The more the merrier.
At this point, I'd say with everyone exploring and testing at a very
basic level the only thing to do is to keep a list as best we can.
Eventually things will probably come together as the best solutions
appear, but for a while it's going to be a bit crazy.
The requirement to document code in a literate fashion means the hurdle
to get code in the main tree is high, and that means a lot of
experimental branches will spring up as people do "not ready for prime
time" work. In some ways this might actually keep people from assuming
Axiom is ready for uses it isn't really ready for, so it's not all bad.
Cheers,
CY
P.S. - is http://weitz.de/cl-fad/ of interest for the path issues? For
sockets http://common-lisp.net/project/usocket/ might be of interest.
\start
Date: Tue, 13 Feb 2007 12:48:17 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: SBCL and Axiom
Gabriel Dos Reis wrote:
> Cliff Yapp writes:
> | Gaby, did SHOE ever reach a point where it could convert all of the
> | Axiom BOOT code to lisp?
>
> We are almost there. I've found that the new Boot is much simpler,
> and more comfortable to work with.
>
Gaby, how do you plan to avoid latent bugs due to semantic differences
between Boot and Shoe? AFAICS Shoe accepts almast all (or maybe all)
Boot, but trying to use it results in build failure due to mistranslation.
Do you have a tool that can flag places where semantics of Boot and Shoe
differ?
\start
Date: Tue, 13 Feb 2007 06:58:14 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: SBCL and Axiom
On Tue, 13 Feb 2007, Waldek Hebisch wrote:
| Gabriel Dos Reis wrote:
| > Cliff Yapp writes:
| > | Gaby, did SHOE ever reach a point where it could convert all of the
| > | Axiom BOOT code to lisp?
| >
| > We are almost there. I've found that the new Boot is much simpler,
| > and more comfortable to work with.
| >
|
| Gaby, how do you plan to avoid latent bugs due to semantic differences
| between Boot and Shoe? AFAICS Shoe accepts almast all (or maybe all)
| Boot,
Almost -- not all. If you run the New Boot translator on some files
in src/interp, you'll get syntax errors.
| but trying to use it results in build failure due to mistranslation.
What mistranslation?
| Do you have a tool that can flag places where semantics of Boot and Shoe
| differ?
No, but the only places I'm aware of where both languages differ
is in a tiny part of "built-in" or "library" functions.
To have a tool that does what you say, we must have the difference in
semantics documented.
The differences are apparent once we have the table in
front of our eyes, and there we can have a warning is we want.
For any other construct, I'm not aware of semantics difference.
\start
Date: Tue, 13 Feb 2007 15:02:43 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: SBCL and Axiom
Gabriel Dos Reis wrote:
> On Tue, 13 Feb 2007, Waldek Hebisch wrote:
>
> | Gabriel Dos Reis wrote:
> | > Cliff Yapp writes:
> | > | Gaby, did SHOE ever reach a point where it could convert all of the
> | > | Axiom BOOT code to lisp?
> | >
> | > We are almost there. I've found that the new Boot is much simpler,
> | > and more comfortable to work with.
> | >
> |
> | Gaby, how do you plan to avoid latent bugs due to semantic differences
> | between Boot and Shoe? AFAICS Shoe accepts almast all (or maybe all)
> | Boot,
>
> Almost -- not all. If you run the New Boot translator on some files
> in src/interp, you'll get syntax errors.
>
> | but trying to use it results in build failure due to mistranslation.
>
> What mistranslation?
>
Well, I tried once to compile all .boot files using Shoe. IIRC I was
able to quckly handle syntax errors. But the process quickly died
during algebra build: clearly SPAD compiler was mistranslated.
I now tried to just convert 'postpar.boot.pamphlet'. First, quoted
symbols such as 'if 'in 'where where upcased (AFAIUI you call this
"library" differences). I am not aware of any more problem with
'postpar.boot.pamphlet', but ATM build is in progress and it will
take some time to verify results. However, I also noticed another
problem: Shoe mistranslates some where constructs. In particular,
in as.boot.pamphlet we have function asCategoryParts which has
where clause defining three functions: main, build, and exportsOf.
main references exportsOf. Shoe renames the three nested functions,
but fails to rename reference in main to exportsOf.
\start
Date: Tue, 13 Feb 2007 08:49:41 -0500
From: Cliff Yapp
To: Gregory Vanuxem
Subject: Re: SBCL and Axiom
Gregory Vanuxem wrote:
>> 1. You mentioned Juergen Weiss's CMUCL port - did you alter that code
>> to run on SBCL or use the techniques there as a guide and convert one of
>> the other trees?
>
> I completely based this work on the version of Juergen Weiss. My work
> was essentially the one of an ant. I grepped the code for "cmu" added
> support of SBCL and Clisp. After that I added some files and modified
> bootsys so that it can be compiled on GCL, SBCL, Clisp and (for the fun)
> Allegro CL. Finally I tried to fix as much as can bugs.
OK
> Juergen Weiss did an amazing work...
No question. It's a shame that work didn't get more press way back when.
> Of course there are some GLC'ish things in the boot code, as Gaby said
> previously, that needed to be fixed. I must point out that what I have
> done will need to be checked by Lisp specialists. The version that I'll
> share will not be the one I'm working on. I added to this "shareable"
> version a tons of things from the official Axiom such that it'll be easy
> to diff it.
OK, sounds good. I'm fooling around with asdf at the moment trying to
figure out how to work with it, which may be a bit premature but will
hopefully be useful later on. (Don't know how well GCL/asdf play
together, I've never successfully run asdf on GCL personally.)
> But I intimately think that we have to reorganise, simplify,
> factorise, develop and document the code when we will merge changes. I
> already began to reorganise the code, this is a pain to work on, say
> stream for example, when the code is disseminated everywhere...
>
>> 2. Did you change the boot/SPAD compilers to output SBCL compliant lisp
>> code, or hand tweak the lisp code produced by the "regular" compile?
>
> No the code (from spad, bootsys boot and old boot) produced by the version
> on which I'm working (presumably the same than the official Axiom))
> is compilable and "runnable" by SBCL, CMU [1] and Clisp.
Really?? That's excellent news, but rather surprising.
> Spad, bootsys boot and old boot can be compiled without problem
:-). It's really
> simple to add support of SBCL, Clisp, CMU and Allegro (though I'm pretty sure
> some bugs remain) to bootsys.
Nice! I have the code in the boot/ directory loading on sbcl as well,
so it will be interesting to check what the various diffs look like. I
have tried running it on interp but I get what are probably the
collisions between old boot and new boot Gaby mentioned before.
> I forgot to say one thing, I have not "ported" the socket code. I need
> first to better understand some parts of Axiom relative to this.
I'd say usockets and cl-fad might be of interest here (the links I
provided in another email) but I don't have enough experience with
either to know for sure.
\start
Date: 13 Feb 2007 16:22:43 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: document missing in installation
Dear Waldek,
it seems that version 434 of wh-sandbox seems to install "document" to
axiom/target/.../bin
Is this only on my machine?
Furthermore, it seems that my packages get recompiled in any case, even if I
only did a configure to change the prefix.
\start
Date: Wed, 14 Feb 2007 16:18:52 +0600 (NOVT)
From: Andrey G. Grozin
To: Gabriel Dos Reis
Subject: Re: build-improvements without external noweb: is it supposed to work?
I've installed noweb and did
./configure --prefix=/usr --infodir=/usr/share/info \
--mandir=/usr/share/man --without-gcl
(because my external gcl is ansi), then make. After some time, I've got
./../..//build/i686-pc-linux/bin/lisp -batch -eval \
'(progn (mapcar (function (lambda (x) (load x))) \
(quote ( "boothdr.o" "exports.o" "npextras.o"
"stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
"stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
"stage0/tytree1.o"))) \
(system::save-system "bootsys"))'
Error: The variable |
| is unbound.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by PROGN.
Broken at MAPCAR. Type :H for Help.
>>
What should I do next?
\start
Date: Wed, 14 Feb 2007 08:36:25 -0600 (CST)
From: Gabriel Dos Reis
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb: is it supposed to work?
On Wed, 14 Feb 2007, Andrey G. Grozin wrote:
| Hello,
|
| I've installed noweb and did
|
| ./configure --prefix=/usr --infodir=/usr/share/info \
| --mandir=/usr/share/man --without-gcl
|
| (because my external gcl is ansi), then make. After some time, I've got
|
| ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
| '(progn (mapcar (function (lambda (x) (load x))) \
| (quote ( "boothdr.o" "exports.o" "npextras.o"
| "stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
| "stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
| "stage0/tytree1.o"))) \
| (system::save-system "bootsys"))'
|
| Error: The variable |
| | is unbound.
| Fast links are on: do (si::use-fast-links nil) for debugging
| Error signalled by PROGN.
| Broken at MAPCAR. Type :H for Help.
| >>
|
| What should I do next?
This is a bug in GCL, also reported by Bill. I'll check in a work
around for Axiom.
\start
Date: Wed, 14 Feb 2007 10:52:32 -0500
From: Bill Page
To: list
Subject: gcl and noweb in the build-improvements source tree
Cc: Gabriel Dos Reis
Every time I download build-improvments on a new machine, I've been
thinking about the decision to include gcl and noweb source in the
Axiom source tree (in source format) in the SVN repository at
SourceForge. It seems to me that rather than having gcl inside the
tree
/trunk
....
/branches/wh-sandbox
...
/branches/build-improvements
/branches/build-improvements/gcl
/branches/build-improvements/noweb
...
what we should have done is create a new root directory
/trunk
....
/branches/wh-sandbox
...
/branches/build-improvements
...
/extras
/gcl
/noweb
...
That way, it would be possible to avoid having to pull all the
source for gcl and noweb if these are already pre-installed.
\start
Date: Wed, 14 Feb 2007 10:59:50 -0500
From: Bill Page
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb: is it supposed to work?
Cc: Gabriel Dos Reis
Quoting Andrey G. Grozin:
>
> I've installed noweb and did
>
> ./configure --prefix=/usr --infodir=/usr/share/info \
> --mandir=/usr/share/man --without-gcl
>
> (because my external gcl is ansi), then make. After some time, I've got
>
> ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
> '(progn (mapcar (function (lambda (x) (load x))) \
> (quote ( "boothdr.o" "exports.o" "npextras.o"
> "stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
> "stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
> "stage0/tytree1.o"))) \
> (system::save-system "bootsys"))'
>
> Error: The variable |
> | is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by PROGN.
> Broken at MAPCAR. Type :H for Help.
>>>
>
> What should I do next?
>
Here is a patch that I use to solve this problem. It seems that at least
on some platforms, i.e. combinations of shell and/or make, gcl cannot
process the '-batch -eval' arguments in the the way one would expect.
---------
[page@axiom-developer axiom.build-improvements]$ diff -u
src/boot/Makefile.pamp
hlet.orig src/boot/Makefile.pamphlet.new
--- src/boot/Makefile.pamphlet.orig 2007-02-14 09:53:36.000000000 -0600
+++ src/boot/Makefile.pamphlet.new 2007-02-14 09:55:32.000000000 -0600
@@ -1341,10 +1341,10 @@
and saving the resulting image back on disk.
<<build bootsys>>=
bootsys$(EXEEXT): $(OBJECTS)
- $(LOADSYS) -batch -eval \
+ echo \
'(progn (mapcar (function (lambda (x) (load x))) \
(quote ($(patsubst %, "%", $(OBJECTS))))) \
- (system::save-system "$@"))'
+ (system::save-system "$@"))' | $(LOADSYS
@
The make rule [[bootsys]] is executed through a recursive call to [[$(MAKE)]]
\start
Date: Wed, 14 Feb 2007 10:06:27 -0600 (CST)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements without external noweb: is it supposed to work?
| Quoting Andrey G. Grozin:
|
| >
| > I've installed noweb and did
| >
| > ./configure --prefix=/usr --infodir=/usr/share/info \
| > --mandir=/usr/share/man --without-gcl
| >
| > (because my external gcl is ansi), then make. After some time, I've got
| >
| > ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
| > '(progn (mapcar (function (lambda (x) (load x))) \
| > (quote ( "boothdr.o" "exports.o" "npextras.o"
| > "stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
| > "stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
| > "stage0/tytree1.o"))) \
| > (system::save-system "bootsys"))'
| >
| > Error: The variable |
| > | is unbound.
| > Fast links are on: do (si::use-fast-links nil) for debugging
| > Error signalled by PROGN.
| > Broken at MAPCAR. Type :H for Help.
| >>>
| >
| > What should I do next?
| >
|
| Here is a patch that I use to solve this problem. It seems that at least
| on some platforms, i.e. combinations of shell and/or make, gcl cannot
| process the '-batch -eval' arguments in the the way one would expect.
Yes. More curious is that Jacob Smith ran into similar problem on a
Debina based system only for some of the "-batch -eval" things.
:-(
Bill, please could you check in your patch?
\start
Date: Wed, 14 Feb 2007 10:16:51 -0600 (CST)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: gcl and noweb in the build-improvements source tree
On Wed, 14 Feb 2007, Bill Page wrote:
| Gaby, et al.
|
| Every time I download build-improvments on a new machine, I've been
| thinking about the decision to include gcl and noweb source in the
| Axiom source tree (in source format) in the SVN repository at
| SourceForge. It seems to me that rather than having gcl inside the
| tree
|
| /trunk
| ....
| /branches/wh-sandbox
| ...
| /branches/build-improvements
| /branches/build-improvements/gcl
| /branches/build-improvements/noweb
| ...
|
| what we should have done is create a new root directory
|
| /trunk
| ....
| /branches/wh-sandbox
| ...
| /branches/build-improvements
| ...
|
| /extras
| /gcl
| /noweb
| ...
|
| That way, it would be possible to avoid having to pull all the
| source for gcl and noweb if these are already pre-installed.
That is a good alternative.
I would rename /extras to /tools though :-)
The implication though is that when we make a release, we must make
sure gcl and noweb are included. That slightly complicates the logic
of the Makefiles, but it is doable. Also we must watch out that
people don't forget building and testing --without-gcl and
--without-noweb (which will be the common cases).
\start
Date: Wed, 14 Feb 2007 10:47:16 -0600 (CST)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: gcl and noweb in the build-improvements source tree
On Wed, 14 Feb 2007, Bill Page wrote:
| Gaby, et al.
|
| Every time I download build-improvments on a new machine, I've been
| thinking about the decision to include gcl and noweb source in the
| Axiom source tree (in source format) in the SVN repository at
| SourceForge. It seems to me that rather than having gcl inside the
| tree
|
| /trunk
| ....
| /branches/wh-sandbox
| ...
| /branches/build-improvements
| /branches/build-improvements/gcl
| /branches/build-improvements/noweb
| ...
I should probably add that with SVN, it is possible to branch "only"
directories people are interested, not the whole stuff.
\start
Date: Wed, 14 Feb 2007 12:51:57 -0800 (PST)
From: Brent Fulgham
To: Gabriel Dos Reis, Bill Page
Subject: re: gcl and noweb in the build-improvements source tree
> The implication though is that when we make a release, we must make
> sure gcl and noweb are included. That slightly complicates the logic
> of the Makefiles, but it is doable. Also we must watch out that
> people don't forget building and testing --without-gcl and
> --without-noweb (which will be the common cases).
I don't understand why GCL and Noweb are included in the first place.
You don't include AWK/SED, GCC, or a variety of other tools necessary
for building the software.
I suppose for GCL is was necessary, since Axiom might depend on
specifics of the Lisp language supported.
But it seems like making 'noweb' a build requirement might be an
easier approach. And as Axiom migrates to a more ANSI code base you
could remove GCL as well.
\start
Date: Wed, 14 Feb 2007 15:27:37 -0600 (CST)
From: Gabriel Dos Reis
To: Brent Fulgham
Subject: re: gcl and noweb in the build-improvements source tree
On Wed, 14 Feb 2007, Brent Fulgham wrote:
| > The implication though is that when we make a release, we must make
| > sure gcl and noweb are included. That slightly complicates the logic
| > of the Makefiles, but it is doable. Also we must watch out that
| > people don't forget building and testing --without-gcl and
| > --without-noweb (which will be the common cases).
|
| I don't understand why GCL and Noweb are included in the first place.
since this is a recuring discussion, we should probably have an FAQ
entry for it. The archive has some record of the discussion.
| You don't include AWK/SED, GCC, or a variety of other tools
| necessary for building the software.
indeed. Because they are standard tools.
Which distros include noweb and GCL as standard tools?
| I suppose for GCL is was necessary, since Axiom might depend on specifics of the Lisp language supported.
You suppose right.
| But it seems like making 'noweb' a build requirement might be an easier approach. And as Axiom migrates to a more ANSI code base you could remove GCL as well.
I don't think the inclusionof GCL was supposed to be forever. It will
be however necessary, as long as it isn't standard tool.
\start
Date: Thu, 15 Feb 2007 22:55:42 +0100
From: Gregory Vanuxem
To: list
Subject: Lisp format in sf.spad.pamphlet
Hello,
I have introduced two bugs in DFLOAT when I sent a patch against
sf.spad.pamphlet (outputting routine). Try, for example,
complex(1.7,-2.3@SF) or 3.0*x^3+-2.7@SF*x^2. Furthermore, the directive
used ("~G") is not "the" good one (it's not portable, the directive
works this way only on GCL). Patch in attachment (I have used the Float
method (via 'message')).
A suggestion, what about using )spool to produce *.output file?
(to simplify the comparison via diff of two versions of Axiom (different
banners)).
Greg
PS : Tested on Gold and Build-improvements (should work on Wh-sandbox, I
think). My tests were : building from scratch, tracing outputTran and
testing all outputting formats (algebra, fortran, tex etc...).
--- /home/greg/TDevel/cvs/axiom/src/algebra/sf.spad.pamphlet 2006-04-17 08:=
28:41.000000000 +0200
+++ src/algebra/sf.spad.pamphlet 2007-02-14 12:17:59.000000000 +0100
@@ -846,7 +846,7 @@
++ (that is, \spad{|(r-f)/f| < b**(-n)}).
== add
- format: String := "~G"
+ format: String := "~A"
MER ==> Record(MANTISSA:Integer,EXPONENT:Integer)
manexp: % -> MER
@@ -914,7 +914,8 @@
exp1() == FLOAT(534625820200,MOST_-POSITIVE_-LONG_-FLOAT$=
Lisp)$Lisp / FLOAT(196677847971,MOST_-POSITIVE_-LONG_-FLOAT$Lisp)$Lisp
pi() == PI$Lisp
coerce(x:%):OutputForm ==
- outputForm(FORMAT(NIL$Lisp,format,x)$Lisp pretend DoubleFloat)
+ x >= 0 => message(FORMAT(NIL$Lisp,format,x)$Lisp pretend String)
+ - (message(FORMAT(NIL$Lisp,format,-x)$Lisp pretend String))
convert(x:%):InputForm == convert(x pretend DoubleFloat)$InputForm
x < y == (x<y)$Lisp
- x == (-x)$Lisp
@@ -1085,273 +1086,277 @@
<<DFLOAT.lsp BOOTSTRAP>>=
-(|/VERSIONCHECK| 2)
-(DEFUN |DFLOAT;OMwrite;$S;1| (|x| |$|) (PROG (|sp| |dev| |s|) (RETURN (SEQ=
(LETT |s| "" |DFLOAT;OMwrite;$S;1|) (LETT |sp| (|OM-STRINGTOSTRINGPTR| |s|=
) |DFLOAT;OMwrite;$S;1|) (LETT |dev| (SPADCALL |sp| (SPADCALL (QREFELT |$| =
7)) (QREFELT |$| 10)) |DFLOAT;OMwrite;$S;1|) (SPADCALL |dev| (QREFELT |$| 1=
2)) (SPADCALL |dev| |x| (QREFELT |$| 14)) (SPADCALL |dev| (QREFELT |$| 15))=
(SPADCALL |dev| (QREFELT |$| 16)) (LETT |s| (|OM-STRINGPTRTOSTRING| |sp|) =
|DFLOAT;OMwrite;$S;1|) (EXIT |s|)))))
+(/VERSIONCHECK 2)
-(DEFUN |DFLOAT;OMwrite;$BS;2| (|x| |wholeObj| |$|) (PROG (|sp| |dev| |s|) =
(RETURN (SEQ (LETT |s| "" |DFLOAT;OMwrite;$BS;2|) (LETT |sp| (|OM-STRINGTOS=
TRINGPTR| |s|) |DFLOAT;OMwrite;$BS;2|) (LETT |dev| (SPADCALL |sp| (SPADCALL=
(QREFELT |$| 7)) (QREFELT |$| 10)) |DFLOAT;OMwrite;$BS;2|) (COND (|wholeOb=
j| (SPADCALL |dev| (QREFELT |$| 12)))) (SPADCALL |dev| |x| (QREFELT |$| 14)=
) (COND (|wholeObj| (SPADCALL |dev| (QREFELT |$| 15)))) (SPADCALL |dev| (QR=
EFELT |$| 16)) (LETT |s| (|OM-STRINGPTRTOSTRING| |sp|) |DFLOAT;OMwrite;$BS;=
2|) (EXIT |s|)))))
+(DEFUN |DFLOAT;doubleFloatFormat;2S;1| (|s| $) (PROG (|ss|) (RETURN (SEQ (=
LETT |ss| (QREFELT $ 6) |DFLOAT;doubleFloatFormat;2S;1|) (SETELT $ 6 |s|) (=
EXIT |ss|)))))
-(DEFUN |DFLOAT;OMwrite;Omd$V;3| (|dev| |x| |$|) (SEQ (SPADCALL |dev| (QREF=
ELT |$| 12)) (SPADCALL |dev| |x| (QREFELT |$| 14)) (EXIT (SPADCALL |dev| (Q=
REFELT |$| 15)))))
+(DEFUN |DFLOAT;OMwrite;$S;2| (|x| $) (PROG (|sp| |dev| |s|) (RETURN (SEQ (=
LETT |s| "" |DFLOAT;OMwrite;$S;2|) (LETT |sp| (OM-STRINGTOSTRINGPTR |s|) |D=
FLOAT;OMwrite;$S;2|) (LETT |dev| (SPADCALL |sp| (SPADCALL (QREFELT $ 10)) (=
QREFELT $ 12)) |DFLOAT;OMwrite;$S;2|) (SPADCALL |dev| (QREFELT $ 14)) (SPAD=
CALL |dev| |x| (QREFELT $ 16)) (SPADCALL |dev| (QREFELT $ 17)) (SPADCALL |d=
ev| (QREFELT $ 18)) (LETT |s| (OM-STRINGPTRTOSTRING |sp|) |DFLOAT;OMwrite;$=
S;2|) (EXIT |s|)))))
-(DEFUN |DFLOAT;OMwrite;Omd$BV;4| (|dev| |x| |wholeObj| |$|) (SEQ (COND (|w=
holeObj| (SPADCALL |dev| (QREFELT |$| 12)))) (SPADCALL |dev| |x| (QREFELT |=
$| 14)) (EXIT (COND (|wholeObj| (SPADCALL |dev| (QREFELT |$| 15)))))))
+(DEFUN |DFLOAT;OMwrite;$BS;3| (|x| |wholeObj| $) (PROG (|sp| |dev| |s|) (R=
ETURN (SEQ (LETT |s| "" |DFLOAT;OMwrite;$BS;3|) (LETT |sp| (OM-STRINGTOSTRI=
NGPTR |s|) |DFLOAT;OMwrite;$BS;3|) (LETT |dev| (SPADCALL |sp| (SPADCALL (QR=
EFELT $ 10)) (QREFELT $ 12)) |DFLOAT;OMwrite;$BS;3|) (COND (|wholeObj| (SPA=
DCALL |dev| (QREFELT $ 14)))) (SPADCALL |dev| |x| (QREFELT $ 16)) (COND (|w=
holeObj| (SPADCALL |dev| (QREFELT $ 17)))) (SPADCALL |dev| (QREFELT $ 18)) =
(LETT |s| (OM-STRINGPTRTOSTRING |sp|) |DFLOAT;OMwrite;$BS;3|) (EXIT |s|))))=
)
-(PUT (QUOTE |DFLOAT;checkComplex|) (QUOTE |SPADreplace|) (QUOTE |C-TO-R|))=
+(DEFUN |DFLOAT;OMwrite;Omd$V;4| (|dev| |x| $) (SEQ (SPADCALL |dev| (QREFEL=
T $ 14)) (SPADCALL |dev| |x| (QREFELT $ 16)) (EXIT (SPADCALL |dev| (QREFELT=
$ 17)))))
-(DEFUN |DFLOAT;checkComplex| (|x| |$|) (|C-TO-R| |x|))
+(DEFUN |DFLOAT;OMwrite;Omd$BV;5| (|dev| |x| |wholeObj| $) (SEQ (COND (|who=
leObj| (SPADCALL |dev| (QREFELT $ 14)))) (SPADCALL |dev| |x| (QREFELT $ 16)=
) (EXIT (COND (|wholeObj| (SPADCALL |dev| (QREFELT $ 17)))))))
-(PUT (QUOTE |DFLOAT;base;Pi;6|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (|F=
LOAT-RADIX| 0.0))))
+(PUT (QUOTE |DFLOAT;checkComplex|) (QUOTE |SPADreplace|) (QUOTE C-TO-R))
-(DEFUN |DFLOAT;base;Pi;6| (|$|) (|FLOAT-RADIX| 0.0))
+(DEFUN |DFLOAT;checkComplex| (|x| $) (C-TO-R |x|))
-(DEFUN |DFLOAT;mantissa;$I;7| (|x| |$|) (QCAR (|DFLOAT;manexp| |x| |$|)))
+(PUT (QUOTE |DFLOAT;base;Pi;7|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FL=
OAT-RADIX 0.0))))
-(DEFUN |DFLOAT;exponent;$I;8| (|x| |$|) (QCDR (|DFLOAT;manexp| |x| |$|)))
+(DEFUN |DFLOAT;base;Pi;7| ($) (FLOAT-RADIX 0.0))
-(PUT (QUOTE |DFLOAT;precision;Pi;9|) (QUOTE |SPADreplace|) (QUOTE (XLAM NI=
L (|FLOAT-DIGITS| 0.0))))
+(DEFUN |DFLOAT;mantissa;$I;8| (|x| $) (QCAR (|DFLOAT;manexp| |x| $)))
-(DEFUN |DFLOAT;precision;Pi;9| (|$|) (|FLOAT-DIGITS| 0.0))
+(DEFUN |DFLOAT;exponent;$I;9| (|x| $) (QCDR (|DFLOAT;manexp| |x| $)))
-(DEFUN |DFLOAT;bits;Pi;10| (|$|) (PROG (#1=#:G105705) (RETURN (COND ((EQ=
L (|FLOAT-RADIX| 0.0) 2) (|FLOAT-DIGITS| 0.0)) ((EQL (|FLOAT-RADIX| 0.0) 16=
) (|*| 4 (|FLOAT-DIGITS| 0.0))) ((QUOTE T) (PROG1 (LETT #1# (FIX (SPADCALL =
(|FLOAT-DIGITS| 0.0) (SPADCALL (FLOAT (|FLOAT-RADIX| 0.0) |MOST-POSITIVE-LO=
NG-FLOAT|) (QREFELT |$| 28)) (QREFELT |$| 29))) |DFLOAT;bits;Pi;10|) (|chec=
k-subtype| (|>| #1# 0) (QUOTE (|PositiveInteger|)) #1#)))))))
+(PUT (QUOTE |DFLOAT;precision;Pi;10|) (QUOTE |SPADreplace|) (QUOTE (XLAM N=
IL (FLOAT-DIGITS 0.0))))
-(PUT (QUOTE |DFLOAT;max;$;11|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL |MOS=
T-POSITIVE-LONG-FLOAT|)))
+(DEFUN |DFLOAT;precision;Pi;10| ($) (FLOAT-DIGITS 0.0))
-(DEFUN |DFLOAT;max;$;11| (|$|) |MOST-POSITIVE-LONG-FLOAT|)
+(DEFUN |DFLOAT;bits;Pi;11| ($) (PROG (#0=#:G1444) (RETURN (COND ((EQL (F=
LOAT-RADIX 0.0) 2) (FLOAT-DIGITS 0.0)) ((EQL (FLOAT-RADIX 0.0) 16) (* 4 (FL=
OAT-DIGITS 0.0))) ((QUOTE T) (PROG1 (LETT #0# (FIX (SPADCALL (FLOAT-DIGITS =
0.0) (SPADCALL (FLOAT (FLOAT-RADIX 0.0) MOST-POSITIVE-LONG-FLOAT) (QREFELT =
$ 30)) (QREFELT $ 31))) |DFLOAT;bits;Pi;11|) (|check-subtype| (> #0# 0) (QU=
OTE (|PositiveInteger|)) #0#)))))))
-(PUT (QUOTE |DFLOAT;min;$;12|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL |MOS=
T-NEGATIVE-LONG-FLOAT|)))
+(PUT (QUOTE |DFLOAT;max;$;12|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL MOST=
-POSITIVE-LONG-FLOAT)))
-(DEFUN |DFLOAT;min;$;12| (|$|) |MOST-NEGATIVE-LONG-FLOAT|)
+(DEFUN |DFLOAT;max;$;12| ($) MOST-POSITIVE-LONG-FLOAT)
-(DEFUN |DFLOAT;order;$I;13| (|a| |$|) (|-| (|+| (|FLOAT-DIGITS| 0.0) (SPAD=
CALL |a| (QREFELT |$| 26))) 1))
+(PUT (QUOTE |DFLOAT;min;$;13|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL MOST=
-NEGATIVE-LONG-FLOAT)))
-(PUT (QUOTE |DFLOAT;Zero;$;14|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FL=
OAT 0 |MOST-POSITIVE-LONG-FLOAT|))))
+(DEFUN |DFLOAT;min;$;13| ($) MOST-NEGATIVE-LONG-FLOAT)
-(DEFUN |DFLOAT;Zero;$;14| (|$|) (FLOAT 0 |MOST-POSITIVE-LONG-FLOAT|))
+(DEFUN |DFLOAT;order;$I;14| (|a| $) (- (+ (FLOAT-DIGITS 0.0) (SPADCALL |a|=
(QREFELT $ 28))) 1))
-(PUT (QUOTE |DFLOAT;One;$;15|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FLO=
AT 1 |MOST-POSITIVE-LONG-FLOAT|))))
+(PUT (QUOTE |DFLOAT;Zero;$;15|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FL=
OAT 0 MOST-POSITIVE-LONG-FLOAT))))
-(DEFUN |DFLOAT;One;$;15| (|$|) (FLOAT 1 |MOST-POSITIVE-LONG-FLOAT|))
+(DEFUN |DFLOAT;Zero;$;15| ($) (FLOAT 0 MOST-POSITIVE-LONG-FLOAT))
-(DEFUN |DFLOAT;exp1;$;16| (|$|) (|/| (FLOAT 534625820200 |MOST-POSITIVE-LO=
NG-FLOAT|) (FLOAT 196677847971 |MOST-POSITIVE-LONG-FLOAT|)))
+(PUT (QUOTE |DFLOAT;One;$;16|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FLO=
AT 1 MOST-POSITIVE-LONG-FLOAT))))
-(PUT (QUOTE |DFLOAT;pi;$;17|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL PI)))=
+(DEFUN |DFLOAT;One;$;16| ($) (FLOAT 1 MOST-POSITIVE-LONG-FLOAT))
-(DEFUN |DFLOAT;pi;$;17| (|$|) PI)
+(DEFUN |DFLOAT;exp1;$;17| ($) (/ (FLOAT 534625820200 MOST-POSITIVE-LONG-FL=
OAT) (FLOAT 196677847971 MOST-POSITIVE-LONG-FLOAT)))
-(DEFUN |DFLOAT;coerce;$Of;18| (|x| |$|) (SPADCALL |x| (QREFELT |$| 39)))
+(PUT (QUOTE |DFLOAT;pi;$;18|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL PI)))=
-(DEFUN |DFLOAT;convert;$If;19| (|x| |$|) (SPADCALL |x| (QREFELT |$| 42)))
+(DEFUN |DFLOAT;pi;$;18| ($) PI)
-(PUT (QUOTE |DFLOAT;<;2$B;20|) (QUOTE |SPADreplace|) (QUOTE |<|))
+(DEFUN |DFLOAT;coerce;$Of;19| (|x| $) (COND ((< |x| 0.0) (SPADCALL (SPADCA=
LL (FORMAT NIL (QREFELT $ 6) (- |x|)) (QREFELT $ 41)) (QREFELT $ 42))) ((QU=
OTE T) (SPADCALL (FORMAT NIL (QREFELT $ 6) |x|) (QREFELT $ 41)))))
-(DEFUN |DFLOAT;<;2$B;20| (|x| |y| |$|) (|<| |x| |y|))
+(DEFUN |DFLOAT;convert;$If;20| (|x| $) (SPADCALL |x| (QREFELT $ 45)))
-(PUT (QUOTE |DFLOAT;-;2$;21|) (QUOTE |SPADreplace|) (QUOTE |-|))
+(PUT (QUOTE |DFLOAT;<;2$B;21|) (QUOTE |SPADreplace|) (QUOTE <))
-(DEFUN |DFLOAT;-;2$;21| (|x| |$|) (|-| |x|))
+(DEFUN |DFLOAT;<;2$B;21| (|x| |y| $) (< |x| |y|))
-(PUT (QUOTE |DFLOAT;+;3$;22|) (QUOTE |SPADreplace|) (QUOTE |+|))
+(PUT (QUOTE |DFLOAT;-;2$;22|) (QUOTE |SPADreplace|) (QUOTE -))
-(DEFUN |DFLOAT;+;3$;22| (|x| |y| |$|) (|+| |x| |y|))
+(DEFUN |DFLOAT;-;2$;22| (|x| $) (- |x|))
-(PUT (QUOTE |DFLOAT;-;3$;23|) (QUOTE |SPADreplace|) (QUOTE |-|))
+(PUT (QUOTE |DFLOAT;+;3$;23|) (QUOTE |SPADreplace|) (QUOTE +))
-(DEFUN |DFLOAT;-;3$;23| (|x| |y| |$|) (|-| |x| |y|))
+(DEFUN |DFLOAT;+;3$;23| (|x| |y| $) (+ |x| |y|))
-(PUT (QUOTE |DFLOAT;*;3$;24|) (QUOTE |SPADreplace|) (QUOTE |*|))
+(PUT (QUOTE |DFLOAT;-;3$;24|) (QUOTE |SPADreplace|) (QUOTE -))
-(DEFUN |DFLOAT;*;3$;24| (|x| |y| |$|) (|*| |x| |y|))
+(DEFUN |DFLOAT;-;3$;24| (|x| |y| $) (- |x| |y|))
-(PUT (QUOTE |DFLOAT;*;I2$;25|) (QUOTE |SPADreplace|) (QUOTE |*|))
+(PUT (QUOTE |DFLOAT;*;3$;25|) (QUOTE |SPADreplace|) (QUOTE *))
-(DEFUN |DFLOAT;*;I2$;25| (|i| |x| |$|) (|*| |i| |x|))
+(DEFUN |DFLOAT;*;3$;25| (|x| |y| $) (* |x| |y|))
-(PUT (QUOTE |DFLOAT;max;3$;26|) (QUOTE |SPADreplace|) (QUOTE MAX))
+(PUT (QUOTE |DFLOAT;*;I2$;26|) (QUOTE |SPADreplace|) (QUOTE *))
-(DEFUN |DFLOAT;max;3$;26| (|x| |y| |$|) (MAX |x| |y|))
+(DEFUN |DFLOAT;*;I2$;26| (|i| |x| $) (* |i| |x|))
-(PUT (QUOTE |DFLOAT;min;3$;27|) (QUOTE |SPADreplace|) (QUOTE MIN))
+(PUT (QUOTE |DFLOAT;max;3$;27|) (QUOTE |SPADreplace|) (QUOTE MAX))
-(DEFUN |DFLOAT;min;3$;27| (|x| |y| |$|) (MIN |x| |y|))
+(DEFUN |DFLOAT;max;3$;27| (|x| |y| $) (MAX |x| |y|))
-(PUT (QUOTE |DFLOAT;=;2$B;28|) (QUOTE |SPADreplace|) (QUOTE |=|))
+(PUT (QUOTE |DFLOAT;min;3$;28|) (QUOTE |SPADreplace|) (QUOTE MIN))
-(DEFUN |DFLOAT;=;2$B;28| (|x| |y| |$|) (|=| |x| |y|))
+(DEFUN |DFLOAT;min;3$;28| (|x| |y| $) (MIN |x| |y|))
-(PUT (QUOTE |DFLOAT;/;$I$;29|) (QUOTE |SPADreplace|) (QUOTE |/|))
+(PUT (QUOTE |DFLOAT;=;2$B;29|) (QUOTE |SPADreplace|) (QUOTE =))
-(DEFUN |DFLOAT;/;$I$;29| (|x| |i| |$|) (|/| |x| |i|))
+(DEFUN |DFLOAT;=;2$B;29| (|x| |y| $) (= |x| |y|))
-(DEFUN |DFLOAT;sqrt;2$;30| (|x| |$|) (|DFLOAT;checkComplex| (SQRT |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;/;$I$;30|) (QUOTE |SPADreplace|) (QUOTE /))
-(DEFUN |DFLOAT;log10;2$;31| (|x| |$|) (|DFLOAT;checkComplex| (|log| |x|) |=
$|))
+(DEFUN |DFLOAT;/;$I$;30| (|x| |i| $) (/ |x| |i|))
-(PUT (QUOTE |DFLOAT;**;$I$;32|) (QUOTE |SPADreplace|) (QUOTE EXPT))
+(DEFUN |DFLOAT;sqrt;2$;31| (|x| $) (|DFLOAT;checkComplex| (SQRT |x|) $))
-(DEFUN |DFLOAT;**;$I$;32| (|x| |i| |$|) (EXPT |x| |i|))
+(DEFUN |DFLOAT;log10;2$;32| (|x| $) (|DFLOAT;checkComplex| (|log| |x|) $))=
-(DEFUN |DFLOAT;**;3$;33| (|x| |y| |$|) (|DFLOAT;checkComplex| (EXPT |x| |y=
|) |$|))
+(PUT (QUOTE |DFLOAT;**;$I$;33|) (QUOTE |SPADreplace|) (QUOTE EXPT))
-(PUT (QUOTE |DFLOAT;coerce;I$;34|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|i|=
) (FLOAT |i| |MOST-POSITIVE-LONG-FLOAT|))))
+(DEFUN |DFLOAT;**;$I$;33| (|x| |i| $) (EXPT |x| |i|))
-(DEFUN |DFLOAT;coerce;I$;34| (|i| |$|) (FLOAT |i| |MOST-POSITIVE-LONG-FLOA=
T|))
+(DEFUN |DFLOAT;**;3$;34| (|x| |y| $) (|DFLOAT;checkComplex| (EXPT |x| |y|)=
$))
-(PUT (QUOTE |DFLOAT;exp;2$;35|) (QUOTE |SPADreplace|) (QUOTE EXP))
+(PUT (QUOTE |DFLOAT;coerce;I$;35|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|i|=
) (FLOAT |i| MOST-POSITIVE-LONG-FLOAT))))
-(DEFUN |DFLOAT;exp;2$;35| (|x| |$|) (EXP |x|))
+(DEFUN |DFLOAT;coerce;I$;35| (|i| $) (FLOAT |i| MOST-POSITIVE-LONG-FLOAT))=
-(DEFUN |DFLOAT;log;2$;36| (|x| |$|) (|DFLOAT;checkComplex| (LN |x|) |$|))
+(PUT (QUOTE |DFLOAT;exp;2$;36|) (QUOTE |SPADreplace|) (QUOTE EXP))
-(DEFUN |DFLOAT;log2;2$;37| (|x| |$|) (|DFLOAT;checkComplex| (LOG2 |x|) |$|=
))
+(DEFUN |DFLOAT;exp;2$;36| (|x| $) (EXP |x|))
-(PUT (QUOTE |DFLOAT;sin;2$;38|) (QUOTE |SPADreplace|) (QUOTE SIN))
+(DEFUN |DFLOAT;log;2$;37| (|x| $) (|DFLOAT;checkComplex| (LN |x|) $))
-(DEFUN |DFLOAT;sin;2$;38| (|x| |$|) (SIN |x|))
+(DEFUN |DFLOAT;log2;2$;38| (|x| $) (|DFLOAT;checkComplex| (LOG2 |x|) $))
-(PUT (QUOTE |DFLOAT;cos;2$;39|) (QUOTE |SPADreplace|) (QUOTE COS))
+(PUT (QUOTE |DFLOAT;sin;2$;39|) (QUOTE |SPADreplace|) (QUOTE SIN))
-(DEFUN |DFLOAT;cos;2$;39| (|x| |$|) (COS |x|))
+(DEFUN |DFLOAT;sin;2$;39| (|x| $) (SIN |x|))
-(PUT (QUOTE |DFLOAT;tan;2$;40|) (QUOTE |SPADreplace|) (QUOTE TAN))
+(PUT (QUOTE |DFLOAT;cos;2$;40|) (QUOTE |SPADreplace|) (QUOTE COS))
-(DEFUN |DFLOAT;tan;2$;40| (|x| |$|) (TAN |x|))
+(DEFUN |DFLOAT;cos;2$;40| (|x| $) (COS |x|))
-(PUT (QUOTE |DFLOAT;cot;2$;41|) (QUOTE |SPADreplace|) (QUOTE COT))
+(PUT (QUOTE |DFLOAT;tan;2$;41|) (QUOTE |SPADreplace|) (QUOTE TAN))
-(DEFUN |DFLOAT;cot;2$;41| (|x| |$|) (COT |x|))
+(DEFUN |DFLOAT;tan;2$;41| (|x| $) (TAN |x|))
-(PUT (QUOTE |DFLOAT;sec;2$;42|) (QUOTE |SPADreplace|) (QUOTE SEC))
+(PUT (QUOTE |DFLOAT;cot;2$;42|) (QUOTE |SPADreplace|) (QUOTE COT))
-(DEFUN |DFLOAT;sec;2$;42| (|x| |$|) (SEC |x|))
+(DEFUN |DFLOAT;cot;2$;42| (|x| $) (COT |x|))
-(PUT (QUOTE |DFLOAT;csc;2$;43|) (QUOTE |SPADreplace|) (QUOTE CSC))
+(PUT (QUOTE |DFLOAT;sec;2$;43|) (QUOTE |SPADreplace|) (QUOTE SEC))
-(DEFUN |DFLOAT;csc;2$;43| (|x| |$|) (CSC |x|))
+(DEFUN |DFLOAT;sec;2$;43| (|x| $) (SEC |x|))
-(DEFUN |DFLOAT;asin;2$;44| (|x| |$|) (|DFLOAT;checkComplex| (ASIN |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;csc;2$;44|) (QUOTE |SPADreplace|) (QUOTE CSC))
-(DEFUN |DFLOAT;acos;2$;45| (|x| |$|) (|DFLOAT;checkComplex| (ACOS |x|) |$|=
))
+(DEFUN |DFLOAT;csc;2$;44| (|x| $) (CSC |x|))
-(PUT (QUOTE |DFLOAT;atan;2$;46|) (QUOTE |SPADreplace|) (QUOTE ATAN))
+(DEFUN |DFLOAT;asin;2$;45| (|x| $) (|DFLOAT;checkComplex| (ASIN |x|) $))
-(DEFUN |DFLOAT;atan;2$;46| (|x| |$|) (ATAN |x|))
+(DEFUN |DFLOAT;acos;2$;46| (|x| $) (|DFLOAT;checkComplex| (ACOS |x|) $))
-(DEFUN |DFLOAT;acsc;2$;47| (|x| |$|) (|DFLOAT;checkComplex| (ACSC |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;atan;2$;47|) (QUOTE |SPADreplace|) (QUOTE ATAN))
-(PUT (QUOTE |DFLOAT;acot;2$;48|) (QUOTE |SPADreplace|) (QUOTE ACOT))
+(DEFUN |DFLOAT;atan;2$;47| (|x| $) (ATAN |x|))
-(DEFUN |DFLOAT;acot;2$;48| (|x| |$|) (ACOT |x|))
+(DEFUN |DFLOAT;acsc;2$;48| (|x| $) (|DFLOAT;checkComplex| (ACSC |x|) $))
-(DEFUN |DFLOAT;asec;2$;49| (|x| |$|) (|DFLOAT;checkComplex| (ASEC |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;acot;2$;49|) (QUOTE |SPADreplace|) (QUOTE ACOT))
-(PUT (QUOTE |DFLOAT;sinh;2$;50|) (QUOTE |SPADreplace|) (QUOTE SINH))
+(DEFUN |DFLOAT;acot;2$;49| (|x| $) (ACOT |x|))
-(DEFUN |DFLOAT;sinh;2$;50| (|x| |$|) (SINH |x|))
+(DEFUN |DFLOAT;asec;2$;50| (|x| $) (|DFLOAT;checkComplex| (ASEC |x|) $))
-(PUT (QUOTE |DFLOAT;cosh;2$;51|) (QUOTE |SPADreplace|) (QUOTE COSH))
+(PUT (QUOTE |DFLOAT;sinh;2$;51|) (QUOTE |SPADreplace|) (QUOTE SINH))
-(DEFUN |DFLOAT;cosh;2$;51| (|x| |$|) (COSH |x|))
+(DEFUN |DFLOAT;sinh;2$;51| (|x| $) (SINH |x|))
-(PUT (QUOTE |DFLOAT;tanh;2$;52|) (QUOTE |SPADreplace|) (QUOTE TANH))
+(PUT (QUOTE |DFLOAT;cosh;2$;52|) (QUOTE |SPADreplace|) (QUOTE COSH))
-(DEFUN |DFLOAT;tanh;2$;52| (|x| |$|) (TANH |x|))
+(DEFUN |DFLOAT;cosh;2$;52| (|x| $) (COSH |x|))
-(PUT (QUOTE |DFLOAT;csch;2$;53|) (QUOTE |SPADreplace|) (QUOTE CSCH))
+(PUT (QUOTE |DFLOAT;tanh;2$;53|) (QUOTE |SPADreplace|) (QUOTE TANH))
-(DEFUN |DFLOAT;csch;2$;53| (|x| |$|) (CSCH |x|))
+(DEFUN |DFLOAT;tanh;2$;53| (|x| $) (TANH |x|))
-(PUT (QUOTE |DFLOAT;coth;2$;54|) (QUOTE |SPADreplace|) (QUOTE COTH))
+(PUT (QUOTE |DFLOAT;csch;2$;54|) (QUOTE |SPADreplace|) (QUOTE CSCH))
-(DEFUN |DFLOAT;coth;2$;54| (|x| |$|) (COTH |x|))
+(DEFUN |DFLOAT;csch;2$;54| (|x| $) (CSCH |x|))
-(PUT (QUOTE |DFLOAT;sech;2$;55|) (QUOTE |SPADreplace|) (QUOTE SECH))
+(PUT (QUOTE |DFLOAT;coth;2$;55|) (QUOTE |SPADreplace|) (QUOTE COTH))
-(DEFUN |DFLOAT;sech;2$;55| (|x| |$|) (SECH |x|))
+(DEFUN |DFLOAT;coth;2$;55| (|x| $) (COTH |x|))
-(PUT (QUOTE |DFLOAT;asinh;2$;56|) (QUOTE |SPADreplace|) (QUOTE ASINH))
+(PUT (QUOTE |DFLOAT;sech;2$;56|) (QUOTE |SPADreplace|) (QUOTE SECH))
-(DEFUN |DFLOAT;asinh;2$;56| (|x| |$|) (ASINH |x|))
+(DEFUN |DFLOAT;sech;2$;56| (|x| $) (SECH |x|))
-(DEFUN |DFLOAT;acosh;2$;57| (|x| |$|) (|DFLOAT;checkComplex| (ACOSH |x|) |=
$|))
+(PUT (QUOTE |DFLOAT;asinh;2$;57|) (QUOTE |SPADreplace|) (QUOTE ASINH))
-(DEFUN |DFLOAT;atanh;2$;58| (|x| |$|) (|DFLOAT;checkComplex| (ATANH |x|) |=
$|))
+(DEFUN |DFLOAT;asinh;2$;57| (|x| $) (ASINH |x|))
-(PUT (QUOTE |DFLOAT;acsch;2$;59|) (QUOTE |SPADreplace|) (QUOTE ACSCH))
+(DEFUN |DFLOAT;acosh;2$;58| (|x| $) (|DFLOAT;checkComplex| (ACOSH |x|) $))=
-(DEFUN |DFLOAT;acsch;2$;59| (|x| |$|) (ACSCH |x|))
+(DEFUN |DFLOAT;atanh;2$;59| (|x| $) (|DFLOAT;checkComplex| (ATANH |x|) $))=
-(DEFUN |DFLOAT;acoth;2$;60| (|x| |$|) (|DFLOAT;checkComplex| (ACOTH |x|) |=
$|))
+(PUT (QUOTE |DFLOAT;acsch;2$;60|) (QUOTE |SPADreplace|) (QUOTE ACSCH))
-(DEFUN |DFLOAT;asech;2$;61| (|x| |$|) (|DFLOAT;checkComplex| (ASECH |x|) |=
$|))
+(DEFUN |DFLOAT;acsch;2$;60| (|x| $) (ACSCH |x|))
-(PUT (QUOTE |DFLOAT;/;3$;62|) (QUOTE |SPADreplace|) (QUOTE |/|))
+(DEFUN |DFLOAT;acoth;2$;61| (|x| $) (|DFLOAT;checkComplex| (ACOTH |x|) $))=
-(DEFUN |DFLOAT;/;3$;62| (|x| |y| |$|) (|/| |x| |y|))
+(DEFUN |DFLOAT;asech;2$;62| (|x| $) (|DFLOAT;checkComplex| (ASECH |x|) $))=
-(PUT (QUOTE |DFLOAT;negative?;$B;63|) (QUOTE |SPADreplace|) (QUOTE MINUSP)=
)
+(PUT (QUOTE |DFLOAT;/;3$;63|) (QUOTE |SPADreplace|) (QUOTE /))
-(DEFUN |DFLOAT;negative?;$B;63| (|x| |$|) (MINUSP |x|))
+(DEFUN |DFLOAT;/;3$;63| (|x| |y| $) (/ |x| |y|))
-(PUT (QUOTE |DFLOAT;zero?;$B;64|) (QUOTE |SPADreplace|) (QUOTE ZEROP))
+(PUT (QUOTE |DFLOAT;negative?;$B;64|) (QUOTE |SPADreplace|) (QUOTE MINUSP)=
)
-(DEFUN |DFLOAT;zero?;$B;64| (|x| |$|) (ZEROP |x|))
+(DEFUN |DFLOAT;negative?;$B;64| (|x| $) (MINUSP |x|))
-(PUT (QUOTE |DFLOAT;hash;$I;65|) (QUOTE |SPADreplace|) (QUOTE HASHEQ))
+(PUT (QUOTE |DFLOAT;zero?;$B;65|) (QUOTE |SPADreplace|) (QUOTE ZEROP))
-(DEFUN |DFLOAT;hash;$I;65| (|x| |$|) (HASHEQ |x|))
+(DEFUN |DFLOAT;zero?;$B;65| (|x| $) (ZEROP |x|))
-(DEFUN |DFLOAT;recip;$U;66| (|x| |$|) (COND ((ZEROP |x|) (CONS 1 "failed")=
) ((QUOTE T) (CONS 0 (|/| 1.0 |x|)))))
+(PUT (QUOTE |DFLOAT;hash;$I;66|) (QUOTE |SPADreplace|) (QUOTE HASHEQ))
-(PUT (QUOTE |DFLOAT;differentiate;2$;67|) (QUOTE |SPADreplace|) (QUOTE (XL=
AM (|x|) 0.0)))
+(DEFUN |DFLOAT;hash;$I;66| (|x| $) (HASHEQ |x|))
-(DEFUN |DFLOAT;differentiate;2$;67| (|x| |$|) 0.0)
+(DEFUN |DFLOAT;recip;$U;67| (|x| $) (COND ((ZEROP |x|) (CONS 1 "failed")) =
((QUOTE T) (CONS 0 (/ 1.0 |x|)))))
-(DEFUN |DFLOAT;Gamma;2$;68| (|x| |$|) (SPADCALL |x| (QREFELT |$| 93)))
+(PUT (QUOTE |DFLOAT;differentiate;2$;68|) (QUOTE |SPADreplace|) (QUOTE (XL=
AM (|x|) 0.0)))
-(DEFUN |DFLOAT;Beta;3$;69| (|x| |y| |$|) (SPADCALL |x| |y| (QREFELT |$| 95=
)))
+(DEFUN |DFLOAT;differentiate;2$;68| (|x| $) 0.0)
-(PUT (QUOTE |DFLOAT;wholePart;$I;70|) (QUOTE |SPADreplace|) (QUOTE FIX))
+(DEFUN |DFLOAT;Gamma;2$;69| (|x| $) (SPADCALL |x| (QREFELT $ 96)))
-(DEFUN |DFLOAT;wholePart;$I;70| (|x| |$|) (FIX |x|))
+(DEFUN |DFLOAT;Beta;3$;70| (|x| |y| $) (SPADCALL |x| |y| (QREFELT $ 98)))
-(DEFUN |DFLOAT;float;2IPi$;71| (|ma| |ex| |b| |$|) (|*| |ma| (EXPT (FLOAT =
|b| |MOST-POSITIVE-LONG-FLOAT|) |ex|)))
+(PUT (QUOTE |DFLOAT;wholePart;$I;71|) (QUOTE |SPADreplace|) (QUOTE FIX))
-(PUT (QUOTE |DFLOAT;convert;2$;72|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x=
|) |x|)))
+(DEFUN |DFLOAT;wholePart;$I;71| (|x| $) (FIX |x|))
-(DEFUN |DFLOAT;convert;2$;72| (|x| |$|) |x|)
+(DEFUN |DFLOAT;float;2IPi$;72| (|ma| |ex| |b| $) (* |ma| (EXPT (FLOAT |b| =
MOST-POSITIVE-LONG-FLOAT) |ex|)))
-(DEFUN |DFLOAT;convert;$F;73| (|x| |$|) (SPADCALL |x| (QREFELT |$| 101)))
+(PUT (QUOTE |DFLOAT;convert;2$;73|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x=
|) |x|)))
-(DEFUN |DFLOAT;rationalApproximation;$NniF;74| (|x| |d| |$|) (SPADCALL |x|=
|d| 10 (QREFELT |$| 105)))
+(DEFUN |DFLOAT;convert;2$;73| (|x| $) |x|)
-(DEFUN |DFLOAT;atan;3$;75| (|x| |y| |$|) (PROG (|theta|) (RETURN (SEQ (CON=
D ((|=| |x| 0.0) (COND ((|<| 0.0 |y|) (|/| PI 2)) ((|<| |y| 0.0) (|-| (|/=
| PI 2))) ((QUOTE T) 0.0))) ((QUOTE T) (SEQ (LETT |theta| (ATAN (|FLOAT-SIG=
N| 1.0 (|/| |y| |x|))) |DFLOAT;atan;3$;75|) (COND ((|<| |x| 0.0) (LETT |the=
ta| (|-| PI |theta|) |DFLOAT;atan;3$;75|))) (COND ((|<| |y| 0.0) (LETT |the=
ta| (|-| |theta|) |DFLOAT;atan;3$;75|))) (EXIT |theta|))))))))
+(DEFUN |DFLOAT;convert;$F;74| (|x| $) (SPADCALL |x| (QREFELT $ 104)))
-(DEFUN |DFLOAT;retract;$F;76| (|x| |$|) (PROG (#1=#:G105780) (RETURN (SP=
ADCALL |x| (PROG1 (LETT #1# (|-| (|FLOAT-DIGITS| 0.0) 1) |DFLOAT;retract;$F=
;76|) (|check-subtype| (|>=| #1# 0) (QUOTE (|NonNegativeInteger|)) #1#)) =
(|FLOAT-RADIX| 0.0) (QREFELT |$| 105)))))
+(DEFUN |DFLOAT;rationalApproximation;$NniF;75| (|x| |d| $) (SPADCALL |x| |=
d| 10 (QREFELT $ 108)))
-(DEFUN |DFLOAT;retractIfCan;$U;77| (|x| |$|) (PROG (#1=#:G105785) (RETUR=
N (CONS 0 (SPADCALL |x| (PROG1 (LETT #1# (|-| (|FLOAT-DIGITS| 0.0) 1) |DFLO=
AT;retractIfCan;$U;77|) (|check-subtype| (|>=| #1# 0) (QUOTE (|NonNegativ=
eInteger|)) #1#)) (|FLOAT-RADIX| 0.0) (QREFELT |$| 105))))))
+(DEFUN |DFLOAT;atan;3$;76| (|x| |y| $) (PROG (|theta|) (RETURN (SEQ (COND =
((= |x| 0.0) (COND ((< 0.0 |y|) (/ PI 2)) ((< |y| 0.0) (- (/ PI 2))) ((QU=
OTE T) 0.0))) ((QUOTE T) (SEQ (LETT |theta| (ATAN (FLOAT-SIGN 1.0 (/ |y| |x=
|))) |DFLOAT;atan;3$;76|) (COND ((< |x| 0.0) (LETT |theta| (- PI |theta|) |=
DFLOAT;atan;3$;76|))) (COND ((< |y| 0.0) (LETT |theta| (- |theta|) |DFLOAT;=
atan;3$;76|))) (EXIT |theta|))))))))
-(DEFUN |DFLOAT;retract;$I;78| (|x| |$|) (PROG (|n|) (RETURN (SEQ (LETT |n|=
(FIX |x|) |DFLOAT;retract;$I;78|) (EXIT (COND ((|=| |x| (FLOAT |n| |MOST=
-POSITIVE-LONG-FLOAT|)) |n|) ((QUOTE T) (|error| "Not an integer"))))))))
+(DEFUN |DFLOAT;retract;$F;77| (|x| $) (PROG (#0=#:G1519) (RETURN (SPADCA=
LL |x| (PROG1 (LETT #0# (- (FLOAT-DIGITS 0.0) 1) |DFLOAT;retract;$F;77|) (|=
check-subtype| (>= #0# 0) (QUOTE (|NonNegativeInteger|)) #0#)) (FLOAT-RAD=
IX 0.0) (QREFELT $ 108)))))
-(DEFUN |DFLOAT;retractIfCan;$U;79| (|x| |$|) (PROG (|n|) (RETURN (SEQ (LET=
T |n| (FIX |x|) |DFLOAT;retractIfCan;$U;79|) (EXIT (COND ((|=| |x| (FLOAT=
|n| |MOST-POSITIVE-LONG-FLOAT|)) (CONS 0 |n|)) ((QUOTE T) (CONS 1 "failed"=
))))))))
+(DEFUN |DFLOAT;retractIfCan;$U;78| (|x| $) (PROG (#0=#:G1524) (RETURN (C=
ONS 0 (SPADCALL |x| (PROG1 (LETT #0# (- (FLOAT-DIGITS 0.0) 1) |DFLOAT;retra=
ctIfCan;$U;78|) (|check-subtype| (>= #0# 0) (QUOTE (|NonNegativeInteger|)=
) #0#)) (FLOAT-RADIX 0.0) (QREFELT $ 108))))))
-(DEFUN |DFLOAT;sign;$I;80| (|x| |$|) (SPADCALL (|FLOAT-SIGN| |x| 1.0) (QRE=
FELT |$| 111)))
+(DEFUN |DFLOAT;retract;$I;79| (|x| $) (PROG (|n|) (RETURN (SEQ (LETT |n| (=
FIX |x|) |DFLOAT;retract;$I;79|) (EXIT (COND ((= |x| (FLOAT |n| MOST-POSI=
TIVE-LONG-FLOAT)) |n|) ((QUOTE T) (|error| "Not an integer"))))))))
-(PUT (QUOTE |DFLOAT;abs;2$;81|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x|) (=
|FLOAT-SIGN| 1.0 |x|))))
+(DEFUN |DFLOAT;retractIfCan;$U;80| (|x| $) (PROG (|n|) (RETURN (SEQ (LETT =
|n| (FIX |x|) |DFLOAT;retractIfCan;$U;80|) (EXIT (COND ((= |x| (FLOAT |n|=
MOST-POSITIVE-LONG-FLOAT)) (CONS 0 |n|)) ((QUOTE T) (CONS 1 "failed"))))))=
))
-(DEFUN |DFLOAT;abs;2$;81| (|x| |$|) (|FLOAT-SIGN| 1.0 |x|))
+(DEFUN |DFLOAT;sign;$I;81| (|x| $) (SPADCALL (FLOAT-SIGN |x| 1.0) (QREFELT=
$ 114)))
-(DEFUN |DFLOAT;manexp| (|x| |$|) (PROG (|s| #1=#:G105806 |me| |two53|) (=
RETURN (SEQ (EXIT (COND ((ZEROP |x|) (CONS 0 0)) ((QUOTE T) (SEQ (LETT |s| =
(SPADCALL |x| (QREFELT |$| 114)) |DFLOAT;manexp|) (LETT |x| (|FLOAT-SIGN| 1=
.0 |x|) |DFLOAT;manexp|) (COND ((|<| |MOST-POSITIVE-LONG-FLOAT| |x|) (PROGN=
(LETT #1# (CONS (|+| (|*| |s| (SPADCALL |MOST-POSITIVE-LONG-FLOAT| (QREFEL=
T |$| 25))) 1) (SPADCALL |MOST-POSITIVE-LONG-FLOAT| (QREFELT |$| 26))) |DFL=
OAT;manexp|) (GO #1#)))) (LETT |me| (MANEXP |x|) |DFLOAT;manexp|) (LETT |tw=
o53| (EXPT (|FLOAT-RADIX| 0.0) (|FLOAT-DIGITS| 0.0)) |DFLOAT;manexp|) (EXIT=
(CONS (|*| |s| (FIX (|*| |two53| (QCAR |me|)))) (|-| (QCDR |me|) (|FLOAT-D=
IGITS| 0.0)))))))) #1# (EXIT #1#)))))
+(PUT (QUOTE |DFLOAT;abs;2$;82|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x|) (=
FLOAT-SIGN 1.0 |x|))))
-(DEFUN |DFLOAT;rationalApproximation;$2NniF;83| (|f| |d| |b| |$|) (PROG (|=
#G102| |nu| |ex| BASE #1=#:G105809 |de| |tol| |#G103| |q| |r| |p2| |q2| #=
2=#:G105827 |#G104| |#G105| |p0| |p1| |#G106| |#G107| |q0| |q1| |#G108| |=
#G109| |s| |t| #3=#:G105825) (RETURN (SEQ (EXIT (SEQ (PROGN (LETT |#G102|=
(|DFLOAT;manexp| |f| |$|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT =
|nu| (QCAR |#G102|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |ex| (Q=
CDR |#G102|) |DFLOAT;rationalApproximation;$2NniF;83|) |#G102|) (LETT BASE =
(|FLOAT-RADIX| 0.0) |DFLOAT;rationalApproximation;$2NniF;83|) (EXIT (COND (=
(|<| |ex| 0) (SEQ (LETT |de| (EXPT BASE (PROG1 (LETT #1# (|-| |ex|) |DFLOAT=
;rationalApproximation;$2NniF;83|) (|check-subtype| (|>=| #1# 0) (QUOTE (=
|NonNegativeInteger|)) #1#))) |DFLOAT;rationalApproximation;$2NniF;83|) (EX=
IT (COND ((|<| |b| 2) (|error| "base must be > 1")) ((QUOTE T) (SEQ (LETT |=
tol| (EXPT |b| |d|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |s| |nu=
| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |t| |de| |DFLOAT;rational=
Approximation;$2NniF;83|) (LETT |p0| 0 |DFLOAT;rationalApproximation;$2NniF=
;83|) (LETT |p1| 1 |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q0| 1 |=
DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q1| 0 |DFLOAT;rationalAppro=
ximation;$2NniF;83|) (EXIT (SEQ G190 NIL (SEQ (PROGN (LETT |#G103| (DIVIDE2=
|s| |t|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q| (QCAR |#G103|=
) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |r| (QCDR |#G103|) |DFLOA=
T;rationalApproximation;$2NniF;83|) |#G103|) (LETT |p2| (|+| (|*| |q| |p1|)=
|p0|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q2| (|+| (|*| |q| |=
q1|) |q0|) |DFLOAT;rationalApproximation;$2NniF;83|) (COND ((OR (EQL |r| 0)=
(|<| (SPADCALL |tol| (ABS (|-| (|*| |nu| |q2|) (|*| |de| |p2|))) (QREFELT =
|$| 118)) (|*| |de| (ABS |p2|)))) (EXIT (PROGN (LETT #2# (SPADCALL |p2| |q2=
| (QREFELT |$| 117)) |DFLOAT;rationalApproximation;$2NniF;83|) (GO #2#)))))=
(PROGN (LETT |#G104| |p1| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT =
|#G105| |p2| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |p0| |#G104| |=
DFLOAT;rationalApproximation;$2NniF;83|) (LETT |p1| |#G105| |DFLOAT;rationa=
lApproximation;$2NniF;83|)) (PROGN (LETT |#G106| |q1| |DFLOAT;rationalAppro=
ximation;$2NniF;83|) (LETT |#G107| |q2| |DFLOAT;rationalApproximation;$2Nni=
F;83|) (LETT |q0| |#G106| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |=
q1| |#G107| |DFLOAT;rationalApproximation;$2NniF;83|)) (EXIT (PROGN (LETT |=
#G108| |t| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |#G109| |r| |DFL=
OAT;rationalApproximation;$2NniF;83|) (LETT |s| |#G108| |DFLOAT;rationalApp=
roximation;$2NniF;83|) (LETT |t| |#G109| |DFLOAT;rationalApproximation;$2Nn=
iF;83|)))) NIL (GO G190) G191 (EXIT NIL))))))))) ((QUOTE T) (SPADCALL (|*| =
|nu| (EXPT BASE (PROG1 (LETT #3# |ex| |DFLOAT;rationalApproximation;$2NniF;=
83|) (|check-subtype| (|>=| #3# 0) (QUOTE (|NonNegativeInteger|)) #3#))))=
(QREFELT |$| 119))))))) #2# (EXIT #2#)))))
+(DEFUN |DFLOAT;abs;2$;82| (|x| $) (FLOAT-SIGN 1.0 |x|))
-(DEFUN |DFLOAT;**;$F$;84| (|x| |r| |$|) (PROG (|n| |d| #1=#:G105837) (RE=
TURN (SEQ (EXIT (COND ((ZEROP |x|) (COND ((SPADCALL |r| (QREFELT |$| 120)) =
(|error| "0**0 is undefined")) ((SPADCALL |r| (QREFELT |$| 121)) (|error| "=
division by 0")) ((QUOTE T) 0.0))) ((OR (SPADCALL |r| (QREFELT |$| 120)) (S=
PADCALL |x| (QREFELT |$| 122))) 1.0) ((QUOTE T) (COND ((SPADCALL |r| (QREFE=
LT |$| 123)) |x|) ((QUOTE T) (SEQ (LETT |n| (SPADCALL |r| (QREFELT |$| 124)=
) |DFLOAT;**;$F$;84|) (LETT |d| (SPADCALL |r| (QREFELT |$| 125)) |DFLOAT;**=
;$F$;84|) (EXIT (COND ((MINUSP |x|) (COND ((ODDP |d|) (COND ((ODDP |n|) (PR=
OGN (LETT #1# (|-| (SPADCALL (|-| |x|) |r| (QREFELT |$| 126))) |DFLOAT;**;$=
F$;84|) (GO #1#))) ((QUOTE T) (PROGN (LETT #1# (SPADCALL (|-| |x|) |r| (QRE=
FELT |$| 126)) |DFLOAT;**;$F$;84|) (GO #1#))))) ((QUOTE T) (|error| "negati=
ve root")))) ((EQL |d| 2) (EXPT (SPADCALL |x| (QREFELT |$| 54)) |n|)) ((QUO=
TE T) (SPADCALL |x| (|/| (FLOAT |n| |MOST-POSITIVE-LONG-FLOAT|) (FLOAT |d| =
|MOST-POSITIVE-LONG-FLOAT|)) (QREFELT |$| 57))))))))))) #1# (EXIT #1#)))))
+(DEFUN |DFLOAT;manexp| (|x| $) (PROG (|s| #0=#:G1545 |me| |two53|) (RETU=
RN (SEQ (EXIT (COND ((ZEROP |x|) (CONS 0 0)) ((QUOTE T) (SEQ (LETT |s| (SPA=
DCALL |x| (QREFELT $ 117)) |DFLOAT;manexp|) (LETT |x| (FLOAT-SIGN 1.0 |x|) =
|DFLOAT;manexp|) (COND ((< MOST-POSITIVE-LONG-FLOAT |x|) (PROGN (LETT #0# (=
CONS (+ (* |s| (SPADCALL MOST-POSITIVE-LONG-FLOAT (QREFELT $ 27))) 1) (SPAD=
CALL MOST-POSITIVE-LONG-FLOAT (QREFELT $ 28))) |DFLOAT;manexp|) (GO #0#))))=
(LETT |me| (MANEXP |x|) |DFLOAT;manexp|) (LETT |two53| (EXPT (FLOAT-RADIX =
0.0) (FLOAT-DIGITS 0.0)) |DFLOAT;manexp|) (EXIT (CONS (* |s| (FIX (* |two53=
| (QCAR |me|)))) (- (QCDR |me|) (FLOAT-DIGITS 0.0)))))))) #0# (EXIT #0#))))=
)
-(DEFUN |DoubleFloat| NIL (PROG NIL (RETURN (PROG (#1=#:G105850) (RETURN =
(COND ((LETT #1# (HGET |$ConstructorCache| (QUOTE |DoubleFloat|)) |DoubleFl=
oat|) (|CDRwithIncrement| (CDAR #1#))) ((QUOTE T) (|UNWIND-PROTECT| (PROG1 =
(CDDAR (HPUT |$ConstructorCache| (QUOTE |DoubleFloat|) (LIST (CONS NIL (CON=
S 1 (|DoubleFloat;|)))))) (LETT #1# T |DoubleFloat|)) (COND ((NOT #1#) (HRE=
M |$ConstructorCache| (QUOTE |DoubleFloat|))))))))))))
+(DEFUN |DFLOAT;rationalApproximation;$2NniF;84| (|f| |d| |b| $) (PROG (|#G=
103| |nu| |ex| BASE #0=#:G1548 |de| |tol| |#G104| |q| |r| |p2| |q2| #1==
#:G1566 |#G105| |#G106| |p0| |p1| |#G107| |#G108| |q0| |q1| |#G109| |#G110|=
|s| |t| #2=#:G1564) (RETURN (SEQ (EXIT (SEQ (PROGN (LETT |#G103| (|DFLOA=
T;manexp| |f| $) |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |nu| (QCAR=
|#G103|) |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |ex| (QCDR |#G103=
|) |DFLOAT;rationalApproximation;$2NniF;84|) |#G103|) (LETT BASE (FLOAT-RAD=
IX 0.0) |DFLOAT;rationalApproximation;$2NniF;84|) (EXIT (COND ((< |ex| 0) (=
SEQ (LETT |de| (EXPT BASE (PROG1 (LETT #0# (- |ex|) |DFLOAT;rationalApproxi=
mation;$2NniF;84|) (|check-subtype| (>= #0# 0) (QUOTE (|NonNegativeIntege=
r|)) #0#))) |DFLOAT;rationalApproximation;$2NniF;84|) (EXIT (COND ((< |b| 2=
) (|error| "base must be > 1")) ((QUOTE T) (SEQ (LETT |tol| (EXPT |b| |d|) =
|DFLOAT;rationalApproximation;$2NniF;84|) (LETT |s| |nu| |DFLOAT;rationalAp=
proximation;$2NniF;84|) (LETT |t| |de| |DFLOAT;rationalApproximation;$2NniF=
;84|) (LETT |p0| 0 |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |p1| 1 |=
DFLOAT;rationalApproximation;$2NniF;84|) (LETT |q0| 1 |DFLOAT;rationalAppro=
ximation;$2NniF;84|) (LETT |q1| 0 |DFLOAT;rationalApproximation;$2NniF;84|)=
(EXIT (SEQ G190 NIL (SEQ (PROGN (LETT |#G104| (DIVIDE2 |s| |t|) |DFLOAT;ra=
tionalApproximation;$2NniF;84|) (LETT |q| (QCAR |#G104|) |DFLOAT;rationalAp=
proximation;$2NniF;84|) (LETT |r| (QCDR |#G104|) |DFLOAT;rationalApproximat=
ion;$2NniF;84|) |#G104|) (LETT |p2| (+ (* |q| |p1|) |p0|) |DFLOAT;rationalA=
pproximation;$2NniF;84|) (LETT |q2| (+ (* |q| |q1|) |q0|) |DFLOAT;rationalA=
pproximation;$2NniF;84|) (COND ((OR (EQL |r| 0) (< (SPADCALL |tol| (ABS (- =
(* |nu| |q2|) (* |de| |p2|))) (QREFELT $ 121)) (* |de| (ABS |p2|)))) (EXIT =
(PROGN (LETT #1# (SPADCALL |p2| |q2| (QREFELT $ 120)) |DFLOAT;rationalAppro=
ximation;$2NniF;84|) (GO #1#))))) (PROGN (LETT |#G105| |p1| |DFLOAT;rationa=
lApproximation;$2NniF;84|) (LETT |#G106| |p2| |DFLOAT;rationalApproximation=
;$2NniF;84|) (LETT |p0| |#G105| |DFLOAT;rationalApproximation;$2NniF;84|) (=
LETT |p1| |#G106| |DFLOAT;rationalApproximation;$2NniF;84|)) (PROGN (LETT |=
#G107| |q1| |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |#G108| |q2| |D=
FLOAT;rationalApproximation;$2NniF;84|) (LETT |q0| |#G107| |DFLOAT;rational=
Approximation;$2NniF;84|) (LETT |q1| |#G108| |DFLOAT;rationalApproximation;=
$2NniF;84|)) (EXIT (PROGN (LETT |#G109| |t| |DFLOAT;rationalApproximation;$=
2NniF;84|) (LETT |#G110| |r| |DFLOAT;rationalApproximation;$2NniF;84|) (LET=
T |s| |#G109| |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |t| |#G110| |=
DFLOAT;rationalApproximation;$2NniF;84|)))) NIL (GO G190) G191 (EXIT NIL)))=
)))))) ((QUOTE T) (SPADCALL (* |nu| (EXPT BASE (PROG1 (LETT #2# |ex| |DFLOA=
T;rationalApproximation;$2NniF;84|) (|check-subtype| (>= #2# 0) (QUOTE (|=
NonNegativeInteger|)) #2#)))) (QREFELT $ 122))))))) #1# (EXIT #1#)))))
-(DEFUN |DoubleFloat;| NIL (PROG (|dv$| |$| |pv$|) (RETURN (PROGN (LETT |dv=
$| (QUOTE (|DoubleFloat|)) . #1=(|DoubleFloat|)) (LETT |$| (GETREFV 140) =
. #1#) (QSETREFV |$| 0 |dv$|) (QSETREFV |$| 3 (LETT |pv$| (|buildPredVector=
| 0 0 NIL) . #1#)) (|haddProp| |$ConstructorCache| (QUOTE |DoubleFloat|) NI=
L (CONS 1 |$|)) (|stuffDomainSlots| |$|) |$|))))
+(DEFUN |DFLOAT;**;$F$;85| (|x| |r| $) (PROG (|n| |d| #0=#:G1575) (RETURN=
(SEQ (EXIT (COND ((ZEROP |x|) (COND ((SPADCALL |r| (QREFELT $ 123)) (|erro=
r| "0**0 is undefined")) ((SPADCALL |r| (QREFELT $ 124)) (|error| "division=
by 0")) ((QUOTE T) 0.0))) ((OR (SPADCALL |r| (QREFELT $ 123)) (= |x| 1.0=
)) 1.0) ((QUOTE T) (COND ((SPADCALL |r| (|spadConstant| $ 125) (QREFELT $ 1=
26)) |x|) ((QUOTE T) (SEQ (LETT |n| (SPADCALL |r| (QREFELT $ 127)) |DFLOAT;=
**;$F$;85|) (LETT |d| (SPADCALL |r| (QREFELT $ 128)) |DFLOAT;**;$F$;85|) (E=
XIT (COND ((MINUSP |x|) (COND ((ODDP |d|) (COND ((ODDP |n|) (PROGN (LETT #0=
# (- (SPADCALL (- |x|) |r| (QREFELT $ 129))) |DFLOAT;**;$F$;85|) (GO #0#)))=
((QUOTE T) (PROGN (LETT #0# (SPADCALL (- |x|) |r| (QREFELT $ 129)) |DFLOAT=
;**;$F$;85|) (GO #0#))))) ((QUOTE T) (|error| "negative root")))) ((EQL |d|=
2) (EXPT (SPADCALL |x| (QREFELT $ 57)) |n|)) ((QUOTE T) (SPADCALL |x| (/ (=
FLOAT |n| MOST-POSITIVE-LONG-FLOAT) (FLOAT |d| MOST-POSITIVE-LONG-FLOAT)) (=
QREFELT $ 60))))))))))) #0# (EXIT #0#)))))
-(MAKEPROP (QUOTE |DoubleFloat|) (QUOTE |infovec|) (LIST (QUOTE #(NIL NIL N=
IL NIL NIL NIL (|OpenMathEncoding|) (0 . |OMencodingXML|) (|String|) (|Open=
MathDevice|) (4 . |OMopenString|) (|Void|) (10 . |OMputObject|) (|DoubleFlo=
at|) (15 . |OMputFloat|) (21 . |OMputEndObject|) (26 . |OMclose|) |DFLOAT;O=
Mwrite;$S;1| (|Boolean|) |DFLOAT;OMwrite;$BS;2| |DFLOAT;OMwrite;Omd$V;3| |D=
FLOAT;OMwrite;Omd$BV;4| (|PositiveInteger|) |DFLOAT;base;Pi;6| (|Integer|) =
|DFLOAT;mantissa;$I;7| |DFLOAT;exponent;$I;8| |DFLOAT;precision;Pi;9| |DFLO=
AT;log2;2$;37| (31 . |*|) |DFLOAT;bits;Pi;10| |DFLOAT;max;$;11| |DFLOAT;min=
;$;12| |DFLOAT;order;$I;13| (CONS IDENTITY (FUNCALL (|dispatchFunction| |DF=
LOAT;Zero;$;14|) |$|)) (CONS IDENTITY (FUNCALL (|dispatchFunction| |DFLOAT;=
One;$;15|) |$|)) |DFLOAT;exp1;$;16| |DFLOAT;pi;$;17| (|OutputForm|) (37 . |=
outputForm|) |DFLOAT;coerce;$Of;18| (|InputForm|) (42 . |convert|) |DFLOAT;=
convert;$If;19| |DFLOAT;<;2$B;20| |DFLOAT;-;2$;21| |DFLOAT;+;3$;22| |DFLOAT=
;-;3$;23| |DFLOAT;*;3$;24| |DFLOAT;*;I2$;25| |DFLOAT;max;3$;26| |DFLOAT;min=
;3$;27| |DFLOAT;=;2$B;28| |DFLOAT;/;$I$;29| |DFLOAT;sqrt;2$;30| |DFLOAT;l=
og10;2$;31| |DFLOAT;**;$I$;32| |DFLOAT;**;3$;33| |DFLOAT;coerce;I$;34| |DFL=
OAT;exp;2$;35| |DFLOAT;log;2$;36| |DFLOAT;sin;2$;38| |DFLOAT;cos;2$;39| |DF=
LOAT;tan;2$;40| |DFLOAT;cot;2$;41| |DFLOAT;sec;2$;42| |DFLOAT;csc;2$;43| |D=
FLOAT;asin;2$;44| |DFLOAT;acos;2$;45| |DFLOAT;atan;2$;46| |DFLOAT;acsc;2$;4=
7| |DFLOAT;acot;2$;48| |DFLOAT;asec;2$;49| |DFLOAT;sinh;2$;50| |DFLOAT;cosh=
;2$;51| |DFLOAT;tanh;2$;52| |DFLOAT;csch;2$;53| |DFLOAT;coth;2$;54| |DFLOAT=
;sech;2$;55| |DFLOAT;asinh;2$;56| |DFLOAT;acosh;2$;57| |DFLOAT;atanh;2$;58|=
|DFLOAT;acsch;2$;59| |DFLOAT;acoth;2$;60| |DFLOAT;asech;2$;61| |DFLOAT;/;3=
$;62| |DFLOAT;negative?;$B;63| |DFLOAT;zero?;$B;64| |DFLOAT;hash;$I;65| (|U=
nion| |$| (QUOTE "failed")) |DFLOAT;recip;$U;66| |DFLOAT;differentiate;2$;6=
7| (|DoubleFloatSpecialFunctions|) (47 . |Gamma|) |DFLOAT;Gamma;2$;68| (52 =
. |Beta|) |DFLOAT;Beta;3$;69| |DFLOAT;wholePart;$I;70| |DFLOAT;float;2IPi$;=
71| |DFLOAT;convert;2$;72| (|Float|) (58 . |convert|) |DFLOAT;convert;$F;73=
| (|Fraction| 24) (|NonNegativeInteger|) |DFLOAT;rationalApproximation;$2Nn=
iF;83| |DFLOAT;rationalApproximation;$NniF;74| |DFLOAT;atan;3$;75| |DFLOAT;=
retract;$F;76| (|Union| 103 (QUOTE "failed")) |DFLOAT;retractIfCan;$U;77| |=
DFLOAT;retract;$I;78| (|Union| 24 (QUOTE "failed")) |DFLOAT;retractIfCan;$U=
;79| |DFLOAT;sign;$I;80| |DFLOAT;abs;2$;81| (63 . |Zero|) (67 . |/|) (73 . =
|*|) (79 . |coerce|) (84 . |zero?|) (89 . |negative?|) (94 . |one?|) (99 . =
|one?|) (104 . |numer|) (109 . |denom|) |DFLOAT;**;$F$;84| (|Pattern| 100) =
(|PatternMatchResult| 100 |$|) (|Factored| |$|) (|Union| 131 (QUOTE "failed=
")) (|List| |$|) (|Record| (|:| |coef1| |$|) (|:| |coef2| |$|) (|:| |genera=
tor| |$|)) (|Record| (|:| |coef1| |$|) (|:| |coef2| |$|)) (|Union| 133 (QUO=
TE "failed")) (|Record| (|:| |quotient| |$|) (|:| |remainder| |$|)) (|Recor=
d| (|:| |coef| 131) (|:| |generator| |$|)) (|SparseUnivariatePolynomial| |$=
|) (|Record| (|:| |unit| |$|) (|:| |canonical| |$|) (|:| |associate| |$|)) =
(|SingleInteger|))) (QUOTE #(|~=| 114 |zero?| 120 |wholePart| 125 |unitNo=
rmal| 130 |unitCanonical| 135 |unit?| 140 |truncate| 145 |tanh| 150 |tan| 1=
55 |subtractIfCan| 160 |squareFreePart| 166 |squareFree| 171 |sqrt| 176 |si=
zeLess?| 181 |sinh| 187 |sin| 192 |sign| 197 |sech| 202 |sec| 207 |sample| =
212 |round| 216 |retractIfCan| 221 |retract| 231 |rem| 241 |recip| 247 |rat=
ionalApproximation| 252 |quo| 265 |principalIdeal| 271 |prime?| 276 |precis=
ion| 281 |positive?| 285 |pi| 290 |patternMatch| 294 |order| 301 |one?| 306=
|nthRoot| 311 |norm| 317 |negative?| 322 |multiEuclidean| 327 |min| 333 |m=
ax| 343 |mantissa| 353 |log2| 358 |log10| 363 |log| 368 |lcm| 373 |latex| 3=
84 |inv| 389 |hash| 394 |gcdPolynomial| 404 |gcd| 410 |fractionPart| 421 |f=
loor| 426 |float| 431 |factor| 444 |extendedEuclidean| 449 |exquo| 462 |exp=
ressIdealMember| 468 |exponent| 474 |exp1| 479 |exp| 483 |euclideanSize| 48=
8 |divide| 493 |digits| 499 |differentiate| 503 |csch| 514 |csc| 519 |coth|=
524 |cot| 529 |cosh| 534 |cos| 539 |convert| 544 |coerce| 564 |characteris=
tic| 594 |ceiling| 598 |bits| 603 |base| 607 |atanh| 611 |atan| 616 |associ=
ates?| 627 |asinh| 633 |asin| 638 |asech| 643 |asec| 648 |acsch| 653 |acsc|=
658 |acoth| 663 |acot| 668 |acosh| 673 |acos| 678 |abs| 683 |^| 688 |Zero|=
706 |One| 710 |OMwrite| 714 |Gamma| 738 D 743 |Beta| 754 |>=| 760 |>| 76=
6 |=| 772 |<=| 778 |<| 784 |/| 790 |-| 802 |+| 813 |**| 819 |*| 849)) (=
QUOTE ((|approximate| . 0) (|canonicalsClosed| . 0) (|canonicalUnitNormal| =
. 0) (|noZeroDivisors| . 0) ((|commutative| "*") . 0) (|rightUnitary| . 0) =
(|leftUnitary| . 0) (|unitsKnown| . 0))) (CONS (|makeByteWordVec2| 1 (QUOTE=
(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0=
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0))) (CONS (QUOTE #(|FloatingPointSyst=
em&| |RealNumberSystem&| |Field&| |EuclideanDomain&| NIL |UniqueFactorizati=
onDomain&| |GcdDomain&| |DivisionRing&| |IntegralDomain&| |Algebra&| |Algeb=
ra&| |DifferentialRing&| NIL |OrderedRing&| |Module&| NIL NIL |Module&| NIL=
NIL NIL |Ring&| NIL NIL NIL NIL NIL NIL NIL |AbelianGroup&| NIL NIL |Abeli=
anMonoid&| |Monoid&| NIL |OrderedSet&| |AbelianSemiGroup&| |SemiGroup&| |Tr=
anscendentalFunctionCategory&| NIL |SetCategory&| NIL |ElementaryFunctionCa=
tegory&| NIL |HyperbolicFunctionCategory&| |ArcTrigonometricFunctionCategor=
y&| |TrigonometricFunctionCategory&| NIL NIL |RadicalCategory&| |Retractabl=
eTo&| |RetractableTo&| NIL NIL |BasicType&| NIL)) (CONS (QUOTE #((|Floating=
PointSystem|) (|RealNumberSystem|) (|Field|) (|EuclideanDomain|) (|Principa=
lIdealDomain|) (|UniqueFactorizationDomain|) (|GcdDomain|) (|DivisionRing|)=
(|IntegralDomain|) (|Algebra| 103) (|Algebra| |$$|) (|DifferentialRing|) (=
|CharacteristicZero|) (|OrderedRing|) (|Module| 103) (|EntireRing|) (|Commu=
tativeRing|) (|Module| |$$|) (|OrderedAbelianGroup|) (|BiModule| 103 103) (=
|BiModule| |$$| |$$|) (|Ring|) (|OrderedCancellationAbelianMonoid|) (|Right=
Module| 103) (|LeftModule| 103) (|LeftModule| |$$|) (|Rng|) (|RightModule| =
|$$|) (|OrderedAbelianMonoid|) (|AbelianGroup|) (|OrderedAbelianSemiGroup|)=
(|CancellationAbelianMonoid|) (|AbelianMonoid|) (|Monoid|) (|PatternMatcha=
ble| 100) (|OrderedSet|) (|AbelianSemiGroup|) (|SemiGroup|) (|Transcendenta=
lFunctionCategory|) (|RealConstant|) (|SetCategory|) (|ConvertibleTo| 41) (=
|ElementaryFunctionCategory|) (|ArcHyperbolicFunctionCategory|) (|Hyperboli=
cFunctionCategory|) (|ArcTrigonometricFunctionCategory|) (|TrigonometricFun=
ctionCategory|) (|OpenMath|) (|ConvertibleTo| 127) (|RadicalCategory|) (|Re=
tractableTo| 103) (|RetractableTo| 24) (|ConvertibleTo| 100) (|ConvertibleT=
o| 13) (|BasicType|) (|CoercibleTo| 38))) (|makeByteWordVec2| 139 (QUOTE (0=
6 0 7 2 9 0 8 6 10 1 9 11 0 12 2 9 11 0 13 14 1 9 11 0 15 1 9 11 0 16 2 0 =
0 22 0 29 1 38 0 13 39 1 41 0 13 42 1 92 13 13 93 2 92 13 13 13 95 1 100 0 =
13 101 0 103 0 116 2 103 0 24 24 117 2 24 0 104 0 118 1 103 0 24 119 1 103 =
18 0 120 1 103 18 0 121 1 0 18 0 122 1 103 18 0 123 1 103 24 0 124 1 103 24=
0 125 2 0 18 0 0 1 1 0 18 0 87 1 0 24 0 97 1 0 138 0 1 1 0 0 0 1 1 0 18 0 =
1 1 0 0 0 1 1 0 0 0 75 1 0 0 0 63 2 0 89 0 0 1 1 0 0 0 1 1 0 129 0 1 1 0 0 =
0 54 2 0 18 0 0 1 1 0 0 0 73 1 0 0 0 61 1 0 24 0 114 1 0 0 0 78 1 0 0 0 65 =
0 0 0 1 1 0 0 0 1 1 0 109 0 110 1 0 112 0 113 1 0 103 0 108 1 0 24 0 111 2 =
0 0 0 0 1 1 0 89 0 90 2 0 103 0 104 106 3 0 103 0 104 104 105 2 0 0 0 0 1 1=
0 136 131 1 1 0 18 0 1 0 0 22 27 1 0 18 0 1 0 0 0 37 3 0 128 0 127 128 1 1=
0 24 0 33 1 0 18 0 122 2 0 0 0 24 1 1 0 0 0 1 1 0 18 0 86 2 0 130 131 0 1 =
0 0 0 32 2 0 0 0 0 51 0 0 0 31 2 0 0 0 0 50 1 0 24 0 25 1 0 0 0 28 1 0 0 0 =
55 1 0 0 0 60 1 0 0 131 1 2 0 0 0 0 1 1 0 8 0 1 1 0 0 0 1 1 0 24 0 88 1 0 1=
39 0 1 2 0 137 137 137 1 1 0 0 131 1 2 0 0 0 0 1 1 0 0 0 1 1 0 0 0 1 3 0 0 =
24 24 22 98 2 0 0 24 24 1 1 0 129 0 1 2 0 132 0 0 1 3 0 134 0 0 0 1 2 0 89 =
0 0 1 2 0 130 131 0 1 1 0 24 0 26 0 0 0 36 1 0 0 0 59 1 0 104 0 1 2 0 135 0=
0 1 0 0 22 1 1 0 0 0 91 2 0 0 0 104 1 1 0 0 0 76 1 0 0 0 66 1 0 0 0 77 1 0=
0 0 64 1 0 0 0 74 1 0 0 0 62 1 0 41 0 43 1 0 127 0 1 1 0 13 0 99 1 0 100 0=
102 1 0 0 103 1 1 0 0 24 58 1 0 0 103 1 1 0 0 24 58 1 0 0 0 1 1 0 38 0 40 =
0 0 104 1 1 0 0 0 1 0 0 22 30 0 0 22 23 1 0 0 0 81 2 0 0 0 0 107 1 0 0 0 69=
2 0 18 0 0 1 1 0 0 0 79 1 0 0 0 67 1 0 0 0 84 1 0 0 0 72 1 0 0 0 82 1 0 0 =
0 70 1 0 0 0 83 1 0 0 0 71 1 0 0 0 80 1 0 0 0 68 1 0 0 0 115 2 0 0 0 24 1 2=
0 0 0 104 1 2 0 0 0 22 1 0 0 0 34 0 0 0 35 2 0 11 9 0 20 3 0 11 9 0 18 21 =
1 0 8 0 17 2 0 8 0 18 19 1 0 0 0 94 1 0 0 0 1 2 0 0 0 104 1 2 0 0 0 0 96 2 =
0 18 0 0 1 2 0 18 0 0 1 2 0 18 0 0 52 2 0 18 0 0 1 2 0 18 0 0 44 2 0 0 0 24=
53 2 0 0 0 0 85 2 0 0 0 0 47 1 0 0 0 45 2 0 0 0 0 46 2 0 0 0 0 57 2 0 0 0 =
103 126 2 0 0 0 24 56 2 0 0 0 104 1 2 0 0 0 22 1 2 0 0 0 103 1 2 0 0 103 0 =
1 2 0 0 0 0 48 2 0 0 24 0 49 2 0 0 104 0 1 2 0 0 22 0 29)))))) (QUOTE |look=
upComplete|)))
+(DEFUN |DoubleFloat| NIL (PROG NIL (RETURN (PROG (#0=#:G1588) (RETURN (C=
OND ((LETT #0# (HGET |$ConstructorCache| (QUOTE |DoubleFloat|)) |DoubleFloa=
t|) (|CDRwithIncrement| (CDAR #0#))) ((QUOTE T) (UNWIND-PROTECT (PROG1 (CDD=
AR (HPUT |$ConstructorCache| (QUOTE |DoubleFloat|) (LIST (CONS NIL (CONS 1 =
(|DoubleFloat;|)))))) (LETT #0# T |DoubleFloat|)) (COND ((NOT #0#) (HREM |$=
ConstructorCache| (QUOTE |DoubleFloat|))))))))))))
+
+(DEFUN |DoubleFloat;| NIL (PROG (|dv$| $ |pv$|) (RETURN (PROGN (LETT |dv$|=
(QUOTE (|DoubleFloat|)) . #0=(|DoubleFloat|)) (LETT $ (GETREFV 143) . #0=
#) (QSETREFV $ 0 |dv$|) (QSETREFV $ 3 (LETT |pv$| (|buildPredVector| 0 0 NI=
L) . #0#)) (|haddProp| |$ConstructorCache| (QUOTE |DoubleFloat|) NIL (CONS =
1 $)) (|stuffDomainSlots| $) (QSETREFV $ 6 "~A") $))))
+
+(MAKEPROP (QUOTE |DoubleFloat|) (QUOTE |infovec|) (LIST (QUOTE #(NIL NIL N=
IL NIL NIL NIL (QUOTE |format|) (|String|) |DFLOAT;doubleFloatFormat;2S;1| =
(|OpenMathEncoding|) (0 . |OMencodingXML|) (|OpenMathDevice|) (4 . |OMopenS=
tring|) (|Void|) (10 . |OMputObject|) (|DoubleFloat|) (15 . |OMputFloat|) (=
21 . |OMputEndObject|) (26 . |OMclose|) |DFLOAT;OMwrite;$S;2| (|Boolean|) |=
DFLOAT;OMwrite;$BS;3| |DFLOAT;OMwrite;Omd$V;4| |DFLOAT;OMwrite;Omd$BV;5| (|=
PositiveInteger|) |DFLOAT;base;Pi;7| (|Integer|) |DFLOAT;mantissa;$I;8| |DF=
LOAT;exponent;$I;9| |DFLOAT;precision;Pi;10| |DFLOAT;log2;2$;38| (31 . *) |=
DFLOAT;bits;Pi;11| |DFLOAT;max;$;12| |DFLOAT;min;$;13| |DFLOAT;order;$I;14|=
(CONS IDENTITY (FUNCALL (|dispatchFunction| |DFLOAT;Zero;$;15|) $)) (CONS =
IDENTITY (FUNCALL (|dispatchFunction| |DFLOAT;One;$;16|) $)) |DFLOAT;exp1;$=
;17| |DFLOAT;pi;$;18| (|OutputForm|) (37 . |message|) (42 . -) |DFLOAT;coer=
ce;$Of;19| (|InputForm|) (47 . |convert|) |DFLOAT;convert;$If;20| |DFLOAT;<=
;2$B;21| |DFLOAT;-;2$;22| |DFLOAT;+;3$;23| |DFLOAT;-;3$;24| |DFLOAT;*;3$;25=
| |DFLOAT;*;I2$;26| |DFLOAT;max;3$;27| |DFLOAT;min;3$;28| |DFLOAT;=;2$B;2=
9| |DFLOAT;/;$I$;30| |DFLOAT;sqrt;2$;31| |DFLOAT;log10;2$;32| |DFLOAT;**;$I=
$;33| |DFLOAT;**;3$;34| |DFLOAT;coerce;I$;35| |DFLOAT;exp;2$;36| |DFLOAT;lo=
g;2$;37| |DFLOAT;sin;2$;39| |DFLOAT;cos;2$;40| |DFLOAT;tan;2$;41| |DFLOAT;c=
ot;2$;42| |DFLOAT;sec;2$;43| |DFLOAT;csc;2$;44| |DFLOAT;asin;2$;45| |DFLOAT=
;acos;2$;46| |DFLOAT;atan;2$;47| |DFLOAT;acsc;2$;48| |DFLOAT;acot;2$;49| |D=
FLOAT;asec;2$;50| |DFLOAT;sinh;2$;51| |DFLOAT;cosh;2$;52| |DFLOAT;tanh;2$;5=
3| |DFLOAT;csch;2$;54| |DFLOAT;coth;2$;55| |DFLOAT;sech;2$;56| |DFLOAT;asin=
h;2$;57| |DFLOAT;acosh;2$;58| |DFLOAT;atanh;2$;59| |DFLOAT;acsch;2$;60| |DF=
LOAT;acoth;2$;61| |DFLOAT;asech;2$;62| |DFLOAT;/;3$;63| |DFLOAT;negative?;$=
B;64| |DFLOAT;zero?;$B;65| |DFLOAT;hash;$I;66| (|Union| $ (QUOTE "failed"))=
|DFLOAT;recip;$U;67| |DFLOAT;differentiate;2$;68| (|DoubleFloatSpecialFunc=
tions|) (52 . |Gamma|) |DFLOAT;Gamma;2$;69| (57 . |Beta|) |DFLOAT;Beta;3$;7=
0| |DFLOAT;wholePart;$I;71| |DFLOAT;float;2IPi$;72| |DFLOAT;convert;2$;73| =
(|Float|) (63 . |convert|) |DFLOAT;convert;$F;74| (|Fraction| 26) (|NonNega=
tiveInteger|) |DFLOAT;rationalApproximation;$2NniF;84| |DFLOAT;rationalAppr=
oximation;$NniF;75| |DFLOAT;atan;3$;76| |DFLOAT;retract;$F;77| (|Union| 106=
(QUOTE "failed")) |DFLOAT;retractIfCan;$U;78| |DFLOAT;retract;$I;79| (|Uni=
on| 26 (QUOTE "failed")) |DFLOAT;retractIfCan;$U;80| |DFLOAT;sign;$I;81| |D=
FLOAT;abs;2$;82| (68 . |Zero|) (72 . /) (78 . *) (84 . |coerce|) (89 . |zer=
o?|) (94 . |negative?|) (99 . |One|) (103 . =) (109 . |numer|) (114 . |de=
nom|) |DFLOAT;**;$F$;85| (|PatternMatchResult| 103 $) (|Pattern| 103) (|Fac=
tored| $) (|Union| 134 (QUOTE "failed")) (|List| $) (|Record| (|:| |coef1| =
$) (|:| |coef2| $) (|:| |generator| $)) (|Record| (|:| |coef1| $) (|:| |coe=
f2| $)) (|Union| 136 (QUOTE "failed")) (|Record| (|:| |quotient| $) (|:| |r=
emainder| $)) (|Record| (|:| |coef| 134) (|:| |generator| $)) (|SparseUniva=
riatePolynomial| $) (|Record| (|:| |unit| $) (|:| |canonical| $) (|:| |asso=
ciate| $)) (|SingleInteger|))) (QUOTE #(~= 119 |zero?| 125 |wholePart| 13=
0 |unitNormal| 135 |unitCanonical| 140 |unit?| 145 |truncate| 150 |tanh| 15=
5 |tan| 160 |subtractIfCan| 165 |squareFreePart| 171 |squareFree| 176 |sqrt=
| 181 |sizeLess?| 186 |sinh| 192 |sin| 197 |sign| 202 |sech| 207 |sec| 212 =
|sample| 217 |round| 221 |retractIfCan| 226 |retract| 236 |rem| 246 |recip|=
252 |rationalApproximation| 257 |quo| 270 |principalIdeal| 276 |prime?| 28=
1 |precision| 286 |positive?| 290 |pi| 295 |patternMatch| 299 |order| 306 |=
one?| 311 |nthRoot| 316 |norm| 322 |negative?| 327 |multiEuclidean| 332 |mi=
n| 338 |max| 348 |mantissa| 358 |log2| 363 |log10| 368 |log| 373 |lcm| 378 =
|latex| 389 |inv| 394 |hash| 399 |gcdPolynomial| 409 |gcd| 415 |fractionPar=
t| 426 |floor| 431 |float| 436 |factor| 449 |extendedEuclidean| 454 |exquo|=
467 |expressIdealMember| 473 |exponent| 479 |exp1| 484 |exp| 488 |euclidea=
nSize| 493 |doubleFloatFormat| 498 |divide| 503 |digits| 509 |differentiate=
| 513 |csch| 524 |csc| 529 |coth| 534 |cot| 539 |cosh| 544 |cos| 549 |conve=
rt| 554 |coerce| 574 |characteristic| 604 |ceiling| 608 |bits| 613 |base| 6=
17 |atanh| 621 |atan| 626 |associates?| 637 |asinh| 643 |asin| 648 |asech| =
653 |asec| 658 |acsch| 663 |acsc| 668 |acoth| 673 |acot| 678 |acosh| 683 |a=
cos| 688 |abs| 693 ^ 698 |Zero| 716 |One| 720 |OMwrite| 724 |Gamma| 748 D 7=
53 |Beta| 764 >= 770 > 776 = 782 <= 788 < 794 / 800 - 812 + 823 ** 82=
9 * 859)) (QUOTE ((|approximate| . 0) (|canonicalsClosed| . 0) (|canonicalU=
nitNormal| . 0) (|noZeroDivisors| . 0) ((|commutative| "*") . 0) (|rightUni=
tary| . 0) (|leftUnitary| . 0) (|unitsKnown| . 0))) (CONS (|makeByteWordVec=
2| 1 (QUOTE (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0))) (CONS (QUOTE #(|Floati=
ngPointSystem&| |RealNumberSystem&| |Field&| |EuclideanDomain&| NIL |Unique=
FactorizationDomain&| |GcdDomain&| |DivisionRing&| |IntegralDomain&| |Algeb=
ra&| |Algebra&| |DifferentialRing&| NIL |OrderedRing&| |Module&| NIL NIL |M=
odule&| NIL NIL NIL |Ring&| NIL NIL NIL NIL NIL NIL NIL |AbelianGroup&| NIL=
NIL |AbelianMonoid&| |Monoid&| NIL |OrderedSet&| |AbelianSemiGroup&| |Semi=
Group&| |TranscendentalFunctionCategory&| NIL |SetCategory&| NIL |Elementar=
yFunctionCategory&| NIL |HyperbolicFunctionCategory&| |ArcTrigonometricFunc=
tionCategory&| |TrigonometricFunctionCategory&| NIL NIL |RadicalCategory&| =
|RetractableTo&| |RetractableTo&| NIL NIL |BasicType&| NIL)) (CONS (QUOTE #=
((|FloatingPointSystem|) (|RealNumberSystem|) (|Field|) (|EuclideanDomain|)=
(|PrincipalIdealDomain|) (|UniqueFactorizationDomain|) (|GcdDomain|) (|Div=
isionRing|) (|IntegralDomain|) (|Algebra| 106) (|Algebra| $$) (|Differentia=
lRing|) (|CharacteristicZero|) (|OrderedRing|) (|Module| 106) (|EntireRing|=
) (|CommutativeRing|) (|Module| $$) (|OrderedAbelianGroup|) (|BiModule| 106=
106) (|BiModule| $$ $$) (|Ring|) (|OrderedCancellationAbelianMonoid|) (|Ri=
ghtModule| 106) (|LeftModule| 106) (|LeftModule| $$) (|Rng|) (|RightModule|=
$$) (|OrderedAbelianMonoid|) (|AbelianGroup|) (|OrderedAbelianSemiGroup|) =
(|CancellationAbelianMonoid|) (|AbelianMonoid|) (|Monoid|) (|PatternMatchab=
le| 103) (|OrderedSet|) (|AbelianSemiGroup|) (|SemiGroup|) (|Transcendental=
FunctionCategory|) (|RealConstant|) (|SetCategory|) (|ConvertibleTo| 44) (|=
ElementaryFunctionCategory|) (|ArcHyperbolicFunctionCategory|) (|Hyperbolic=
FunctionCategory|) (|ArcTrigonometricFunctionCategory|) (|TrigonometricFunc=
tionCategory|) (|OpenMath|) (|ConvertibleTo| 131) (|RadicalCategory|) (|Ret=
ractableTo| 106) (|RetractableTo| 26) (|ConvertibleTo| 103) (|ConvertibleTo=
| 15) (|BasicType|) (|CoercibleTo| 40))) (|makeByteWordVec2| 142 (QUOTE (0 =
9 0 10 2 11 0 7 9 12 1 11 13 0 14 2 11 13 0 15 16 1 11 13 0 17 1 11 13 0 18=
2 0 0 24 0 31 1 40 0 7 41 1 40 0 0 42 1 44 0 15 45 1 95 15 15 96 2 95 15 1=
5 15 98 1 103 0 15 104 0 106 0 119 2 106 0 26 26 120 2 26 0 107 0 121 1 106=
0 26 122 1 106 20 0 123 1 106 20 0 124 0 106 0 125 2 106 20 0 0 126 1 106 =
26 0 127 1 106 26 0 128 2 0 20 0 0 1 1 0 20 0 90 1 0 26 0 100 1 0 141 0 1 1=
0 0 0 1 1 0 20 0 1 1 0 0 0 1 1 0 0 0 78 1 0 0 0 66 2 0 92 0 0 1 1 0 0 0 1 =
1 0 132 0 1 1 0 0 0 57 2 0 20 0 0 1 1 0 0 0 76 1 0 0 0 64 1 0 26 0 117 1 0 =
0 0 81 1 0 0 0 68 0 0 0 1 1 0 0 0 1 1 0 112 0 113 1 0 115 0 116 1 0 106 0 1=
11 1 0 26 0 114 2 0 0 0 0 1 1 0 92 0 93 2 0 106 0 107 109 3 0 106 0 107 107=
108 2 0 0 0 0 1 1 0 139 134 1 1 0 20 0 1 0 0 24 29 1 0 20 0 1 0 0 0 39 3 0=
130 0 131 130 1 1 0 26 0 35 1 0 20 0 1 2 0 0 0 26 1 1 0 0 0 1 1 0 20 0 89 =
2 0 133 134 0 1 0 0 0 34 2 0 0 0 0 54 0 0 0 33 2 0 0 0 0 53 1 0 26 0 27 1 0=
0 0 30 1 0 0 0 58 1 0 0 0 63 1 0 0 134 1 2 0 0 0 0 1 1 0 7 0 1 1 0 0 0 1 1=
0 26 0 91 1 0 142 0 1 2 0 140 140 140 1 1 0 0 134 1 2 0 0 0 0 1 1 0 0 0 1 =
1 0 0 0 1 3 0 0 26 26 24 101 2 0 0 26 26 1 1 0 132 0 1 2 0 135 0 0 1 3 0 13=
7 0 0 0 1 2 0 92 0 0 1 2 0 133 134 0 1 1 0 26 0 28 0 0 0 38 1 0 0 0 62 1 0 =
107 0 1 1 0 7 7 8 2 0 138 0 0 1 0 0 24 1 1 0 0 0 94 2 0 0 0 107 1 1 0 0 0 7=
9 1 0 0 0 69 1 0 0 0 80 1 0 0 0 67 1 0 0 0 77 1 0 0 0 65 1 0 44 0 46 1 0 13=
1 0 1 1 0 103 0 105 1 0 15 0 102 1 0 0 106 1 1 0 0 26 61 1 0 0 106 1 1 0 0 =
26 61 1 0 0 0 1 1 0 40 0 43 0 0 107 1 1 0 0 0 1 0 0 24 32 0 0 24 25 1 0 0 0=
84 2 0 0 0 0 110 1 0 0 0 72 2 0 20 0 0 1 1 0 0 0 82 1 0 0 0 70 1 0 0 0 87 =
1 0 0 0 75 1 0 0 0 85 1 0 0 0 73 1 0 0 0 86 1 0 0 0 74 1 0 0 0 83 1 0 0 0 7=
1 1 0 0 0 118 2 0 0 0 26 1 2 0 0 0 107 1 2 0 0 0 24 1 0 0 0 36 0 0 0 37 3 0=
13 11 0 20 23 2 0 7 0 20 21 2 0 13 11 0 22 1 0 7 0 19 1 0 0 0 97 1 0 0 0 1=
2 0 0 0 107 1 2 0 0 0 0 99 2 0 20 0 0 1 2 0 20 0 0 1 2 0 20 0 0 55 2 0 20 =
0 0 1 2 0 20 0 0 47 2 0 0 0 26 56 2 0 0 0 0 88 2 0 0 0 0 50 1 0 0 0 48 2 0 =
0 0 0 49 2 0 0 0 0 60 2 0 0 0 106 129 2 0 0 0 26 59 2 0 0 0 107 1 2 0 0 0 2=
4 1 2 0 0 0 106 1 2 0 0 106 0 1 2 0 0 0 0 51 2 0 0 26 0 52 2 0 0 107 0 1 2 =
0 0 24 0 31)))))) (QUOTE |lookupComplete|)))
(MAKEPROP (QUOTE |DoubleFloat|) (QUOTE NILADIC) T)
+
@
\section{License}
<<license>>=
\start
Date: Thu, 15 Feb 2007 23:17:10 +0100
From: Gregory Vanuxem
To: list
Subject: Re: Lisp format in sf.spad.pamphlet
Le jeudi 15 f=E9vrier 2007 =E0 22:55 +0100, Gregory Vanuxem a =E9crit :
> A suggestion, what about using )spool to produce *.output file?
> (to simplify the comparison via diff of two versions of Axiom (differen=
t
> banners)).
I forgot one thing, GCL adds something like "Starts dribbling to
test.axiom (2007/2/15, 23:13:40)" in the output file so this suggestion
does not help.
\start
Date: Fri, 16 Feb 2007 00:56:20 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Lisp format in sf.spad.pamphlet
Gregory Vanuxem wrote:
> Hello,
>
> I have introduced two bugs in DFLOAT when I sent a patch against
> sf.spad.pamphlet (outputting routine). Try, for example,
> complex(1.7,-2.3@SF) or 3.0*x^3+-2.7@SF*x^2. Furthermore, the directive
> used ("~G") is not "the" good one (it's not portable, the directive
> works this way only on GCL). Patch in attachment (I have used the Float
> method (via 'message')).
>
I wonder how portable "~A" is. The standard promises nice output,
but nothing more. OTOH all Lisp implementations that I tried get
"~G" wrong (GCL does not add trailing spaces, the other lose
some significant digits).
> A suggestion, what about using )spool to produce *.output file?
> (to simplify the comparison via diff of two versions of Axiom (different
> banners)).
>
FYI: I use the script below. The crucial thing is at the end:
I use sed to delete banner and timing messages. I also normalize
paths that appear for various reasons (most from 'Loading' messages).
---------------------------<cut here>-------------------------
#!/bin/sh
DIR1=$1
DIR2=$2
echo DIR1=$DIR1
echo DIR2=$DIR2
ADIR1=$(cd $DIR1; pwd)
ADIR2=$(cd $DIR2; pwd)
verify_dir () {
if ! [ -d $1 ] ; then
echo $1: does not exist
exit
fi
}
verify_dir $ADIR1
verify_dir $ADIR2
IDIR1=$ADIR1/int/input
IDIR2=$ADIR2/int/input
verify_dir $IDIR1
verify_dir $IDIR2
TDIR1=$ADIR1/mnt
TDIR2=$ADIR2/mnt
if ! [ -d $TDIR1 ] ; then
TDIR1=$ADIR1/target
fi
if ! [ -d $TDIR2 ] ; then
TDIR2=$ADIR2/target
fi
verify_dir $TDIR1
verify_dir $TDIR2
PLF=""
for A in $(ls $TDIR1); do
if [ -d $TDIR1/$A ] ; then
if [ "$PLF"x != x ] ; then
echo $TDIR1: contains more then one subdirectory
else
PLF=$A
fi
fi
done
AX1=$TDIR1/$PLF
PLF=""
for A in $(ls $TDIR2); do
if [ -d $TDIR2/$A ] ; then
if [ "$PLF"x != x ] ; then
echo $TDIR2: contains more then one subdirectory
else
PLF=$A
fi
fi
done
AX2=$TDIR2/$PLF
echo AX1=$AX1
echo AX2=$AX2
trap "rm -f /tmp/tcmp1.$$ /tmp/tcmp2.$$" 0 2 3 15
cd $IDIR1
for A in *.output; do
echo Diffing $A
if ! [ -f $IDIR2/$A ] ; then
echo $A: only in $IDIR1
else
sed "1,/^(/d;/^ *Time: /d;s,$AX1,AXIOM,g" $A > /tmp/tcmp1.$$
sed "1,/^(/d;/^ *Time: /d;s,$AX2,AXIOM,g" $IDIR2/$A > /tmp/tcmp2.$$
diff -u /tmp/tcmp1.$$ /tmp/tcmp2.$$
fi
done
-----------------------<cut here>------------------------
\start
Date: Thu, 15 Feb 2007 23:47:18 -0800 (PST)
From: Cliff Yapp
To: list
Subject: A first attempt at a notangle in Lisp
I hesitate to say it's useful, but I have what appears to be a (more or
less) working notangle command in lisp. It successfully handles a
couple test files, and although I haven't inspected the results it
handled most of the contents of boot and interp without crashing.
Unfortunately it's performance is worse than abysmal. The first result
is with noweb's notangle on the boot and interp directories, the second
with the lisp one:
CL-USER> (load "./setup/cleardirs.lisp")
T
CL-USER> (time (load "./setup/runnotangle.lisp"))
Evaluation took:
7.172 seconds of real time
0.892056 seconds of user run time
1.44809 seconds of system run time
[Run times include 0.016 seconds GC run time.]
0 calls to %EVAL
0 page faults and
12,691,344 bytes consed.
T
CL-USER> (load "./setup/cleardirs.lisp")
T
CL-USER> (time (load "./setup/runlispnotangle.lisp"))
Evaluation took:
610.982 seconds of real time
591.209 seconds of user run time
10.440652 seconds of system run time
[Run times include 15.088 seconds GC run time.]
0 calls to %EVAL
0 page faults and
12,712,508,936 bytes consed.
T
What I'm hoping is all of the things I've undoubtedly done very very
wrong can be fixed, but I'm not sure at this point. In the hopes that
this will prod someone into doing it right, I'll upload the files (and
yes the cl-notangle.lisp file was notangled by cl-notangle ;-). I
haven't got a noweb command in lisp yet though, which I guess we would
need unless we switch to the latex-as-chunks style.
Cheers,
CY
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
--0-279212549-1171612038=:61325
XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0gClx1c2VwYWNrYWdle2F4aW9tfQpc
YmVnaW57ZG9jdW1lbnR9Clx0aXRsZXtjbC1ub3RhbmdsZSB2MC4xIC0gYSBM
aXRlcmF0ZSBQcm9ncmFtIENvZGUgRXh0cmFjdG9yIGZvciBBTlNJIENvbW1v
biBMaXNwfSAKXGF1dGhvcntDbGlmZm9yZCBZYXBwfQpcbWFrZXRpdGxlClxi
ZWdpbnthYnN0cmFjdH0KICBOT1dFQiBpcyB0aGUgY2xhc3NpYyBsYW5ndWFn
ZSBhZ25vc3RpYyB0b29sIHVzZWQgZm9yIGxpdGVyYXRlIHByb2dyYW1taW5n
CiAgaW4gdGhlIHN0eWxlIG9mIEtudXRoJ3Mgb3JpZ2luYWwgV0VCLiAgVGhp
cyB0b29sIGltcGxlbWVudHMgYSBtZXRob2QgaW4KICBsaXNwIGZvciBleHRy
YWN0aW5nIHRoZSBzb3VyY2UgY29kZSBmcm9tIGxpdGVyYXRlIGRvY3VtZW50
cy4KXGVuZHthYnN0cmFjdH0KXGVqZWN0Clx0YWJsZW9mY29udGVudHMKXGVq
ZWN0Cgpcc2VjdGlvbntDb3B5cmlnaHQgYW5kIExpY2Vuc2V9CgogVGhpcyBw
cm9ncmFtIGlzIGF2YWlsYWJsZSB1bmRlciB0aGUgTW9kaWZpZWQgQlNEIGxp
Y2Vuc2UuICBUaGUgd29yZGluZwogb2YgdGhlIGZpbGUgd2FzIGNoYW5nZWQg
c2xpZ2h0bHksIGFzIHRoZXJlIGlzIG5vIG9yZ2FuaXphdGlvbiBhc3NvY2lh
dGVkCiB3aXRoIHRoZSBjcmVhdGlvbiBvZiB0aGlzIGZpbGUsIGJ1dCBpZiB0
aGVyZSBpcyBhbnkgcXVlc3Rpb24gdGhlIGxpY2Vuc2UKIGlzIGludGVuZGVk
IHRvIGJlIE1vZGlmaWVkIEJTRC4KCjw8Y29weXJpZ2h0Pj49Cjs7IENvcHly
aWdodCAoYykgMjAwNywgQ2xpZmZvcmQgWWFwcAo7OyBBbGwgcmlnaHRzIHJl
c2VydmVkLgoKQAoKPDxsaWNlbnNlPj49Cjs7IFJlZGlzdHJpYnV0aW9uIGFu
ZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0
aG91dAo7OyBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg
dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlCjs7IG1ldDoKOzsK
OzsgICAgLSBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCBy
ZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAgIG5vdGljZSwgdGhp
cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh
aW1lci4KOzsKOzsgICAgLSBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZv
cm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAg
IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xs
b3dpbmcgZGlzY2xhaW1lciBpbgo7OyAgICAgIHRoZSBkb2N1bWVudGF0aW9u
IGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKOzsg
ICAgICBkaXN0cmlidXRpb24uCjs7Cjs7ICAgIC0gVGhlIG5hbWVzIG9mIHRo
ZSBjb250cmlidXRvcnMgbWF5IG5vdCBiZSB1c2VkIHRvIGVuZG9yc2Ugb3Ig
cHJvbW90ZQo7OyAgICAgIHByb2R1Y3RzIGRlcml2ZWQgZnJvbSB0aGlzIHNv
ZnR3YXJlIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbgo7OyAgICAg
IHBlcm1pc3Npb24uCjs7Cjs7VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBC
WSBUSEUgQ09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUyAiQVMK
OztJUyIgQU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywg
SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQKOztUTywgVEhFIElNUExJRUQg
V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9S
IEEKOztQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuIElOIE5P
IEVWRU5UIFNIQUxMIFRIRSBDT1BZUklHSFQgT1dORVIKOztPUiBDT05UUklC
VVRPUlMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5D
SURFTlRBTCwgU1BFQ0lBTCwKOztFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJ
QUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sCjs7
UFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsg
TE9TUyBPRiBVU0UsIERBVEEsIE9SCjs7UFJPRklUUzsgT1IgQlVTSU5FU1Mg
SU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9S
WSBPRgo7O0xJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNU
IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HCjs7TkVHTElHRU5DRSBP
UiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVT
RSBPRiBUSElTCjs7U09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUg
UE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCgpAIAoKXGVqZWN0ClxzZWN0
aW9ue0ludHJvZHVjdGlvbiAtIE5PV0VCIGFuZCBMaXRlcmF0ZSBQcm9ncmFt
bWluZ30KClRoZSBjb25jZXB0IG9mIExpdGVyYXRlIFByb2dyYW1taW5nIHRy
YWNlcyBiYWNrIHRvIERvbmFsZCBLbnV0aCwgdGhlIGF1dGhvcgpvZiB0aGUg
VGVYIHR5cGVzZXR0aW5nIHN5c3RlbSBhbmQgQ1dFQi4gIFRoZSBmdW5kYW1l
bnRhbCBpZGVhIG9mIGxpdGVyYXRlIApwcm9ncmFtbWluZyBpcyB0byBkZXZl
bG9wIHRoZSBjb2RlIGFuZCBkb2N1bWVudGF0aW9uIGFzIG9uZSBpbnRlZ3Jh
dGVkIHdob2xlIAotIHJhdGhlciB0aGFuIGhhdmluZyBzb3VyY2UgY29kZSBp
biBvbmUgZmlsZSBhbmQgZG9jdW1lbnRhdGlvbiBpbiBhbm90aGVyIHRoZSAK
dHdvIGFyZSB3b3ZlbiB0b2dldGhlci4gIFRoaXMgcGxhY2VzIHRoZSBlbXBo
YXNpcyBvbiBpZGVhcyBtb3JlIHRoYW4gY29kZSwgYW5kIAppcyBpbnRlbmRl
ZCB0byBlbmNvdXJhZ2UgdGhlIGNyZWF0aW9uIG9mIHByb2dyYW1zIHRoYXQg
d2lsbCBiZSB1bmRlcnN0YW5kYWJsZSAKYW5kIHVzYWJsZSBhcyBsb25nIGFz
IHRoZSBpZGVhcyBiZWhpbmQgdGhlIGRlc2lnbiBpdHNlbGYgYXJlIHZhbGlk
LgoKT25lIG9mIHRoZSBwcmFjdGljYWwgY29uc2VxdWVuY2VzIG9mIHRoaXMg
aWRlYSBpcyB0aGF0IGluIG9yZGVyIGZvciB0aGUgY29kZSAKaW4gYSBsaXRl
cmF0ZSBkb2N1bWVudCB0byBiZSBsb2FkZWQgaW50byBhIG1hY2hpbmUsIGl0
IG11c3QgYmUgZXh0cmFjdGVkIGZyb20gCnRoZSBkb2N1bWVudC4gVGhpcyBp
cyBmdXJ0aGVyIGNvbXBsaWNhdGVkIGJ5IHRoZSBlbXBoYXNpcyBvZiBsaXRl
cmF0ZSAKcHJvZ3JhbW1pbmcgb24gaWRlYXMgcmF0aGVyIHRoYW4gY29kZSBk
aWN0YXRpbmcgdGhlIG9yZGVyIG9mIGEgcHJvZ3JhbW1lcidzIAp3b3JrLiAg
V0VCIGRvY3VtZW50cyB0aHVzIGFyZSBub3Qgb25seSBpbnRlcndvdmVuIHRl
eHQgYW5kIHNvdXJjZSBjb2RlLCBidXQgCmhhdmUgY2h1bmtzIG9mIGNvZGUg
ZGVmaW5lZCBhdCBhcmJpdHJhcnkgcG9pbnRzIGluIHRoZSBkb2N1bWVudC4g
IFRoZXJlIGlzIAp1c3VhbGx5IGEgcm9vdCBjaHVuayB3aGljaCBwbGFjZXMg
dGhlIGluZGl2aWR1YWwgcGllY2VzIGluIHRoZSBjb3JyZWN0IG9yZGVyLCAK
YnV0IGVhY2ggcGllY2UgbWF5IGluIHR1cm4gcmVmZXJlbmNlIG90aGVyIHBp
ZWNlcyBhbmQgYWxsIG9mIHRoZW0gbXVzdCBiZSAKZXZlbnR1YWxseSBwdXQg
aW4gdGhlIGNvcnJlY3Qgc2VxdWVuY2UgdG8gYWxsb3cgdGhlIG1hY2hpbmUg
dG8gcmVhZCB0aGVtLgoKSW4gTk9XRUIsIHRoZSBzcGVjaWZpYyBjb21tYW5k
IHRoYXQgZG9lcyB0aGlzIGpvYiBpcyBjYWxsZWQgbm90YW5nbGUuICBUaGVy
ZSAKYXJlIG90aGVyIGNvbW1hbmRzIHRoYXQgcHJvY2VzcyB0aGUgZG9jdW1l
bnQgaW50byB2YXJpb3VzIG91dHB1dCBmb3JtcywgYnV0IApmcm9tIHRoZSBz
dGFuZHBvaW50IG9mIHRoZSBtYWNoaW5lIHVuZGVyc3RhbmRpbmcgdGhlIGNv
ZGUgbm90YW5nbGUgaXMgdGhlIAptb3N0IGNyaXRpY2FsLgoKSGVyZSwgd2Ug
d2lsbCBpbXBsZW1lbnQgYSB3YXkgaW4gbGlzcCB0byBsb2FkIGEgcGFtcGhs
ZXQgZmlsZSwgQXhpb20ncyBmb3JtIApvZiBsaXRlcmF0ZSBwcm9ncmFtbWlu
ZyBkb2N1bWVudCwgYW5kIGV4dHJhY3QgdGhlIGNvZGUgZnJvbSBpdC4KCgpc
c2VjdGlvbntUaGUgVG9wIExldmVsIEZpbGUgU3RydWN0dXJlfQoKPDwqPj49
Cjw8Y29weXJpZ2h0Pj4KPDxsaWNlbnNlPj4KPDxkZWxpbWl0ZXJzPj4KPDxo
YXNodGFibGU+Pgo8PGNodW5rY2xhc3M+Pgo8PGJhc2ljLWNodW5rLW9wZXJh
dGlvbnM+Pgo8PHJlYWRpbi1jaHVuaz4+Cjw8dG9wbGV2ZWwtY2h1bmstc2Nh
bm5pbmc+Pgo8PHJlZmVyZW5jZS1jaHVuay1zY2FubmluZz4+Cjw8bG9hZC1m
aWxlPj4KPDx3cml0ZS1maWxlPj4KPDxub3RhbmdsZT4+CkAgCgpcc2VjdGlv
bntJbml0aWFsIERlZmluaXRpb25zfQoKVGhlIG1vc3QgaW1wb3J0YW50IHBp
ZWNlcyBvZiBpbmZvcm1hdGlvbiBuZWVkZWQgd2hlbiB1bnRhbmdsaW5nIGEg
ZmlsZSBhcmUgCnRoZSBkZWxpbWl0aW5nIHN0cmluZ3MgdXNlZCB0byBpZGVu
dGlmeSBwYXJ0cyBvZiBhIGNodW5rLiAgQXMgYSBydWxlLCBjaHVua3MgCmNv
bnNpc3Qgb2YgYSBuYW1lLCBhIGJvZHksIGFuZCBhbiBlbmQgb2YgY2h1bmsg
Y2hhcmFjdGVyIHdoaWNoIHNpZ25pZmllcyB0aGUgCmVuZCBvZiB0aGUgY29k
ZS4gIEhvd2V2ZXIsIGJlY2F1c2UgY2h1bmtzIG1heSBhbHNvIHJlZmVyZW5j
ZSBvdGhlciBjaHVua3MsIAp0aGVyZSBhbHNvIG5lZWQgdG8gYmUgY2h1bmsg
cmVmZXJlbmNlIGZsYWdzIHRoYXQgY2FuIGJlIHNlZW4gaW5zaWRlIHRoZSBi
b2R5IAppdHNlbGYuICBBeGlvbSBjb252ZW50aW9ucyBhcmUgdXNlZCBoZXJl
IGZvciB0aGUgZGVmYXVsdHMsIGJ1dCBvdGhlcnMgYXJlIApjZXJ0YWlubHkg
cG9zc2libGUgYW5kIGNhbiBiZSBhY2hpZXZlZCBieSBzaW1wbHkgcmUtZGVm
aW5pbmcgdGhlc2UgdmFyaWFibGVzLiAgCk5vdGUsIGhvd2V2ZXIsIHRoYXQg
Y29sbGlzaW9ucyBiZXR3ZWVuIGRlbGltaXRlcnMgYXQgdGhlIHNhbWUgbGV2
ZWxzIChzYXksIAp0aGUgZW5kaW5nIGNoYXJhY3RlcnMgZm9yIHRoZSBuYW1l
IG9mIHRoZSBjaHVuayBhbmQgdGhlIGVuZCBvZiBjaHVuayBib2R5IApjaGFy
YWN0ZXIsIG9yIHRoZSB0d28gZGVsaW1pdGVycyB1c2VkIGluc2lkZSB0aGUg
Ym9keSBmb3IgcmVmZXJlbmNlcykgd2lsbCAKYWxtb3N0IGNlcnRhaW5seSBw
cmV2ZW50IGNvcnJlY3QgcGFyc2luZyBvZiB0aGUgZmlsZS4KCjw8ZGVsaW1p
dGVycz4+PQooZGVmdmFyIHN0YXJ0Y2hhcnMgIjw8IikKKGRlZnZhciBlbmRj
aGFycyAiPj49IikKKGRlZnZhciBlbmRjaHVua2NoYXJzICJAIikKKGRlZnZh
ciByZWZzdGFydGNoYXJzICI8PCIpCihkZWZ2YXIgcmVmZW5kY2hhcnMgIj4+
IikgCgpACgpXaGVuIHJlYWRpbmcgaW4gY2h1bmtzIGFuZCBzdG9yaW5nIHRo
ZW0sIGEgaGFzaCB0YWJsZSBpcyB1c2VkLiAgV2UgaW5pdGlhbGl6ZSAKdGhh
dCB0YWJsZSBhdCB0aGUgYmVnaW5uaW5nLCBzaW5jZSBpdCBpcyB1c2VkIHRo
cm91Z2hvdXQgdGhlIHByb2dyYW0uICBBbiAKaW1wb3J0YW50IGZlYXR1cmUg
dG8gbm90ZSBoZXJlIGlzIHRoYXQgdGhpcyBoYXNoIHRhYmxlIHVzZXMgdGhl
IGBgZXF1YWwnJyAKZnVuY3Rpb24gZm9yIGVxdWFsaXR5IHRlc3RpbmcsIHdo
aWNoIGlzIG5lY2Vzc2FyeSBmb3IgdGhlIGhhc2ggdGFibGUgdG8gd29yayAK
d2l0aCBzdHJpbmcga2V5cy4gIENodW5rIG5hbWVzIGFyZSBzdHJpbmdzLCBh
bmQgYSBkZWZhdWx0IGhhc2ggdGFibGUgCmNvbmZpZ3VyYXRpb24gaW4gTGlz
cCB3aWxsIG5vdCBhY2NlcHQgdGhlbS4KCjw8aGFzaHRhYmxlPj49CihkZWZw
YXJhbWV0ZXIgKmNodW5rLWhhc2gtdGFibGUqIChtYWtlLWhhc2gtdGFibGUg
OnRlc3QgJ2VxdWFsKSkKCkAKClxzZWN0aW9ue0NodW5rIHN0cnVjdHVyZSBp
biBDTE9TfQoKQ0xPUyAodGhlIENvbW1vbiBMaXNwIE9iamVjdCBTeXN0ZW0p
IHByb3ZpZGVzIGV4Y2VsbGVudCB0b29scyBmb3IgZGF0YSAKc3RydWN0dXJl
IGNyZWF0aW9uIGFuZCBtYW5pcHVsYXRpb24uICBXZSB3aWxsIG1ha2Ugb25s
eSBtaW5vciB1c2Ugb2YgaXQgaGVyZSwgCnRvIGRlZmluZSBhIGRhdGEgc3Ry
dWN0dXJlIHRoYXQgd2lsbCBob2xkIGNodW5rcyBhcyB0aGV5IGFyZSByZWFk
IGluIGFuZCAKcGFyc2VkLiAgKEl0IGlzIHBlcmhhcHMgbm90IHN0cmljdGx5
IG5lY2Vzc2FyeSB0byBpbmNsdWRlIHRoZSBjaHVuayBuYW1lIGluIAp0aGUg
ZGF0YSBzdHJ1Y3R1cmUsIHNpbmNlIHRoZSBoYXNoIGNvZGUgaXMgYWxzbyB0
aGUgY2h1bmsgbmFtZS4pIFRoaXMgCmRlZmluaXRpb24gd2lsbCBhbHNvIGF1
dG9tYXRpY2FsbHkgcHJvZHVjZSBmdW5jdGlvbnMgdG8gbWFuaXB1bGF0ZSB0
aGUgCnN0cnVjdHVyZXMgd2l0aGluIHRoZSBjbGFzcywgYWx0aG91Z2ggd2Ug
d2lsbCBkZWZpbmUgY29udmVuaWVuY2UgZnVuY3Rpb25zIApmb3IgdGhvc2Ug
b3BlcmF0aW9ucyBsYXRlci4gVGhlIGNvbnRlbnRzIG9mIHRoZSBjaHVuayBh
cmUgaW5pdGlhbGl6ZWQgdG8gdGhlIAplbXB0eSBzdHJpbmcuCgo8PGNodW5r
Y2xhc3M+Pj0KKGRlZmNsYXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAg
ICA6aW5pdGFyZyA6Y2h1bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAi
TXVzdCBzdXBwbHkgYSBjaHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5r
LW5hbWUKICAgIDpkb2N1bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAg
IChjaHVuay1jb250ZW50cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRz
CiAgICA6aW5pdGZvcm0gIiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50
cwogICAgOmRvY3VtZW50YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5j
bHVkZSByZWZlcmVuY2VzIHRvIG90aGVyIGNodW5rcyIpKSkKCkAKClxzZWN0
aW9ue0Jhc2ljIENodW5rIE9wZXJhdGlvbnN9CgpUaGVyZSBhcmUgdGhyZWUg
dGhpbmdzIHdlIHdpbGwgbm9ybWFsbHkgbmVlZCB0byBkbyB3aXRoIGNodW5r
czogIG1ha2UgbmV3IApvbmVzLCByZWFkIHRoZSBjb250ZW50IG9mIGFscmVh
ZHkgZXhpc3RpbmcgY2h1bmtzLCBhbmQgYWRkIGRhdGEgdG8gYWxyZWFkeSAK
ZXhpc3RpbmcgY2h1bmtzLiAgQ2h1bmsgYnVpbGRpbmcgZG9lcyBub3Qgbm9y
bWFsbHkgbmVlZCB0byByZW1vdmUgY29udGVudCAtIAptb3JlIHN1YnRsZSBt
YW5pcHVsYXRpb24gb2YgY29udGVudCBpcyBuZWVkZWQgZm9yIGhhbmRsaW5n
IHJlZmVyZW5jZXMsIGJ1dCAKdGhhdCBpcyBkZWFsdCB3aXRoIGVsc2V3aGVy
ZS4KClxzdWJzZWN0aW9ue05ldyBDaHVua3N9CgpBIG5ldyBjaHVuayBpcyBh
bHdheXMgYXNzdW1lZCB0byBiZSBlbXB0eSwgc28gd2Ugc2ltcGx5IHRha2Ug
YSBuYW1lIGFyZ3VtZW50IAphbmQgaW5pdGlhbGl6ZSB0aGUgY2h1bmssIG1l
cmdpbmcgaXQgaW50byB0aGUgY2VudHJhbCBoYXNoIHRhYmxlIGFzIHdlIApj
cmVhdGUgaXQuICBUaGlzIG1lYW5zIHRoZSBjaHVuayBgYGxpdmVzJycgaW4g
dGhlIGhhc2ggdGFibGUgYW5kIGRvZXMgbm90IApleGlzdCBhcyBhIHZhcmlh
YmxlIGluIHRoZSBMaXNwIGVudmlyb25tZW50LCBzbyB5b3Ugd2lsbCBuZXZl
ciB0eXBlIApgYGNodW5rMScnIGFuZCBzZWUgdGhlIGNvbnRlbnRzIG9mIHRo
ZSBjaHVuay4KCjw8bmV3LWNodW5rPj49CihkZWZ1biBtYWtlLW5ldy1jaHVu
ayAoY3Vyci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1
bmstbmFtZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2Ug
J2NodW5rIDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKQAoKXHN1
YnNlY3Rpb257UmVhZGluZyBDaHVuayBDb250ZW50c30KCkJlY2F1c2UgdGhl
IGNodW5rcyBhcmUgY29udGFpbmVkIGluIHRoZSBoYXNoIHRhYmxlLCB3ZSBu
ZWVkIGEgd2F5IHRvIHN1cHBseSAKdGhlIG5hbWUgb2YgYSBjaHVuayBhbmQg
cmV0cmlldmUgdGhlIGNvbnRlbnRzLiAgTm90ZSB0aGF0IHRoaXMgcmV0dXJu
cyAKdGhlIGxpdGVyYWwgc3RyaW5nIG9mIHRoZSBjaHVuayBhbmQgZG9lcyBu
b3Qgc3dhcCBpbiBkZWZpbml0aW9ucyBmb3IgCnJlZmVyZW5jZXMuCgo8PGdl
dC1jaHVuay1jb250ZW50cz4+PQooZGVmdW4gZ2V0LWNodW5rLWNvbnRlbnRz
IChjdXJyLWNodW5rLW5hbWUpCiAgKGNodW5rLWNvbnRlbnRzIChnZXRoYXNo
IGN1cnItY2h1bmstbmFtZSAqY2h1bmstaGFzaC10YWJsZSopKSkKCkAKClxz
dWJzZWN0aW9ue0FkZGluZyBOZXcgQ29udGVudCB0byBDaHVua3N9CgpBcyB0
aGUgZmlsZSBpcyByZWFkIGluIGxpbmUgYnkgbGluZSwgd2UgZG9uJ3QgZGVm
aW5lIGNodW5rIGNvbnRlbnRzIGluIGEgCnNpbmdsZSBgYGd1bHAnJyBidXQg
b25lIGxpbmUgYXQgYSB0aW1lLiAgU28gd2UgbmVlZCBhIGNvbnZlbmllbnQg
d2F5IHRvIGFkZCAKbmV3IGxpbmVzIHRvIHRoZSBjb250ZW50cyBvZiBhIGNo
dW5rIGtub3dpbmcgb25seSB0aGUgbmFtZSBvZiB0aGUgY2h1bmsgYW5kIAp0
aGUgY29udGVudHMgdG8gYWRkLiAgVGhlIG9ubHkgbWlub3IgZGlmZmljdWx0
eSBoZXJlIGlzIHRoYXQgcmVhZC1saW5lIGluIApMaXNwIGRvZXNuJ3QgcHJl
c2VydmUgbmV3bGluZXMgYXMgcGFydCBvZiB0aGUgc3RyaW5nLCB3aGljaCBp
cyBub3JtYWxseSB0aGUgCmRlc2lyZWQgYmVoYXZpb3IgYnV0IG5vdCB3aGF0
IGlzIG5lZWRlZCBoZXJlLiAgU28gdGhlcmUgYXJlIHR3byBjYXNlcyAtIGlu
IAp0aGUgaW5pdGlhbCBjYXNlIHdoZW4gdGhlIGNvbnRlbnRzIGFyZSBlbXB0
eSB3ZSBzaW1wbHkgYXNzaWduIHRoZSBzdHJpbmcgYXMKdGhlIG5ldyBjb250
ZW50cy4gIElmIHRoZSBjb250ZW50cyBhcmUgbm90IGVtcHR5IHdlIG5lZWQg
dG8gY3JlYXRlIGEgbmV3IApzdHJpbmcgY29udGFpbmluZyB0aGUgb3JpZ2lu
YWwgY29udGVudHMsIGEgbmV3bGluZSBjaGFyYWN0ZXIsIGFuZCB0aGUgbmV3
IApsaW5lLgoKPDxhZGQtY2h1bmstY29udGVudHM+Pj0KKGRlZnVuIGFkZC10
by1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lIG5ldy1jb250ZW50
cykKICAobGV0ICgoc3RhcnRpbmctY2h1bmstY29udGVudHMgKGdldC1jaHVu
ay1jb250ZW50cyBjdXJyLWNodW5rLW5hbWUpKSkKICAgIChpZiAoc3RyaW5n
LWVxdWFsIHN0YXJ0aW5nLWNodW5rLWNvbnRlbnRzICIiKQoJKHNldGYgKGNo
dW5rLWNvbnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmst
aGFzaC10YWJsZSopKQoJICAgICAgbmV3LWNvbnRlbnRzKQoJKHNldGYgKGNo
dW5rLWNvbnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmst
aGFzaC10YWJsZSopKQoJICAgICAgKGNvbmNhdGVuYXRlICdzdHJpbmcgc3Rh
cnRpbmctY2h1bmstY29udGVudHMgKHN0cmluZyAjXE5ld2xpbmUpCgkJCSAg
IG5ldy1jb250ZW50cykpKSkpCgpACgpcc3Vic2VjdGlvbntBbGwgQmFzaWMg
RnVuY3Rpb25zfQoKVGhlc2UgdGhyZWUgb3BlcmF0aW9ucyBhcmUgdGhlIGNv
cmUgb2Ygd2hhdCBpcyBuZWVkZWQuICBXZSB3aWxsIGFkZCBvbmUgbW9yZSAK
ZnVuY3Rpb24gZm9yIGNvbnZlbmllbmNlIGR1cmluZyBkZWJ1Z2dpbmcsIHdo
aWNoIHByaW50cyBvdXQgYWxsIGNodW5rcyBpbiAKdGhlIGhhc2ggdGFibGUu
Cgo8PHZpZXctYWxsPj49CihkZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAo
bWFwaGFzaCAjJyhsYW1iZGEgKGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4l
IiBrIHYpKSAqY2h1bmstaGFzaC10YWJsZSopKQoKQAoKPDxiYXNpYy1jaHVu
ay1vcGVyYXRpb25zPj49Cjw8bmV3LWNodW5rPj4KPDxnZXQtY2h1bmstY29u
dGVudHM+Pgo8PGFkZC1jaHVuay1jb250ZW50cz4+Cjw8dmlldy1hbGw+PgpA
Cgpcc2VjdGlvbntMb2NhdGluZyBDaHVua3MgYW5kIENodW5rIFJlZmVyZW5j
ZXN9CgpUaGUgbW9zdCBkaWZmaWN1bHQgcGFydCBvZiBkZWFsaW5nIHdpdGgg
bGl0ZXJhdGUgcHJvZ3JhbW1pbmcgZmlsZXMgaXMgdGhlIAppbnRlcndvdmVu
IHN0cnVjdHVyZSB0aGF0IGNvZGUgY2h1bmsgcmVmZXJlbmNlcyBjYW4gcHJv
ZHVjZS4gIFR3byBsZXZlbHMgYXJlIApuZWVkZWQgLSBpZGVudGlmeSBhbmQg
c3RvcmUgZGVmaW5lZCBjaHVua3MsIGFuZCBzcG90IHJlZmVyZW5jZXMgdG8g
Y2h1bmtzIAppbnNpZGUgb2YgY2h1bmsgYm9kaWVzLgoKXHN1YnNlY3Rpb257
SWRlbnRpZnlpbmcgYW5kIFN0b3JpbmcgQ2h1bmtzIC0gVG9wIExldmVsfQoK
QW4gYXNzdW1wdGlvbiBtYWRlIGlzIHRoYXQgYWxsIGNodW5rIGRlZmluaXRp
b25zIGFyZSBgYHRvcCBsZXZlbCcnIC0gdGhhdCBpcywgCm5vIGNodW5rIGlz
IGRlZmluZWQgaW4gdGhlIGJvZHkgb2YgYW5vdGhlciBjaHVuay4gIEdyYW50
aW5nIHRoYXQgYXNzdW1wdGlvbiwgCml0IGlzIHBvc3NpYmxlIHRvIGNoZWNr
IGVhY2ggc3RyaW5nIGFzIGl0IGlzIHJlYWQgdG8gc2VlIGlmIGl0IGlzIHRo
ZSBzdGFydCAKb2YgYSBuZXcgY2h1bmsuICBUaGlzIGlzIGRvbmUgdXNpbmcg
TGlzcCBzdHJpbmcgc2VhcmNoaW5nIGFuZCBzcGFjZSB0cmltbWluZy4KQW5v
dGhlciBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlIGJlZ2lubmluZyBpZGVudGlm
aWVyIGZvciBhIGNodW5rIGlzIG9uIGl0cyAKb3duIGxpbmUgLSB0aGlzIGlz
IHByb2JhYmx5IG5vdCBzdHJpY3RseSBuZWNlc3NhcnkgYnV0IHNob3VsZCBi
ZSBzdGFuZGFyZCAKY29udmVudGlvbi4KCjw8dG9wbGV2ZWwtY2h1bmstc2Nh
bm5pbmc+Pj0KKGRlZnVuIGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayAoaW5w
dXRzdHJpbmcgZmlsZW5hbWUpCiAgIChsZXQgKCh0ZXN0c3RyaW5nIChzdHJp
bmctdHJpbSAiICIgaW5wdXRzdHJpbmcpKSkKICAgICAoaWYgKD4gKGxlbmd0
aCB0ZXN0c3RyaW5nKSAzKQogICAgIChpZiAoYW5kIChzdHJpbmctZXF1YWwg
c3RhcnRjaGFycyB0ZXN0c3RyaW5nIDplbmQyIChsZW5ndGggc3RhcnRjaGFy
cykpCgkgICAgICAoc3RyaW5nLWVxdWFsIGVuZGNoYXJzIHRlc3RzdHJpbmcg
CgkJCSAgICAgOnN0YXJ0MiAoLSAobGVuZ3RoIHRlc3RzdHJpbmcpIChsZW5n
dGggZW5kY2hhcnMpKQoJCQkgICAgIDplbmQyIChsZW5ndGggdGVzdHN0cmlu
ZykpKQogICAgICAgICAobGV0ICgobmV3LWNodW5rLW5hbWUgKHN1YnNlcSB0
ZXN0c3RyaW5nIChsZW5ndGggc3RhcnRjaGFycykKCQkJCSAgICgtIChsZW5n
dGggdGVzdHN0cmluZykgKGxlbmd0aCBlbmRjaGFycykpKSkpCgkgICAobWFr
ZS1uZXctY2h1bmsgbmV3LWNodW5rLW5hbWUpCgkgICAocmVhZC1pbi1jaHVu
ayBuZXctY2h1bmstbmFtZSBmaWxlbmFtZSkKCSAgIHQpCgkgKSkpKQoKQAoK
XHN1YnNlY3Rpb257SWRlbnRpZnlpbmcgYW5kIEV4cGFuZGluZyBDaHVuayBS
ZWZlcmVuY2VzfQoKVGhlIGFib3ZlIHdpbGwgc2VydmUgZm9yIHRvcGxldmVs
IGNodW5rIGlkZW50aWZpY2F0aW9uLCBidXQgdGhlIHRhc2sgb2YgCmlkZW50
aWZ5aW5nIHJlZmVyZW5jZXMgdG8gY2h1bmtzIGluIHRoZSBib2R5IG9mIGEg
Y2h1bmsgaXMgYSBzbGlnaHRseSAKZGlmZmVyZW50IHRhc2suICBBIGxpbmUg
d2lsbCBjb250YWluIG9ubHkgb25lIGNodW5rIGRlZmluaXRpb24sIGJ1dCB0
aGUgCmNvbnRlbnRzIG9mIGEgY2h1bmsgYm9keSBtYXkgY29udGFpbiBtYW55
IGNodW5rIHJlZmVyZW5jZXMuICBBIGZ1cnRoZXIgCmNvbXBsaWNhdGlvbiBp
cyB0aGF0IGV2ZW4gd2hlbiB0aG9zZSByZWZlcmVuY2VzIGFyZSBleHBhbmRl
ZCwgdGhleSBtYXkgCmluIHR1cm4gY29udGFpbiBvdGhlciByZWZlcmVuY2Vz
LiAgVG8gaGFuZGxlIHRoaXMgYSByZWN1cnNpdmUgZnVuY3Rpb24KaWRlbnRp
ZmllcyAgdGhlIGZpcnN0IGNodW5rLCBleHBhbmRzIGl0LCBidWlsZHMgYSBu
ZXcgc3RyaW5nIGJhc2VkIG9uIAp0aGUgY29tYmluYXRpb24gIG9mIG9sZCBh
bmQgbmV3LCBpbnNlcnRzIGluIHBsYWNlIG9mIHRoZSByZWZlcmVuY2UsIAph
bmQgY2FsbHMgaXRzZWxmIG9uIHRoZSBuZXcgcmVzdWx0LiBJbiB0aGUgZW5k
LCB0aGUgcmV0dXJuZWQgCnN0cmluZyB3aWxsIGhhdmUgYWxsIHJlZmVyZW5j
ZXMgZXhwYW5kZWQgYW5kIGNvbnN0aXR1dGUgdGhlIGZpbmFsIGZvcm0gb2Yg
CnRoZSBjaHVuayBhcyBpdCBpcyB0byBiZSBzZW50IHRvIHRoZSBvdXRwdXQg
ZmlsZS4KCkhvd2V2ZXIsIHRoZXJlIGFyZSBzZXZlcmFsIHRoaW5ncyB0byBi
ZSB3YXJ5IG9mIHdoZW4gZG9pbmcgdGhpcyBzY2FuLiAgVGhlCmZpcnN0IGlz
IGEgYmFkIGNodW5rLCBvciBhIHJlZmVyZW5jZSBjaHVuayB3aGljaCBoYXMg
bm8gZGVmaW5pdGlvbi4gIFRoaXMKaXMgaGFuZGxlZCBieSB0aHJvd2luZyBh
biBlcnJvciBpZiBzdWNoIGEgY2h1bmsgaXMgZW5jb3VudGVyZWQuICBXZSB3
aWxsCmFsc28gZGVmaW5lIGhlcmUgdGhlIGNvcmUgcm91dGluZSBmb3IgbWVy
Z2luZyB0aGUgc3RyaW5nczoKCjw8Y29yZS1yZWY+Pj0KKHByb2duCiAgKGxl
dCAoKG1pZGRsZXN0cmluZyAoc3Vic2VxIGlucHV0c3RyaW5nIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoKyBwb3MxIChsZW5ndGggcmVmc3Rh
cnRjaGFycykpIAoJCQkgICAgICBwb3MyKSkpCiAgICAoaWYgKGdldGhhc2gg
bWlkZGxlc3RyaW5nICpjaHVuay1oYXNoLXRhYmxlKikKCShwcm9nbgoJICAo
c2V0ZiBpbnB1dHN0cmluZyAKCQkoY29uY2F0ZW5hdGUgJ3N0cmluZwoJCQkg
ICAgIChzdWJzZXEgaW5wdXRzdHJpbmcgMCBwb3MxKQoJCQkgICAgIChnZXQt
Y2h1bmstY29udGVudHMgbWlkZGxlc3RyaW5nKQoJCQkgICAgIChzdWJzZXEg
aW5wdXRzdHJpbmcgCgkJCSAgICAgICAgICAgICAoKyBwb3MyIChsZW5ndGgg
cmVmZW5kY2hhcnMpKSkpKQoJICAoY2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1
bmsgaW5wdXRzdHJpbmcgcG9zMSkpCgkoZXJyb3IgICJ+UyB3YXMgbm90IGZv
dW5kIGluIGhhc2ggdGFibGUuIiBtaWRkbGVzdHJpbmcpKSkpKSkKQAoKVGhl
IG5leHQgY2hlY2sgaXMgZm9yIGEgY2FzZSB3aGVyZSB0aGUgZGVsaW1pdGlu
ZyBjaGFyYWN0ZXJzIGFyZSBicm9rZW4KdXAgb3ZlciB0d28gbGluZXMuICBX
ZSB3aWxsIG5vdCByZWdhcmQgdGhpcyBhcyBhIGxlZ2FsIGNodW5rIG5hbWUs
IGFzCml0IGlzIGEgcmF0aGVyIHVubGlrZWx5IGNoYXJhY3RlciBjb21iaW5h
dGlvbiBmb3IgYSBsYWJlbCwgYW5kIGl0IGFsc28KYWxsb3dzIHRoZSBhdm9p
ZGFuY2Ugb2YgYWNjaWRlbnRhbCBjaHVuayBuYW1lIG1hdGNoaW5nIHdoZW4g
aXQgaXMgbm90CmludGVuZGVkIChvbmUgb2YgdGhlIGNodW5rcyBpbiB0aGlz
IHBhbXBobGV0LCBmb3IgZXhhbXBsZSwgd291bGQgdHJpZ2dlcgpzdWNoIGFu
IGVycm9yLikgIElmIHN1Y2ggYSBjb25kaXRpb24gaXMgZm91bmQsIHRoZSBz
Y2FuIHNob3VsZCBiZSByZXN1bWVkCmJleW9uZCB0aGUgbmV3bGluZSBjaGFy
YWN0ZXIuCgo8PGNoZWNrLWZvci1uZXdsaW5lPj49CihpZiAoc2VhcmNoIChz
dHJpbmcgI1xOZXdsaW5lKSBpbnB1dHN0cmluZyA6c3RhcnQyIHBvczEgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6ZW5k
MiBwb3MyKQogIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayBpbnB1dHN0
cmluZyAKICAJKCsoc2VhcmNoIChzdHJpbmcgI1xOZXdsaW5lKSBpbnB1dHN0
cmluZyA6c3RhcnQyIHBvczEKCQkJCQkJIDplbmQyIHBvczIpIDEpICkKICA8
PGNvcmUtcmVmPj4KQAoKV2l0aCB0aG9zZSB0d28gY2hlY2tzIGluIHBsYWNl
LCB3ZSBub3cgZGVmaW5lIHRoZSB0b3AgbGV2ZWwgY29udHJvbApmb3IgcG9z
aXRpb25pbmcgdGhlIHNlYXJjaCBjb21tYW5kLiAgVG8gYXZvaWQgY29uZnVz
aW9uIGFuZCB1bm5lZWRlZApzY2FubmluZywgdGhlIGNvbW1hbmQgdGFrZXMg
YSBzdGFydGluZyBwb3NpdGlvbiBhcyBhbiBhcmd1bWVudC4gIFRoaXMKYWxs
b3dzIHN1YnNlcXVlbnQgcmVjdXJzaXZlIGNhbGxzIHRvIGRpY3RhdGUgdGhl
aXIgc3RhcnRpbmcgcG9zaXRpb24sCmFuZCB0aGUgaW5pdGlhbCBjYWxsIHNp
bXBseSBzcGVjaWZpZXMgemVybyBhcyB0aGUgYmVnaW5uaW5nLiAgQXQgdGhp
cyBsZXZlbAp3ZSBhbHNvIGhhdmUgdGhlIGV4aXQgY29uZGl0aW9uIC0gaWYg
b25lIG9yIG1vcmUgb2YgcG9zMSBhbmQgcG9zMiBhcmUKbmlsLCB0aGF0IG1l
YW5zIHRoaXMgcGFydGljdWxhciBzdHJpbmcgaXMgY29tcGxldGUgYW5kIGNh
biBiZSByZXR1cm5lZC4KCjw8cmVmZXJlbmNlLWNodW5rLXNjYW5uaW5nPj49
CihkZWZ1biBjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAoaW5wdXRzdHJp
bmcgc3RhcnRwb3MpCiAgIChsZXQgKChwb3MxIChzZWFyY2ggcmVmc3RhcnRj
aGFycyBpbnB1dHN0cmluZyA6c3RhcnQyIHN0YXJ0cG9zKSkpCiAgICAgKGxl
dCAoKHBvczIgKGlmIHBvczEgKHNlYXJjaCByZWZlbmRjaGFycyBpbnB1dHN0
cmluZyA6c3RhcnQyIHBvczEpKSkpCiAgICAgICAoaWYgKGFuZCBwb3MxIHBv
czIpCgkgICAocHJvZ24KCSAgIDw8Y2hlY2stZm9yLW5ld2xpbmU+PgoJICAg
aW5wdXRzdHJpbmcpKSkpCgpACgpcc2VjdGlvbntSZWFkaW5nIGluIENodW5r
c30KCk9uY2Ugd2UgaGF2ZSBpZGVudGlmaWVkIGEgY2h1bmsgYXQgdGhlIHRv
cCBsZXZlbCwgd2UgbXVzdCByZWFkIGl0IGluLiBJbiB0aGUgCnRvcGxldmVs
IGZ1bmN0aW9uIHRoYXQgam9iIGlzIHBhc3NlZCBvZmYgdGhhdCBqb2IgdG8g
YSBmdW5jdGlvbiBjYWxsZWQgCnJlYWQtaW4tY2h1bmsuICByZWFkLWluLWNo
dW5rIGlzIHRoZSBmdW5jdGlvbiB0aGF0IHB1dHMgYWRkaXRpb25hbCBsaW5l
cyBpbnRvIAp0aGUgY2h1bmsgY29udGVudHMgc2xvdCB1bnRpbCB0aGUgZW5k
LW9mLWNodW5rLWJvZHkgY2hhcmFjdGVyIGlzIHNwb3R0ZWQuICAKSXQgYWxz
byB1c2VzIHJlY3Vyc2lvbiAtIGlmIHRoZSBsaW5lIGl0IHJlYWRzIGlzbid0
IHRoZSBlbmQtb2YtYm9keSBtYXJrZXIsIAppdCBhcHBlbmRzIHRoYXQgbGlu
ZSB0byB0aGUgY29udGVudHMgYW5kIGNhbGxzIGl0c2VsZiB0byBjaGVjayB0
aGUgbmV4dCAKbGluZS4gIEl0IGFsc28gd2lsbCBhdm9pZCBhbiBlbmQtb2Yt
Ym9keSBtYXJrZXIgd2l0aCBhIGRvdWJsZS1xdW90ZSBpbiBmcm9udApvZiBp
dCwgdG8gYWxsb3cgdGhlIHByZXNlbmNlIG9mIHRoYXQgY2hhcmFjdGVyIGlu
IGNlcnRhaW4gdXNlcy4KCjw8cmVhZGluLWNodW5rPj49CihkZWZ1biByZWFk
LWluLWNodW5rIChjdXJyLWNodW5rLW5hbWUgZmlsZW5hbWUpCiAgKGxldCAo
KG5leHRsaW5lIChyZWFkLWxpbmUgZmlsZW5hbWUgbmlsKSkpCiAgICAoaWYg
KG9yIChub3QgKHNlYXJjaCBlbmRjaHVua2NoYXJzIG5leHRsaW5lKSkgCiAg
ICAgICAgICAgIChzZWFyY2ggKGNvbmNhdGVuYXRlICdzdHJpbmcgKHN0cmlu
ZyAjXCIpIGVuZGNodW5rY2hhcnMpCgkgICAgICAgICAgICAgbmV4dGxpbmUp
KSAKCShwcm9nbgoJICAoYWRkLXRvLWNodW5rLWNvbnRlbnRzIGN1cnItY2h1
bmstbmFtZSBuZXh0bGluZSkKCSAgKHJlYWQtaW4tY2h1bmsgY3Vyci1jaHVu
ay1uYW1lIGZpbGVuYW1lKSkpKSkKCkAKClxzZWN0aW9ue0ZpbGUgT3BlcmF0
aW9uc30KCk5vdyB0aGF0IHdlIGtub3cgaG93IHRvIGhhbmRsZSBjaHVua3Ms
IHdlIG9ubHkgbmVlZCB0byBhcHBseSB0aGF0IGtub3dsZWRnZSAKdG8gc29t
ZSBwYXJ0aWN1bGFyIGZpbGUuICBGb3IgdGhpcywgd2UgdXNlIGEgbG9vcCBt
YWNybyByYXRoZXIgdGhhbiByZWN1cnNpb24uCgo8PGxvYWQtZmlsZT4+PQoo
ZGVmdW4gbG9hZC1wYW1waGxldC1maWxlIChmaWxlbmFtZSkKICAobGV0ICgo
aW4gKG9wZW4gZmlsZW5hbWUgOmlmLWRvZXMtbm90LWV4aXN0IG5pbCkpKQog
ICAgKHdoZW4gaW4KICAgICAgKGxvb3AgZm9yIGxpbmUgPSAocmVhZC1saW5l
IGluIG5pbCkKCSAgICB3aGlsZSBsaW5lIGRvIChjaGVjay1mb3ItdG9wbGV2
ZWwtY2h1bmsgbGluZSBpbikpCiAgICAgIChjbG9zZSBpbikpKSkKCkAKCldl
IGFsc28gbmVlZCB0byBiZSBhYm91dCB0byBvdXRwdXQgdG8gYSBmaWxlLiBU
aGUgemVybyBpbiB0aGUgd3JpdGUtc3RyaW5nIApjb21tYW5kIHNpbXBseSB0
ZWxscyB0aGUgc2Nhbm5lciB0byBzdGFydCBhdCB0aGUgYmVnaW5uaW5nIG9m
IHRoZSBmaWxlLiAgQXMKaXQgaXMgY3VycmVudGx5IGNvbmZpZ3VyZWQsIHRo
ZSBvdXRwdXQgZmlsZSBpcyBhbHdheXMgb3ZlcndyaXR0ZW4uCgo8PHdyaXRl
LWZpbGU+Pj0KKGRlZnVuIHdyaXRlLW91dHB1dC1maWxlIChmaWxlbmFtZSBj
aHVua25hbWUpCiAgKGxldCAoKG91dHB1dHN0cmVhbSAob3BlbiBmaWxlbmFt
ZSA6ZGlyZWN0aW9uIDpvdXRwdXQgOmlmLWV4aXN0cyA6c3VwZXJzZWRlKSkp
CiAgICAod3JpdGUtc3RyaW5nIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVu
ayAKCQkgICAoZ2V0LWNodW5rLWNvbnRlbnRzIGNodW5rbmFtZSkgMCkgb3V0
cHV0c3RyZWFtKQogICAgKGNsb3NlIG91dHB1dHN0cmVhbSkpKQoKQAoKXHNl
Y3Rpb257UHVsbGluZyBJdCBUb2dldGhlciAtIFRoZSBub3RhbmdsZSBDb21t
YW5kfQoKVGhlIGZpbmFsLCB0b3AgbGV2ZWwgY29udHJvbCBjb21tYW5kIGlz
IG5hbWVkIG5vdGFuZ2xlIHRvIGNvbmZvcm0gdG8gdGhlIApOT1dFQiBjb252
ZW50aW9uLiAgVGhpcyBjb21tYW5kIGFjY2VwdHMgYW4gaW5wdXQgZmlsZSwg
b3V0cHV0IGZpbGUsIGFuZCAKb3B0aW9uYWxseSB0aGUgbmFtZSBvZiB0aGUg
Y2h1bmsgYXQgd2hpY2ggdG8gc3RhcnQgZXh0cmFjdGluZyBjb250ZW50cy4g
IApUaGUgZGVmYXVsdCBjb252ZW50aW9uIG9mIEF4aW9tIGlzIHRvIHVzZSBh
biBhc3RlcmlzayBhcyB0aGUgcm9vdCBub2RlLCBidXQgCnRoaXMgaXMgbm90
IHVuaXZlcnNhbGx5IHRydWUgYW5kIGl0IGlzIHNvbWV0aW1lcyBkZXNpcmFi
bGUgdG8gb3V0cHV0IGNvZGUgCmZyb20gb25lIHBhbXBobGV0IGludG8gbXVs
dGlwbGUgdGFyZ2V0IGZpbGVzLCBzdGFydGluZyBhdCBtdWx0aXBsZSByb290
cy4gIApJbiB0aGF0IGNhc2UsIHRoZSBjaHVuayBuYW1lIGlzIHBhc3NlZCB0
byBub3RhcmdldCBhcyB3ZWxsLiAgRm9yIGV4YW1wbGU6CgpcYmVnaW57cXVv
dGV9Cihub3RhbmdsZSBgYGJvb3QucGFtcGhsZXQnJyBgYGJvb3QubGlzcCcn
IGBgUkxpc3AnJykKXGVuZHtxdW90ZX0KClxub2luZGVudCB3b3VsZCBleHRy
YWN0IGFsbCBjb2RlIHJlZmVyZW5jZWQgYnkgdGhlIFJMaXNwIGNodW5rLCB3
aGVyZWFzCgpcYmVnaW57cXVvdGV9Cihub3RhbmdsZSBgYGJvb3QucGFtcGhs
ZXQnJyBgYGJvb3QuYm9vdCcnKQpcZW5ke3F1b3RlfQoKXG5vaW5kZW50IHdv
dWxkIGV4dHJhY3QgYWxsIGNvZGUgcmVmZXJlbmNlZCBieSB0aGUgXHZlcmJA
JycqJydAIG5vZGUuCgpUaGUgbm90YW5nbGUgY29tbWFuZCB3aWxsIGFsd2F5
cyBjbGVhciB0aGUgaGFzaCB0YWJsZSBiZWZvcmUgYW5kIGFmdGVyCnVzZSwg
dG8gZW5zdXJlIG5vIGFjY2lkZW50YWwgY29sbGlzaW9ucyBhbmQgYXZvaWQg
dW5uZWNlc3NhcnkgbWVtb3J5CnVzYWdlLgoKPDxub3RhbmdsZT4+PQooZGVm
dW4gbm90YW5nbGUgKGZpbGVpbm5hbWUgZmlsZW91dG5hbWUgJm9wdGlvbmFs
IChjaHVua25hbWUgIioiKSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJs
ZSopCiAgKGxvYWQtcGFtcGhsZXQtZmlsZSBmaWxlaW5uYW1lKQogICh3cml0
ZS1vdXRwdXQtZmlsZSBmaWxlb3V0bmFtZSBjaHVua25hbWUpCiAgKGNscmhh
c2ggKmNodW5rLWhhc2gtdGFibGUqKSkKQAoKXGVuZHtkb2N1bWVudH0K
--0-279212549-1171612038=:61325
OzsgQ29weXJpZ2h0IChjKSAyMDA3LCBDbGlmZm9yZCBZYXBwCjs7IEFsbCBy
aWdodHMgcmVzZXJ2ZWQuCgo7OyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGlu
IHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKOzsg
bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zIGFyZQo7OyBtZXQ6Cjs7Cjs7ICAgIC0g
UmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRo
ZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMgbGlzdCBv
ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCjs7
Cjs7ICAgIC0gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg
cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2Us
IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp
c2NsYWltZXIgaW4KOzsgICAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig
b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCjs7ICAgICAgZGlz
dHJpYnV0aW9uLgo7Owo7OyAgICAtIFRoZSBuYW1lcyBvZiB0aGUgY29udHJp
YnV0b3JzIG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUK
OzsgICAgICBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3
aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4KOzsgICAgICBwZXJtaXNz
aW9uLgo7Owo7O1RISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENP
UFlSSUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTCjs7SVMiIEFO
RCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO
RywgQlVUIE5PVCBMSU1JVEVECjs7VE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBCjs7UEFS
VElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBT
SEFMTCBUSEUgQ09QWVJJR0hUIE9XTkVSCjs7T1IgQ09OVFJJQlVUT1JTIEJF
IExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws
IFNQRUNJQUwsCjs7RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFH
RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLAo7O1BST0NVUkVN
RU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0Yg
VVNFLCBEQVRBLCBPUgo7O1BST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ
VElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YKOztM
SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJ
VFksIE9SIFRPUlQgKElOQ0xVRElORwo7O05FR0xJR0VOQ0UgT1IgT1RIRVJX
SVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJ
Uwo7O1NPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklM
SVRZIE9GIFNVQ0ggREFNQUdFLgoKKGRlZnZhciBzdGFydGNoYXJzICI8PCIp
CihkZWZ2YXIgZW5kY2hhcnMgIj4+PSIpCihkZWZ2YXIgZW5kY2h1bmtjaGFy
cyAiQCIpCihkZWZ2YXIgcmVmc3RhcnRjaGFycyAiPDwiKQooZGVmdmFyIHJl
ZmVuZGNoYXJzICI+PiIpIAoKKGRlZnBhcmFtZXRlciAqY2h1bmstaGFzaC10
YWJsZSogKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXF1YWwpKQoKKGRlZmNs
YXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAgICA6aW5pdGFyZyA6Y2h1
bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAiTXVzdCBzdXBwbHkgYSBj
aHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5rLW5hbWUKICAgIDpkb2N1
bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAgIChjaHVuay1jb250ZW50
cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRzCiAgICA6aW5pdGZvcm0g
IiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50cwogICAgOmRvY3VtZW50
YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5jbHVkZSByZWZlcmVuY2Vz
IHRvIG90aGVyIGNodW5rcyIpKSkKCihkZWZ1biBtYWtlLW5ldy1jaHVuayAo
Y3Vyci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1bmst
bmFtZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2UgJ2No
dW5rIDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKKGRlZnVuIGdl
dC1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lKQogIChjaHVuay1j
b250ZW50cyAoZ2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gt
dGFibGUqKSkpCgooZGVmdW4gYWRkLXRvLWNodW5rLWNvbnRlbnRzIChjdXJy
LWNodW5rLW5hbWUgbmV3LWNvbnRlbnRzKQogIChsZXQgKChzdGFydGluZy1j
aHVuay1jb250ZW50cyAoZ2V0LWNodW5rLWNvbnRlbnRzIGN1cnItY2h1bmst
bmFtZSkpKQogICAgKGlmIChzdHJpbmctZXF1YWwgc3RhcnRpbmctY2h1bmst
Y29udGVudHMgIiIpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICBu
ZXctY29udGVudHMpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICAo
Y29uY2F0ZW5hdGUgJ3N0cmluZyBzdGFydGluZy1jaHVuay1jb250ZW50cyAo
c3RyaW5nICNcTmV3bGluZSkKCQkJICAgbmV3LWNvbnRlbnRzKSkpKSkKCihk
ZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAobWFwaGFzaCAjJyhsYW1iZGEg
KGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4lIiBrIHYpKSAqY2h1bmstaGFz
aC10YWJsZSopKQoKKGRlZnVuIHJlYWQtaW4tY2h1bmsgKGN1cnItY2h1bmst
bmFtZSBmaWxlbmFtZSkKICAobGV0ICgobmV4dGxpbmUgKHJlYWQtbGluZSBm
aWxlbmFtZSBuaWwpKSkKICAgIChpZiAob3IgKG5vdCAoc2VhcmNoIGVuZGNo
dW5rY2hhcnMgbmV4dGxpbmUpKSAKICAgICAgICAgICAgKHNlYXJjaCAoY29u
Y2F0ZW5hdGUgJ3N0cmluZyAoc3RyaW5nICNcIikgZW5kY2h1bmtjaGFycykK
CSAgICAgICAgICAgICBuZXh0bGluZSkpIAoJKHByb2duCgkgIChhZGQtdG8t
Y2h1bmstY29udGVudHMgY3Vyci1jaHVuay1uYW1lIG5leHRsaW5lKQoJICAo
cmVhZC1pbi1jaHVuayBjdXJyLWNodW5rLW5hbWUgZmlsZW5hbWUpKSkpKQoK
KGRlZnVuIGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayAoaW5wdXRzdHJpbmcg
ZmlsZW5hbWUpCiAgIChsZXQgKCh0ZXN0c3RyaW5nIChzdHJpbmctdHJpbSAi
ICIgaW5wdXRzdHJpbmcpKSkKICAgICAoaWYgKD4gKGxlbmd0aCB0ZXN0c3Ry
aW5nKSAzKQogICAgIChpZiAoYW5kIChzdHJpbmctZXF1YWwgc3RhcnRjaGFy
cyB0ZXN0c3RyaW5nIDplbmQyIChsZW5ndGggc3RhcnRjaGFycykpCgkgICAg
ICAoc3RyaW5nLWVxdWFsIGVuZGNoYXJzIHRlc3RzdHJpbmcgCgkJCSAgICAg
OnN0YXJ0MiAoLSAobGVuZ3RoIHRlc3RzdHJpbmcpIChsZW5ndGggZW5kY2hh
cnMpKQoJCQkgICAgIDplbmQyIChsZW5ndGggdGVzdHN0cmluZykpKQogICAg
ICAgICAobGV0ICgobmV3LWNodW5rLW5hbWUgKHN1YnNlcSB0ZXN0c3RyaW5n
IChsZW5ndGggc3RhcnRjaGFycykKCQkJCSAgICgtIChsZW5ndGggdGVzdHN0
cmluZykgKGxlbmd0aCBlbmRjaGFycykpKSkpCgkgICAobWFrZS1uZXctY2h1
bmsgbmV3LWNodW5rLW5hbWUpCgkgICAocmVhZC1pbi1jaHVuayBuZXctY2h1
bmstbmFtZSBmaWxlbmFtZSkKCSAgIHQpCgkgKSkpKQoKKGRlZnVuIGNoZWNr
LWZvci1yZWZlcmVuY2VkLWNodW5rIChpbnB1dHN0cmluZyBzdGFydHBvcykK
ICAgKGxldCAoKHBvczEgKHNlYXJjaCByZWZzdGFydGNoYXJzIGlucHV0c3Ry
aW5nIDpzdGFydDIgc3RhcnRwb3MpKSkKICAgICAobGV0ICgocG9zMiAoaWYg
cG9zMSAoc2VhcmNoIHJlZmVuZGNoYXJzIGlucHV0c3RyaW5nIDpzdGFydDIg
cG9zMSkpKSkKICAgICAgIChpZiAoYW5kIHBvczEgcG9zMikKCSAgIChwcm9n
bgoJICAgKGlmIChzZWFyY2ggKHN0cmluZyAjXE5ld2xpbmUpIGlucHV0c3Ry
aW5nIDpzdGFydDIgcG9zMSAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDplbmQyIHBvczIpCiAgKGNoZWNrLWZvci1yZWZl
cmVuY2VkLWNodW5rIGlucHV0c3RyaW5nIAogIAkoKyhzZWFyY2ggKHN0cmlu
ZyAjXE5ld2xpbmUpIGlucHV0c3RyaW5nIDpzdGFydDIgcG9zMQoJCQkJCQkg
OmVuZDIgcG9zMikgMSkgKQogIChwcm9nbgogIChsZXQgKChtaWRkbGVzdHJp
bmcgKHN1YnNlcSBpbnB1dHN0cmluZyAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKCsgcG9zMSAobGVuZ3RoIHJlZnN0YXJ0Y2hhcnMpKSAKCQkJ
ICAgICAgcG9zMikpKQogICAgKGlmIChnZXRoYXNoIG1pZGRsZXN0cmluZyAq
Y2h1bmstaGFzaC10YWJsZSopCgkocHJvZ24KCSAgKHNldGYgaW5wdXRzdHJp
bmcgCgkJKGNvbmNhdGVuYXRlICdzdHJpbmcKCQkJICAgICAoc3Vic2VxIGlu
cHV0c3RyaW5nIDAgcG9zMSkKCQkJICAgICAoZ2V0LWNodW5rLWNvbnRlbnRz
IG1pZGRsZXN0cmluZykKCQkJICAgICAoc3Vic2VxIGlucHV0c3RyaW5nIAoJ
CQkgICAgICAgICAgICAgKCsgcG9zMiAobGVuZ3RoIHJlZmVuZGNoYXJzKSkp
KSkKCSAgKGNoZWNrLWZvci1yZWZlcmVuY2VkLWNodW5rIGlucHV0c3RyaW5n
IHBvczEpKQoJKGVycm9yICAiflMgd2FzIG5vdCBmb3VuZCBpbiBoYXNoIHRh
YmxlLiIgbWlkZGxlc3RyaW5nKSkpKSkpCgkgICBpbnB1dHN0cmluZykpKSkK
CihkZWZ1biBsb2FkLXBhbXBobGV0LWZpbGUgKGZpbGVuYW1lKQogIChsZXQg
KChpbiAob3BlbiBmaWxlbmFtZSA6aWYtZG9lcy1ub3QtZXhpc3QgbmlsKSkp
CiAgICAod2hlbiBpbgogICAgICAobG9vcCBmb3IgbGluZSA9IChyZWFkLWxp
bmUgaW4gbmlsKQoJICAgIHdoaWxlIGxpbmUgZG8gKGNoZWNrLWZvci10b3Bs
ZXZlbC1jaHVuayBsaW5lIGluKSkKICAgICAgKGNsb3NlIGluKSkpKQoKKGRl
ZnVuIHdyaXRlLW91dHB1dC1maWxlIChmaWxlbmFtZSBjaHVua25hbWUpCiAg
KGxldCAoKG91dHB1dHN0cmVhbSAob3BlbiBmaWxlbmFtZSA6ZGlyZWN0aW9u
IDpvdXRwdXQgOmlmLWV4aXN0cyA6c3VwZXJzZWRlKSkpCiAgICAod3JpdGUt
c3RyaW5nIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAKCQkgICAoZ2V0
LWNodW5rLWNvbnRlbnRzIGNodW5rbmFtZSkgMCkgb3V0cHV0c3RyZWFtKQog
ICAgKGNsb3NlIG91dHB1dHN0cmVhbSkpKQoKKGRlZnVuIG5vdGFuZ2xlIChm
aWxlaW5uYW1lIGZpbGVvdXRuYW1lICZvcHRpb25hbCAoY2h1bmtuYW1lICIq
IikpCiAgKGNscmhhc2ggKmNodW5rLWhhc2gtdGFibGUqKQogIChsb2FkLXBh
bXBobGV0LWZpbGUgZmlsZWlubmFtZSkKICAod3JpdGUtb3V0cHV0LWZpbGUg
ZmlsZW91dG5hbWUgY2h1bmtuYW1lKQogIChjbHJoYXNoICpjaHVuay1oYXNo
LXRhYmxlKikp
\start
Date: Fri, 16 Feb 2007 16:04:28 +0600 (NOVT)
From: Andrey G. Grozin
To: Bill Page
Subject: Re: build-improvements without external noweb: is it supposed to work?
Cc: Gabriel Dos Reis
On Wed, 14 Feb 2007, Bill Page wrote:
> Quoting Andrey G. Grozin:
>> ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
>> '(progn (mapcar (function (lambda (x) (load x))) \
>> (quote ( "boothdr.o" "exports.o" "npextras.o"
>> "stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
>> "stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
>> "stage0/tytree1.o"))) \
>> (system::save-system "bootsys"))'
>>
>> Error: The variable |
>> | is unbound.
>> Fast links are on: do (si::use-fast-links nil) for debugging
>> Error signalled by PROGN.
>> Broken at MAPCAR. Type :H for Help.
Doing ./configure and make in a freshly checked-out tree with the latest
Bill's patch, I get exactly the same error:
./../..//build/i686-pc-linux/bin/lisp -batch -eval \
'(progn (mapcar (function (lambda (x) (load x))) \
(quote ( "boothdr.o" "exports.o" "npextras.o"
"stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
"stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
"stage0/tytree1.o"))) \
(system::save-system "bootsys"))'
Error: The variable |
| is unbound.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by PROGN.
Broken at MAPCAR. Type :H for Help.
Maybe, changes of this kind are needed in several places?
\start
Date: Fri, 16 Feb 2007 13:44:50 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp
> I hesitate to say it's useful, but I have what appears to be a (more or
> less) working notangle command in lisp. It successfully handles a
> couple test files, and although I haven't inspected the results it
> handled most of the contents of boot and interp without crashing.
> Unfortunately it's performance is worse than abysmal.
Your method of appending content to a chunk was quadratic. Below
is a diff changing this to linear method, gives much better speed (at
least on "nag-e02.boot.pamphlet") but still much slower than Debian
notangle (0.48s sbcl, 0.028s system version). AFAICS reading
pamphlets is still slow (takes 0.4s on "nag-e02.boot.pamphlet").
--- cl-notangle.lisp.pamphlet 2007-02-16 11:57:23.000000000 +0100
+++ cl-notangle.lisp.pamphlet 2007-02-16 13:03:47.000000000 +0100
@@ -365,13 +365,21 @@
<<readin-chunk>>=
(defun read-in-chunk (curr-chunk-name filename)
- (let ((nextline (read-line filename nil)))
- (if (or (not (search endchunkchars nextline))
- (search (concatenate 'string (string #\") endchunkchars)
- nextline))
- (progn
- (add-to-chunk-contents curr-chunk-name nextline)
- (read-in-chunk curr-chunk-name filename)))))
+ (let ((lines nil))
+ (loop for nextline = (read-line filename nil)
+ while (or (not (search endchunkchars nextline))
+ (search (concatenate 'string (string #\") endchunkchars)
+ nextline))
+ do
+ (progn
+ (push nextline lines)
+ (push (string #\Newline) lines)))
+ (if lines
+ (progn
+ (pop lines)
+ (add-to-chunk-contents curr-chunk-name
+ (apply #'concatenate 'string
+ (reverse lines)))))))
@
\start
Date: Fri, 16 Feb 2007 06:03:06 -0800 (PST)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: A first attempt at a notangle in Lisp
--- Waldek Hebisch wrote:
> Your method of appending content to a chunk was quadratic. Below
> is a diff changing this to linear method, gives much better speed (at
> least on "nag-e02.boot.pamphlet") but still much slower than Debian
> notangle (0.48s sbcl, 0.028s system version). AFAICS reading
> pamphlets is still slow (takes 0.4s on "nag-e02.boot.pamphlet").
Thanks! Wow, did that ever make a difference. Where you running the
above after compiling cl-notangle.lisp or just loading it? Running the
same comparison (I'm in SBCL 1.01, by the way) I've now got:
CL-USER> (time (load "./setup/runnotangle.lisp"))
Evaluation took:
4.93 seconds of real time
0.848053 seconds of user run time
0.728046 seconds of system run time
[Run times include 0.1 seconds GC run time.]
0 calls to %EVAL
0 page faults and
12,686,456 bytes consed.
T
CL-USER> (load "./setup/cleardirs.lisp")
T
CL-USER> (time (load "./setup/runlispnotangle.lisp"))
Evaluation took:
9.45 seconds of real time
9.208575 seconds of user run time
0.240015 seconds of system run time
[Run times include 0.248 seconds GC run time.]
0 calls to %EVAL
0 page faults and
175,565,168 bytes consed.
Which doesn't achieve Tim's goal of a faster notangle than notangle but
is usably quick. Thanks Waldek!
I attached v0.2 with this patch applied.
CY
P.S. - I know the descriptive text in the file needs quite a lot of
improvement (for example I don't cite any sources at the moment) but
them's the breaks when it's 2am and you have to work tomorrow. If
there is real interest in this as a tool for Axiom I'll try to spruce
it up some more.
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
--0-631001030-1171634586=:41236
XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0gClx1c2VwYWNrYWdle2F4aW9tfQpc
YmVnaW57ZG9jdW1lbnR9Clx0aXRsZXtjbC1ub3RhbmdsZSB2MC4yIC0gYSBM
aXRlcmF0ZSBQcm9ncmFtIENvZGUgRXh0cmFjdG9yIGZvciBBTlNJIENvbW1v
biBMaXNwfSAKXGF1dGhvcntDbGlmZm9yZCBZYXBwLCBXYWxkZWsgSGViaXNj
aH0KXG1ha2V0aXRsZQpcYmVnaW57YWJzdHJhY3R9CiAgTk9XRUIgaXMgdGhl
IGNsYXNzaWMgbGFuZ3VhZ2UgYWdub3N0aWMgdG9vbCB1c2VkIGZvciBsaXRl
cmF0ZSBwcm9ncmFtbWluZwogIGluIHRoZSBzdHlsZSBvZiBLbnV0aCdzIG9y
aWdpbmFsIFdFQi4gIFRoaXMgdG9vbCBpbXBsZW1lbnRzIGEgbWV0aG9kIGlu
CiAgbGlzcCBmb3IgZXh0cmFjdGluZyB0aGUgc291cmNlIGNvZGUgZnJvbSBs
aXRlcmF0ZSBkb2N1bWVudHMuClxlbmR7YWJzdHJhY3R9ClxlamVjdApcdGFi
bGVvZmNvbnRlbnRzClxlamVjdAoKXHNlY3Rpb257VXBkYXRlc30KClxub2lu
ZGVudCBcdmVyYkAoMi8xNS8wNylAIC0gSW5pdGlhbCB2MC4xIHJlbGVhc2Vk
Clxub2luZGVudCBcdmVyYkAoMi8xNi8wNylAIC0gV2FsdGVyIEhlYmlzY2gg
cHJvdmlkZXMgbGluZWFyIHRpbWUgcmVhZC1pbi1jaHVuawoKXHNlY3Rpb257
Q29weXJpZ2h0IGFuZCBMaWNlbnNlfQoKIFRoaXMgcHJvZ3JhbSBpcyBhdmFp
bGFibGUgdW5kZXIgdGhlIE1vZGlmaWVkIEJTRCBsaWNlbnNlLiAgVGhlIHdv
cmRpbmcKIG9mIHRoZSBmaWxlIHdhcyBjaGFuZ2VkIHNsaWdodGx5LCBhcyB0
aGVyZSBpcyBubyBvcmdhbml6YXRpb24gYXNzb2NpYXRlZAogd2l0aCB0aGUg
Y3JlYXRpb24gb2YgdGhpcyBmaWxlLCBidXQgaWYgdGhlcmUgaXMgYW55IHF1
ZXN0aW9uIHRoZSBsaWNlbnNlCiBpcyBpbnRlbmRlZCB0byBiZSBNb2RpZmll
ZCBCU0QuCgo8PGNvcHlyaWdodD4+PQo7OyBDb3B5cmlnaHQgKGMpIDIwMDcs
IENsaWZmb3JkIFlhcHAKOzsgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCkAKCjw8
bGljZW5zZT4+PQo7OyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJj
ZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKOzsgbW9kaWZp
Y2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv
d2luZyBjb25kaXRpb25zIGFyZQo7OyBtZXQ6Cjs7Cjs7ICAgIC0gUmVkaXN0
cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92
ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25k
aXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCjs7Cjs7ICAg
IC0gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9k
dWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMg
bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt
ZXIgaW4KOzsgICAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIg
bWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCjs7ICAgICAgZGlzdHJpYnV0
aW9uLgo7Owo7OyAgICAtIFRoZSBuYW1lcyBvZiB0aGUgY29udHJpYnV0b3Jz
IG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUKOzsgICAg
ICBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3aXRob3V0
IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4KOzsgICAgICBwZXJtaXNzaW9uLgo7
Owo7O1RISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdI
VCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTCjs7SVMiIEFORCBBTlkg
RVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU
IE5PVCBMSU1JVEVECjs7VE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg
TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBCjs7UEFSVElDVUxB
UiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBTSEFMTCBU
SEUgQ09QWVJJR0hUIE9XTkVSCjs7T1IgQ09OVFJJQlVUT1JTIEJFIExJQUJM
RSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJ
QUwsCjs7RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElO
Q0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLAo7O1BST0NVUkVNRU5UIE9G
IFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE
QVRBLCBPUgo7O1BST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikg
SE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YKOztMSUFCSUxJ
VFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9S
IFRPUlQgKElOQ0xVRElORwo7O05FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB
UklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUwo7O1NP
RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9G
IFNVQ0ggREFNQUdFLgoKQCAKClxlamVjdApcc2VjdGlvbntJbnRyb2R1Y3Rp
b24gLSBOT1dFQiBhbmQgTGl0ZXJhdGUgUHJvZ3JhbW1pbmd9CgpUaGUgY29u
Y2VwdCBvZiBMaXRlcmF0ZSBQcm9ncmFtbWluZyB0cmFjZXMgYmFjayB0byBE
b25hbGQgS251dGgsIHRoZSBhdXRob3IKb2YgdGhlIFRlWCB0eXBlc2V0dGlu
ZyBzeXN0ZW0gYW5kIENXRUIuICBUaGUgZnVuZGFtZW50YWwgaWRlYSBvZiBs
aXRlcmF0ZSAKcHJvZ3JhbW1pbmcgaXMgdG8gZGV2ZWxvcCB0aGUgY29kZSBh
bmQgZG9jdW1lbnRhdGlvbiBhcyBvbmUgaW50ZWdyYXRlZCB3aG9sZSAKLSBy
YXRoZXIgdGhhbiBoYXZpbmcgc291cmNlIGNvZGUgaW4gb25lIGZpbGUgYW5k
IGRvY3VtZW50YXRpb24gaW4gYW5vdGhlciB0aGUgCnR3byBhcmUgd292ZW4g
dG9nZXRoZXIuICBUaGlzIHBsYWNlcyB0aGUgZW1waGFzaXMgb24gaWRlYXMg
bW9yZSB0aGFuIGNvZGUsIGFuZCAKaXMgaW50ZW5kZWQgdG8gZW5jb3VyYWdl
IHRoZSBjcmVhdGlvbiBvZiBwcm9ncmFtcyB0aGF0IHdpbGwgYmUgdW5kZXJz
dGFuZGFibGUgCmFuZCB1c2FibGUgYXMgbG9uZyBhcyB0aGUgaWRlYXMgYmVo
aW5kIHRoZSBkZXNpZ24gaXRzZWxmIGFyZSB2YWxpZC4KCk9uZSBvZiB0aGUg
cHJhY3RpY2FsIGNvbnNlcXVlbmNlcyBvZiB0aGlzIGlkZWEgaXMgdGhhdCBp
biBvcmRlciBmb3IgdGhlIGNvZGUgCmluIGEgbGl0ZXJhdGUgZG9jdW1lbnQg
dG8gYmUgbG9hZGVkIGludG8gYSBtYWNoaW5lLCBpdCBtdXN0IGJlIGV4dHJh
Y3RlZCBmcm9tIAp0aGUgZG9jdW1lbnQuIFRoaXMgaXMgZnVydGhlciBjb21w
bGljYXRlZCBieSB0aGUgZW1waGFzaXMgb2YgbGl0ZXJhdGUgCnByb2dyYW1t
aW5nIG9uIGlkZWFzIHJhdGhlciB0aGFuIGNvZGUgZGljdGF0aW5nIHRoZSBv
cmRlciBvZiBhIHByb2dyYW1tZXIncyAKd29yay4gIFdFQiBkb2N1bWVudHMg
dGh1cyBhcmUgbm90IG9ubHkgaW50ZXJ3b3ZlbiB0ZXh0IGFuZCBzb3VyY2Ug
Y29kZSwgYnV0IApoYXZlIGNodW5rcyBvZiBjb2RlIGRlZmluZWQgYXQgYXJi
aXRyYXJ5IHBvaW50cyBpbiB0aGUgZG9jdW1lbnQuICBUaGVyZSBpcyAKdXN1
YWxseSBhIHJvb3QgY2h1bmsgd2hpY2ggcGxhY2VzIHRoZSBpbmRpdmlkdWFs
IHBpZWNlcyBpbiB0aGUgY29ycmVjdCBvcmRlciwgCmJ1dCBlYWNoIHBpZWNl
IG1heSBpbiB0dXJuIHJlZmVyZW5jZSBvdGhlciBwaWVjZXMgYW5kIGFsbCBv
ZiB0aGVtIG11c3QgYmUgCmV2ZW50dWFsbHkgcHV0IGluIHRoZSBjb3JyZWN0
IHNlcXVlbmNlIHRvIGFsbG93IHRoZSBtYWNoaW5lIHRvIHJlYWQgdGhlbS4K
CkluIE5PV0VCLCB0aGUgc3BlY2lmaWMgY29tbWFuZCB0aGF0IGRvZXMgdGhp
cyBqb2IgaXMgY2FsbGVkIG5vdGFuZ2xlLiAgVGhlcmUgCmFyZSBvdGhlciBj
b21tYW5kcyB0aGF0IHByb2Nlc3MgdGhlIGRvY3VtZW50IGludG8gdmFyaW91
cyBvdXRwdXQgZm9ybXMsIGJ1dCAKZnJvbSB0aGUgc3RhbmRwb2ludCBvZiB0
aGUgbWFjaGluZSB1bmRlcnN0YW5kaW5nIHRoZSBjb2RlIG5vdGFuZ2xlIGlz
IHRoZSAKbW9zdCBjcml0aWNhbC4KCkhlcmUsIHdlIHdpbGwgaW1wbGVtZW50
IGEgd2F5IGluIGxpc3AgdG8gbG9hZCBhIHBhbXBobGV0IGZpbGUsIEF4aW9t
J3MgZm9ybSAKb2YgbGl0ZXJhdGUgcHJvZ3JhbW1pbmcgZG9jdW1lbnQsIGFu
ZCBleHRyYWN0IHRoZSBjb2RlIGZyb20gaXQuCgoKXHNlY3Rpb257VGhlIFRv
cCBMZXZlbCBGaWxlIFN0cnVjdHVyZX0KCjw8Kj4+PQo8PGNvcHlyaWdodD4+
Cjw8bGljZW5zZT4+Cjw8ZGVsaW1pdGVycz4+Cjw8aGFzaHRhYmxlPj4KPDxj
aHVua2NsYXNzPj4KPDxiYXNpYy1jaHVuay1vcGVyYXRpb25zPj4KPDxyZWFk
aW4tY2h1bms+Pgo8PHRvcGxldmVsLWNodW5rLXNjYW5uaW5nPj4KPDxyZWZl
cmVuY2UtY2h1bmstc2Nhbm5pbmc+Pgo8PGxvYWQtZmlsZT4+Cjw8d3JpdGUt
ZmlsZT4+Cjw8bm90YW5nbGU+PgpAIAoKXHNlY3Rpb257SW5pdGlhbCBEZWZp
bml0aW9uc30KClRoZSBtb3N0IGltcG9ydGFudCBwaWVjZXMgb2YgaW5mb3Jt
YXRpb24gbmVlZGVkIHdoZW4gdW50YW5nbGluZyBhIGZpbGUgYXJlIAp0aGUg
ZGVsaW1pdGluZyBzdHJpbmdzIHVzZWQgdG8gaWRlbnRpZnkgcGFydHMgb2Yg
YSBjaHVuay4gIEFzIGEgcnVsZSwgY2h1bmtzIApjb25zaXN0IG9mIGEgbmFt
ZSwgYSBib2R5LCBhbmQgYW4gZW5kIG9mIGNodW5rIGNoYXJhY3RlciB3aGlj
aCBzaWduaWZpZXMgdGhlIAplbmQgb2YgdGhlIGNvZGUuICBIb3dldmVyLCBi
ZWNhdXNlIGNodW5rcyBtYXkgYWxzbyByZWZlcmVuY2Ugb3RoZXIgY2h1bmtz
LCAKdGhlcmUgYWxzbyBuZWVkIHRvIGJlIGNodW5rIHJlZmVyZW5jZSBmbGFn
cyB0aGF0IGNhbiBiZSBzZWVuIGluc2lkZSB0aGUgYm9keSAKaXRzZWxmLiAg
QXhpb20gY29udmVudGlvbnMgYXJlIHVzZWQgaGVyZSBmb3IgdGhlIGRlZmF1
bHRzLCBidXQgb3RoZXJzIGFyZSAKY2VydGFpbmx5IHBvc3NpYmxlIGFuZCBj
YW4gYmUgYWNoaWV2ZWQgYnkgc2ltcGx5IHJlLWRlZmluaW5nIHRoZXNlIHZh
cmlhYmxlcy4gIApOb3RlLCBob3dldmVyLCB0aGF0IGNvbGxpc2lvbnMgYmV0
d2VlbiBkZWxpbWl0ZXJzIGF0IHRoZSBzYW1lIGxldmVscyAoc2F5LCAKdGhl
IGVuZGluZyBjaGFyYWN0ZXJzIGZvciB0aGUgbmFtZSBvZiB0aGUgY2h1bmsg
YW5kIHRoZSBlbmQgb2YgY2h1bmsgYm9keSAKY2hhcmFjdGVyLCBvciB0aGUg
dHdvIGRlbGltaXRlcnMgdXNlZCBpbnNpZGUgdGhlIGJvZHkgZm9yIHJlZmVy
ZW5jZXMpIHdpbGwgCmFsbW9zdCBjZXJ0YWlubHkgcHJldmVudCBjb3JyZWN0
IHBhcnNpbmcgb2YgdGhlIGZpbGUuCgo8PGRlbGltaXRlcnM+Pj0KKGRlZnZh
ciBzdGFydGNoYXJzICI8PCIpCihkZWZ2YXIgZW5kY2hhcnMgIj4+PSIpCihk
ZWZ2YXIgZW5kY2h1bmtjaGFycyAiQCIpCihkZWZ2YXIgcmVmc3RhcnRjaGFy
cyAiPDwiKQooZGVmdmFyIHJlZmVuZGNoYXJzICI+PiIpIAoKQAoKV2hlbiBy
ZWFkaW5nIGluIGNodW5rcyBhbmQgc3RvcmluZyB0aGVtLCBhIGhhc2ggdGFi
bGUgaXMgdXNlZC4gIFdlIGluaXRpYWxpemUgCnRoYXQgdGFibGUgYXQgdGhl
IGJlZ2lubmluZywgc2luY2UgaXQgaXMgdXNlZCB0aHJvdWdob3V0IHRoZSBw
cm9ncmFtLiAgQW4gCmltcG9ydGFudCBmZWF0dXJlIHRvIG5vdGUgaGVyZSBp
cyB0aGF0IHRoaXMgaGFzaCB0YWJsZSB1c2VzIHRoZSBgYGVxdWFsJycgCmZ1
bmN0aW9uIGZvciBlcXVhbGl0eSB0ZXN0aW5nLCB3aGljaCBpcyBuZWNlc3Nh
cnkgZm9yIHRoZSBoYXNoIHRhYmxlIHRvIHdvcmsgCndpdGggc3RyaW5nIGtl
eXMuICBDaHVuayBuYW1lcyBhcmUgc3RyaW5ncywgYW5kIGEgZGVmYXVsdCBo
YXNoIHRhYmxlIApjb25maWd1cmF0aW9uIGluIExpc3Agd2lsbCBub3QgYWNj
ZXB0IHRoZW0uCgo8PGhhc2h0YWJsZT4+PQooZGVmcGFyYW1ldGVyICpjaHVu
ay1oYXNoLXRhYmxlKiAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkp
CgpACgpcc2VjdGlvbntDaHVuayBzdHJ1Y3R1cmUgaW4gQ0xPU30KCkNMT1Mg
KHRoZSBDb21tb24gTGlzcCBPYmplY3QgU3lzdGVtKSBwcm92aWRlcyBleGNl
bGxlbnQgdG9vbHMgZm9yIGRhdGEgCnN0cnVjdHVyZSBjcmVhdGlvbiBhbmQg
bWFuaXB1bGF0aW9uLiAgV2Ugd2lsbCBtYWtlIG9ubHkgbWlub3IgdXNlIG9m
IGl0IGhlcmUsIAp0byBkZWZpbmUgYSBkYXRhIHN0cnVjdHVyZSB0aGF0IHdp
bGwgaG9sZCBjaHVua3MgYXMgdGhleSBhcmUgcmVhZCBpbiBhbmQgCnBhcnNl
ZC4gIChJdCBpcyBwZXJoYXBzIG5vdCBzdHJpY3RseSBuZWNlc3NhcnkgdG8g
aW5jbHVkZSB0aGUgY2h1bmsgbmFtZSBpbiAKdGhlIGRhdGEgc3RydWN0dXJl
LCBzaW5jZSB0aGUgaGFzaCBjb2RlIGlzIGFsc28gdGhlIGNodW5rIG5hbWUu
KSBUaGlzIApkZWZpbml0aW9uIHdpbGwgYWxzbyBhdXRvbWF0aWNhbGx5IHBy
b2R1Y2UgZnVuY3Rpb25zIHRvIG1hbmlwdWxhdGUgdGhlIApzdHJ1Y3R1cmVz
IHdpdGhpbiB0aGUgY2xhc3MsIGFsdGhvdWdoIHdlIHdpbGwgZGVmaW5lIGNv
bnZlbmllbmNlIGZ1bmN0aW9ucyAKZm9yIHRob3NlIG9wZXJhdGlvbnMgbGF0
ZXIuIFRoZSBjb250ZW50cyBvZiB0aGUgY2h1bmsgYXJlIGluaXRpYWxpemVk
IHRvIHRoZSAKZW1wdHkgc3RyaW5nLgoKPDxjaHVua2NsYXNzPj49CihkZWZj
bGFzcyBjaHVuayAoKQogICgoY2h1bmstbmFtZQogICAgOmluaXRhcmcgOmNo
dW5rLW5hbWUKICAgIDppbml0Zm9ybSAoZXJyb3IgIk11c3Qgc3VwcGx5IGEg
Y2h1bmsgbmFtZS4iKQogICAgOnJlYWRlciBjaHVuay1uYW1lCiAgICA6ZG9j
dW1lbnRhdGlvbiAiTmFtZSBvZiBjaHVuay4iKQogICAoY2h1bmstY29udGVu
dHMKICAgIDppbml0YXJnIDpjaHVuay1jb250ZW50cwogICAgOmluaXRmb3Jt
ICIiCiAgICA6YWNjZXNzb3IgY2h1bmstY29udGVudHMKICAgIDpkb2N1bWVu
dGF0aW9uICJUZXh0IG9mIGNodW5rIC0gbWF5IGluY2x1ZGUgcmVmZXJlbmNl
cyB0byBvdGhlciBjaHVua3MiKSkpCgpACgpcc2VjdGlvbntCYXNpYyBDaHVu
ayBPcGVyYXRpb25zfQoKVGhlcmUgYXJlIHRocmVlIHRoaW5ncyB3ZSB3aWxs
IG5vcm1hbGx5IG5lZWQgdG8gZG8gd2l0aCBjaHVua3M6ICBtYWtlIG5ldyAK
b25lcywgcmVhZCB0aGUgY29udGVudCBvZiBhbHJlYWR5IGV4aXN0aW5nIGNo
dW5rcywgYW5kIGFkZCBkYXRhIHRvIGFscmVhZHkgCmV4aXN0aW5nIGNodW5r
cy4gIENodW5rIGJ1aWxkaW5nIGRvZXMgbm90IG5vcm1hbGx5IG5lZWQgdG8g
cmVtb3ZlIGNvbnRlbnQgLSAKbW9yZSBzdWJ0bGUgbWFuaXB1bGF0aW9uIG9m
IGNvbnRlbnQgaXMgbmVlZGVkIGZvciBoYW5kbGluZyByZWZlcmVuY2VzLCBi
dXQgCnRoYXQgaXMgZGVhbHQgd2l0aCBlbHNld2hlcmUuCgpcc3Vic2VjdGlv
bntOZXcgQ2h1bmtzfQoKQSBuZXcgY2h1bmsgaXMgYWx3YXlzIGFzc3VtZWQg
dG8gYmUgZW1wdHksIHNvIHdlIHNpbXBseSB0YWtlIGEgbmFtZSBhcmd1bWVu
dCAKYW5kIGluaXRpYWxpemUgdGhlIGNodW5rLCBtZXJnaW5nIGl0IGludG8g
dGhlIGNlbnRyYWwgaGFzaCB0YWJsZSBhcyB3ZSAKY3JlYXRlIGl0LiAgVGhp
cyBtZWFucyB0aGUgY2h1bmsgYGBsaXZlcycnIGluIHRoZSBoYXNoIHRhYmxl
IGFuZCBkb2VzIG5vdCAKZXhpc3QgYXMgYSB2YXJpYWJsZSBpbiB0aGUgTGlz
cCBlbnZpcm9ubWVudCwgc28geW91IHdpbGwgbmV2ZXIgdHlwZSAKYGBjaHVu
azEnJyBhbmQgc2VlIHRoZSBjb250ZW50cyBvZiB0aGUgY2h1bmsuCgo8PG5l
dy1jaHVuaz4+PQooZGVmdW4gbWFrZS1uZXctY2h1bmsgKGN1cnItY2h1bmst
bmFtZSkKICAoc2V0ZiAoZ2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5r
LWhhc2gtdGFibGUqKSAKCShtYWtlLWluc3RhbmNlICdjaHVuayA6Y2h1bmst
bmFtZSBjdXJyLWNodW5rLW5hbWUpKSkKCkAKClxzdWJzZWN0aW9ue1JlYWRp
bmcgQ2h1bmsgQ29udGVudHN9CgpCZWNhdXNlIHRoZSBjaHVua3MgYXJlIGNv
bnRhaW5lZCBpbiB0aGUgaGFzaCB0YWJsZSwgd2UgbmVlZCBhIHdheSB0byBz
dXBwbHkgCnRoZSBuYW1lIG9mIGEgY2h1bmsgYW5kIHJldHJpZXZlIHRoZSBj
b250ZW50cy4gIE5vdGUgdGhhdCB0aGlzIHJldHVybnMgCnRoZSBsaXRlcmFs
IHN0cmluZyBvZiB0aGUgY2h1bmsgYW5kIGRvZXMgbm90IHN3YXAgaW4gZGVm
aW5pdGlvbnMgZm9yIApyZWZlcmVuY2VzLgoKPDxnZXQtY2h1bmstY29udGVu
dHM+Pj0KKGRlZnVuIGdldC1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1u
YW1lKQogIChjaHVuay1jb250ZW50cyAoZ2V0aGFzaCBjdXJyLWNodW5rLW5h
bWUgKmNodW5rLWhhc2gtdGFibGUqKSkpCgpACgpcc3Vic2VjdGlvbntBZGRp
bmcgTmV3IENvbnRlbnQgdG8gQ2h1bmtzfQoKQXMgdGhlIGZpbGUgaXMgcmVh
ZCBpbiBsaW5lIGJ5IGxpbmUsIHdlIGRvbid0IGRlZmluZSBjaHVuayBjb250
ZW50cyBpbiBhIApzaW5nbGUgYGBndWxwJycgYnV0IG9uZSBsaW5lIGF0IGEg
dGltZS4gIFNvIHdlIG5lZWQgYSBjb252ZW5pZW50IHdheSB0byBhZGQgCm5l
dyBsaW5lcyB0byB0aGUgY29udGVudHMgb2YgYSBjaHVuayBrbm93aW5nIG9u
bHkgdGhlIG5hbWUgb2YgdGhlIGNodW5rIGFuZCAKdGhlIGNvbnRlbnRzIHRv
IGFkZC4gIFRoZSBvbmx5IG1pbm9yIGRpZmZpY3VsdHkgaGVyZSBpcyB0aGF0
IHJlYWQtbGluZSBpbiAKTGlzcCBkb2Vzbid0IHByZXNlcnZlIG5ld2xpbmVz
IGFzIHBhcnQgb2YgdGhlIHN0cmluZywgd2hpY2ggaXMgbm9ybWFsbHkgdGhl
IApkZXNpcmVkIGJlaGF2aW9yIGJ1dCBub3Qgd2hhdCBpcyBuZWVkZWQgaGVy
ZS4gIFNvIHRoZXJlIGFyZSB0d28gY2FzZXMgLSBpbiAKdGhlIGluaXRpYWwg
Y2FzZSB3aGVuIHRoZSBjb250ZW50cyBhcmUgZW1wdHkgd2Ugc2ltcGx5IGFz
c2lnbiB0aGUgc3RyaW5nIGFzCnRoZSBuZXcgY29udGVudHMuICBJZiB0aGUg
Y29udGVudHMgYXJlIG5vdCBlbXB0eSB3ZSBuZWVkIHRvIGNyZWF0ZSBhIG5l
dyAKc3RyaW5nIGNvbnRhaW5pbmcgdGhlIG9yaWdpbmFsIGNvbnRlbnRzLCBh
IG5ld2xpbmUgY2hhcmFjdGVyLCBhbmQgdGhlIG5ldyAKbGluZS4KCjw8YWRk
LWNodW5rLWNvbnRlbnRzPj49CihkZWZ1biBhZGQtdG8tY2h1bmstY29udGVu
dHMgKGN1cnItY2h1bmstbmFtZSBuZXctY29udGVudHMpCiAgKGxldCAoKHN0
YXJ0aW5nLWNodW5rLWNvbnRlbnRzIChnZXQtY2h1bmstY29udGVudHMgY3Vy
ci1jaHVuay1uYW1lKSkpCiAgICAoaWYgKHN0cmluZy1lcXVhbCBzdGFydGlu
Zy1jaHVuay1jb250ZW50cyAiIikKCShzZXRmIChjaHVuay1jb250ZW50cyAo
Z2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gtdGFibGUqKSkK
CSAgICAgIG5ldy1jb250ZW50cykKCShzZXRmIChjaHVuay1jb250ZW50cyAo
Z2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gtdGFibGUqKSkK
CSAgICAgIChjb25jYXRlbmF0ZSAnc3RyaW5nIHN0YXJ0aW5nLWNodW5rLWNv
bnRlbnRzIChzdHJpbmcgI1xOZXdsaW5lKQoJCQkgICBuZXctY29udGVudHMp
KSkpKQoKQAoKXHN1YnNlY3Rpb257QWxsIEJhc2ljIEZ1bmN0aW9uc30KClRo
ZXNlIHRocmVlIG9wZXJhdGlvbnMgYXJlIHRoZSBjb3JlIG9mIHdoYXQgaXMg
bmVlZGVkLiAgV2Ugd2lsbCBhZGQgb25lIG1vcmUgCmZ1bmN0aW9uIGZvciBj
b252ZW5pZW5jZSBkdXJpbmcgZGVidWdnaW5nLCB3aGljaCBwcmludHMgb3V0
IGFsbCBjaHVua3MgaW4gCnRoZSBoYXNoIHRhYmxlLgoKPDx2aWV3LWFsbD4+
PQooZGVmdW4gdmlldy1hbGwtY2h1bmtzICgpCiAgKG1hcGhhc2ggIycobGFt
YmRhIChrIHYpIChmb3JtYXQgdCAifmEgPT4gfmF+JSIgayB2KSkgKmNodW5r
LWhhc2gtdGFibGUqKSkKCkAKCjw8YmFzaWMtY2h1bmstb3BlcmF0aW9ucz4+
PQo8PG5ldy1jaHVuaz4+Cjw8Z2V0LWNodW5rLWNvbnRlbnRzPj4KPDxhZGQt
Y2h1bmstY29udGVudHM+Pgo8PHZpZXctYWxsPj4KQAoKXHNlY3Rpb257TG9j
YXRpbmcgQ2h1bmtzIGFuZCBDaHVuayBSZWZlcmVuY2VzfQoKVGhlIG1vc3Qg
ZGlmZmljdWx0IHBhcnQgb2YgZGVhbGluZyB3aXRoIGxpdGVyYXRlIHByb2dy
YW1taW5nIGZpbGVzIGlzIHRoZSAKaW50ZXJ3b3ZlbiBzdHJ1Y3R1cmUgdGhh
dCBjb2RlIGNodW5rIHJlZmVyZW5jZXMgY2FuIHByb2R1Y2UuICBUd28gbGV2
ZWxzIGFyZSAKbmVlZGVkIC0gaWRlbnRpZnkgYW5kIHN0b3JlIGRlZmluZWQg
Y2h1bmtzLCBhbmQgc3BvdCByZWZlcmVuY2VzIHRvIGNodW5rcyAKaW5zaWRl
IG9mIGNodW5rIGJvZGllcy4KClxzdWJzZWN0aW9ue0lkZW50aWZ5aW5nIGFu
ZCBTdG9yaW5nIENodW5rcyAtIFRvcCBMZXZlbH0KCkFuIGFzc3VtcHRpb24g
bWFkZSBpcyB0aGF0IGFsbCBjaHVuayBkZWZpbml0aW9ucyBhcmUgYGB0b3Ag
bGV2ZWwnJyAtIHRoYXQgaXMsIApubyBjaHVuayBpcyBkZWZpbmVkIGluIHRo
ZSBib2R5IG9mIGFub3RoZXIgY2h1bmsuICBHcmFudGluZyB0aGF0IGFzc3Vt
cHRpb24sIAppdCBpcyBwb3NzaWJsZSB0byBjaGVjayBlYWNoIHN0cmluZyBh
cyBpdCBpcyByZWFkIHRvIHNlZSBpZiBpdCBpcyB0aGUgc3RhcnQgCm9mIGEg
bmV3IGNodW5rLiAgVGhpcyBpcyBkb25lIHVzaW5nIExpc3Agc3RyaW5nIHNl
YXJjaGluZyBhbmQgc3BhY2UgdHJpbW1pbmcuCkFub3RoZXIgYXNzdW1wdGlv
biBpcyB0aGF0IHRoZSBiZWdpbm5pbmcgaWRlbnRpZmllciBmb3IgYSBjaHVu
ayBpcyBvbiBpdHMgCm93biBsaW5lIC0gdGhpcyBpcyBwcm9iYWJseSBub3Qg
c3RyaWN0bHkgbmVjZXNzYXJ5IGJ1dCBzaG91bGQgYmUgc3RhbmRhcmQgCmNv
bnZlbnRpb24uCgo8PHRvcGxldmVsLWNodW5rLXNjYW5uaW5nPj49CihkZWZ1
biBjaGVjay1mb3ItdG9wbGV2ZWwtY2h1bmsgKGlucHV0c3RyaW5nIGZpbGVu
YW1lKQogICAobGV0ICgodGVzdHN0cmluZyAoc3RyaW5nLXRyaW0gIiAiIGlu
cHV0c3RyaW5nKSkpCiAgICAgKGlmICg+IChsZW5ndGggdGVzdHN0cmluZykg
MykKICAgICAoaWYgKGFuZCAoc3RyaW5nLWVxdWFsIHN0YXJ0Y2hhcnMgdGVz
dHN0cmluZyA6ZW5kMiAobGVuZ3RoIHN0YXJ0Y2hhcnMpKQoJICAgICAgKHN0
cmluZy1lcXVhbCBlbmRjaGFycyB0ZXN0c3RyaW5nIAoJCQkgICAgIDpzdGFy
dDIgKC0gKGxlbmd0aCB0ZXN0c3RyaW5nKSAobGVuZ3RoIGVuZGNoYXJzKSkK
CQkJICAgICA6ZW5kMiAobGVuZ3RoIHRlc3RzdHJpbmcpKSkKICAgICAgICAg
KGxldCAoKG5ldy1jaHVuay1uYW1lIChzdWJzZXEgdGVzdHN0cmluZyAobGVu
Z3RoIHN0YXJ0Y2hhcnMpCgkJCQkgICAoLSAobGVuZ3RoIHRlc3RzdHJpbmcp
IChsZW5ndGggZW5kY2hhcnMpKSkpKQoJICAgKG1ha2UtbmV3LWNodW5rIG5l
dy1jaHVuay1uYW1lKQoJICAgKHJlYWQtaW4tY2h1bmsgbmV3LWNodW5rLW5h
bWUgZmlsZW5hbWUpCgkgICB0KQoJICkpKSkKCkAKClxzdWJzZWN0aW9ue0lk
ZW50aWZ5aW5nIGFuZCBFeHBhbmRpbmcgQ2h1bmsgUmVmZXJlbmNlc30KClRo
ZSBhYm92ZSB3aWxsIHNlcnZlIGZvciB0b3BsZXZlbCBjaHVuayBpZGVudGlm
aWNhdGlvbiwgYnV0IHRoZSB0YXNrIG9mIAppZGVudGlmeWluZyByZWZlcmVu
Y2VzIHRvIGNodW5rcyBpbiB0aGUgYm9keSBvZiBhIGNodW5rIGlzIGEgc2xp
Z2h0bHkgCmRpZmZlcmVudCB0YXNrLiAgQSBsaW5lIHdpbGwgY29udGFpbiBv
bmx5IG9uZSBjaHVuayBkZWZpbml0aW9uLCBidXQgdGhlIApjb250ZW50cyBv
ZiBhIGNodW5rIGJvZHkgbWF5IGNvbnRhaW4gbWFueSBjaHVuayByZWZlcmVu
Y2VzLiAgQSBmdXJ0aGVyIApjb21wbGljYXRpb24gaXMgdGhhdCBldmVuIHdo
ZW4gdGhvc2UgcmVmZXJlbmNlcyBhcmUgZXhwYW5kZWQsIHRoZXkgbWF5IApp
biB0dXJuIGNvbnRhaW4gb3RoZXIgcmVmZXJlbmNlcy4gIFRvIGhhbmRsZSB0
aGlzIGEgcmVjdXJzaXZlIGZ1bmN0aW9uCmlkZW50aWZpZXMgIHRoZSBmaXJz
dCBjaHVuaywgZXhwYW5kcyBpdCwgYnVpbGRzIGEgbmV3IHN0cmluZyBiYXNl
ZCBvbiAKdGhlIGNvbWJpbmF0aW9uICBvZiBvbGQgYW5kIG5ldywgaW5zZXJ0
cyBpbiBwbGFjZSBvZiB0aGUgcmVmZXJlbmNlLCAKYW5kIGNhbGxzIGl0c2Vs
ZiBvbiB0aGUgbmV3IHJlc3VsdC4gSW4gdGhlIGVuZCwgdGhlIHJldHVybmVk
IApzdHJpbmcgd2lsbCBoYXZlIGFsbCByZWZlcmVuY2VzIGV4cGFuZGVkIGFu
ZCBjb25zdGl0dXRlIHRoZSBmaW5hbCBmb3JtIG9mIAp0aGUgY2h1bmsgYXMg
aXQgaXMgdG8gYmUgc2VudCB0byB0aGUgb3V0cHV0IGZpbGUuCgpIb3dldmVy
LCB0aGVyZSBhcmUgc2V2ZXJhbCB0aGluZ3MgdG8gYmUgd2FyeSBvZiB3aGVu
IGRvaW5nIHRoaXMgc2Nhbi4gIFRoZQpmaXJzdCBpcyBhIGJhZCBjaHVuaywg
b3IgYSByZWZlcmVuY2UgY2h1bmsgd2hpY2ggaGFzIG5vIGRlZmluaXRpb24u
ICBUaGlzCmlzIGhhbmRsZWQgYnkgdGhyb3dpbmcgYW4gZXJyb3IgaWYgc3Vj
aCBhIGNodW5rIGlzIGVuY291bnRlcmVkLiAgV2Ugd2lsbAphbHNvIGRlZmlu
ZSBoZXJlIHRoZSBjb3JlIHJvdXRpbmUgZm9yIG1lcmdpbmcgdGhlIHN0cmlu
Z3M6Cgo8PGNvcmUtcmVmPj49Cihwcm9nbgogIChsZXQgKChtaWRkbGVzdHJp
bmcgKHN1YnNlcSBpbnB1dHN0cmluZyAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKCsgcG9zMSAobGVuZ3RoIHJlZnN0YXJ0Y2hhcnMpKSAKCQkJ
ICAgICAgcG9zMikpKQogICAgKGlmIChnZXRoYXNoIG1pZGRsZXN0cmluZyAq
Y2h1bmstaGFzaC10YWJsZSopCgkocHJvZ24KCSAgKHNldGYgaW5wdXRzdHJp
bmcgCgkJKGNvbmNhdGVuYXRlICdzdHJpbmcKCQkJICAgICAoc3Vic2VxIGlu
cHV0c3RyaW5nIDAgcG9zMSkKCQkJICAgICAoZ2V0LWNodW5rLWNvbnRlbnRz
IG1pZGRsZXN0cmluZykKCQkJICAgICAoc3Vic2VxIGlucHV0c3RyaW5nIAoJ
CQkgICAgICAgICAgICAgKCsgcG9zMiAobGVuZ3RoIHJlZmVuZGNoYXJzKSkp
KSkKCSAgKGNoZWNrLWZvci1yZWZlcmVuY2VkLWNodW5rIGlucHV0c3RyaW5n
IHBvczEpKQoJKGVycm9yICAiflMgd2FzIG5vdCBmb3VuZCBpbiBoYXNoIHRh
YmxlLiIgbWlkZGxlc3RyaW5nKSkpKSkpCkAKClRoZSBuZXh0IGNoZWNrIGlz
IGZvciBhIGNhc2Ugd2hlcmUgdGhlIGRlbGltaXRpbmcgY2hhcmFjdGVycyBh
cmUgYnJva2VuCnVwIG92ZXIgdHdvIGxpbmVzLiAgV2Ugd2lsbCBub3QgcmVn
YXJkIHRoaXMgYXMgYSBsZWdhbCBjaHVuayBuYW1lLCBhcwppdCBpcyBhIHJh
dGhlciB1bmxpa2VseSBjaGFyYWN0ZXIgY29tYmluYXRpb24gZm9yIGEgbGFi
ZWwsIGFuZCBpdCBhbHNvCmFsbG93cyB0aGUgYXZvaWRhbmNlIG9mIGFjY2lk
ZW50YWwgY2h1bmsgbmFtZSBtYXRjaGluZyB3aGVuIGl0IGlzIG5vdAppbnRl
bmRlZCAob25lIG9mIHRoZSBjaHVua3MgaW4gdGhpcyBwYW1waGxldCwgZm9y
IGV4YW1wbGUsIHdvdWxkIHRyaWdnZXIKc3VjaCBhbiBlcnJvci4pICBJZiBz
dWNoIGEgY29uZGl0aW9uIGlzIGZvdW5kLCB0aGUgc2NhbiBzaG91bGQgYmUg
cmVzdW1lZApiZXlvbmQgdGhlIG5ld2xpbmUgY2hhcmFjdGVyLgoKPDxjaGVj
ay1mb3ItbmV3bGluZT4+PQooaWYgKHNlYXJjaCAoc3RyaW5nICNcTmV3bGlu
ZSkgaW5wdXRzdHJpbmcgOnN0YXJ0MiBwb3MxIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgOmVuZDIgcG9zMikKICAoY2hl
Y2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgaW5wdXRzdHJpbmcgCiAgCSgrKHNl
YXJjaCAoc3RyaW5nICNcTmV3bGluZSkgaW5wdXRzdHJpbmcgOnN0YXJ0MiBw
b3MxCgkJCQkJCSA6ZW5kMiBwb3MyKSAxKSApCiAgPDxjb3JlLXJlZj4+CkAK
CldpdGggdGhvc2UgdHdvIGNoZWNrcyBpbiBwbGFjZSwgd2Ugbm93IGRlZmlu
ZSB0aGUgdG9wIGxldmVsIGNvbnRyb2wKZm9yIHBvc2l0aW9uaW5nIHRoZSBz
ZWFyY2ggY29tbWFuZC4gIFRvIGF2b2lkIGNvbmZ1c2lvbiBhbmQgdW5uZWVk
ZWQKc2Nhbm5pbmcsIHRoZSBjb21tYW5kIHRha2VzIGEgc3RhcnRpbmcgcG9z
aXRpb24gYXMgYW4gYXJndW1lbnQuICBUaGlzCmFsbG93cyBzdWJzZXF1ZW50
IHJlY3Vyc2l2ZSBjYWxscyB0byBkaWN0YXRlIHRoZWlyIHN0YXJ0aW5nIHBv
c2l0aW9uLAphbmQgdGhlIGluaXRpYWwgY2FsbCBzaW1wbHkgc3BlY2lmaWVz
IHplcm8gYXMgdGhlIGJlZ2lubmluZy4gIEF0IHRoaXMgbGV2ZWwKd2UgYWxz
byBoYXZlIHRoZSBleGl0IGNvbmRpdGlvbiAtIGlmIG9uZSBvciBtb3JlIG9m
IHBvczEgYW5kIHBvczIgYXJlCm5pbCwgdGhhdCBtZWFucyB0aGlzIHBhcnRp
Y3VsYXIgc3RyaW5nIGlzIGNvbXBsZXRlIGFuZCBjYW4gYmUgcmV0dXJuZWQu
Cgo8PHJlZmVyZW5jZS1jaHVuay1zY2FubmluZz4+PQooZGVmdW4gY2hlY2st
Zm9yLXJlZmVyZW5jZWQtY2h1bmsgKGlucHV0c3RyaW5nIHN0YXJ0cG9zKQog
ICAobGV0ICgocG9zMSAoc2VhcmNoIHJlZnN0YXJ0Y2hhcnMgaW5wdXRzdHJp
bmcgOnN0YXJ0MiBzdGFydHBvcykpKQogICAgIChsZXQgKChwb3MyIChpZiBw
b3MxIChzZWFyY2ggcmVmZW5kY2hhcnMgaW5wdXRzdHJpbmcgOnN0YXJ0MiBw
b3MxKSkpKQogICAgICAgKGlmIChhbmQgcG9zMSBwb3MyKQoJICAgKHByb2du
CgkgICA8PGNoZWNrLWZvci1uZXdsaW5lPj4KCSAgIGlucHV0c3RyaW5nKSkp
KQoKQAoKXHNlY3Rpb257UmVhZGluZyBpbiBDaHVua3N9CgpPbmNlIHdlIGhh
dmUgaWRlbnRpZmllZCBhIGNodW5rIGF0IHRoZSB0b3AgbGV2ZWwsIHdlIG11
c3QgcmVhZCBpdCBpbi4gSW4gdGhlIAp0b3BsZXZlbCBmdW5jdGlvbiB0aGF0
IGpvYiBpcyBwYXNzZWQgb2ZmIHRoYXQgam9iIHRvIGEgZnVuY3Rpb24gY2Fs
bGVkIApyZWFkLWluLWNodW5rLiAgcmVhZC1pbi1jaHVuayBpcyB0aGUgZnVu
Y3Rpb24gdGhhdCBwdXRzIGFkZGl0aW9uYWwgbGluZXMgaW50byAKdGhlIGNo
dW5rIGNvbnRlbnRzIHNsb3QgdW50aWwgdGhlIGVuZC1vZi1jaHVuay1ib2R5
IGNoYXJhY3RlciBpcyBzcG90dGVkLiAgCkl0IGFsc28gdXNlcyByZWN1cnNp
b24gLSBpZiB0aGUgbGluZSBpdCByZWFkcyBpc24ndCB0aGUgZW5kLW9mLWJv
ZHkgbWFya2VyLCAKaXQgYXBwZW5kcyB0aGF0IGxpbmUgdG8gdGhlIGNvbnRl
bnRzIGFuZCBjYWxscyBpdHNlbGYgdG8gY2hlY2sgdGhlIG5leHQgCmxpbmUu
ICBJdCBhbHNvIHdpbGwgYXZvaWQgYW4gZW5kLW9mLWJvZHkgbWFya2VyIHdp
dGggYSBkb3VibGUtcXVvdGUgaW4gZnJvbnQKb2YgaXQsIHRvIGFsbG93IHRo
ZSBwcmVzZW5jZSBvZiB0aGF0IGNoYXJhY3RlciBpbiBjZXJ0YWluIHVzZXMu
Cgo8PHJlYWRpbi1jaHVuaz4+PQooZGVmdW4gcmVhZC1pbi1jaHVuayAoY3Vy
ci1jaHVuay1uYW1lIGZpbGVuYW1lKQogIChsZXQgKChsaW5lcyBuaWwpKQog
ICAgIChsb29wIGZvciBuZXh0bGluZSA9IChyZWFkLWxpbmUgZmlsZW5hbWUg
bmlsKQogICAgICAgICAgICB3aGlsZSAob3IgKG5vdCAoc2VhcmNoIGVuZGNo
dW5rY2hhcnMgbmV4dGxpbmUpKQogICAgICAgICAgICAgICAgICAgICAgIChz
ZWFyY2ggKGNvbmNhdGVuYXRlICdzdHJpbmcgKHN0cmluZyAjXCIpIAoJCQkJ
CWVuZGNodW5rY2hhcnMpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbmV4dGxpbmUpKQogICAgICAgICAgICBkbwogICAgICAgICAgICAgICAg
ICAocHJvZ24KICAgICAgICAgICAgICAgICAgICAgKHB1c2ggbmV4dGxpbmUg
bGluZXMpCiAgICAgICAgICAgICAgICAgICAgIChwdXNoIChzdHJpbmcgI1xO
ZXdsaW5lKSBsaW5lcykpKQogICAgICAoaWYgbGluZXMKICAgICAgICAgKHBy
b2duCiAgICAgICAgICAgIChwb3AgbGluZXMpCiAgICAgICAgICAgIChhZGQt
dG8tY2h1bmstY29udGVudHMgY3Vyci1jaHVuay1uYW1lCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoYXBwbHkgIydjb25jYXRlbmF0ZSAnc3RyaW5n
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocmV2ZXJzZSBs
aW5lcykpKSkpKSkKCkAKClxzZWN0aW9ue0ZpbGUgT3BlcmF0aW9uc30KCk5v
dyB0aGF0IHdlIGtub3cgaG93IHRvIGhhbmRsZSBjaHVua3MsIHdlIG9ubHkg
bmVlZCB0byBhcHBseSB0aGF0IGtub3dsZWRnZSAKdG8gc29tZSBwYXJ0aWN1
bGFyIGZpbGUuICBGb3IgdGhpcywgd2UgdXNlIGEgbG9vcCBtYWNybyByYXRo
ZXIgdGhhbiByZWN1cnNpb24uCgo8PGxvYWQtZmlsZT4+PQooZGVmdW4gbG9h
ZC1wYW1waGxldC1maWxlIChmaWxlbmFtZSkKICAobGV0ICgoaW4gKG9wZW4g
ZmlsZW5hbWUgOmlmLWRvZXMtbm90LWV4aXN0IG5pbCkpKQogICAgKHdoZW4g
aW4KICAgICAgKGxvb3AgZm9yIGxpbmUgPSAocmVhZC1saW5lIGluIG5pbCkK
CSAgICB3aGlsZSBsaW5lIGRvIChjaGVjay1mb3ItdG9wbGV2ZWwtY2h1bmsg
bGluZSBpbikpCiAgICAgIChjbG9zZSBpbikpKSkKCkAKCldlIGFsc28gbmVl
ZCB0byBiZSBhYm91dCB0byBvdXRwdXQgdG8gYSBmaWxlLiBUaGUgemVybyBp
biB0aGUgd3JpdGUtc3RyaW5nIApjb21tYW5kIHNpbXBseSB0ZWxscyB0aGUg
c2Nhbm5lciB0byBzdGFydCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBmaWxl
LiAgQXMKaXQgaXMgY3VycmVudGx5IGNvbmZpZ3VyZWQsIHRoZSBvdXRwdXQg
ZmlsZSBpcyBhbHdheXMgb3ZlcndyaXR0ZW4uCgo8PHdyaXRlLWZpbGU+Pj0K
KGRlZnVuIHdyaXRlLW91dHB1dC1maWxlIChmaWxlbmFtZSBjaHVua25hbWUp
CiAgKGxldCAoKG91dHB1dHN0cmVhbSAob3BlbiBmaWxlbmFtZSA6ZGlyZWN0
aW9uIDpvdXRwdXQgOmlmLWV4aXN0cyA6c3VwZXJzZWRlKSkpCiAgICAod3Jp
dGUtc3RyaW5nIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAKCQkgICAo
Z2V0LWNodW5rLWNvbnRlbnRzIGNodW5rbmFtZSkgMCkgb3V0cHV0c3RyZWFt
KQogICAgKGNsb3NlIG91dHB1dHN0cmVhbSkpKQoKQAoKXHNlY3Rpb257UHVs
bGluZyBJdCBUb2dldGhlciAtIFRoZSBub3RhbmdsZSBDb21tYW5kfQoKVGhl
IGZpbmFsLCB0b3AgbGV2ZWwgY29udHJvbCBjb21tYW5kIGlzIG5hbWVkIG5v
dGFuZ2xlIHRvIGNvbmZvcm0gdG8gdGhlIApOT1dFQiBjb252ZW50aW9uLiAg
VGhpcyBjb21tYW5kIGFjY2VwdHMgYW4gaW5wdXQgZmlsZSwgb3V0cHV0IGZp
bGUsIGFuZCAKb3B0aW9uYWxseSB0aGUgbmFtZSBvZiB0aGUgY2h1bmsgYXQg
d2hpY2ggdG8gc3RhcnQgZXh0cmFjdGluZyBjb250ZW50cy4gIApUaGUgZGVm
YXVsdCBjb252ZW50aW9uIG9mIEF4aW9tIGlzIHRvIHVzZSBhbiBhc3Rlcmlz
ayBhcyB0aGUgcm9vdCBub2RlLCBidXQgCnRoaXMgaXMgbm90IHVuaXZlcnNh
bGx5IHRydWUgYW5kIGl0IGlzIHNvbWV0aW1lcyBkZXNpcmFibGUgdG8gb3V0
cHV0IGNvZGUgCmZyb20gb25lIHBhbXBobGV0IGludG8gbXVsdGlwbGUgdGFy
Z2V0IGZpbGVzLCBzdGFydGluZyBhdCBtdWx0aXBsZSByb290cy4gIApJbiB0
aGF0IGNhc2UsIHRoZSBjaHVuayBuYW1lIGlzIHBhc3NlZCB0byBub3Rhcmdl
dCBhcyB3ZWxsLiAgRm9yIGV4YW1wbGU6CgpcYmVnaW57cXVvdGV9Cihub3Rh
bmdsZSBgYGJvb3QucGFtcGhsZXQnJyBgYGJvb3QubGlzcCcnIGBgUkxpc3An
JykKXGVuZHtxdW90ZX0KClxub2luZGVudCB3b3VsZCBleHRyYWN0IGFsbCBj
b2RlIHJlZmVyZW5jZWQgYnkgdGhlIFJMaXNwIGNodW5rLCB3aGVyZWFzCgpc
YmVnaW57cXVvdGV9Cihub3RhbmdsZSBgYGJvb3QucGFtcGhsZXQnJyBgYGJv
b3QuYm9vdCcnKQpcZW5ke3F1b3RlfQoKXG5vaW5kZW50IHdvdWxkIGV4dHJh
Y3QgYWxsIGNvZGUgcmVmZXJlbmNlZCBieSB0aGUgXHZlcmJAJycqJydAIG5v
ZGUuCgpUaGUgbm90YW5nbGUgY29tbWFuZCB3aWxsIGFsd2F5cyBjbGVhciB0
aGUgaGFzaCB0YWJsZSBiZWZvcmUgYW5kIGFmdGVyCnVzZSwgdG8gZW5zdXJl
IG5vIGFjY2lkZW50YWwgY29sbGlzaW9ucyBhbmQgYXZvaWQgdW5uZWNlc3Nh
cnkgbWVtb3J5CnVzYWdlLgoKPDxub3RhbmdsZT4+PQooZGVmdW4gbm90YW5n
bGUgKGZpbGVpbm5hbWUgZmlsZW91dG5hbWUgJm9wdGlvbmFsIChjaHVua25h
bWUgIioiKSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJsZSopCiAgKGxv
YWQtcGFtcGhsZXQtZmlsZSBmaWxlaW5uYW1lKQogICh3cml0ZS1vdXRwdXQt
ZmlsZSBmaWxlb3V0bmFtZSBjaHVua25hbWUpCiAgKGNscmhhc2ggKmNodW5r
LWhhc2gtdGFibGUqKSkKQAoKXGVuZHtkb2N1bWVudH0K
--0-631001030-1171634586=:41236
OzsgQ29weXJpZ2h0IChjKSAyMDA3LCBDbGlmZm9yZCBZYXBwCjs7IEFsbCBy
aWdodHMgcmVzZXJ2ZWQuCgo7OyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGlu
IHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKOzsg
bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zIGFyZQo7OyBtZXQ6Cjs7Cjs7ICAgIC0g
UmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRo
ZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMgbGlzdCBv
ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCjs7
Cjs7ICAgIC0gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg
cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2Us
IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp
c2NsYWltZXIgaW4KOzsgICAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig
b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCjs7ICAgICAgZGlz
dHJpYnV0aW9uLgo7Owo7OyAgICAtIFRoZSBuYW1lcyBvZiB0aGUgY29udHJp
YnV0b3JzIG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUK
OzsgICAgICBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3
aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4KOzsgICAgICBwZXJtaXNz
aW9uLgo7Owo7O1RISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENP
UFlSSUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTCjs7SVMiIEFO
RCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO
RywgQlVUIE5PVCBMSU1JVEVECjs7VE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBCjs7UEFS
VElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBT
SEFMTCBUSEUgQ09QWVJJR0hUIE9XTkVSCjs7T1IgQ09OVFJJQlVUT1JTIEJF
IExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws
IFNQRUNJQUwsCjs7RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFH
RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLAo7O1BST0NVUkVN
RU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0Yg
VVNFLCBEQVRBLCBPUgo7O1BST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ
VElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YKOztM
SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJ
VFksIE9SIFRPUlQgKElOQ0xVRElORwo7O05FR0xJR0VOQ0UgT1IgT1RIRVJX
SVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJ
Uwo7O1NPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklM
SVRZIE9GIFNVQ0ggREFNQUdFLgoKKGRlZnZhciBzdGFydGNoYXJzICI8PCIp
CihkZWZ2YXIgZW5kY2hhcnMgIj4+PSIpCihkZWZ2YXIgZW5kY2h1bmtjaGFy
cyAiQCIpCihkZWZ2YXIgcmVmc3RhcnRjaGFycyAiPDwiKQooZGVmdmFyIHJl
ZmVuZGNoYXJzICI+PiIpIAoKKGRlZnBhcmFtZXRlciAqY2h1bmstaGFzaC10
YWJsZSogKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXF1YWwpKQoKKGRlZmNs
YXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAgICA6aW5pdGFyZyA6Y2h1
bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAiTXVzdCBzdXBwbHkgYSBj
aHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5rLW5hbWUKICAgIDpkb2N1
bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAgIChjaHVuay1jb250ZW50
cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRzCiAgICA6aW5pdGZvcm0g
IiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50cwogICAgOmRvY3VtZW50
YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5jbHVkZSByZWZlcmVuY2Vz
IHRvIG90aGVyIGNodW5rcyIpKSkKCihkZWZ1biBtYWtlLW5ldy1jaHVuayAo
Y3Vyci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1bmst
bmFtZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2UgJ2No
dW5rIDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKKGRlZnVuIGdl
dC1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lKQogIChjaHVuay1j
b250ZW50cyAoZ2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gt
dGFibGUqKSkpCgooZGVmdW4gYWRkLXRvLWNodW5rLWNvbnRlbnRzIChjdXJy
LWNodW5rLW5hbWUgbmV3LWNvbnRlbnRzKQogIChsZXQgKChzdGFydGluZy1j
aHVuay1jb250ZW50cyAoZ2V0LWNodW5rLWNvbnRlbnRzIGN1cnItY2h1bmst
bmFtZSkpKQogICAgKGlmIChzdHJpbmctZXF1YWwgc3RhcnRpbmctY2h1bmst
Y29udGVudHMgIiIpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICBu
ZXctY29udGVudHMpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICAo
Y29uY2F0ZW5hdGUgJ3N0cmluZyBzdGFydGluZy1jaHVuay1jb250ZW50cyAo
c3RyaW5nICNcTmV3bGluZSkKCQkJICAgbmV3LWNvbnRlbnRzKSkpKSkKCihk
ZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAobWFwaGFzaCAjJyhsYW1iZGEg
KGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4lIiBrIHYpKSAqY2h1bmstaGFz
aC10YWJsZSopKQoKKGRlZnVuIHJlYWQtaW4tY2h1bmsgKGN1cnItY2h1bmst
bmFtZSBmaWxlbmFtZSkKICAobGV0ICgobGluZXMgbmlsKSkKICAgICAobG9v
cCBmb3IgbmV4dGxpbmUgPSAocmVhZC1saW5lIGZpbGVuYW1lIG5pbCkKICAg
ICAgICAgICAgd2hpbGUgKG9yIChub3QgKHNlYXJjaCBlbmRjaHVua2NoYXJz
IG5leHRsaW5lKSkKICAgICAgICAgICAgICAgICAgICAgICAoc2VhcmNoIChj
b25jYXRlbmF0ZSAnc3RyaW5nIChzdHJpbmcgI1wiKSAKCQkJCQllbmRjaHVu
a2NoYXJzKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5leHRs
aW5lKSkKICAgICAgICAgICAgZG8KICAgICAgICAgICAgICAgICAgKHByb2du
CiAgICAgICAgICAgICAgICAgICAgIChwdXNoIG5leHRsaW5lIGxpbmVzKQog
ICAgICAgICAgICAgICAgICAgICAocHVzaCAoc3RyaW5nICNcTmV3bGluZSkg
bGluZXMpKSkKICAgICAgKGlmIGxpbmVzCiAgICAgICAgIChwcm9nbgogICAg
ICAgICAgICAocG9wIGxpbmVzKQogICAgICAgICAgICAoYWRkLXRvLWNodW5r
LWNvbnRlbnRzIGN1cnItY2h1bmstbmFtZQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKGFwcGx5ICMnY29uY2F0ZW5hdGUgJ3N0cmluZyAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKHJldmVyc2UgbGluZXMpKSkp
KSkpCgooZGVmdW4gY2hlY2stZm9yLXRvcGxldmVsLWNodW5rIChpbnB1dHN0
cmluZyBmaWxlbmFtZSkKICAgKGxldCAoKHRlc3RzdHJpbmcgKHN0cmluZy10
cmltICIgIiBpbnB1dHN0cmluZykpKQogICAgIChpZiAoPiAobGVuZ3RoIHRl
c3RzdHJpbmcpIDMpCiAgICAgKGlmIChhbmQgKHN0cmluZy1lcXVhbCBzdGFy
dGNoYXJzIHRlc3RzdHJpbmcgOmVuZDIgKGxlbmd0aCBzdGFydGNoYXJzKSkK
CSAgICAgIChzdHJpbmctZXF1YWwgZW5kY2hhcnMgdGVzdHN0cmluZyAKCQkJ
ICAgICA6c3RhcnQyICgtIChsZW5ndGggdGVzdHN0cmluZykgKGxlbmd0aCBl
bmRjaGFycykpCgkJCSAgICAgOmVuZDIgKGxlbmd0aCB0ZXN0c3RyaW5nKSkp
CiAgICAgICAgIChsZXQgKChuZXctY2h1bmstbmFtZSAoc3Vic2VxIHRlc3Rz
dHJpbmcgKGxlbmd0aCBzdGFydGNoYXJzKQoJCQkJICAgKC0gKGxlbmd0aCB0
ZXN0c3RyaW5nKSAobGVuZ3RoIGVuZGNoYXJzKSkpKSkKCSAgIChtYWtlLW5l
dy1jaHVuayBuZXctY2h1bmstbmFtZSkKCSAgIChyZWFkLWluLWNodW5rIG5l
dy1jaHVuay1uYW1lIGZpbGVuYW1lKQoJICAgdCkKCSApKSkpCgooZGVmdW4g
Y2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgKGlucHV0c3RyaW5nIHN0YXJ0
cG9zKQogICAobGV0ICgocG9zMSAoc2VhcmNoIHJlZnN0YXJ0Y2hhcnMgaW5w
dXRzdHJpbmcgOnN0YXJ0MiBzdGFydHBvcykpKQogICAgIChsZXQgKChwb3My
IChpZiBwb3MxIChzZWFyY2ggcmVmZW5kY2hhcnMgaW5wdXRzdHJpbmcgOnN0
YXJ0MiBwb3MxKSkpKQogICAgICAgKGlmIChhbmQgcG9zMSBwb3MyKQoJICAg
KHByb2duCgkgICAoaWYgKHNlYXJjaCAoc3RyaW5nICNcTmV3bGluZSkgaW5w
dXRzdHJpbmcgOnN0YXJ0MiBwb3MxIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgOmVuZDIgcG9zMikKICAoY2hlY2stZm9y
LXJlZmVyZW5jZWQtY2h1bmsgaW5wdXRzdHJpbmcgCiAgCSgrKHNlYXJjaCAo
c3RyaW5nICNcTmV3bGluZSkgaW5wdXRzdHJpbmcgOnN0YXJ0MiBwb3MxCgkJ
CQkJCSA6ZW5kMiBwb3MyKSAxKSApCiAgKHByb2duCiAgKGxldCAoKG1pZGRs
ZXN0cmluZyAoc3Vic2VxIGlucHV0c3RyaW5nIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoKyBwb3MxIChsZW5ndGggcmVmc3RhcnRjaGFycykp
IAoJCQkgICAgICBwb3MyKSkpCiAgICAoaWYgKGdldGhhc2ggbWlkZGxlc3Ry
aW5nICpjaHVuay1oYXNoLXRhYmxlKikKCShwcm9nbgoJICAoc2V0ZiBpbnB1
dHN0cmluZyAKCQkoY29uY2F0ZW5hdGUgJ3N0cmluZwoJCQkgICAgIChzdWJz
ZXEgaW5wdXRzdHJpbmcgMCBwb3MxKQoJCQkgICAgIChnZXQtY2h1bmstY29u
dGVudHMgbWlkZGxlc3RyaW5nKQoJCQkgICAgIChzdWJzZXEgaW5wdXRzdHJp
bmcgCgkJCSAgICAgICAgICAgICAoKyBwb3MyIChsZW5ndGggcmVmZW5kY2hh
cnMpKSkpKQoJICAoY2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgaW5wdXRz
dHJpbmcgcG9zMSkpCgkoZXJyb3IgICJ+UyB3YXMgbm90IGZvdW5kIGluIGhh
c2ggdGFibGUuIiBtaWRkbGVzdHJpbmcpKSkpKSkKCSAgIGlucHV0c3RyaW5n
KSkpKQoKKGRlZnVuIGxvYWQtcGFtcGhsZXQtZmlsZSAoZmlsZW5hbWUpCiAg
KGxldCAoKGluIChvcGVuIGZpbGVuYW1lIDppZi1kb2VzLW5vdC1leGlzdCBu
aWwpKSkKICAgICh3aGVuIGluCiAgICAgIChsb29wIGZvciBsaW5lID0gKHJl
YWQtbGluZSBpbiBuaWwpCgkgICAgd2hpbGUgbGluZSBkbyAoY2hlY2stZm9y
LXRvcGxldmVsLWNodW5rIGxpbmUgaW4pKQogICAgICAoY2xvc2UgaW4pKSkp
CgooZGVmdW4gd3JpdGUtb3V0cHV0LWZpbGUgKGZpbGVuYW1lIGNodW5rbmFt
ZSkKICAobGV0ICgob3V0cHV0c3RyZWFtIChvcGVuIGZpbGVuYW1lIDpkaXJl
Y3Rpb24gOm91dHB1dCA6aWYtZXhpc3RzIDpzdXBlcnNlZGUpKSkKICAgICh3
cml0ZS1zdHJpbmcgKGNoZWNrLWZvci1yZWZlcmVuY2VkLWNodW5rIAoJCSAg
IChnZXQtY2h1bmstY29udGVudHMgY2h1bmtuYW1lKSAwKSBvdXRwdXRzdHJl
YW0pCiAgICAoY2xvc2Ugb3V0cHV0c3RyZWFtKSkpCgooZGVmdW4gbm90YW5n
bGUgKGZpbGVpbm5hbWUgZmlsZW91dG5hbWUgJm9wdGlvbmFsIChjaHVua25h
bWUgIioiKSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJsZSopCiAgKGxv
YWQtcGFtcGhsZXQtZmlsZSBmaWxlaW5uYW1lKQogICh3cml0ZS1vdXRwdXQt
ZmlsZSBmaWxlb3V0bmFtZSBjaHVua25hbWUpCiAgKGNscmhhc2ggKmNodW5r
LWhhc2gtdGFibGUqKSk=
\start
Date: Fri, 16 Feb 2007 15:10:25 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp
Hi Cliff,
Wouldn't it make sense to contact the Texmacs people whether they would
want some literate programming support. Or has Texmacs LP support already?
\start
Date: Fri, 16 Feb 2007 06:59:38 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: A first attempt at a notangle in Lisp
That's a good question. I don't know if they support it - I'll have to
check tonight. At the moment I can't compile TeXmacs for some reason
on my machine, so I'll have to figure that out first. I don't know if
there would be interest on the product side.
The Emacs mode is nice but that syntax highlighting problem is annoying
and is apparently a limitation of mmm-mode - that plus the mathematical
WYSIWYG of TeXmacs could be Very Nice indeed. Don't know how much work
is involved with making TeXmacs nice for our purposes, but it's
probably worth a look.
Cheers,
CY
--- Ralf Hemmecke wrote:
> Hi Cliff,
>
> Wouldn't it make sense to contact the Texmacs people whether they
> would want some literate programming support. Or has Texmacs LP
> support already?
\start
Date: Fri, 16 Feb 2007 17:59:15 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: A first attempt at a notangle in Lisp
Le vendredi 16 f=E9vrier 2007 =E0 13:44 +0100, Waldek Hebisch a =E9crit :=
> > I hesitate to say it's useful, but I have what appears to be a (more =
or
> > less) working notangle command in lisp. It successfully handles a
> > couple test files, and although I haven't inspected the results it
> > handled most of the contents of boot and interp without crashing.
> > Unfortunately it's performance is worse than abysmal.
>
> Your method of appending content to a chunk was quadratic. Below
> is a diff changing this to linear method, gives much better speed (at
> least on "nag-e02.boot.pamphlet") but still much slower than Debian
> notangle (0.48s sbcl, 0.028s system version). AFAICS reading
> pamphlets is still slow (takes 0.4s on "nag-e02.boot.pamphlet").
>
>
> --- cl-notangle.lisp.pamphlet 2007-02-16 11:57:23.000000000 +0100
> +++ cl-notangle.lisp.pamphlet 2007-02-16 13:03:47.000000000 +0100
> @@ -365,13 +365,21 @@
>
> <<readin-chunk>>=
> (defun read-in-chunk (curr-chunk-name filename)
> - (let ((nextline (read-line filename nil)))
> - (if (or (not (search endchunkchars nextline))
> - (search (concatenate 'string (string #\") endchunkchars)
> - nextline))
> - (progn
> - (add-to-chunk-contents curr-chunk-name nextline)
> - (read-in-chunk curr-chunk-name filename)))))
> + (let ((lines nil))
> + (loop for nextline = (read-line filename nil)
> + while (or (not (search endchunkchars nextline))
> + (search (concatenate 'string (string #\") endch=
unkchars)
> + nextline))
> + do
> + (progn
> + (push nextline lines)
> + (push (string #\Newline) lines)))
> + (if lines
> + (progn
> + (pop lines)
> + (add-to-chunk-contents curr-chunk-name
> + (apply #'concatenate 'string
> + (reverse lines)))))))
And another one (it does not remove the last #\Newline):
(defun read-in-chunk (curr-chunk-name filename)
(let* ((nl (string #\Newline))
(lines (loop for nextline = (read-line filename nil)
while (or (not (search endchunkchars nextline))
(search (concatenate 'string (string #\")
endchunkchars)
nextline))
collect (concatenate 'string nextline nl))))
(if lines
(add-to-chunk-contents curr-chunk-name
(apply #'concatenate 'string
lines)))))
Only tested on nag-e02.boot.pamphlet with SBCL.
\start
Date: Fri, 16 Feb 2007 11:24:57 -0600
From: Tim Daly
To: list
Subject: lisp noweb speed issue
Generally doing read or readline calls is a very slow way to read a file.
Use read-sequence instead. The improvement is noticeable.
See <http://www.emmett.ca/~sabetts/slurp.html>
\start
Date: Fri, 16 Feb 2007 19:10:15 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp
On 02/16/2007 03:59 PM, C Y wrote:
> That's a good question. I don't know if they support it - I'll have to
> check tonight. At the moment I can't compile TeXmacs for some reason
> on my machine, so I'll have to figure that out first. I don't know if
> there would be interest on the product side.
Well, every time I try texmacs I get frustrated after a few minutes.
Recently I downloaded TeXmacs-1.0.6.8-static-gnu-linux.tar.gz extracted
and started it. Then I started a Maple session typed just
2 + 3
and ENTER and texmacs stopped to respond.
After setting MATHLINK_PLATFORM I get a few warnings but Mma seems to work.
Anyway, always seem to run into trouble with TeXmacs although I find the
idea very good and I think texmacs is very appropriate as an Axiom GUI
and also (and in particular) for the literate programming way of writing
the Axiom program itself.
> The Emacs mode is nice but that syntax highlighting problem is annoying
> and is apparently a limitation of mmm-mode
Well, I thought you in particular could trace that bug somehow.
Unfortunately, I cannot do serious things in LISP.
\start
Date: Fri, 16 Feb 2007 10:27:05 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: A first attempt at a notangle in Lisp
--- Ralf Hemmecke wrote:
> > The Emacs mode is nice but that syntax highlighting problem is
> > annoying and is apparently a limitation of mmm-mode
>
> Well, I thought you in particular could trace that bug somehow.
I probably can, but my current (imperfect) understanding of the issue
is that it is buried deeply in the controlling of the Emacs syntax
highlighting routines and how they work. It would probably involve
some serious greasemonkey work on mmm-mode's guts (I don't think
mmm-mode is being actively developed any more), and if I'm going to do
that I would rather turn the whole thing into a literate program and
actually understand what it is doing. (I'd probably have to do that
much work anyway to figure out how to handle this.)
> Unfortunately, I cannot do serious things in LISP.
Well, I can't either ;-). No point in letting that stop me though -
given enough head banging you can punch a hole in a brick wall :-).
\start
Date: Fri, 16 Feb 2007 10:36:06 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: lisp noweb speed issue
I'll take a look at read-sequence this weekend and see if I can figure
it out.
Tim, performance tuning and fixing a couple of hacks aside (I need to
look over Ralf's perl solution to make sure I've got my bases covered)
is this something that you think could be used in Axiom? I wrote it
because I want to teach asdf how to handle Axiom's source files by
itself, and for experimental purposes it will probably serve in its
current form, but if there's a real chance of it being used in Axiom
proper I'll put some more time into it. It will probably never be as
flexible as noweb itself but I doubt we need all of that flexibility.
Of course, that begs the noweb side of the question, but that's more
complex than notangle and will probably have to wait a bit.
Cheers,
CY
--- Tim Daly wrote:
> Generally doing read or readline calls is a very slow way to read a
> file.
> Use read-sequence instead. The improvement is noticeable.
>
> See <http://www.emmett.ca/~sabetts/slurp.html>
\start
Date: 16 Feb 2007 04:31:05 -0600
From: Gabriel Dos Reis
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb: is it supposed to work?
Andrey G. Grozin writes:
| On Wed, 14 Feb 2007, Bill Page wrote:
| > Quoting Andrey G. Grozin:
| >> ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
| >> '(progn (mapcar (function (lambda (x) (load x))) \
| >> (quote ( "boothdr.o" "exports.o" "npextras.o"
| >> "stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
| >> "stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
| >> "stage0/tytree1.o"))) \
| >> (system::save-system "bootsys"))'
| >>
| >> Error: The variable |
| >> | is unbound.
| >> Fast links are on: do (si::use-fast-links nil) for debugging
| >> Error signalled by PROGN.
| >> Broken at MAPCAR. Type :H for Help.
| Doing ./configure and make in a freshly checked-out tree with the
| latest Bill's patch, I get exactly the same error:
|
| ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
| '(progn (mapcar (function (lambda (x) (load x))) \
| (quote ( "boothdr.o" "exports.o"
| "npextras.o" "stage0/ptyout.o" "stage0/btincl2.o" "stage0/btscan2.o"
| "stage0/typrops.o" "stage0/btpile2.o" "stage0/typars.o"
| "stage0/tytree1.o"))) \
| (system::save-system "bootsys"))'
I just finished a build with Bill's patch -- there was only one
glitch: there was a missing closing paren.
\start
Date: 16 Feb 2007 20:53:16 +0100
From: Martin Rubey
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp
Cliff Yapp writes:
> --- Ralf Hemmecke wrote:
> > > The Emacs mode is nice but that syntax highlighting problem is annoying
> > > and is apparently a limitation of mmm-mode
> >
> > Well, I thought you in particular could trace that bug somehow.
>
> I probably can,
PLEASE PLEASE DO. In fact, since you say that mmm is roughly dead, maybe you
could resurrect it? It is a wunderful thing, apart from those glitches...
\start
Date: Fri, 16 Feb 2007 21:55:52 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp
Hello Cliff,
On 02/16/2007 08:53 PM, Martin Rubey wrote:
> Cliff Yapp writes:
>
>> --- Ralf Hemmecke wrote:
>>>> The Emacs mode is nice but that syntax highlighting problem is annoying
>>>> and is apparently a limitation of mmm-mode
>>> Well, I thought you in particular could trace that bug somehow.
>> I probably can,
>
> PLEASE PLEASE DO. In fact, since you say that mmm is roughly dead, maybe you
> could resurrect it? It is a wunderful thing, apart from those glitches...
I support Martin. It is really annoying that I have to add %$ after the
end of a code chunk if the code chunk contained an odd number of $'s.
That only happens in XEmacs. but Martin has similar problems with the
double quotes although they seem to be paired correctly.
If you or some other on this mailing list could find the bug in mmm-mode
that would really be wonderful. Martin and me could probably put
together a demonstration file for this syntax-highlighting problem.
\start
Date: Fri, 16 Feb 2007 15:03:27 -0600
From: Tim Daly
To: Cliff Yapp
Subject: lisp lisp noweb speed issue
> is this something you think can be used in Axiom?
Yes, I do. This debate has raged before on this list but I
believe that we need a lisp version of noweb for several reasons.
Your opinions may vary.
1) the )compile command needs to understand pamphlets directly
2) we need tighter integration of the interpreter and documentation
3) the build process will eventually be lisp-only (controversy)
4) we need to be able to experiment with pamphlet formats for new ideas
5) noweb slows considerably as the files get larger, apparently due to
the shell pipe of data from process to process.
(my work pamphlet is now 6M lines, (4k pages of doc, 67k lines of lisp))
\start
Date: Fri, 16 Feb 2007 14:06:25 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: lisp lisp noweb speed issue
--- Tim Daly wrote:
> > is this something you think can be used in Axiom?
>
> Yes, I do. This debate has raged before on this list but I
> believe that we need a lisp version of noweb for several reasons.
What would you consider as the minimal features required to include
cl-notangle (or cl-noweb as the case may be) in Axiom? I would like to
know what the key minimal requirements are so I know what to shoot for
first.
> 1) the )compile command needs to understand pamphlets directly
Agreed.
> 2) we need tighter integration of the interpreter and documentation
Not sure quite how that works but it sounds good.
> 3) the build process will eventually be lisp-only (controversy)
This is my main reason for wanting notangle in lisp. Is the eventual
goal of building in lisp controversial? My understanding is
all-in-lisp is regarded as the best (most portable) way to handle this
process, but the tools were/are lacking - perhaps with notangle in lisp
(and eventually noweb) we can achieve this. The only catch is that we
can't be lisp only if we need to build GCL first, but at least once we
have a running lisp everything else can be lisp. The news that we are
close to replacing old boot with new boot (which is simpler to get
working in ANSI lisp) and an sbcl port are two major pieces of the
puzzle, so I'm trying to add notangle and an asdf based loading system
as the other missing pieces.
> 4) we need to be able to experiment with pamphlet formats for new
> ideas
Yes - I would like to see the default Axiom pamphlet output a little
different (fancier) than it is now (now there's controversy ;-)
> 5) noweb slows considerably as the files get larger, apparently due
> to
> the shell pipe of data from process to process.
> (my work pamphlet is now 6M lines, (4k pages of doc, 67k lines of
> lisp))
Tim, out of curosity how does this version (suboptimal I know) compare
with noweb on that really large file? I'm sure the read commands will
be a killer but it shouldn't be piping data around, at least. (Dunno
if it works in GCL, I've only tested it on sbcl).
\start
Date: Fri, 16 Feb 2007 14:11:15 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: A first attempt at a notangle in Lisp
--- Ralf Hemmecke wrote:
> I support Martin. It is really annoying that I have to add %$ after
> the end of a code chunk if the code chunk contained an odd number of
> $'s. That only happens in XEmacs. but Martin has similar problems
> with the double quotes although they seem to be paired correctly.
I think it's basically that the coloring function for Emacs's syntax
highlighting doesn't skip chunks in mmm-mode when deciding how to
highlight things. That's what would need to be fixed, and it may be
rather non-trivial (but worthwhile) to fix it. I have a feeling it may
wind up being the case that mmm-mode serves as a guide for a new
literate programming mode, rather than being a fix to mmm-mode - we
will see. My major concern is that that behavior of Emacs's syntax
highlighting is not user configurable at all, but I don't know enough
to say.
> If you or some other on this mailing list could find the bug in
> mmm-mode that would really be wonderful. Martin and me could
> probably put together a demonstration file for this syntax-
> highlighting problem.
I've seen it before on the $ symbol, in Emacs. I'll have a look and
see what can be done, but it may be a slow process.
\start
Date: 16 Feb 2007 23:21:46 +0100
From: Martin Rubey
To: Cliff Yapp
Subject: Re: pamphlets
Dear all,
I keep repeating it.
> > 4) we need to be able to experiment with pamphlet formats for new ideas
BEFORE you start developing new ideas, PLEASE look at ALLPROSE. for example by
checking out aldor-combinat
-------------------------------------------------------------------------------
svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
cd combinat/trunk/combinat
notangle -t8 Makefile.nw > Makefile
make dvi
or
make colored dvi
or, if you have tex4ht installed,
make colored html
-------------------------------------------------------------------------------
It does not make sense to reinvent the wheel. A lot of though has gone into
ALLPROSE, and it proved *very* convenient. Note that aldor-combinat is *not* a
small project. I did use ALLPROSE also for very small projects, by the way. It
just works.
\start
Date: 16 Feb 2007 23:23:30 +0100
From: Martin Rubey
To: list
Subject: Summer of code
I just came across
http://code.google.com/support/bin/answer.py?answer=60302&topic=10727
So, who is going to prepare the application for google SOC?
If nobody volonteers, I'll do it. I'd propose a HyperDoc replacement using the
ALLPROSE format.
\start
Date: Fri, 16 Feb 2007 18:00:53 -0500
From: Cliff Yapp
To: Martin Rubey
Subject: Re: pamphlets
Martin Rubey wrote:
> Dear all,
>
> I keep repeating it.
>
>>> 4) we need to be able to experiment with pamphlet formats for new ideas
>
> BEFORE you start developing new ideas, PLEASE look at ALLPROSE. for example by
> checking out aldor-combinat
>
> -------------------------------------------------------------------------------
> svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
>
> cd combinat/trunk/combinat
>
> notangle -t8 Makefile.nw > Makefile
>
> make dvi
>
> or
>
> make colored dvi
Martin, I'm failing on the latter command with:
! TeX capacity exceeded, sorry [grouping levels=255].
\@textcolor #1#2#3->\protect \leavevmode {
\color #1{#2}#3}
l.148 ...YVERSION}}\\{{projectname}{projectname}}}
\nwindexuse{LIBRARYVERSION...
Do I need to tweak a texmf.cnf setting or some such?
\start
Date: 16 Feb 2007 17:16:43 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [437] branches/wh-sandbox
Waldek Hebisch writes:
[...]
| Modified: branches/wh-sandbox/ChangeLog.wh
| ===================================================================
| --- branches/wh-sandbox/ChangeLog.wh 2007-02-16 10:31:28 UTC (rev 436)
| +++ branches/wh-sandbox/ChangeLog.wh 2007-02-16 21:41:44 UTC (rev 437)
| @@ -1,3 +1,22 @@
| +2007-02-16 Waldek Hebisch Waldek Hebisch
| +
| + Build depsys using Shoe.
| + * src/interp/Makefile.pamphlet: Use bootsys to translate
| + depsys boot files. Do not include c-util in depsys.
| + * src/interp/Makefile.in: Regenerate.
| + * src/interp/c-util.boot.pamphlet: Remove bootstrap Lisp.
| + * src/interp/clam.boot.pamphlet: Adjust for Shoe, remove
| + bootstrap Lisp.
| + * src/interp/g-boot.boot.pamphlet: Likewise.
| + * src/interp/g-util.boot.pamphlet: Likewise.
| + * src/interp/interp-proclaims.lisp: Likewise.
| + * src/interp/parse.boot.pamphlet: Likewise.
| + * src/interp/postpar.boot.pamphlet: Likewise.
| + * src/interp/slam.boot.pamphlet: Likewise.
| + * src/interp/vmlisp.lisp.pamphlet: AXIOM-MEMBER: new function
| + * src/interp/interp-proclaims.lisp: Mention it.
| + * src/interp/sys-pkg.lisp.pamphlet: Likewise.
Interesting. I had similar (and more) patches like that in my local
tree as of 2006-12-26. I never committed it because there was a small
catch -- which I can't explain right now because I don't have all the
elements handy :-( Good to see someone is catching on :-)
\start
Date: Sat, 17 Feb 2007 00:36:30 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: pamphlets
>> make colored dvi
> Martin, I'm failing on the latter command with:
> ! TeX capacity exceeded, sorry [grouping levels=255].
> \@textcolor #1#2#3->\protect \leavevmode {
\color #1{#2}#3}
> l.148 ...YVERSION}}\\{{projectname}{projectname}}}
> \nwindexuse{LIBRARYVERSION...
> Do I need to tweak a texmf.cnf setting or some such?
I don't know exactly what you have done, and although I have increase my
pool sizes locally, it is very probably not the reason for the problem.
I guess, there might be something missing on your computer.
Maybe you first install "packaged-allprose" from
http://www.risc.uni-linz.ac.at/people/hemmecke/aldor/allprose/index.html
in particular you should install the newest version of srcltx.sty.
ALLPROSE needs at least version 1.4. (I have the suspicion that this
could be the reason for this strange error message.)
Try first srcltx and then packaged-allprose. Then let me know.
\start
Date: Sat, 17 Feb 2007 00:40:11 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [437] branches/wh-sandbox
Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
>
> [...]
>
> | Modified: branches/wh-sandbox/ChangeLog.wh
> | ===================================================================
> | --- branches/wh-sandbox/ChangeLog.wh 2007-02-16 10:31:28 UTC (rev 436)
> | +++ branches/wh-sandbox/ChangeLog.wh 2007-02-16 21:41:44 UTC (rev 437)
> | @@ -1,3 +1,22 @@
> | +2007-02-16 Waldek Hebisch Waldek Hebisch
> | +
> | + Build depsys using Shoe.
> | + * src/interp/Makefile.pamphlet: Use bootsys to translate
> | + depsys boot files. Do not include c-util in depsys.
> | + * src/interp/Makefile.in: Regenerate.
> | + * src/interp/c-util.boot.pamphlet: Remove bootstrap Lisp.
<snip>
> Interesting. I had similar (and more) patches like that in my local
> tree as of 2006-12-26. I never committed it because there was a small
> catch -- which I can't explain right now because I don't have all the
> elements handy :-( Good to see someone is catching on :-)
>
The patch is more tricky than it looks like: greping for suspected
keywords give tons of false positives and in first shot I missed few
places (and I dicovered that a few more bad keywords). And I still
use depsys for to translate c-util (trying to use bootsys gives me
some misterious errors).
I have checked that resulting Lisp (output from depsys and interpsys)
is identical (modulo gensymed names) so the patch works reasonably,
but there is still risk of bugs in rarely used code.
\start
Date: Sat, 17 Feb 2007 09:04:01 -0500
From: Cliff Yapp
To: list
Subject: mmm-noweb and fontification
In case this triggers a flag for anybody, it looks like this might
be what we need (or mmm-mode needs anyway) to fontify in such a way
that chunks are avoided:
;;; Fontification functions.
;; Rather than the function, e.g., `font-lock-fontify-region' containing
;; the code to fontify a region, the function runs the function whose
;; name is the value of the variable, e.g.,
;; `font-lock-fontify-region-function'. Normally, the value of this
;; variable is, e.g., `font-lock-default-fontify-region'
;; which does contain the code to fontify a region. However, the value
;; of the variable could be anything and thus, e.g.,
;;`font-lock-fontify-region' could do anything. The indirection of the
;; fontification functions gives major modes the capability of modifying
;; the way font-lock.el fontifies. Major modes can modify the values
;; of, e.g., `font-lock-fontify-region-function',
;; via the variable `font-lock-defaults'.
;; Languages that contain text normally contained in different major
;; modes could define their own fontification functions that treat text
;; differently depending on its context. For example, Perl mode could
;; arrange that here docs are fontified differently than Perl code. Or
;; Yacc mode could fontify rules one way and C code another. Neat!
That sounds like the ticket, now to figure out how to use it!
\start
Date: Sun, 18 Feb 2007 00:10:37 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Lisp format in sf.spad.pamphlet
> Hello,
>
> I have introduced two bugs in DFLOAT when I sent a patch against
> sf.spad.pamphlet (outputting routine). Try, for example,
> complex(1.7,-2.3@SF) or 3.0*x^3+-2.7@SF*x^2. Furthermore, the directive
> used ("~G") is not "the" good one (it's not portable, the directive
> works this way only on GCL). Patch in attachment (I have used the Float
> method (via 'message')).
>
> A suggestion, what about using )spool to produce *.output file?
> (to simplify the comparison via diff of two versions of Axiom (different
> banners)).
>
> Greg
>
> PS : Tested on Gold and Build-improvements (should work on Wh-sandbox, I
> think). My tests were : building from scratch, tracing outputTran and
> testing all outputting formats (algebra, fortran, tex etc...).
Included now in wh-sandbox (the Lisp part was not needed, since wh-sandbox
now contains no algebra bootstrap Lisp).
\start
Date: Sat, 17 Feb 2007 15:58:03 -0800 (PST)
From: Cliff Yapp
To: list
Subject: No progress on notangle :-(
I have tried to use read-sequence to load a file quickly, which works
fine, but I'm afraid I haven't done too well with the problem of
working with the resulting string. The code so far is actually slower
than the earlier version, and from what I can tell the primary issue
seems to be too many subseq operations on the big one-pamphlet string.
I tried leaving the string intact and just identifying positions rather
than chopping it off as I scanned, but the searches got progressively
more expensive even though I was supplying new start positions.
There's probably a better way to do it or an obvious mistake in the way
I have done it, but I'm afraid I've been staring at it a bit too long.
(defvar startchars "<<")
(defvar endchars ">>=")
(defvar endchunkchars "@")
(defvar refstartchars "<<")
(defvar refendchars ">>")
(defparameter *chunk-hash-table* (make-hash-table :test 'equal))
(defclass chunk ()
((chunk-name
:initarg :chunk-name
:initform (error "Must supply a chunk name.")
:reader chunk-name
:documentation "Name of chunk.")
(chunk-contents
:initarg :chunk-contents
:initform ""
:accessor chunk-contents
:documentation "Text of chunk - may include references to other
chunks")))
(defun make-new-chunk (curr-chunk-name curr-chunk-contents)
(setf (gethash curr-chunk-name *chunk-hash-table*)
(make-instance 'chunk :chunk-name curr-chunk-name
:chunk-contents curr-chunk-contents)))
(defun get-chunk-contents (curr-chunk-name)
(chunk-contents (gethash curr-chunk-name *chunk-hash-table*)))
(defun view-all-chunks ()
(maphash #'(lambda (k v) (format t "~a => ~a~%" k v))
*chunk-hash-table*))
(defun check-for-referenced-chunk (inputstring startpos)
(let ((pos1 (search refstartchars inputstring :start2 startpos)))
(let ((pos2 (if pos1 (search refendchars inputstring :start2
pos1))))
(if (and pos1 pos2)
(progn
(if (search (string #\Newline) inputstring :start2 pos1
:end2 pos2)
(check-for-referenced-chunk inputstring
(+(search (string #\Newline) inputstring :start2
pos1
:end2 pos2)
1) )
(progn
(let ((middlestring (subseq inputstring
(+ pos1 (length
refstartchars))
pos2)))
(if (gethash middlestring *chunk-hash-table*)
(progn
(setf inputstring
(concatenate 'string
(subseq inputstring 0 pos1)
(get-chunk-contents
middlestring)
(subseq inputstring
(+ pos2 (length
refendchars)))))
(check-for-referenced-chunk inputstring pos1))
(error "~S was not found in hash table."
middlestring))))))
inputstring))))
(defun check-for-newline-in-name (endofname pamphletfile)
(let ((newlinepos (search (string #\Newline) pamphletfile :end2
endofname :from-end t))
(startcharspos (search startchars pamphletfile :end2 endofname
:from-end t)))
(if newlinepos
(if (> newlinepos startcharspos) t))))
(defun find-next-chunk (startingpoint pamphletfile)
(let ((endofname (search endchars pamphletfile :start2
startingpoint))
(startofname) (startofbody) (endofbody))
(if endofname
(if (check-for-newline-in-name endofname pamphletfile)
(find-next-chunk (+ endofname (length endchars)) pamphletfile)
(progn
(setf startofname (+ (length startchars) (search startchars
pamphletfile :end2 endofname :from-end t)))
(setf startofbody (+ (length endchars) endofname 1))
(setf endofbody (+ 1 (search (concatenate 'string (string
#\Newline) endchunkchars) pamphletfile :start2 endofname)))
(if (and startofname endofname startofbody endofbody)
(list startofname endofname startofbody endofbody)))))))
(defun file-to-string (filename)
(let ((openfile (open filename :if-does-not-exist nil)))
(let ((fileasstring (make-array (file-length openfile) :element-type
'character :fill-pointer t)))
(setf (fill-pointer fileasstring) (read-sequence fileasstring
openfile))
(close openfile)
fileasstring)))
(defun load-pamphlet-file (filename)
(let ((pamphletfile (file-to-string filename)))
(let ((checkedlength 0)
(totallength (length pamphletfile))
(chunkpositions (find-next-chunk 0 pamphletfile)))
(if chunkpositions
(progn
(do ()
((> checkedlength totallength))
(progn
(make-new-chunk (subseq pamphletfile (first chunkpositions)
(second chunkpositions))
(subseq pamphletfile (third chunkpositions) (fourth
chunkpositions)))
(setf pamphletfile (subseq pamphletfile (fourth
chunkpositions)))
(setf chunkpositions (find-next-chunk 0 pamphletfile))
(if (not chunkpositions) (setf checkedlength (+ 1
totallength)))))
)
(error "No code chunks found. Perhaps delimiters are
incorrect?")))))
(defun write-output-file (filename chunkname)
(let ((outputstream (open filename :direction :output :if-exists
:supersede)))
(write-string (check-for-referenced-chunk
(get-chunk-contents chunkname) 0) outputstream)
(close outputstream)))
(defun notangle (fileinname fileoutname &optional (chunkname "*"))
(clrhash *chunk-hash-table*)
(load-pamphlet-file fileinname)
(write-output-file fileoutname chunkname)
(clrhash *chunk-hash-table*))
\start
Date: Sat, 17 Feb 2007 16:22:31 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Minor cleanup on working version
Forgot to add Waldek's name to the lisp level copyright notice. Also
changed the exception for the end-of-chunk-body character to look for
it not in the first column, rather than for a double quite before it
(like the perl version.)
v0.3 attached.
--0-2090592225-1171758151=:52761
XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0gClx1c2VwYWNrYWdle2F4aW9tfQpc
YmVnaW57ZG9jdW1lbnR9Clx0aXRsZXtjbC1ub3RhbmdsZSB2MC4zIC0gYSBM
aXRlcmF0ZSBQcm9ncmFtIENvZGUgRXh0cmFjdG9yIGZvciBBTlNJIENvbW1v
biBMaXNwfSAKXGF1dGhvcntDbGlmZm9yZCBZYXBwLCBXYWxkZWsgSGViaXNj
aH0KXG1ha2V0aXRsZQpcYmVnaW57YWJzdHJhY3R9CiAgTk9XRUIgaXMgdGhl
IGNsYXNzaWMgbGFuZ3VhZ2UgYWdub3N0aWMgdG9vbCB1c2VkIGZvciBsaXRl
cmF0ZSBwcm9ncmFtbWluZwogIGluIHRoZSBzdHlsZSBvZiBLbnV0aCdzIG9y
aWdpbmFsIFdFQi4gIFRoaXMgdG9vbCBpbXBsZW1lbnRzIGEgbWV0aG9kIGlu
CiAgbGlzcCBmb3IgZXh0cmFjdGluZyB0aGUgc291cmNlIGNvZGUgZnJvbSBs
aXRlcmF0ZSBkb2N1bWVudHMuClxlbmR7YWJzdHJhY3R9ClxlamVjdApcdGFi
bGVvZmNvbnRlbnRzClxlamVjdAoKXHNlY3Rpb257VXBkYXRlc30KClxub2lu
ZGVudCBcdmVyYkAoMi8xNS8wNylAIC0gSW5pdGlhbCB2MC4xIHJlbGVhc2Vk
Clxub2luZGVudCBcdmVyYkAoMi8xNi8wNylAIC0gV2FsdGVyIEhlYmlzY2gg
cHJvdmlkZXMgbGluZWFyIHRpbWUgcmVhZC1pbi1jaHVuawpcbm9pbmRlbnQg
XHZlcmJAKDIvMTcvMDcpQCAtIE1pbm9yIGNoYW5nZSB0byBjaGVjayBmb3Ig
QCBjaGFyYWN0ZXIsIGNvcHlyaWdodCBmaXgKClxzZWN0aW9ue0NvcHlyaWdo
dCBhbmQgTGljZW5zZX0KCiBUaGlzIHByb2dyYW0gaXMgYXZhaWxhYmxlIHVu
ZGVyIHRoZSBNb2RpZmllZCBCU0QgbGljZW5zZS4gIFRoZSB3b3JkaW5nCiBv
ZiB0aGUgZmlsZSB3YXMgY2hhbmdlZCBzbGlnaHRseSwgYXMgdGhlcmUgaXMg
bm8gb3JnYW5pemF0aW9uIGFzc29jaWF0ZWQKIHdpdGggdGhlIGNyZWF0aW9u
IG9mIHRoaXMgZmlsZSwgYnV0IGlmIHRoZXJlIGlzIGFueSBxdWVzdGlvbiB0
aGUgbGljZW5zZQogaXMgaW50ZW5kZWQgdG8gYmUgTW9kaWZpZWQgQlNELgoK
PDxjb3B5cmlnaHQ+Pj0KOzsgQ29weXJpZ2h0IChjKSAyMDA3LCBDbGlmZm9y
ZCBZYXBwLCBXYWxkZWsgSGViaXNjaAo7OyBBbGwgcmlnaHRzIHJlc2VydmVk
LgoKQAoKPDxsaWNlbnNlPj49Cjs7IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2Ug
aW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAo7
OyBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0
aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlCjs7IG1ldDoKOzsKOzsgICAg
LSBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4g
dGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAgIG5vdGljZSwgdGhpcyBsaXN0
IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4K
OzsKOzsgICAgLSBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVz
dCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAgIG5vdGlj
ZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcg
ZGlzY2xhaW1lciBpbgo7OyAgICAgIHRoZSBkb2N1bWVudGF0aW9uIGFuZC9v
ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKOzsgICAgICBk
aXN0cmlidXRpb24uCjs7Cjs7ICAgIC0gVGhlIG5hbWVzIG9mIHRoZSBjb250
cmlidXRvcnMgbWF5IG5vdCBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90
ZQo7OyAgICAgIHByb2R1Y3RzIGRlcml2ZWQgZnJvbSB0aGlzIHNvZnR3YXJl
IHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbgo7OyAgICAgIHBlcm1p
c3Npb24uCjs7Cjs7VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUg
Q09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUyAiQVMKOztJUyIg
QU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVE
SU5HLCBCVVQgTk9UIExJTUlURUQKOztUTywgVEhFIElNUExJRUQgV0FSUkFO
VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEKOztQ
QVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5U
IFNIQUxMIFRIRSBDT1BZUklHSFQgT1dORVIKOztPUiBDT05UUklCVVRPUlMg
QkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRB
TCwgU1BFQ0lBTCwKOztFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFN
QUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sCjs7UFJPQ1VS
RU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBP
RiBVU0UsIERBVEEsIE9SCjs7UFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJS
VVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRgo7
O0xJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJ
TElUWSwgT1IgVE9SVCAoSU5DTFVESU5HCjs7TkVHTElHRU5DRSBPUiBPVEhF
UldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBPRiBU
SElTCjs7U09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lC
SUxJVFkgT0YgU1VDSCBEQU1BR0UuCgpAIAoKXGVqZWN0ClxzZWN0aW9ue0lu
dHJvZHVjdGlvbiAtIE5PV0VCIGFuZCBMaXRlcmF0ZSBQcm9ncmFtbWluZ30K
ClRoZSBjb25jZXB0IG9mIExpdGVyYXRlIFByb2dyYW1taW5nIHRyYWNlcyBi
YWNrIHRvIERvbmFsZCBLbnV0aCwgdGhlIGF1dGhvcgpvZiB0aGUgVGVYIHR5
cGVzZXR0aW5nIHN5c3RlbSBhbmQgQ1dFQi4gIFRoZSBmdW5kYW1lbnRhbCBp
ZGVhIG9mIGxpdGVyYXRlIApwcm9ncmFtbWluZyBpcyB0byBkZXZlbG9wIHRo
ZSBjb2RlIGFuZCBkb2N1bWVudGF0aW9uIGFzIG9uZSBpbnRlZ3JhdGVkIHdo
b2xlIAotIHJhdGhlciB0aGFuIGhhdmluZyBzb3VyY2UgY29kZSBpbiBvbmUg
ZmlsZSBhbmQgZG9jdW1lbnRhdGlvbiBpbiBhbm90aGVyIHRoZSAKdHdvIGFy
ZSB3b3ZlbiB0b2dldGhlci4gIFRoaXMgcGxhY2VzIHRoZSBlbXBoYXNpcyBv
biBpZGVhcyBtb3JlIHRoYW4gY29kZSwgYW5kIAppcyBpbnRlbmRlZCB0byBl
bmNvdXJhZ2UgdGhlIGNyZWF0aW9uIG9mIHByb2dyYW1zIHRoYXQgd2lsbCBi
ZSB1bmRlcnN0YW5kYWJsZSAKYW5kIHVzYWJsZSBhcyBsb25nIGFzIHRoZSBp
ZGVhcyBiZWhpbmQgdGhlIGRlc2lnbiBpdHNlbGYgYXJlIHZhbGlkLgoKT25l
IG9mIHRoZSBwcmFjdGljYWwgY29uc2VxdWVuY2VzIG9mIHRoaXMgaWRlYSBp
cyB0aGF0IGluIG9yZGVyIGZvciB0aGUgY29kZSAKaW4gYSBsaXRlcmF0ZSBk
b2N1bWVudCB0byBiZSBsb2FkZWQgaW50byBhIG1hY2hpbmUsIGl0IG11c3Qg
YmUgZXh0cmFjdGVkIGZyb20gCnRoZSBkb2N1bWVudC4gVGhpcyBpcyBmdXJ0
aGVyIGNvbXBsaWNhdGVkIGJ5IHRoZSBlbXBoYXNpcyBvZiBsaXRlcmF0ZSAK
cHJvZ3JhbW1pbmcgb24gaWRlYXMgcmF0aGVyIHRoYW4gY29kZSBkaWN0YXRp
bmcgdGhlIG9yZGVyIG9mIGEgcHJvZ3JhbW1lcidzIAp3b3JrLiAgV0VCIGRv
Y3VtZW50cyB0aHVzIGFyZSBub3Qgb25seSBpbnRlcndvdmVuIHRleHQgYW5k
IHNvdXJjZSBjb2RlLCBidXQgCmhhdmUgY2h1bmtzIG9mIGNvZGUgZGVmaW5l
ZCBhdCBhcmJpdHJhcnkgcG9pbnRzIGluIHRoZSBkb2N1bWVudC4gIFRoZXJl
IGlzIAp1c3VhbGx5IGEgcm9vdCBjaHVuayB3aGljaCBwbGFjZXMgdGhlIGlu
ZGl2aWR1YWwgcGllY2VzIGluIHRoZSBjb3JyZWN0IG9yZGVyLCAKYnV0IGVh
Y2ggcGllY2UgbWF5IGluIHR1cm4gcmVmZXJlbmNlIG90aGVyIHBpZWNlcyBh
bmQgYWxsIG9mIHRoZW0gbXVzdCBiZSAKZXZlbnR1YWxseSBwdXQgaW4gdGhl
IGNvcnJlY3Qgc2VxdWVuY2UgdG8gYWxsb3cgdGhlIG1hY2hpbmUgdG8gcmVh
ZCB0aGVtLgoKSW4gTk9XRUIsIHRoZSBzcGVjaWZpYyBjb21tYW5kIHRoYXQg
ZG9lcyB0aGlzIGpvYiBpcyBjYWxsZWQgbm90YW5nbGUuICBUaGVyZSAKYXJl
IG90aGVyIGNvbW1hbmRzIHRoYXQgcHJvY2VzcyB0aGUgZG9jdW1lbnQgaW50
byB2YXJpb3VzIG91dHB1dCBmb3JtcywgYnV0IApmcm9tIHRoZSBzdGFuZHBv
aW50IG9mIHRoZSBtYWNoaW5lIHVuZGVyc3RhbmRpbmcgdGhlIGNvZGUgbm90
YW5nbGUgaXMgdGhlIAptb3N0IGNyaXRpY2FsLgoKSGVyZSwgd2Ugd2lsbCBp
bXBsZW1lbnQgYSB3YXkgaW4gbGlzcCB0byBsb2FkIGEgcGFtcGhsZXQgZmls
ZSwgQXhpb20ncyBmb3JtIApvZiBsaXRlcmF0ZSBwcm9ncmFtbWluZyBkb2N1
bWVudCwgYW5kIGV4dHJhY3QgdGhlIGNvZGUgZnJvbSBpdC4KCgpcc2VjdGlv
bntUaGUgVG9wIExldmVsIEZpbGUgU3RydWN0dXJlfQoKPDwqPj49Cjw8Y29w
eXJpZ2h0Pj4KPDxsaWNlbnNlPj4KPDxkZWxpbWl0ZXJzPj4KPDxoYXNodGFi
bGU+Pgo8PGNodW5rY2xhc3M+Pgo8PGJhc2ljLWNodW5rLW9wZXJhdGlvbnM+
Pgo8PHJlYWRpbi1jaHVuaz4+Cjw8dG9wbGV2ZWwtY2h1bmstc2Nhbm5pbmc+
Pgo8PHJlZmVyZW5jZS1jaHVuay1zY2FubmluZz4+Cjw8bG9hZC1maWxlPj4K
PDx3cml0ZS1maWxlPj4KPDxub3RhbmdsZT4+CkAgCgpcc2VjdGlvbntJbml0
aWFsIERlZmluaXRpb25zfQoKVGhlIG1vc3QgaW1wb3J0YW50IHBpZWNlcyBv
ZiBpbmZvcm1hdGlvbiBuZWVkZWQgd2hlbiB1bnRhbmdsaW5nIGEgZmlsZSBh
cmUgCnRoZSBkZWxpbWl0aW5nIHN0cmluZ3MgdXNlZCB0byBpZGVudGlmeSBw
YXJ0cyBvZiBhIGNodW5rLiAgQXMgYSBydWxlLCBjaHVua3MgCmNvbnNpc3Qg
b2YgYSBuYW1lLCBhIGJvZHksIGFuZCBhbiBlbmQgb2YgY2h1bmsgY2hhcmFj
dGVyIHdoaWNoIHNpZ25pZmllcyB0aGUgCmVuZCBvZiB0aGUgY29kZS4gIEhv
d2V2ZXIsIGJlY2F1c2UgY2h1bmtzIG1heSBhbHNvIHJlZmVyZW5jZSBvdGhl
ciBjaHVua3MsIAp0aGVyZSBhbHNvIG5lZWQgdG8gYmUgY2h1bmsgcmVmZXJl
bmNlIGZsYWdzIHRoYXQgY2FuIGJlIHNlZW4gaW5zaWRlIHRoZSBib2R5IApp
dHNlbGYuICBBeGlvbSBjb252ZW50aW9ucyBhcmUgdXNlZCBoZXJlIGZvciB0
aGUgZGVmYXVsdHMsIGJ1dCBvdGhlcnMgYXJlIApjZXJ0YWlubHkgcG9zc2li
bGUgYW5kIGNhbiBiZSBhY2hpZXZlZCBieSBzaW1wbHkgcmUtZGVmaW5pbmcg
dGhlc2UgdmFyaWFibGVzLiAgCk5vdGUsIGhvd2V2ZXIsIHRoYXQgY29sbGlz
aW9ucyBiZXR3ZWVuIGRlbGltaXRlcnMgYXQgdGhlIHNhbWUgbGV2ZWxzIChz
YXksIAp0aGUgZW5kaW5nIGNoYXJhY3RlcnMgZm9yIHRoZSBuYW1lIG9mIHRo
ZSBjaHVuayBhbmQgdGhlIGVuZCBvZiBjaHVuayBib2R5IApjaGFyYWN0ZXIs
IG9yIHRoZSB0d28gZGVsaW1pdGVycyB1c2VkIGluc2lkZSB0aGUgYm9keSBm
b3IgcmVmZXJlbmNlcykgd2lsbCAKYWxtb3N0IGNlcnRhaW5seSBwcmV2ZW50
IGNvcnJlY3QgcGFyc2luZyBvZiB0aGUgZmlsZS4KCjw8ZGVsaW1pdGVycz4+
PQooZGVmdmFyIHN0YXJ0Y2hhcnMgIjw8IikKKGRlZnZhciBlbmRjaGFycyAi
Pj49IikKKGRlZnZhciBlbmRjaHVua2NoYXJzICJAIikKKGRlZnZhciByZWZz
dGFydGNoYXJzICI8PCIpCihkZWZ2YXIgcmVmZW5kY2hhcnMgIj4+IikgCgpA
CgpXaGVuIHJlYWRpbmcgaW4gY2h1bmtzIGFuZCBzdG9yaW5nIHRoZW0sIGEg
aGFzaCB0YWJsZSBpcyB1c2VkLiAgV2UgaW5pdGlhbGl6ZSAKdGhhdCB0YWJs
ZSBhdCB0aGUgYmVnaW5uaW5nLCBzaW5jZSBpdCBpcyB1c2VkIHRocm91Z2hv
dXQgdGhlIHByb2dyYW0uICBBbiAKaW1wb3J0YW50IGZlYXR1cmUgdG8gbm90
ZSBoZXJlIGlzIHRoYXQgdGhpcyBoYXNoIHRhYmxlIHVzZXMgdGhlIGBgZXF1
YWwnJyAKZnVuY3Rpb24gZm9yIGVxdWFsaXR5IHRlc3RpbmcsIHdoaWNoIGlz
IG5lY2Vzc2FyeSBmb3IgdGhlIGhhc2ggdGFibGUgdG8gd29yayAKd2l0aCBz
dHJpbmcga2V5cy4gIENodW5rIG5hbWVzIGFyZSBzdHJpbmdzLCBhbmQgYSBk
ZWZhdWx0IGhhc2ggdGFibGUgCmNvbmZpZ3VyYXRpb24gaW4gTGlzcCB3aWxs
IG5vdCBhY2NlcHQgdGhlbS4KCjw8aGFzaHRhYmxlPj49CihkZWZwYXJhbWV0
ZXIgKmNodW5rLWhhc2gtdGFibGUqIChtYWtlLWhhc2gtdGFibGUgOnRlc3Qg
J2VxdWFsKSkKCkAKClxzZWN0aW9ue0NodW5rIHN0cnVjdHVyZSBpbiBDTE9T
fQoKQ0xPUyAodGhlIENvbW1vbiBMaXNwIE9iamVjdCBTeXN0ZW0pIHByb3Zp
ZGVzIGV4Y2VsbGVudCB0b29scyBmb3IgZGF0YSAKc3RydWN0dXJlIGNyZWF0
aW9uIGFuZCBtYW5pcHVsYXRpb24uICBXZSB3aWxsIG1ha2Ugb25seSBtaW5v
ciB1c2Ugb2YgaXQgaGVyZSwgCnRvIGRlZmluZSBhIGRhdGEgc3RydWN0dXJl
IHRoYXQgd2lsbCBob2xkIGNodW5rcyBhcyB0aGV5IGFyZSByZWFkIGluIGFu
ZCAKcGFyc2VkLiAgKEl0IGlzIHBlcmhhcHMgbm90IHN0cmljdGx5IG5lY2Vz
c2FyeSB0byBpbmNsdWRlIHRoZSBjaHVuayBuYW1lIGluIAp0aGUgZGF0YSBz
dHJ1Y3R1cmUsIHNpbmNlIHRoZSBoYXNoIGNvZGUgaXMgYWxzbyB0aGUgY2h1
bmsgbmFtZS4pIFRoaXMgCmRlZmluaXRpb24gd2lsbCBhbHNvIGF1dG9tYXRp
Y2FsbHkgcHJvZHVjZSBmdW5jdGlvbnMgdG8gbWFuaXB1bGF0ZSB0aGUgCnN0
cnVjdHVyZXMgd2l0aGluIHRoZSBjbGFzcywgYWx0aG91Z2ggd2Ugd2lsbCBk
ZWZpbmUgY29udmVuaWVuY2UgZnVuY3Rpb25zIApmb3IgdGhvc2Ugb3BlcmF0
aW9ucyBsYXRlci4gVGhlIGNvbnRlbnRzIG9mIHRoZSBjaHVuayBhcmUgaW5p
dGlhbGl6ZWQgdG8gdGhlIAplbXB0eSBzdHJpbmcuCgo8PGNodW5rY2xhc3M+
Pj0KKGRlZmNsYXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAgICA6aW5p
dGFyZyA6Y2h1bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAiTXVzdCBz
dXBwbHkgYSBjaHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5rLW5hbWUK
ICAgIDpkb2N1bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAgIChjaHVu
ay1jb250ZW50cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRzCiAgICA6
aW5pdGZvcm0gIiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50cwogICAg
OmRvY3VtZW50YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5jbHVkZSBy
ZWZlcmVuY2VzIHRvIG90aGVyIGNodW5rcyIpKSkKCkAKClxzZWN0aW9ue0Jh
c2ljIENodW5rIE9wZXJhdGlvbnN9CgpUaGVyZSBhcmUgdGhyZWUgdGhpbmdz
IHdlIHdpbGwgbm9ybWFsbHkgbmVlZCB0byBkbyB3aXRoIGNodW5rczogIG1h
a2UgbmV3IApvbmVzLCByZWFkIHRoZSBjb250ZW50IG9mIGFscmVhZHkgZXhp
c3RpbmcgY2h1bmtzLCBhbmQgYWRkIGRhdGEgdG8gYWxyZWFkeSAKZXhpc3Rp
bmcgY2h1bmtzLiAgQ2h1bmsgYnVpbGRpbmcgZG9lcyBub3Qgbm9ybWFsbHkg
bmVlZCB0byByZW1vdmUgY29udGVudCAtIAptb3JlIHN1YnRsZSBtYW5pcHVs
YXRpb24gb2YgY29udGVudCBpcyBuZWVkZWQgZm9yIGhhbmRsaW5nIHJlZmVy
ZW5jZXMsIGJ1dCAKdGhhdCBpcyBkZWFsdCB3aXRoIGVsc2V3aGVyZS4KClxz
dWJzZWN0aW9ue05ldyBDaHVua3N9CgpBIG5ldyBjaHVuayBpcyBhbHdheXMg
YXNzdW1lZCB0byBiZSBlbXB0eSwgc28gd2Ugc2ltcGx5IHRha2UgYSBuYW1l
IGFyZ3VtZW50IAphbmQgaW5pdGlhbGl6ZSB0aGUgY2h1bmssIG1lcmdpbmcg
aXQgaW50byB0aGUgY2VudHJhbCBoYXNoIHRhYmxlIGFzIHdlIApjcmVhdGUg
aXQuICBUaGlzIG1lYW5zIHRoZSBjaHVuayBgYGxpdmVzJycgaW4gdGhlIGhh
c2ggdGFibGUgYW5kIGRvZXMgbm90IApleGlzdCBhcyBhIHZhcmlhYmxlIGlu
IHRoZSBMaXNwIGVudmlyb25tZW50LCBzbyB5b3Ugd2lsbCBuZXZlciB0eXBl
IApgYGNodW5rMScnIGFuZCBzZWUgdGhlIGNvbnRlbnRzIG9mIHRoZSBjaHVu
ay4KCjw8bmV3LWNodW5rPj49CihkZWZ1biBtYWtlLW5ldy1jaHVuayAoY3Vy
ci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1bmstbmFt
ZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2UgJ2NodW5r
IDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKQAoKXHN1YnNlY3Rp
b257UmVhZGluZyBDaHVuayBDb250ZW50c30KCkJlY2F1c2UgdGhlIGNodW5r
cyBhcmUgY29udGFpbmVkIGluIHRoZSBoYXNoIHRhYmxlLCB3ZSBuZWVkIGEg
d2F5IHRvIHN1cHBseSAKdGhlIG5hbWUgb2YgYSBjaHVuayBhbmQgcmV0cmll
dmUgdGhlIGNvbnRlbnRzLiAgTm90ZSB0aGF0IHRoaXMgcmV0dXJucyAKdGhl
IGxpdGVyYWwgc3RyaW5nIG9mIHRoZSBjaHVuayBhbmQgZG9lcyBub3Qgc3dh
cCBpbiBkZWZpbml0aW9ucyBmb3IgCnJlZmVyZW5jZXMuCgo8PGdldC1jaHVu
ay1jb250ZW50cz4+PQooZGVmdW4gZ2V0LWNodW5rLWNvbnRlbnRzIChjdXJy
LWNodW5rLW5hbWUpCiAgKGNodW5rLWNvbnRlbnRzIChnZXRoYXNoIGN1cnIt
Y2h1bmstbmFtZSAqY2h1bmstaGFzaC10YWJsZSopKSkKCkAKClxzdWJzZWN0
aW9ue0FkZGluZyBOZXcgQ29udGVudCB0byBDaHVua3N9CgpBcyB0aGUgZmls
ZSBpcyByZWFkIGluIGxpbmUgYnkgbGluZSwgd2UgZG9uJ3QgZGVmaW5lIGNo
dW5rIGNvbnRlbnRzIGluIGEgCnNpbmdsZSBgYGd1bHAnJyBidXQgb25lIGxp
bmUgYXQgYSB0aW1lLiAgU28gd2UgbmVlZCBhIGNvbnZlbmllbnQgd2F5IHRv
IGFkZCAKbmV3IGxpbmVzIHRvIHRoZSBjb250ZW50cyBvZiBhIGNodW5rIGtu
b3dpbmcgb25seSB0aGUgbmFtZSBvZiB0aGUgY2h1bmsgYW5kIAp0aGUgY29u
dGVudHMgdG8gYWRkLiAgVGhlIG9ubHkgbWlub3IgZGlmZmljdWx0eSBoZXJl
IGlzIHRoYXQgcmVhZC1saW5lIGluIApMaXNwIGRvZXNuJ3QgcHJlc2VydmUg
bmV3bGluZXMgYXMgcGFydCBvZiB0aGUgc3RyaW5nLCB3aGljaCBpcyBub3Jt
YWxseSB0aGUgCmRlc2lyZWQgYmVoYXZpb3IgYnV0IG5vdCB3aGF0IGlzIG5l
ZWRlZCBoZXJlLiAgU28gdGhlcmUgYXJlIHR3byBjYXNlcyAtIGluIAp0aGUg
aW5pdGlhbCBjYXNlIHdoZW4gdGhlIGNvbnRlbnRzIGFyZSBlbXB0eSB3ZSBz
aW1wbHkgYXNzaWduIHRoZSBzdHJpbmcgYXMKdGhlIG5ldyBjb250ZW50cy4g
IElmIHRoZSBjb250ZW50cyBhcmUgbm90IGVtcHR5IHdlIG5lZWQgdG8gY3Jl
YXRlIGEgbmV3IApzdHJpbmcgY29udGFpbmluZyB0aGUgb3JpZ2luYWwgY29u
dGVudHMsIGEgbmV3bGluZSBjaGFyYWN0ZXIsIGFuZCB0aGUgbmV3IApsaW5l
LgoKPDxhZGQtY2h1bmstY29udGVudHM+Pj0KKGRlZnVuIGFkZC10by1jaHVu
ay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lIG5ldy1jb250ZW50cykKICAo
bGV0ICgoc3RhcnRpbmctY2h1bmstY29udGVudHMgKGdldC1jaHVuay1jb250
ZW50cyBjdXJyLWNodW5rLW5hbWUpKSkKICAgIChpZiAoc3RyaW5nLWVxdWFs
IHN0YXJ0aW5nLWNodW5rLWNvbnRlbnRzICIiKQoJKHNldGYgKGNodW5rLWNv
bnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmstaGFzaC10
YWJsZSopKQoJICAgICAgbmV3LWNvbnRlbnRzKQoJKHNldGYgKGNodW5rLWNv
bnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmstaGFzaC10
YWJsZSopKQoJICAgICAgKGNvbmNhdGVuYXRlICdzdHJpbmcgc3RhcnRpbmct
Y2h1bmstY29udGVudHMgKHN0cmluZyAjXE5ld2xpbmUpCgkJCSAgIG5ldy1j
b250ZW50cykpKSkpCgpACgpcc3Vic2VjdGlvbntBbGwgQmFzaWMgRnVuY3Rp
b25zfQoKVGhlc2UgdGhyZWUgb3BlcmF0aW9ucyBhcmUgdGhlIGNvcmUgb2Yg
d2hhdCBpcyBuZWVkZWQuICBXZSB3aWxsIGFkZCBvbmUgbW9yZSAKZnVuY3Rp
b24gZm9yIGNvbnZlbmllbmNlIGR1cmluZyBkZWJ1Z2dpbmcsIHdoaWNoIHBy
aW50cyBvdXQgYWxsIGNodW5rcyBpbiAKdGhlIGhhc2ggdGFibGUuCgo8PHZp
ZXctYWxsPj49CihkZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAobWFwaGFz
aCAjJyhsYW1iZGEgKGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4lIiBrIHYp
KSAqY2h1bmstaGFzaC10YWJsZSopKQoKQAoKPDxiYXNpYy1jaHVuay1vcGVy
YXRpb25zPj49Cjw8bmV3LWNodW5rPj4KPDxnZXQtY2h1bmstY29udGVudHM+
Pgo8PGFkZC1jaHVuay1jb250ZW50cz4+Cjw8dmlldy1hbGw+PgpACgpcc2Vj
dGlvbntMb2NhdGluZyBDaHVua3MgYW5kIENodW5rIFJlZmVyZW5jZXN9CgpU
aGUgbW9zdCBkaWZmaWN1bHQgcGFydCBvZiBkZWFsaW5nIHdpdGggbGl0ZXJh
dGUgcHJvZ3JhbW1pbmcgZmlsZXMgaXMgdGhlIAppbnRlcndvdmVuIHN0cnVj
dHVyZSB0aGF0IGNvZGUgY2h1bmsgcmVmZXJlbmNlcyBjYW4gcHJvZHVjZS4g
IFR3byBsZXZlbHMgYXJlIApuZWVkZWQgLSBpZGVudGlmeSBhbmQgc3RvcmUg
ZGVmaW5lZCBjaHVua3MsIGFuZCBzcG90IHJlZmVyZW5jZXMgdG8gY2h1bmtz
IAppbnNpZGUgb2YgY2h1bmsgYm9kaWVzLgoKXHN1YnNlY3Rpb257SWRlbnRp
ZnlpbmcgYW5kIFN0b3JpbmcgQ2h1bmtzIC0gVG9wIExldmVsfQoKQW4gYXNz
dW1wdGlvbiBtYWRlIGlzIHRoYXQgYWxsIGNodW5rIGRlZmluaXRpb25zIGFy
ZSBgYHRvcCBsZXZlbCcnIC0gdGhhdCBpcywgCm5vIGNodW5rIGlzIGRlZmlu
ZWQgaW4gdGhlIGJvZHkgb2YgYW5vdGhlciBjaHVuay4gIEdyYW50aW5nIHRo
YXQgYXNzdW1wdGlvbiwgCml0IGlzIHBvc3NpYmxlIHRvIGNoZWNrIGVhY2gg
c3RyaW5nIGFzIGl0IGlzIHJlYWQgdG8gc2VlIGlmIGl0IGlzIHRoZSBzdGFy
dCAKb2YgYSBuZXcgY2h1bmsuICBUaGlzIGlzIGRvbmUgdXNpbmcgTGlzcCBz
dHJpbmcgc2VhcmNoaW5nIGFuZCBzcGFjZSB0cmltbWluZy4KQW5vdGhlciBh
c3N1bXB0aW9uIGlzIHRoYXQgdGhlIGJlZ2lubmluZyBpZGVudGlmaWVyIGZv
ciBhIGNodW5rIGlzIG9uIGl0cyAKb3duIGxpbmUgLSB0aGlzIGlzIHByb2Jh
Ymx5IG5vdCBzdHJpY3RseSBuZWNlc3NhcnkgYnV0IHNob3VsZCBiZSBzdGFu
ZGFyZCAKY29udmVudGlvbi4KCjw8dG9wbGV2ZWwtY2h1bmstc2Nhbm5pbmc+
Pj0KKGRlZnVuIGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayAoaW5wdXRzdHJp
bmcgZmlsZW5hbWUpCiAgIChsZXQgKCh0ZXN0c3RyaW5nIChzdHJpbmctdHJp
bSAiICIgaW5wdXRzdHJpbmcpKSkKICAgICAoaWYgKD4gKGxlbmd0aCB0ZXN0
c3RyaW5nKSAzKQogICAgIChpZiAoYW5kIChzdHJpbmctZXF1YWwgc3RhcnRj
aGFycyB0ZXN0c3RyaW5nIDplbmQyIChsZW5ndGggc3RhcnRjaGFycykpCgkg
ICAgICAoc3RyaW5nLWVxdWFsIGVuZGNoYXJzIHRlc3RzdHJpbmcgCgkJCSAg
ICAgOnN0YXJ0MiAoLSAobGVuZ3RoIHRlc3RzdHJpbmcpIChsZW5ndGggZW5k
Y2hhcnMpKQoJCQkgICAgIDplbmQyIChsZW5ndGggdGVzdHN0cmluZykpKQog
ICAgICAgICAobGV0ICgobmV3LWNodW5rLW5hbWUgKHN1YnNlcSB0ZXN0c3Ry
aW5nIChsZW5ndGggc3RhcnRjaGFycykKCQkJCSAgICgtIChsZW5ndGggdGVz
dHN0cmluZykgKGxlbmd0aCBlbmRjaGFycykpKSkpCgkgICAobWFrZS1uZXct
Y2h1bmsgbmV3LWNodW5rLW5hbWUpCgkgICAocmVhZC1pbi1jaHVuayBuZXct
Y2h1bmstbmFtZSBmaWxlbmFtZSkKCSAgIHQpCgkgKSkpKQoKQAoKXHN1YnNl
Y3Rpb257SWRlbnRpZnlpbmcgYW5kIEV4cGFuZGluZyBDaHVuayBSZWZlcmVu
Y2VzfQoKVGhlIGFib3ZlIHdpbGwgc2VydmUgZm9yIHRvcGxldmVsIGNodW5r
IGlkZW50aWZpY2F0aW9uLCBidXQgdGhlIHRhc2sgb2YgCmlkZW50aWZ5aW5n
IHJlZmVyZW5jZXMgdG8gY2h1bmtzIGluIHRoZSBib2R5IG9mIGEgY2h1bmsg
aXMgYSBzbGlnaHRseSAKZGlmZmVyZW50IHRhc2suICBBIGxpbmUgd2lsbCBj
b250YWluIG9ubHkgb25lIGNodW5rIGRlZmluaXRpb24sIGJ1dCB0aGUgCmNv
bnRlbnRzIG9mIGEgY2h1bmsgYm9keSBtYXkgY29udGFpbiBtYW55IGNodW5r
IHJlZmVyZW5jZXMuICBBIGZ1cnRoZXIgCmNvbXBsaWNhdGlvbiBpcyB0aGF0
IGV2ZW4gd2hlbiB0aG9zZSByZWZlcmVuY2VzIGFyZSBleHBhbmRlZCwgdGhl
eSBtYXkgCmluIHR1cm4gY29udGFpbiBvdGhlciByZWZlcmVuY2VzLiAgVG8g
aGFuZGxlIHRoaXMgYSByZWN1cnNpdmUgZnVuY3Rpb24KaWRlbnRpZmllcyAg
dGhlIGZpcnN0IGNodW5rLCBleHBhbmRzIGl0LCBidWlsZHMgYSBuZXcgc3Ry
aW5nIGJhc2VkIG9uIAp0aGUgY29tYmluYXRpb24gIG9mIG9sZCBhbmQgbmV3
LCBpbnNlcnRzIGluIHBsYWNlIG9mIHRoZSByZWZlcmVuY2UsIAphbmQgY2Fs
bHMgaXRzZWxmIG9uIHRoZSBuZXcgcmVzdWx0LiBJbiB0aGUgZW5kLCB0aGUg
cmV0dXJuZWQgCnN0cmluZyB3aWxsIGhhdmUgYWxsIHJlZmVyZW5jZXMgZXhw
YW5kZWQgYW5kIGNvbnN0aXR1dGUgdGhlIGZpbmFsIGZvcm0gb2YgCnRoZSBj
aHVuayBhcyBpdCBpcyB0byBiZSBzZW50IHRvIHRoZSBvdXRwdXQgZmlsZS4K
Ckhvd2V2ZXIsIHRoZXJlIGFyZSBzZXZlcmFsIHRoaW5ncyB0byBiZSB3YXJ5
IG9mIHdoZW4gZG9pbmcgdGhpcyBzY2FuLiAgVGhlCmZpcnN0IGlzIGEgYmFk
IGNodW5rLCBvciBhIHJlZmVyZW5jZSBjaHVuayB3aGljaCBoYXMgbm8gZGVm
aW5pdGlvbi4gIFRoaXMKaXMgaGFuZGxlZCBieSB0aHJvd2luZyBhbiBlcnJv
ciBpZiBzdWNoIGEgY2h1bmsgaXMgZW5jb3VudGVyZWQuICBXZSB3aWxsCmFs
c28gZGVmaW5lIGhlcmUgdGhlIGNvcmUgcm91dGluZSBmb3IgbWVyZ2luZyB0
aGUgc3RyaW5nczoKCjw8Y29yZS1yZWY+Pj0KKHByb2duCiAgKGxldCAoKG1p
ZGRsZXN0cmluZyAoc3Vic2VxIGlucHV0c3RyaW5nIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoKyBwb3MxIChsZW5ndGggcmVmc3RhcnRjaGFy
cykpIAoJCQkgICAgICBwb3MyKSkpCiAgICAoaWYgKGdldGhhc2ggbWlkZGxl
c3RyaW5nICpjaHVuay1oYXNoLXRhYmxlKikKCShwcm9nbgoJICAoc2V0ZiBp
bnB1dHN0cmluZyAKCQkoY29uY2F0ZW5hdGUgJ3N0cmluZwoJCQkgICAgIChz
dWJzZXEgaW5wdXRzdHJpbmcgMCBwb3MxKQoJCQkgICAgIChnZXQtY2h1bmst
Y29udGVudHMgbWlkZGxlc3RyaW5nKQoJCQkgICAgIChzdWJzZXEgaW5wdXRz
dHJpbmcgCgkJCSAgICAgICAgICAgICAoKyBwb3MyIChsZW5ndGggcmVmZW5k
Y2hhcnMpKSkpKQoJICAoY2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgaW5w
dXRzdHJpbmcgcG9zMSkpCgkoZXJyb3IgICJ+UyB3YXMgbm90IGZvdW5kIGlu
IGhhc2ggdGFibGUuIiBtaWRkbGVzdHJpbmcpKSkpKSkKQAoKVGhlIG5leHQg
Y2hlY2sgaXMgZm9yIGEgY2FzZSB3aGVyZSB0aGUgZGVsaW1pdGluZyBjaGFy
YWN0ZXJzIGFyZSBicm9rZW4KdXAgb3ZlciB0d28gbGluZXMuICBXZSB3aWxs
IG5vdCByZWdhcmQgdGhpcyBhcyBhIGxlZ2FsIGNodW5rIG5hbWUsIGFzCml0
IGlzIGEgcmF0aGVyIHVubGlrZWx5IGNoYXJhY3RlciBjb21iaW5hdGlvbiBm
b3IgYSBsYWJlbCwgYW5kIGl0IGFsc28KYWxsb3dzIHRoZSBhdm9pZGFuY2Ug
b2YgYWNjaWRlbnRhbCBjaHVuayBuYW1lIG1hdGNoaW5nIHdoZW4gaXQgaXMg
bm90CmludGVuZGVkIChvbmUgb2YgdGhlIGNodW5rcyBpbiB0aGlzIHBhbXBo
bGV0LCBmb3IgZXhhbXBsZSwgd291bGQgdHJpZ2dlcgpzdWNoIGFuIGVycm9y
LikgIElmIHN1Y2ggYSBjb25kaXRpb24gaXMgZm91bmQsIHRoZSBzY2FuIHNo
b3VsZCBiZSByZXN1bWVkCmJleW9uZCB0aGUgbmV3bGluZSBjaGFyYWN0ZXIu
Cgo8PGNoZWNrLWZvci1uZXdsaW5lPj49CihpZiAoc2VhcmNoIChzdHJpbmcg
I1xOZXdsaW5lKSBpbnB1dHN0cmluZyA6c3RhcnQyIHBvczEgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6ZW5kMiBwb3My
KQogIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayBpbnB1dHN0cmluZyAK
ICAJKCsoc2VhcmNoIChzdHJpbmcgI1xOZXdsaW5lKSBpbnB1dHN0cmluZyA6
c3RhcnQyIHBvczEKCQkJCQkJIDplbmQyIHBvczIpIDEpICkKICA8PGNvcmUt
cmVmPj4KQAoKV2l0aCB0aG9zZSB0d28gY2hlY2tzIGluIHBsYWNlLCB3ZSBu
b3cgZGVmaW5lIHRoZSB0b3AgbGV2ZWwgY29udHJvbApmb3IgcG9zaXRpb25p
bmcgdGhlIHNlYXJjaCBjb21tYW5kLiAgVG8gYXZvaWQgY29uZnVzaW9uIGFu
ZCB1bm5lZWRlZApzY2FubmluZywgdGhlIGNvbW1hbmQgdGFrZXMgYSBzdGFy
dGluZyBwb3NpdGlvbiBhcyBhbiBhcmd1bWVudC4gIFRoaXMKYWxsb3dzIHN1
YnNlcXVlbnQgcmVjdXJzaXZlIGNhbGxzIHRvIGRpY3RhdGUgdGhlaXIgc3Rh
cnRpbmcgcG9zaXRpb24sCmFuZCB0aGUgaW5pdGlhbCBjYWxsIHNpbXBseSBz
cGVjaWZpZXMgemVybyBhcyB0aGUgYmVnaW5uaW5nLiAgQXQgdGhpcyBsZXZl
bAp3ZSBhbHNvIGhhdmUgdGhlIGV4aXQgY29uZGl0aW9uIC0gaWYgb25lIG9y
IG1vcmUgb2YgcG9zMSBhbmQgcG9zMiBhcmUKbmlsLCB0aGF0IG1lYW5zIHRo
aXMgcGFydGljdWxhciBzdHJpbmcgaXMgY29tcGxldGUgYW5kIGNhbiBiZSBy
ZXR1cm5lZC4KCjw8cmVmZXJlbmNlLWNodW5rLXNjYW5uaW5nPj49CihkZWZ1
biBjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAoaW5wdXRzdHJpbmcgc3Rh
cnRwb3MpCiAgIChsZXQgKChwb3MxIChzZWFyY2ggcmVmc3RhcnRjaGFycyBp
bnB1dHN0cmluZyA6c3RhcnQyIHN0YXJ0cG9zKSkpCiAgICAgKGxldCAoKHBv
czIgKGlmIHBvczEgKHNlYXJjaCByZWZlbmRjaGFycyBpbnB1dHN0cmluZyA6
c3RhcnQyIHBvczEpKSkpCiAgICAgICAoaWYgKGFuZCBwb3MxIHBvczIpCgkg
ICAocHJvZ24KCSAgIDw8Y2hlY2stZm9yLW5ld2xpbmU+PgoJICAgaW5wdXRz
dHJpbmcpKSkpCgpACgpcc2VjdGlvbntSZWFkaW5nIGluIENodW5rc30KCk9u
Y2Ugd2UgaGF2ZSBpZGVudGlmaWVkIGEgY2h1bmsgYXQgdGhlIHRvcCBsZXZl
bCwgd2UgbXVzdCByZWFkIGl0IGluLiBJbiB0aGUgCnRvcGxldmVsIGZ1bmN0
aW9uIHRoYXQgam9iIGlzIHBhc3NlZCBvZmYgdGhhdCBqb2IgdG8gYSBmdW5j
dGlvbiBjYWxsZWQgCnJlYWQtaW4tY2h1bmsuICByZWFkLWluLWNodW5rIGlz
IHRoZSBmdW5jdGlvbiB0aGF0IHB1dHMgYWRkaXRpb25hbCBsaW5lcyBpbnRv
IAp0aGUgY2h1bmsgY29udGVudHMgc2xvdCB1bnRpbCB0aGUgZW5kLW9mLWNo
dW5rLWJvZHkgY2hhcmFjdGVyIGlzIHNwb3R0ZWQuICAKSXQgYWxzbyB1c2Vz
IHJlY3Vyc2lvbiAtIGlmIHRoZSBsaW5lIGl0IHJlYWRzIGlzbid0IHRoZSBl
bmQtb2YtYm9keSBtYXJrZXIsIAppdCBhcHBlbmRzIHRoYXQgbGluZSB0byB0
aGUgY29udGVudHMgYW5kIGNhbGxzIGl0c2VsZiB0byBjaGVjayB0aGUgbmV4
dCAKbGluZS4gIEl0IGFsc28gd2lsbCBhdm9pZCBhbiBlbmQtb2YtYm9keSBt
YXJrZXIgbm90IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlCnN0cmluZywgdG8g
YXZvaWQgZW5kLW9mLWNodW5rLWJvZHkgY2hhcmFjdGVycyBpbiB0aGUgYm9k
eSBvZiBjb2RlIGFjY2lkZW50bHkKdHJpZ2dlcmluZyBhbiBlbmQgb2YgcmVh
ZC4KCjw8cmVhZGluLWNodW5rPj49CihkZWZ1biByZWFkLWluLWNodW5rIChj
dXJyLWNodW5rLW5hbWUgZmlsZW5hbWUpCiAgKGxldCAoKGxpbmVzIG5pbCkp
CiAgICAgKGxvb3AgZm9yIG5leHRsaW5lID0gKHJlYWQtbGluZSBmaWxlbmFt
ZSBuaWwpCiAgICAgICAgICAgIHdoaWxlIChvciAobm90IChzZWFyY2ggZW5k
Y2h1bmtjaGFycyBuZXh0bGluZSkpCiAgICAgICAgICAgICAgICAgICAgICAg
KHNlYXJjaCBlbmRjaHVua2NoYXJzIG5leHRsaW5lIDpzdGFydDIgMSkpCiAg
ICAgICAgICAgIGRvCiAgICAgICAgICAgICAgICAgIChwcm9nbgogICAgICAg
ICAgICAgICAgICAgICAocHVzaCBuZXh0bGluZSBsaW5lcykKICAgICAgICAg
ICAgICAgICAgICAgKHB1c2ggKHN0cmluZyAjXE5ld2xpbmUpIGxpbmVzKSkp
CiAgICAgIChpZiBsaW5lcwogICAgICAgICAocHJvZ24KICAgICAgICAgICAg
KHBvcCBsaW5lcykKICAgICAgICAgICAgKGFkZC10by1jaHVuay1jb250ZW50
cyBjdXJyLWNodW5rLW5hbWUKICAgICAgICAgICAgICAgICAgICAgICAgICAg
IChhcHBseSAjJ2NvbmNhdGVuYXRlICdzdHJpbmcgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChyZXZlcnNlIGxpbmVzKSkpKSkpKQoKQAoK
XHNlY3Rpb257RmlsZSBPcGVyYXRpb25zfQoKTm93IHRoYXQgd2Uga25vdyBo
b3cgdG8gaGFuZGxlIGNodW5rcywgd2Ugb25seSBuZWVkIHRvIGFwcGx5IHRo
YXQga25vd2xlZGdlIAp0byBzb21lIHBhcnRpY3VsYXIgZmlsZS4gIEZvciB0
aGlzLCB3ZSB1c2UgYSBsb29wIG1hY3JvIHJhdGhlciB0aGFuIHJlY3Vyc2lv
bi4KCjw8bG9hZC1maWxlPj49CihkZWZ1biBsb2FkLXBhbXBobGV0LWZpbGUg
KGZpbGVuYW1lKQogIChsZXQgKChpbiAob3BlbiBmaWxlbmFtZSA6aWYtZG9l
cy1ub3QtZXhpc3QgbmlsKSkpCiAgICAod2hlbiBpbgogICAgICAobG9vcCBm
b3IgbGluZSA9IChyZWFkLWxpbmUgaW4gbmlsKQoJICAgIHdoaWxlIGxpbmUg
ZG8gKGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayBsaW5lIGluKSkKICAgICAg
KGNsb3NlIGluKSkpKQoKQAoKV2UgYWxzbyBuZWVkIHRvIGJlIGFib3V0IHRv
IG91dHB1dCB0byBhIGZpbGUuIFRoZSB6ZXJvIGluIHRoZSB3cml0ZS1zdHJp
bmcgCmNvbW1hbmQgc2ltcGx5IHRlbGxzIHRoZSBzY2FubmVyIHRvIHN0YXJ0
IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGZpbGUuICBBcwppdCBpcyBjdXJy
ZW50bHkgY29uZmlndXJlZCwgdGhlIG91dHB1dCBmaWxlIGlzIGFsd2F5cyBv
dmVyd3JpdHRlbi4KCjw8d3JpdGUtZmlsZT4+PQooZGVmdW4gd3JpdGUtb3V0
cHV0LWZpbGUgKGZpbGVuYW1lIGNodW5rbmFtZSkKICAobGV0ICgob3V0cHV0
c3RyZWFtIChvcGVuIGZpbGVuYW1lIDpkaXJlY3Rpb24gOm91dHB1dCA6aWYt
ZXhpc3RzIDpzdXBlcnNlZGUpKSkKICAgICh3cml0ZS1zdHJpbmcgKGNoZWNr
LWZvci1yZWZlcmVuY2VkLWNodW5rIAoJCSAgIChnZXQtY2h1bmstY29udGVu
dHMgY2h1bmtuYW1lKSAwKSBvdXRwdXRzdHJlYW0pCiAgICAoY2xvc2Ugb3V0
cHV0c3RyZWFtKSkpCgpACgpcc2VjdGlvbntQdWxsaW5nIEl0IFRvZ2V0aGVy
IC0gVGhlIG5vdGFuZ2xlIENvbW1hbmR9CgpUaGUgZmluYWwsIHRvcCBsZXZl
bCBjb250cm9sIGNvbW1hbmQgaXMgbmFtZWQgbm90YW5nbGUgdG8gY29uZm9y
bSB0byB0aGUgCk5PV0VCIGNvbnZlbnRpb24uICBUaGlzIGNvbW1hbmQgYWNj
ZXB0cyBhbiBpbnB1dCBmaWxlLCBvdXRwdXQgZmlsZSwgYW5kIApvcHRpb25h
bGx5IHRoZSBuYW1lIG9mIHRoZSBjaHVuayBhdCB3aGljaCB0byBzdGFydCBl
eHRyYWN0aW5nIGNvbnRlbnRzLiAgClRoZSBkZWZhdWx0IGNvbnZlbnRpb24g
b2YgQXhpb20gaXMgdG8gdXNlIGFuIGFzdGVyaXNrIGFzIHRoZSByb290IG5v
ZGUsIGJ1dCAKdGhpcyBpcyBub3QgdW5pdmVyc2FsbHkgdHJ1ZSBhbmQgaXQg
aXMgc29tZXRpbWVzIGRlc2lyYWJsZSB0byBvdXRwdXQgY29kZSAKZnJvbSBv
bmUgcGFtcGhsZXQgaW50byBtdWx0aXBsZSB0YXJnZXQgZmlsZXMsIHN0YXJ0
aW5nIGF0IG11bHRpcGxlIHJvb3RzLiAgCkluIHRoYXQgY2FzZSwgdGhlIGNo
dW5rIG5hbWUgaXMgcGFzc2VkIHRvIG5vdGFyZ2V0IGFzIHdlbGwuICBGb3Ig
ZXhhbXBsZToKClxiZWdpbntxdW90ZX0KKG5vdGFuZ2xlIGBgYm9vdC5wYW1w
aGxldCcnIGBgYm9vdC5saXNwJycgYGBSTGlzcCcnKQpcZW5ke3F1b3RlfQoK
XG5vaW5kZW50IHdvdWxkIGV4dHJhY3QgYWxsIGNvZGUgcmVmZXJlbmNlZCBi
eSB0aGUgUkxpc3AgY2h1bmssIHdoZXJlYXMKClxiZWdpbntxdW90ZX0KKG5v
dGFuZ2xlIGBgYm9vdC5wYW1waGxldCcnIGBgYm9vdC5ib290JycpClxlbmR7
cXVvdGV9Cgpcbm9pbmRlbnQgd291bGQgZXh0cmFjdCBhbGwgY29kZSByZWZl
cmVuY2VkIGJ5IHRoZSBcdmVyYkAnJyonJ0Agbm9kZS4KClRoZSBub3Rhbmds
ZSBjb21tYW5kIHdpbGwgYWx3YXlzIGNsZWFyIHRoZSBoYXNoIHRhYmxlIGJl
Zm9yZSBhbmQgYWZ0ZXIKdXNlLCB0byBlbnN1cmUgbm8gYWNjaWRlbnRhbCBj
b2xsaXNpb25zIGFuZCBhdm9pZCB1bm5lY2Vzc2FyeSBtZW1vcnkKdXNhZ2Uu
Cgo8PG5vdGFuZ2xlPj49CihkZWZ1biBub3RhbmdsZSAoZmlsZWlubmFtZSBm
aWxlb3V0bmFtZSAmb3B0aW9uYWwgKGNodW5rbmFtZSAiKiIpKQogIChjbHJo
YXNoICpjaHVuay1oYXNoLXRhYmxlKikKICAobG9hZC1wYW1waGxldC1maWxl
IGZpbGVpbm5hbWUpCiAgKHdyaXRlLW91dHB1dC1maWxlIGZpbGVvdXRuYW1l
IGNodW5rbmFtZSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJsZSopKQpA
CgpcZW5ke2RvY3VtZW50fQo=
\start
Date: Sat, 17 Feb 2007 19:04:32 -0800
From: Arthur Ralfs
To: list
Subject: MathML package
I've posted my MathML package on SandBoxMathML.
I'm still working on both the code and the documentation but
it does work now. I've also included the diff files needed to
patch Axiom so it can be built with mathml as a new output
form. There are also a few files to help with viewing the
output in Firefox.
\start
Date: Sun, 18 Feb 2007 05:43:22 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: No progress on notangle
> I have tried to use read-sequence to load a file quickly, which works
> fine, but I'm afraid I haven't done too well with the problem of
> working with the resulting string. The code so far is actually slower
> than the earlier version, and from what I can tell the primary issue
> seems to be too many subseq operations on the big one-pamphlet string.
> I tried leaving the string intact and just identifying positions rather
> than chopping it off as I scanned, but the searches got progressively
> more expensive even though I was supplying new start positions.
> There's probably a better way to do it or an obvious mistake in the way
> I have done it, but I'm afraid I've been staring at it a bit too long.
Fast way to scan strings is to use finite automaton. The code below
shows how this can be done in Lisp.
Notes:
- This is a proof of concept (probably buggy) code, in particular I
only extract the main chunk (do not handle rescannig for other
chunks). Rescannig can be done by similar code, which simulatneously
could handle @-escapes ("@<<" etc). If escapes are not supported one
could do with a single scan, extending automaton to remember positions
of embedded tags. Alternative way to have single scan is to
copy content to new array during scan handling escapes during
copy.
- AFAICS this code is faster then Debian (pretty fast) notangle.
I belive that after adding needed features it can still be
fast.
- I use (unsigned-byte 8) as a type because Lisp implementation
may choose to have Unicode character and perfrom complicated
recoding during input and output. Also, Unicode characters
are likely to require more storage (so more time for memory
access and for garbage collection).
- The main function 'scan-for-chunks' is a rat nest of gotos.
But that is correct because finite automaton _is_ a rat nest
of transition and one of the simplest ways to implement
transitions is to use gotos. One can make it shorter by
using apropritate macros. Ideally the automaton code should
be mechanically generated -- writing in C I would use flex
(the task is trivial for flex, but no so trivial by hand).
- For ultimate speed pamplets should be read directly by Spad
scanner. This would avoid duplicate work. Namely, Spad have
to scan the file anyway. Recoginzing noweb markers adds
only little complexity to scanner and (if implemented via
finite automaton) almost no execution time. Spad performs
macro expansion and the same mechanizm can substitute chunks
if they respect pile rules. If one really wants unstructured
chunks one can handle them redirection parser input (like
include files).
- Re-doing Spad scanning/parsing is on my todo list. But ATM
parsing works no worse than the rest of compiler and while
quite slow it is still one of the fastest parts in the compiler.
So this task has very low priority.
Code follows:
;;; Usage:
;;; (untangle "input.file.name" "output.file.name")
;;;
(defconstant start-tag-code1 (char-code #\<))
(defconstant start-tag-code2 (char-code #\<))
(defconstant end-tag-code-1 (char-code #\>))
(defconstant end-tag-code-2 (char-code #\>))
(defconstant end-tag-code-3 (char-code #\=))
(defconstant chunk-end-code (char-code #\@))
(defconstant newline-code 10)
(defconstant space-code (char-code #\ ))
(defun read-file (f)
(let* ((b-len (file-length f))
(buff (make-array (list (+ b-len 1))
:element-type '(unsigned-byte 8))))
(read-sequence buff f)
(setf (aref buff b-len) newline-code)
buff))
(defun read-named-file (name)
(with-open-file (f name :element-type '(unsigned-byte 8))
(read-file f)))
(defclass chunk ()
((chunk-name
:initarg :chunk-name
:initform (error "Must supply a chunk name.")
:reader chunk-name
:documentation "Name of chunk.")
(chunk-contents
:initarg :chunk-contents
:initform '()
:accessor chunk-contents
:documentation "Text of chunk - may include references to other chunks")))
(defparameter *chunk-hash-table* (make-hash-table :test 'equalp))
(defun add-to-chunk-contents (name content)
(let ((chunk (gethash name *chunk-hash-table*)))
(if (not chunk)
(setf chunk (setf (gethash name *chunk-hash-table*)
(make-instance 'chunk :chunk-name name))))
(push (chunk-contents chunk) content)))
(defun view-all-chunks ()
(maphash #'(lambda (k v) (format t "~a => ~S~&" k v)) *chunk-hash-table*))
(defun print-chunk-name (name line-number)
(format t "Chunk start in line ~A: <<" line-number)
(dotimes (i (array-dimension name 0))
(format t "~A" (code-char (aref name i))))
(format t ">>~&"))
(defun scan-for-chunks (buff)
(prog ((pos -1)
(end-buff (- (array-dimension buff 0) 1))
(start-pos)
(code)
(chunk-name)
(line-number 0))
normal-start
(incf pos)
(incf line-number)
(if (>= pos end-buff)
(return-from scan-for-chunks))
(setf code (aref buff pos))
(if (equal code start-tag-code1)
(go chunk-start-tag-1))
(if (equal code newline-code)
(go normal-start))
(go normal)
normal
(incf pos)
(setf code (aref buff pos))
(if (equal code newline-code)
(go normal-start))
(go normal)
chunk-start-tag-1
(incf pos)
(setf code (aref buff pos))
(if (equal code start-tag-code2)
(progn
(setf start-pos (+ pos 1))
(format t "start-pos: ~A, char: ~A~&" start-pos
(aref buff start-pos))
(go in-chunk-start-tag)))
(if (equal code newline-code)
(go normal-start))
(go normal)
in-chunk-start-tag
(incf pos)
(setf code (aref buff pos))
(if (equal code end-tag-code-1)
(go in-chunk-start-tag-3))
(if (equal code newline-code)
(go normal-start))
(go in-chunk-start-tag)
in-chunk-start-tag-3
(incf pos)
(setf code (aref buff pos))
(if (equal code end-tag-code-2)
(go in-chunk-start-tag-4))
(if (equal code newline-code)
(go normal-start))
(go normal)
in-chunk-start-tag-4
(incf pos)
(setf code (aref buff pos))
(if (equal code end-tag-code-3)
(progn
(setf chunk-name (subseq buff start-pos (- pos 2)))
(go in-chunk-start-tag-trailing)))
(if (equal code newline-code)
(go normal-start))
(go normal)
in-chunk-start-tag-trailing
(incf pos)
(setf code (aref buff pos))
(if (equal code newline-code)
(progn
(print-chunk-name chunk-name line-number)
(setf chunk-start-pos (+ pos 1))
(go in-chunk)))
(if (equal code space-code)
(go in-chunk-start-tag-trailing))
(go normal)
chunk-start
(setf chunk-end-pos pos)
(incf pos)
(if (>= pos end-buff)
(break "unexpected end of file"))
(setf code (aref buff pos))
(incf line-number)
(if (equal code newline-code)
(go chunk-start))
(if (equal code chunk-end-code)
(progn
(add-to-chunk-contents
chunk-name
(list chunk-start-pos chunk-end-pos))
(go chunk-end-trailing)))
(go in-chunk)
chunk-end-trailing
(incf pos)
(setf code (aref buff pos))
(if (equal code newline-code)
(go normal-start))
(if (equal code space-code)
(go chunk-end-trailing))
(format t "pos: ~A, code: ~A~&" pos code)
(break "garbage after end of chunk marker")
in-chunk
(incf pos)
(setf code (aref buff pos))
(if (equal code newline-code)
(go chunk-start))
(go in-chunk)))
(defun untangle (in-file out-file)
(let ((buff (read-named-file in-file)) (chunk))
(scan-for-chunks buff)
(setf chunk (gethash (make-array (list 1)
:element-type '(unsigned-byte 8)
:initial-element (char-code #\*))
*chunk-hash-table*))
(if (not chunk)
(break "No main chunk"))
(with-open-file (of out-file :direction :output
:element-type '(unsigned-byte 8))
(dolist (seg (reverse (chunk-contents chunk)))
(write-sequence buff of :start (nth 0 seg)
:end (nth 1 seg))))))
\start
Date: Sat, 17 Feb 2007 21:50:03 -0800 (PST)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: No progress on notangle
> Fast way to scan strings is to use finite automaton. The code below
> shows how this can be done in Lisp.
Eeeep. I'm impressed!
> - The main function 'scan-for-chunks' is a rat nest of gotos.
> But that is correct because finite automaton _is_ a rat nest
> of transition and one of the simplest ways to implement
> transitions is to use gotos. One can make it shorter by
> using apropritate macros. Ideally the automaton code should
> be mechanically generated -- writing in C I would use flex
> (the task is trivial for flex, but no so trivial by hand).
Perhaps they could be prototyped in flex and then mapped to the Lisp
macro system?
This raises a question for me - I know Tim has need of a very fast
notangle for his work, but does Axiom actually need this kind of speed?
The complexity of this code makes me wonder of the extra 30 seconds in
Axiom build time are worth the added obfuscation. I suppose if we get
the macros written it won't be so formidible though...
I did a little bit of analysis, which Waldek's work makes more or less
moot but I'll add on anyway in case it winds up being of use to someone
else who is interested in basic profiling. One point - unless I'm
misunderstanding what the finite automaton solution is, this analysis
actually does point in the correct optimization direction - which is to
say, not read-line or reading speed but rather string manipulation
speed. Perhaps similar (but more advanced) study will wind up being
useful for other parts of Axiom.
Among the interesting features of sbcl, it turns out there is a neat
little utility called sb-profile that lets one watch how much time
functions take over time. I tried it using v0.3 of the cl-notangle,
and it is suggesting that it's not only (or even primarily) read-line
that is taking the time.
Here's what I did:
SETUP> (load "/home/cyapp/cl-notangle-v0.3.lisp")
T
SETUP> (sb-profile:profile MAKE-NEW-CHUNK GET-CHUNK-CONTENTS
ADD-TO-CHUNK-CONTENTS READ-IN-CHUNK CHECK-FOR-TOPLEVEL-CHUNK
CHECK-FOR-REFERENCED-CHUNK LOAD-PAMPHLET-FILE WRITE-OUTPUT-FILE)
; No value
That sets up the profiling on the defined functions. I then run my
benchmark test, which is essentially all of boot and interp:
SETUP> (load "./setup/runlispnotangle.lisp")
T
This takes anywhere from 10 to 13 seconds, bases on earlier testing.
Looking at the report:
SETUP> (sb-profile:report)
seconds | consed | calls | sec/call | name
----------------------------------------------------------
5.369 | 101,785,848 | 761 | 0.007055 |
CHECK-FOR-REFERENCED-CHUNK
4.869 | 72,160,120 | 802 | 0.006072 | READ-IN-CHUNK
0.378 | 2,271,408 | 207 | 0.001826 | WRITE-OUTPUT-FILE
0.204 | 4,750,544 | 207 | 0.000985 | LOAD-PAMPHLET-FILE
0.066 | 1,925,024 | 10,731 | 0.000006 |
CHECK-FOR-TOPLEVEL-CHUNK
0.031 | 296,264 | 802 | 0.000039 | MAKE-NEW-CHUNK
0.019 | 0 | 1,557 | 0.000012 | GET-CHUNK-CONTENTS
0.010 | 20,480 | 800 | 0.000013 | ADD-TO-CHUNK-CONTENTS
----------------------------------------------------------
10.946 | 183,209,688 | 15,867 | | Total
estimated total profiling overhead: 0.03 seconds
overhead estimation parameters:
2.4e-8s/call, 2.088e-6s total profiling, 9.44e-7s internal profiling
; No value
interesting things immediately jump out - the majority of the read-line
calls are in read-in-chunk and load-pamphlet-file, but they account for
only about half the time. Admittedly that's already as long as noweb
takes to finish the job, but the real killer is
CHECK-FOR-REFERENCED-CHUNK. So, since read-line was the initial
suspect, we take the instrumenting one step further and add some more
basic functions:
SETUP> (sb-profile:reset)
NIL
SETUP> (sb-profile:profile read-line string-equal concatenate search)
; No value
We run the identical test:
SETUP> (load "./setup/runlispnotangle.lisp")
T
and get a new report:
SETUP> (sb-profile:report)
seconds | consed | calls | sec/call | name
-----------------------------------------------------------
5.533 | 89,786,440 | 11,880 | 0.000466 | CONCATENATE
2.402 | 0 | 160,425 | 0.000015 | SEARCH
1.971 | 49,896,872 | 761 | 0.002590 |
CHECK-FOR-REFERENCED-CHUNK
0.445 | 31,027,600 | 168,558 | 0.000003 | READ-LINE
0.308 | 1,564,872 | 207 | 0.001487 | WRITE-OUTPUT-FILE
0.154 | 15,594,040 | 802 | 0.000192 | READ-IN-CHUNK
0.021 | 90,736 | 11,315 | 0.000002 | STRING-EQUAL
0.019 | 0 | 1,557 | 0.000012 | GET-CHUNK-CONTENTS
0.003 | 20,160 | 802 | 0.000004 | MAKE-NEW-CHUNK
0.001 | 14,880 | 800 | 0.000002 | ADD-TO-CHUNK-CONTENTS
0.000 | 2,523,816 | 207 | 0.000000 | LOAD-PAMPHLET-FILE
0.000 | 2,074,864 | 10,731 | 0.000000 |
CHECK-FOR-TOPLEVEL-CHUNK
-----------------------------------------------------------
10.856 | 192,594,280 | 368,045 | | Total
estimated total profiling overhead: 0.77 seconds
overhead estimation parameters:
2.4e-8s/call, 2.088e-6s total profiling, 9.44e-7s internal profiling
; No value
Ah - concatenate by itself takes about as long as noweb does to do the
complete job. search and read-line together take less than 3s, and
are called a combined total of over 300k times to concatenate's less
than 12k. This seems to suggest read-line, while slower than
read-sequence, is not yet the limiting factor.
Unfortunately, unless someone knows of a library that implements the
type of system Waldek is talking about, it looks like there is some
work ahead to implement the best of all possible notangles. I may go
ahead and use the less efficient one for the moment to try other things
like teaching asdf to read pamphlet files, and when we are ready to go
"live" we can try for high end optimization targets. Waldek (if you
made it this far), how much work do you think is involved with setting
up the full polished system? Also, can you recommend some background
reading on the technique you're describing?
\start
Date: Sun, 18 Feb 2007 01:08:36 -0500
From: Bill Page
To: Arthur Ralfs
Subject: RE: MathML package
On February 17, 2007 10:05 PM Arthur Ralfs wrote:
>
> I've posted my MathML package on SandBoxMathML.
> I'm still working on both the code and the documentation but
> it does work now. I've also included the diff files needed to
> patch Axiom so it can be built with mathml as a new output
> form. There are also a few files to help with viewing the
> output in Firefox.
>
Arthur,
Thank you very much for this contribution! I think this will
be very important for the development of new users interfaces
for Axiom. At the moment I am bogged down with other activities
but I plan to install your patches in my version of Axiom soon
and give this a test run.
Perhaps we can also install this on the Axiom Wiki web server
so that MathML output can be viewed directly in the Wiki. Last
time I tried this (with the Reduce MathML interface) I ran into
problems with forcing the Wiki to generate the correct headers
for web pages that contain MathML. Do you know of any way to
embed MathML into HTML that does not (quite) conform to the
XHTML standard?
Regards,
Bill Page.
PS. You might notice that I added your mathml.spad pamphlet as
a page on the Wiki (see link on left sidebar of SandBoxMathML)
so now you can see the documentation and code online.
\start
Date: Sun, 18 Feb 2007 00:17:18 -0800
From: Arthur Ralfs
To: Bill Page
Subject: Re: MathML package
Bill Page wrote:
> Arthur,
>
> Perhaps we can also install this on the Axiom Wiki web server
> so that MathML output can be viewed directly in the Wiki. Last
> time I tried this (with the Reduce MathML interface) I ran into
> problems with forcing the Wiki to generate the correct headers
> for web pages that contain MathML. Do you know of any way to
> embed MathML into HTML that does not (quite) conform to the
> XHTML standard?
>
> Regards,
> Bill Page.
>
>
Bill,
As far as I know the following is the "correct" way to embed mathml into
xhtml. The file needs to have the extension xml or xhtml. html doesn't
work (in Firefox), I guess however that if delivering the page with a
web server the content type could be set so that the file extension
wouldn't matter.
<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
"http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>MathML Test </title>
</head>
<body>
<math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big"
display="block">
<msup><mi>x</mi><mn>2</mn></msup>
</math>
</body>
</html>
This also works, again with file extension xml or xhtml.
<html>
<body>
<math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big"
display="block">
<msup><mi>x</mi><mn>2</mn></msup>
</math>
</body>
</html>
\start
Date: 18 Feb 2007 03:19:11 -0600
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: No progress on notangle
Cliff Yapp writes:
[...]
| This raises a question for me - I know Tim has need of a very fast
| notangle for his work, but does Axiom actually need this kind of speed?
Yes!
>From my perspective, anything that is slower (by any margin) than
current noweb isn't worth replacing it. Axiom builds tens of hundreds
of algebras and noweb is invoked on all files. I don't want to slow
down more the build. Yes, this is religious issue, but it takes too
long to build Axiom, which slows down the patch-build-test cycle.
\start
Date: Sun, 18 Feb 2007 05:10:19 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: No progress on notangle
--- Gabriel Dos Reis wrote:
> Cliff Yapp writes:
>
> [...]
>
> | This raises a question for me - I know Tim has need of a very fast
> | notangle for his work, but does Axiom actually need this kind of
> | speed?
>
> Yes!
<grin> ask a silly question... OK, I'll keep trying to follow what
Waldek is doing.
> From my perspective, anything that is slower (by any margin) than
> current noweb isn't worth replacing it. Axiom builds tens of
> hundreds of algebras and noweb is invoked on all files.
> I don't want to slow down more the build. Yes, this is religious
> issue, but it takes too long to build Axiom, which slows down the
> patch-build-test cycle.
OK... Hmm. What about this - I already have taught sbcl how to run
the external notangle command for some previous work. What if we set
it up that the lisp notangle command first looks for the external
notangle and tries to run it, but failing that falls back to the
internal one? That way, we can make use of a pre-installed noweb if
it's available, and if that fails fall back on the lisp version.
If/when we get a faster one we simply reverse the order in which the
options are tried. For that matter, we can add the perl one to the
list as well - I've never benchmarked that one so I can't say how fast
it is.
For the case where noweb isn't already installed, I guess it's a
question of whether the increased time of cl-notangle is greater than
the time it takes to build the regular noweb. I haven't timed the
noweb build so I'm not sure - I don't think the 7 second difference for
boot+interp would do it but of course the real volume is in the algebra
source files which I've not yet tried.
I guess another question is whether Axiom is set up so that ./configure
can build only noweb and nothing else on request.
\start
Date: Sun, 18 Feb 2007 09:28:33 -0600 (CST)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: No progress on notangle
On Sun, 18 Feb 2007, C Y wrote:
[...]
| I guess another question is whether Axiom is set up so that ./configure
| can build only noweb and nothing else on request.
make all-noweb
\start
Date: Sun, 18 Feb 2007 12:50:10 -0600
From: Tim Daly
To: Camm Maguire
Subject: GCC/GCL warning messages
Camm,
I'm building the next Axiom release. During the GCL build I see a large
number of messages that read:
gcl_defmacro.c:In function `L12':
gcl_defmacro.c:79: warning: dereferencing type-punned pointer will
break strict-aliasing rules
C99 language semantics now assume that pointers to different types
point to different memory locations, which is obvious nonsense, but
part of the new standard.
You might want to add -fno-strict-aliasing option to the GCC command line.
The alternative fix is to embed a (void *) between your cast and your
thing thus:
x = (yourcast)(void *)thing
\start
Date: Sun, 18 Feb 2007 21:19:49 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: No progress on notangle
Below is a newer version of CL notangle, this time handling recursive
references. There are still significant differences compared to
real notangle (lack of @ escapes, different end of line handling, ...).
I also fixed performace problem in scan-for-chunks (previous version
was using 'equal' and sbcl emited actual call to 'equal', current
version uses 'eql' which generates inline code). Another performance
problem was using arrays of bytes as hash keys (completly killed
performance for pamphlets with many small chunks, or chunks
split into many small pieces). I solved this problem converting
arrays to strings before hashing.
This version seem to be significantly faster than notangle: it is able
to process simple 8 Mb file (containing few big chunks) in 0.14s while
notangle needs 2s. On 8Mb file containing 1000 chunks, each consisting
of 100 pieces 10 lines each, my version needs 0.24s, while notangle
uses 2.85s.
BTW. Timing was done on 2GHz Athlon 64. Notangle came from Axiom build,
Lisp is sbcl 1.0. I tried also clisp, but it is quite slow (need 8.73
senconds on my second test file) -- no wonder since I use a low level
code. This version (like the previous one) does not work with gcl
(ANSI 2.6.5 interpreter claims that 'read-sequence' is undefined,
non-ANSI interpreter chokes on 'defclass').
(defconstant start-tag-code-1 (char-code #\<))
(defconstant start-tag-code-2 (char-code #\<))
(defconstant end-tag-code-1 (char-code #\>))
(defconstant end-tag-code-2 (char-code #\>))
(defconstant end-tag-code-3 (char-code #\=))
(defconstant start-marker-code-1 (char-code #\<))
(defconstant start-marker-code-2 (char-code #\<))
(defconstant end-marker-code-1 (char-code #\>))
(defconstant end-marker-code-2 (char-code #\>))
(defconstant chunk-end-code (char-code #\@))
(defconstant newline-code 10)
(defconstant space-code (char-code #\ ))
(defun read-file (f)
(let* ((b-len (file-length f))
(buff (make-array (list (+ b-len 1))
:element-type '(unsigned-byte 8))))
(read-sequence buff f)
(setf (aref buff b-len) newline-code)
buff))
(defun read-named-file (name)
(with-open-file (f name :element-type '(unsigned-byte 8))
(read-file f)))
(defclass chunk ()
((chunk-name
:initarg :chunk-name
:initform (error "Must supply a chunk name.")
:reader chunk-name
:documentation "Name of chunk.")
(chunk-contents
:initarg :chunk-contents
:initform '()
:accessor chunk-contents
:documentation "Text of chunk - may include references to other chunks")))
(defparameter *chunk-hash-table* (make-hash-table :test 'equal))
(defun add-to-chunk-contents (name content)
(declare (optimize (speed 3)))
(let ((chunk (gethash name *chunk-hash-table*)))
(if (not chunk)
(setf chunk (setf (gethash name *chunk-hash-table*)
(make-instance 'chunk :chunk-name name))))
(push content (chunk-contents chunk))))
(defun view-all-chunks ()
(maphash #'(lambda (k v) (format t "~a => ~S~&" k (chunk-contents v))) *chunk-hash-table*))
(defun print-chunk-name (name line-number)
(format t "Chunk start in line ~A: <<" line-number)
(dotimes (i (array-dimension name 0))
(format t "~A" (code-char (aref name i))))
(format t ">>~&"))
(defun array-to-string (ar)
(declare (optimize (speed 3))
(type (simple-array (unsigned-byte 8) (*)) ar))
(let* ((len (array-dimension ar 0))
(str (make-string len)))
(dotimes (i len)
(setf (aref str i) (code-char (aref ar i))))
str))
(defun scan-for-chunks (buff)
(declare (optimize (speed 3)))
(prog ((pos -1)
(end-buff (- (array-dimension buff 0) 1))
(start-pos)
(code)
(chunk-name)
(content nil)
(chunk-start-pos)
(chunk-end-pos)
(line-number 0))
(declare (type (signed-byte 32) pos end-buff line-number)
(type (simple-array (unsigned-byte 8) (*)) buff))
normal-start
(incf pos)
(incf line-number)
(if (>= pos end-buff)
(return-from scan-for-chunks))
(setf code (aref buff pos))
(if (eql code start-tag-code-1)
(go chunk-start-tag-1))
(if (eql code newline-code)
(go normal-start))
(go normal)
normal
(incf pos)
(setf code (aref buff pos))
(if (eql code newline-code)
(go normal-start))
(go normal)
chunk-start-tag-1
(incf pos)
(setf code (aref buff pos))
(if (eql code start-tag-code-2)
(progn
(setf start-pos (+ pos 1))
;;; (format t "start-pos: ~A, char: ~A~&" start-pos
;;; (aref buff start-pos))
(go in-chunk-start-tag)))
(if (eql code newline-code)
(go normal-start))
(go normal)
in-chunk-start-tag
(incf pos)
(setf code (aref buff pos))
(if (eql code end-tag-code-1)
(go in-chunk-start-tag-3))
(if (eql code newline-code)
(go normal-start))
(go in-chunk-start-tag)
in-chunk-start-tag-3
(incf pos)
(setf code (aref buff pos))
(if (eql code end-tag-code-2)
(go in-chunk-start-tag-4))
(if (eql code newline-code)
(go normal-start))
(go normal)
in-chunk-start-tag-4
(incf pos)
(setf code (aref buff pos))
(if (eql code end-tag-code-3)
(progn
(setf chunk-name (subseq buff start-pos (- pos 2)))
(go in-chunk-start-tag-trailing)))
(if (eql code newline-code)
(go normal-start))
(go normal)
in-chunk-start-tag-trailing
(incf pos)
(setf code (aref buff pos))
(if (eql code newline-code)
(progn
;;; (print-chunk-name chunk-name line-number)
(setf chunk-start-pos (+ pos 1))
(go in-chunk)))
(if (eql code space-code)
(go in-chunk-start-tag-trailing))
(go normal)
chunk-start
(setf chunk-end-pos pos)
(incf pos)
(if (>= pos end-buff)
(break "unexpected end of file"))
(setf code (aref buff pos))
(incf line-number)
(if (eql code newline-code)
(go chunk-start))
(if (eql code start-marker-code-1)
(go start-marker-1))
(if (eql code chunk-end-code)
(progn
(push (list chunk-start-pos chunk-end-pos) content)
(setf content (reverse content))
;;; (format t "Adding ~S to ~S~&" content chunk-name)
(add-to-chunk-contents
(array-to-string chunk-name)
content)
;;; (view-all-chunks)
(setf content nil)
(go chunk-end-trailing)))
(go in-chunk)
chunk-end-trailing
(incf pos)
(setf code (aref buff pos))
(if (eql code newline-code)
(go normal-start))
(if (eql code space-code)
(go chunk-end-trailing))
(format t "pos: ~A, code: ~A~&" pos code)
(break "garbage after end of chunk marker")
in-chunk
(incf pos)
(setf code (aref buff pos))
(if (eql code newline-code)
(go chunk-start))
(if (eql code start-marker-code-1)
(go start-marker-1))
(go in-chunk)
start-marker-1
(incf pos)
(setf code (aref buff pos))
(if (eql code start-marker-code-2)
(progn
(setf start-pos (+ pos 1))
(go start-marker-2)))
(if (eql code newline-code)
(go chunk-start))
(go in-chunk)
start-marker-2
(incf pos)
(setf code (aref buff pos))
(if (eql code end-marker-code-1)
(go start-marker-3))
(if (eql code newline-code)
(go chunk-start))
(go start-marker-2)
start-marker-3
(incf pos)
(setf code (aref buff pos))
(if (eql code end-marker-code-2)
(progn
(push (list chunk-start-pos (- start-pos 2)) content)
(push (array-to-string
(subseq buff start-pos (- pos 1)))
content)
(setf chunk-start-pos (+ pos 1))
(go in-chunk)))
(if (eql code newline-code)
(go chunk-start))
(go start-marker-2)))
(defun write-chunk (buff name out-file)
(let ((chunk (gethash name *chunk-hash-table*)))
(dolist (segs (reverse (chunk-contents chunk)))
(dolist (seg segs)
(if (consp seg)
(write-sequence buff out-file :start (nth 0 seg)
:end (nth 1 seg))
(write-chunk buff seg out-file))))))
(defun untangle (in-file out-name)
(clrhash *chunk-hash-table*)
(let ((buff (read-named-file in-file))
(chunk)
(name (make-array (list 1)
:element-type '(unsigned-byte 8)
:initial-element (char-code #\*))))
(scan-for-chunks buff)
;;; (setf name (array-to-string name))
(setf name "*")
(setf chunk (gethash name *chunk-hash-table*))
(if (not chunk)
(break "No main chunk"))
(with-open-file (out-file out-name :direction :output
:if-exists :supersede
:element-type '(unsigned-byte 8))
(write-chunk buff name out-file))))
\start
Date: Sun, 18 Feb 2007 22:01:48 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: No progress on notangle
Unforunately, I am a lisp illiterate. :-( So I don't even know how to
start your program on test files. So I would like to give a little
(meaningless) testfile.
The output of notangle on the program below is
----------------------
foo(x: Integer): Integer == z := 1
for i in 1.. x repeat
h := 1
for j in 1..i repeat
h := h + j
h := 2*h
h := if h > 100
then
h-2
else
h+2
h := 3*h
z := h
z
----------------------
Does your program give the same result?
Furthermore what about the option "-L" that can be given to notangle?
That is particularly useful if your compiler emits a column number for
error messages. #pile mode is bad in that case anyway, but there are
also files that are indentation-independent.
Ralf
---BEGIN aaa.spad.pamphlet
<<*>>=
foo(x: Integer): Integer == <<foo body>>
@
<<foo body>>=
z := 1
for i in 1.. x repeat
<<auxiliary computation>>
h := <<post computation>>
<<binding z>>
z
@
<<auxiliary computation>>=
h := 1
for j in 1..i repeat
h := h + j
h := 2*h
@
<<post computation>>=
if h > 100
then
h-2
else
h+2
@
<<binding z>>=
h := 3*h
z := h
@
---END aaa.spad.pamphlet
\start
Date: Sun, 18 Feb 2007 14:01:53 -0800 (PST)
From: Cliff Yapp
To: Waldek Hebisch
Subject: notangle
(changing the subject since it's no longer true ;-)
--- Waldek Hebisch wrote:
> Below is a newer version of CL notangle, this time handling recursive
> references. There are still significant differences compared to
> real notangle (lack of @ escapes, different end of line handling,
> ...).
Well, we probably don't actually need the full power of noweb notangle
- I think it makes more sense to enforce sane pamphlet writing style
instead (improves human readability, for that matter - stays
consistent).
By lack of @ escapes, do you mean that any @ in the file is treated as
the end of a code chunk, e.g. no awareness of position? (e.g. it won't
be able to process itself as a pamphlet?) From what I saw earlier the
only two things that are really needed are recognizing an illegal chunk
name due to newline inclusion (you may not even need that one the way
you've defined your start and end chars) and making sure @ is right
after a newline (at least for parsing Axiom files, which is the main
goal.) I'll have a go at it later and see how it behaves.
> I also fixed performace problem in scan-for-chunks (previous version
> was using 'equal' and sbcl emited actual call to 'equal', current
> version uses 'eql' which generates inline code). Another performance
> problem was using arrays of bytes as hash keys (completly killed
> performance for pamphlets with many small chunks, or chunks
> split into many small pieces). I solved this problem converting
> arrays to strings before hashing.
Wow. VERY impressive work. One question Waldek - I'm willing to try
to convert this code into a literate document for purposes of Axiom
inclusion, but I fear I'm not competent to describe these issues and
reasons for specific choices. I'll take a stab at it using your emails
as a starting point (indeed, that might be a good way to ensure the
documentation covers enough for other clueless beginners) but are you
up for a few painfully ignorant questions? ;-)
Also, are you OK with the modified BSD license for this? It's
essentially all your code at this point so I don't want to presume.
> This version seem to be significantly faster than notangle: it is
> able to process simple 8 Mb file (containing few big chunks) in 0.14s
> while notangle needs 2s. On 8Mb file containing 1000 chunks, each
> consisting of 100 pieces 10 lines each, my version needs 0.24s, while
> notangle uses 2.85s.
You may have just become the poster child for those trying to debunk
the "lisp is slow" myth ;-).
> BTW. Timing was done on 2GHz Athlon 64. Notangle came from Axiom
> build, Lisp is sbcl 1.0. I tried also clisp, but it is quite slow
> (need 8.73 senconds on my second test file) -- no wonder since I use
> a low level code. This version (like the previous one) does not
> work with gcl (ANSI 2.6.5 interpreter claims that 'read-sequence'
> is undefined, non-ANSI interpreter chokes on 'defclass').
Um. Clisp doesn't surprise me, and normally if speed is a concern
people don't run on Clisp anyway. I also ran into the defclass thing
on GCL - perhaps we could use defstruct instead? I don't know that
there's any particular reason to use CLOS other than convenience and
trying to be "modern".
Cheers, and thanks again for some really excellent work!
\start
Date: Sun, 18 Feb 2007 23:13:52 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: No progress on notangle
Ralf Hemmecke wrote:
> Unforunately, I am a lisp illiterate. :-( So I don't even know how to
> start your program on test files. So I would like to give a little
> (meaningless) testfile.
If you have sbcl you can do (assuming that you have saved the program
int the file "nono2.lisp"):
(load "nono2.lisp")
(untangle "input.file" "output.file")
For timing:
(time (untangle "input.file" "output.file"))
Other Lisps require extra commands to compile the code but at least
up to version 1.0 sbcl automatically compiles the code.
>
> The output of notangle on the program below is
>
> ----------------------
> foo(x: Integer): Integer == z := 1
> for i in 1.. x repeat
> h := 1
> for j in 1..i repeat
> h := h + j
> h := 2*h
> h := if h > 100
> then
> h-2
> else
> h+2
> h := 3*h
> z := h
> z
> ----------------------
>
> Does your program give the same result?
>
No. First I have noticed that notangle behaves in rather inconsitent
way. I do not want to waste time trying to find out exact rules used
by notangle. With pile semantics it seems better to integrate
notangle like processing with Spad scanning and treat each hunk as
a pile (IMHO having piles spanning hunk boundary is just confusing
and error prone).
To supporting such feature would require storing information about
all line endings. This is not very hard, but I do not want to
invest much more time in this program unless other find it useful.
Also note that the reason to use Lisp is so that the program can
run inside Axiom process. For external program I would use C
which probably would be faster to write and would give faster
program. Note that this is not intended to be a general remark
about languages: I simply know C better (most of the time for
writing program was actually spent in CL manuals), I know C tools
for scanning, I have a collection of C utility routines which
make the task easier.
> Furthermore what about the option "-L" that can be given to notangle?
> That is particularly useful if your compiler emits a column number for
> error messages. #pile mode is bad in that case anyway, but there are
> also files that are indentation-independent.
>
That could be easily addedd: the program traces line numbers anyway
(for debugging purposes) so it would be easy to store them together
with chunks and emit when needed.
> ---BEGIN aaa.spad.pamphlet
> <<*>>=
> foo(x: Integer): Integer == <<foo body>>
> @
>
> <<foo body>>=
> z := 1
> for i in 1.. x repeat
> <<auxiliary computation>>
> h := <<post computation>>
> <<binding z>>
> z
> @
>
> <<auxiliary computation>>=
> h := 1
> for j in 1..i repeat
> h := h + j
> h := 2*h
> @
>
> <<post computation>>=
> if h > 100
> then
> h-2
> else
> h+2
> @
>
> <<binding z>>=
> h := 3*h
> z := h
> @
> ---END aaa.spad.pamphlet
>
BTW: is the the test program supposed to be in good literate style?
both <<auxiliary computation>> and <<binding z>> change h without
any hint about such possibility in <<foo body>>. I find such
practice _very_ bad for readability.
\start
Date: Sun, 18 Feb 2007 23:37:19 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: No progress on notangle
> First I have noticed that notangle behaves in rather inconsitent
> way.
Really? I've met some cases where notangle does not as I would like, but
these cases are rare.
> I do not want to waste time trying to find out exact rules used
> by notangle. With pile semantics it seems better to integrate
> notangle like processing with Spad scanning and treat each hunk as
> a pile (IMHO having piles spanning hunk boundary is just confusing
> and error prone).
Of course, I would also forbid the equivalent way of saying
<<*>>=
foo(): () == {
some code
@
some doc
<<*>>=
some more code
}
@
But the code I gave was not of that style.
>> Furthermore what about the option "-L" that can be given to notangle?
>> That is particularly useful if your compiler emits a column number for
>> error messages. #pile mode is bad in that case anyway, but there are
>> also files that are indentation-independent.
> That could be easily addedd: the program traces line numbers anyway
> (for debugging purposes) so it would be easy to store them together
> with chunks and emit when needed.
But you know that then notangle doesn't indentate? If you remove the
#line lines from the output of "notangle -L ..." you don't get the same
output as "notangle ...". And this is actually a good thing. I once
complaint about the missing indentation, but Norman refused to change
the behaviour and he is right.
>> ---BEGIN aaa.spad.pamphlet
>> <<*>>=
>> foo(x: Integer): Integer == <<foo body>>
>> @
>>
>> <<foo body>>=
>> z := 1
>> for i in 1.. x repeat
>> <<auxiliary computation>>
>> h := <<post computation>>
>> <<binding z>>
>> z
>> @
>>
>> <<auxiliary computation>>=
>> h := 1
>> for j in 1..i repeat
>> h := h + j
>> h := 2*h
>> @
>>
>> <<post computation>>=
>> if h > 100
>> then
>> h-2
>> else
>> h+2
>> @
>>
>> <<binding z>>=
>> h := 3*h
>> z := h
>> @
>> ---END aaa.spad.pamphlet
> BTW: is the the test program supposed to be in good literate style?
> both <<auxiliary computation>> and <<binding z>> change h without
> any hint about such possibility in <<foo body>>. I find such
> practice _very_ bad for readability.
Of course that was just a cooked up example for the indentation problem.
What I like is code like...
<<implementation: gosperForm>>=
gosperForm(f: P, g: P): (P, P, P) == {
import from FractionalRoot Integer;
import from Integer;
nonNegativeIntegerRoots: Generator Integer := {
<<nonnegative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>
}
<<build up the Gosper triple $(p, q, c)$>>
(p, q, c)
}
@
<<non-negative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>=
r: UPh := resultant(lift(f), lift(g)(n+h::UPhn));
v for i in integerRoots r | (v:=integralValue i) > 0;
@
<<build up the Gosper triple $(p, q, c)$>>=
c:P := 1;
p := f;
q := g;
for root in nonNegativeIntegerRoots repeat {
u:P := gcd(p, q(x + root::P));
p := quotient(p, u);
q := quotient(q, u(x - root::P));
for j in 1..root repeat c := c*u(x - j::P);
}
@
... and even that could be improved. (I omitted the latex part.)
Anyway, I don't claim that I know the best way to write literate programs.
\start
Date: 18 Feb 2007 17:26:37 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: GCC/GCL warning messages
Cc: Camm Maguire
Tim Daly writes:
| Camm,
|
| I'm building the next Axiom release. During the GCL build I see a large
| number of messages that read:
|
| gcl_defmacro.c:In function `L12':
| gcl_defmacro.c:79: warning: dereferencing type-punned pointer will
| break strict-aliasing rules
|
| C99 language semantics now assume that pointers to different types
| point to different memory locations, which is obvious nonsense, but
| part of the new standard.
That statement is obviously untrue.
The non-aliasing rule, which has always been there since I don't know
when -- certainly, it is part of C89, and it is not a C99 invention --
says that the following is undefined behaviour
double z;
*(long*)&z = 1;
printf ("%g", z);
That makes perfect sense. Why would you think it is nonsense?
| You might want to add -fno-strict-aliasing option to the GCC command line.
Instead of papering over the incorrectness, I would suggest to fix it.
\start
Date: Sun, 18 Feb 2007 18:45:49 -0500
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: No progress on notangle
Ralf, I take it what you expect, based on your example, is
that notangle will "fill in" the pile spacing used by each
chunk in the output? Is this default behavior or does it
need an option?
I must say I'm a bit confused - my original thought was that
all notangle had to do was get the code out of the chunks
"as is" line by line and stuff it into the output file in
the right order. Can you point me to a couple examples of using
-L and what its effects/utility are? (Sorry if they're in the
archives - I can try digging later.)
I've been reading over Waldek's code and I think I understand
what he is up to now, so I'll see what I can do with it - I can
see where automatic generation of some of this code via macro
would be a Good Thing.
Waldek, I'm not sure if others will find it useful but I do intend
to use it to try and make asdf load pamphlet files transparently.
(or more correctly, load code from pamphlet files.) I really appreciate
the time you've put into this and I for one have learned something
from it :)
\start
Date: Mon, 19 Feb 2007 00:52:48 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: notangle
C Y wrote:
> --- Waldek Hebisch wrote:
>
> > Below is a newer version of CL notangle, this time handling recursive
> > references. There are still significant differences compared to
> > real notangle (lack of @ escapes, different end of line handling,
> > ...).
>
> Well, we probably don't actually need the full power of noweb notangle
> - I think it makes more sense to enforce sane pamphlet writing style
> instead (improves human readability, for that matter - stays
> consistent).
>
> By lack of @ escapes, do you mean that any @ in the file is treated as
> the end of a code chunk, e.g. no awareness of position? (e.g. it won't
> be able to process itself as a pamphlet?) From what I saw earlier the
> only two things that are really needed are recognizing an illegal chunk
> name due to newline inclusion (you may not even need that one the way
> you've defined your start and end chars) and making sure @ is right
> after a newline (at least for parsing Axiom files, which is the main
> goal.) I'll have a go at it later and see how it behaves.
>
Look at the following C program:
<<*>>=
int
fun(int x)
{
return (x@<<8) | (x>>8);
}
@
<<8) | (x>>=
+
@
Normal notangle gives:
int
fun(int x)
{
return (x<<8) | (x>>8);
}
while CL version gives:
int
fun(int x)
{
return (x@+8);
}
Without the "8) | (x" chunk CL notangle would just halt on error.
> > I also fixed performace problem in scan-for-chunks (previous version
> > was using 'equal' and sbcl emited actual call to 'equal', current
> > version uses 'eql' which generates inline code). Another performance
> > problem was using arrays of bytes as hash keys (completly killed
> > performance for pamphlets with many small chunks, or chunks
> > split into many small pieces). I solved this problem converting
> > arrays to strings before hashing.
>
> Wow. VERY impressive work. One question Waldek - I'm willing to try
> to convert this code into a literate document for purposes of Axiom
> inclusion, but I fear I'm not competent to describe these issues and
> reasons for specific choices. I'll take a stab at it using your emails
> as a starting point (indeed, that might be a good way to ensure the
> documentation covers enough for other clueless beginners) but are you
> up for a few painfully ignorant questions? ;-)
>
Ask, I will try too answer.
> Also, are you OK with the modified BSD license for this? It's
> essentially all your code at this point so I don't want to presume.
>
Sure, I prefer to omit license from files to avoid clutter, but use
the code any way you wish. For Axiom distribution probably putting
a single line like "For legal info see Axiom.Licence" could be a good
compromise between beetween legal pedantry and practicality.
> > This version seem to be significantly faster than notangle: it is
> > able to process simple 8 Mb file (containing few big chunks) in 0.14s
> > while notangle needs 2s. On 8Mb file containing 1000 chunks, each
> > consisting of 100 pieces 10 lines each, my version needs 0.24s, while
> > notangle uses 2.85s.
>
> You may have just become the poster child for those trying to debunk
> the "lisp is slow" myth ;-).
>
Do not be too eager with this. It is clear that even for strings
hashtables take a lot of time. We are forced to do an otherwise
useless copy to string to avoid huge slowdon. And in the main
loop the code is clearly worse then the code from a C compiler.
So the program is probably faster than similar Perl or Python
programs, but slower than good C version.
> > BTW. Timing was done on 2GHz Athlon 64. Notangle came from Axiom
> > build, Lisp is sbcl 1.0. I tried also clisp, but it is quite slow
> > (need 8.73 senconds on my second test file) -- no wonder since I use
> > a low level code. This version (like the previous one) does not
> > work with gcl (ANSI 2.6.5 interpreter claims that 'read-sequence'
> > is undefined, non-ANSI interpreter chokes on 'defclass').
>
> Um. Clisp doesn't surprise me, and normally if speed is a concern
> people don't run on Clisp anyway. I also ran into the defclass thing
> on GCL - perhaps we could use defstruct instead? I don't know that
> there's any particular reason to use CLOS other than convenience and
> trying to be "modern".
>
Yes, defstruct should be enough. 'read-sequence' (and I guess also
'write-sequence') causes more problems, because performance depends on
it. For gcl we probably must provide our own (calling C) versions.
\start
Date: Mon, 19 Feb 2007 01:26:10 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: No progress on notangle
On 02/19/2007 12:45 AM, C Y wrote:
> Ralf, I take it what you expect, based on your example, is
> that notangle will "fill in" the pile spacing used by each
> chunk in the output? Is this default behavior or does it
> need an option?
Getting the indentation right is the default behaviour. But it can get
rather complicated.
---BEGIN aaa.spad.pamphlet
<<*>>=
<<blah>><<foo>>
bar
@
<<blah>>=
x
XX
@
<<foo>>=
y
YY
@
---END aaa.spad.pamphlet
What would you expect? Perhaps
=================
x
XXy
YY
bar
=================
??? That is what I get with
notangle aaa.spad.pamphlet
Contrary to that with
notangle -L'#line %L "aaa.spad.pamphlet"%N' aaa.spad.pamphlet
I get
=============================
#line 7 "aaa.spad.pamphlet"
x
XX
#line 11 "aaa.spad.pamphlet"
y
YY
#line 4 "aaa.spad.pamphlet"
bar
=============================
> I must say I'm a bit confused - my original thought was that
> all notangle had to do was get the code out of the chunks
> "as is" line by line and stuff it into the output file in
> the right order. Can you point me to a couple examples of using
> -L and what its effects/utility are? (Sorry if they're in the
> archives - I can try digging later.)
I know you have downloaded Aldor-Combinat. After saying "make dvi"
you find two types of .as files under the src directory.
series.as -- generated without -L option
csseries.as -- generated with -L option.
Ignore the +++ comments since they are missing in the files that are not
prefixed by cs.
But generally the indentation with -L is *exactly* as in the original
source i.e. the .pamphlet/.nw file.
\start
Date: Mon, 19 Feb 2007 01:41:44 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: No progress on notangle
> > First I have noticed that notangle behaves in rather inconsitent
> > way.
>
> Really? I've met some cases where notangle does not as I would like, but
> these cases are rare.
>
Suppose that your program contains an arbitrary sequence of '@', '<<'
and '>>'. Do you know how to write the source file to get required
output? I did not want to waste time on this problem, but a few
trials gave rather bizzare results.
Your example suggest that notangle is consistent in its indentation
rules, but if you take "random" input the results look strange.
Also, I thought that notagle is inconsistent in it treatment of
tabs (sometimes mangles then, but preserves leading tabs in Makefiles),
but it seems that normaly notagle consistently mangles tabs and
just needs extra option to preserve tabs.
> >> Furthermore what about the option "-L" that can be given to notangle?
> >> That is particularly useful if your compiler emits a column number for
> >> error messages. #pile mode is bad in that case anyway, but there are
> >> also files that are indentation-independent.
>
> > That could be easily addedd: the program traces line numbers anyway
> > (for debugging purposes) so it would be easy to store them together
> > with chunks and emit when needed.
>
> But you know that then notangle doesn't indentate? If you remove the
> #line lines from the output of "notangle -L ..." you don't get the same
> output as "notangle ...". And this is actually a good thing. I once
> complaint about the missing indentation, but Norman refused to change
> the behaviour and he is right.
ATM CL version also do not indentate. It puts first char of the chunk
in the same line as <<xxx>> marker, but of course printing '#line' we
can also emit a newline before it.
> Of course that was just a cooked up example for the indentation problem.
> What I like is code like...
>
> <<implementation: gosperForm>>=
> gosperForm(f: P, g: P): (P, P, P) == {
> import from FractionalRoot Integer;
> import from Integer;
> nonNegativeIntegerRoots: Generator Integer := {
> <<nonnegative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>
> }
> <<build up the Gosper triple $(p, q, c)$>>
> (p, q, c)
> }
> @
>
> <<non-negative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>=
> r: UPh := resultant(lift(f), lift(g)(n+h::UPhn));
> v for i in integerRoots r | (v:=integralValue i) > 0;
> @
>
> <<build up the Gosper triple $(p, q, c)$>>=
> c:P := 1;
> p := f;
> q := g;
> for root in nonNegativeIntegerRoots repeat {
> u:P := gcd(p, q(x + root::P));
> p := quotient(p, u);
> q := quotient(q, u(x - root::P));
> for j in 1..root repeat c := c*u(x - j::P);
> }
> @
>
> ... and even that could be improved. (I omitted the latex part.)
>
> Anyway, I don't claim that I know the best way to write literate programs.
I am asking to understand which features of notangle are useful. Would
you need notangle for a programming language where by default input is
a comment, all code must be in procedures/functions, you can write
procedures in arbitrary order and you can have arbitrary procedure names
(but with special begin/end name markers).
In such language your example could look like:
<<implementation: gosperForm>>(f: P, g: P): (P, P, P)=
import from FractionalRoot Integer;
import from Integer;
nonNegativeIntegerRoots: Generator Integer := {
<<nonnegative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>(f, g, h)
}
<<build up the Gosper triple $(p, q, c)$>>
(p, q, c)
@
<<non-negative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>(f, g, h)=
r: UPh := resultant(lift(f), lift(g)(n+h::UPhn));
v for i in integerRoots r | (v:=integralValue i) > 0;
@
....
That would be less flexible that notangle because of need for explicit
parameter passing, but at least for me having explicit parameters
(and explicit scopes) makes text more readable.
\start
Date: Sun, 18 Feb 2007 21:25:41 -0500
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: notangle
Waldek Hebisch wrote:
>> You may have just become the poster child for those trying to debunk
>> the "lisp is slow" myth ;-).
>
> Do not be too eager with this. It is clear that even for strings
> hashtables take a lot of time. We are forced to do an otherwise
> useless copy to string to avoid huge slowdon. And in the main
> loop the code is clearly worse then the code from a C compiler.
> So the program is probably faster than similar Perl or Python
> programs, but slower than good C version.
Don't worry - I'm not usually one to get involved with language
wars anyway. But I think by any measure we would want to worry
about this result is excellent - after all, notangle as a percentage
of the total build time looks to be pretty small, so at some point
the time put in to optimize further reaches diminishing returns.
This solution should integrate well with Axiom, perform very well,
and can be expanded upon for other uses (like the SPAD compiler).
Thanks for all the effort to fix my original code - I'll see if
I can make defstruct work and get something that will do for
GCL as well.
(One question - I thought read-sequence was part of the ANSI
Common Lisp spec? Is it just that GCL hasn't implemented it yet?
Of course it's not so critical since we aren't running on the
ANSI image yet anyway.)
\start
Date: 19 Feb 2007 12:15:07 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: status of windows version
Dear all,
sorry about asking a FAQ...
Tomorrow I will have to install Axiom on a MS Windows machine for a very
renowned professor who wants to use my guessing package.
Is there anything I should be aware of? Is Windows version 0.1.4 the current
version? Is there any way to make hyperdoc, i.e., the "browse" functionality,
available under windows?
I guess wh-sandbox does not run under windows? (Bill said, build-improvements
does...)
\start
Date: Mon, 19 Feb 2007 09:31:30 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: status of windows version
Cc: Gabriel Dos Reis, Waldek Hebisch
On February 19, 2007 6:15 AM Martin Rubey wrote:
>
> sorry about asking a FAQ...
>
:-) No so frequent, I think.
> Tomorrow I will have to install Axiom on a MS Windows machine
> for a very renowned professor who wants to use my guessing
> package.
>
> Is there anything I should be aware of? Is Windows version
> 0.1.4 the current version?
Yes - current as of 2 years ago. :-(
> Is there any way to make hyperdoc, i.e., the "browse"
> functionality, available under windows?
>
No, not at present. I think the best way of supporting hyperdoc
on Windows is to use Microsoft Virtual PC (or VMware, both are
free) and install a linux system on the virtual machine, then
install Axiom, e.g. wh-sandbox. I use Virtual PC extensively.
It works very well - especially if you have at least a dual-core
machine and enough ram (at least 1 Gb.). If you need help with
> I guess wh-sandbox does not run under windows? (Bill said,
> build-improvements does...)
>
Yes, I have successfully built build-improvments on Windows.
Of course since there is no X-windows environment of Windows,
hyperdoc and graphics are not built.
wh-sandbox was branched from build-improvements before the
ability to build on Windows was added so, no, I don't think
wh-sandbox will build on Windows at this time. It would be nice
if Waldek or Gaby could merge the build-improvements branch
with the wh-sandbox branch. If they could do that, I think
it would form a very good basis for a new Axiom Silver
distribution.
\start
Date: 19 Feb 2007 09:24:39 -0600
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: status of windows version
Cc: Waldek Hebisch
Bill Page writes:
[...]
| wh-sandbox was branched from build-improvements before the
| ability to build on Windows was added so, no, I don't think
| wh-sandbox will build on Windows at this time. It would be nice
| if Waldek or Gaby could merge the build-improvements branch
| with the wh-sandbox branch. If they could do that, I think
| it would form a very good basis for a new Axiom Silver
| distribution.
Waldek is more familiar with wh-sandbox than me, so I would pass the
ball to him :-)
However, there are other experiments in wh-sandbox that we should
discuss before we consider it basis for Axiom Silver. That discussion
surely would be long and intense; so I would prefer Waldek works more
on it before we get to that point.
\start
Date: Mon, 19 Feb 2007 08:32:56 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Martin Rubey
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis
--- Bill Page wrote:
> > I guess wh-sandbox does not run under windows? (Bill said,
> > build-improvements does...)
>
> Yes, I have successfully built build-improvments on Windows.
Bill, is that result something we could wrap up in the NSIS installer
and push out as a release?
> Of course since there is no X-windows environment of Windows,
> hyperdoc and graphics are not built.
Maybe as an alternative to command-line-only we could bundle ntemacs
and the Emacs mode, and rig it to start that up when the icon is
clicked? Axiom is big enough that a few more megs probably won't break
anybody's back, and we could always provide a "no-emacs" binary if
someone wanted it.
When I tested emacs mode + Axiom on Windows it did succeed, give or
take a bug in turning input red when it is changed. (the latest cvs
emacs build fixed it but I doubt we would want to distribute that.)
Unfortunately, I don't have access to a Windows box so I'm not much
help on this issue :-(.
\start
Date: Tue, 20 Feb 2007 01:19:46 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: status of windows version
Gabriel Dos Reis wrote:
> Bill Page writes:
>
> [...]
>
> | wh-sandbox was branched from build-improvements before the
> | ability to build on Windows was added so, no, I don't think
> | wh-sandbox will build on Windows at this time. It would be nice
> | if Waldek or Gaby could merge the build-improvements branch
> | with the wh-sandbox branch. If they could do that, I think
> | it would form a very good basis for a new Axiom Silver
> | distribution.
>
> Waldek is more familiar with wh-sandbox than me, so I would pass the
> ball to him :-)
Well, I actually intended to bulk-merge changes to build-improvements
but some changes (like removal of DESTDIR) look backwards, some other
changes (src/algebra/Makefile.pamphlet and src/interp/Makefile.pamphlet)
are from my point of view mostly irrelevant (due to new algebra
bootstrap). In general many changes looks like incomplete transitions
(was there any reason not to ansify graph subdirectory?). I could
probably just pick changes needed for Windows build. But I decided
to not do so for two reasons:
- it would make full merge harder
- it is rather incovenint for me to test on Windows
> However, there are other experiments in wh-sandbox that we should
> discuss before we consider it basis for Axiom Silver. That discussion
> surely would be long and intense; so I would prefer Waldek works more
> on it before we get to that point.
Let me summarize main changes in wh-sandbox:
1) removal of unused code from compiler/interpreter
2) translating depsys using Shoe and removal of depsys bootstrap Lisp
3) new algebra bootstrap and removal of algebra bootstrap Lisp
4) mechanical generation of (most of) .pht pages
5) hyperdoc and algebra fixes
6) removal of useless files
7) pretty-printing of intermediate files and asq rewrite
8) adding guessing package written by Martin Rubey
Given change may be split into multiple commits, but looking at change
log should be clear how to categorize commits. Somebody making a
release may prefer to pick only bug fixes (position 5) or maybe
also guessing package. To large degree this should be possible since
(IIRC) only some documentation fixes depend on generation of .pht pages
(and one can just pick the newly generated pages), otherwise fixes do not
depend on structural changes. OTOH I consider structural changes
essential for future Axiom maintenance. I plan much deeper structural
changes, but IMHO they already give significant benefits. There
are some costs, for example new algebra bootstrap takes more time than
the old one. I feel reasonably confident that changes I made work
correctly so if I was making a release I would include them.
\start
Date: Mon, 19 Feb 2007 18:32:35 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: status of windows version
On Tue, 20 Feb 2007, Waldek Hebisch wrote:
| Well, I actually intended to bulk-merge changes to build-improvements
| but some changes (like removal of DESTDIR) look backwards, some other
It is a mistake to defined DESTDIR in a Makefile. The solution
I implemented in the build-improvements was a mild fix. The real
fix is to remove the definition. Which is what happened.
[...]
| 1) removal of unused code from compiler/interpreter
I'm nervous about code removal when I have not understood beyond "it
is dead code". It does not mean I'm opposed to it. I'm saying I'd
like to understand why the code is removed.
\start
Date: Tue, 20 Feb 2007 03:05:19 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Lisp comparator
Below is a little utility that I use to compare Lisp files produced
by Axiom. Axiom uses uninterned (gensymed) symbols in its output.
Such sumbols are printed like '#:G706711' where the numbers depend
on computation history. When Lisp is reading the file the numbers
does not matter at all -- what matter is if two such symbols are
equal (which is marked in special way) or different. When comparing
files as texts different numbering of gensymed symbols give a lot
of spuriouos differences. The program below can discard most such
differences (it does not recurse into arrays, so it may sometimes
show difference for textually identical files).
Note that this _not_ a polished code, just something that other may
find useful (comments show how the code may be called). BTW, I use
the Lisp code via a shell wrapper:
-------------<start wrapper>------------------
#!/bin/sh
exec /usr/bin/sbcl --noinform --noprint \
--load /var/tmp/hebisch/axp4/pp/ldiff.fasl \
--disable-debugger \
--eval '(make-package "VMLISP")' \
--eval '(make-package "BOOT")' \
--eval '(compare-files "'"$1"'" "'"$2"'")' \
--eval '(sb-ext:quit)'
# --disable-debugger
-------------<end wrapper>--------------------
(defun read-forms (file)
(let ((result nil) (pp))
(do () (nil)
(setf pp (read file nil nil))
(if (null pp)
(return-from read-forms (reverse result))
(setf result (cons pp result))))))
;;; (compare-forms '(ala ola "as" (1 2 3)) '(ala ola "as" (1 2 3)))
(defun compare-forms (f1 f2)
(let ((sym-hash1 (make-hash-table))
(sym-hash2 (make-hash-table))
(sym-count 0))
(labels
((compare-forms-0 (f1 f2)
(cond
((consp f1)
(if (not (consp f2))
(return-from compare-forms nil))
(do () (nil)
(let ((el1 (car f1)) (el2 (car f2)))
(setf f1 (cdr f1))
(setf f2 (cdr f2))
(if (not (compare-forms-0 el1 el2))
(return-from compare-forms nil)))
(if (not (and (consp f1) (consp f2)))
(return-from compare-forms-0
(compare-forms-0 f1 f2))))
t)
((and (symbolp f1) (not (symbol-package f1)))
(if (or (not (symbolp f2)) (symbol-package f2))
(return-from compare-forms nil))
(let ((pp1 (gethash f1 sym-hash1))
(pp2 (gethash f2 sym-hash2)))
(if (not (equal pp1 pp2))
(return-from compare-forms nil))
(cond
((not pp1)
(incf sym-count)
(setf (gethash f1 sym-hash1) sym-count)
(setf (gethash f2 sym-hash2) sym-count)))
t))
(t (equalp f1 f2)))))
(compare-forms-0 f1 f2))))
(defun print-heading (el)
(let ((*print-level* 2) (*print-length* 3))
(pprint el)))
;;; (compare-files "/mn/a6/pom/axiom/nn5/ax-build1/int/algebra/INT.NRLIB/code.lsp" "/mn/a6/pom/axiom/nn6/ax-build1/int/algebra/INT.NRLIB/code.lsp")
(defun compare-files (name1 name2)
(let* ((fil1 (open name1 :direction :input :if-does-not-exist :error))
(fil2 (open name2 :direction :input :if-does-not-exist :error))
(l1 (read-forms fil1)) (l2 (read-forms fil2)) (el2 nil))
(dolist (el1 l1)
(if (not (consp l2))
(return-from compare-files (and (format t "short l2~&") nil)))
(setf el2 (car l2))
(setf l2 (cdr l2))
(if (not (compare-forms el1 el2))
(progn ()
(format t "Difference in:")
(print-heading el1)
(format t "~&and:")
(print-heading el2)
(format t "~&")
(return-from compare-files nil))))
(not l2)))
\start
Date: Mon, 19 Feb 2007 20:47:06 -0600
From: Tim Daly
To: Cliff Yapp, Waldek Hebisch
Subject: lisp speedups
Another technique that significantly improves the speed of lisp
code is the use of declarations. In general, a function call in
lisp has to have a case statement of the possible types of each
argument and needs to handle the possible types. However, if you
tell the compiler what the argument types are and the return types
are you can get significantly faster code. The best way to illustrate
this is to use the DISASSEMBLE function which will show you the code
that gets laid down by the lisp compiler. CMUCL and SBCL are very
good at optimizing code. GCL also does an excellent job. That's what
the .fn files are for in Axiom.
So, if you have a function + and you say:
(+ a b)
the compiler cannot assume that a or b are anything so it has to
check for arguments such as lists.
You can improve the calling code by using THE... as in
(+ (the integer a) (the integer b))
Lisp can optimize a bit further if you know that the arguments will
always be less than a machine-sized integer, called a FIXNUM. Then
you can say:
(+ (the fixnum a) (the fixnum b))
However you haven't told the compiler that the result will not
exceed a machine fixnum. You can do this with:
(the fixnum (+ (the fixnum a) (the fixnum b)))
And now the compiler can improve the function call, potentially
even inlining the + operation and reducing it to a single machine
add instruction. It can assume that the add will get two machine
sized integers and return a machine-sized result without overflow.
Type declarations can cause a huge speed improvement. CMUCL and
SBCL have amazing optimizing compilers that use type information well.
GCL can automatically generate the type information for all of
the functions in a file. If you first load the GCL file, gcl_collectfn.lsp
and then tell the compiler to emit the type definitions you'll get a .fn
file. So the sequence for optimizing is:
(load "gcl_collectfn.lsp")
(compiler::emit-fn t)
(compile-file "yourfile.lisp")
(load "yourfile.fn")
(compile-file "yourfile.lisp")
The first compile-file will generate the .fn, which contains the type
info (and you can hand-augment this if you like), and the second compile-file
will generate much faster code. Once you know this type information you can
hand code it in your original source file and eliminate the collectfn step.
You can do global declarations using PROCLAIM and DECLARE.
See http://www.lrdr.epita.fr/dload/papers/verna.06.imecs.pdf
"How to make Lisp go faster than C"
\start
Date: Tue, 20 Feb 2007 04:51:21 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: lisp speedups
> Another technique that significantly improves the speed of lisp
> code is the use of declarations. In general, a function call in
> lisp has to have a case statement of the possible types of each
> argument and needs to handle the possible types. However, if you
> tell the compiler what the argument types are and the return types
> are you can get significantly faster code. The best way to illustrate
> this is to use the DISASSEMBLE function which will show you the code
> that gets laid down by the lisp compiler. CMUCL and SBCL are very
> good at optimizing code. GCL also does an excellent job. That's what
> the .fn files are for in Axiom.
>
The program I posted uses declarations. AFAICS sbcl has enough
information about types, from the declarations I gave it can infer
the rest (in my experiance gcl needs much more declarations).
When I wrote that the code could be faster I examined also output
of dissasemble. The following snippet:
normal-start
(incf pos)
(incf line-number)
(if (>= pos end-buff)
(return-from scan-for-chunks))
(setf code (aref buff pos))
(if (eql code start-tag-code-1)
(go chunk-start-tag-1))
(if (eql code newline-code)
(go normal-start))
(go normal)
corresponds to the following assembly code:
; 2AF4: L1: 488B4DD0 MOV RCX, [RBP-48]
; 2AF8: 4883C108 ADD RCX, 8
; 2AFC: 48894DD0 MOV [RBP-48], RCX
; 2B00: 488B55D0 MOV RDX, [RBP-48]
; 2B04: 488B45C8 MOV RAX, [RBP-56]
; 2B08: 488B48F9 MOV RCX, [RAX-7]
; 2B0C: 488B45C8 MOV RAX, [RBP-56]
; 2B10: 4839D1 CMP RCX, RDX
; 2B13: 0F86ED0B0000 JBE L48
; 2B19: 48C1FA03 SAR RDX, 3
; 2B1D: 488B45C8 MOV RAX, [RBP-56]
; 2B21: 480FB64C1001 MOVZX RCX, BYTE PTR [RAX+RDX+1]
; 2B27: 48C1E103 SHL RCX, 3
; 2B2B: 4883F950 CMP RCX, 80
; 2B2F: 0F840F090000 JEQ L34
; 2B35: EBBD JMP L1
Why this code is far from optimal? First, sbcl failed to allocate
variables to registers. FYI I use AMD64 machine and sbcl in principle
can use 14 general purpose registers (there is 16 registers, but two,
stack pointer RSP and base pointer RBP are used bu sbcl). The
'scan-for-chunks' function has 11 variables, so it does not look very
hard to allocate _all_ variables into registers. But apparently sbcl
not only failed to keep variables in registers, it also reloads value
which is still available in register. Second, there are useless shifts
-- variable code is always used in comparison with (constant) integers
and pos is mostly used in integer operations (it is also stored in
lists).
As a compiler writer I can understand why sbcl is unable to produce
better code. But I would not call it excellent.
\start
Date: Tue, 20 Feb 2007 05:40:43 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: status of windows version
> On Tue, 20 Feb 2007, Waldek Hebisch wrote:
>
> | Well, I actually intended to bulk-merge changes to build-improvements
> | but some changes (like removal of DESTDIR) look backwards, some other
>
> It is a mistake to defined DESTDIR in a Makefile. The solution
> I implemented in the build-improvements was a mild fix. The real
> fix is to remove the definition. Which is what happened.
>
OK, my mistake -- after quick scanning I thought that you removed
DESTDIR support. Now I see that you implemented correct handling.
\start
Date: Tue, 20 Feb 2007 17:48:27 +0100
From: Gregory Vanuxem
To: list
Subject: Current directory at startup
Hello,
I have just built wh-sandbox and found a _serious_ bug. It's present in
Build-improvement too (and probably Gold). Last time, I uploaded a
binary version of Axiom I made an error, I added the function 'reroot'
just before the uploading and this function is wrong, at least in the
version on which I'm working. The problem is that at startup the
"current directory" is incorrectly set and if you compile a file it will
compile the one in your home directory instead of the one in the current
directory (if the "basenames" are identical). This issue can mess up the
build process (it happened with build-improvement (version 395)).
There is another problem with file (fixed in wh-sandbox): probe-file no
longer works on directory. Tim I think you should take care of these
issues if you plan to release a new version of Gold, several persons
already reported problems related to this one (with fixes too I
believe).
Greg
PS: See reroot (bookvol5), make-input-filename (nlib.lisp) etc...
\start
Date: Tue, 20 Feb 2007 18:04:29 +0100
From: Gregory Vanuxem
To: list
Subject: Re: Current directory at startup
Some (?) other issues:
(1) -> )cd temp
The current AXIOM default directory
is /home/greg/wh-axiom/axiom/target/x86_64-unknown-linux/
(1) -> )cd
The current AXIOM default directory is /home/greg/
(1) -> )cd temp
>> System error:
#p"/home/greg/" is not of type SEQUENCE.
the /home/greg/temp directory exists.
Greg
PS : Bill, in the bug report that you sent me, you mention two bugs but
I think there was only one bug, )cd without parameter changes the
working directory to $HOME ($HOMEPATH on Windows I think) :
(1) -> )sys cd
C:\Documents and Settings\Administrator.ASUS\My Documents
---> The current system path is correct.
(1) -> )cd
The current AXIOM default directory is
C:\Documents and Settings\Administrator.ASUS\
---> This current directory is wrong. So this file is not found.
Le mardi 20 f=E9vrier 2007 =E0 17:48 +0100, Gregory Vanuxem a =E9crit :
> Hello,
>
> I have just built wh-sandbox and found a _serious_ bug. It's present in
> Build-improvement too (and probably Gold). Last time, I uploaded a
> binary version of Axiom I made an error, I added the function 'reroot'
> just before the uploading and this function is wrong, at least in the
> version on which I'm working. The problem is that at startup the
> "current directory" is incorrectly set and if you compile a file it wil=
l
> compile the one in your home directory instead of the one in the curren=
t
> directory (if the "basenames" are identical). This issue can mess up th=
e
> build process (it happened with build-improvement (version 395)).
>
> There is another problem with file (fixed in wh-sandbox): probe-file no
> longer works on directory. Tim I think you should take care of these
> issues if you plan to release a new version of Gold, several persons
> already reported problems related to this one (with fixes too I
> believe).
>
> Greg
>
> PS: See reroot (bookvol5), make-input-filename (nlib.lisp) etc...
\start
Date: Wed, 21 Feb 2007 10:31:43 -0500
From: Bill Page
To: list
Subject: First about Sage published
Althought this is not directly about Axiom, it might be of interest
to note that Sage does include an interface to Axiom as well as
several other computer algebra systems. I think it is remarkable
that a system that is less than two years old is already the basis
of a new book - even if the author of the book is also the (primary)
author of the system.
http://www.ams.org/bookstore-getitem/item=gsm-79
Modular Forms, a Computational Approach
William Stein
The leading expert in computations with modular forms demystifies
this process with practical algorithms . free software is available
to assist with exercises .
--
Review
This marvellous and highly original book fills a significant gap in
the extensive literature on classical modular forms. This is not
just yet another introductory text to this theory, though it could
certainly be used as such in conjunction with more traditional
treatments. Its novelty lies in its computational emphasis
throughout: Stein not only defines what modular forms are, but shows
in illuminating detail how one can compute everything about them in
practice. This is illustrated throughout the book with examples from
his own (entirely free) software package SAGE, which really bring the
subject to life while not detracting in any way from its theoretical
beauty. The author is the leading expert in computations with modular
forms, and what he says on this subject is all tried and tested and
based on his extensive experience. As well as being an invaluable
companion to those learning the theory in a more traditional way,
this book will be a great help to those who wish to use modular forms
in applications, such as in the explicit solution of Diophantine
equations. There is also a useful Appendix by Gunnells on extensions
to more general modular forms, which has enough in it to inspire many
PhD theses for years to come. While the book's main readership will
be graduate students in number theory, it will also be accessible to
advanced undergraduates and useful to both specialists and non-
specialists in number theory.
--John E. Cremona, University of Nottingham
William Stein is an associate professor of mathematics at the
University of Washington at Seattle. He earned a PhD in mathematics
from UC Berkeley and has held positions at Harvard University and
UC San Diego. His current research interests lie in modular forms,
elliptic curves, and computational mathematics.
--
Oh, for the "glory days" of Axiom when Axiom might have been the
tool of choice for this type of work!
\start
Date: Wed, 21 Feb 2007 13:47:26 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis
On February 19, 2007 11:33 AM C Y wrote:
>
> --- Bill Page wrote:
>
> > > I guess wh-sandbox does not run under windows? (Bill said,
> > > build-improvements does...)
> >
> > Yes, I have successfully built build-improvments on Windows.
>
> Bill, is that result something we could wrap up in the NSIS installer
> and push out as a release?
>
I think that's a great idea - especially if we also merge the bug
fixes from wh-sandbox.
If you would like to do this, please let me know. I would be glad
to help. Compiling the windows version is described on the Axiom
Wiki. Using NSIS to package the result is very easy.
\start
Date: 21 Feb 2007 20:08:27 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis
Bill Page writes:
> On February 19, 2007 11:33 AM C Y wrote:
> > Bill, is that result something we could wrap up in the NSIS installer and
> > push out as a release?
> >
>
> I think that's a great idea - especially if we also merge the bug fixes from
> wh-sandbox.
It would be great if you could package my guessing package, too. It is quite
annoying needing access to somebody's computer just to have it installed. (I
succeeded, though)
Another thing: is Aldor working with wh-sandbox / build improvements?
It is quite possible that I will have a chance to present Ralf's and my work at
the "Seminaire Lotharingien" end of march. Would be nice to have cd's as
giveaways...
\start
Date: Wed, 21 Feb 2007 15:00:27 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis
On February 21, 2007 2:08 PM Martin Rubey wrote:
>
> Bill Page writes:
>
> > On February 19, 2007 11:33 AM C Y wrote:
>
> > > Bill, is that result something we could wrap up in the
> > > NSIS installer and push out as a release?
> > >
> >
> > I think that's a great idea - especially if we also merge
> > the bug fixes from wh-sandbox.
>
> It would be great if you could package my guessing package,
> too.
As you know, Waldek has added your integer sequence guessing
package to wh-sandbox, however wh-sandbox has not yet been
shown to build on Windows. I doubt that wh-sandbox will build
on Windows at this time since it was branched from an earlier
version of build-improvements before the Windows build was
possible. There are changes needed specifically to avoid trying
to build the components dependent on X-windows.
On the other hand wh-sandbox now uses a much better algebra
bootstrap method which makes it simpler to add new algebra which
build-improvements doesn't have yet. This might complicate things
until/when Gaby and Waldek manage to merge these two developments.
I recall the problems you had trying to add GUESS to the Axiom
Gold distribution.
> It is quite annoying needing access to somebody's computer
> just to have it installed. (I succeeded, though)
Were you able to install GUESS on the Windows version of Axiom?
>
> Another thing: is Aldor working with wh-sandbox / build-
> improvements?
Aldor, oh Aldor, will you ever be free?
Aldor does work with build-improvemnts. (That is what we are
currently using on the Axiom Wiki server.) I am not sure about
wh-sandbox (because of the change in bootstrap method) but I
believe that it should be quite easy to install Aldor on that
version too since basically, Aldor support is just added on
top.
>
> It is quite possible that I will have a chance to present
> Ralf's and my work at the "Seminaire Lotharingien" end of
> march. Would be nice to have cd's as giveaways...
>
Do you mean something like the Doyen LiveCD? Perhaps we need
to encourage Alfredo to produce a new version...
\start
Date: 21 Feb 2007 22:42:08 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: status of windows version
Cc: Gabriel Dos Reis, Waldek Hebisch
Bill Page writes:
> > It would be great if you could package my guessing package, too.
>
> As you know, Waldek has added your integer sequence guessing package to
> wh-sandbox, however wh-sandbox has not yet been shown to build on Windows. I
> doubt that wh-sandbox will build on Windows at this time since it was
> branched from an earlier version of build-improvements before the Windows
> build was possible. There are changes needed specifically to avoid trying to
> build the components dependent on X-windows.
Yes. In fact, that's the greatest pain of all: no HyperDoc on Windows.
> > It is quite annoying needing access to somebody's computer just to have it
> > installed. (I succeeded, though)
>
> Were you able to install GUESS on the Windows version of Axiom?
Yes, it's trivial - apart from the fact that it takes roughly half an hour to
compile. But I cannot expect anybody to start with axiom by learning how to
compile a package. Well, I could really provide an input file "compile.input"
and another one "load.input". Still, I'd like it better if it was included.
> > Another thing: is Aldor working with wh-sandbox / build- improvements?
> Aldor does work with build-improvemnts. (That is what we are currently using
> on the Axiom Wiki server.) I am not sure about wh-sandbox (because of the
> change in bootstrap method) but I believe that it should be quite easy to
> install Aldor on that version too since basically, Aldor support is just
> added on top.
Great!
> > It is quite possible that I will have a chance to present Ralf's and my
> > work at the "Seminaire Lotharingien" end of march. Would be nice to have
> > cd's as giveaways...
>
> Do you mean something like the Doyen LiveCD? Perhaps we need to encourage
> Alfredo to produce a new version...
Yes. But, as you remarked above, no Guessing package with Gold. And no
Aldor. I'd need both, plus ALLPROSE, plus aldor-combinat.
\start
Date: 21 Feb 2007 22:48:42 +0100
From: Martin Rubey
To: list
Subject: Bug with paths in wh-sandbox
Cc: Waldek Hebisch
I made wh-sandbox available on my linux box for other members of the
departement by setting the file permissions of
~/axiom
(the install directory) appropriately. However, it seems that axiom wants the
build directory to be availble. I received the following notice:
Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
(1) ->
(1) -> f(0)==0
Type: Void
(2) -> f(1)==1
Type: Void
(3) -> f(n)==f(n-1)+f(n-2)
Type: Void
(4) -> f(7)
Compiling function f with type Integer -> NonNegativeInteger
Compiling function f as a recurrence relation.
cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
Apart from these minor glitches, wh-sandbox is working very well, it seems!
Thank you,
\start
Date: Wed, 21 Feb 2007 20:25:17 -0500
From: Alfredo Portes
To: Bill Page
Subject: Re: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis
> Do you mean something like the Doyen LiveCD? Perhaps we need
> to encourage Alfredo to produce a new version...
No encouragement needed just more time :-).
Please let me know what Axiom "version" should I use or if I should
wait for a possible new Silver (build-improvements + wh-sandbox).
One possibility for those that need hyperdoc on Windows is using
vmware + Doyen.
Sorry Martin about not having the CD ready for your presentation last
time. By the way, I don't know if it was ever addressed the problem with Gold
patch 50 that would break HyperDoc when adding Martin's package.
\start
Date: 21 Feb 2007 23:15:02 -0600
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Bug with paths in wh-sandbox
Cc: Waldek Hebisch
Martin Rubey writes:
| I made wh-sandbox available on my linux box for other members of the
| departement by setting the file permissions of
|
| ~/axiom
|
| (the install directory) appropriately. However, it seems that axiom wants the
| build directory to be availble. I received the following notice:
The current handling of paths in Axiom (Gold) and its branches
are just dead plain wrong. some of the issues were corrected in
build-improvements (therefore wh-sandbox), but most of them remain.
I consider that your report and that of Gregory are related and fall
in the same basket.
\start
Date: 22 Feb 2007 11:09:02 +0100
From: Martin Rubey
To: list
Subject: unit testing
Dear all,
I'm discussing with Christian Aistleitner unit testing in Axiom, and I
wondered, how the regression tests are currently run. I only found the .input
files, but cannot find any files containing the corresponding "should be"
output.
Furthermore, how is "should be" and "is" currently compared?
\start
Date: Thu, 22 Feb 2007 05:11:27 -0500
From: Bill Page
To: Alfredo Portes
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis
Hi Alfredo,
On February 21, 2007 8:25 PM you wrote:
> Bill Page wrote:
> > Do you mean something like the Doyen LiveCD? Perhaps we need
> > to encourage Alfredo to produce a new version...
>
> No encouragement needed just more time :-).
>
Oh, I know that problem!
> Please let me know what Axiom "version" should I use or if
> I should wait for a possible new Silver (build-improvements +
> wh-sandbox).
>
Well, my personal opinion is that it is no good to wait. We
should use the best of what we have right now. What that might
be 6 months from now, it is hard to tell. Open source projects
like Axiom really do not have schedules and resources like in
the commercial world; it all depends on personal initiative and
how much people are willing and able to give to others.
For a new Linux distribution of Axiom I favour wh-sandbox. It has
the greatest and most significant number of fixes and improvements
as far as the end user is concerned. Waldek has done a great job
of repairing and even completing parts of Hyperdoc that never were
resolved in the "commerical" version. I have never liked hyperdoc
much because I found it so unstable and the gui rather dry and ugly,
but the new wh-sandbox version is changing my mind a little - because
it actally works. Waldek has also corrected a number of significant
bugs in the algebra and added Martin's GUESS package.
For a new Windows distribution of Axiom hyperdoc is not an issue
since there is no available hyperdoc version for Windows, but the
build procedure that does not assume X-windows is important, so our
best choice right now is build-improvements.
Merging the downstream algebra bug fixes from wh-sandbox back into
build-improvements is only a matter of using svn to pick and apply
the appropriate revisions from the repository. If I some how find
a few minutes of the next week, perhaps I can do that. Merging the
GUESS build changes might be a bit more challenging.
Even if no one gets a chance to do any merging, building a new
Windows version from build-improvements is still worth it because
build-improvements is based on Axiom Gold (patch-50) while the
current windows build is two years old and based on about patch-30
or something like that and an older version of GCL.
> ...
\start
Date: Thu, 22 Feb 2007 12:21:40 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: unit testing
> Dear all,
>
> I'm discussing with Christian Aistleitner unit testing in Axiom, and I
> wondered, how the regression tests are currently run. I only found the .input
> files, but cannot find any files containing the corresponding "should be"
> output.
>
> Furthermore, how is "should be" and "is" currently compared?
>
The procedure I use for wh-sandbox is as follows. First, when a change
is developed I use ad hoc methods to verify that the change is having
intended effect typically going trough many iterations. When I am
satisfied with change I do a full build and compare test output and
generated .pht pages. For recent changes to algebra bootstrap and to
interpreter (switch from boot to Shoe) I also compared generated Lisp.
I do not consider any version as "should be" -- I simply monitor changes.
I compare with previous versions, typically with the preceeding one,
but sometimes also with older versions.
I compare .pht pages just using diff. For .output files I use a script
that I recently posted. For lisp files I have a special Lisp comparator
program (also recently posted).
I tried to use random expressions for testing but there are few problems
- my first attempt generated a lot of invalid expressions (like divisions
by zero or type errors)
- the expressions have bad distribution, many are quite trivial but
the other quickly get too complicated for Axiom to handle
- test runs tend to get trapped in infinite or semi-infinite computations
or run out of memory (timeouts could help, but some examples _do_ get
correct answer only after hours of computations)
- big problem is how to find correct answer to compare with test result.
For indefinite integrals we can just integrate derivatives. For
definite integrals (and possibly some other expressions) we may
compare numerical evaluation of symbolic result with result of
numerical integration. Another possibility is are multi-CAS
competitions: compare outputs of different systems.
--
Waldek Hebisch
Waldek Hebisch
\start
Date: 22 Feb 2007 13:09:00 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: unit testing
Waldek Hebisch writes:
> > Dear all,
> >
> > I'm discussing with Christian Aistleitner unit testing in Axiom, and I
> > wondered, how the regression tests are currently run. I only found the .input
> > files, but cannot find any files containing the corresponding "should be"
> > output.
> >
> > Furthermore, how is "should be" and "is" currently compared?
> >
>
> The procedure I use for wh-sandbox is as follows. First, when a change
> is developed I use ad hoc methods to verify that the change is having
> intended effect typically going trough many iterations. When I am
> satisfied with change I do a full build and compare test output and
> generated .pht pages. For recent changes to algebra bootstrap and to
> interpreter (switch from boot to Shoe) I also compared generated Lisp.
Oh, I meant, results of computations using axiom...
> - big problem is how to find correct answer to compare with test result. For
> indefinite integrals we can just integrate derivatives. For definite
> integrals (and possibly some other expressions) we may compare numerical
> evaluation of symbolic result with result of numerical integration. Another
> possibility is are multi-CAS competitions: compare outputs of different
> systems.
Yes, that's what I have in mind - although, for the moment, static only. I.e.,
a rather large database of results, which are checked after a change in the
algebra is made
\start
Date: Thu, 22 Feb 2007 17:40:49 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: SBCL and compiler speed
Encouraged by progress made by Greg Vanuxem I decided to retry
my attempt to compile Axiom using sbcl. One of my main motivators
is problem of long compile times. It is hard to resolve such
problems without a profiler. I was unable to profile gcl compiled
programs, while profiling seem to work quite well in sbcl.
FYI I use the following patch to Juergen Weiss version:
http://www.math.uni.wroc.pl/~hebisch/prog/sbcl-cmu2.diff
Currently Debian sbcl 0.9.16 gives up compiling ALGSC (1.0 after
1 hour is still working), however I collected some timing data.
Namely I used sbcl compiled interpsys to do bootstrap part of
algebra build (like new bootstrap in wh-sandbox). The profile
shows interesting things. First, compilation is much faster than
using gcl (about 15 minutes on the same machine) . Most of the
time is spent in Lisp compilation, but we also have a few hot
spots in spad compilation.
Some remarks: This is profile from the third bootstrap stage,
consisting of normal compilation of all categories and about
20 core domains. Profiles form earlier stages are somwhat
different -- the first stage is much faster, and Lisp compilation
takes smaller part. The second stage is similar to the third.
I think that third stage is closer to normal compilation
(however, bootstrap compiles only few domains, while rest of
build handles bulk of domains and packages).
seconds | consed | calls | sec/call | name
---------------------------------------------------------------
56.724 | 3,295,119,728 | 342 | 0.165859 | RECOMPILE-LIB-FILE-IF-NECESSARY
26.956 | 39,137,360 | 437,427 | 0.000062 | |coerce|
18.446 | 1,135,112,672 | 342 | 0.053935 | LOCALDATABASE
15.316 | 382,448 | 398,448 | 0.000038 | |isDomainForm|
14.991 | 546,596,384 | 386,423 | 0.000039 | |comp3|
14.179 | 848,948,032 | 10,826 | 0.001310 | EVAL
6.340 | 82,164,176 | 1,301,192 | 0.000005 | |macroExpand|
5.923 | 355,568,272 | 2,482 | 0.002386 | |spadCompileOrSetq|
5.512 | 188,600,624 | 2,140 | 0.002576 | |compDefineCapsuleFunction|
3.792 | 40,395,328 | 265,305 | 0.000014 | |compAtom|
3.732 | 253,396,128 | 342 | 0.010912 | |compDefineLisplib|
2.740 | 105,498,352 | 2,795 | 0.000980 | COMP370
2.332 | 151,835,232 | 118 | 0.019762 | |mkCategoryPackage|
1.968 | 97,820,208 | 204 | 0.009645 | |compDefineCategory2|
1.814 | 129,140,032 | 19,498 | 0.000093 | |knownInfo|
1.751 | 12,989,472 | 4,432 | 0.000395 | |compColon|
0.992 | 6,727,248 | 204,213 | 0.000005 | |compSymbol|
0.951 | 30,750,720 | 142,563 | 0.000007 | |getFormModemaps|
0.749 | 225,793,568 | 138 | 0.005431 | |compDefineFunctor1|
0.740 | 42,394,672 | 2,482 | 0.000298 | |compile|
0.557 | 58,616,512 | 7 | 0.079579 | |compAdd|
0.484 | 19,390,784 | 138 | 0.003507 | |makeFunctorArgumentParameters|
0.203 | 8,872,672 | 2,502 | 0.000081 | COMP
0.099 | 2,912,032 | 9,164 | 0.000011 | |updateCategoryFrameForCategory|
0.094 | 6,528,944 | 250 | 0.000375 | |updateCategoryFrameForConstructor|
0.067 | 111,328 | 2,140 | 0.000031 | |hasSigInTargetCategory|
0.010 | 1,569,968 | 18,160 | 0.000001 | |compCategoryItem|
0.010 | 130,496 | 342 | 0.000029 | |compileConstructor1|
0.008 | 226,064 | 3,438 | 0.000002 | |compDefineAddSignature|
0.007 | 4,144 | 342 | 0.000020 | |unloadOneConstructor|
0.006 | 0 | 4,137 | 0.000002 | |getAbbreviation|
0.002 | 0 | 2,140 | 0.000001 | |addArgumentConditions|
0.002 | 8,192 | 2,341 | 0.000001 | |getSignatureFromMode|
0.002 | 144,448 | 956 | 0.000002 | |orderByDependency|
0.001 | 0 | 2,281 | 0.000001 | |primitiveType|
0.001 | 0 | 138 | 0.000007 | |addEmptyCapsuleIfNecessary|
0.000 | 8,192 | 138 | 0.000000 | |compDefineFunctor|
0.000 | 138,848 | 3,328 | 0.000000 | |compDefine|
0.000 | 16,384 | 204 | 0.000000 | |compDefineCategory|
0.000 | 18,943,744 | 250,466 | 0.000000 | |comp|
0.000 | 206,764,272 | 386,423 | 0.000000 | |comp2|
0.000 | 446,928 | 346 | 0.000000 | |compWithMappingMode|
0.000 | 75,078,768 | 107,669 | 0.000000 | |compExpression|
0.000 | 11,108,624 | 84,858 | 0.000000 | |compForm|
0.000 | 190,556,032 | 143,419 | 0.000000 | |compForm1|
0.000 | 4,939,808 | 58,857 | 0.000000 | |compArgumentsAndTryAgain|
0.000 | 12,663,168 | 73,948 | 0.000000 | |compForm2|
0.000 | 55,031,440 | 91,510 | 0.000000 | |compForm3|
0.000 | 1,759,856 | 1,796 | 0.000000 | |compIf|
0.000 | 45,840 | 2,046 | 0.000000 | |getSuccessEnvironment|
0.000 | 823,344 | 3,545 | 0.000000 | |compDefine1|
0.000 | 53,600 | 204 | 0.000000 | |compDefineCategory1|
0.000 | 634,384 | 956 | 0.000000 | |compDefWhereClause|
0.000 | 903,936 | 2,887 | 0.000000 | |doIt|
0.000 | 3,801,216 | 31,201 | 0.000000 | |compApplication|
0.000 | 2,805,328 | 4,855 | 0.000000 | |applyMapping|
0.000 | 65,133,568 | 51,649 | 0.000000 | |compApplyModemap|
---------------------------------------------------------------
187.502 | 8,338,543,520 | 4,530,493 | | Total
\start
Date: Thu, 22 Feb 2007 18:39:17 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: SBCL and compiler speed
Waldek,
Le jeudi 22 f=E9vrier 2007 =E0 17:40 +0100, Waldek Hebisch a =E9crit :
> Encouraged by progress made by Greg Vanuxem I decided to retry
> my attempt to compile Axiom using sbcl. One of my main motivators
> is problem of long compile times. It is hard to resolve such
> problems without a profiler. I was unable to profile gcl compiled
> programs, while profiling seem to work quite well in sbcl.
> FYI I use the following patch to Juergen Weiss version:
>
> http://www.math.uni.wroc.pl/~hebisch/prog/sbcl-cmu2.diff
I you want I can upload what I have done (more precisely what is
"distributable"), I planned to upload it Sunday but I'm not against this
idea (I'm busy). The bad news is that the interpreter is not
pamphletised [1], I do not think that the documentation must be done
now, it has to be done when merging and when, I think, we have _fixed_
the API (a lot of functions rely on CltL1 (GCL ?) (symbol used to
extensively for example)). WHat I'm saying does not prevent to document,
"conceptually", some part of the "interpreter" such that the database,
the compiler(s) etc...
Greg
[1] The build process is buggy too, somes versions of Make (the one in
Cygwin for example) does not accept the algebra Makefile and its
inclusions.
\start
Date: Fri, 23 Feb 2007 00:41:08 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: SBCL and compiler speed
> Waldek,
>
> Le jeudi 22 f=E9vrier 2007 ? 17:40 +0100, Waldek Hebisch a =E9crit :
> > Encouraged by progress made by Greg Vanuxem I decided to retry
> > my attempt to compile Axiom using sbcl. One of my main motivators
> > is problem of long compile times. It is hard to resolve such
> > problems without a profiler. I was unable to profile gcl compiled
> > programs, while profiling seem to work quite well in sbcl.
> > FYI I use the following patch to Juergen Weiss version:
> >
> > http://www.math.uni.wroc.pl/~hebisch/prog/sbcl-cmu2.diff
>
> I you want I can upload what I have done (more precisely what is
> "distributable"), I planned to upload it Sunday but I'm not against this
> idea (I'm busy). The bad news is that the interpreter is not
> pamphletised [1], I do not think that the documentation must be done
> now, it has to be done when merging and when, I think, we have _fixed_
> the API (a lot of functions rely on CltL1 (GCL ?) (symbol used to
> extensively for example)). WHat I'm saying does not prevent to document,
> "conceptually", some part of the "interpreter" such that the database,
> the compiler(s) etc...
>
> Greg
>
> [1] The build process is buggy too, somes versions of Make (the one in
> Cygwin for example) does not accept the algebra Makefile and its
> inclusions.
>
It would be nice to see your version. I certainly would like to
know how you solved some specific problems (non-ANSI type declarations,
BPINAME function etc). I would like also to time build process.
\start
Date: Fri, 23 Feb 2007 06:02:35 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Bug with paths in wh-sandbox
> I made wh-sandbox available on my linux box for other members of the
> departement by setting the file permissions of
>
> ~/axiom
>
> (the install directory) appropriately. However, it seems that axiom wants the
> build directory to be availble. I received the following notice:
>
<snip>
> cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
>
>
Currently wh-sandbox (and I belive also build-improvements) does not install
gcl files (in this case cmpinclude.h) in target directory. The simplest
solution is to use system installed gcl (and make sure that gcl _is_
installed on target machine).
Gaby is right that we have mess with paths, but even with correct paths
we still would have problem: we simply do not install the needed include
file.
\start
Date: Fri, 23 Feb 2007 10:14:55 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: Bug with paths in wh-sandbox
On February 23, 2007 12:03 AM Waldek Hebisch wrote:
> ...
> Currently wh-sandbox (and I belive also build-improvements)
> does not install gcl files (in this case cmpinclude.h) in
> target directory.
> The simplest solution is to use system installed gcl (and
> make sure that gcl _is_ installed on target machine).
>
> Gaby is right that we have mess with paths, but even with
> correct paths we still would have problem: we simply do not
> install the needed include file.
>
I think that this file is installed in the target directory
(mnt) in the Axiom Gold release. Right?
\start
Date: Sat, 24 Feb 2007 04:16:09 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox
Gabriel Dos Reis wrote:
> Martin Rubey writes:
>
> | I made wh-sandbox available on my linux box for other members of the
> | departement by setting the file permissions of
> |
> | ~/axiom
> |
> | (the install directory) appropriately. However, it seems that axiom wants the
> | build directory to be availble. I received the following notice:
>
> The current handling of paths in Axiom (Gold) and its branches
> are just dead plain wrong. some of the issues were corrected in
> build-improvements (therefore wh-sandbox), but most of them remain.
> I consider that your report and that of Gregory are related and fall
> in the same basket.
>
After some investigation it turend out that eariler versions do not
need "cmpinclude.h" -- gcl simply puts inline content of this file.
gcl behaviour is controlled by the Lisp compiler::*default-system-p*
variable, which is set to t. As a workaround one can use the following
in the start script:
)lisp (setf compiler::*default-system-p* nil)
AFAICS the problem was interoduced in version 25 (patch 45): this
variable is set to t when using system installed gcl. Typically
this is not a problem, but I belive that if somebody builds gold
using system installed gcl (assuming that this would work ...)
and then puts the content of Axiom directory on a machine whithout
installed gcl, then the same problem would appear.
Now, the question is how to solve the problem. One way is to patch
src/lsp/Makefile.pamphlet so that it does not set
compiler::*default-system-p* to t. Another possibility is to
set compiler::*default-system-p* to nil when dumping final AXIOMsys.
For me the second possibility looks slightly better, as it avoids
putting extra crud into intermediate C files.
>From my point of view nicest solution would be to teach gcl check
if cmpinclude.h is in expected place, if yes use it, otherwise
use cached version.
\start
Date: Sat, 24 Feb 2007 15:46:28 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Sources of the port of Axiom to SBCL/CMUCL/Clisp (was: SBCL and compiler speed)
Le vendredi 23 f=E9vrier 2007 =E0 00:41 +0100, Waldek Hebisch a =E9crit :=
> >
> > I you want I can upload what I have done (more precisely what is
> > "distributable"), I planned to upload it Sunday but I'm not against t=
his
> > idea (I'm busy). The bad news is that the interpreter is not
> > pamphletised [1], I do not think that the documentation must be done
> > now, it has to be done when merging and when, I think, we have _fixed=
_
> > the API (a lot of functions rely on CltL1 (GCL ?) (symbol used to
> > extensively for example)). WHat I'm saying does not prevent to docume=
nt,
> > "conceptually", some part of the "interpreter" such that the database=
,
> > the compiler(s) etc...
> >
> > Greg
> >
> > [1] The build process is buggy too, somes versions of Make (the one i=
n
> > Cygwin for example) does not accept the algebra Makefile and its
> > inclusions.
> >
>
> It would be nice to see your version. I certainly would like to
> know how you solved some specific problems (non-ANSI type declarations,
> BPINAME function etc). I would like also to time build process.
>
Here are the sources:
http://perso.orange.fr/parabola/axiom-cl.tar.gz
It is based on the work of Juergen Weiss available here:
http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz
(So you can easily diff these to know who did what)
For the question of BPINAME, I have the same problem than you.
When I read your code I was particularly interested in your
implementation of this function. This function is
implemented but further investigations are needed.
For example the
((and (consp func) (eq (car func) 'lambda)) (second (third func)))
is probably never used. Furthermore in boot code we can see several
reference to compiled-function-p before using BPINAME, compiled-function-=
p
is really implementation dependant so... I will work on this when time wi=
ll permit.
Anyway there are numerous "TODO" in the code, if some of you want to work=
on
this port feel free to improve it :-) (when there are "QUESTION" in the c=
ode
this is because further investigation are needed and eventually I'll have=
to
ask Juergen Weiss why it's implemented this way).
To compile it 'cd' to src/boot, edit the Makefile.(sbcl|clisp|cmu) and th=
e Makefile.inc
to change the variables defined if necessary (you'll have, for sure, to m=
odify AXIOMROOT).
Export the AXIOM environment variable so for example with SBCL :
export AXIOM=/usr/local/axiom-cl/mnt/sbcl
and use 'make -f Makdefile.sbcl' to build bootsys with SBCL.
Do the same thing for src/interp and src/algebra.
To use Axiom do not forget to export the environment variable AXIOM
(this is necessary for the moment).
The build process has been done in such a way that you can easily build
Axiom for each CL implementation (and test the three at the same time).
And, a last remark (for fun)
<Hans Reiser argument>
Original Axiom:
-------------------------------------------------------------------------=
---
time echo ')r zdsolve' | /usr/local/axiom/mnt/linux/bin/AXIOMsys &>/dev/n=
ull
real 1m24.392s
user 1m21.025s
sys 0m1.010s
-------------------------------------------------------------------------=
---
Axiom on SBCL:
-------------------------------------------------------------------------=
---
time echo ')r zdsolve' | /usr/local/axiom-cl/mnt/sbcl/bin/interpsys &>/de=
v/null
real 0m29.127s
user 0m25.860s
sys 0m0.506s
-------------------------------------------------------------------------=
---
</Hans Reiser argument>
And there are a lot of other types of remark...
Greg
PS: If you have fix, amelioration etc... please let me know.
PS2: For the "warriors" who want to use Aldor edit foam_l.lisp since
it's specialised for me (the |SInt| type). A better way is to use an inte=
ger
range as type instead of a predefined type such that fixnum. The
other problem is that we don't have the sources so we can not know
what exactly a |Sint| is.)
==========================
==========================
==========================
=====
KNOWN PROBLEMS (not related to Axiom):
If you encounter a "NIL is not of type continuation" with CMUCL try to ch=
ange
the safety optimise setting, this is apparently a bug in CMUCL.
Some versions of SBCL (mine for example (x86-64)), apparently, loop indef=
initely
when computing the gcd with MOST-NEGATIVE-FIXNUM as one of its arguments.=
Solution
fix SBCL :-)
(this one is related to the build process of Axiom)
It will be not possible to build the algebra with some version of Make.
This need to be fixed. The typical error message is something like
"can not load BASTYPE", this type is not available since the correspondin=
g
.spad file is not compiled). On MinGW-MSYS I have to create the included =
makefiles
with the "standard" version of make and use the "packaged make" to
build the algebra :-(
\start
Date: Sat, 24 Feb 2007 11:47:57 -0600
From: Tim Daly
To: list
Subject: next release
I'm working on the next release of Axiom Gold.
Work is being done on Axiom in several different locations
and I've made an effort to harvest those changes that I understand
and to merge, test, and document these changes back into the release.
In open source projects it is important that changes get collected
and packaged so they can be merged with the main release. This
is done by releasing diffs and changesets (the whole point of SVN).
Often the original author is the only one who can diff, document,
test and package these changesets.
The mailing list has almost no patches posted.
Why is that?
\start
Date: 24 Feb 2007 19:23:07 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: next release
Tim Daly writes:
> I'm working on the next release of Axiom Gold.
Great! Could you please try to include my guessing package?
> The mailing list has almost no patches posted.
> Why is that?
I sent all patches to issue tracker. Look at "fix proposed", please.
\start
Date: Sun, 25 Feb 2007 03:30:09 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Sources of the port of Axiom to SBCL/CMUCL/Clisp
Gregory Vanuxem wrote:
> Here are the sources:
>
> http://perso.orange.fr/parabola/axiom-cl.tar.gz
>
Thanks, nice job.
> It is based on the work of Juergen Weiss available here:
>
> http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz
>
> (So you can easily diff these to know who did what)
>
> For the question of BPINAME, I have the same problem than you.
> When I read your code I was particularly interested in your
> implementation of this function. This function is
> implemented but further investigations are needed.
>
> For example the
>
> ((and (consp func) (eq (car func) 'lambda)) (second (third func)))
>
> is probably never used. Furthermore in boot code we can see several
> reference to compiled-function-p before using BPINAME, compiled-function-p
> is really implementation dependant so... I will work on this when time will permit.
>
I suspect that the use of compiled-function-p is bogus: Axiom probably
assumes that the function is either given by a lambda list or is
a compiled function. But it looks that such assumption was true in
the past, but now both compiled and interpreted functions are (represented
by) function objects. I think that the case you quote above just
tests for archaic representation of interpreted functions.
I hope that Lisp implementation that is capable of finding name of a function
object will return this name as a third value of function-lambda-expression.
However, I noticed that sbcl returns funny things for functions obtained
from lambda expresions so I added a little samity check. I wonder
how well such implementation works with other Lisps -- in principle
it may be quite portable.
> To compile it 'cd' to src/boot, edit the Makefile.(sbcl|clisp|cmu) and the Makefile.inc
> to change the variables defined if necessary (you'll have, for sure, to modify AXIOMROOT).
> Export the AXIOM environment variable so for example with SBCL :
>
> export AXIOM=/usr/local/axiom-cl/mnt/sbcl
>
> and use 'make -f Makdefile.sbcl' to build bootsys with SBCL.
>
> Do the same thing for src/interp and src/algebra.
>
> To use Axiom do not forget to export the environment variable AXIOM
> (this is necessary for the moment).
>
I had apply the following diff to build with sbcl 0.9.16. The first
hunks just corrects a typo, the second chunk is a quick hack around the
problem that sb-unix::unix-mkdir accepts only base-string, while we have
a string as an argument. I did not try building using sbcl 1.0, but
I did check that in sbcl 1.0 sb-unix::unix-mkdir works just with
strings, so probably 1.0 needs no workaround.
diff -u pp/axiom-cl/src/interp/Makefile.sbcl axiom-cl/src/interp/Makefile.sbcl
--- pp/axiom-cl/src/interp/Makefile.sbcl 2007-02-24 14:01:24.000000000 +0100
+++ axiom-cl/src/interp/Makefile.sbcl 2007-02-25 00:05:33.000000000 +0100
@@ -15,7 +15,7 @@
@ echo copy $@ from $<
@ cp -p $< $@
-${OUT_DEP}/proclaims.${lisp}: ${IN}/sbcl_proclaims.lisp
+${OUT_DEP}/proclaims.${LISP}: ${IN}/sbcl_proclaims.lisp
@ echo making $@ from $<
@ ln -s $< $@
diff -u pp/axiom-cl/src/interp/nlib.lisp axiom-cl/src/interp/nlib.lisp
--- pp/axiom-cl/src/interp/nlib.lisp 2007-02-24 13:52:50.000000000 +0100
+++ axiom-cl/src/interp/nlib.lisp 2007-02-25 00:27:08.000000000 +0100
@@ -248,7 +248,7 @@
#+(and :sbcl :unix)
(defun makedir (fname)
- (sb-unix::unix-mkdir (boot::interp-make-directory fname) #o755))
+ (sb-ext::run-program "/bin/mkdir" (list fname)))
#+:clisp
(defun makedir (fname)
\start
Date: 24 Feb 2007 20:52:14 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release
Tim Daly writes:
| I'm working on the next release of Axiom Gold.
|
| Work is being done on Axiom in several different locations
| and I've made an effort to harvest those changes that I understand
| and to merge, test, and document these changes back into the release.
|
| In open source projects it is important that changes get collected
| and packaged so they can be merged with the main release. This
| is done by releasing diffs and changesets (the whole point of SVN).
| Often the original author is the only one who can diff, document,
| test and package these changesets.
|
| The mailing list has almost no patches posted.
| Why is that?
Well, patches are supposed to be posted when they are ready for
"prime time" use. For "personal" experimentation we don't require
that (should we?).
The axiom-commit mailing list has the history of all commits
to SVN -- when they are not truncated due to SF policy.
\start
Date: Sat, 24 Feb 2007 20:54:45 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox
On Sat, 24 Feb 2007, Waldek Hebisch wrote:
| Gabriel Dos Reis wrote:
| > Martin Rubey writes:
| >
| > | I made wh-sandbox available on my linux box for other members of the
| > | departement by setting the file permissions of
| > |
| > | ~/axiom
| > |
| > | (the install directory) appropriately. However, it seems that axiom wants the
| > | build directory to be availble. I received the following notice:
| >
| > The current handling of paths in Axiom (Gold) and its branches
| > are just dead plain wrong. some of the issues were corrected in
| > build-improvements (therefore wh-sandbox), but most of them remain.
| > I consider that your report and that of Gregory are related and fall
| > in the same basket.
| >
|
| After some investigation it turend out that eariler versions do not
| need "cmpinclude.h" -- gcl simply puts inline content of this file.
| gcl behaviour is controlled by the Lisp compiler::*default-system-p*
| variable, which is set to t. As a workaround one can use the following
| in the start script:
|
| )lisp (setf compiler::*default-system-p* nil)
|
| AFAICS the problem was interoduced in version 25 (patch 45): this
| variable is set to t when using system installed gcl. Typically
| this is not a problem, but I belive that if somebody builds gold
| using system installed gcl (assuming that this would work ...)
| and then puts the content of Axiom directory on a machine whithout
| installed gcl, then the same problem would appear.
|
| Now, the question is how to solve the problem. One way is to patch
| src/lsp/Makefile.pamphlet so that it does not set
| compiler::*default-system-p* to t. Another possibility is to
| set compiler::*default-system-p* to nil when dumping final AXIOMsys.
| For me the second possibility looks slightly better, as it avoids
| putting extra crud into intermediate C files.
|
| From my point of view nicest solution would be to teach gcl check
| if cmpinclude.h is in expected place, if yes use it, otherwise
| use cached version.
You have spent some time investigating this; but, unfortunately I do
not see the direct link to GCL stuff being system-wide or not.
Please could you walk me (slowly) through your invesgitation?
[ I just saw your patch, but I would first like to see why the
patch is correct at the "algorithmic" level. ]
\start
Date: Sun, 25 Feb 2007 04:41:54 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox
Gabriel Dos Reis wrote:
> On Sat, 24 Feb 2007, Waldek Hebisch wrote:
> | After some investigation it turend out that eariler versions do not
> | need "cmpinclude.h" -- gcl simply puts inline content of this file.
> | gcl behaviour is controlled by the Lisp compiler::*default-system-p*
> | variable, which is set to t. As a workaround one can use the following
> | in the start script:
> |
> | )lisp (setf compiler::*default-system-p* nil)
> |
> | AFAICS the problem was interoduced in version 25 (patch 45): this
> | variable is set to t when using system installed gcl. Typically
> | this is not a problem, but I belive that if somebody builds gold
> | using system installed gcl (assuming that this would work ...)
> | and then puts the content of Axiom directory on a machine whithout
> | installed gcl, then the same problem would appear.
> |
> | Now, the question is how to solve the problem. One way is to patch
> | src/lsp/Makefile.pamphlet so that it does not set
> | compiler::*default-system-p* to t. Another possibility is to
> | set compiler::*default-system-p* to nil when dumping final AXIOMsys.
> | For me the second possibility looks slightly better, as it avoids
> | putting extra crud into intermediate C files.
> |
> | From my point of view nicest solution would be to teach gcl check
> | if cmpinclude.h is in expected place, if yes use it, otherwise
> | use cached version.
>
> You have spent some time investigating this; but, unfortunately I do
> not see the direct link to GCL stuff being system-wide or not.
> Please could you walk me (slowly) through your invesgitation?
>
> [ I just saw your patch, but I would first like to see why the
> patch is correct at the "algorithmic" level. ]
>
in the file gcl_cmpmain.lsp we have:
(defun compiler-pass2 (c-pathname h-pathname system-p )
(declare (special *init-name*))
(with-open-file (st c-pathname :direction :output)
(let ((*compiler-output1* (if (eq system-p 'disassemble) *standard-output*
st)))
(declare (special *compiler-output1*))
(with-open-file (*compiler-output2* h-pathname :direction :output)
(cond ((and
(stringp *cmpinclude-string*)
(not system-p)
(si::fwrite *cmpinclude-string* 0
(length *cmpinclude-string*) *compiler-output1*)))
(t (wt-nl1 "#include " *cmpinclude*)))
So, if system-p argument to compiler-pass2 is true, it will try to
use system include file.
now in the same file in compile-file1 we have
(compiler-pass2 c-pathname h-pathname system-p ))
and the beginning of compile-file1 is:
(defun compile-file1 (input-pathname
&key (output-file input-pathname)
(o-file t)
(c-file *default-c-file*)
(h-file *default-h-file*)
(data-file *default-data-file*)
(c-debug nil)
#+aosvs (ob-file nil)
(system-p *default-system-p*)
so during compile system-p is taken from *default-system-p*, unless
a specific values is given as a keyword argument.
\start
Date: Sun, 25 Feb 2007 05:30:15 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: next release
> I'm working on the next release of Axiom Gold.
>
> Work is being done on Axiom in several different locations
> and I've made an effort to harvest those changes that I understand
> and to merge, test, and document these changes back into the release.
>
> In open source projects it is important that changes get collected
> and packaged so they can be merged with the main release. This
> is done by releasing diffs and changesets (the whole point of SVN).
> Often the original author is the only one who can diff, document,
> test and package these changesets.
>
> The mailing list has almost no patches posted.
> Why is that?
>
Each version to wh-sandbox is typically a single changeset (some
large changes which are concepually a single unit are split into
multiple commits). AFAIK you are receiveg the patches via axiom-commit
mailing list. In my experience also web interface at:
http://axiom.svn.sourceforge.net/viewvc/axiom/
works reasonably.
Most patches to wh-sandbox are a very dull reading: they remove
hundreds of lines of machine generated files. The following
patches to wh-sandbox fix user visible problems (many of them
were posted to the axiom-developr mailing list). The number
allow to identify SVN version and get more details.
+++ ChangeLog.wh (wersja 423)
@@ -1,3 +1,10 @@
+2007-01-17 Waldek Hebisch Waldek Hebisch
+
+ Fix bug 101
+ * src/algebra/laplace.spad.pamphlet:
+ LaplaceTransform.lapkernel: handle derivatives
+ LaplaceTransform.locallaplace: supress last rule
+
+++ ChangeLog.wh (wersja 421)
@@ -1,3 +1,12 @@
+2007-01-15 Waldek Hebisch Waldek Hebisch
+ Martin Rubey
+
+ Fix bug 103
+ * src/algebra/polycat.spad.pamphlet:
+ FiniteAbelianMonoidRing.exquo: test for zero divisor
+ PolynomialCategory.primitivePart: special handling for zero
+ argument
+++ ChangeLog.wh (wersja 419)
@@ -1,3 +1,15 @@
+2007-01-06 Waldek Hebisch Waldek Hebisch
+
+ * src/interp/br-data.boot.pamphlet: dbHasExamplePage: Correct
+ path to example pages.
+ * src/hyper/pages/MSET.ht: Replace MultiSet by Multiset.
+ * src/hyper/pages/ug01.ht: Likewise.
+ * src/hyper/pages/xmpexp.ht: Likewise.
+ * src/hyper/pages/man0.ht: Use full path to htsearch
+ * src/hyper/htinp.pamphlet: Use full path to viewAlone.
+ * src/hyper/pages/util.ht: Likewise. Use $AXIOM insead of $SPAD
+ * src/hyper/pages/ht.db: Remove.
+
+++ ChangeLog.wh (wersja 418)
@@ -1,3 +1,9 @@
+2007-01-05 Waldek Hebisch Waldek Hebisch
+
+ * src/algebra/gaussian.spad.pamphlet: Fix complex
+ argument (fixes or works around bugs 15, 47, 184,
+ 293, 314)
+
+++ ChangeLog.wh (wersja 410)
@@ -1,3 +1,7 @@
+2006-12-21 Waldek Hebisch Waldek Hebisch
+
+ * src/algebra/intfact.spad.pamphlet: Fix bug 329.
+
+++ ChangeLog.wh (wersja 397)
@@ -1,3 +1,7 @@
+2006-12-12 Waldek Hebisch Waldek Hebisch
+
+ * src/algebra/manip.spad.pamphlet: Fix bug 278.
+
+++ ChangeLog.wh (wersja 388)
@@ -1,5 +1,9 @@
2006-12-09 Waldek Hebisch Waldek Hebisch
+ * src/algebra/intef.spad.pamphlet: Fix bugs 100 and 308.
+
+++ ChangeLog.wh (wersja 387)
@@ -1,5 +1,9 @@
2006-12-09 Waldek Hebisch Waldek Hebisch
+ * src/algebra/intrf.spad.pamphlet: Partial fix for bug 199.
+
+++ ChangeLog.wh (wersja 386)
@@ -1,3 +1,7 @@
+2006-12-09 Waldek Hebisch Waldek Hebisch
+
+ * src/algebra/sttaylor.spad.pamphlet: Fix bug 312
+
+++ ChangeLog.wh (wersja 343)
@@ -1,5 +1,9 @@
2006-11-30 Waldek Hebisch Waldek Hebisch
+ * src/sman/sman.c.pamphlet: Do not mess with terminal on exit.
+
+++ ChangeLog.wh (wersja 342)
@@ -1,5 +1,13 @@
2006-11-30 Waldek Hebisch Waldek Hebisch
+ * src/include/com.h: Add new command code.
+ * src/interp/sockio.lisp.pamphlet: Likewise.
+ * src/interp/server.boot.pamphlet: serverReadLine: send it.
+ * src/sman/session.c.pamphlet: accept_session_connection:
+ Use new code to detect lost race.
+
+++ ChangeLog.wh (wersja 341)
@@ -1,5 +1,11 @@
2006-11-30 Waldek Hebisch Waldek Hebisch
+ * src/hyper/parse-types.pamphlet: Do not add ".Z" extension.
+ * src/lib/pixmap.c.pamphlet: Atomatically switch between
+ compressed and uncompressed pixmaps.
+
+++ ChangeLog.wh (wersja 339)
@@ -1,3 +1,8 @@
+2006-11-30 Waldek Hebisch Waldek Hebisch
+
+ * src/algebra/newdata.spad.pamphlet:
+ iprint$InternalPrintPackage: remove useless call to FLUSH
+
+++ ChangeLog.wh (wersja 327)
@@ -1,3 +1,8 @@
+2006-11-28 Waldek Hebisch Waldek Hebisch
+
+ * src/graph/view3D/component3d.c.pamphlet: draw3DComponents():
+ reference starting point.
+
+++ ChangeLog.wh (wersja 325)
@@ -1,3 +1,7 @@
+2006-11-26 Waldek Hebisch Waldek Hebisch
+
+ * src/hyper/htinp.pamphlet: strCopy(): call strcpy.
+
+++ ChangeLog.wh (wersja 312)
@@ -1,5 +1,11 @@
2006-11-23 Waldek Hebisch Waldek Hebisch
+ Fix for bug #280.
+ * src/interp/br-search.boot.pamphlet: grepConstruct:
+ Exit early on errors
+
+++ ChangeLog.wh (wersja 310)
@@ -1,5 +1,10 @@
2006-11-23 Waldek Hebisch Waldek Hebisch
+ * src/interp/daase.lisp.pamphlet: getdatabase: when
+ reporting misses print arguments in consistent order
+
+++ ChangeLog.wh (wersja 306)
@@ -1,5 +1,11 @@
2006-11-23 Waldek Hebisch Waldek Hebisch
+ * src/hyper/pages/util.ht: Undo change from 2003:
+ uncomment \spadcmd and \spadsys, remove leadinig
+ parenthesis from \spadsyscom
+
+++ ChangeLog.wh (wersja 284)
@@ -1,5 +1,11 @@
-2006-11-17
+2006-11-17 Waldek Hebisch Waldek Hebisch
+ * src/etc/axiom: Add Axiom binary directory to the PATH
+ * src/hyper/search.pamphlet: use -k sort option, fix
+ presea script
+
+++ ChangeLog.build-improvements (wersja 281)
@@ -1,3 +1,13 @@
+2006-11-15 Waldek Hebisch
+ Bill Page
+
+ * rename mixed case files to avoid svn checkout problems
+ on Windows and Mac, e.g. src/hyper/bitmaps/Alpha.bitmap
+ to alpha-cap.bitmap, etc.
+ * delete duplicate file src/share/doc/hypertex/pages/util.ht
+ and junk from src/doc/ps
+ * Correct noweb syntax in Rosetta.pamphlt
+
+++ ChangeLog.wh (wersja 280)
@@ -1,3 +1,12 @@
+2006-11-17 Waldek Hebisch Waldek Hebisch
+
+ Fixes for Spad filehandling.
+ * src/algebra/files.spad.pamphlet: Remove checks, add close! to
+ Libray exports
+ * src/interp/fname.lisp.pamphlet: Use axiom-probe-file
+ * src/interp/nlib.lisp.pamphlet (probe-name): Likewise.
+ (make-input-filename): Add slash to separate names.
+
+++ ChangeLog.wh (wersja 271)
@@ -1,5 +1,14 @@
2006-11-15 Waldek Hebisch Waldek Hebisch
+ * src/interp/lisplib.boot.pamphlet: readLibPathFast:
+ activate error checking
+ * src/interp/nlib.lisp.pamphlet: fix search for
+ directories
+ * src/etc/Makefile.pamphlet: Install USERS.DAASE and
+ DEPENDENTS.DAASE
+
\start
Date: Sat, 24 Feb 2007 23:22:44 -0600
From: Tim Daly
To: Waldek Hebisch
Subject: next release
I've seen the changes on axiom-commit and some of them have been
merged with in the next release. For instance, I've removed all
of the C prototype code. However, there are changes that are
deeper (e.g. math) which do not have documentation or test cases,
such as changes to the series package. I'm not able to decide if
these changes are correct. I had a conversation with Clifton
Williamson about it but so far the details are still unresolved.
I'm still not clear if the original code, the previous patch, or
the current patch is correct.
I'm also having difficulty deciding what changes should be added
and what changes are part of a larger change (e.g. the asq rewrite).
Is it possible to isolate a closed set of changes that are diff -Naur
changes from Gold?
In general, publishing a changeset to a branch is not the same as
publishing a diff -Naur from Gold. I've been trying to sift thru
the changesets but it takes a great deal of time to decide what
to do in the absence of documentation.
Working without published diff -Naur from Gold I expect that
people will complain that their favorite change will not be
included. I'd prefer to get it right the first time.
\start
Date: 25 Feb 2007 11:25:44 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: next release
Tim Daly writes:
> such as changes to the series package. I'm not able to decide if
> these changes are correct. I had a conversation with Clifton
> Williamson about it but so far the details are still unresolved.
> I'm still not clear if the original code, the previous patch, or
> the current patch is correct.
I'll try to document that patch today or tomorrow. Did you already look at the
others?
http://wiki.axiom-developer.org/IssueTracker?status:list=fix%20proposed
I also posted a documentation patch to ystream.spad.pamphlet some time ago.
Concerning "favorite fix":
* Waldek's patches to hyperdoc
* my patches to hyperdoc (i.e. spadedit.pamphlet) (#5, #144)
* the patch correcting the typo for multiset documentation (#319)
* the patch for the series package (#312)
* the patch to COMBF correcting the binomial inconsitency (a necessity for my
guessingPackage, meanwhile) (#336)
* waldek's patch correcting the problem in normalize.
* #199, but is is hopeless to get documentation there, I think. Waldek is the
only one we could ask...
\start
Date: 25 Feb 2007 13:25:57 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] %S in some contr. pkg fails to compile
Dear Ralf
(I'm the author of mantepse & co)
Ralf Hemmecke writes:
> Hello, why is it that I can compile the Simpson's method's spad file but not
> mantepse.spad? The latter contains %S strings which let the compile command
> choke.
Hm, I don't see any %S strings in any of my source packages?
If you just want to use the package, I'd advise you to check out Waldek
Hebisch's branch, it contains my package and many other improvements.
Otherwise, here are some instructions:
you need to get *all* of
ssolve.spad.pamphlet
rec.spad.pamphlet
fffg.spad.pamphlet
mantepse.spad.pamphlet
Put them into a directory, say "guess" and cd to that directory:
cd guess
you then have to issue
document ssolve.spad.pamphlet
document rec.spad.pamphlet
document fffg.spad.pamphlet
document mantepse.spad.pamphlet
which should produce ssolve.spad, rec.spad, fffg.spad, mantepse.spad and also
documentation in .dvi format.
If any of these files contains "%S", something is wrong...
Now you should start Axiom
axiom
and start compiling *in this order*:
)co fffg.spad
)co ssolve.spad
the following will most likely signal an error like "UFPS not found"...
)co mantepse.spad )co UFPS
thus you have to do it once more:
)co mantepse.spad )co UFPS
)co rec.spad
the following is the easiest way to work around a stupid bug...
)sys rm -rf UFPS.*
this final compilation will take a *very* long time (half an hour or so)
)co mantepse.spad
if any of the above compile commands (except the one indicated) fails, please
send mail again.
I'm very sorry that building is so complicated. I'd be very interested
whether you succeed...
Good Luck,
Martin
PS: this week there will be a yet improved version of my package available.
\start
Date: Sun, 25 Feb 2007 15:46:55 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: Sources of the port of Axiom to SBCL/CMUCL/Clisp
Le dimanche 25 f=E9vrier 2007 =E0 03:30 +0100, Waldek Hebisch a =E9crit :=
[...]
> I suspect that the use of compiled-function-p is bogus: Axiom probably
> assumes that the function is either given by a lambda list or is
> a compiled function. But it looks that such assumption was true in
> the past, but now both compiled and interpreted functions are (represen=
ted
> by) function objects. I think that the case you quote above just
> tests for archaic representation of interpreted functions.
This is what I think too.
>
> I hope that Lisp implementation that is capable of finding name of a fu=
nction
> object will return this name as a third value of function-lambda-expres=
sion.
> However, I noticed that sbcl returns funny things for functions obtaine=
d
> from lambda expresions so I added a little samity check. I wonder
> how well such implementation works with other Lisps -- in principle
> it may be quite portable.
It is definitely a better implementation.
[...]
> I had apply the following diff to build with sbcl 0.9.16. The first
> hunks just corrects a typo, the second chunk is a quick hack around the
> problem that sb-unix::unix-mkdir accepts only base-string, while we hav=
e
> a string as an argument. I did not try building using sbcl 1.0, but
> I did check that in sbcl 1.0 sb-unix::unix-mkdir works just with
> strings, so probably 1.0 needs no workaround.
I'm working with 1.0.2 (in fact pre 1.0.3 since I use a file from CVS (be=
cause of some changes
in the FOP compiler in 1.0.2, in some circumstances, undeclared variables=
are not "accepted",
the "real" compiler treats them as specials)).
I'll keep my implementation since the unix feature and the function unix-=
mkdir is available on
Windows, though I'm hesitant.
\start
Date: Sun, 25 Feb 2007 09:28:12 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox
On Sun, 25 Feb 2007, Waldek Hebisch wrote:
| Gabriel Dos Reis wrote:
| > On Sat, 24 Feb 2007, Waldek Hebisch wrote:
| > | After some investigation it turend out that eariler versions do not
| > | need "cmpinclude.h" -- gcl simply puts inline content of this file.
| > | gcl behaviour is controlled by the Lisp compiler::*default-system-p*
| > | variable, which is set to t. As a workaround one can use the following
| > | in the start script:
| > |
| > | )lisp (setf compiler::*default-system-p* nil)
| > |
| > | AFAICS the problem was interoduced in version 25 (patch 45): this
| > | variable is set to t when using system installed gcl. Typically
| > | this is not a problem, but I belive that if somebody builds gold
| > | using system installed gcl (assuming that this would work ...)
| > | and then puts the content of Axiom directory on a machine whithout
| > | installed gcl, then the same problem would appear.
| > |
| > | Now, the question is how to solve the problem. One way is to patch
| > | src/lsp/Makefile.pamphlet so that it does not set
| > | compiler::*default-system-p* to t. Another possibility is to
| > | set compiler::*default-system-p* to nil when dumping final AXIOMsys.
| > | For me the second possibility looks slightly better, as it avoids
| > | putting extra crud into intermediate C files.
| > |
| > | From my point of view nicest solution would be to teach gcl check
| > | if cmpinclude.h is in expected place, if yes use it, otherwise
| > | use cached version.
| >
| > You have spent some time investigating this; but, unfortunately I do
| > not see the direct link to GCL stuff being system-wide or not.
| > Please could you walk me (slowly) through your invesgitation?
| >
| > [ I just saw your patch, but I would first like to see why the
| > patch is correct at the "algorithmic" level. ]
| >
|
| in the file gcl_cmpmain.lsp we have:
|
| (defun compiler-pass2 (c-pathname h-pathname system-p )
| (declare (special *init-name*))
| (with-open-file (st c-pathname :direction :output)
| (let ((*compiler-output1* (if (eq system-p 'disassemble) *standard-output*
| st)))
| (declare (special *compiler-output1*))
| (with-open-file (*compiler-output2* h-pathname :direction :output)
| (cond ((and
| (stringp *cmpinclude-string*)
| (not system-p)
| (si::fwrite *cmpinclude-string* 0
| (length *cmpinclude-string*) *compiler-output1*)))
| (t (wt-nl1 "#include " *cmpinclude*)))
|
| So, if system-p argument to compiler-pass2 is true, it will try to
| use system include file.
Yes, I understood that part.
The link I'm missing is why Axiom's misbehaviour (reported by both
Gregory and Martin) is traced back to that. Or am I lured by the
title of the thread? (I have been travelling the whole week, so I have
no access to all the discussion, only this one and some other bits).
| now in the same file in compile-file1 we have
|
| (compiler-pass2 c-pathname h-pathname system-p ))
|
| and the beginning of compile-file1 is:
|
| (defun compile-file1 (input-pathname
| &key (output-file input-pathname)
| (o-file t)
| (c-file *default-c-file*)
| (h-file *default-h-file*)
| (data-file *default-data-file*)
| (c-debug nil)
| #+aosvs (ob-file nil)
| (system-p *default-system-p*)
|
| so during compile system-p is taken from *default-system-p*, unless
| a specific values is given as a keyword argument.
\start
Date: Sun, 25 Feb 2007 17:45:21 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox
Gabriel Dos Reis wrote:
> On Sun, 25 Feb 2007, Waldek Hebisch wrote:
>
> | Gabriel Dos Reis wrote:
> | > On Sat, 24 Feb 2007, Waldek Hebisch wrote:
> | > | After some investigation it turend out that eariler versions do not
> | > | need "cmpinclude.h" -- gcl simply puts inline content of this file.
> | > | gcl behaviour is controlled by the Lisp compiler::*default-system-p*
> | > | variable, which is set to t. As a workaround one can use the following
> | > | in the start script:
> | > |
> | > | )lisp (setf compiler::*default-system-p* nil)
> | > |
> | > | AFAICS the problem was interoduced in version 25 (patch 45): this
> | > | variable is set to t when using system installed gcl. Typically
> | > | this is not a problem, but I belive that if somebody builds gold
> | > | using system installed gcl (assuming that this would work ...)
> | > | and then puts the content of Axiom directory on a machine whithout
> | > | installed gcl, then the same problem would appear.
> | > |
> | > | Now, the question is how to solve the problem. One way is to patch
> | > | src/lsp/Makefile.pamphlet so that it does not set
> | > | compiler::*default-system-p* to t. Another possibility is to
> | > | set compiler::*default-system-p* to nil when dumping final AXIOMsys.
> | > | For me the second possibility looks slightly better, as it avoids
> | > | putting extra crud into intermediate C files.
> | > |
> | > | From my point of view nicest solution would be to teach gcl check
> | > | if cmpinclude.h is in expected place, if yes use it, otherwise
> | > | use cached version.
> | >
> | > You have spent some time investigating this; but, unfortunately I do
> | > not see the direct link to GCL stuff being system-wide or not.
> | > Please could you walk me (slowly) through your invesgitation?
> | >
> | > [ I just saw your patch, but I would first like to see why the
> | > patch is correct at the "algorithmic" level. ]
> | >
> |
> | in the file gcl_cmpmain.lsp we have:
> |
> | (defun compiler-pass2 (c-pathname h-pathname system-p )
> | (declare (special *init-name*))
> | (with-open-file (st c-pathname :direction :output)
> | (let ((*compiler-output1* (if (eq system-p 'disassemble) *standard-output*
> | st)))
> | (declare (special *compiler-output1*))
> | (with-open-file (*compiler-output2* h-pathname :direction :output)
> | (cond ((and
> | (stringp *cmpinclude-string*)
> | (not system-p)
> | (si::fwrite *cmpinclude-string* 0
> | (length *cmpinclude-string*) *compiler-output1*)))
> | (t (wt-nl1 "#include " *cmpinclude*)))
> |
> | So, if system-p argument to compiler-pass2 is true, it will try to
> | use system include file.
>
> Yes, I understood that part.
>
> The link I'm missing is why Axiom's misbehaviour (reported by both
> Gregory and Martin) is traced back to that. Or am I lured by the
> title of the thread? (I have been travelling the whole week, so I have
> no access to all the discussion, only this one and some other bits).
>
First, this fixes _part_ of the problem that Martin reported (problem
reported by Gregory are fixed by another patch).
: Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
: (1) ->
: (1) -> f(0)==0
: Type: Void
: (2) -> f(1)==1
: Type: Void
: (3) -> f(n)==f(n-1)+f(n-2)
: Type: Void
: (4) -> f(7)
: Compiling function f with type Integer -> NonNegativeInteger
: Compiling function f as a recurrence relation.
: cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
This errors came for gcc search for include files. The patch I applied
allows Axiom to work when build tree is not present. In other words,
when you make a tarball of installed Axiom and put it on another
machine it will work, unless there is unreadable directory on path
leading to original build tree.
That is, one still gets the error when build tree is unreadable. It is
hard to say who is a guilty party. At least part of blame goes to the
following:
- gcc: it skips nonexistent directories, but raises errors for unreadable
ones
- gcl: it unconditionally adds include directive of form
-I/gcl/system/directory/../h
(where /gcl/system/directory/ is stored in si::*system-directory*
variable)
- Axiom, because it lets si::*system-directory* stay at its default
setting.
One possibility to solve this problem is to point si::*system-directory*
(more precisely the pathname with "../h" appended) to known empty (or non
existent) directory (for example somwhere inside Axiom tree). If we
decide to do that we may even create real h directory and put
cmpinclude.h there. I initially rejected such idea (changing
si::*system-directory*) because I prefer limit our intervention into
gcl internals (note that compiler::*default-system-p* is nil by
default, so my patch merely restored default setting). I was
also not aware that evan after applying the patch the permission
problem is still present: my assumption was that gcl should be
capable of generating working standalone executables which can
compile code on the fly. It is obvious that such executable
needs C compiler in the system, but I consider it a bug that
mere presence of unreadable directory with a magic name can
break such a program.
> | now in the same file in compile-file1 we have
> |
> | (compiler-pass2 c-pathname h-pathname system-p ))
> |
> | and the beginning of compile-file1 is:
> |
> | (defun compile-file1 (input-pathname
> | &key (output-file input-pathname)
> | (o-file t)
> | (c-file *default-c-file*)
> | (h-file *default-h-file*)
> | (data-file *default-data-file*)
> | (c-debug nil)
> | #+aosvs (ob-file nil)
> | (system-p *default-system-p*)
> |
> | so during compile system-p is taken from *default-system-p*, unless
> | a specific values is given as a keyword argument.
>
> -- Gaby
>
\start
Date: Sun, 25 Feb 2007 17:53:12 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: document missing in installation
> Dear Waldek,
>
> it seems that version 434 of wh-sandbox seems to install "document" to
> axiom/target/.../bin
>
> Is this only on my machine?
>
On my machine wh-sandbox does not istall "document". Do you want to
have "document" installed?
> Furthermore, it seems that my packages get recompiled in any case, even if I
> only did a configure to change the prefix.
>
I belive that this is fixed in version 439.
\start
Date: Sun, 25 Feb 2007 18:09:44 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Current directory at startup
Gregory Vanuxem wrote:
> Some (?) other issues:
>
> (1) -> )cd temp
> The current AXIOM default directory
> is /home/greg/wh-axiom/axiom/target/x86_64-unknown-linux/
> (1) -> )cd
> The current AXIOM default directory is /home/greg/
> (1) -> )cd temp
>
> >> System error:
> #p"/home/greg/" is not of type SEQUENCE.
>
> the /home/greg/temp directory exists.
>
> Greg
>
I belive that following patch (applied to wh-sandbox) fixes this problem.
The patch may be somewhat controversial -- I removed code for ancient
systems (because this code is clearly broken by later changes) and
decided to consistently apply convention that directory names have
no extra directory separator at the end. The changes may works or
not on Windows depending how Windows Lisps handle namestrings,
since I can not test what happens on Windows I did not try to add
special code. AFAIK Windows kernel happily works with pathnames
containing slashes and many portable programs internally exclusively
use slashes in pathnames (converting from backslashes on input),
so the code _may_ work.
Anyway, patch follows (note that this patch will probably do
no good without other pathname changes from wh-sandbox):
Index: src/interp/vmlisp.lisp.pamphlet
===================================================================
--- src/interp/vmlisp.lisp.pamphlet (wersja 440)
+++ src/interp/vmlisp.lisp.pamphlet (wersja 441)
@@ -97,13 +97,18 @@
\section{The get-current-directory function}
Contributed by Juergen Weiss.
<<getCD>>=
+(defun trim-directory-name (name)
+ #+:unix
+ (if (char= (char name (1- (length name))) #\/)
+ (setf name (subseq name 0 (1- (length name)))))
+ name)
#+:cmu
(defun get-current-directory ()
(namestring (extensions::default-directory)))
#+(or :akcl :gcl)
(defun get-current-directory ()
- (namestring (truename "")))
+ (trim-directory-name (namestring (truename ""))))
@
\section{License}
@@ -2015,13 +2020,14 @@
(defun MAKE-BVEC (n)
(make-array (list n) :element-type 'bit :initial-element 0))
+<<getCD>>
+
(in-package 'boot)
<<manexp>>
<<acot>>
<<cot>>
<<asec>>
-<<getCD>>
<<Missing DFLOAT Transcendental functions>>
Index: src/interp/bootlex.lisp.pamphlet
===================================================================
--- src/interp/bootlex.lisp.pamphlet (wersja 440)
+++ src/interp/bootlex.lisp.pamphlet (wersja 441)
@@ -184,7 +184,6 @@
(OPTIONLIST nil)
(*EOF* NIL)
(File-Closed NIL)
- ;; ($current-directory "/spad/libraries/")
(/editfile *spad-input-file*)
(|$noSubsumption| |$noSubsumption|)
in-stream out-stream)
Index: src/interp/util.lisp.pamphlet
===================================================================
--- src/interp/util.lisp.pamphlet (wersja 440)
+++ src/interp/util.lisp.pamphlet (wersja 441)
@@ -760,36 +760,6 @@
(mapcar #'load files)))
@
-\subsubsection{interp-make-directory}
-This is used by the ")cd" system command.
-<<interp-make-directory>>=
-(defun interp-make-directory (direc)
- (setq direc (namestring direc))
- (if (string= direc "") $current-directory
- (if (or (memq :unix *features*)
- (memq 'unix *features*))
- (progn
- (if (char/= (char $current-directory (1-(length $current-directory))) #\/)
- (setq $current-directory (concat $current-directory "/")))
- (if (char/= (char direc 0) #\/)
- (setq direc (concat $current-directory direc)))
- (if (char/= (char direc (1- (length direc))) #\/)
- (setq direc (concat direc "/")))
- direc)
- (progn ;; Assume Windows conventions
- (if (not (or (char= (char $current-directory (1- (length $current-directory))) #\/)
- (char= (char $current-directory (1- (length $current-directory))) #\\ )))
- (setq $current-directory (concat $current-directory "\\")))
- (if (not (or (char= (char direc 0) #\/)
- (char= (char direc 0) #\\)
- (find #\: direc)))
- (setq direc (concat $current-directory direc)))
- (if (not (or (char= (char direc (1- (length direc))) #\/)
- (char= (char direc (1- (length direc))) #\\ )))
- (setq direc (concat direc "\\")))
- direc))))
-
-@
\subsubsection{make-directory}
Make a directory relative to the {\bf \$spadroot} variable.
<<make-directory>>=
@@ -1448,12 +1418,11 @@
<<license>>
(in-package "BOOT")
-(export '($spadroot $directory-list $current-directory reroot
+(export '($spadroot $directory-list reroot
make-absolute-filename |$msgDatabaseName| |$defaultMsgDatabaseName|))
<<our-write-date>>
<<make-directory>>
-<<interp-make-directory>>
<<bin-path>>
<<load-directory>>
<<compspadfiles>>
Index: src/interp/patches.lisp.pamphlet
===================================================================
--- src/interp/patches.lisp.pamphlet (wersja 440)
+++ src/interp/patches.lisp.pamphlet (wersja 441)
@@ -114,15 +114,11 @@
))
(defun |cd| (args)
- (cond ((null args)
-#+(and :lucid :ibm/370)
- (setq $current-directory "")
-#-(and :lucid :ibm/370)
- (setq $current-directory (truename (user-homedir-pathname))) )
- ((eql (|directoryp| (interp-make-directory (car args))) 1)
- (setq $current-directory (namestring (truename (interp-make-directory (car args)))))))
-#+(or :kcl :ibcl :CCL) (system:CHDIR $current-directory)
- (|sayKeyedMsg| 'S2IZ0070 (list (namestring $current-directory))))
+ (let ((dname (if (null args)
+ (trim-directory-name (namestring (user-homedir-pathname)))
+ (car args))))
+ #+(or :kcl :ibcl :CCL) (system:CHDIR dname))
+ (|sayKeyedMsg| 'S2IZ0070 (list (get-current-directory))))
<<toplevel>>
(define-function 'top-level #'toplevel)
@@ -285,10 +281,6 @@
(setq |$consistencyCheck| ()) ;; prevents wasting time checking consistency
-#+(or :CCL (and :lucid :ibm/370))
-(setq vmlisp::$current-directory (truename "."))
-#-(or :CCL (and :lucid :ibm/370))
-(setq vmlisp::$current-directory (make-directory *default-pathname-defaults*))
(defvar *msghash* nil "hash table keyed by msg number")
@@ -328,8 +320,6 @@
(|initializeTimedNames| |$interpreterTimedNames| |$interpreterTimedClasses|)
#+:dos
-(setq vmlisp::$current-directory (truename "."))
-#+:dos
(setq vmlisp::$spadroot "/spad/mnt/dos")
#+:dos
(defun user-homedir-pathname ()
Index: src/interp/nlib.lisp.pamphlet
===================================================================
--- src/interp/nlib.lisp.pamphlet (wersja 440)
+++ src/interp/nlib.lisp.pamphlet (wersja 441)
@@ -435,7 +435,7 @@
(defun make-full-namestring (filearg &optional (filetype nil))
(namestring (merge-pathnames (make-filename filearg filetype))))
-(defun get-directory-list (ft &aux (cd (namestring $current-directory)))
+(defun get-directory-list (ft &aux (cd (get-current-directory)))
(cond ((member ft '("NRLIB" "DAASE" "EXPOSED") :test #'string=)
(if (eq BOOT::|$UserLevel| 'BOOT::|development|)
(cons cd $library-directory-list)
Index: src/interp/bookvol5.pamphlet
===================================================================
--- src/interp/bookvol5.pamphlet (wersja 440)
+++ src/interp/bookvol5.pamphlet (wersja 441)
@@ -177,8 +177,6 @@
coerceFailure & & runspad \\
curinstream & ncIntLoop & \\
curoutstream & ncIntLoop & \\
-vmlisp::\$current-directory & restart & \\
- & reroot & \\
\$currentLine & restart & removeUndoLines \\
\$dalymode & & intloopReadConsole \\
\$defaultMsgDatabaseName & reroot & \\
@@ -275,28 +273,6 @@
[[*standard-output*]] common lisp variable in [[ncIntLoop]].
While not using the ``dollar'' convention this variable is still ``global''.
-\subsection{vmlisp::\$current-directory}
-When running in Lucid Common Lisp ([[:lucid]]) on an IBM/370 mainframe
-([[:ibm/370]]) this variable is used in place of the
-[[*default-pathname-defaults*]] common lisp variable.
-Otherwise this variable is
-set to the empty string in [[restart]].
-
-Notice that the variable [[*default-pathname-defaults*]] is a Common
-Lisp standard variable with implementation defined meaning.
-Typically, its value is an object that represents the directory from
-where the Lisp image has been started.
-
-The [[reroot]] function sets this variable to the value of
-[[$spadroot]] which itself has the value of the argument to the
-[[reroot]] function. Since the argument to the [[reroot]] function is
-an string which represents an absolute pathname pointing to AXIOM the
-net result is that the [[$current-directory]] is set to point to the
-shell [[AXIOM]] variable.
-
-So during execute both [[$current-directory]] and [[$spadroot]] reflect
-the value of the [[AXIOM]] shell variable.
-
\subsection{\$currentLine}
The [[$currentLine]] line is set to [[NIL]] in [[restart]].
It is used in [[removeUndoLines]] in the undo mechanism.
@@ -708,11 +684,6 @@
(setq |$IOindex| 1)
(setq |$InteractiveFrame| (|makeInitialModemapFrame|))
(setq |$printLoadMsgs| t)
-#+(and :lucid :ibm/370)
- (setq vmlisp::$current-directory "")
-#-(and :lucid :ibm/370)
- (setq vmlisp::$current-directory
- (make-directory *default-pathname-defaults*))
(|loadExposureGroupData|)
(|statisticsInitialization|)
(|initHist|)
@@ -1144,8 +1115,7 @@
(mapcar #'make-absolute-filename $relative-library-directory-list))
(setq |$defaultMsgDatabaseName|
(pathname (make-absolute-filename "/share/msgs/s2-us.msgs")))
- (setq |$msgDatabaseName| ())
- (setq $current-directory $spadroot))
+ (setq |$msgDatabaseName| ()))
@
\subsection{defun statisticsInitialization}
Index: src/interp/sys-pkg.lisp.pamphlet
===================================================================
--- src/interp/sys-pkg.lisp.pamphlet (wersja 440)
+++ src/interp/sys-pkg.lisp.pamphlet (wersja 441)
@@ -427,7 +427,7 @@
VMLISP::APPLX VMLISP::LASTNODE VMLISP::SUBSTQ VMLISP::TRUEFN
VMLISP::|last| VMLISP::RPLACSTR VMLISP::SETQP VMLISP::QCADDR
VMLISP::QCAADAR VMLISP::QCDDAAR VMLISP::|intersection|
- VMLISP::HASHTABLE-CLASS VMLISP::$CURRENT-DIRECTORY
+ VMLISP::HASHTABLE-CLASS
VMLISP::*COMP370-APPLY* VMLISP::QSETVELT VMLISP::MOVEVEC
VMLISP::ID VMLISP::DEFINE-FUNCTION VMLISP::MSUBSTQ VMLISP::|nsubst|
VMLISP::LISTOFFLUIDS VMLISP::SUB1 VMLISP::NUMBEROFARGS
@@ -449,7 +449,8 @@
VMLISP::INTERSECTIONQ VMLISP::DSETQ VMLISP::FETCHCHAR
VMLISP::STRCONC VMLISP::MACRO-MISSINGARGS VMLISP::RPACKFILE
VMLISP::EXIT VMLISP::PLUS VMLISP::RKEYIDS
- VMLISP::COMPILE-LIB-FILE VMLISP::RECOMPILE-LIB-FILE-IF-NECESSARY))
+ VMLISP::COMPILE-LIB-FILE VMLISP::RECOMPILE-LIB-FILE-IF-NECESSARY
+ VMLISP::GET-CURRENT-DIRECTORY VMLISP::TRIM-DIRECTORY-NAME))
;;; Definitions for package BOOT of type SHADOW
(lisp:in-package "BOOT")
Index: ChangeLog.wh
===================================================================
--- ChangeLog.wh (wersja 440)
+++ ChangeLog.wh (wersja 441)
@@ -1,3 +1,22 @@
+2007-02-25 Waldek Hebisch Waldek Hebisch
+
+ Fix current directory handling. Remove $current-directory
+ variable and all referenctes to it.
+ * src/interp/vmlisp.lisp.pamphlet: trim-directory-name: new
+ function.
+ <getCD>: move to VMLISP package
+ * src/interp/sys-pkg.lisp.pamphlet: export get-current-directory
+ and trim-directory-name.
+ * src/interp/patches.lisp.pamphlet: |cd|: just change directory
+ (do not mess with $current-directory).
+ do not set $current-directory.
+ * src/interp/bookvol5.pamphlet: do not set $current-directory.
+ * src/interp/nlib.lisp.pamphlet: get-directory-list: use
+ get-current-directory.
+ * src/interp/util.lisp.pamphlet: interp-make-directory: remove.
+ * src/interp/bootlex.lisp.pamphlet: remove comment referencing
+ $current-directory.
+
2007-02-24 Waldek Hebisch Waldek Hebisch
Make the final image independent of cmpinclude.h
\start
Date: 25 Feb 2007 18:37:40 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox
Cc: Gabriel Dos Reis
Dear all,
Waldek Hebisch writes:
> my assumption was that gcl should be capable of generating working standalone
> executables which can compile code on the fly. It is obvious that such
> executable needs C compiler in the system, but I consider it a bug that mere
> presence of unreadable directory with a magic name can break such a program.
I'm not sure if Camm reads axiom-devel, so, did you consider asking him?
\start
Date: 25 Feb 2007 18:39:25 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: document missing in installation
Waldek Hebisch writes:
> On my machine wh-sandbox does not istall "document". Do you want to have
> "document" installed?
Yes, definitively. Otherwise, contributed packages cannot be compiled.
\start
Date: Sun, 25 Feb 2007 11:48:28 -0600
From: Tim Daly
To: Gregory Vanuxem, Waldek Hebisch
Subject: compiled-function-p
> I suspect that the use of compiled-function-p is bogus: Axiom probably
> assumes that the function is either a lambda list or is
> a compiled function. But it looks that such assumption was true in
> the past....
Actually, in other lisps that hosted Axiom, such as VMLisp, it was
perfectly possible for the so-called function position of an
expression to contain virtually any expression. VMLisp will do a
complete recursive evaluation of the car of an expression. Common
lisp introduced restrictions on what could appear in the function
position. Since common lisp is our new, favorite lisp we can remove
the test. Portions of the code still contain these historical lisp-isms.
\start
Date: Sun, 25 Feb 2007 11:49:04 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox
On Sun, 25 Feb 2007, Waldek Hebisch wrote:
| > The link I'm missing is why Axiom's misbehaviour (reported by both
| > Gregory and Martin) is traced back to that. Or am I lured by the
| > title of the thread? (I have been travelling the whole week, so I have
| > no access to all the discussion, only this one and some other bits).
| >
|
| First, this fixes _part_ of the problem that Martin reported (problem
| reported by Gregory are fixed by another patch).
Aha, this is what I missed -- I thought the other parts were also solved.
\start
Date: Sun, 25 Feb 2007 12:15:26 -0600
From: Tim Daly
To: Waldek Hebisch
Subject: compiled-function-p
> Anyway, patch follows (note that this patch will probably do
> no good without other pathname changes from wh-sandbox
Here is where my problem arises. When trying to build a system that
many people will use, such as Gold, it is important that I don't
introduce more, or more subtle, errors than I fix. I'm very reluctant
to change what I don't understand since, in the long run I and others
may need to maintain it.
In order to apply your changes I will need to evaluate every other
change you've made to decide if it is related or a prerequisite change.
It can take a day or more to difference your source tree from Gold and
do this evaluation since there is no documentation in the source files
explaining why the change was made. And it is not clear if these changes
depend on other parts of your sandbox, such as Gaby's build system.
This change is a worthwhile idea and should be brought forward to Gold.
It would be most helpful, and Gold would happen a lot faster, if you
could take the time to make a diff-Naur Gold patch containing the
complete changeset.
\start
Date: Sun, 25 Feb 2007 12:55:09 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox
On Sun, 25 Feb 2007, Waldek Hebisch wrote:
[...]
| First, this fixes _part_ of the problem that Martin reported (problem
| reported by Gregory are fixed by another patch).
|
| : Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
| : (1) ->
| : (1) -> f(0)==0
| : Type: Void
| : (2) -> f(1)==1
| : Type: Void
| : (3) -> f(n)==f(n-1)+f(n-2)
| : Type: Void
| : (4) -> f(7)
| : Compiling function f with type Integer -> NonNegativeInteger
| : Compiling function f as a recurrence relation.
| : cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
|
| This errors came for gcc search for include files. The patch I applied
| allows Axiom to work when build tree is not present. In other words,
| when you make a tarball of installed Axiom and put it on another
| machine it will work, unless there is unreadable directory on path
| leading to original build tree.
|
| That is, one still gets the error when build tree is unreadable. It is
| hard to say who is a guilty party. At least part of blame goes to the
| following:
|
| - gcc: it skips nonexistent directories, but raises errors for unreadable
| ones
In this case, it is not clear to me how the resulting C program would
compile if GCL's header is not included. So, it is probably a good
thing that GCC complained. But, I think the root cause is elsewhere.
| - gcl: it unconditionally adds include directive of form
| -I/gcl/system/directory/../h
| (where /gcl/system/directory/ is stored in si::*system-directory*
| variable)
| - Axiom, because it lets si::*system-directory* stay at its default
| setting.
My understanding (Camm, please correct me) is that GCL is not set up
yet to work without its internal header file. However, if that is
true I can't explain why we did not run into that problem before...
\start
Date: Sun, 25 Feb 2007 12:57:51 -0600 (CST)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Bug with paths in wh-sandbox
On Sun, 25 Feb 2007, Martin Rubey wrote:
| Dear all,
|
| Waldek Hebisch writes:
|
| > my assumption was that gcl should be capable of generating working standalone
| > executables which can compile code on the fly. It is obvious that such
| > executable needs C compiler in the system, but I consider it a bug that mere
| > presence of unreadable directory with a magic name can break such a program.
|
| I'm not sure if Camm reads axiom-devel, so, did you consider asking him?
My understanding is that Camm is subscribed to the list. However,
from time to time -- for our own protection against spams -- bona fide
subscribers may be unsubscribed. I believe Camm had suggested to be
explicitly CC:'d in case his input is needed. Furthermore, I think he
also explained that he will not be back before March or something like
that.
\start
Date: 25 Feb 2007 13:36:34 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Lazyness in lexing Boot and Spad
Axiom's implementation of Boot's and Spad source includer
(src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
through function "Delay"). This is also variously known as zipper.
My quesion is how much of the complexity introduced by faking
lazyness actually outweight the benefits? Is the lazyness actually
beneficial?
\start
Date: Sun, 25 Feb 2007 21:14:52 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox
Gabriel Dos Reis wrote:
> On Sun, 25 Feb 2007, Waldek Hebisch wrote:
>
> [...]
>
> | First, this fixes _part_ of the problem that Martin reported (problem
> | reported by Gregory are fixed by another patch).
> |
> | : Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
> | : (1) ->
> | : (1) -> f(0)==0
> | : Type: Void
> | : (2) -> f(1)==1
> | : Type: Void
> | : (3) -> f(n)==f(n-1)+f(n-2)
> | : Type: Void
> | : (4) -> f(7)
> | : Compiling function f with type Integer -> NonNegativeInteger
> | : Compiling function f as a recurrence relation.
> | : cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
> |
> | This errors came for gcc search for include files. The patch I applied
> | allows Axiom to work when build tree is not present. In other words,
> | when you make a tarball of installed Axiom and put it on another
> | machine it will work, unless there is unreadable directory on path
> | leading to original build tree.
> |
> | That is, one still gets the error when build tree is unreadable. It is
> | hard to say who is a guilty party. At least part of blame goes to the
> | following:
> |
> | - gcc: it skips nonexistent directories, but raises errors for unreadable
> | ones
>
> In this case, it is not clear to me how the resulting C program would
> compile if GCL's header is not included. So, it is probably a good
> thing that GCC complained. But, I think the root cause is elsewhere.
>
My point is that GCC is inconsistent here: both non-existent and unreadable
directory raise the some alternative: either directory is not needed
(and may be safely skipped) or is needed. I can guess that GCC made
a pragmatic decision here: non existent directories are probably very
frequent and GCC does not dare to signal error.
> | - gcl: it unconditionally adds include directive of form
> | -I/gcl/system/directory/../h
> | (where /gcl/system/directory/ is stored in si::*system-directory*
> | variable)
> | - Axiom, because it lets si::*system-directory* stay at its default
> | setting.
>
> My understanding (Camm, please correct me) is that GCL is not set up
> yet to work without its internal header file. However, if that is
> true I can't explain why we did not run into that problem before...
>
Try the following (or belive me that you get indicated result). Create
a simple Spad file. Take Axiom from build-improvements (or wh-sandbox),
with gcl intalation visible. By default you should see
compiler::*default-system-p* set to t.
1) Try just compiling your file. It should compile fine.
2) Change access right on gcl instaltion so that it is unreadable by
you. Again try compiling: you should see error about lack of
access to gcl directory
3) rename gcl directory. Again try compiling: you should see a
cascade of errors from gcc (due to missing declarations from
include file).
4) do
)lisp (setf compiler::*default-system-p* nil)
compile again: Your file should compile fine.
5) Move back gcl instalation into is original place (still
ureadable by you). Compile again: you should see the same
error as in 2.
Point 4 shows that executable created by gcl _can_ compile Lisp
files if compiler::*default-system-p* is set to nil and
include directory is either absent or readible. With include
directory present, but unreadable (point 5 above) you get errors.
As I wrote, when compiler::*default-system-p* is nil C files generated
by gcl do not need the gcl include file. But gcl still add corresponding
-I option to gcc comand line, and you get spurious errors.
\start
Date: Sun, 25 Feb 2007 22:08:02 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Lazyness in lexing Boot and Spad
>
> Hello,
>
> Axiom's implementation of Boot's and Spad source includer
> (src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
> through function "Delay"). This is also variously known as zipper.
> My quesion is how much of the complexity introduced by faking
> lazyness actually outweight the benefits? Is the lazyness actually
> beneficial?
>
AFAICS the main potential of benefit of lazyness is that it allows
writing algorithm as if it operated on the whole file, but still
have "interactive" parser -- that is parser which stops reading
its input when it sees end of a syntactic construct.
This potential benefit is completly lost in Axiom: the command
line parser requires that the whole construct is on single logical
line (that is single line after joining all continuated lines).
I can guess that command line parser is non-interactive due to
backtracking and also because whitespace syntax lacks explicit
end-of-construct markes (for example parser sees that a procedure
ended only when seeing next procedure or end of file).
I must say that this whole pipeline:
scan.boot.pamphlet pile.boot.pamphlet pf2sex.boot.pamphlet
pf2atree.boot.pamphlet parini.boot.pamphlet packtran.boot.pamphlet
macex.boot.pamphlet intfile.boot.pamphlet incl.boot.pamphlet
dq.boot.pamphlet cstream.boot.pamphlet cparse.boot.pamphlet
astr.boot.pamphlet
is on my list of candidates for removal. I would like to reuse
parts of this code, but I belive that what we need can be done
simpler. However, rewriting this part for me is of low priority,
and I probably will not get to this before summer.
My vision of future compiler is:
- classical lexer which generates basic syntax tree nodes (including
line number info)
- first stage parser (build surface syntax tree) accepting very
loose grammar
- macroexpander
- second stage parser (flattening trees and checking syntactic
constraints which cna be checked only after macro expansion)
- typechecker, probably multipass. In first few passes I would only
consider interface parts, the final pass would also check bodys
(and resolve overloading)
- final code generation
Some remarks why such structure: I want macro expansion rather
early, because before macro expansion is it impossible to check
for syntax correctness. Also, full syntactic information helps
with typechecking (current parser has it backwards, it uses
type information for parsing, leading sometimes to weird errors).
Also, current compiler couples code generation with type checking,
which is potentialy wastefull. Namely, in some cases the compiler
has to do backtracking search on possible type assignments, so
it generates code and then discard it during backtracking (I am
not sure how serious this problem is -- most of the time backtracking
is very limited).
During compilation in some cases (IIRC in chaseInferences) the compiler
uses recursive traversal on a dag (ignoring identity of nodes)
which leads to about 3m spent on a single file (samewhat surprisingly
the particular procedure I found shows pathological behaviour only one
file, on other taking only little time).
I belive that having typechecking as a separate phase operationg
essentially on the whole program would allow beter search technique
and would avoid many time sinks (currently many global data structure
are invalidated after compilation of any constructors, which is
probably responsible for nonlinear compile times for multifile
compilations).
\start
Date: 25 Feb 2007 18:01:50 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Lazyness in lexing Boot and Spad
Waldek Hebisch writes:
| >
| > Hello,
| >
| > Axiom's implementation of Boot's and Spad source includer
| > (src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
| > through function "Delay"). This is also variously known as zipper.
| > My quesion is how much of the complexity introduced by faking
| > lazyness actually outweight the benefits? Is the lazyness actually
| > beneficial?
| >
|
| AFAICS the main potential of benefit of lazyness is that it allows
| writing algorithm as if it operated on the whole file, but still
| have "interactive" parser -- that is parser which stops reading
| its input when it sees end of a syntactic construct.
I'm familiar with Haskell -- and have written slightly more than "toy"
programs in Haskell, so I appreciate the benefits of lazyness in
general. I apologize I did not make make it clearer that I'm talking
of the specific case of Axiom's way of consuming the token stream.
I posit that if we had strictness analysis in Axiom, then the analysis
would find out that actually the parts that effectively consumes the
token stream are strict in the token stream argument. So, lazyness
buys nothing. I base that conjecture over "debugging" under GCL.
That is why I raised the question of the lazyness benefits in the
specific case of Axiom's current infrastructure.
| This potential benefit is completly lost in Axiom: the command
| line parser requires that the whole construct is on single logical
| line (that is single line after joining all continuated lines).
Yes. Which a strictness analysis will find out.
| I can guess that command line parser is non-interactive due to
| backtracking and also because whitespace syntax lacks explicit
| end-of-construct markes (for example parser sees that a procedure
| ended only when seeing next procedure or end of file).
Yes. But, I don't think that makes a huge difference.
| I must say that this whole pipeline:
|
| scan.boot.pamphlet pile.boot.pamphlet pf2sex.boot.pamphlet
| pf2atree.boot.pamphlet parini.boot.pamphlet packtran.boot.pamphlet
| macex.boot.pamphlet intfile.boot.pamphlet incl.boot.pamphlet
| dq.boot.pamphlet cstream.boot.pamphlet cparse.boot.pamphlet
| astr.boot.pamphlet
|
| is on my list of candidates for removal.
There are many files on that list that I would disagree on removing.
This statement is based on spending a non-negligible part of the last
10 months studying from different angles. No doubt they need
improvement. But, I'm deeply skeptical about their removal.
| I would like to reuse
| parts of this code, but I belive that what we need can be done
| simpler. However, rewriting this part for me is of low priority,
| and I probably will not get to this before summer.
I've done some work on it in several local tress, but their
combination is not a coherent structure at this time I'm afraid.
While working on those parts of the compiler (and interpreter), I've
considered a suggestion made by Bill Page some time ago: maybe rewrite
Axiom in Haskell? On several occasions, I've resisted that idea.
But, if we get the improvements in both Boot and the compiler
structures, it will look a lot like something written in "simple
Haskell". Funny.
| My vision of future compiler is:
| - classical lexer which generates basic syntax tree nodes (including
| line number info)
| - first stage parser (build surface syntax tree) accepting very
| loose grammar
| - macroexpander
| - second stage parser (flattening trees and checking syntactic
| constraints which cna be checked only after macro expansion)
| - typechecker, probably multipass. In first few passes I would only
| consider interface parts, the final pass would also check bodys
| (and resolve overloading)
| - final code generation
|
| Some remarks why such structure: I want macro expansion rather
| early, because before macro expansion is it impossible to check
| for syntax correctness. Also, full syntactic information helps
| with typechecking (current parser has it backwards, it uses
| type information for parsing, leading sometimes to weird errors).
I'm unclear about your issue with macro expansion. From my
understanding, they happen very early in the compilation process --
albeit not like C macro expansion (a horror I would like to see
disappear the surface of the planet).
--% WHERE
compWhere([.,form,:exprList],m,eInit) ==
$insideExpressionIfTrue: local:= false
$insideWhereIfTrue: local:= true
e:= eInit
u:=
for item in exprList repeat
[.,.,e]:= comp(item,$EmptyMode,e) or return "failed"
u="failed" => return nil
$insideWhereIfTrue:= false
[x,m,eAfter]:= comp(macroExpand(form,eBefore:= e),m,e) or return nil
eFinal:=
del:= deltaContour(eAfter,eBefore) => addContour(del,eInit)
eInit
[x,m,eFinal]
I would like Axiom to have the ability to store the following:
(1) the "parse form"
(2) the "fully typed ast" before code generation
I have an intermediate representation of Spad in Spad. It lacks
a couple of feature, but I can handle almost all algebra files.
| Also, current compiler couples code generation with type checking,
| which is potentialy wastefull. Namely, in some cases the compiler
| has to do backtracking search on possible type assignments, so
| it generates code and then discard it during backtracking (I am
| not sure how serious this problem is -- most of the time backtracking
| is very limited).
Yes, my guestimate was that the waste generated by backtracking is
small enough.
| During compilation in some cases (IIRC in chaseInferences) the compiler
| uses recursive traversal on a dag (ignoring identity of nodes)
| which leads to about 3m spent on a single file (samewhat surprisingly
| the particular procedure I found shows pathological behaviour only one
| file, on other taking only little time).
|
| I belive that having typechecking as a separate phase operationg
| essentially on the whole program would allow beter search technique
| and would avoid many time sinks (currently many global data structure
| are invalidated after compilation of any constructors, which is
| probably responsible for nonlinear compile times for multifile
| compilations).
That idea is already present in some form:
intloopSpadProcess(stepNo,lines,ptree,interactive?)==
$stepNo:local := stepNo
$currentCarrier := cc := ['carrier]
ncPutQ(cc, 'stepNumber, stepNo)
ncPutQ(cc, 'messages, $ncMsgList)
ncPutQ(cc, 'lines, lines)
$ncMsgList := nil
result := CatchAsCan(flung, Catch("SpadCompileItem",
CATCH($intCoerceFailure, CATCH($intSpadReader,
interp(cc, ptree, interactive?))))) where
interp(cc, ptree, interactive?) ==
ncConversationPhase(function phParse, [cc, ptree])
ncConversationPhase(function phMacro, [cc])
ncConversationPhase(function phIntReportMsgs,[cc, interactive?])
ncConversationPhase(function phInterpret, [cc])
#ncEltQ(cc, 'messages) ^= 0 => ncError()
intSetNeedToSignalSessionManager()
$prevCarrier := $currentCarrier
result = 'ncEnd => stepNo
result = 'ncError => stepNo
result = 'ncEndItem => stepNo
stepNo+1
\start
Date: Mon, 26 Feb 2007 10:08:13 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Build problem (was [SOLVED] %S in some contr. pkg fails to compile)
Martin,
it all works now thanks to your detailed help. I compiled
the latest axiom-silver, that's why the reply took so long.
The problem was, on the web page I saw the button named 'src'
and I thought hey just )read that into axiom ...
Axiom Silver has a bug BTW which prevents it from building
from svn. svn creates subdirectories named .svn/ with some read-only
files, and at two places in the make process there are commands
'cp -r' (recursive) that will try to copy these directories, too.
Maybe they should be changed to 'cp -r [a-zA-Z]* ...'?
\start
Date: Mon, 26 Feb 2007 15:07:13 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Lazyness in lexing Boot and Spad
If SPAD provides "Generator" that would be sufficient. In Aldor-Combinat
I have implemented streams and formal power series building on that concept.
I have not checked Axiom, but I guess defining a series like
s: FormalPowerSeries(Integer) := new();
set!(s, 1 + monom * s * s);
is not possible. Am I wrong? Maybe the delay keyword allows it??? (Could
someone show me?)
Of course, I would rather like to write
s := 1 + monom * s * s;
or perhaps with == instead of :=, but that would really require lazyness.
Ralf
On 02/25/2007 08:36 PM, Gabriel Dos Reis wrote:
> Hello,
>
> Axiom's implementation of Boot's and Spad source includer
> (src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
> through function "Delay"). This is also variously known as zipper.
> My quesion is how much of the complexity introduced by faking
> lazyness actually outweight the benefits? Is the lazyness actually
> beneficial?
>
\start
Date: Mon, 26 Feb 2007 09:34:19 -0600 (CST)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Lazyness in lexing Boot and Spad
On Mon, 26 Feb 2007, Ralf Hemmecke wrote:
| If SPAD provides "Generator" that would be sufficient. In Aldor-Combinat
| I have implemented streams and formal power series building on that concept.
|
| I have not checked Axiom, but I guess defining a series like
|
| s: FormalPowerSeries(Integer) := new();
| set!(s, 1 + monom * s * s);
|
| is not possible. Am I wrong? Maybe the delay keyword allows it??? (Could
| someone show me?)
|
| Of course, I would rather like to write
|
| s := 1 + monom * s * s;
|
| or perhaps with == instead of :=, but that would really require lazyness.
The lazyness I was talking about in my message is at the Boot source
code level.
Lazyness at Spad level is a different issue. The computational rules
used by Spad does not seem to be documented anywhere. Experimental
evidence suggests "call by value" but that does not seem to be
sancitoned by an official documentation.
\start
Date: Mon, 26 Feb 2007 17:45:57 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: Lazyness in lexing Boot and Spad
> Is the lazyness actually beneficial?
I do not have knowledge of the internals of boot, which was
designed and written entirely by Dick Jenks and Bill Burge.
There were many parsers for Axiom and this was a research
area for Bill. I suspect that the DELAY you see in the zipper
parser was just another research experiment, not related to
the delay in recent languages in any way.
Frankly I believe the whole thing should be rewritten using the
syntax and semantics of Aldor but implemented in lisp, following
the original scratchpad project plan.
The C based version can never reach into the axiom algebra tree
where the real value of axiom lies. Most of the functionality of
Aldor already exists. A cleanly designed and implemented parser
would go a long way toward making the project a stronger research
platform, both for language and for algebra. We could remove all
of boot and its complications and have a clearly specified AST
layer that users could access. Indeed, done properly and carefully
documented a new parser would allow an algebra file to define its
own input syntax, similar to it's ability to define its own output
syntax. Thus a quantum physics user could implement the "bra" and
"ket" operators, handle greek letters, etc.
But I think a parser rewrite waits on the language definition.
I don't think it would benefit us to be overly religious about
the language points at this time. It would be more important to
be able to parse what exists cleanly and make the parser extensible
from algebra. Lisp gives us the unique ability to manipulate the
intermediate language forms in the same implementation language.
Thus the "overhead" of letting algebra introduce new syntax is
minimal since even the console readtables can be changed on the fly.
\start
Date: 26 Feb 2007 18:34:20 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Lazyness in lexing Boot and Spad
Tim Daly writes:
| > Is the lazyness actually beneficial?
|
| I do not have knowledge of the internals of boot, which was
| designed and written entirely by Dick Jenks and Bill Burge.
| There were many parsers for Axiom and this was a research
| area for Bill. I suspect that the DELAY you see in the zipper
| parser was just another research experiment, not related to
| the delay in recent languages in any way.
|
| Frankly I believe the whole thing should be rewritten using the
| syntax and semantics of Aldor but implemented in lisp, following
| the original scratchpad project plan.
I agree with the goal, except on the mean: src/boot/ should be
improved instead of being replaced by a system directly written in
Lisp. I've spent a fair amount trying to understand that part of the
system. I conjecture that anything that would be reinvented in Lisp
would be inferior and the resource is best spent documenting and
improving it. For example, pattern matching let us directly express
algorithms and ideas, instead of the current circumvolutions of
predicate testing and wild casting. src/boot/ already has pattern
matching, along with algebraic data type definition. Initial testing
shows that the translator translates just fine. It is regretful that
it has not been used in the rest of src/interp.
[...]
| But I think a parser rewrite waits on the language definition.
Yes.
| I don't think it would benefit us to be overly religious about
| the language points at this time. It would be more important to
| be able to parse what exists cleanly and make the parser extensible
| from algebra. Lisp gives us the unique ability to manipulate the
| intermediate language forms in the same implementation language.
So does Boot.
| Thus the "overhead" of letting algebra introduce new syntax is
| minimal since even the console readtables can be changed on the fly.
yes, and many aspect of the current implementation reminds me of use
Template Haskell
http://www.haskell.org/th/
in domain specific languages.
\start
Date: Mon, 26 Feb 2007 18:43:16 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: next release
> Well, patches are supposed to be posted when they are ready for
> "prime time" use. For "personal" experimentation we don't require
> that (should we?)
Well, clearly "personal" experimentation is a non-issue.
I'm not claiming that anyone has an obligation to share their
local changes. Indeed, the license does not require this either.
However, working together on a common project tends to imply sharing.
But real sharing involves work to "get it off your desk" and into
the common distribution.
The published mechanism for making changes to Gold is to post
diff -Naur goldcode yourcode >patch
files to the mailing list
I see changes in various files that can be picked up at this time and
would benefit everyone. However, there are several, shall we say,
"challenges":
Challenge 1: SIMPLE CHANGES, such as removing the C prototype
code is clear, tedious, harmless, and requires no explanation.
I've already picked up these changes and made sure they happen
in every file.
Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
the boot code. This change was made with no documentation added
to the source code making it impossible to (a) guess why and
(b) test. Furthermore, there are no test cases so even if I
understood it I'd have to develop the test cases again (assuming
you had them in the first place) from scratch.
Challenge 3: ALGEBRA CHANGES. these are clearly beneficial as
they address known bugs. Unfortunately I'm not an expert in ALL
of the algebra and I'm adverse to changing what I don't understand.
(Consider me the first in a long line of people maintaining this
code over the next 30 years. If I can't understand it how will they?)
There was a change to the series code which went into Gold. Now we
find out that the "fix" was wrong and a new "fix" is proposed.
I spoke with Clifton Williamson, the original author of the code, to
try to validate the original code vs the new fix, so far with no
decision. Do we want algebra bug fixes to lay around unmerged?
Do we want to change algebra we don't understand? If we understand
it do we want to share that information with future maintainers?
If algebra bug fixes are to be merged we'd need to have some
explanation of the algorithm so the code could be understood by
people other than the person who proposed the fix. You need to
understand the algorithm to fix it anyway so write down what you
understand so others can understand.
If algebra bug fixes are to be merged we'd need to have some
test cases of the algorithm so the code can be checked, especially
for boundary cases. If you've understood the algorithm and can fix
it I'd suppose that you had test cases. Publish these as part of
the fix.
Challenge 4: DEEP STRUCTURAL CHANGES. these are harder to merge as
they will completely restructure axiom. this will have an impact
not only on the main line of code but also on every other "private"
branch of axiom, so it is vital that they are complete, consistent,
and correct.
In order to merge this code it would need a cleanly documented
pile of code. One of the main project goals is to make sure that
the system can be maintained. That implies that other people can
gain an understanding of the code without having to reverse
engineer it. We're stuck with the reverse engineering task because
Daly, et.al. didn't document anything. Lets learn from history.
It would also have to be a diff of Gold since it would be impossible
to know all of the little dependent pieces that are tucked away
(e.g. the new axiom-c-macro.h file) or the new handling of
gcl-cmpinclude.h, etc. You've spent months making GNU configure
work. Wouldn't it be frustrating to find it badly broken because
of merging problems?
Other deep changes, such as a new parser, are also likely to be a
"challenge 4" task.
> The axiom-commit mailing list has the history of all commits
> to SVN -- when they are not truncated due to SF policy
The axiom-commit mailing list posts are essentially worthless as a
Gold-merge resource. I can reclaim the same information in more detail
by doing
diff -r --brief build-improvements gold
What's missing is the (a) changesets (b) documentation (c) tests
The "changeset" mentality is that all of the changes necessary to
produce a final single effect are packaged in a single set of patches.
Changesets are essential to contain all of a change and only a change.
In the current bi/wh branches even simple changes, such as eliding
the C protoype code are spread over multiple commits and not fully
implemented everywhere. The new asq requires new database formats
and changes to the database generation code, all of which have to
happen at the same time.
Documentation is essential because while the axiom-commit says something
cryptic like "fixed bug #NNN", that message is hardly considered a high
quality, "production" piece of code. If we're going to make progress
against the winds of time we've got to consider the future maintainers.
Tests are necessary so that (a) other people can see what the impact
of a change is, (b) we can see what breaks in other peoples' branches
or the gold branch, (c) we can (eventually) regression test and (d) we
can eventually build up a more organized, comprehensive test suite
like CATS (Computer Algebra Test Suite) that other people can build upon.
Since I'm in the midst of reverse-engineering the build-improvements
and wh-sandbox branches it would be a good time to consider packaging
up changesets for functionality you consider complete and ready. I know
it takes you away from "interesting" axiom tasks. The whole build process
has already cost me several weeks so I understand.
\start
Date: Tue, 27 Feb 2007 02:05:07 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: fixes and patches
> > Anyway, patch follows (note that this patch will probably do
> > no good without other pathname changes from wh-sandbox
>
> Here is where my problem arises. When trying to build a system that
> many people will use, such as Gold, it is important that I don't
> introduce more, or more subtle, errors than I fix. I'm very reluctant
> to change what I don't understand since, in the long run I and others
> may need to maintain it.
>
> In order to apply your changes I will need to evaluate every other
> change you've made to decide if it is related or a prerequisite change.
> It can take a day or more to difference your source tree from Gold and
> do this evaluation since there is no documentation in the source files
> explaining why the change was made. And it is not clear if these changes
> depend on other parts of your sandbox, such as Gaby's build system.
>
> This change is a worthwhile idea and should be brought forward to Gold.
> It would be most helpful, and Gold would happen a lot faster, if you
> could take the time to make a diff-Naur Gold patch containing the
> complete changeset.
>
I am trying to help, but sorry ATM I am very busy. The list I posted
contains all changes that I consider to be user visible changes. I belive
they are mostly independent of other patches. Patches to .spad files
should apply to Gold with no (or little) changes. Most algebra patches
reference bug numbers in Issue tracker. Having Issue tracker number
you can find a testcase and frequently disscusion. Some fixes are
taken from Issue tracker. Many algebra fixes show in test result
(the script I posted helps to automate comparison). In particular
bug 312 is prominently visible (IIRC in series2.output) -- just
compare test results.
IIRC one fix to .spad files depends on changes to file handling
in interpreter (this should be obvious since those changes form
a single changeset == form single patch). I think that changes
to interpreter files are independent of build system. One change
affecting Hyperdoc, that is installation on libdb etc, changes
Makefiles -- IIRC I have posted a version of this patch which
applies to Gold. One change to Hyperdoc (extra change in protocol)
must be done both to Hyperdoc and to interpreter (otherwise
things will break), I belive that other Hyperdoc changes can be
applied independently (but some fixes concern Hyperdoc crashes,
so if you take incomplete set of fixes crash may eliminate
possibility to see improvement due to other fixes).
I do not have time to make (and test) diffs to Gold. But even
if I had time I do not know if making such diffs would be a
good idea: IIUC your devlopement version is different from
published one and you apply diffs manually. Most of the time
different between Gold and wh-sandbox is trivial and will
cause no trouble. The only trouble points are likely to
be due to removal of duplicate code in wh-sandbox and improvements
to build machinery. But those to changes are made precisely
to avoid doing extra work. Gaby spent time cleaning build
system, I spent time identifying duplicate/unused code (I do
_not_ remove code lightly). Now you want us to spent time
working with issues that our work eliminated?
Note, if you want changes to wh-sandbox as separate patches
I can provide this (but I think you already have them from
the commit mailing list). Also, if you have specific questions
concering patches I will try to answer.
\start
Date: Tue, 27 Feb 2007 02:52:54 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: next release
Cc: Gabriel Dos Reis
> Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
> the boot code. This change was made with no documentation added
> to the source code making it impossible to (a) guess why and
> (b) test. Furthermore, there are no test cases so even if I
> understood it I'd have to develop the test cases again (assuming
> you had them in the first place) from scratch.
>
That issue has been discussed on the mailing list:
Shoe tranlates member to MEMBER and passes MEMBER unchanged
Boot tranlates MEMBER to |member| and passes member as |member|
(to check just look at generated Lisp). MEMBER and |member| have
different semantics. If you look at generated spad files you
may easily see that compiler which uses MEMBER (insted of |member|)
mistranslate many files.
>
>
>
> Challenge 3: ALGEBRA CHANGES. these are clearly beneficial as
> they address known bugs. Unfortunately I'm not an expert in ALL
> of the algebra and I'm adverse to changing what I don't understand.
> (Consider me the first in a long line of people maintaining this
> code over the next 30 years. If I can't understand it how will they?)
> There was a change to the series code which went into Gold. Now we
> find out that the "fix" was wrong and a new "fix" is proposed.
If somebody compared test results the problem would be recognized
immediately.
> I spoke with Clifton Williamson, the original author of the code, to
> try to validate the original code vs the new fix, so far with no
> decision. Do we want algebra bug fixes to lay around unmerged?
> Do we want to change algebra we don't understand? If we understand
> it do we want to share that information with future maintainers?
>
I wrote an explanation. And my conclusion is simple: original code
was correct, but did not handle some cases with negative powers.
After change those cases were handled correctly, but fix missed
the last line from original code. I restored the this missing
line (which is needed _only_ when constant term is 0).
> > The axiom-commit mailing list has the history of all commits
> > to SVN -- when they are not truncated due to SF policy
>
> The axiom-commit mailing list posts are essentially worthless as a
> Gold-merge resource. I can reclaim the same information in more detail
> by doing
> diff -r --brief build-improvements gold
>
> What's missing is the (a) changesets (b) documentation (c) tests
>
Tim, at least in wh-sandbox I tried to have changeset == commit. There
are some exceptions (merge from build improvements was split into
few commits, once or twice I made a mistake and next commit fixed this),
but essentially having commits you have changesets.
> The "changeset" mentality is that all of the changes necessary to
> produce a final single effect are packaged in a single set of patches.
>
> Changesets are essential to contain all of a change and only a change.
If you want to make changes completly indepenent then I must say sorry.
I try to avoid unneded dependencies, but changes I do are all part
of larger effort to make Axiom better. Each is self contained but
may depend on previous changes. Note that identifying independent
sets is a nonlinear and essentially useless task -- we want _one_
good version, not a myriad of combiantions of various patches.
> In the current bi/wh branches even simple changes, such as eliding
> the C protoype code are spread over multiple commits and not fully
> implemented everywhere. The new asq requires new database formats
> and changes to the database generation code, all of which have to
> happen at the same time.
>
No. New asq should work fine with old databases. Old asq can not
work with compressed or pretty printed databases (note that
database documentation claims that compression is optional and
says that hunks are just Lisp forms -- nothing forbiding
pretty printing). So new asq just implements what is documented
(removes undocumented restrictions from old asq). The new
asq is _required_ if you want to use asq with uncompressed
databases (or prett print them).
\start
Date: 26 Feb 2007 23:27:45 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release
Tim Daly writes:
| > Well, patches are supposed to be posted when they are ready for
| > "prime time" use. For "personal" experimentation we don't require
| > that (should we?)
|
| Well, clearly "personal" experimentation is a non-issue.
|
| I'm not claiming that anyone has an obligation to share their
| local changes. Indeed, the license does not require this either.
| However, working together on a common project tends to imply sharing.
| But real sharing involves work to "get it off your desk" and into
| the common distribution.
This is true in general, including your changes to Gold we don't see
until the Big Day. I'm trying to single you out. We all have local
experimental trees that would do more harms if published than kept local.
[...]
| Challenge 1: SIMPLE CHANGES, such as removing the C prototype
| code is clear, tedious, harmless, and requires no explanation.
| I've already picked up these changes and made sure they happen
| in every file.
Those changes are clearly beneficial in isolation. Please note also
that because Gold and Silver have gone, until very recently, into very
uncertain status, it was hard to do anything useful. Changes should
first go into Silver before being picked up and lifted to Gold. We,
at least me, don't know which branch is Silver and what is its
status. I don't know which is going to be Gold and its day-to-day
status, i.e. preview of what is to be Gold. Under those
circumstances, it is hard to do anything useful to Silver and Gold.
| Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
| the boot code. This change was made with no documentation added
| to the source code making it impossible to (a) guess why and
| (b) test. Furthermore, there are no test cases so even if I
| understood it I'd have to develop the test cases again (assuming
| you had them in the first place) from scratch.
I don't remember any patch eliding "member" from the Boot code.
[...]
| > The axiom-commit mailing list has the history of all commits
| > to SVN -- when they are not truncated due to SF policy
|
| The axiom-commit mailing list posts are essentially worthless as a
| Gold-merge resource. I can reclaim the same information in more detail
| by doing
| diff -r --brief build-improvements gold
Those changes that would go into Gold, are ideally, diffs between
Silver and Gold. However, I no longer know what is Silver and what is
Gold.
| What's missing is the (a) changesets (b) documentation (c) tests
|
| The "changeset" mentality is that all of the changes necessary to
| produce a final single effect are packaged in a single set of patches.
The "changeset" mentality must make room for incremental improvements;
that is a necessity when you don't have the power (e.g. resources) to
make change in one shot in a timely manner and remain useful. Users
are more tolerant of incremental improvements than may be assumed.
[...]
| Since I'm in the midst of reverse-engineering the build-improvements
| and wh-sandbox branches it would be a good time to consider packaging
| up changesets for functionality you consider complete and ready. I know
| it takes you away from "interesting" axiom tasks. The whole build process
| has already cost me several weeks so I understand.
It is not a matter of taking me away from "interesting" axiom tasks than
asking me to allocate time today or this week when I have none to
solve the fuzzily defined problem. I was travelling last week
attending (important) ISO C++ meetings, which made me fall behind
class schedules which I need to catch on this week, plus the usual
deadlines that come hard when time is short.
I need the following:
(a) a clear mark of what is Silver, what is Gold
(b) I would like to be able to propose diff between Silver and Gold
for inclusion in Gold
(c) I would like to have patches applied directly to Silver,
assumming the general community is interested. I.e. I would like
to see more testing of "gold preview".
Can we work that out?
\start
Date: 26 Feb 2007 23:46:36 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release
Gabriel Dos Reis writes:
| Tim Daly writes:
|
| | > Well, patches are supposed to be posted when they are ready for
| | > "prime time" use. For "personal" experimentation we don't require
| | > that (should we?)
| |
| | Well, clearly "personal" experimentation is a non-issue.
| |
| | I'm not claiming that anyone has an obligation to share their
| | local changes. Indeed, the license does not require this either.
| | However, working together on a common project tends to imply sharing.
| | But real sharing involves work to "get it off your desk" and into
| | the common distribution.
|
| This is true in general, including your changes to Gold we don't see
| until the Big Day. I'm trying to single you out. We all have local
^
arrgh. I did it again :-(. Obviously my fingers again did not obey my
brain when it said "NOT". Sorry for that. I hope you deduced that
from the rest of the paragraph.
| experimental trees that would do more harms if published than kept local.
\start
Date: Tue, 27 Feb 2007 00:11:39 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: next release
Gaby,
> This is true in general, including your changes to Gold we don't see
> until the Big Day. I'm trying to single you out. We all have local
> experimental trees that would do more harms if published than kept local.
I published my whole research tree (in git, since svn was broken)
in November when we had this same discussion but got no response.
All of my axiom-related work is now kept in that tree.
>...[snip]... Please note also
> that because Gold and Silver have gone, until very recently, into very
> uncertain status ...[snip]...
The plan was to publish a new Gold at the end of November. But in the
beginning of November we had the big discussion about me being "a
single point of failure" so I stepped out of the way and told everyone
that any changes they wanted in Gold they would have to do
themselves. Everyone had permission to do that. Since that time no-one
has changed anything. It became clear that nobody was going to make
the effort to create a new release. I've decided to step back into
the role of releasing systems and am trying to catch up to the
outstanding changes.
I tried maintaining silver but I was the only one making changes.
Plus the additional copies of Axiom were causing rising server costs.
If it depends on my effort silver is dead. I only have enough time
available to do Gold and do my own axiom-related work. I certainly
don't have time to maintain silver. Since advocacy is volunteering
you're welcome to create and maintain a silver version that is a
test version for gold changes.
Gold will again be released on a 2-month, best-effort schedule.
\start
Date: Tue, 27 Feb 2007 00:20:06 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: next release
> arrgh. I did it again :-(
funny. :-)
\start
Date: Tue, 27 Feb 2007 00:58:49 -0600 (CST)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release
On Tue, 27 Feb 2007 Tim Daly wrote:
| Gaby,
|
| > This is true in general, including your changes to Gold we don't see
| > until the Big Day. I'm trying to single you out. We all have local
| > experimental trees that would do more harms if published than kept local.
|
| I published my whole research tree (in git, since svn was broken)
| in November when we had this same discussion but got no response.
It appeared to me to be an "experiment". I did not exactly what I
should "answer".
| All of my axiom-related work is now kept in that tree.
|
|
|
|
| >...[snip]... Please note also
| > that because Gold and Silver have gone, until very recently, into very
| > uncertain status ...[snip]...
|
| The plan was to publish a new Gold at the end of November. But in the
| beginning of November we had the big discussion about me being "a
| single point of failure" so I stepped out of the way and told everyone
| that any changes they wanted in Gold they would have to do
| themselves. Everyone had permission to do that. Since that time no-one
| has changed anything. It became clear that nobody was going to make
| the effort to create a new release.
My understanding was that decision was the outcome of
miscommunication, therefore I was not going to do any release or do any
commit to Silver or Gold (I don't know exactly which trees are those)
_until that was resolved_. Clearly, I'm not going to take anybody's
place if that someone thinks he is being "kicked out". Sorry to put
it that way, but that is how your message sounded.
[ For example, I needed an "official" version for my last semester
class project, but in the end I distributed an official version
of build-improvements so that students can work. I would have
preferred it was official. ]
| I've decided to step back into the role of releasing systems and am
| trying to catch up to the outstanding changes.
I very much welcome your stepping back into the role of releasing the
system.
| I tried maintaining silver but I was the only one making changes.
Going back to last semester discussion, you're the only one doing the
commit to Silver, because it appeared to me that:
(1) the system was set up in a way that you're the only one to
effectively commit to silver, e.g. any commit to SF SVN
reposiotyr is effectively "lost" from your perspective.
(2) you wanted to take over silver, which I was originally maintaining.
| Plus the additional copies of Axiom were causing rising server costs.
| If it depends on my effort silver is dead. I only have enough time
| available to do Gold and do my own axiom-related work. I certainly
| don't have time to maintain silver. Since advocacy is volunteering
| you're welcome to create and maintain a silver version that is a
| test version for gold changes.
So, we are again back to what things were in April-September 2006?
This is an important question I need a clear answer for.
As I already pointed out, we should encourage people to commit
themselves their patches to Silver. That reduces the load on the
maintainer.
\start
Date: Tue, 27 Feb 2007 00:59:39 -0600 (CST)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release
On Tue, 27 Feb 2007 Tim Daly wrote:
| > arrgh. I did it again :-(
|
| funny. :-)
Well, being the perpetrator I feel differently :-( :-/
\start
Date: Tue, 27 Feb 2007 12:34:05 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: mapleok results
Here are results of my analysis of several integrals from mapleok
before and after applying arc tangent patch.
I had examined a few other integral, but did not record my conclusion.
In general for integrals missing from (rather short) list below I
make no statement. To conclude that we get an integral wrong I
was typically satisfied with results of numerical integration. To
conclude that we got integral OK I looked if jump discontinuities are
present (absence of jump discontinuities means we got the integral
correct). I did some sanity checking for other problems, but
besically I trusted that up to jump discontinuities we get them
correct.
integrate(z/(2-cos(z^2))^2, z=0..2, "noPole")
was wrong
is wrong
in1012a:=integrate(log(abs(z^3-1))/(1+z)^2, z= 0..%plusInfinity,"noPole")
wrong
in1084a:=integrate(atan(sin(z))+atan(1/sin(z)), z= 0..1,"noPole")
wrong
in1118:=integrate(acot(z), z= 0..1/2*I)
was wrong
is OK
in1149:=integrate(imag(z)*z^(1/6), z= -%i..%i)
wrong
in1167a:=integrate((z^2)^(1/6), z= -3..-1,"noPole")
wrong
in1183a:=integrate(csc(z), z= 1-I..1+I,"noPole")
too complicated
in1186a:=integrate((z^2+z)^(1/2)/(1+z^2)^2, z= 0..1,"noPole")
was OK
is wrong
in1190a:=integrate(sin(z)^2*tan(z)^(1/2), z=0..1, "noPole")
was wrong
is wrong
too complicated answer
in1191a:=integrate(sin(z)^2/tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is wrong
in1207a:=integrate(sin(z)*cos(z)*tan(z)^(1/2), z= 0..1, "noPole")
was wrong
is OK
in1214a:=integrate(-sin(z)*tan(z)*csc(z-1), z= 0..1, "noPole")
wrong (is divergent)
in1217a:=integrate(sin(z)*sec(z)*tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is OK
in1218a:=integrate(sin(z)*sec(z)/tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is OK
in15ab:=integrate(log(sqrt(z)+z^5), z=0..a,"noPole")
was wrong
is OK
in1228a:=integrate(sin(z)*csc(z)*tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is OK
in1248a:=integrate(sin(z)*csc(z)*tan(z)^(1/2), z= 0..1,"noPole")
duplicate
in1261a:=integrate(1/(sin(z)+cos(2*z)), z= -1..1,"noPole")
wrong (divergent)
in1376a:=integrate(z*acoth(z^(1/2)), z= 0..1,"noPole")
ignored imaginary part
in143a:=integrate(sqrt(1+z)/(1+z^2), z= 0..1,"noPole")
was wrong
is OK
in1933a:=integrate(atan(z)/z/(z*(1+z))^(1/2), z= 0..1,"noPole")
was wrong
is OK
in202a:=integrate(acsc(z), z= 0..1/2,"noPole")
ignored imaginary part
real part was wrong
in2053a:=integrate(atan(2*z-1), z= 0..infinity,"noPole")
was wrong
is OK
integrate(atan(2*z-1), z= 0..%plusInfinity,"noPole")
was wrong
is OK
in2201a:=integrate(acoth(z)+%pi-asec(z-1), z= 0..1,"noPole")
ignored imaginary part
????
in249a:=integrate((sin(z)/(cos(z)-1))^(1/3), z= 0..%pi,"noPole")
ignored imaginary part
????
\start
Date: 27 Feb 2007 16:44:57 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Problem compiling wh-sandbox
Dear Waldek,
It seems I've got a problem compiling version 441 of wh-sandbox.
* gcl is not insatlled on my machine
* configure doesn't seem to do anything unusual
* make seems to get into an infinite loop starting with
if test "." != "."; then \
cp -r ./gcl .; \
fi; cd gcl; \
./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
make && make install
/bin/sh: line 0: cd: gcl: No such file or directory
\start
Date: Tue, 27 Feb 2007 10:51:59 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Problem compiling wh-sandbox
Cc: Waldek Hebisch
Marin,
On February 27, 2007 10:45 AM you wrote:
>
> It seems I've got a problem compiling version 441 of wh-sandbox.
>
> * gcl is not insatlled on my machine
> ...
As far as I know wh-sandbox requires that both gcl and noweb be
pre-installed *before* building Axiom.
As far as I am concerned, that is a good thing. gcl and noweb
should not be part of the Axiom distribution.
\start
Date: Tue, 27 Feb 2007 15:25:29 -0500
From: Cliff Yapp
To: Martin Rubey
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch
Martin,
I hit the same thing and worked around it by copying the gcl tree over
from build-improvements.
Cheers,
CY
Martin Rubey wrote:
> Dear Waldek,
>
> It seems I've got a problem compiling version 441 of wh-sandbox.
>
> * gcl is not insatlled on my machine
>
> * configure doesn't seem to do anything unusual
>
> * make seems to get into an infinite loop starting with
>
> if test "." != "."; then \
> cp -r ./gcl .; \
> fi; cd gcl; \
> ./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
> make && make install
> /bin/sh: line 0: cd: gcl: No such file or directory
\start
Date: 27 Feb 2007 16:51:30 -0600
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch
Cliff Yapp writes:
| Martin,
|
| I hit the same thing and worked around it by copying the gcl tree over
| from build-improvements.
|
| Cheers,
| CY
|
| Martin Rubey wrote:
| > Dear Waldek,
| > It seems I've got a problem compiling version 441 of wh-sandbox.
| > * gcl is not insatlled on my machine
| > * configure doesn't seem to do anything unusual
| > * make seems to get into an infinite loop starting with
| > if test "." != "."; then \
| > cp -r ./gcl .; \
| > fi; cd gcl; \
| > ./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
| > make && make install
| > /bin/sh: line 0: cd: gcl: No such file or directory
I believe Waldek said you must have GCL installed if you want to use
wh-sandbox. If that recollection is accurate, then I think he might
want to enforce that at configuration time,
\start
Date: Tue, 27 Feb 2007 18:40:49 -0500
From: Bill Page
To: Cliff Yapp
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch
Quoting C Y:
>
> I hit the same thing and worked around it by copying the gcl tree over
> from build-improvements.
>
> Cheers,
> CY
>
> Martin Rubey wrote:
>>
>> It seems I've got a problem compiling version 441 of wh-sandbox.
>>
>> * gcl is not insatlled on my machine
>>
It may not be obvious but you do not need to checkout the complete
build-improvements branch in order to get gcl and noweb. The following
svn commands are sufficient:
svn co
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl
svn co
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/noweb
To build gcl just the default build would be sufficient:
$ cd ~/gcl
$ ./configure
$ make
$ make install
( by default installs in /usr/local )
But if you want optimize GCL just for building Axiom you can use:
$ ./configure --prefix=... --disable-tkconfig --disable-x --disable-xgcl
where ... is where you want to install gcl and '.../bin' must in the PATH
$ export PATH=.../bin:$PATH
To install noweb you must edit the Makefile by hand:
$ cd ~/noweb/src
or apply the following patch to install noweb in /usr/local:
-------- noweb.patch ----------
$ diff -au Makefile.orig Makefile
--- Makefile.orig 2007-02-27 17:10:46.000000000 -0600
+++ Makefile 2007-02-27 17:17:12.000000000 -0600
@@ -6,9 +6,9 @@
CFLAGS=
# If you have Icon, you should use the Icon versions of the noweb pipeline.
# Set LIBSRC=icon
-LIBSRC=awk
+LIBSRC=icon
# If you have no Icon compiler, but do have icont, make ICONC=icont
-ICONC=iconc
+ICONC=icont
ICONT=icont
# BIN is where the commands (notangle, noweave, nountangle, noroots) land
@@ -18,9 +18,9 @@
# MAN7EXT is the extension for the nowebstyle man page (usually 7)
# TEXINPUTS is the directory for TeX macro files
# ELISP is the directory for emacs lisp files, or /dev/null not to install
-BIN=/usr/local/noweb
-LIB=/usr/local/noweb/lib
-MAN=/usr/local/noweb/man
+BIN=/usr/local/bin
+LIB=/usr/local/lib
+MAN=/usr/local/man
MANEXT=1
MAN7EXT=7
TEXINPUTS=/usr/local/tex/inputs
---------
$ patch < noweb.patch
$ make
$ make install
Note:
This patch uses the 'icon' option instead of 'awk'. Using icon results in
a significantly faster version of noweb. You can download icon from
http://www.cs.arizona.edu/icon
\start
Date: Wed, 28 Feb 2007 19:32:25 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch
> Dear Waldek,
>
> It seems I've got a problem compiling version 441 of wh-sandbox.
>
> * gcl is not insatlled on my machine
>
> * configure doesn't seem to do anything unusual
>
> * make seems to get into an infinite loop starting with
>
> if test "." != "."; then \
> cp -r ./gcl .; \
> fi; cd gcl; \
> ./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
> make && make install
> /bin/sh: line 0: cd: gcl: No such file or directory
>
In general to compile wh-sandbox you need to do one of the following:
-- have gcl pre-installed on your machine (note that if you have gcl in
a private directory you can tell configure where to find it)
-- copy gcl tree from build-improvements.
I will put this information into README.wh. Also, for out of source
build the build just stopped -- I will investigate how to detect missing
gcl tree and give sensible error message (intead of the loop you were
seeing).
--
Waldek Hebisch
Waldek Hebisch
|