From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER Date: Thu, 14 Mar 2002 14:43:25 -0800 Sender: guile-devel-admin@gnu.org Message-ID: References: <877kognusb.fsf@zagadka.ping.de> <87vgbzx8y7.fsf@zagadka.ping.de> Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1016146128 25471 127.0.0.1 (14 Mar 2002 22:48:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 14 Mar 2002 22:48:48 +0000 (UTC) Cc: guile-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16le1f-0006cj-00 for ; Thu, 14 Mar 2002 23:48:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16le1O-0004pf-00; Thu, 14 Mar 2002 17:48:30 -0500 Original-Received: from ca-crlsbd-u3-c5c-122.crlsca.adelphia.net ([68.64.59.122] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16ldz8-0004im-00 for ; Thu, 14 Mar 2002 17:46:11 -0500 Original-Received: from ttn by giblet with local (Exim 3.33 #1 (Debian)) id 16ldwT-0007Yb-00; Thu, 14 Mar 2002 14:43:25 -0800 Original-To: mvo@zagadka.ping.de In-Reply-To: <87vgbzx8y7.fsf@zagadka.ping.de> (message from Marius Vollmer on 14 Mar 2002 20:09:36 +0100) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:47 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:47 From: Marius Vollmer Date: 14 Mar 2002 20:09:36 +0100 > this is not guaranteed to work; when invoked w/ "foo > out.x", the shell > does indeed create out.x first, satisfying most CPPs' requirements for > out.x existing to be #included. Sorry, I was confused. I still am, for that matter. How can it happen that during guile-snarf foo.c >foo.x the file foo.x does not exist? It should get created by the shell before guile-snarf is executed. wrt when foo.x is created, we're saying the same thing. (the "this is not guaranteed to work" applies to the whole design -- where we need to regard mere file availability as insufficient.) This is a specific problem on AIX, and the workaround need only work on AIX, so we only need to worry about this when AIX does in fact buffer echoes. I would be surprised if it does... the AIX problem is not that its shell buffers echo, but that its cpp (reportedly) doesn't like to #include an empty .x file. shells (of any platform) buffering subprocess output could be regarded as a problem, but is generally accepted (and desirable for obvious reasons), so we need to re-examine our usage. here's a simple program that tests the relevant behavior: #!/bin/sh echo hi cat zz save to file z, chmod +x z, and invoke it like "z > zz". what do you see? on my system i see: cat: zz: input file is output file and the program exits w/ non-zero status value. substitute cat w/ some other program that eventually needs to read zz, and it is no surprise if that program fails. thus, i conclude that in general this kind of usage is the wrong way to go about things, not because cat failed, but because this style forces us to know the intracacies of each program (e.g., "test -f" works, "test -s" works sometimes, etc), which is a PITA to determine and maintain. big lose. we can special-case for AIX but that way lies madness. the approach i've taken is to look at the AIX problem as an additional constraint that when satisfied should not burden other platforms. Yes, but it is still easier not to change existing code that makes use of the old behavior of guile-snarf. here, the code that needs changing is primarily in makefiles, which are not as big a pain to update as C source, there being fewer makefiles than source files typically. (if someone installs a new guile (and new guile-snarf), they need to modify the makefile to enable some compatibility anyway. in the process if they don't take advantage of the less-crufty new usage and demand "support" for making them do more work, rather than question their dubious judgement (and unslackful ethics) i suppose my response would be to say that guile-snarf was never documented in the first place, and be done w/ it.) on the other hand, i am eager to resolve the SCM_VCELL removal issue in favor of allowing minimal changes to C source. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel