Menu
▾
▴
clisp-devel — closed list for developers and testers
You can subscribe to this list here.
| 2000 |
Jan
(81) |
Feb
(55) |
Mar
(459) |
Apr
(159) |
May
(126) |
Jun
(69) |
Jul
(48) |
Aug
(29) |
Sep
(106) |
Oct
(76) |
Nov
(155) |
Dec
(161) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(122) |
Feb
(150) |
Mar
(294) |
Apr
(124) |
May
(197) |
Jun
(266) |
Jul
(111) |
Aug
(259) |
Sep
(163) |
Oct
(142) |
Nov
(101) |
Dec
(86) |
| 2002 |
Jan
(187) |
Feb
(108) |
Mar
(274) |
Apr
(157) |
May
(346) |
Jun
(242) |
Jul
(345) |
Aug
(187) |
Sep
(263) |
Oct
(69) |
Nov
(30) |
Dec
(76) |
| 2003 |
Jan
(125) |
Feb
(191) |
Mar
(87) |
Apr
(69) |
May
(107) |
Jun
(66) |
Jul
(112) |
Aug
(161) |
Sep
(184) |
Oct
(137) |
Nov
(28) |
Dec
(61) |
| 2004 |
Jan
(148) |
Feb
(99) |
Mar
(365) |
Apr
(225) |
May
(311) |
Jun
(204) |
Jul
(95) |
Aug
(214) |
Sep
(256) |
Oct
(290) |
Nov
(239) |
Dec
(152) |
| 2005 |
Jan
(253) |
Feb
(183) |
Mar
(178) |
Apr
(88) |
May
(175) |
Jun
(195) |
Jul
(122) |
Aug
(81) |
Sep
(119) |
Oct
(200) |
Nov
(110) |
Dec
(179) |
| 2006 |
Jan
(154) |
Feb
(64) |
Mar
(55) |
Apr
(69) |
May
(66) |
Jun
(64) |
Jul
(80) |
Aug
(59) |
Sep
(62) |
Oct
(90) |
Nov
(132) |
Dec
(106) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(59) |
Apr
(19) |
May
(33) |
Jun
(52) |
Jul
(15) |
Aug
(50) |
Sep
(41) |
Oct
(259) |
Nov
(323) |
Dec
(136) |
| 2008 |
Jan
(205) |
Feb
(128) |
Mar
(203) |
Apr
(126) |
May
(307) |
Jun
(166) |
Jul
(259) |
Aug
(181) |
Sep
(217) |
Oct
(265) |
Nov
(256) |
Dec
(132) |
| 2009 |
Jan
(104) |
Feb
(81) |
Mar
(27) |
Apr
(21) |
May
(85) |
Jun
(237) |
Jul
(243) |
Aug
(199) |
Sep
(178) |
Oct
(151) |
Nov
(64) |
Dec
(39) |
| 2010 |
Jan
(33) |
Feb
(146) |
Mar
(125) |
Apr
(109) |
May
(52) |
Jun
(135) |
Jul
(103) |
Aug
(68) |
Sep
(99) |
Oct
(88) |
Nov
(45) |
Dec
(56) |
| 2011 |
Jan
(19) |
Feb
(32) |
Mar
(50) |
Apr
(105) |
May
(46) |
Jun
(22) |
Jul
(101) |
Aug
(80) |
Sep
(52) |
Oct
(16) |
Nov
(10) |
Dec
(29) |
| 2012 |
Jan
(8) |
Feb
(22) |
Mar
(17) |
Apr
(68) |
May
(19) |
Jun
(19) |
Jul
(12) |
Aug
(6) |
Sep
(13) |
Oct
(5) |
Nov
(5) |
Dec
(5) |
| 2013 |
Jan
(6) |
Feb
(4) |
Mar
(3) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(16) |
Apr
(1) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(8) |
Mar
(23) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
(5) |
| 2016 |
Jan
|
Feb
|
Mar
(16) |
Apr
(6) |
May
(53) |
Jun
(19) |
Jul
(3) |
Aug
(39) |
Sep
(24) |
Oct
(2) |
Nov
(19) |
Dec
|
| 2017 |
Jan
(13) |
Feb
(44) |
Mar
(208) |
Apr
(12) |
May
(94) |
Jun
(54) |
Jul
(18) |
Aug
(52) |
Sep
(12) |
Oct
(22) |
Nov
(27) |
Dec
(93) |
| 2018 |
Jan
(85) |
Feb
(28) |
Mar
(16) |
Apr
(47) |
May
(16) |
Jun
(15) |
Jul
(10) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
|
| 2019 |
Jan
(4) |
Feb
(6) |
Mar
(12) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2022 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(5) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(28) |
Dec
(3) |
| 2025 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-04-06 16:18:46
|
Feature Requests item #3276560, was opened at 2011-04-05 20:13 Message generated for change (Comment added) made by donc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extend ANSI CL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Don Cohen (donc) Assigned to: Sam Steingold (sds) Summary: econnreset error => subclass of eof Initial Comment: Right now, when a socket is reset by the peer, nothing exciting happens until you try to read past the last available input. At that point you get a OS error (ECONNRESET) which is not an EOF condition (I think it should be), and this further closes the fd, without marking the stream as closed (which I think it should not do). The result is that further attempts to use the stream give EBADF OS errors. Requests: - new condition class CONNECTION-RESET: (define-condition connection-reset (end-of-file) ()) - change in CLISP behavior s.t. ECONNRESET results in CONNECTION-RESET and not in OS-ERROR (or whatever) - don't close fd on ECONNRESET - it should act like other eof's - another attempt to read from the stream should cause another eof. Test code (at least for linux) This requires two lisp processes, one for the client, one for the server. I make use of the fact that closing a socket when there is still input available seems to result (again, only tested in linux) in a TCP reset rather than a FIN. The result of a FIN terminated connection is what I view as correct, so I will demonstrate that also. [server] (setf ss (socket:socket-server 1234)) [server] (setf s (socket-accept ss)) [client] (setf s (socket:socket-connect 1234)) [server-RST] (princ "asd" s) [client] (close s) at this point the stream is closed, either with FIN if the [server-RST] line is left out, or with RST if it is included [server] (read-char s) the result in FIN scenario is an EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number [server] (read-char s) in the FIN scenario the result is another EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number In both cases s appears to be an open stream, though in the RST scenario, the underlying fd has been closed. ---------------------------------------------------------------------- >Comment By: Don Cohen (donc) Date: 2011-04-06 16:18 Message: I now notice that the ECONNRESET OS-ERROR occurs on both read and write. I'd like to clarify that only reads should result in EOF errors, so the condition should perhaps be named to indicate some relation to eof or read, e.g., TCP-RESET-EOF, and ECONNRESET resulting from a write should not result in that particular condition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&group_id=1355 |
|
From: <cli...@li...> - 2011-04-06 12:04:21
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: Tweak last two changes. (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Tue, 05 Apr 2011 23:37:38 +0000 From: cli...@li... Subject: clisp: Tweak last two changes. To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/68a97cddb8ab changeset: 15322:68a97cddb8ab4008b68955537a5de4cd417eb9a4 user: Bruno Haible <br...@cl...> date: 2011-04-06 01:27:33 +0200 description: Tweak last two changes. diffstat: src/ChangeLog | 8 ++++++++ src/lispbibl.d | 36 ++++++++++++++++++++++++------------ src/spvw.d | 8 +++++++- src/spvw_fault.d | 11 +++++------ 4 files changed, 44 insertions(+), 19 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 59, Issue 4 **************************************** |
|
From: SourceForge.net <no...@so...> - 2011-04-05 20:13:51
|
Feature Requests item #3276560, was opened at 2011-04-05 20:13 Message generated for change (Tracker Item Submitted) made by donc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extend ANSI CL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Don Cohen (donc) Assigned to: Sam Steingold (sds) Summary: econnreset error => subclass of eof Initial Comment: Right now, when a socket is reset by the peer, nothing exciting happens until you try to read past the last available input. At that point you get a OS error (ECONNRESET) which is not an EOF condition (I think it should be), and this further closes the fd, without marking the stream as closed (which I think it should not do). The result is that further attempts to use the stream give EBADF OS errors. Requests: - new condition class CONNECTION-RESET: (define-condition connection-reset (end-of-file) ()) - change in CLISP behavior s.t. ECONNRESET results in CONNECTION-RESET and not in OS-ERROR (or whatever) - don't close fd on ECONNRESET - it should act like other eof's - another attempt to read from the stream should cause another eof. Test code (at least for linux) This requires two lisp processes, one for the client, one for the server. I make use of the fact that closing a socket when there is still input available seems to result (again, only tested in linux) in a TCP reset rather than a FIN. The result of a FIN terminated connection is what I view as correct, so I will demonstrate that also. [server] (setf ss (socket:socket-server 1234)) [server] (setf s (socket-accept ss)) [client] (setf s (socket:socket-connect 1234)) [server-RST] (princ "asd" s) [client] (close s) at this point the stream is closed, either with FIN if the [server-RST] line is left out, or with RST if it is included [server] (read-char s) the result in FIN scenario is an EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number [server] (read-char s) in the FIN scenario the result is another EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number In both cases s appears to be an open stream, though in the RST scenario, the underlying fd has been closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&group_id=1355 |
|
From: <don...@is...> - 2011-04-05 19:50:07
|
Sam Steingold writes: > do you read clisp-devel? Now that I receive clisp-devel again I do see the new digests. Thanks. |
|
From: <cli...@li...> - 2011-04-05 12:05:04
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: 2 new changesets (cli...@li...) 2. clisp: * src/lispbibl.d (GENERATIONAL_GC): fix last patch to res... (cli...@li...) 3. clisp: 2 new changesets (cli...@li...) 4. clisp: 3 new changesets (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Mon, 04 Apr 2011 15:27:32 +0000 From: cli...@li... Subject: clisp: 2 new changesets To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/f161de5975bb changeset: 15314:f161de5975bb621751ba46feac005e6a2430c56f user: Sam Steingold <sd...@po...> date: 2011-04-04 11:25:27 -0400 description: * src/spvw_fault.d (handle_fault): fix last patch to restore support to libsigsegv-2.9 and before details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/38762f7593e8 changeset: 15315:38762f7593e8b3012a3f401a10a846073003fc48 user: Sam Steingold <sd...@po...> date: 2011-04-04 11:27:14 -0400 description: call OS:ENDUTXENT to close the FD diffstat: modules/syscalls/test.tst | 5 +++-- src/ChangeLog | 8 +++++++- src/spvw_fault.d | 29 ++++++++++++++++------------- 3 files changed, 26 insertions(+), 16 deletions(-) ------------------------------ Message: 2 Date: Mon, 04 Apr 2011 15:44:00 +0000 From: cli...@li... Subject: clisp: * src/lispbibl.d (GENERATIONAL_GC): fix last patch to res... To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/07211c2aa6b7 changeset: 15316:07211c2aa6b748524f192e04a1211115e50593bd user: Sam Steingold <sd...@po...> date: 2011-04-04 11:43:43 -0400 description: * src/lispbibl.d (GENERATIONAL_GC): fix last patch to restore support to libsigsegv-2.9 and earlier diffstat: src/ChangeLog | 3 ++- src/lispbibl.d | 9 ++++++++- 2 files changed, 10 insertions(+), 2 deletions(-) ------------------------------ Message: 3 Date: Mon, 04 Apr 2011 20:53:07 +0000 From: cli...@li... Subject: clisp: 2 new changesets To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/5403eeca997d changeset: 15317:5403eeca997d86e6bb56b6c6870f13b57a9f548c user: Sam Steingold <sd...@po...> date: 2011-04-04 16:45:38 -0400 description: Reduce consing in HANDLER-BIND et al (bug#3147908). details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/8d0ba422f5c6 changeset: 15318:8d0ba422f5c62ad80f55d2e7512526175b091b2e user: Sam Steingold <sd...@po...> date: 2011-04-04 16:52:38 -0400 description: stream-handles: warning: do not close FDs diffstat: doc/impbody.xml | 7 ++++++- src/NEWS | 1 + 2 files changed, 7 insertions(+), 1 deletions(-) ------------------------------ Message: 4 Date: Mon, 04 Apr 2011 22:36:40 +0000 From: cli...@li... Subject: clisp: 3 new changesets To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/291aaafcdd55 changeset: 15319:291aaafcdd55d35967b5558172f5f474c8eed909 user: Sam Steingold <sd...@po...> date: 2011-04-04 18:22:52 -0400 description: file-tree-walk: traversal order is not fixed details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1f52feb02049 changeset: 15320:1f52feb020494ed633adec6dffd9f7785b318939 user: Sam Steingold <sd...@po...> date: 2011-04-04 18:35:33 -0400 description: prefix keywords with : details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b2c6cfbdb671 changeset: 15321:b2c6cfbdb671c9c0d3014e5b39b41a277d4141f2 user: Sam Steingold <sd...@po...> date: 2011-04-04 18:35:54 -0400 description: use role="errno" for error numbers diffstat: doc/impbody.xml | 6 +++--- doc/impbyte.xml | 2 +- modules/rawsock/rawsock.xml | 6 +++--- modules/syscalls/syscalls.xml | 2 +- modules/syscalls/test.tst | 32 +++++++++++++++++++------------- 5 files changed, 27 insertions(+), 21 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 59, Issue 3 **************************************** |
|
From: SourceForge.net <no...@so...> - 2011-04-05 00:38:35
|
Bugs item #3275143, was opened at 2011-04-05 00:38 Message generated for change (Tracker Item Submitted) made by donc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3275143&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: multithreading Group: segfault Status: Open Resolution: None Priority: 5 Private: No Submitted By: Don Cohen (donc) Assigned to: Vladimir Tzankov (vtz) Summary: stack overflows are not caught in non-initial threads Initial Comment: Test case: [1]> (defun f()(f)) F [2]> (f) *** - Lisp stack overflow. RESET whereas Break 1 [4]> (mt:make-thread (lambda nil (f))) #<THREAD :LAMBDA> Break 1 [4]> Segmentation fault (core dumped) Re: stack overflow => segfault in MT From: Vladimir Tzankov <vtzankov@gm...> - 2011-03-06 22:28 On 3/6/11, Don Cohen <don-sourceforge-xxz@...> wrote: > I send this on the theory that any segfault qualifies as a clisp bug. > This is with current source. On non-MT I get > *** - Program stack overflow. RESET > whereas in MT I get segfault. With MT - only the "main thread" (first one) has stack overflow detection. Stack overflow detection/recovery is implemented via libsigsegv and it supports single stack range. May be libsigesgv should be enhanced with multiple stack range support? gSam? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3275143&group_id=1355 |
|
From: <cli...@li...> - 2011-04-04 12:04:27
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: Support for generational GC on Linux/S390. (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Sun, 03 Apr 2011 16:24:14 +0000 From: cli...@li... Subject: clisp: Support for generational GC on Linux/S390. To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/38ab33e38701 changeset: 15313:38ab33e38701f6ba579a4e5cbe4843c770479dc7 user: Bruno Haible <br...@cl...> date: 2011-04-03 18:17:43 +0200 description: Support for generational GC on Linux/S390. diffstat: configure | 4 ++-- src/ChangeLog | 8 ++++++++ src/lispbibl.d | 2 +- src/spvw_fault.d | 20 +++++++++++++++----- 4 files changed, 26 insertions(+), 8 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 59, Issue 2 **************************************** |
|
From: Bruno H. <br...@cl...> - 2011-04-03 16:39:25
|
Hi Christoph, > Using the -pre libsigsegv I can build clisp fine and it appears to > be basically working -- playing around doesn't result in any obvious > problems. However `make check` is segfaulting. I've attached output of > make check. Thanks for the testing. The segfault appears to be related to the foreign function interface; the generational GC works fine now. I've therefore released libsigsegv 2.10 and committed the change into clisp. Regarding the segfaulting test, you may follow up with Sam on clisp-devel. My first, uninformed suspicion is that it's related to the representation of NULL pointers or stack addresses on this platform (I remember something about bit 31). Bruno -- In memoriam Albert Merz <http://en.wikipedia.org/wiki/Albert_Merz> |
|
From: Christoph E. <chr...@de...> - 2011-04-03 14:07:16
|
Hi!
Sorry for not getting to it quicker.
Bruno Haible <br...@cl...> writes:
> On 2011-03-13, you reported that with the Linux/S390 specific modifications
> to libsigsegv clisp did not yet work correctly. I proposed a patch that ought
> to fix this:
> <http://lists.gnu.org/archive/html/bug-libsigsegv/2011-03/msg00007.html>
>
> Did you have time to test this patch? I would not want to commit into clisp
> a patch that is not tested, and I don't want to release libsigsegv 2.10
> before it has been asserted that it works fine in clisp.
Using the -pre libsigsegv I can build clisp fine and it appears to
be basically working -- playing around doesn't result in any obvious
problems. However `make check` is segfaulting. I've attached output of
make check.
Regards
Christoph
|
|
From: SourceForge.net <no...@so...> - 2011-04-03 13:02:21
|
Bugs item #3017588, was opened at 2010-06-17 15:12 Message generated for change (Settings changed) made by haible You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3017588&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: build problems >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Pascal J. Bourguignon (informatimago) Assigned to: Bruno Haible (haible) Summary: ari80386.c not generated <= discrepancy kernel/system Initial Comment: I'm running on Xen-4 a linux kernel for x86_64 (in an Intel i7), a virtual machine containing a debian lenny 32-bit system. uname -m reports x86_64, but all the tools and libraries are 32-bit. [pjb@mdi-development-1 localhost:12.0 ~]$ file /bin/ls /usr/lib/libcallback.so.0.0.0 /bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped /usr/lib/libcallback.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped [pjb@mdi-development-1 localhost:12.0 ~]$ uname -m x86_64 When compiling clisp-2.48 # Doing INSTALL-PACKAGE on #<TARBALL-PACKAGE clisp> { ( source /usr/local/env.sh ; tar jxf "clisp-2.48.tar.bz2" ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } { ( source /usr/local/env.sh ; ( cd "clisp-2.48" ; patch -p2 < ../"clisp-2.48"-sudo.patch ) ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } # Current directory: /home/pjb/firms/medicalis/src/tools/clisp-2.48/ { ( source /usr/local/env.sh ; CFLAGS=-I"/usr/local"/include LDFLAGS=-L"/usr/local"/lib ./configure --prefix="/usr/local" && (cd src ; make && make install) ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } the compilation fails with this error: gcc -I/home/pjb/firms/medicalis/src/tools/clisp-2.48/src/gllib -I/usr/local/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compa\ re -Wno-format-nonliteral -O -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -c lisparit.c In file included from lisparit.d:28: arilev1.d:257:28: error: ari80386.c: No such file or directory make[1]: *** [lisparit.o] Error 1 make[1]: Leaving directory `/home/pjb/firms/medicalis/src/tools/clisp-2.48/src' configure identified a 64-bit system: checking build system type... (cached) x86_64-unknown-linux-gnu checking host system type... (cached) x86_64-unknown-linux-gnu but this is only the kernel that is 64-bit. Perhaps there would be a way to know what gcc can compile? Or to generate in all cases ari80386.c ? Here are the ari*.c files: [pjb@mdi-development-1 localhost:11.0 tools]$ ls clisp-2.48/src/ari*.c clisp-2.48/src/ari80386.msvc.c clisp-2.48/src/arilev1c.c clisp-2.48/src/aridecl.c clisp-2.48/src/arilev1e.c clisp-2.48/src/arilev0.c clisp-2.48/src/arilev1i.c clisp-2.48/src/arilev1.c [pjb@mdi-development-1 localhost:11.0 tools]$ ---------------------------------------------------------------------- Comment By: Bruno Haible (haible) Date: 2011-04-03 15:01 Message: Find attached a patch for clisp 2.49. In HEAD it was fixed by Sam on 2010-07-21 and 2010-09-01, through modifications in makemake.in. Note that this will only work if the linker (/usr/bin/ld) supports linking 32-bit objects. On a bi-arch openSUSE 11.0 system, my linker reports an error in the "ld -r ..." command: ld -r -o lisp.o spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o unixaux.o built.o ari80386.o ld: Relocatable linking with relocations from format elf32-i386 (spvw.o) to format elf64-x86-64 (lisp.o) is not supported make: *** [lisp.a] Error 1 Adding "--oformat elf32-i386" does not help, it produces the error: ld: Relocatable linking with relocations from format elf32-i386 (spvw.o) to format elf32-i386 (lisp.o) is not supported As a workaround, I really have to use a 32-bit ELF linker instead of /usr/bin/ld. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-31 17:46 Message: did you try the makemake.in patch? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-06-22 16:09 Message: here is what I see on my 64-bit laptop: # host system: hostname = "sysu76" HSYS = "x86_64" HSYSOS = "linux" HOS = "unix" host_cpu = "x86_64" cpu = "x86_64" host_os = "linux-gnu" host = "x86_64-unknown-linux-gnu" # target system: TSYS = "x86_64" TSYSOS = "linux" TOS = "unix" $ gcc -print-multi-os-directory ../lib i.e., the same output for a 64-bit machine. 1. please try cvs head instead: it has some updated scripts, it might detect the platform differently. if it does not, I think you should ask for help on the autoconf mailing list. 2. please try this patch: --- makemake.in.~1.922.~ 2010-06-18 11:20:25.000000000 -0400 +++ makemake.in 2010-06-22 10:07:32.002447000 -0400 @@ -1123,7 +1123,7 @@ fi case "$host_cpu" in hppa*) cpu=hppa ;; arm*) cpu=arm ;; - x86_64) cpu=x86_64 ;; + x86_64) cpu=i386 ;; ia64) cpu=ia64 ;; mips) cpu=mips ;; mips64*) cpu=mips64 ;; obviously, this will never go through, I just want to make sure that the platform detection is the only problem. ---------------------------------------------------------------------- Comment By: Pascal J. Bourguignon (informatimago) Date: 2010-06-22 02:22 Message: 1- Well, I would like to compile a 32-bit version actually, so I tried CC='gcc -m32' but it ends the same way. 2- [pjb@mdi-development-1 localhost:10.0 src]$ touch makemake [pjb@mdi-development-1 localhost:10.0 src]$ make Makefile ./makemake --verbose --with-dynamic-ffi --prefix=/usr/local > Makefile.tmp with_dynamic_ffi=yes # host system: hostname = "mdi-development-1" HSYS = "x86_64" HSYSOS = "linux" HOS = "unix" host_cpu = "x86_64" cpu = "x86_64" host_os = "linux-gnu" host = "x86_64-unknown-linux-gnu" # target system: TSYS = "x86_64" TSYSOS = "linux" TOS = "unix" mv Makefile Makefile~ mv Makefile.tmp Makefile make: `Makefile' is up to date. 3- [pjb@mdi-development-1 localhost:10.0 src]$ gcc -print-multi-os-directory ../lib [pjb@mdi-development-1 localhost:10.0 src]$ ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-06-17 16:31 Message: 1. you can force building 64-bit clisp using "./configure CC='gcc -m64' ..." 2. please edit Makefile and add "--verbose" to the "./makemake" invocation in the "Makefile:" target; then touch makemake and do "make Makefile". This will print some information to the stderror, please cut and paste it here. 3. please send us "gcc -print-multi-os-directory" output thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3017588&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-04-03 13:01:24
|
Bugs item #3017588, was opened at 2010-06-17 15:12 Message generated for change (Comment added) made by haible You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3017588&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: build problems Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pascal J. Bourguignon (informatimago) Assigned to: Bruno Haible (haible) >Summary: ari80386.c not generated <= discrepancy kernel/system Initial Comment: I'm running on Xen-4 a linux kernel for x86_64 (in an Intel i7), a virtual machine containing a debian lenny 32-bit system. uname -m reports x86_64, but all the tools and libraries are 32-bit. [pjb@mdi-development-1 localhost:12.0 ~]$ file /bin/ls /usr/lib/libcallback.so.0.0.0 /bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped /usr/lib/libcallback.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped [pjb@mdi-development-1 localhost:12.0 ~]$ uname -m x86_64 When compiling clisp-2.48 # Doing INSTALL-PACKAGE on #<TARBALL-PACKAGE clisp> { ( source /usr/local/env.sh ; tar jxf "clisp-2.48.tar.bz2" ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } { ( source /usr/local/env.sh ; ( cd "clisp-2.48" ; patch -p2 < ../"clisp-2.48"-sudo.patch ) ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } # Current directory: /home/pjb/firms/medicalis/src/tools/clisp-2.48/ { ( source /usr/local/env.sh ; CFLAGS=-I"/usr/local"/include LDFLAGS=-L"/usr/local"/lib ./configure --prefix="/usr/local" && (cd src ; make && make install) ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } the compilation fails with this error: gcc -I/home/pjb/firms/medicalis/src/tools/clisp-2.48/src/gllib -I/usr/local/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compa\ re -Wno-format-nonliteral -O -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -c lisparit.c In file included from lisparit.d:28: arilev1.d:257:28: error: ari80386.c: No such file or directory make[1]: *** [lisparit.o] Error 1 make[1]: Leaving directory `/home/pjb/firms/medicalis/src/tools/clisp-2.48/src' configure identified a 64-bit system: checking build system type... (cached) x86_64-unknown-linux-gnu checking host system type... (cached) x86_64-unknown-linux-gnu but this is only the kernel that is 64-bit. Perhaps there would be a way to know what gcc can compile? Or to generate in all cases ari80386.c ? Here are the ari*.c files: [pjb@mdi-development-1 localhost:11.0 tools]$ ls clisp-2.48/src/ari*.c clisp-2.48/src/ari80386.msvc.c clisp-2.48/src/arilev1c.c clisp-2.48/src/aridecl.c clisp-2.48/src/arilev1e.c clisp-2.48/src/arilev0.c clisp-2.48/src/arilev1i.c clisp-2.48/src/arilev1.c [pjb@mdi-development-1 localhost:11.0 tools]$ ---------------------------------------------------------------------- >Comment By: Bruno Haible (haible) Date: 2011-04-03 15:01 Message: Find attached a patch for clisp 2.49. In HEAD it was fixed by Sam on 2010-07-21 and 2010-09-01, through modifications in makemake.in. Note that this will only work if the linker (/usr/bin/ld) supports linking 32-bit objects. On a bi-arch openSUSE 11.0 system, my linker reports an error in the "ld -r ..." command: ld -r -o lisp.o spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o unixaux.o built.o ari80386.o ld: Relocatable linking with relocations from format elf32-i386 (spvw.o) to format elf64-x86-64 (lisp.o) is not supported make: *** [lisp.a] Error 1 Adding "--oformat elf32-i386" does not help, it produces the error: ld: Relocatable linking with relocations from format elf32-i386 (spvw.o) to format elf32-i386 (lisp.o) is not supported As a workaround, I really have to use a 32-bit ELF linker instead of /usr/bin/ld. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-31 17:46 Message: did you try the makemake.in patch? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-06-22 16:09 Message: here is what I see on my 64-bit laptop: # host system: hostname = "sysu76" HSYS = "x86_64" HSYSOS = "linux" HOS = "unix" host_cpu = "x86_64" cpu = "x86_64" host_os = "linux-gnu" host = "x86_64-unknown-linux-gnu" # target system: TSYS = "x86_64" TSYSOS = "linux" TOS = "unix" $ gcc -print-multi-os-directory ../lib i.e., the same output for a 64-bit machine. 1. please try cvs head instead: it has some updated scripts, it might detect the platform differently. if it does not, I think you should ask for help on the autoconf mailing list. 2. please try this patch: --- makemake.in.~1.922.~ 2010-06-18 11:20:25.000000000 -0400 +++ makemake.in 2010-06-22 10:07:32.002447000 -0400 @@ -1123,7 +1123,7 @@ fi case "$host_cpu" in hppa*) cpu=hppa ;; arm*) cpu=arm ;; - x86_64) cpu=x86_64 ;; + x86_64) cpu=i386 ;; ia64) cpu=ia64 ;; mips) cpu=mips ;; mips64*) cpu=mips64 ;; obviously, this will never go through, I just want to make sure that the platform detection is the only problem. ---------------------------------------------------------------------- Comment By: Pascal J. Bourguignon (informatimago) Date: 2010-06-22 02:22 Message: 1- Well, I would like to compile a 32-bit version actually, so I tried CC='gcc -m32' but it ends the same way. 2- [pjb@mdi-development-1 localhost:10.0 src]$ touch makemake [pjb@mdi-development-1 localhost:10.0 src]$ make Makefile ./makemake --verbose --with-dynamic-ffi --prefix=/usr/local > Makefile.tmp with_dynamic_ffi=yes # host system: hostname = "mdi-development-1" HSYS = "x86_64" HSYSOS = "linux" HOS = "unix" host_cpu = "x86_64" cpu = "x86_64" host_os = "linux-gnu" host = "x86_64-unknown-linux-gnu" # target system: TSYS = "x86_64" TSYSOS = "linux" TOS = "unix" mv Makefile Makefile~ mv Makefile.tmp Makefile make: `Makefile' is up to date. 3- [pjb@mdi-development-1 localhost:10.0 src]$ gcc -print-multi-os-directory ../lib [pjb@mdi-development-1 localhost:10.0 src]$ ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-06-17 16:31 Message: 1. you can force building 64-bit clisp using "./configure CC='gcc -m64' ..." 2. please edit Makefile and add "--verbose" to the "./makemake" invocation in the "Makefile:" target; then touch makemake and do "make Makefile". This will print some information to the stderror, please cut and paste it here. 3. please send us "gcc -print-multi-os-directory" output thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3017588&group_id=1355 |
|
From: Bruno H. <br...@cl...> - 2011-04-03 12:43:57
|
Hi Christoph, On 2011-03-13, you reported that with the Linux/S390 specific modifications to libsigsegv clisp did not yet work correctly. I proposed a patch that ought to fix this: <http://lists.gnu.org/archive/html/bug-libsigsegv/2011-03/msg00007.html> Did you have time to test this patch? I would not want to commit into clisp a patch that is not tested, and I don't want to release libsigsegv 2.10 before it has been asserted that it works fine in clisp. For convenience, here's the proposed patch again. Bruno diff -r 69cbad2fb9bd src/lispbibl.d --- a/src/lispbibl.d Tue Mar 08 19:07:07 2011 -0500 +++ b/src/lispbibl.d Sun Mar 13 18:55:35 2011 +0100 @@ -3003,7 +3003,7 @@ /* Flavor of the garbage collection: normal or generational. */ -#if defined(VIRTUAL_MEMORY) && (defined(SINGLEMAP_MEMORY) || defined(TRIVIALMAP_MEMORY)) && defined(HAVE_WORKING_MPROTECT) && defined(HAVE_SIGSEGV_RECOVERY) && !defined(UNIX_IRIX) && !defined(WIDE_SOFT_LARGEFIXNUM) && (SAFETY < 3) && !defined(NO_GENERATIONAL_GC) +#if defined(VIRTUAL_MEMORY) && (defined(SINGLEMAP_MEMORY) || defined(TRIVIALMAP_MEMORY)) && defined(HAVE_WORKING_MPROTECT) && defined(HAVE_SIGSEGV_RECOVERY) && (defined(SINGLEMAP_MEMORY) || SIGSEGV_FAULT_ADDRESS_ALIGNMENT <= 1UL) && !defined(UNIX_IRIX) && !defined(WIDE_SOFT_LARGEFIXNUM) && (SAFETY < 3) && !defined(NO_GENERATIONAL_GC) /* "generational garbage collection" has some requirements. With Linux, it will only work with 1.1.52, and higher, which will be checked in makemake. On IRIX 6, it worked in the past, but leads to core dumps now. Reason unknown. FIXME! */ diff -r 69cbad2fb9bd src/spvw_fault.d --- a/src/spvw_fault.d Tue Mar 08 19:07:07 2011 -0500 +++ b/src/spvw_fault.d Sun Mar 13 18:55:35 2011 +0100 @@ -125,17 +125,27 @@ var aint pa_address = address & -physpagesize; /* page aligned address */ #ifdef SPVW_PURE_BLOCKS heapnr = typecode(obj); - #elif defined(SPVW_MIXED_BLOCKS_STAGGERED) - heapnr = (address >= mem.heaps[1].heap_mgen_start ? 1 : 0); - #else /* SPVW_MIXED_BLOCKS_OPPOSITE */ - heapnr = (address >= mem.heaps[1].heap_start ? 1 : 0); + #else + #if defined(GENERATIONAL_GC) && defined(SIGSEGV_FAULT_ADDRESS_ALIGNMENT) + /* Compile-time check: SIGSEGV_FAULT_ADDRESS_ALIGNMENT is 1. + Otherwise the address argument is not the exact fault address, but the + address rounded down to page alignment, and the comparisons below may + yield a wrong heapnr. */ + typedef int sigsegv_fault_address_alignment_check[2 * (SIGSEGV_FAULT_ADDRESS_ALIGNMENT == 1UL) - 1]; + #endif + #if defined(SPVW_MIXED_BLOCKS_STAGGERED) + heapnr = (address >= mem.heaps[1].heap_mgen_start ? 1 : 0); + #else /* SPVW_MIXED_BLOCKS_OPPOSITE */ + heapnr = (address >= mem.heaps[1].heap_start ? 1 : 0); + #endif #endif { #ifdef GENERATIONAL_GC var Heap* heap = &mem.heaps[heapnr]; if (!is_heap_containing_objects(heapnr)) goto error1; - if (!((heap->heap_gen0_start <= address) && (address < heap->heap_gen0_end))) + if (!((heap->heap_gen0_start & ~(SIGSEGV_FAULT_ADDRESS_ALIGNMENT-1) <= address) + && (address < heap->heap_gen0_end))) goto error2; if (heap->physpages == NULL) goto error5; -- In memoriam Albert Merz <http://en.wikipedia.org/wiki/Albert_Merz> |
|
From: SourceForge.net <no...@so...> - 2011-04-01 16:20:08
|
Bugs item #3222889, was opened at 2011-03-18 15:01 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3222889&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: ANSI compliance issue >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Pascal J. Bourguignon (informatimago) Assigned to: Sam Steingold (sds) Summary: (floatp #C(1.2 0)) --> T is wrong. Initial Comment: (floatp #C(1.2 0)) --> T but the standard specifies that when the real part is floating point, the imaginary part must become floating point, and #c(1.2 0.0) is complexp, not floatp. 12.1.5.3 Rule of Canonical Representation for Complex Rationals 12.1.5.3.1 Examples of Rule of Canonical Representation for Complex Rationals ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-04-01 16:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-18 16:05 Message: this is a clisp extension: complex numbers with different types of real and imaginary parts. http://clisp.org/impnotes/num-concepts.html#complex-comp ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-18 16:05 Message: This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you - the reporter - act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3222889&group_id=1355 |
|
From: Sam S. <sd...@gn...> - 2011-04-01 14:08:22
|
Hi, > * Christoph Egger <pue...@qr...> [2011-03-07 16:38:21 +0100]: > > Testing this kind of issue should be easily possible with a 32bit > linux chroot on a x86_64 system. could you please be more specific wrt what I should do to reproduce the bug? (also, it would be better if you filed a bug report on SF). -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X http://thereligionofpeace.com http://camera.org http://truepeace.org http://iris.org.il http://palestinefacts.org If you try to fail, and succeed, which have you done? |
|
From: <cli...@li...> - 2011-04-01 12:04:28
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: use &with-subprocesses;, &wait;, &usage; (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Fri, 01 Apr 2011 03:18:41 +0000 From: cli...@li... Subject: clisp: use &with-subprocesses;, &wait;, &usage; To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a0acafd6f2a5 changeset: 15312:a0acafd6f2a5f07665839eb21617ad2af3fd5d61 user: Sam Steingold <sd...@po...> date: 2011-03-31 23:18:33 -0400 description: use &with-subprocesses;, &wait;, &usage; diffstat: modules/syscalls/syscalls.xml | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 59, Issue 1 **************************************** |
|
From: SourceForge.net <no...@so...> - 2011-03-31 19:26:09
|
Bugs item #1672132, was opened at 2007-03-01 20:26 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1672132&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: build problems >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Adam Fedor (fgstep) Assigned to: Bruno Haible (haible) Summary: mprotect configure test incorrect Initial Comment: The configure test for mprotect appears to be incorrect, producing exactly the opposite result it is supposed to. Attached is the patch ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-31 15:26 Message: This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case or answering our other recent requests), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2007-03-04 19:44 Message: Logged In: YES user_id=5735 Originator: NO OK, so you are saying that the tests are too permissive. fine, please add more tests (but first make sure that they will not cause undue loss of mprotect functionality on linux etc) ---------------------------------------------------------------------- Comment By: Adam Fedor (fgstep) Date: 2007-03-04 17:58 Message: Logged In: YES user_id=1326233 Originator: YES Err, OK I see that. But now the test makes absolutely no sense at all. All it seems to be testing is that you are properly prohibited from looking at or writing to memory that has been protected correctly. It certainly doesn't check to see if you can make memory writeable or even executable, which is what trampoline.c expects to use it for. I'll defer to other bugs (#1531290 for instance), which encapsulate what I really want fixed... ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2007-03-04 13:01 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2007-03-04 13:01 Message: Logged In: YES user_id=5735 Originator: NO I deleted my patch because I now think that the original code is correct. please examine the comments: /* this should cause an exception or signal */ ==> action-if-succeed="no_mprotect=1" /* this should not cause an exception or signal */ ==> action-if-fail="no_mprotect=1" ---------------------------------------------------------------------- Comment By: Adam Fedor (fgstep) Date: 2007-03-04 12:48 Message: Logged In: YES user_id=1326233 Originator: YES OK. I missed that one. Thanks. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2007-03-03 23:46 Message: Logged In: YES user_id=5735 Originator: NO then why are you changing the 2 places only? see my patch (attached): now no_mprotect is handled identically in all 5 places. File Added: mprotect.m4.diff ---------------------------------------------------------------------- Comment By: Adam Fedor (fgstep) Date: 2007-03-02 00:37 Message: Logged In: YES user_id=1326233 Originator: YES The autoconf code for AC_TRY_RUN is roughly: AC_TRY_RUN(program, action-if-succeed, action-if-fail, action-if-cross-compile), and in mprotect.m4, it's implemented roughly as: AC_TRY_RUN('mprotect program', no_mprotect=1, , ) so no_mprotect gets set if the program suceeds (it's correct in the first test but not the others). Later on, it's tested: if test -z "$no_mprotect"; cl_cv_func_mprotect_works=yes - so the test shows mprotect as working if no_mprotect is NOT set, but the previous AC_TRY_RUN tests set no_mprotect if it does works. I can show you a config.log file where the mprotect test clearly fails, but HAVE_WORKING_MPROTECT is defined. Perhaps it's worked all these years for other reasons? Actually, I found this on powerpc-apple-darwin8.8 and fixed it, but this just causes other problems, which may be similar to bug #1535284. Perhaps I just need to look at the wider issue of what's not working... ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2007-03-02 00:00 Message: Logged In: YES user_id=5735 Originator: NO the current code have been detecting mprotect just fine for many years. could you please be more specific - what are you unhappy about? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1672132&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-03-31 19:22:29
|
Bugs item #1731469, was opened at 2007-06-05 11:04 Message generated for change (Settings changed) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1731469&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: None >Status: Closed Resolution: Fixed Priority: 3 Private: No Submitted By: Jörg Höhle (hoehle) Assigned to: Sam Steingold (sds) Summary: loop expansion: spurious LET twice Initial Comment: Hi, Looking at CLISP macroexpansions after my (gensym "NAME-") patches made me discover the following irregularity. The pattern variable for loop destructuring is bound twice. I don't think the reason for duplication is special tricks with shadowing, I rather believe it's a small bug, producing no known error. (loop for nil on '(1 2 . 3) count t) (MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-ERROR))) (BLOCK NIL (LET ((#:PATTERN-6274 NIL)) ; here (LET ((#:LIST-6273 '(1 2 . 3))) (PROGN (LET ((#:PATTERN-6274 NIL)) ; here (LET ((#:ACCUNUM-VAR-6275 0)) (MACROLET ((LOOP-FINISH NIL '(GO SYSTEM::END-LOOP))) (TAGBODY SYSTEM::BEGIN-LOOP (WHEN (ATOM #:LIST-6273) (LOOP-FINISH)) (SETQ #:PATTERN-6274 #:LIST-6273) (PROGN (WHEN T (INCF #:ACCUNUM-VAR-6275))) (PSETQ #:LIST-6273 (CDR #:LIST-6273)) (GO SYSTEM::BEGIN-LOOP) SYSTEM::END-LOOP (MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-WARN) '(GO SYSTEM::END-LOOP))) (RETURN-FROM NIL #:ACCUNUM-VAR-6275))))))))))) ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-31 15:21 Message: thank you for your bug report. the bug has been fixed in the source tree (mercurial/hg). you can either wait for the next release (recommended) or check out the current mercurial tree (see http://clisp.org) and build CLISP from the sources (be advised that between releases the source tree is very unstable and may not even build on your platform). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1731469&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-03-31 19:21:43
|
Bugs item #1731469, was opened at 2007-06-05 11:04 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1731469&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: None Status: Open >Resolution: Fixed Priority: 3 Private: No Submitted By: Jörg Höhle (hoehle) >Assigned to: Sam Steingold (sds) Summary: loop expansion: spurious LET twice Initial Comment: Hi, Looking at CLISP macroexpansions after my (gensym "NAME-") patches made me discover the following irregularity. The pattern variable for loop destructuring is bound twice. I don't think the reason for duplication is special tricks with shadowing, I rather believe it's a small bug, producing no known error. (loop for nil on '(1 2 . 3) count t) (MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-ERROR))) (BLOCK NIL (LET ((#:PATTERN-6274 NIL)) ; here (LET ((#:LIST-6273 '(1 2 . 3))) (PROGN (LET ((#:PATTERN-6274 NIL)) ; here (LET ((#:ACCUNUM-VAR-6275 0)) (MACROLET ((LOOP-FINISH NIL '(GO SYSTEM::END-LOOP))) (TAGBODY SYSTEM::BEGIN-LOOP (WHEN (ATOM #:LIST-6273) (LOOP-FINISH)) (SETQ #:PATTERN-6274 #:LIST-6273) (PROGN (WHEN T (INCF #:ACCUNUM-VAR-6275))) (PSETQ #:LIST-6273 (CDR #:LIST-6273)) (GO SYSTEM::BEGIN-LOOP) SYSTEM::END-LOOP (MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-WARN) '(GO SYSTEM::END-LOOP))) (RETURN-FROM NIL #:ACCUNUM-VAR-6275))))))))))) ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-31 15:21 Message: thank you for your bug report. the bug has been fixed in the source tree (mercurial/hg). you can either wait for the next release (recommended) or check out the current mercurial tree (see http://clisp.org) and build CLISP from the sources (be advised that between releases the source tree is very unstable and may not even build on your platform). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1731469&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-03-31 15:46:04
|
Bugs item #3017588, was opened at 2010-06-17 09:12 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3017588&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: build problems Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pascal J. Bourguignon (informatimago) Assigned to: Bruno Haible (haible) Summary: ari80384.c not generated <= discrepancy kernel/system Initial Comment: I'm running on Xen-4 a linux kernel for x86_64 (in an Intel i7), a virtual machine containing a debian lenny 32-bit system. uname -m reports x86_64, but all the tools and libraries are 32-bit. [pjb@mdi-development-1 localhost:12.0 ~]$ file /bin/ls /usr/lib/libcallback.so.0.0.0 /bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped /usr/lib/libcallback.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped [pjb@mdi-development-1 localhost:12.0 ~]$ uname -m x86_64 When compiling clisp-2.48 # Doing INSTALL-PACKAGE on #<TARBALL-PACKAGE clisp> { ( source /usr/local/env.sh ; tar jxf "clisp-2.48.tar.bz2" ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } { ( source /usr/local/env.sh ; ( cd "clisp-2.48" ; patch -p2 < ../"clisp-2.48"-sudo.patch ) ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } # Current directory: /home/pjb/firms/medicalis/src/tools/clisp-2.48/ { ( source /usr/local/env.sh ; CFLAGS=-I"/usr/local"/include LDFLAGS=-L"/usr/local"/lib ./configure --prefix="/usr/local" && (cd src ; make && make install) ) >> /home/pjb/firms/medicalis/src/tools/clisp-2.48.log 2>&1 ; } the compilation fails with this error: gcc -I/home/pjb/firms/medicalis/src/tools/clisp-2.48/src/gllib -I/usr/local/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compa\ re -Wno-format-nonliteral -O -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -c lisparit.c In file included from lisparit.d:28: arilev1.d:257:28: error: ari80386.c: No such file or directory make[1]: *** [lisparit.o] Error 1 make[1]: Leaving directory `/home/pjb/firms/medicalis/src/tools/clisp-2.48/src' configure identified a 64-bit system: checking build system type... (cached) x86_64-unknown-linux-gnu checking host system type... (cached) x86_64-unknown-linux-gnu but this is only the kernel that is 64-bit. Perhaps there would be a way to know what gcc can compile? Or to generate in all cases ari80386.c ? Here are the ari*.c files: [pjb@mdi-development-1 localhost:11.0 tools]$ ls clisp-2.48/src/ari*.c clisp-2.48/src/ari80386.msvc.c clisp-2.48/src/arilev1c.c clisp-2.48/src/aridecl.c clisp-2.48/src/arilev1e.c clisp-2.48/src/arilev0.c clisp-2.48/src/arilev1i.c clisp-2.48/src/arilev1.c [pjb@mdi-development-1 localhost:11.0 tools]$ ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-03-31 11:46 Message: did you try the makemake.in patch? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-06-22 10:09 Message: here is what I see on my 64-bit laptop: # host system: hostname = "sysu76" HSYS = "x86_64" HSYSOS = "linux" HOS = "unix" host_cpu = "x86_64" cpu = "x86_64" host_os = "linux-gnu" host = "x86_64-unknown-linux-gnu" # target system: TSYS = "x86_64" TSYSOS = "linux" TOS = "unix" $ gcc -print-multi-os-directory ../lib i.e., the same output for a 64-bit machine. 1. please try cvs head instead: it has some updated scripts, it might detect the platform differently. if it does not, I think you should ask for help on the autoconf mailing list. 2. please try this patch: --- makemake.in.~1.922.~ 2010-06-18 11:20:25.000000000 -0400 +++ makemake.in 2010-06-22 10:07:32.002447000 -0400 @@ -1123,7 +1123,7 @@ fi case "$host_cpu" in hppa*) cpu=hppa ;; arm*) cpu=arm ;; - x86_64) cpu=x86_64 ;; + x86_64) cpu=i386 ;; ia64) cpu=ia64 ;; mips) cpu=mips ;; mips64*) cpu=mips64 ;; obviously, this will never go through, I just want to make sure that the platform detection is the only problem. ---------------------------------------------------------------------- Comment By: Pascal J. Bourguignon (informatimago) Date: 2010-06-21 20:22 Message: 1- Well, I would like to compile a 32-bit version actually, so I tried CC='gcc -m32' but it ends the same way. 2- [pjb@mdi-development-1 localhost:10.0 src]$ touch makemake [pjb@mdi-development-1 localhost:10.0 src]$ make Makefile ./makemake --verbose --with-dynamic-ffi --prefix=/usr/local > Makefile.tmp with_dynamic_ffi=yes # host system: hostname = "mdi-development-1" HSYS = "x86_64" HSYSOS = "linux" HOS = "unix" host_cpu = "x86_64" cpu = "x86_64" host_os = "linux-gnu" host = "x86_64-unknown-linux-gnu" # target system: TSYS = "x86_64" TSYSOS = "linux" TOS = "unix" mv Makefile Makefile~ mv Makefile.tmp Makefile make: `Makefile' is up to date. 3- [pjb@mdi-development-1 localhost:10.0 src]$ gcc -print-multi-os-directory ../lib [pjb@mdi-development-1 localhost:10.0 src]$ ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-06-17 10:31 Message: 1. you can force building 64-bit clisp using "./configure CC='gcc -m64' ..." 2. please edit Makefile and add "--verbose" to the "./makemake" invocation in the "Makefile:" target; then touch makemake and do "make Makefile". This will print some information to the stderror, please cut and paste it here. 3. please send us "gcc -print-multi-os-directory" output thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3017588&group_id=1355 |
|
From: <cli...@li...> - 2011-03-31 12:03:54
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. test: 7 file (cli...@li...) 2. test: 8 file (cli...@li...) 3. test: 9 file (cli...@li...) 4. test: 10 file (cli...@li...) 5. test: 11 file (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Wed, 30 Mar 2011 18:35:43 +0000 From: cli...@li... Subject: test: 7 file To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/test/test/rev/a1f2ecb020ab changeset: 6:a1f2ecb020ab8b55a50671857d8085ed2e236b13 user: Sam Steingold <sd...@po...> date: 2011-03-30 14:35:33 -0400 description: 7 file diffstat: file | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (8 lines): diff -r 122ae46b04d1 -r a1f2ecb020ab file --- a/file Wed Mar 30 14:32:36 2011 -0400 +++ b/file Wed Mar 30 14:35:33 2011 -0400 @@ -4,3 +4,4 @@ 2011-03-30 14:21:34 2011-03-30 14:26:39 2011-03-30 14:32:36 +2011-03-30 14:35:33 |
|
From: SourceForge.net <no...@so...> - 2011-03-29 22:55:43
|
Bugs item #3258485, was opened at 2011-03-29 17:52 Message generated for change (Settings changed) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3258485&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: ANSI compliance issue >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Sam Steingold (sds) >Assigned to: Sam Steingold (sds) Summary: HANDLER-BIND cannot handle handlers defined using CONSTANTLY Initial Comment: (compile nil (lambda (arg) (handler-bind ((error (constantly nil))) (car arg)))) *** - Compiler bug!! Occurred in ASSEMBLE-LAP at (HANDLER-BEGIN). this bug was present before the 2005-01-21 patch which made %HANDLER-BIND have a function syntax. it is now (after the 2011-03-29 patch which fixed bug#3147908) present again. note that asdf.lisp cannot be compiled ootb until this bug is fixed. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-29 18:55 Message: thank you for your bug report. the bug has been fixed in the source tree (mercurial/hg). you can either wait for the next release (recommended) or check out the current mercurial tree (see http://clisp.org) and build CLISP from the sources (be advised that between releases the source tree is very unstable and may not even build on your platform). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-29 18:17 Message: the following seems to work around the bug: (defun fix-handler-begin (list) "replace (... (HANDLER-BEGIN) ...) with (... (HANDLER-BEGIN&PUSH) (POP) ...)" (do ((tail list (cdr tail))) ((endp tail) list) (when (equal (car tail) '(SYS::HANDLER-BEGIN)) (setf (car tail) '(SYS::HANDLER-BEGIN&PUSH) (cdr tail) (cons '(SYS::POP) (cdr tail)) tail (cddr tail))))) (trace (sys::insert-combined-LAPs :post (fix-handler-begin (car *trace-values*)))) I wonder if this is the right fix... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3258485&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-03-29 22:17:23
|
Bugs item #3258485, was opened at 2011-03-29 17:52 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3258485&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: ANSI compliance issue Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Steingold (sds) Assigned to: Bruno Haible (haible) Summary: HANDLER-BIND cannot handle handlers defined using CONSTANTLY Initial Comment: (compile nil (lambda (arg) (handler-bind ((error (constantly nil))) (car arg)))) *** - Compiler bug!! Occurred in ASSEMBLE-LAP at (HANDLER-BEGIN). this bug was present before the 2005-01-21 patch which made %HANDLER-BIND have a function syntax. it is now (after the 2011-03-29 patch which fixed bug#3147908) present again. note that asdf.lisp cannot be compiled ootb until this bug is fixed. ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-03-29 18:17 Message: the following seems to work around the bug: (defun fix-handler-begin (list) "replace (... (HANDLER-BEGIN) ...) with (... (HANDLER-BEGIN&PUSH) (POP) ...)" (do ((tail list (cdr tail))) ((endp tail) list) (when (equal (car tail) '(SYS::HANDLER-BEGIN)) (setf (car tail) '(SYS::HANDLER-BEGIN&PUSH) (cdr tail) (cons '(SYS::POP) (cdr tail)) tail (cddr tail))))) (trace (sys::insert-combined-LAPs :post (fix-handler-begin (car *trace-values*)))) I wonder if this is the right fix... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3258485&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-03-29 14:23:27
|
Bugs item #3206412, was opened at 2011-03-11 08:23 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3206412&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Christoph Bauer (fridolin) Assigned to: Bruno Haible (haible) Summary: Installation on HP-UX 11.11 Initial Comment: in principle it is possible to install clisp on HP-UX. But I had some problems. You have to configure with --without-dynamic-module. Otherwise you get an error later. You could put this as a note in unix/PLATFORMS. unix/PLATFORM says, you should be able to compile clisp with "cc -Aa -z -D_HPUX_SOURCE" But at least you would need -Ae instead of -Aa. And even then you get either a undefined symbol divu_6432_3232_. (There was a mail in the mailing list about that). But much more success you have with gcc, which is fine for me. In the makemake (clisp-4.49was a match of hpux9* and hpux10*, but not hpux11, but this seems to be fixed in the CVS version. In the Makefile there is a line m=`cd ../modules/$@; pwd`; \ unfortunatly it doesn't work on HP-UX. (maybe the string contains a newline or so. it seems to be good, but I can't do an `ls $m') I replaced it by m=$(realpath ../modules/$@) ; \ because I have GNU make here and I changed the next line to if test -f $$m/configure -a \( ! -f $@/config.status -o $$m/configure -nt $@/config.status \); then ( cd $@ ; $(RMRF) gllib;\ (This was also needed with make SHELL=bash. Is my bash 2.04 too old?). With ffcall installed, i get this error (CVS Version): subrkw.d: In function 'init_subr_tab_2': subrkw.d:219: error: 'struct symbol_tab_' has no member named 'S_Krequire' subrkw.d:220: error: 'struct subr_tab_' has no member named 'D_open_foreign_library' So I configured with --without-ffcall I ignored this warning time.d:565: warning: integer overflow in expression The last problem (solved with #if 0) .../clisp/src/gllib/sys/socket.h:398: error: redefinition of 'struct sockaddr_storage' and then finally: i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `-+-' / 8 8 8 ooooo 8oooo `-__|__-' 8 8 8 8 8 | 8 o 8 8 o 8 8 ------+------ ooooo 8oooooo ooo8ooo ooooo 8 Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.cons.org/> ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-03-29 10:23 Message: glad to here that clisp works for you. please report the ac_cv_type_struct_sockaddr_storage issue to the gnulib maintainers (bug...@gn...); this variable comes from their file sys_socket_h.m4. ---------------------------------------------------------------------- Comment By: Christoph Bauer (fridolin) Date: 2011-03-29 09:03 Message: For completeness 1-6: 1. HP-UX kl-hp1 B.11.11 U 9000/785 unknown unknown HP-UX gcc-4.3.2 2. CVS, 29 march 2011 3. with the new bash, this works with untouched sources now: export ac_cv_type_struct_sockaddr_storage=yes ./configure --without-ffcall --without-dynamic-modules --prefix=... cd src make && make install 4. n/a 5. "2.49+ (2010-07-17) (built 3509783157) (memory 3509783956)" 6. (:QUICKLISP :ASDF2 :ASDF :REGEXP :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :SOCKETS :GENERIC-STREAMS :LOGICAL-PATHNAMES :SCREEN :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :UNIX) quicklisp is already loaded :-) With my new trick export ac_cv_type_struct_sockaddr_storage=yes I can install clisp on my system. Please close the Bug. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-23 16:57 Message: so, did upgrading bash fix all your problems? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-23 16:57 Message: this is the standard request for more information. 1. what is your platform? ("uname -a" on a Unix system) compiler version? libc (on Linux)? 2. where did you get the sources? when? (absolute dates are prefered over the relative ones) 3. how did you build CLISP? (what command, options &c) please do a clean build (remove your build directory and build CLISP with "./configure --build build" or at least do a "make distclean" before "make") 4. if you are using pre-built binaries, the problem is likely to be in the incompatibilities between the platform on which the binary was built and yours; please try compiling the sources. 5. what is the output of (lisp-implementation-version)? 6. what is the value of *features*? 7. please supply the full output (copy and paste) of all the error messages. If you cannot build CLISP, you can obviously skip 5 and 6, but then you should provide more information in 1. please see <http://clisp.cons.org/clisp.html#bugs> for more information. Thanks. PS. This bug report is now marked "pending" and will auto-close unless you respond (in which case it will auto-re-open). ---------------------------------------------------------------------- Comment By: Christoph Bauer (fridolin) Date: 2011-03-11 10:50 Message: after upgrading to bash 4.2, i don't need the changes in the Makefile (realpath + test) anymore ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3206412&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-03-29 13:03:51
|
Bugs item #3206412, was opened at 2011-03-11 13:23 Message generated for change (Settings changed) made by fridolin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3206412&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christoph Bauer (fridolin) Assigned to: Bruno Haible (haible) Summary: Installation on HP-UX 11.11 Initial Comment: in principle it is possible to install clisp on HP-UX. But I had some problems. You have to configure with --without-dynamic-module. Otherwise you get an error later. You could put this as a note in unix/PLATFORMS. unix/PLATFORM says, you should be able to compile clisp with "cc -Aa -z -D_HPUX_SOURCE" But at least you would need -Ae instead of -Aa. And even then you get either a undefined symbol divu_6432_3232_. (There was a mail in the mailing list about that). But much more success you have with gcc, which is fine for me. In the makemake (clisp-4.49was a match of hpux9* and hpux10*, but not hpux11, but this seems to be fixed in the CVS version. In the Makefile there is a line m=`cd ../modules/$@; pwd`; \ unfortunatly it doesn't work on HP-UX. (maybe the string contains a newline or so. it seems to be good, but I can't do an `ls $m') I replaced it by m=$(realpath ../modules/$@) ; \ because I have GNU make here and I changed the next line to if test -f $$m/configure -a \( ! -f $@/config.status -o $$m/configure -nt $@/config.status \); then ( cd $@ ; $(RMRF) gllib;\ (This was also needed with make SHELL=bash. Is my bash 2.04 too old?). With ffcall installed, i get this error (CVS Version): subrkw.d: In function 'init_subr_tab_2': subrkw.d:219: error: 'struct symbol_tab_' has no member named 'S_Krequire' subrkw.d:220: error: 'struct subr_tab_' has no member named 'D_open_foreign_library' So I configured with --without-ffcall I ignored this warning time.d:565: warning: integer overflow in expression The last problem (solved with #if 0) .../clisp/src/gllib/sys/socket.h:398: error: redefinition of 'struct sockaddr_storage' and then finally: i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `-+-' / 8 8 8 ooooo 8oooo `-__|__-' 8 8 8 8 8 | 8 o 8 8 o 8 8 ------+------ ooooo 8oooooo ooo8ooo ooooo 8 Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.cons.org/> ---------------------------------------------------------------------- >Comment By: Christoph Bauer (fridolin) Date: 2011-03-29 13:03 Message: For completeness 1-6: 1. HP-UX kl-hp1 B.11.11 U 9000/785 unknown unknown HP-UX gcc-4.3.2 2. CVS, 29 march 2011 3. with the new bash, this works with untouched sources now: export ac_cv_type_struct_sockaddr_storage=yes ./configure --without-ffcall --without-dynamic-modules --prefix=... cd src make && make install 4. n/a 5. "2.49+ (2010-07-17) (built 3509783157) (memory 3509783956)" 6. (:QUICKLISP :ASDF2 :ASDF :REGEXP :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :SOCKETS :GENERIC-STREAMS :LOGICAL-PATHNAMES :SCREEN :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :UNIX) quicklisp is already loaded :-) With my new trick export ac_cv_type_struct_sockaddr_storage=yes I can install clisp on my system. Please close the Bug. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-23 20:57 Message: so, did upgrading bash fix all your problems? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2011-03-23 20:57 Message: this is the standard request for more information. 1. what is your platform? ("uname -a" on a Unix system) compiler version? libc (on Linux)? 2. where did you get the sources? when? (absolute dates are prefered over the relative ones) 3. how did you build CLISP? (what command, options &c) please do a clean build (remove your build directory and build CLISP with "./configure --build build" or at least do a "make distclean" before "make") 4. if you are using pre-built binaries, the problem is likely to be in the incompatibilities between the platform on which the binary was built and yours; please try compiling the sources. 5. what is the output of (lisp-implementation-version)? 6. what is the value of *features*? 7. please supply the full output (copy and paste) of all the error messages. If you cannot build CLISP, you can obviously skip 5 and 6, but then you should provide more information in 1. please see <http://clisp.cons.org/clisp.html#bugs> for more information. Thanks. PS. This bug report is now marked "pending" and will auto-close unless you respond (in which case it will auto-re-open). ---------------------------------------------------------------------- Comment By: Christoph Bauer (fridolin) Date: 2011-03-11 15:50 Message: after upgrading to bash 4.2, i don't need the changes in the Makefile (realpath + test) anymore ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3206412&group_id=1355 |
|
From: SourceForge.net <no...@so...> - 2011-03-28 22:05:49
|
Bugs item #3147908, was opened at 2010-12-29 20:14 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3147908&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Steingold (sds) Assigned to: Sam Steingold (sds) Summary: too much consing when compiling IGNORE-ERRORS Initial Comment: in GNU CLISP 2.33.1 (2004-05-22) (and earlier) (disassemble (LAMBDA (X Y) (IGNORE-ERRORS (= X Y)))) Disassembly of function :LAMBDA (CONST 0) = NIL (CONST 1) = (#(ERROR 15) 2 . 1) 2 required arguments 0 optional arguments No rest parameter No keyword parameters 16 byte-code instructions: 0 (BLOCK-OPEN 0 L24) 3 (HANDLER-OPEN 1 L15) ; (#(ERROR 15) 2 . 1) 5 (LOAD&PUSH 9) 6 (LOAD&PUSH 9) 7 (CALLSR 1 45) ; = 10 (SKIP 4) 12 (BLOCK-CLOSE) 13 (SKIP&RET 3) 15 L15 15 (HANDLER-BEGIN&PUSH) 16 (NIL&PUSH) 17 (LOAD&PUSH 1) 18 (STACK-TO-MV 2) 20 (RETURN-FROM-I 0 0 2) 24 L24 24 (SKIP&RET 3) in GNU CLISP 2.34 (2005-07-20) (and later): (disassemble (LAMBDA (X Y) (IGNORE-ERRORS (= X Y)))) Disassembly of function :LAMBDA (CONST 0) = NIL (CONST 1) = #<COMPILED-FUNCTION :LAMBDA-1> (CONST 2) = #<COMPILED-FUNCTION :LAMBDA-2> (CONST 3) = (#(ERROR 32) 2 . 1) 2 required arguments 0 optional arguments No rest parameter No keyword parameters 25 byte-code instructions: 0 (NIL) 1 (MAKE-VECTOR1&PUSH 2) 3 (LOAD&STOREC 3 0 0) 7 (LOAD&STOREC 2 0 1) 11 (BLOCK-OPEN 0 L47) 14 (LOAD&PUSH 2) 15 (COPY-CLOSURE&PUSH 1 1) ; #<COMPILED-FUNCTION :LAMBDA-1> 18 (LOAD&PUSH 4) 19 (COPY-CLOSURE&PUSH 2 1) ; #<COMPILED-FUNCTION :LAMBDA-2> 22 (HANDLER-OPEN 3 L32) ; (#(ERROR 32) 2 . 1) 24 (LOAD&PUSH 4) 25 (FUNCALL 0) 27 (SKIP 6) 29 (BLOCK-CLOSE) 30 (SKIP&RET 4) 32 L32 32 (HANDLER-BEGIN&PUSH) 33 (LOADI&PUSH 0 0 1) 37 (FUNCALL&PUSH 0) 39 (LOAD&PUSH 1) 40 (FUNCALL 1) 42 (SKIPSP 3 1) 45 (SKIP&RET 2) 47 L47 47 (SKIP&RET 4) which is longer and conses more. ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2011-03-28 18:05 Message: the simple version (defmacro handler-bind (clauses &body body) `(LOCALLY (DECLARE (COMPILE)) (SYS::%HANDLER-BIND #'(LAMBDA () ,@body) ,@(mapcan #'(lambda (clause) (destructuring-bind (typespec handler) clause `(',typespec ,handler))) clauses)))) does not work. before the patch c-handler-bind received the non-macro-expanded version which made all it possible to inline everything. ---------------------------------------------------------------------- Comment By: Bruno Haible (haible) Date: 2010-12-30 21:25 Message: Yes I agree it's most likely caused by this patch: 2005-01-21 Sam Steingold <sd...@gn...> * condition.lisp (handler-bind): use the function syntax for %HANDLER-BIND * compiler.lisp (quote-p): new function (l-constantp, c-constantp): use it (c-form-table): do not handle HANDLER-BIND specially (c-HANDLER-BIND): handle HANDLER-BIND in function syntax * init.lisp (%expand-form): do not handle %HANDLER-BIND specially * clos-class3.lisp (reinitialize-instance-<defined-class>): use use the function syntax for %HANDLER-BIND * clos-genfun4.lisp (generic-function-undeterminedp): ditto * clos-methcomb2.lisp (any-method-combination-check-options): ditto The NEWS entry for this patch was: "Third party code walkers can now handle HANDLER-BIND et al." So the objective was to remove the need for code walkers to handle sys::%handler-bind. The patch itself was fine. The problem is that this macroexpansion: > (macroexpand-1 (third (macroexpand-1 '(IGNORE-ERRORS (= X Y))))) (LET ((#:G2727 #'(LAMBDA NIL (PROGN #'(LAMBDA (CONDITION) (RETURN-FROM #:G2726 (VALUES NIL CONDITION))) ) ) ) (#:G2728 #'(LAMBDA NIL (PROGN (= X Y)))) ) (LOCALLY (DECLARE (COMPILE)) (SYSTEM::%HANDLER-BIND #:G2728 'ERROR #'(LAMBDA (CONDITION) (FUNCALL (FUNCALL #:G2727) CONDITION)) ) ) ) is not compiled to good code. This needs work in the compiler. A smaller example is: (disassemble (LAMBDA (X Y) (HANDLER-BIND () (= X Y)))) Macro expansion: (LET ((#:G2784 #'(LAMBDA NIL (PROGN (= X Y))))) (LOCALLY (DECLARE (COMPILE)) (SYSTEM::%HANDLER-BIND #:G2784)) ) clisp's function inliner is not powerful enough to resolve this. I don't remember whether it is because it does not do data flow analysis or because the LOCALLY form introduces a new declaration scope. But there is a way to make this special case work better without beefing up the function inliner nor the data flow analysis... ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-12-30 09:12 Message: somehow I cannot compile 2.34 on my laptop (intparam.h:7:2: error: #error "Integers of type int have no binary representation!!" &c) so my investigation is limited to the lisp side. looks like older clisp compiles the call to = and values inline which 2.34 creates closures for that (which is kind of crazy). apparently caused by my 2005-01-21 patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3147908&group_id=1355 |
32 messages has been excluded from this view by a project administrator.
