From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22903 invoked by alias); 19 May 2004 15:44:07 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 22893 invoked from network); 19 May 2004 15:44:06 -0000 Received: from unknown (HELO mail3.panix.com) (166.84.1.74) by sourceware.org with SMTP; 19 May 2004 15:44:06 -0000 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id E8B6D982DD; Wed, 19 May 2004 11:44:05 -0400 (EDT) Received: (from kingdon@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i4JFi5305143; Wed, 19 May 2004 11:44:05 -0400 (EDT) Date: Wed, 19 May 2004 15:44:00 -0000 Message-Id: <200405191544.i4JFi5305143@panix5.panix.com> From: Jim Kingdon To: mskala@ansuz.sooke.bc.ca Cc: mcdonald@phy.cmich.edu, xconq7@sources.redhat.com In-reply-to: (mskala@ansuz.sooke.bc.ca) Subject: Re: (remove) doesn't work References: X-SW-Source: 2004/txt/msg00345.txt.bz2 > It looks to me like it would be pretty easy to modify the eval() function > near line 1432 of lisp.c, where it calls remove_from_list(), to detect > when the thing being removed is a list, and in that case iterate over it. Yeah. The only thing that spring to my mind is whether xconq has lists of lists, and whether you'd want remove (c d) from (a b (c d) e) to return (a b e) Off the top of my head I don't even remember whether xconq has lists of lists, much less whether the above functionality is important. > What concerns me is that this looks like the sort of thing that > could have wacky side effects if modified, because even though the > code looks straightforward right there, it seems to tie into LISP > stuff that I don't understand. I will point out that this kind of thing is quite easy to write unit tests for. Some of the existing stuff in autotest.c is strange, in the sense of not cleanly clearing out the game state before each test and getting things set up consistently. But that issue of game state isn't a problem for writing tests for lisp.c style code. Although writing tests won't completely prevent unintended consequences or bugs, it does make it easier to see what the code is supposed to do and verify that it continues to work as it evolves.