tag:old.nabble.com,2006:forum-1615Nabble - Gnu - GCL2009-12-19T14:32:37ZGnu GCL is an implementation of Common Lisp. Gnu - GCL home is <a href="http://www.gnu.org/software/gcl/gcl.html" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26859206Re: GCL and the fork system call2009-12-19T14:32:37Z2009-12-19T14:32:37ZGabriel Dos Reis-2Camm Maguire <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26859206&i=0" target="_top" rel="nofollow">camm@...</a>> writes:
<br><br>| Greetings!
<br>|
<br>| Gabriel Dos Reis <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26859206&i=1" target="_top" rel="nofollow">gdr@...</a>> writes:
<br>|
<br>| > Hi Camm --
<br>| >
<br>| > It is "safe" for a C function linked into GCL image to call fork()?
<br>| >
<br>| > Thanks,
<br>| >
<br>|
<br>| In general, yes. This is used already in several places, esp. cvs
<br>| head.
<br>|
<br>| Please keep in mind that fork usually uses copy on write pages, so
<br>| that if you gc in the child, you will page out and copy basically the
<br>| entire heap.
<br><br>OK, many thanks for th info.
<br><br>-- Gaby
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26859206&i=2" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26856312Re: GCL and the fork system call2009-12-19T08:15:46Z2009-12-19T08:15:46ZCamm Maguire-2Greetings!
<br><br>Gabriel Dos Reis <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26856312&i=0" target="_top" rel="nofollow">gdr@...</a>> writes:
<br><br>> Hi Camm --
<br>>
<br>> It is "safe" for a C function linked into GCL image to call fork()?
<br>>
<br>> Thanks,
<br>>
<br><br>In general, yes. This is used already in several places, esp. cvs
<br>head.
<br><br>Please keep in mind that fork usually uses copy on write pages, so
<br>that if you gc in the child, you will page out and copy basically the
<br>entire heap.
<br><br>Take care,
<br><div class='shrinkable-quote'><br>> -- Gaby
<br>>
<br>>
<br>> _______________________________________________
<br>> Gcl-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26856312&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br>> <a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br>>
<br>>
<br>>
<br>>
</div><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26856312&i=2" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26856312&i=3" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26849472GCL and the fork system call2009-12-18T12:43:03Z2009-12-18T12:43:03ZGabriel Dos ReisHi Camm --
<br><br> It is "safe" for a C function linked into GCL image to call fork()?
<br><br>Thanks,
<br><br>-- Gaby
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26849472&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26832587Ownership (or assignment) of GCL test code2009-12-17T10:18:06Z2009-12-17T10:18:06ZAidan Kehoe<br>Hi there --
<br><br>I’m doing some XEmacs work, and I’d like to use the GCL test code, e.g.
<br>here: <a href="http://mid.gmane.org/19190.54586.784516.19228@parhasard.net" target="_top" rel="nofollow">http://mid.gmane.org/19190.54586.784516.19228@...</a><br><br>There’s no informationa about who owns the copyright of GCL, and there’s no
<br>copyright notice in the particular file with the tests I’d like to use. Do
<br>you happen to have this information? If not, where can I get it?
<br><br>Best,
<br><br>Aidan Kehoe
<br><br><br>--
<br>“Apart from the nine-banded armadillo, man is the only natural host of
<br>Mycobacterium leprae, although it can be grown in the footpads of mice.”
<br> -- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26832587&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26796252Re: Bug in mpz_get_d2009-12-15T06:49:39Z2009-12-15T06:49:39ZCamm Maguire-2Paul Zimmermann <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26796252&i=0" target="_top" rel="nofollow">Paul.Zimmermann@...</a>> writes:
<br><br>>> Please stop writing verbose message with kilobytes of irrelevant copied
<br>>> text. This is a bugs mailing list and not a dicussion forum. After
<br>>> many long messages, we have yet to see evidence that there is any bug in
<br>>> GMP, just evidence of poor reading of documentation, and possibly poor
<br>>> understanding of IEEE 754.
<br>>
<br><br>Please accept my apologies. You are correct. I did read and
<br>understand the documentation. I did not correctly understand the
<br>implications of the rounding algorithm.
<br><div class='shrinkable-quote'><br>> here is a tentative to close that issue.
<br>>
<br>> Summary: for input a = 2^1000-1 = 10715086071862673...375, mpz_get_d(a) gives
<br>> 1.0715086071862672E301, whereas Camm Maguire expected 1.0715086071862673E301.
<br>>
<br>> Explanation:
<br>> 1) as said in the documentation, mpz_get_d truncates its input, thus 2^1000-1
<br>> is truncated to d = 2^1000-2^947, which is the largest 53-bit floating-point
<br>> number less or equal to a. We have d = 10715086071862672[0]...048.
<br>> 2) when printed to 17 figures, d is rounded to nearest, which gives
<br>> 1.0715086071862672E301.
<br>>
<br>> (Remember that double-precision floating-point numbers are stored in binary.)
<br>>
<br>> Thus I see no bug.
<br>>
</div><br>You are right. Again, my apologies. I did not see at first blush how
<br>rounding toward zero in one base could result in an error of more than
<br>one least significant digit in another base, but it is clearly true.
<br><br><br>Take care, and thanks for your work on GMP.
<br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26796252&i=1" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26796252&i=2" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26788539Re: Apology (was: Bug in mpz_get_d)2009-12-14T18:41:58Z2009-12-14T18:41:58ZEnrique Perez-TerronOn Mon, 2009-12-14 at 15:11 +0100, Torbjorn Granlund wrote:
<br><br>> Please explain what you get and what you expect. *One* example of
<br>> incorrect+correct data is what we need.
<br><br>I aplolgise that I did not check the list of recipients more carefully.
<br>I meant to follow up to the Gcl-devel list, and was not aware that
<br>the parent post already had added gmp-bugs to the recipients. Reporting
<br>a bug to Gmp was mentioned as an option later in the thread, and I am
<br>confused to find that the original poster had already done so.
<br><br>> Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788539&i=0" target="_top" rel="nofollow">enrio@...</a>> writes:
<br>>
<br>> If stability is desired, mpfr is the one to use. GMP does not aim at
<br>> stability, as far as I understand.
<br>>
<br>> You misunderstand. GMP very much aims at stability.
<br><br>You are right. Mpfr adds the option to specify the rounding policy.
<br>That does not mean that Gmp's rounding is unpredictable. My thinking
<br>and my choice of words were inexact.
<br><br>Gmp seems to round toward zero, rather than to nearest. I appreciate
<br>that users of a package like Gmp normally should set the required
<br>precision to suits their needs with a reasonable margin, and not get
<br>hurt if the rounding is another than the canonical one.
<br><br>Different application areas require different rounding policies, and
<br>rounding to zero is not unreasonable, especially if it is faster.
<br><br>Now lisp is an application area independent tool, and it has this
<br>(float) command that converts to a hardware-supported floating point
<br>type. I suppose rounding to nearest is the least surprising to users of
<br>such general software. I suppose there is some cost to this rounding,
<br>but suspect this natural trade-off tips in favor of agreeing with the
<br>canonical rounding.
<br><br>For the benefit of the CC-ed list readers, I add some explanatory
<br>remarks.
<br><br>In the test data used by the OP, the value of "a" happens to be
<br><br> a == 2^1000 - 1.
<br><br>In a binary representation, this is a 1000-bit field with all ones.
<br>Adding one to this number produces a 1001-bit field with a leading one
<br>and a thousand zeros. One can expect rounding policy transitions to
<br>happen here.
<br><br>The "standard" floating-point format splits a 64-bit field in three
<br>areas (s,e,m) of 1, 11, and 52 bits respectively. If these fields are
<br>thought as containing unsigned integers s,e,m, the value of the number
<br>represented is normally
<br><br> (-1)^s * 2^(e - 1023) * ( 1 + m/2^52 ).
<br><br>This gives a choice between representing "a" as
<br><br> 2^1000 (with an "m" part that is all zeros)
<br><br>or
<br><br> 2^1000 - 2^947 (with an "m" part that is all ones)
<br><br>It appears that Gmp truncates the '1's in the binary representation of
<br>"a" that do not fit in the "m" field. This is rounding toward zero, and
<br>chooses the second alternative above.
<br><br>The leading 20 digits of the number 2^1000 - 2^947 in a decimal
<br>representation are
<br><br> 1071 5086 0718 6267 2019
<br><br>The leading 20 digits of the number 2^1000 in a decimal representation
<br>are
<br><br> 1071 5086 0718 6267 3209
<br><br>These are the digits that show in the printout from the OP's post and
<br>from my little test program. This explains the differences in the
<br>outputs as effects of rounding.
<br><br>The Mpfr library has an additional parameter to its functions, that
<br>specifies the desired rounding policy. In the test program I used
<br>rounding to nearest and got for 2^1000 - 1, 2^1000 rather than 2^1000 -
<br>2^947.
<br><br>-Enrique
<br><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788539&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26788315Re: Bug in mpz_get_d2009-12-14T18:08:39Z2009-12-14T18:08:39ZCamm Maguire-2Greetings!
<br><br>Torbjorn Granlund <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788315&i=0" target="_top" rel="nofollow">tg@...</a>> writes:
<br><br>> Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788315&i=1" target="_top" rel="nofollow">enrio@...</a>> writes:
<br>>
<br>> If stability is desired, mpfr is the one to use. GMP does not aim at
<br>> stability, as far as I understand.
<br>>
<br>> You misunderstand. GMP very much aims at stability.
<br>>
<br><br>Whew! Thanks!
<br><br>> --
<br>> Torbjörn
<br>>
<br>>
<br>>
<br>>
<br><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788315&i=2" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788315&i=3" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26788312Re: Bug in mpz_get_d2009-12-14T18:08:22Z2009-12-14T18:08:22ZCamm Maguire-2Greetings!
<br><br>Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788312&i=0" target="_top" rel="nofollow">enrio@...</a>> writes:
<br><div class='shrinkable-quote'><br>> On Mon, 2009-12-14 at 04:23 +0100, Enrique Perez-Terron wrote:
<br>>> On Fri, 2009-12-11 at 15:12 -0500, Camm Maguire wrote:
<br>> [snip]
<br>>> > >(float a)
<br>>> >
<br>>> > 1.0715086071862672E301
<br>>> >
<br>>> > >(float (1+ a))
<br>>> >
<br>>> > 1.0715086071862673E301
<br>>
<br>> But there is just one bit of difference:
<br>>
<br>> 7e6fffffffffffff
<br>> 7e70000000000000
<br>>
</div><br>Yes, but all integers input should begin with the last bit pattern,
<br>no? All are greater than ....73.
<br><br>> (double, high address byte printed first on x86)
<br>>
<br>> If stability is desired, mpfr is the one to use. GMP does not aim at
<br>> stability, as far as I understand. mpfr is specifically "sold" as GMP
<br>> with correct rounding, even if it has grown beyond that.
<br>>
<br><br>????
<br><br>Take care,
<br><br>> -Enrique
<br>>
<br>>
<br>>
<br>>
<br>>
<br><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788312&i=1" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788312&i=2" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26788289Re: Bug in mpz_get_d2009-12-14T18:06:40Z2009-12-14T18:06:40ZCamm Maguire-2Greetings, and thanks for your reply!
<br><br>Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788289&i=0" target="_top" rel="nofollow">enrio@...</a>> writes:
<br><div class='shrinkable-quote'><br>> On Fri, 2009-12-11 at 15:12 -0500, Camm Maguire wrote:
<br>>> Greetings! Workaround?
<br>>>
<br>>> >(setq a (numerator **))
<br>>>
<br>>> 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069375
<br>>>
<br>>> >(float a)
<br>>>
<br>>> 1.0715086071862672E301
<br>>>
<br>>> >(float (1+ a))
<br>>>
<br>>> 1.0715086071862673E301
<br>>>
<br>>> >(float (1- a))
<br>>>
<br>>> 1.0715086071862672E301
</div> ^
<br> This is the problem. Even rounding toward 0 at
<br> all times this should be ....673 from the digit
<br> string above. This is presuming that rounding
<br> toward zero in any base should not produce a number
<br> lower by more than one least significant digit in
<br> any other base. (true?)
<br><div class='shrinkable-quote'><br>>
<br>> Testing GMP and MPFR directly
<br>> $ ./test-gmp
<br>> Using GMP and mpf_get_d:
<br>> ================
<br>> num = 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069375
<br>> 1.071508607186267202E+301
<br>>
<br>> 1 + num = 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376
<br>> 1.0715086071862673209E+301
<br>>
<br>> 1 - num = -10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069374
<br>> -1.071508607186267202E+301
<br>>
</div><br>(in lisp (1- a) = a - 1, so the sign issue is correct here).
<br><div class='shrinkable-quote'><br>>
<br>> Using MPFR:
<br>> ==================
<br>>
<br>> Num = 1.0715086071862673209E+301
<br>>
<br>> 1 + num = 1.0715086071862673209E+301
<br>>
<br>> 1 - num = -1.0715086071862673209E+301
<br>>
<br>> I don't know why float(1-a) turned positive.
<br>>
<br>> It is easy to miss that there is one correct and two wrong digit
<br>> strings, not the other way around.
<br>> Numbers ending in 7202 are the wrong ones, correct ending is 73209.
<br>>
</div><br>This was my thought -- do you agree that the mpz_get_d algorithm should
<br>produce at least 73?
<br><br>I have a temporary ugly workaround which calls mpz_get_str, and sscanf
<br>for big integers, which is working for now, but clearly less than
<br>optimal.
<br><br><br>> Gcl already links with mpfr, no?
<br>>
<br><br>Alas, no. We just use mpz. For now at least.
<br><br>Many thanks for the below!!!
<br><br>Take care,
<br><div class='shrinkable-quote'><br>> Below is the C code. Compile with -lmpfr -lgmp.
<br>> -Enrique
<br>> ------------------------8<-----------------------------
<br>> #include <stdio.h>
<br>> #include <gmp.h>
<br>> #include <mpfr.h>
<br>>
<br>> char *mynum = "10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069375";
<br>>
<br>> main ()
<br>> {
<br>> printf("Using GMP and mpf_get_d:\n================\n");
<br>> mpz_t num;
<br>> mpz_init_set_str(num, mynum, 10);
<br>> printf("num = ");
<br>> mpz_out_str(stdout, 10, num);
<br>> putchar('\n');
<br>>
<br>> mpf_t myfloat;
<br>> mpf_init(myfloat);
<br>> mpf_set_z(myfloat, num);
<br>> printf("%-29.20lG\n\n", mpf_get_d(myfloat));
<br>>
<br>> mpz_t other;
<br>> mpz_init_set_str(other, "1", 10);
<br>> mpz_add(other, other, num);
<br>> printf("1 + num = ");
<br>> mpz_out_str(stdout, 10, other);
<br>> putchar('\n');
<br>>
<br>> mpf_set_z(myfloat, other);
<br>> printf("%-29.20lG\n\n", mpf_get_d(myfloat));
<br>>
<br>> mpz_set_ui(other, 1);
<br>> mpz_sub(other, other, num);
<br>> printf("1 - num = ");
<br>> mpz_out_str(stdout, 10, other);
<br>> putchar('\n');
<br>>
<br>> mpf_set_z(myfloat, other);
<br>> printf("%-29.20lG\n", mpf_get_d(myfloat));
<br>>
<br>> printf("\n\nUsing MPFR:\n==================\n\n");
<br>> mpfr_t mpfr;
<br>> mpfr_init(mpfr);
<br>> printf("Num = ");
<br>> mpfr_set_z(mpfr, num, GMP_RNDN);
<br>> printf("%-29.20lG\n\n", mpfr_get_d(mpfr, GMP_RNDN));
<br>>
<br>> mpz_set_ui(other, 1);
<br>> mpz_add(other, other, num);
<br>> printf("1 + num = ");
<br>>
<br>> mpfr_set_z(mpfr, other, GMP_RNDN);
<br>> printf("%-29.20lG\n\n", mpfr_get_d(mpfr, GMP_RNDN));
<br>>
<br>> mpz_set_ui(other, 1);
<br>> mpz_sub(other, other, num);
<br>> printf("1 - num = ");
<br>> mpfr_set_z(mpfr, other, GMP_RNDN);
<br>> printf("%-29.20lG\n", mpfr_get_d(mpfr, GMP_RNDN));
<br>>
<br>> }
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
</div><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788289&i=1" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26788289&i=2" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26778370Re: Bug in mpz_get_d2009-12-14T06:11:26Z2009-12-14T06:11:26ZTorbjorn Granlund-6Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26778370&i=0" target="_top" rel="nofollow">enrio@...</a>> writes:
<br><br> If stability is desired, mpfr is the one to use. GMP does not aim at
<br> stability, as far as I understand.
<br><br>You misunderstand. GMP very much aims at stability.
<br><br>--
<br>Torbjörn
<br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26778370&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26777740[CfP] ELS 20102009-12-14T05:26:37Z2009-12-14T05:26:37ZPascal Costanza 3rd European Lisp Symposium
<br> ===========================
<br> <<a href="http://www.european-lisp-symposium.org" target="_top" rel="nofollow">http://www.european-lisp-symposium.org</a>>
<br><br><br>May 6-7, 2010, Fundacao Calouste Gulbenkian, Lisbon, Portugal
<br><br>Important Dates
<br>~~~~~~~~~~~~~~~~
<br> + Submission Deadline: *January 29, 2010*
<br> + Author Notification: March 1, 2010
<br> + Final Paper Due: March 26, 2010
<br> + Symposium: *May 6-7, 2010*
<br><br> We hope, as in previous years, to invite authors of accepted
<br> research contributions to submit an extended version of their papers
<br> to a special issue of the Journal of Universal Computer Science
<br> (J.UCS).
<br><br>Scope
<br>~~~~~~
<br> The purpose of the European Lisp Symposium is to provide a forum
<br> for the discussion and dissemination of all aspects of design,
<br> implementation and application of any of the Lisp dialects. We
<br> encourage everyone interested in Lisp to participate.
<br><br> The European Lisp Symposium 2010 invites high quality papers about
<br> novel research results, insights and lessons learned from practical
<br> applications, and educational perspectives, all involving Lisp
<br> dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp,
<br> ISLISP, Dylan, Clojure, and so on.
<br><br> Topics include, but are not limited to:
<br> + Language design and implementation
<br> + Language integration, interoperation and deployment
<br> + Development methodologies, support and environments
<br> + Reflection, protocols and meta-level architectures
<br> + Lisp in Education
<br> + Parallel, distributed and scientific computing
<br> + Large and ultra-large-scale systems
<br> + Hardware, virtual machine and embedded applications
<br> + Domain-oriented programming
<br> + Lisp pearls
<br> + Experience reports and case studies
<br><br> We invite submissions (through EasyChair) in two categories:
<br> original contributions and tutorials.
<br><br> * Original contributions should neither have been published
<br> previously nor be under review in any other refereed events or
<br> publication. Research papers should describe work that advances
<br> the current state of the art, or presents old results from a new
<br> perspective. Experience papers should be of broad interest and
<br> should describe insights gained from substantive practical
<br> applications. The programme committee will evaluate each
<br> contributed paper based on its relevance, significance, clarity,
<br> and originality.
<br><br> * Tutorial submissions should be extended abstracts of up to four
<br> pages for in-depth presentations about topics of special interest
<br> for at least 90 minutes and up to 180 minutes. The programme
<br> committee will evaluate tutorial proposals based on the likely
<br> interest in the topic matter, the clarity of the presentation in
<br> the extended abstract, and the scope for interactive
<br> participation.
<br><br> The tutorials will run during the symposium on May 6, 2010.
<br><br>Programme Chair
<br>~~~~~~~~~~~~~~~~
<br> Christophe Rhodes, Goldsmiths, University of London, UK
<br><br>Local Chair
<br>~~~~~~~~~~~~
<br> Antonio Leitao, Technical University of Lisbon, Portugal
<br><br>Programme Committee
<br>~~~~~~~~~~~~~~~~~~~~
<br> + Marco Antoniotti, Universita Milano Bicocca, Italy
<br> + Giuseppe Attardi, Universita di Pisa, Italy
<br> + Pascal Costanza, Vrije Universiteit Brussel, Belgium
<br> + Irene Anne Durand, Universite Bordeaux I, France
<br> + Marc Feeley, Universite de Montreal, Canada
<br> + Ron Garret, Amalgamated Widgets Unlimited, USA
<br> + Gregor Kiczales, University of British Columbia, Canada
<br> + Nick Levine, Ravenbrook Ltd, UK
<br> + Scott McKay, ITA Software, Inc., USA
<br> + Peter Norvig, Google Inc., USA
<br> + Kent Pitman, PTC, USA
<br> + Christian Queinnec, Universite Pierre et Marie Curie, France
<br> + Robert Strandh, Universite Bordeaux I, France
<br> + Didier Verna, EPITA Research and Development Laboratory, France
<br> + Barry Wilkes, Citi, UK
<br> + Taiichi Yuasa, Kyoto University, Japan
<br><br><br>--
<br>Pascal Costanza, mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26777740&i=0" target="_top" rel="nofollow">pc@...</a>, <a href="http://p-cos.net" target="_top" rel="nofollow">http://p-cos.net</a><br>Vrije Universiteit Brussel
<br>Software Languages Lab
<br>Pleinlaan 2, B-1050 Brussel, Belgium
<br><br><br><br><br><br><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26777740&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26775223Re: Bug in mpz_get_d2009-12-14T01:41:58Z2009-12-14T01:41:58ZEnrique Perez-TerronOn Mon, 2009-12-14 at 04:23 +0100, Enrique Perez-Terron wrote:
<br>> On Fri, 2009-12-11 at 15:12 -0500, Camm Maguire wrote:
<br>[snip]
<br>> > >(float a)
<br>> >
<br>> > 1.0715086071862672E301
<br>> >
<br>> > >(float (1+ a))
<br>> >
<br>> > 1.0715086071862673E301
<br><br>But there is just one bit of difference:
<br><br>7e6fffffffffffff
<br>7e70000000000000
<br><br>(double, high address byte printed first on x86)
<br><br>If stability is desired, mpfr is the one to use. GMP does not aim at
<br>stability, as far as I understand. mpfr is specifically "sold" as GMP
<br>with correct rounding, even if it has grown beyond that.
<br><br>-Enrique
<br><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26775223&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26772497Re: Bug in mpz_get_d2009-12-13T19:23:03Z2009-12-13T19:23:03ZEnrique Perez-TerronOn Fri, 2009-12-11 at 15:12 -0500, Camm Maguire wrote:
<div class='shrinkable-quote'><br>> Greetings! Workaround?
<br>>
<br>> >(setq a (numerator **))
<br>>
<br>> 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069375
<br>>
<br>> >(float a)
<br>>
<br>> 1.0715086071862672E301
<br>>
<br>> >(float (1+ a))
<br>>
<br>> 1.0715086071862673E301
<br>>
<br>> >(float (1- a))
<br>>
<br>> 1.0715086071862672E301
</div><br>Testing GMP and MPFR directly
<br>$ ./test-gmp
<br>Using GMP and mpf_get_d:
<br>================
<br>num = 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069375
<br>1.071508607186267202E+301
<br><br>1 + num = 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376
<br>1.0715086071862673209E+301
<br><br>1 - num = -10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069374
<br>-1.071508607186267202E+301
<br><br><br>Using MPFR:
<br>==================
<br><br>Num = 1.0715086071862673209E+301
<br><br>1 + num = 1.0715086071862673209E+301
<br><br>1 - num = -1.0715086071862673209E+301
<br><br>I don't know why float(1-a) turned positive.
<br><br>It is easy to miss that there is one correct and two wrong digit
<br>strings, not the other way around.
<br>Numbers ending in 7202 are the wrong ones, correct ending is 73209.
<br><br>Gcl already links with mpfr, no?
<br><br>Below is the C code. Compile with -lmpfr -lgmp.
<br>-Enrique
<br>------------------------8<-----------------------------
<br>#include <stdio.h>
<br>#include <gmp.h>
<br>#include <mpfr.h>
<br><br>char *mynum = "10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069375";
<br><br>main ()
<br>{
<br> printf("Using GMP and mpf_get_d:\n================\n");
<br> mpz_t num;
<br> mpz_init_set_str(num, mynum, 10);
<br> printf("num = ");
<br> mpz_out_str(stdout, 10, num);
<br> putchar('\n');
<br><br> mpf_t myfloat;
<br> mpf_init(myfloat);
<br> mpf_set_z(myfloat, num);
<br> printf("%-29.20lG\n\n", mpf_get_d(myfloat));
<br><br> mpz_t other;
<br> mpz_init_set_str(other, "1", 10);
<br> mpz_add(other, other, num);
<br> printf("1 + num = ");
<br> mpz_out_str(stdout, 10, other);
<br> putchar('\n');
<br><br> mpf_set_z(myfloat, other);
<br> printf("%-29.20lG\n\n", mpf_get_d(myfloat));
<br><br> mpz_set_ui(other, 1);
<br> mpz_sub(other, other, num);
<br> printf("1 - num = ");
<br> mpz_out_str(stdout, 10, other);
<br> putchar('\n');
<br><br> mpf_set_z(myfloat, other);
<br> printf("%-29.20lG\n", mpf_get_d(myfloat));
<br><br> printf("\n\nUsing MPFR:\n==================\n\n");
<br> mpfr_t mpfr;
<br> mpfr_init(mpfr);
<br> printf("Num = ");
<br> mpfr_set_z(mpfr, num, GMP_RNDN);
<br> printf("%-29.20lG\n\n", mpfr_get_d(mpfr, GMP_RNDN));
<br><br> mpz_set_ui(other, 1);
<br> mpz_add(other, other, num);
<br> printf("1 + num = ");
<br><br> mpfr_set_z(mpfr, other, GMP_RNDN);
<br> printf("%-29.20lG\n\n", mpfr_get_d(mpfr, GMP_RNDN));
<br><br> mpz_set_ui(other, 1);
<br> mpz_sub(other, other, num);
<br> printf("1 - num = ");
<br> mpfr_set_z(mpfr, other, GMP_RNDN);
<br> printf("%-29.20lG\n", mpfr_get_d(mpfr, GMP_RNDN));
<br><br>}
<br><br><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26772497&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26763095Re: strict aliasing2009-12-12T18:26:16Z2009-12-12T18:26:16ZGabriel Dos ReisOn Fri, Dec 11, 2009 at 3:19 PM, Camm Maguire <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26763095&i=0" target="_top" rel="nofollow">camm@...</a>> wrote:
<div class='shrinkable-quote'><br>> Greetings!
<br>>
<br>> Leo Butler <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26763095&i=1" target="_top" rel="nofollow">l.butler@...</a>> writes:
<br>>
<br>>> On Fri, 11 Dec 2009, Camm Maguire wrote:
<br>>>
<br>>> < Greetings! OK just fixd the GCL bugs, which result in some of the
<br>>> < maxima bugs, and am ready for upload.
<br>>> <
<br>>> < There are new gcc warnings, which I always like to clear up. Perhaps
<br>>> < you might help by figuring out the currently blessed way of writing
<br>>> < the following:
<br>>> <
<br>>> < #define GET_FAULT_ADDR(sig,code,sv,a) \
<br>>> < ((void *)(((struct sigcontext *)(&code))->cr2))
<br>>> < #endif
<br>>> <
<br>>> < sgbc.c: In function 'memprotect_handler':
<br>>> < sgbc.c:1620: warning: dereferencing pointer 'code.636' does break strict-aliasing rules
<br>>> < sgbc.c:1620: note: initialized from here
<br>>>
<br>>> Camm, if I understand strict-aliasing [*] then the problem is that your macro is casting a
<br>>> (void *) while on line 1620, faddr is a (char *).
<br>>>
<br>>> If you change your macro to cast a (char *), then this should fix this problem. Again,
<br>>> from the above article, (char *) may refer to an alias of any object, so this should
<br>>> not introduce any additional breakages of the strict aliasing rules.
</div><br>There is no issue with aliasing if you access a memory storage as
<br>'char *' -- the C sandard explicitly says it is OK.
<br><br>-- Gaby
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26763095&i=2" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26768373mpz_get_d2009-12-12T12:53:18Z2009-12-12T12:53:18ZCamm Maguire-2<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26768373&i=0" target="_top" rel="nofollow">gmp-bugs-owner@...</a> writes:
<br><div class='shrinkable-quote'><br>> Camm Maguire <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26768373&i=1" target="_top" rel="nofollow">camm@...</a>> writes:
<br>>
<br>> Greetings! It was so intended. Is this not the right forum? If the
<br>> objection is due to the GCL interface, I can repost the precise call
<br>> to mpz_get_d from within gdb if needed. It is a straight pass
<br>> through.
<br>>
<br>> If you want to report a GMP bug, we need a GMP test case. Please see
<br>> the manual section on how to report bugs.
<br>>
<br>>
</div><br>Greetings! OK, before I do, is mpz_get_d supposed to return identical
<br>doubles for integers that are equal within the precision of the
<br>mantissa, or is this not guaranteed by the implementation? If the
<br>latter, I'll just find some work around.
<br><br>Take care,
<br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26768373&i=2" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26768373&i=3" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26751613strict aliasing2009-12-11T13:19:39Z2009-12-11T13:19:39ZCamm Maguire-2Greetings!
<br><br>Leo Butler <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751613&i=0" target="_top" rel="nofollow">l.butler@...</a>> writes:
<br><div class='shrinkable-quote'><br>> On Fri, 11 Dec 2009, Camm Maguire wrote:
<br>>
<br>> < Greetings! OK just fixd the GCL bugs, which result in some of the
<br>> < maxima bugs, and am ready for upload.
<br>> <
<br>> < There are new gcc warnings, which I always like to clear up. Perhaps
<br>> < you might help by figuring out the currently blessed way of writing
<br>> < the following:
<br>> <
<br>> < #define GET_FAULT_ADDR(sig,code,sv,a) \
<br>> < ((void *)(((struct sigcontext *)(&code))->cr2))
<br>> < #endif
<br>> <
<br>> < sgbc.c: In function 'memprotect_handler':
<br>> < sgbc.c:1620: warning: dereferencing pointer 'code.636' does break strict-aliasing rules
<br>> < sgbc.c:1620: note: initialized from here
<br>>
<br>> Camm, if I understand strict-aliasing [*] then the problem is that your macro is casting a
<br>> (void *) while on line 1620, faddr is a (char *).
<br>>
<br>> If you change your macro to cast a (char *), then this should fix this problem. Again,
<br>> from the above article, (char *) may refer to an alias of any object, so this should
<br>> not introduce any additional breakages of the strict aliasing rules.
<br>>
</div><br>Alas, this does not work:
<br><br>camm@localhost:~/debian/gcl/gcl-2.6.8pre/o$ rm gbc.o; make gbc.o
<br>gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer -I/home/camm/debian/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk gbc.c
<br>In file included from gbc.c:1508:
<br>sgbc.c: In function 'memprotect_handler':
<br>sgbc.c:1620: warning: dereferencing pointer 'code.636' does break strict-aliasing rules
<br>sgbc.c:1620: note: initialized from here
<br>sgbc.c: In function 'memprotect_handler_test':
<br>sgbc.c:1098: warning: dereferencing pointer 'code.547' does break strict-aliasing rules
<br>sgbc.c:1098: note: initialized from here
<br>camm@localhost:~/debian/gcl/gcl-2.6.8pre/o$ cpp -I../h gbc.c |grep code
<br> faddr=((char *)(((struct sigcontext *)(&code))->cr2));
<br><br>The problem apparently lies with the sigcontext.
<br><br>> Are your fixes available from CVS, and if so, where?
<br>>
<br><br>Yes, cvs -d :pserver:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751613&i=1" target="_top" rel="nofollow">anonymous@...</a>:/sources/gcl -r
<br>Version_2_6_8pre co -d gcl-2.6.8pre gcl
<br><br>BTW, I have a maxima 5.20 build which I might upload now. GCL is
<br>uploaded. There are a few issues -- two test failures due to a double
<br>conversion error in GMP. See <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751613&i=2" target="_top" rel="nofollow">gcl-devel@...</a> archives if interested
<br>or if have workaround suggestions.
<br><br>Take care,
<br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751613&i=3" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751613&i=4" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26751511[(nowhere)] Request to mailing list gmp-bugs rejected2009-12-11T13:10:51Z2009-12-11T13:10:51ZCamm Maguire-2following reason for rejecting your request:
<br><br>"One copy is enough.
<br><br>Surely this is not intended as a bug report for GMP?"
<br><br>Any questions or comments should be directed to the list administrator
<br>at:
<br><br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751511&i=0" target="_top" rel="nofollow">gmp-bugs-owner@...</a>
<br><br><br>Greetings! It was so intended. Is this not the right forum? If the
<br>objection is due to the GCL interface, I can repost the precise call
<br>to mpz_get_d from within gdb if needed. It is a straight pass
<br>through.
<br><br>Take care,
<br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751511&i=1" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26751511&i=2" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26750868Bug in mpz_get_d2009-12-11T12:12:59Z2009-12-11T12:12:59ZCamm Maguire-2Greetings! Workaround?
<br><br>>(setq a (numerator **))
<br><br>10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069375
<br><br>>(float a)
<br><br>1.0715086071862672E301
<br><br>>(float (1+ a))
<br><br>1.0715086071862673E301
<br><br>>(float (1- a))
<br><br>1.0715086071862672E301
<br><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26750868&i=0" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26750868&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26704428gcl (lisp) won't compile (is this the right place for newby problems?)2009-12-08T19:01:03Z2009-12-08T19:01:03Z625DRIf this is the wrong place to ask for support, could you tell me where to ask, and sorry for bothering you.
<br><br>I've installed GCL-2.6.6-ANSI on Windows Vista from binaries, and the interpreter works, but compiling doesn't. This is copied from the console:
<br><br>C:\Lisp>gcl -batch -load hello1.lisp
<br>'gcl' is not recognized as an internal or external command,
<br>operable program or batch file.
<br><br>I've had a look in the Windows Environment Variables and can't see any reference to lisp.
<br>MinGW is installed and should be OK, as gcc compiles C alright.
<br><br>Would appreciate any help.
<br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-26580783PLT patch for GNU ld >= 2.192009-11-30T11:27:57Z2009-11-30T11:27:57ZJerry James-3I recently received this bug report:
<br><br><a href="https://bugzilla.redhat.com/show_bug.cgi?id=542004" target="_top" rel="nofollow">https://bugzilla.redhat.com/show_bug.cgi?id=542004</a><br><br>The patch included in that bug report is to be applied on top of the
<br>PLT patch I sent earlier. I'll attach a patch to this message that
<br>applies directly to current 2.6.8-pre.
<br><br>Regards,
<br>--
<br>Jerry James
<br><a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br><br /> <br />_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26580783&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>gcl-2.6.8-plt.patch</strong> (2K) <a href="http://old.nabble.com/attachment/26580783/0/gcl-2.6.8-plt.patch" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25877399Re: Re: [TeXmacs] A rewrite of tm_axiom.c (attached)2009-10-13T10:35:19Z2009-10-13T10:35:19ZEnrique Perez-TerronOn Mon, 2009-10-12 at 19:56 -0500, Gabriel Dos Reis wrote:
<div class='shrinkable-quote'><br>> Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25877399&i=0" target="_top" rel="nofollow">enrio@...</a>> writes:
<br>>
<br>> | I have just downloaded open-axiom-1.3.0.tar.bz2, and attempted to build
<br>> | it using the standard installed gcl from Fedora 11.
<br>> |
<br>> | I think the builders of Fedora-11 downloaded a CVS snapshot of gcl on
<br>> | some date... Yes, here it is, in their gcl.spec:
<br>> |
<br>> | # The source for this package was pulled from upstream's CVS repository. Use
<br>> | # the following commands to generate the tarball:
<br>> | # cvs -d:pserver:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25877399&i=1" target="_top" rel="nofollow">anonymous@...</a>:/sources/gcl export \
<br>> | # -r Version_2_6_8pre -D 2009-03-04 -d gcl-2.6.8 gcl
<br>> | # tar -cjvf gcl-2.6.8.tar.bz2 gcl-2.6.8
<br>> |
<br>> | But the code quoted below is not different in the cvs snapshot I myself
<br>> | downloaded (without version and date restricting options) on 2009-10-07.
<br>> | (There are differences in other parts of plt.c and fasdump.c.)
<br>>
<br>> Dear Enrique,
<br>>
<br>> something wasn't clear to me from your description:
<br>>
<br>> (1) can you build OpenAxiom with the standard installed GCL on
<br>> Fedora 11?
</div><br>No. Jerry James has sent two patches relative to the Fedora-11 gcl, that
<br>I will now try out.
<br><br>> (2) can you build OpenAxiom with your own version?
<br><br>I'm working on that.
<br><br>Regards, Enrique
<br><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25877399&i=2" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25877080Re: Ellipsis patch2009-10-13T10:03:58Z2009-10-13T10:03:58ZGabriel Dos Reis-2Jerry James <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25877080&i=0" target="_top" rel="nofollow">loganjerry@...</a>> writes:
<br><br>| I can't remember if I sent this one before or not. GCC complains
<br>| about undefined behavior when a varargs function's last non-varargs
<br>| parameter is declared to have storage class register. Since varargs
<br>| works by taking the address of that parameter, and register is a
<br>| promise to never take the address of a variable, the two conflict.
<br>| This patch fixes the issue.
<br><br>They look OK to me.
<br><br>-- Gaby
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25877080&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25876416Ellipsis patch2009-10-13T09:36:13Z2009-10-13T09:36:13ZJerry James-3I can't remember if I sent this one before or not. GCC complains
<br>about undefined behavior when a varargs function's last non-varargs
<br>parameter is declared to have storage class register. Since varargs
<br>works by taking the address of that parameter, and register is a
<br>promise to never take the address of a variable, the two conflict.
<br>This patch fixes the issue.
<br><br>diff -dur gcl-2.6.8.ORIG/o/bind.c gcl-2.6.8/o/bind.c
<br>--- gcl-2.6.8.ORIG/o/bind.c 2006-06-21 14:03:05.000000000 -0600
<br>+++ gcl-2.6.8/o/bind.c 2009-08-11 14:11:56.982474159 -0600
<br>@@ -708,7 +708,7 @@
<br> #define NOT_KEYWORD 1
<br><br> void
<br>-parse_key(object *base, bool rest, bool allow_other_keys, register int n, ...)
<br>+parse_key(object *base, bool rest, bool allow_other_keys, int n, ...)
<br> {
<br> object temporary;
<br> va_list ap;
<br>diff -dur gcl-2.6.8.ORIG/o/external_funs.h gcl-2.6.8/o/external_funs.h
<br>--- gcl-2.6.8.ORIG/o/external_funs.h 2003-08-29 14:41:59.000000000 -0600
<br>+++ gcl-2.6.8/o/external_funs.h 2009-08-11 14:17:35.000473249 -0600
<br>@@ -167,8 +167,8 @@
<br> extern object find_special GPR((object body, struct bind_temp *start,
<br>struct bind_temp *end));;
<br> extern object let_bind GPR((object body, struct bind_temp *start,
<br>struct bind_temp *end));;
<br> extern object letA_bind GPR((object body, struct bind_temp *start,
<br>struct bind_temp *end));;
<br>-extern int parse_key GPR((object *base, bool rest, bool
<br>allow_other_keys, register int n, int __builtin_va_alist));;
<br>-extern int check_other_key GPR((object l, int n, int __builtin_va_alist));;
<br>+extern int parse_key GPR((object *base, bool rest, bool
<br>allow_other_keys, int n, ...));;
<br>+extern int check_other_key GPR((object l, int n, ...));;
<br> extern int parse_key_new GPR((int n, object *base, struct key *keys, ...));;
<br> extern int parse_key_rest GPR((object rest, int n, object *base,
<br>struct key *keys, ...));;
<br> extern int set_key_struct GPR((struct key *ks, object data));;
<br>@@ -380,7 +380,6 @@
<br> extern int not_a_variable GPR((int obj));;
<br> extern int illegal_index GPR((object x, object i));;
<br> extern int Lerror GPR((void));;
<br>-extern object LVerror GPR((int __builtin_va_alist));;
<br> extern int Lcerror GPR((void));;
<br> extern int vfun_wrong_number_of_args GPR((object x));;
<br> extern int init_error GPR((void));;
<br>@@ -415,9 +414,6 @@
<br> extern object ifuncall2 GPR((object fun, object arg1, object arg2));;
<br> extern object ifuncall3 GPR((object fun, object arg1, object arg2,
<br>object arg3));;
<br> extern int funcall_with_catcher GPR((object fname, object fun));;
<br>-extern object fcalln_cclosure GPR((...));;
<br>-extern object fcalln_general GPR((...));;
<br>-extern object fcalln_vfun GPR((va_list vl));;
<br>-extern object fcalln GPR((int __builtin_va_alist));;
<br>-extern object funcall_cfun GPR((funcvoid fn, int n, int
<br>__builtin_va_alist));;
<br>+extern object fcalln GPR((object first, ...));;
<br>+extern object funcall_cfun GPR((funcvoid fn, int n, ...));;
<br> extern int init_eval GPR((void));;
<br><br>--
<br>Jerry James
<br><a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25876416&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25876363PLT patch2009-10-13T09:34:03Z2009-10-13T09:34:03ZJerry James-3This is the patch I used to resolve the recent issue with .iplt
<br>sections and compilation of open-axiom:
<br><br>diff -dur gcl-2.6.8.ORIG/o/makefile gcl-2.6.8/o/makefile
<br>--- gcl-2.6.8.ORIG/o/makefile 2009-08-11 15:11:17.769474923 -0600
<br>+++ gcl-2.6.8/o/makefile 2009-08-11 15:11:46.167645473 -0600
<br>@@ -149,7 +149,7 @@
<br> $(CC) -c $(CFLAGS) $(DEFS) $*.c $(AUX_INFO)
<br><br> plt.h: plttest.o
<br>- nm $< | $(AWK) '/ U / {if ($$NF!=2) next;a=$$2;if (k) sub("^_","",a);\
<br>+ nm $< | $(AWK) '/ U / {if (NF!=2) next;a=$$2;if (k) sub("^_","",a);\
<br> print a}' \
<br> k=$(LEADING_UNDERSCORE) |\
<br> sort | \
<br>diff -dur gcl-2.6.8.ORIG/o/plt.c gcl-2.6.8/o/plt.c
<br>--- gcl-2.6.8.ORIG/o/plt.c 2008-08-03 09:16:22.000000000 -0600
<br>+++ gcl-2.6.8/o/plt.c 2009-08-11 15:12:26.627506327 -0600
<br>@@ -135,7 +135,7 @@
<br> for (i=j=0,li=Cnil;fgets(b,sizeof(b),f);) {
<br> if (!memchr(b,10,sizeof(b)-1))
<br> FEerror("plt buffer too small", 0);
<br>- if (memcmp(b," .plt",4) && !i)
<br>+ if ((memcmp(b," .plt",5) || memcmp(b," .iplt",6)) && !i)
<br> continue;
<br> if (*b=='\r' || *b=='\n') {
<br> i=0;
<br><br>--
<br>Jerry James
<br><a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25876363&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25876300Re: Re: [TeXmacs] A rewrite of tm_axiom.c (attached)2009-10-13T09:30:37Z2009-10-13T09:30:37ZJerry James-3On Mon, Oct 12, 2009 at 9:38 PM, Jerry James <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25876300&i=0" target="_top" rel="nofollow">loganjerry@...</a>> wrote:
<br>> The *(.iplt) line didn't use to be present. I found .iplt lines being
<br>> generated when I last built on Fedora Rawhide (soon to be F-12), and
<br>> fixed the problem there. I didn't realize it had shown up in F-11 as
<br>> well. I'll roll a new F-11 package with the iplt fix in it tomorrow.
<br><br>The new package will appear in the updates-testing repository after
<br>the next compose. Here are direct links for the impatient:
<br><br><a href="http://koji.fedoraproject.org/koji/buildinfo?buildID=136447" target="_top" rel="nofollow">http://koji.fedoraproject.org/koji/buildinfo?buildID=136447</a><br><br>Please let me know whether this build resolves the problem. Regards,
<br>--
<br>Jerry James
<br><a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25876300&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25866757Re: Re: [TeXmacs] A rewrite of tm_axiom.c (attached)2009-10-12T20:44:26Z2009-10-12T20:44:26ZJerry James-3On Mon, Oct 12, 2009 at 9:38 PM, Jerry James <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25866757&i=0" target="_top" rel="nofollow">loganjerry@...</a>> wrote:
<br>> I am the Fedora maintainer of gcl. I welcome input on how the gcl
<br>> package should be configured and built.
<br><br>Et cetera. I got bounce messages back from open-axiom-devel and
<br>texmacs-users, both of which appear to be closed lists. If you want
<br>the discussion to continue cross-posted on those lists, it looks like
<br>you'll have to forward my messages there yourself.
<br>--
<br>Jerry James
<br><a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25866757&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25866722Re: Re: [TeXmacs] A rewrite of tm_axiom.c (attached)2009-10-12T20:38:08Z2009-10-12T20:38:08ZJerry James-3On Mon, Oct 12, 2009 at 5:57 PM, Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25866722&i=0" target="_top" rel="nofollow">enrio@...</a>> wrote:
<br>> I have just downloaded open-axiom-1.3.0.tar.bz2, and attempted to build
<br>> it using the standard installed gcl from Fedora 11.
<br><br>I am the Fedora maintainer of gcl. I welcome input on how the gcl
<br>package should be configured and built.
<br><br>> Obviously the program expects the input to have an empty line separating
<br>> distinct parts. Maybe some tool has been changed. Maybe there used to be
<br>> an empty line just before the "*(.iplt)" line, or may be two lines
<br>> containing .iplt have been added in a recent version of the tools that
<br>> generate the map file. I have
<br><br>The *(.iplt) line didn't use to be present. I found .iplt lines being
<br>generated when I last built on Fedora Rawhide (soon to be F-12), and
<br>fixed the problem there. I didn't realize it had shown up in F-11 as
<br>well. I'll roll a new F-11 package with the iplt fix in it tomorrow.
<br><div class='shrinkable-quote'><br>>> GCL (GNU Common Lisp) April 1994 131072 pages
<br>>> Building symbol table for /home/enrique/src/build-oa/src/lisp/raw_lisp ..
<br>>> loading /usr/lib/gcl-2.6.8/unixport/../lsp/gcl_export.lsp
<br>>> Initializing gcl_defmacro.o
<br>>> Can't open file ~s
<br>>> Lisp initialization failed.
<br>>>
<br>>> "lisp"
<br>>>
<br>>> AxiomCore>
<br>>
<br>> I found the following line in the source of gcl, in file o/fasdump.c:
<br>>
<br>>> if (in == Cnil)
<br>>> FEerror("Can't open file ~s",1,d);
<br>>
<br>> I wonder if the string "~s" should have been "%s" ...
</div><br>No, that function takes Lisp formatting strings. See o/error.c. I
<br>don't know why it didn't expand the ~s.
<br>--
<br>Jerry James
<br><a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25866722&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25865594Re: Re: [TeXmacs] A rewrite of tm_axiom.c (attached)2009-10-12T17:56:38Z2009-10-12T17:56:38ZGabriel Dos Reis-2Enrique Perez-Terron <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25865594&i=0" target="_top" rel="nofollow">enrio@...</a>> writes:
<br><br>| I have just downloaded open-axiom-1.3.0.tar.bz2, and attempted to build
<br>| it using the standard installed gcl from Fedora 11.
<br>|
<br>| I think the builders of Fedora-11 downloaded a CVS snapshot of gcl on
<br>| some date... Yes, here it is, in their gcl.spec:
<br>|
<br>| # The source for this package was pulled from upstream's CVS repository. Use
<br>| # the following commands to generate the tarball:
<br>| # cvs -d:pserver:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25865594&i=1" target="_top" rel="nofollow">anonymous@...</a>:/sources/gcl export \
<br>| # -r Version_2_6_8pre -D 2009-03-04 -d gcl-2.6.8 gcl
<br>| # tar -cjvf gcl-2.6.8.tar.bz2 gcl-2.6.8
<br>|
<br>| But the code quoted below is not different in the cvs snapshot I myself
<br>| downloaded (without version and date restricting options) on 2009-10-07.
<br>| (There are differences in other parts of plt.c and fasdump.c.)
<br><br>Dear Enrique,
<br><br> something wasn't clear to me from your description:
<br><br> (1) can you build OpenAxiom with the standard installed GCL on
<br> Fedora 11?
<br><br> (2) can you build OpenAxiom with your own version?
<br><br>Many thanks for our feedback.
<br><br>-- Gaby
<br><br>|
<br>| I am building on Fedora 11, with SELinux disabled:
<br>|
<br>| $ sudo getenforce
<br>| Disabled
<br>|
<br>| Also relevant:
<br>|
<br>| $ ld --version
<br>| GNU ld version 2.19.51.0.14-1.fc11 20090722
<br>| ...
<br>| $ gcc --version
<br>| gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
<br>|
<br>| $ gcl --version
<br>| GCL (GNU Common Lisp) 2.6.8 ANSI Apr 27 2009 12:50:17
<br>| ...
<br>|
<br>| Just in case: (compare the build date)
<br>|
<br>| $ rpm -qi gcl
<br>| Name : gcl Relocations: (not relocatable)
<br>| Version : 2.6.8 Vendor: Fedora Project
<br>| Release : 0.3.20090303cvs.fc11 Build Date: Mon 27 Apr 2009 06:54:29 PM CEST
<br>| ...
<br>|
<br>|
<br>| (The text below was written for a different mailing list, but I decided
<br>| to send to more appropriate lists when I saw what I have written. Bear
<br>| with the excessive details.)
<br>|
<br>| During the build of open-axiom, the following command:
<br>|
<br>| > echo '(let* ((sys-cc compiler::*cc*) ' \
<br>| > ' (sys-ld compiler::*ld*) ' \
<br>| > ' (compiler::*cc* (concatenate (quote string) ' \
<br>| > ' "../../libtool --mode=compile " ' \
<br>| > ' sys-cc)) ' \
<br>| > ' (compiler::*ld* (concatenate (quote string) ' \
<br>| > ' "../../libtool --mode=link " ' \
<br>| > ' sys-ld))) ' \
<br>| > '(compiler::link (quote ("core.o")) "lisp" ' \
<br>| > ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
<br>| > ' (si::*load-types* ~S)))' \
<br>| > ' (when (fboundp (quote si::sgc-on))' \
<br>| > ' (si::sgc-on nil))' \
<br>| > ' (setq si::*top-level-hook* (read-from-string \"|AxiomCore|::|topLevel|\")))"' \
<br>| > ' si::*system-directory* (quote (list ".lsp")))' \
<br>| > ' "./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o ./../../src/lib/sockio-c.o -lutil -lm"))' \
<br>| > | ./base-lisp
<br>|
<br>| fails with the following output:
<br>|
<br>| > GCL (GNU Common Lisp) 2.6.8 ANSI Apr 27 2009 12:50:17
<br>| > Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
<br>| > Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
<br>| > Modifications of this banner must retain notice of a compatible license
<br>| > Dedicated to the memory of W. Schelter
<br>| >
<br>| > Use (help) to get some basic information on how to use GCL.
<br>| > Temporary directory for compiler files set to /tmp/
<br>| >
<br>| > AxiomCore>libtool: compile: gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wall -DVOL=volatile -fsigned-char -pipe -I/usr/lib/gcl-2.6.8/unixport/../h -O2 -fno-strict-aliasing -c ./user-init.c -w -fPIC -DPIC -o ./.libs/user-init.o
<br>| > libtool: compile: gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wall -DVOL=volatile -fsigned-char -pipe -I/usr/lib/gcl-2.6.8/unixport/../h -O2 -fno-strict-aliasing -c ./user-init.c -w -o ./user-init.o >/dev/null 2>&1
<br>| > libtool: link: gcc -o ./raw_lisp ./user-init.o core.o -Wl,-Map ./raw_lisp_map ./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o ./../../src/lib/sockio-c.o -L/usr/lib/gcl-2.6.8/unixport/ -lansi_gcl -lSM -lICE -lXmu -lXt -lXext -lXaw -lX11 -lgmp -lbfd -liberty -lreadline -lncurses -lc -lgclp -lutil -lm
<br>| > GCL (GNU Common Lisp) April 1994 131072 pages
<br>| > Cannot read address
<br>| > Lisp initialization failed.
<br>| >
<br>| > "lisp"
<br>| >
<br>| > AxiomCore>
<br>|
<br>| I am building using the Fedora-11 native gcl. The command "./base-lisp"
<br>| appears to be a version of gcl that has been dumped with some extra
<br>| functions and a modified prompt "AxiomCore", a few lines earlier in the
<br>| build.
<br>|
<br>| I had the same error a few days ago, and I looked at the gcl source to
<br>| find the error message "Cannot read address". I found it in
<br>| gcl-2.6.8/o/plt.c, and it appears that the function parse_plt() *must*
<br>| fail with exactly this message given the input file
<br>| src/lisp/raw_lisp_map (from the open-axiom build tree).
<br>|
<br>| The input file contains:
<br>|
<br>| > Archive member included because of file (symbol)
<br>| >
<br>| > /usr/lib/gcl-2.6.8/unixport//libansi_gcl.a(alloc.o)
<br>| > ./../../src/lib/cfuns-c.o (free)
<br>| > /usr/lib/gcl-2.6.8/unixport//libansi_gcl.a(cmpaux.o)
<br>| > ./user-init.o (gcl_init_or_load1)
<br>|
<br>| ( ... lots of stuff, then )
<br>|
<br>| > .plt 0x000000000804ebd4 0x27b0
<br>| > *(.plt)
<br>| > .plt 0x000000000804ebd4 0x27b0 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
<br>| > 0x000000000804ebe4 fileno@@GLIBC_2.0
<br>| > 0x000000000804ebf4 getpagesize@@GLIBC_2.0
<br>| > 0x000000000804ec04 XWidthOfScreen
<br>| > 0x000000000804ec14 fputs@@GLIBC_2.0
<br>| > 0x000000000804ec24 abort@@GLIBC_2.0
<br>| > 0x000000000804ec34 __errno_location@@GLIBC_2.0
<br>| > 0x000000000804ec44 XXorRegion
<br>|
<br>| ( ... many similar lines ... )
<br>|
<br>| > 0x0000000008051314 getgid@@GLIBC_2.0
<br>| > 0x0000000008051324 XSetScreenSaver
<br>| > 0x0000000008051334 XChangeWindowAttributes
<br>| > 0x0000000008051344 __gmpz_add_ui
<br>| > 0x0000000008051354 XSetArcMode
<br>| > 0x0000000008051364 XParseGeometry
<br>| > 0x0000000008051374 geteuid@@GLIBC_2.0
<br>| > *(.iplt)
<br>| > .iplt 0x0000000000000000 0x0 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
<br>| >
<br>| > .text 0x0000000008051390 0x33d9dc
<br>| > *(.text .stub .text.* .gnu.linkonce.t.*)
<br>| > .text 0x0000000008051390 0x24 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
<br>| > 0x0000000008051390 _start
<br>| > .text 0x00000000080513b4 0x0 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crti.o
<br>| > *fill* 0x00000000080513b4 0xc 90909090
<br>|
<br>| ( ... etc.)
<br>|
<br>| The code:
<br>|
<br>| > for (i=j=0,li=Cnil;fgets(b,sizeof(b),f);) {
<br>|
<br>| (initialize variable "i" to zero; then repeat reading lines from file
<br>| "f" into buffer "b", and for each line ...)
<br>|
<br>| > if (!memchr(b,10,sizeof(b)-1))
<br>| > FEerror("plt buffer too small", 0);
<br>|
<br>| (fail with an error message if no newline character (code 10) is found
<br>| in the buffer (i.e. the input line was too long to fit), ...)
<br>|
<br>| > if (memcmp(b," .plt",4) && !i)
<br>| > continue;
<br>|
<br>| ("continue" - ie. read the next input line - unless a) "b" begins with
<br>| " .pl", or b) "i" is non-zero. "i" works like a switch, set it to 1 to
<br>| activate the code below for input lines not having " .pl"...)
<br>| (--notice the strange digit 4 when the string literal has 5 characters
<br>| including the leading space. A minor bug? --)
<br>|
<br>| > if (*b=='\r' || *b=='\n') {
<br>| > i=0;
<br>| > continue;
<br>| > }
<br>|
<br>| (turn the switch off again when processing an empty line ... )
<br>|
<br>| > else
<br>| > if (!i) {
<br>| > i=1;
<br>| > continue;
<br>| > }
<br>|
<br>| ( If the switch is off, turn it on, but go back up and get the next
<br>| input line before doing anything more. This prevents the code below
<br>| from acting on the line that begins with " .pl".)
<br>|
<br>| We can only get past this point when the switch is on. The extraction
<br>| happens with
<br>|
<br>| > if (sscanf(b,"%lx%n",&u,&n)!=1)
<br>| > FEerror("Cannot read address", 0);
<br>|
<br>| which must fail when we reach the line that has "*(.iplt)" at the
<br>| start.
<br>|
<br>| I tell all this because the web is full of messages about the problems
<br>| with Fedora and SELinux, but I have SELinux disabled, and this does not
<br>| look like a compiler bug or a compiler over-optimization.
<br>|
<br>| Obviously the program expects the input to have an empty line separating
<br>| distinct parts. Maybe some tool has been changed. Maybe there used to be
<br>| an empty line just before the "*(.iplt)" line, or may be two lines
<br>| containing .iplt have been added in a recent version of the tools that
<br>| generate the map file. I have
<br>|
<br>| OK, I "fixed" it, by placing a shell script "ld" in /usr/local/bin,
<br>| which is ahead of /usr/bin in my path:
<br>|
<br>|
<br>| > #!/bin/sh
<br>| >
<br>| > set -x
<br>| >
<br>| > case "$*" in
<br>| > (*"-Map ./raw_lisp_map"*)
<br>| > /usr/bin/ld "$@"
<br>| > mv ./raw_lisp_map ./raw_lisp_map.old
<br>| > grep -v '\.iplt' ./raw_lisp_map.old > ./raw_lisp_map
<br>| > ;;
<br>| > (*)
<br>| > exec /usr/bin/ld "$@"
<br>| > ;;
<br>| > esac
<br>|
<br>| but I immediately ran into the next problem:
<br>|
<br>|
<br>| > GCL (GNU Common Lisp) April 1994 131072 pages
<br>| > Building symbol table for /home/enrique/src/build-oa/src/lisp/raw_lisp ..
<br>| > loading /usr/lib/gcl-2.6.8/unixport/../lsp/gcl_export.lsp
<br>| > Initializing gcl_defmacro.o
<br>| > Can't open file ~s
<br>| > Lisp initialization failed.
<br>| >
<br>| > "lisp"
<br>| >
<br>| > AxiomCore>
<br>|
<br>| I found the following line in the source of gcl, in file o/fasdump.c:
<br>|
<br>| > if (in == Cnil)
<br>| > FEerror("Can't open file ~s",1,d);
<br>|
<br>| I wonder if the string "~s" should have been "%s" ...
<br>|
<br>| By the way, some days ago I build my CVS snapshot of gcl; this was only
<br>| possible after adding -fno-strict-aliases to TCFLAGS in ./configure
<br>|
<br>| Enrique
<br><br>--
<br>Dr. Gabriel Dos Reis (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25865594&i=2" target="_top" rel="nofollow">gdr@...</a>), Assistant Professor
<br> <a href="http://www.cs.tamu.edu/people/faculty/gdr" target="_top" rel="nofollow">http://www.cs.tamu.edu/people/faculty/gdr</a><br> Department of Computer Science & Engineering; TAMU
<br> 301, Bright Building -- College Station, TX 77843-3112
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25865594&i=3" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25865125Re: [TeXmacs] A rewrite of tm_axiom.c (attached)2009-10-12T16:57:25Z2009-10-12T16:57:25ZEnrique Perez-TerronI have just downloaded open-axiom-1.3.0.tar.bz2, and attempted to build
<br>it using the standard installed gcl from Fedora 11.
<br><br>I think the builders of Fedora-11 downloaded a CVS snapshot of gcl on
<br>some date... Yes, here it is, in their gcl.spec:
<br><br># The source for this package was pulled from upstream's CVS repository. Use
<br># the following commands to generate the tarball:
<br># cvs -d:pserver:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25865125&i=0" target="_top" rel="nofollow">anonymous@...</a>:/sources/gcl export \
<br># -r Version_2_6_8pre -D 2009-03-04 -d gcl-2.6.8 gcl
<br># tar -cjvf gcl-2.6.8.tar.bz2 gcl-2.6.8
<br><br>But the code quoted below is not different in the cvs snapshot I myself
<br>downloaded (without version and date restricting options) on 2009-10-07.
<br>(There are differences in other parts of plt.c and fasdump.c.)
<br><br>I am building on Fedora 11, with SELinux disabled:
<br><br>$ sudo getenforce
<br>Disabled
<br><br>Also relevant:
<br><br>$ ld --version
<br>GNU ld version 2.19.51.0.14-1.fc11 20090722
<br>...
<br>$ gcc --version
<br>gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
<br><br>$ gcl --version
<br>GCL (GNU Common Lisp) 2.6.8 ANSI Apr 27 2009 12:50:17
<br>...
<br><br>Just in case: (compare the build date)
<br><br>$ rpm -qi gcl
<br>Name : gcl Relocations: (not relocatable)
<br>Version : 2.6.8 Vendor: Fedora Project
<br>Release : 0.3.20090303cvs.fc11 Build Date: Mon 27 Apr 2009 06:54:29 PM CEST
<br>...
<br><br><br>(The text below was written for a different mailing list, but I decided
<br>to send to more appropriate lists when I saw what I have written. Bear
<br>with the excessive details.)
<br><br>During the build of open-axiom, the following command:
<br><div class='shrinkable-quote'><br>> echo '(let* ((sys-cc compiler::*cc*) ' \
<br>> ' (sys-ld compiler::*ld*) ' \
<br>> ' (compiler::*cc* (concatenate (quote string) ' \
<br>> ' "../../libtool --mode=compile " ' \
<br>> ' sys-cc)) ' \
<br>> ' (compiler::*ld* (concatenate (quote string) ' \
<br>> ' "../../libtool --mode=link " ' \
<br>> ' sys-ld))) ' \
<br>> '(compiler::link (quote ("core.o")) "lisp" ' \
<br>> ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
<br>> ' (si::*load-types* ~S)))' \
<br>> ' (when (fboundp (quote si::sgc-on))' \
<br>> ' (si::sgc-on nil))' \
<br>> ' (setq si::*top-level-hook* (read-from-string \"|AxiomCore|::|topLevel|\")))"' \
<br>> ' si::*system-directory* (quote (list ".lsp")))' \
<br>> ' "./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o ./../../src/lib/sockio-c.o -lutil -lm"))' \
<br>> | ./base-lisp
</div><br>fails with the following output:
<br><div class='shrinkable-quote'><br>> GCL (GNU Common Lisp) 2.6.8 ANSI Apr 27 2009 12:50:17
<br>> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
<br>> Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
<br>> Modifications of this banner must retain notice of a compatible license
<br>> Dedicated to the memory of W. Schelter
<br>>
<br>> Use (help) to get some basic information on how to use GCL.
<br>> Temporary directory for compiler files set to /tmp/
<br>>
<br>> AxiomCore>libtool: compile: gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wall -DVOL=volatile -fsigned-char -pipe -I/usr/lib/gcl-2.6.8/unixport/../h -O2 -fno-strict-aliasing -c ./user-init.c -w -fPIC -DPIC -o ./.libs/user-init.o
<br>> libtool: compile: gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wall -DVOL=volatile -fsigned-char -pipe -I/usr/lib/gcl-2.6.8/unixport/../h -O2 -fno-strict-aliasing -c ./user-init.c -w -o ./user-init.o >/dev/null 2>&1
<br>> libtool: link: gcc -o ./raw_lisp ./user-init.o core.o -Wl,-Map ./raw_lisp_map ./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o ./../../src/lib/sockio-c.o -L/usr/lib/gcl-2.6.8/unixport/ -lansi_gcl -lSM -lICE -lXmu -lXt -lXext -lXaw -lX11 -lgmp -lbfd -liberty -lreadline -lncurses -lc -lgclp -lutil -lm
<br>> GCL (GNU Common Lisp) April 1994 131072 pages
<br>> Cannot read address
<br>> Lisp initialization failed.
<br>>
<br>> "lisp"
<br>>
<br>> AxiomCore>
</div><br>I am building using the Fedora-11 native gcl. The command "./base-lisp"
<br>appears to be a version of gcl that has been dumped with some extra
<br>functions and a modified prompt "AxiomCore", a few lines earlier in the
<br>build.
<br><br>I had the same error a few days ago, and I looked at the gcl source to
<br>find the error message "Cannot read address". I found it in
<br>gcl-2.6.8/o/plt.c, and it appears that the function parse_plt() *must*
<br>fail with exactly this message given the input file
<br>src/lisp/raw_lisp_map (from the open-axiom build tree).
<br><br>The input file contains:
<br><br>> Archive member included because of file (symbol)
<br>>
<br>> /usr/lib/gcl-2.6.8/unixport//libansi_gcl.a(alloc.o)
<br>> ./../../src/lib/cfuns-c.o (free)
<br>> /usr/lib/gcl-2.6.8/unixport//libansi_gcl.a(cmpaux.o)
<br>> ./user-init.o (gcl_init_or_load1)
<br><br>( ... lots of stuff, then )
<br><div class='shrinkable-quote'><br>> .plt 0x000000000804ebd4 0x27b0
<br>> *(.plt)
<br>> .plt 0x000000000804ebd4 0x27b0 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
<br>> 0x000000000804ebe4 fileno@@GLIBC_2.0
<br>> 0x000000000804ebf4 getpagesize@@GLIBC_2.0
<br>> 0x000000000804ec04 XWidthOfScreen
<br>> 0x000000000804ec14 fputs@@GLIBC_2.0
<br>> 0x000000000804ec24 abort@@GLIBC_2.0
<br>> 0x000000000804ec34 __errno_location@@GLIBC_2.0
<br>> 0x000000000804ec44 XXorRegion
</div><br>( ... many similar lines ... )
<br><div class='shrinkable-quote'><br>> 0x0000000008051314 getgid@@GLIBC_2.0
<br>> 0x0000000008051324 XSetScreenSaver
<br>> 0x0000000008051334 XChangeWindowAttributes
<br>> 0x0000000008051344 __gmpz_add_ui
<br>> 0x0000000008051354 XSetArcMode
<br>> 0x0000000008051364 XParseGeometry
<br>> 0x0000000008051374 geteuid@@GLIBC_2.0
<br>> *(.iplt)
<br>> .iplt 0x0000000000000000 0x0 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
<br>>
<br>> .text 0x0000000008051390 0x33d9dc
<br>> *(.text .stub .text.* .gnu.linkonce.t.*)
<br>> .text 0x0000000008051390 0x24 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
<br>> 0x0000000008051390 _start
<br>> .text 0x00000000080513b4 0x0 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crti.o
<br>> *fill* 0x00000000080513b4 0xc 90909090
</div><br>( ... etc.)
<br><br>The code:
<br><br>> for (i=j=0,li=Cnil;fgets(b,sizeof(b),f);) {
<br><br>(initialize variable "i" to zero; then repeat reading lines from file
<br>"f" into buffer "b", and for each line ...)
<br><br>> if (!memchr(b,10,sizeof(b)-1))
<br>> FEerror("plt buffer too small", 0);
<br><br>(fail with an error message if no newline character (code 10) is found
<br>in the buffer (i.e. the input line was too long to fit), ...)
<br><br>> if (memcmp(b," .plt",4) && !i)
<br>> continue;
<br><br>("continue" - ie. read the next input line - unless a) "b" begins with
<br>" .pl", or b) "i" is non-zero. "i" works like a switch, set it to 1 to
<br>activate the code below for input lines not having " .pl"...)
<br>(--notice the strange digit 4 when the string literal has 5 characters
<br>including the leading space. A minor bug? --)
<br><br>> if (*b=='\r' || *b=='\n') {
<br>> i=0;
<br>> continue;
<br>> }
<br><br>(turn the switch off again when processing an empty line ... )
<br><br>> else
<br>> if (!i) {
<br>> i=1;
<br>> continue;
<br>> }
<br><br>( If the switch is off, turn it on, but go back up and get the next
<br>input line before doing anything more. This prevents the code below
<br>from acting on the line that begins with " .pl".)
<br><br>We can only get past this point when the switch is on. The extraction
<br>happens with
<br><br>> if (sscanf(b,"%lx%n",&u,&n)!=1)
<br>> FEerror("Cannot read address", 0);
<br><br>which must fail when we reach the line that has "*(.iplt)" at the
<br>start.
<br><br>I tell all this because the web is full of messages about the problems
<br>with Fedora and SELinux, but I have SELinux disabled, and this does not
<br>look like a compiler bug or a compiler over-optimization.
<br><br>Obviously the program expects the input to have an empty line separating
<br>distinct parts. Maybe some tool has been changed. Maybe there used to be
<br>an empty line just before the "*(.iplt)" line, or may be two lines
<br>containing .iplt have been added in a recent version of the tools that
<br>generate the map file. I have
<br><br>OK, I "fixed" it, by placing a shell script "ld" in /usr/local/bin,
<br>which is ahead of /usr/bin in my path:
<br><br><div class='shrinkable-quote'><br>> #!/bin/sh
<br>>
<br>> set -x
<br>>
<br>> case "$*" in
<br>> (*"-Map ./raw_lisp_map"*)
<br>> /usr/bin/ld "$@"
<br>> mv ./raw_lisp_map ./raw_lisp_map.old
<br>> grep -v '\.iplt' ./raw_lisp_map.old > ./raw_lisp_map
<br>> ;;
<br>> (*)
<br>> exec /usr/bin/ld "$@"
<br>> ;;
<br>> esac
</div><br>but I immediately ran into the next problem:
<br><br><div class='shrinkable-quote'><br>> GCL (GNU Common Lisp) April 1994 131072 pages
<br>> Building symbol table for /home/enrique/src/build-oa/src/lisp/raw_lisp ..
<br>> loading /usr/lib/gcl-2.6.8/unixport/../lsp/gcl_export.lsp
<br>> Initializing gcl_defmacro.o
<br>> Can't open file ~s
<br>> Lisp initialization failed.
<br>>
<br>> "lisp"
<br>>
<br>> AxiomCore>
</div><br>I found the following line in the source of gcl, in file o/fasdump.c:
<br><br>> if (in == Cnil)
<br>> FEerror("Can't open file ~s",1,d);
<br><br>I wonder if the string "~s" should have been "%s" ...
<br><br>By the way, some days ago I build my CVS snapshot of gcl; this was only
<br>possible after adding -fno-strict-aliases to TCFLAGS in ./configure
<br><br>Enrique
<br><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25865125&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25437921Free memory from the garbage collector2009-09-14T08:18:15Z2009-09-14T08:18:15ZJavier SanchoHi all,
<br><br>I'm developing a Lisp extension for making games with SDL and OpenGL
<br>and I want to manage memory transparently for the programmer.
<br><br>Memory is allocated from C functions calling malloc or other simillar
<br>functions and lisp variables store the memory address. The idea is to
<br>free memory from unused variables when garbage collector is invoked.
<br><br>I've read extensively GCL documentation and I haven't found any
<br>reference for doing something similar.
<br><br>Can anyone help me? Thanks.
<br><br>--
<br>Javier Sancho Fernández - <a href="http://www.jsancho.org/" target="_top" rel="nofollow">http://www.jsancho.org/</a><br>Associate Member of the Free Software Foundation - <a href="http://www.fsf.org/" target="_top" rel="nofollow">http://www.fsf.org/</a><br>Socio de Aditel - <a href="http://www.aditel.org/" target="_top" rel="nofollow">http://www.aditel.org/</a><br>Contra el DRM - <a href="http://www.defectivebydesign.org/what_is_drm" target="_top" rel="nofollow">http://www.defectivebydesign.org/what_is_drm</a><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25437921&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25144759Re: Fedora Sparc build problem2009-08-25T17:38:06Z2009-08-25T17:38:06ZCamm Maguire-2Greetings! OK I'm back, and my ssh key is:
<br><br>=============================================================================
<br>ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtseLLbrS7utxoresgHYJtfUCLckotAcc6SfOqjg1MVrV77GNSuNfR+6iX7ahLDnbNtGzauDJM+8/H0hx2dM0+UMy92betwF+2TYjHfSucsoWhb2kSNUwIFiq714NdSa1vdcEEV/jLQ2v4fDCMew9X2NnzAxovCTSEcRCmMEenaU= camm@wisdom
<br>=============================================================================
<br><br>Take care,
<br><br>Jerry James <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144759&i=0" target="_top" rel="nofollow">loganjerry@...</a>> writes:
<br><div class='shrinkable-quote'><br>> On Sun, Aug 16, 2009 at 8:29 AM, Camm Maguire<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144759&i=1" target="_top" rel="nofollow">camm@...</a>> wrote:
<br>>> Greetings! I'm away from home for another week, but I just wanted t
<br>>> add this quickly -- I think the error handler was called recursively
<br>>> from your output. Please make sure you are looking at the topmost
<br>>> call to the error handler. Also -- if remote access to this machine
<br>>> can be arranged, I'd be happy to take a look if you'd like.
<br>>
<br>> I would be very happy if you could take a look. I'll see if remote
<br>> access for you can be arranged. Thanks!
<br>> --
<br>> Jerry James
<br>> <a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br>>
<br>>
<br>>
<br>>
</div><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144759&i=2" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144759&i=3" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25144765Re: virtual memory2009-08-25T17:36:39Z2009-08-25T17:36:39ZCamm Maguire-2Greetings, and thanks for your report!
<br><br>I'm always interested in this. Were the maxima versions the same? If
<br>not, what were the maxima versions?
<br><br><br>Take care,
<br><br><br>"Andrey G. Grozin" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144765&i=0" target="_top" rel="nofollow">A.G.Grozin@...</a>> writes:
<br><div class='shrinkable-quote'><br>> Hello *,
<br>>
<br>> An older version of gcl-2.6.8-pre in Gentoo (it was taken from Debian,
<br>> don't remember the exact number of the Debian patch) was the fastest
<br>> in running the maxima tests. Recently, I've compiled gcl-2.6.8-pre
<br>> from cvs, and now I cannot complete these tests at all: maxima is
<br>> swapping like mad, and makes very little progress. It seems that it
<br>> uses much more virtual memory than the main memory of my computer
<br>> (which is not large, just 1/4 Gb).
<br>>
<br>> Is there any gcl build parameter which I can tune to reduce the amount
<br>> of virtual memory used by gcl? What has changed in this respect in a
<br>> not too distant past? (this may mean a year ago or something, I don't
<br>> know more exactly).
<br>>
<br>> Andrey
<br>>
<br>>
<br>>
<br>> _______________________________________________
<br>> Gcl-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144765&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br>> <a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br>>
<br>>
<br>>
<br>>
</div><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144765&i=2" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25144765&i=3" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25055309virtual memory2009-08-19T19:46:04Z2009-08-19T19:46:04ZAndrey G. GrozinHello *,
<br><br>An older version of gcl-2.6.8-pre in Gentoo (it was taken from Debian,
<br>don't remember the exact number of the Debian patch) was the fastest in
<br>running the maxima tests. Recently, I've compiled gcl-2.6.8-pre from cvs,
<br>and now I cannot complete these tests at all: maxima is swapping like mad,
<br>and makes very little progress. It seems that it uses much more virtual
<br>memory than the main memory of my computer (which is not large, just 1/4
<br>Gb).
<br><br>Is there any gcl build parameter which I can tune to reduce the amount of
<br>virtual memory used by gcl? What has changed in this respect in a not too
<br>distant past? (this may mean a year ago or something, I don't know more
<br>exactly).
<br><br>Andrey
<br><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25055309&i=0" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-25011034Re: Fedora Sparc build problem2009-08-17T10:36:49Z2009-08-17T10:36:49ZJerry James-3On Sun, Aug 16, 2009 at 8:29 AM, Camm Maguire<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25011034&i=0" target="_top" rel="nofollow">camm@...</a>> wrote:
<br>> Greetings! I'm away from home for another week, but I just wanted t
<br>> add this quickly -- I think the error handler was called recursively
<br>> from your output. Please make sure you are looking at the topmost
<br>> call to the error handler. Also -- if remote access to this machine
<br>> can be arranged, I'd be happy to take a look if you'd like.
<br><br>I would be very happy if you could take a look. I'll see if remote
<br>access for you can be arranged. Thanks!
<br>--
<br>Jerry James
<br><a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25011034&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>tag:old.nabble.com,2006:post-24994074Re: Fedora Sparc build problem2009-08-16T07:29:05Z2009-08-16T07:29:05ZCamm Maguire-2Greetings! I'm away from home for another week, but I just wanted t
<br>add this quickly -- I think the error handler was called recursively
<br>from your output. Please make sure you are looking at the topmost
<br>call to the error handler. Also -- if remote access to this machine
<br>can be arranged, I'd be happy to take a look if you'd like.
<br><br>Take care,
<br><br>Jerry James <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24994074&i=0" target="_top" rel="nofollow">loganjerry@...</a>> writes:
<br><div class='shrinkable-quote'><br>> With the PLT patch I sent recently, the build for Fedora Linux on
<br>> Sparc gets off the ground. However, it doesn't complete. Here is the
<br>> last (relevant) bit of the build log:
<br>>
<br>> ------------------------------------------------------------------------------
<br>> /builddir/build/BUILD/gcl-2.6.8/unixport/raw_pre_gcl
<br>> /builddir/build/BUILD/gcl-2.6.8/unixport/ -libdir
<br>> /builddir/build/BUILD/gcl-2.6.8/ < foo
<br>> GCL (GNU Common Lisp) April 1994 131072 pages
<br>> Building symbol table for
<br>> /builddir/build/BUILD/gcl-2.6.8/unixport/raw_pre_gcl ..
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_export.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_defmacro.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_evalmacros.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_top.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_module.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_autoload.lsp
<br>>>
<br>> #<"COMPILER" package>
<br>>>
<br>> #<"SLOOP" package>
<br>>>
<br>> #<"SERROR" package>
<br>>>
<br>> #<"ANSI-LOOP" package>
<br>>>
<br>> #<"DEFPACKAGE" package>
<br>>>
<br>> #<"TK" package>
<br>>>
<br>> #<"SYSTEM" package>
<br>> SYSTEM>
<br>> *COMMAND-ARGS*
<br>> SYSTEM>loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_listlib.lsp
<br>> Warning: NTHCDR is being redefined.
<br>> Warning: NTH is being redefined.
<br>> Warning: FIRST is being redefined.
<br>> Warning: SECOND is being redefined.
<br>> Warning: THIRD is being redefined.
<br>> Warning: FOURTH is being redefined.
<br>> Warning: FIFTH is being redefined.
<br>> Warning: SIXTH is being redefined.
<br>> Warning: SEVENTH is being redefined.
<br>> Warning: EIGHTH is being redefined.
<br>> Warning: NINTH is being redefined.
<br>> Warning: TENTH is being redefined.loading
<br>> /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_predlib.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_setf.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_arraylib.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_assert.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_defstruct.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_describe.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_iolib.lsp
<br>> Warning: WRITE-BYTE is being redefined.
<br>> Warning: READ-BYTE is being redefined.loading
<br>> /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_mislib.lsp
<br>> Warning: LISP-IMPLEMENTATION-VERSION is being redefined.loading
<br>> /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_numlib.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_packlib.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_seq.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_seqlib.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_trace.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_sloop.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_serror.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_destructuring_bind.lsp
<br>> loading /builddir/build/BUILD/gcl-2.6.8/unixport/../lsp/gcl_loop.lsp
<br>> Error handler called recursively (:ERROR
<br>>
<br>> NIL
<br>>
<br>> SERROR::MAKE-ERROR-CONDITION
<br>>
<br>> ""
<br>>
<br>> "Bad make_structure args for type ~a"
<br>>
<br>> SERROR::ERROR-CONDITION)
<br>> Error: Bad make_structure args for type ERROR-CONDITION
<br>> Error signalled by SERROR::MAKE-ERROR-CONDITION.
<br>> Broken at COND. Type :H for Help.
<br>> ANSI-LOOP>>
<br>> #<"USER" package>
<br>> ------------------------------------------------------------------------------
<br>>
<br>> I ran it in GDB, with a breakpoint set on FEerror. The backtrace is
<br>> 51 frames long. I'll just give the last half:
<br>>
<br>> ------------------------------------------------------------------------------
<br>> #0 FEerror (s=0x206e28 "Bad make_structure args for type ~a", num=1)
<br>> at error.c:268
<br>> #1 0x000000000012fc78 in siLmake_structure () at structure.c:194
<br>> #2 0x00000000001586b4 in eval (form=<value optimized out>) at eval.c:1090
<br>> #3 0x0000000000155e14 in funcall (fun=<value optimized out>) at eval.c:327
<br>> #4 0x0000000000158614 in eval (form=<value optimized out>) at eval.c:1092
<br>> #5 0x000000000011b5e0 in Fprogn (body=0xfb1ea8) at prog.c:248
<br>> #6 0x000000000017cf38 in Fflet (args=0x774808) at let.c:234
<br>> #7 0x00000000001581fc in eval (form=0xfaec60) at eval.c:1037
<br>> #8 0x0000000000155e60 in funcall (fun=<value optimized out>) at eval.c:327
<br>> #9 0x0000000000158614 in eval (form=<value optimized out>) at eval.c:1092
<br>> #10 0x0000000000149484 in let_bind (body=<value optimized out>,
<br>> start=0x7904a8, end=0x7904c8) at bind.c:679
<br>> #11 0x000000000017dacc in Flet (form=0x1042a98) at let.c:78
<br>> #12 0x00000000001581fc in eval (form=0x1041080) at eval.c:1037
<br>> #13 0x0000000000155e14 in funcall (fun=<value optimized out>) at eval.c:327
<br>> #14 0x0000000000158614 in eval (form=<value optimized out>) at eval.c:1092
<br>> #15 0x000000000015896c in Ieval (form=0x1045c68) at eval.c:928
<br>> #16 0x00000000001469b4 in Fsetq (form=0x10459e0) at assignment.c:100
<br>> #17 0x00000000001581fc in eval (form=0x10459c8) at eval.c:1037
<br>> #18 0x000000000011b5e0 in Fprogn (body=0x1045968) at prog.c:248
<br>> #19 0x00000000001581fc in eval (form=0x1045938) at eval.c:1037
<br>> #20 0x000000000015875c in ieval (x=0x1045cb0) at eval.c:1278
<br>> #21 0x0000000000161438 in load (s=<value optimized out>) at file.d:1517
<br>> #22 0x0000000000138e8c in gcl_init_system (no_init=0xbbdd88)
<br>> at sys_pre_gcl.c:102
<br>> #23 0x0000000000104e3c in siLinit_system () at main.c:845
<br>> ------------------------------------------------------------------------------
<br>>
<br>> The code in frame #1 called FEerror here:
<br>>
<br>> ------------------------------------------------------------------------------
<br>> if (type_of(name)!=t_structure ||
<br>> (def=S_DATA(name))->length != --narg)
<br>> FEerror("Bad make_structure args for type ~a",1,
<br>> base[0]);
<br>> ------------------------------------------------------------------------------
<br>>
<br>> At this point, type_of(name) == t_structure. However, narg is 9, but
<br>> S_DATA(name)->length is 0.
<br>>
<br>> I don't know this code well enough to know how to track down the
<br>> problem. Can anyone give me some tips on what I should look for?
<br>> Thanks,
<br>> --
<br>> Jerry James
<br>> <a href="http://www.jamezone.org/" target="_top" rel="nofollow">http://www.jamezone.org/</a><br>>
<br>>
<br>> _______________________________________________
<br>> Gcl-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24994074&i=1" target="_top" rel="nofollow">Gcl-devel@...</a>
<br>> <a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br>>
<br>>
<br>>
<br>>
</div><br>--
<br>Camm Maguire <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24994074&i=2" target="_top" rel="nofollow">camm@...</a>
<br>==========================================================================
<br>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
<br><br><br>_______________________________________________
<br>Gcl-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24994074&i=3" target="_top" rel="nofollow">Gcl-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gcl-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gcl-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GCL---Dev-f1616.html" embed="fixTarget[1616]" target="_top" >Gnu - GCL - Dev</a></p>