From MAILER-DAEMON Sun Jun 01 14:32:43 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MXdL-0002Lk-5A for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 14:32:43 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MXdI-0002J6-J7 for guile-devel@gnu.org; Sun, 01 Jun 2003 14:32:40 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MXdG-0002IJ-Sf for guile-devel@gnu.org; Sun, 01 Jun 2003 14:32:39 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MXZU-00007v-Sn for guile-devel@gnu.org; Sun, 01 Jun 2003 14:28:45 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MXbM-0002ia-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 20:30:40 +0200 Received: (qmail 10934 invoked by uid 1000); 1 Jun 2003 18:27:45 -0000 To: Bruce Korb References: <87iss97ak0.fsf@zagadka.ping.de> <3EC67BA0.2C8FF637@veritas.com> From: Marius Vollmer Date: 01 Jun 2003 20:27:45 +0200 In-Reply-To: <3EC67BA0.2C8FF637@veritas.com> Message-ID: <878yslps9q.fsf@zagadka.ping.de> Lines: 85 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Neil Jerram cc: guile-devel@gnu.org Subject: Re: Re-addition of deprecated stuff to 1.7. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 18:32:41 -0000 Bruce Korb writes: > I'm going to guess here, so please correct me if I am wrong. I > think the client model you are operating with is that someone > develops some code and gets it running on their local system and > then they are happy campers. That is not what I am doing. I am > distributing my stuff to whomever and they will use whatever Guile > happens to be installed on their systems. Some of them are using > libguiles that are quite a few years old. I'd say it is a trade-off between how much pain you are willing to inflict upon your clients and how much pain you are willing to suffer yourself. I think (and hope) it is entirely tolerable to require you clients to install Guile 1.6 when they want to compile your code. They should not need to remove (the run-time parts of) Guile 1.4 for this; thus, software that uses Guile 1.4 will continue to run. Installing Guile 1.6 is no big deal, I hope. The alternative, making sure that your code works with both Guile 1.4 and Guile 1.6, is much more painful and moreover, it wont allow your code to cleanly take advantage of the 'new, improved' features of Guile 1.6. > May I please encourage you to supply configury stuff that is capable > of adapting current interfaces to old Guiles? Too much work for too little gain, I'd say. Instead, we should make it as easy as possible to install Guile 1.6 so that there is no reason not to have it on ones system. > For example, it would be _really_nice_ if it were to define a > scm2newstr_size_t. That way I would not be completely unbuildable > on I32LP64 platforms that still use "int" for the size argument. > Stuff like that would be Really Nice. Yep, that's a bug in Guile 1.6. We haven't been careful enough to keep the public API backwards compatible. For this specific bug, if you really need to work with both API versions, I think it is best to have a configure check in your package that detects what kind of gh_scm2newstr you are compiling against. These configure snippets might be collected in a central place, maybe, when people are willing to maintain such a thing. But given the above, I think it is OK to just fail and require Guile 1.6. > My desire is to use a small stable subset that won't vary very much. > Which is also why I selected the advertized- as-stable gh interface > for as much as possible. *sigh*. There are two reasons (at least) to want stability in an interface: one is that your code works unchanged with multiple versions/implementations of the other side of the API, another is that you don't want to do the work of tracking the changes in an API. In my opinion, the first reason is not very valid for Guile; there should be no reason to require some code to compile _unchanged_ against multiple versions of Guile. When there are such reasons, we should work to remove the reasons, not to make it easier to compile _unchanged_. Not the emphasis on _unchanged_. Not wanting to do much work when tracking API changes is a very good position to take. When changing the Guile API, we should make it in such a way that client code needs to change as little as possible. This often means that it doesn't need to change at all. However, it is not an unbreakable requirement that client code must continue to compile with all new versions of Guile. It is of course good practice to minimize the needed changes, and we probably have botched it a bit in the Guile 1.4 to Guile 1.6 transition. Client code might need to change more than in an ideal transition, but as I said, there should be no strong reasons not to make these changes. > P.S. If _anyone_ can show me how to set the string port file > name and line number, I *sure* would be a happy camper. I'm getting to that in a few minutes... :-) -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 14:48:29 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MXrf-0007OI-SI for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 14:47:31 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MXrF-0005vV-0z for guile-devel@gnu.org; Sun, 01 Jun 2003 14:47:05 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MXr0-0005Lp-Ui for guile-devel@gnu.org; Sun, 01 Jun 2003 14:46:51 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MXqO-00058e-PR for guile-devel@gnu.org; Sun, 01 Jun 2003 14:46:12 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MXsG-0004Eb-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 20:48:08 +0200 Received: (qmail 12682 invoked by uid 1000); 1 Jun 2003 18:45:13 -0000 To: Kevin Ryde References: <3EBC71BF.B2264C7@veritas.com> <874r3t5o1f.fsf@zagadka.ping.de> <3EC6A6CA.94855664@veritas.com> <87of213tk0.fsf@zagadka.ping.de> <87ptmfx0i3.fsf@zip.com.au> From: Marius Vollmer Date: 01 Jun 2003 20:45:13 +0200 In-Reply-To: <87ptmfx0i3.fsf@zip.com.au> Message-ID: <874r39prgm.fsf@zagadka.ping.de> Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: How do I determine the argument type... X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 18:47:30 -0000 Kevin Ryde writes: > Marius Vollmer writes: > > > > Ahh, I see. Yes, it was not a good thing to change gh_new2str that > > way. I'm not sure what to do about this. Changing this back is just > > as bad as the original change from int to size_t. > > The manual still says "int". Damn. > Maybe call it a bug fix and put it back to that. Hmm, no, I prefer changing the docs. "size_t" is the right type, and not many people seem to be affected by the int -> size_t change, so we chould leave it at size_t. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 14:53:41 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MXvd-0002BK-6k for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 14:51:37 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MXtN-0001QO-Ve for guile-devel@gnu.org; Sun, 01 Jun 2003 14:49:17 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MXt9-0000yo-Dy for guile-devel@gnu.org; Sun, 01 Jun 2003 14:49:05 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MXt1-0000ew-HH for guile-devel@gnu.org; Sun, 01 Jun 2003 14:48:55 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MXut-0004SD-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 20:50:51 +0200 Received: (qmail 12956 invoked by uid 1000); 1 Jun 2003 18:47:56 -0000 To: guile-devel@gnu.org References: <874r4186ty.fsf@zip.com.au> <87znll48wr.fsf@zagadka.ping.de> <87he7rwzox.fsf@zip.com.au> From: Marius Vollmer Date: 01 Jun 2003 20:47:56 +0200 In-Reply-To: <87he7rwzox.fsf@zip.com.au> Message-ID: <87znl1ocrn.fsf@zagadka.ping.de> Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Mikael Djurfeldt Subject: Re: scm_remember_upto_here asm volatile X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 18:51:35 -0000 Kevin Ryde writes: > Marius Vollmer writes: > > > > But please understand that this is a critical and tricky corner of > > Guile. Bugs might show up on odd platforms and might be very > > sensitive to the environment that scm_remember_upto_here is used in. > > With the bignum code, is it true that the only problem will be if a gc > starts in another thread at the critical moment? Yes, I would say so. And since a GC does only run when all other threads are stopped in a safe place, there won't be any GCs at critical moments. Since this is so convenient, I think we should continue to make this guarantee (that a GC wont happen spontanously). Mikael? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 15:31:45 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MYXy-0004hD-Tp for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 15:31:14 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MYXi-00048R-IZ for guile-devel@gnu.org; Sun, 01 Jun 2003 15:30:58 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MYXS-0003DU-7o for guile-devel@gnu.org; Sun, 01 Jun 2003 15:30:47 -0400 Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MYXF-0002PZ-N7 for guile-devel@gnu.org; Sun, 01 Jun 2003 15:30:29 -0400 Received: from barbara.blakulla.net ([213.212.21.238] helo=witch) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 19MYX1-0006Ag-00; Sun, 01 Jun 2003 21:30:15 +0200 Received: from mdj by witch with local (Exim 3.35 #1 (Debian)) id 19MYWG-0000u9-00; Sun, 01 Jun 2003 21:29:28 +0200 To: Marius Vollmer References: <874r4186ty.fsf@zip.com.au> <87znll48wr.fsf@zagadka.ping.de> <87he7rwzox.fsf@zip.com.au> <87znl1ocrn.fsf@zagadka.ping.de> From: Mikael Djurfeldt Date: Sun, 01 Jun 2003 21:29:28 +0200 In-Reply-To: <87znl1ocrn.fsf@zagadka.ping.de> (Marius Vollmer's message of "01 Jun 2003 20:47:56 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Mikael Djurfeldt cc: guile-devel@gnu.org cc: djurfeldt@nada.kth.se Subject: Re: scm_remember_upto_here asm volatile X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: djurfeldt@nada.kth.se List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 19:31:13 -0000 [Answers given "out-of-context"---can't read the thread right now.] Marius Vollmer writes: > And since a GC does only run when all other threads are stopped in a > safe place, there won't be any GCs at critical moments. That's right. > Since this is so convenient, I think we should continue to make this > guarantee (that a GC wont happen spontanously). Mikael? Yes, I think this at least gives a simple model for what to expect. Any other more conservative model might have the advantage to preserve more freedom to change the GC/thread policy in the future, but will also need to be much more complex. Besides, we wouldn't know now what kind of cautions are important to think about... (Was that answer intelligible? :) Mikael From MAILER-DAEMON Sun Jun 01 15:51:50 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MYo4-0004Jw-0n for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 15:47:52 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MYnv-0004GB-1e for guile-devel@gnu.org; Sun, 01 Jun 2003 15:47:43 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MYnr-0004E6-Vq for guile-devel@gnu.org; Sun, 01 Jun 2003 15:47:41 -0400 Received: from bay-bridge.veritas.com ([143.127.3.10] helo=bach.veritas.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MYnq-0004Ax-Fi for guile-devel@gnu.org; Sun, 01 Jun 2003 15:47:38 -0400 Received: from veritas.com (localhost [127.0.0.1]) by bach.veritas.com (Postfix) with ESMTP id 5A28A270D0; Sun, 1 Jun 2003 12:56:44 -0700 (PDT) Sender: bkorb@veritas.com Message-ID: <3EDA5A7C.D0FB7603@veritas.com> Date: Sun, 01 Jun 2003 12:56:44 -0700 From: Bruce Korb Organization: Home X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: Marius Vollmer References: <878yslps9q.fsf@zagadka.ping.de> Content-Type: multipart/mixed; boundary="------------9F17C0A8C77AC6BD1B083885" cc: Neil Jerram cc: guile-devel@gnu.org Subject: Re: Re-addition of deprecated stuff to 1.7. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 19:47:45 -0000 This is a multi-part message in MIME format. --------------9F17C0A8C77AC6BD1B083885 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marius Vollmer wrote: > I'd say it is a trade-off between how much pain you are willing to > inflict upon your clients and how much pain you are willing to suffer > yourself. > > I think (and hope) it is entirely tolerable to require you clients to > install Guile 1.6 when they want to compile your code. As the author of a piece of code that is relatively obscure, it is tough enough to get it test-driven, let alone test-driven after they have had to upgrade something else. Current distributions are still using 1.4 (leastwise the latest Red Hat 7.x and SuSE 8.1 use it). These releases are not even a year old yet. It *will* be a couple of years before it is reasonable to expect all potential clients to have 1.6. > > May I please encourage you to supply configury stuff that is capable > > of adapting current interfaces to old Guiles? > > Too much work for too little gain, I'd say. Instead, we should make > it as easy as possible to install Guile 1.6 so that there is no reason > not to have it on ones system. I sent some macros, tho I coded around the need to use it myself. > These configure snippets might be collected in a central place, maybe, > when people are willing to maintain such a thing. That's what I was suggesting... > But given the above, I think it is OK to just fail and require Guile > 1.6. Too early. > There are two [main] reasons... to want stability in an interface: > one is that your code works unchanged with multiple > versions/implementations of the other side of the API, another is that > you don't want to do the work of tracking the changes in an API. > In my opinion, the first reason is not very valid for Guile; there > should be no reason to require some code to compile _unchanged_ > against multiple versions of Guile. When there are such reasons, we > should work to remove the reasons, not to make it easier to compile > _unchanged_. I don't want to really say, "unchanged". I do want to say that the compatibility glue is important. I am now developing against 1.6. However, as much as you would like to see 1.4 retired, the bulk of the distributions at this time have 1.4. I need to be able to jigger what I use so it can adapt to whatever is locally installed. By the time the bulk of installations are running 1.6, you'll be shipping 1.8 and using the same arguments. > Note the emphasis on _unchanged_. Not wanting to do much work when > tracking API changes is a very good position to take. I'm taking both positions (I get to, I'm not developing Guile ;-). But I'm also willing to share what I've done. (Attached are two configury macros. One to find libguile, even on systems where guile-config was omitted [Red Hat], the other to detect 1.4 systems and provide #define glue for scm_eval_x and scm_port.) > When changing > the Guile API, we should make it in such a way that client code needs > to change as little as possible. This often means that it doesn't > need to change at all. However, it is not an unbreakable requirement > that client code must continue to compile with all new versions of > Guile. That's a little extreme. OTOH, when you retire ``scm_port'' you could also add: #if (THE_LAST_GUILE_VERSION_I_KNEW_ABOUT < GUILE_VERSION_1_6) # define scm_port scm_t_port #endif and delete that code only after 1.6 has been in the major distros for a couple of years. The Guile version I understand is a mix of 1.4 and 1.6 'cuz I'm transitioning. The attached configury checks for 1.4 and does the reverse #define: /* Define this if no scm_t_port */ #define scm_t_port scm_port > It is of course good practice to minimize the needed changes, I'm sure you do your best. One's best cannot ever be perfect. > > P.S. If _anyone_ can show me how to set the string port file > > name and line number, I *sure* would be a happy camper. > > I'm getting to that in a few minutes... :-) Cool. :-D --------------9F17C0A8C77AC6BD1B083885 Content-Type: text/plain; charset=us-ascii; name="libguile.m4" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libguile.m4" AC_DEFUN([AG_WITHLIB_GUILE],[ AC_ARG_WITH([libguile], AC_HELP_STRING([--with-libguile], [libguile installation prefix]), [ag_cv_with_libguile_root=${with_libguile}], AC_CACHE_CHECK([whether with-libguile was specified], ag_cv_with_libguile_root, ag_cv_with_libguile_root=no) ) # end of AC_ARG_WITH libguile if test "${with_libguile+set}" = set && \ test "${withval}" = no then ## disabled by request ag_cv_with_libguile_root=no ag_cv_with_libguile_cflags=no ag_cv_with_libguile_libs=no else AC_ARG_WITH([libguile-cflags], AC_HELP_STRING([--with-libguile-cflags], [libguile compile flags]), [ag_cv_with_libguile_cflags=${with_guile_cflags}], AC_CACHE_CHECK([whether with-libguile-cflags was specified], ag_cv_with_libguile_cflags, ag_cv_with_libguile_cflags=no) ) # end of AC_ARG_WITH libguile-cflags AC_ARG_WITH([libguile-libs], AC_HELP_STRING([--with-libguile-libs], [libguile link command arguments]), [ag_cv_with_libguile_libs=${with_guile_libs}], AC_CACHE_CHECK([whether with-libguile-libs was specified], ag_cv_with_libguile_libs, ag_cv_with_libguile_libs=no) ) # end of AC_ARG_WITH libguile-libs case "X${ag_cv_with_libguile_cflags}" in Xyes|Xno|X ) case "X${ag_cv_with_libguile_root}" in Xyes|Xno|X ) ag_cv_with_libguile_cflags=no ;; * ) ag_cv_with_libguile_cflags=-I${ag_cv_with_libguile_root}/include ;; esac esac case "X${ag_cv_with_libguile_libs}" in Xyes|Xno|X ) case "X${ag_cv_with_libguile_root}" in Xyes|Xno|X ) ag_cv_with_libguile_libs=no ;; * ) ag_cv_with_libguile_libs="-L${ag_cv_with_libguile_root}/lib -lguile";; esac esac ag_save_CPPFLAGS="${CPPFLAGS}" ag_save_LIBS="${LIBS}" case "X${ag_cv_with_libguile_cflags}" in Xyes|Xno|X ) f=`guile-config compile 2>/dev/null` || f='' test -n "${f}" && ag_cv_with_libguile_cflags="${f}" && \ AC_MSG_NOTICE([guile-config used for CFLAGS: $f]) ;; esac case "X${ag_cv_with_libguile_libs}" in Xyes|Xno|X ) f=`guile-config link 2>/dev/null` || f='' test -n "${f}" && ag_cv_with_libguile_libs="${f}" && \ AC_MSG_NOTICE([guile-config used for LIBS: $f]) ;; esac fi ## disabled by request case "X${ag_cv_with_libguile_cflags}" in Xyes|Xno|X ) ag_cv_with_libguile_cflags="" ;; * ) CPPFLAGS="${CPPFLAGS} ${ag_cv_with_libguile_cflags}" ;; esac case "X${ag_cv_with_libguile_libs}" in Xyes|Xno|X ) LIBS="${LIBS} -lguile" ag_cv_with_libguile_libs="-lguile" ;; * ) LIBS="${LIBS} ${ag_cv_with_libguile_libs}" ;; esac LIBGUILE_CFLAGS="" LIBGUILE_LIBS="" AC_MSG_CHECKING([whether libguile can be linked with]) AC_CACHE_VAL([ag_cv_with_libguile],[ AC_LINK_IFELSE([[@%:@include @%:@include int main () { SCM fumble, bumble, stumble; stumble = scm_cons( fumble, bumble ); stumble = scm_display( fumble, bumble ); stumble = scm_ilength( fumble ); stumble = scm_makstr( 1, 2 ); stumble = gh_eval_str( "stumble" ); scm_misc_error( "oops", "bad", bumble ); stumble = scm_num_eq_p( fumble, bumble ); scm_wrong_type_arg( "oops", 1, bumble ); return 0; }]], [ag_cv_with_libguile=yes], [ag_cv_with_libguile=no]) # end of AC_LINK_IFELSE ]) # end of AC_CACHE_VAL for ag_cv_with_libguile AC_MSG_RESULT([${ag_cv_with_libguile}]) AC_SUBST([LIBGUILE_CFLAGS]) AC_SUBST([LIBGUILE_LIBS]) AC_SUBST([LIBGUILE_PATH]) if test "X${ag_cv_with_libguile}" != Xno then[ LIBGUILE_CFLAGS="${ag_cv_with_libguile_cflags}" LIBGUILE_LIBS="${ag_cv_with_libguile_libs}" case "${LIBGUILE_LIBS}" in *-L* ) LIBGUILE_PATH=`echo ${LIBGUILE_LIBS} | sed 's/.*-L[ ]*//;s/[ ].*//'` ;; * ) LIBGUILE_PATH='' ;; esac] CPPFLAGS="@S|@{ag_save_CPPFLAGS}" LIBS="@S|@{ag_save_LIBS}" else CPPFLAGS="${ag_save_CPPFLAGS}" LIBS="${ag_save_LIBS}" LIBGUILE_CFLAGS='' LIBGUILE_LIBS='' LIBGUILE_PATH='' AC_MSG_ERROR([Cannot find working libguile]) fi AC_SUBST([AG_GUILE]) ]) # end of AC_DEFUN of AG_WITHLIB_GUILE AC_DEFUN([AG_LINK_EVAL_STRING],[ AC_MSG_CHECKING([whether scm_primitive_eval_x links]) AC_CACHE_VAL([ag_cv_link_eval_string],[ ag_save_CPPFLAGS="${CPPFLAGS}" CPPFLAGS="${ag_cv_with_libguile_cflags} ${CPPFLAGS}" ag_save_LIBS="${LIBS}" LIBS="${ag_cv_with_libguile_libs} ${LIBS}" AC_TRY_LINK([@%:@include @%:@include ], [SCM res = scm_primitive_eval_x( SCM_UNDEFINED );], [ag_cv_link_eval_string=yes],[ag_cv_link_eval_string=no] ) # end of TRY_LINK CPPFLAGS="${ag_save_CPPFLAGS}" LIBS="${ag_save_LIBS}" ]) # end of AC_CACHE_VAL for ag_cv_link_eval_string AC_MSG_RESULT([${ag_cv_link_eval_string}]) if test "X${ag_cv_link_eval_string}" = Xno then AC_DEFINE([scm_primitive_eval_x], [scm_eval_x], [Define this if no scm_primitive_eval_x]) AC_DEFINE([scm_t_port], [scm_port], [Define this if no scm_t_port]) fi ]) # end of AC_DEFUN of AG_LINK_EVAL_STRING --------------9F17C0A8C77AC6BD1B083885-- From MAILER-DAEMON Sun Jun 01 15:59:38 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MYzF-0002as-J2 for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 15:59:25 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MYyj-0001sw-QI for guile-devel@gnu.org; Sun, 01 Jun 2003 15:58:53 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MYyh-0001qv-Sf for guile-devel@gnu.org; Sun, 01 Jun 2003 15:58:52 -0400 Received: from bay-bridge.veritas.com ([143.127.3.10] helo=bach.veritas.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MYy3-0001Kq-8R for guile-devel@gnu.org; Sun, 01 Jun 2003 15:58:11 -0400 Received: from veritas.com (localhost [127.0.0.1]) by bach.veritas.com (Postfix) with ESMTP id 4D03F270CF; Sun, 1 Jun 2003 13:07:19 -0700 (PDT) Sender: bkorb@veritas.com Message-ID: <3EDA5CF7.6DD3BAAA@veritas.com> Date: Sun, 01 Jun 2003 13:07:19 -0700 From: Bruce Korb Organization: Home X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: Marius Vollmer References: <3EBC71BF.B2264C7@veritas.com> <874r3t5o1f.fsf@zagadka.ping.de> <3EC6A6CA.94855664@veritas.com> <87of213tk0.fsf@zagadka.ping.de> <87ptmfx0i3.fsf@zip.com.au> <874r39prgm.fsf@zagadka.ping.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: guile-devel@gnu.org Subject: Re: How do I determine the argument type... X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 19:59:22 -0000 Marius Vollmer wrote: > > > Ahh, I see. Yes, it was not a good thing to change gh_new2str that > > > way. I'm not sure what to do about this. Changing this back is just > > > as bad as the original change from int to size_t. > > > > The manual still says "int". > > Maybe call it a bug fix and put it back to that. > > Hmm, no, I prefer changing the docs. "size_t" is the right type, and > not many people seem to be affected by the int -> size_t change, so we > chould leave it at size_t. "int" is fine for the purpose since there is little need to cope with multi-gigabyte strings. OTOH, you have two libraries in the field. Right now, clients writing to the 1.4 interface that use the length argument to gh_new2str are hosed on I32LP64 platforms. If you were to change it back, clients writing to the current interface using that argument would be hosed on I32LP64 platforms. Re-doc it and leave it be (says the guy who was first to cry "ouch" from stubbing his toe on this.) From MAILER-DAEMON Sun Jun 01 16:03:54 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MZ3A-0005KA-GR for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 16:03:28 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MZ32-00054T-Vp for guile-devel@gnu.org; Sun, 01 Jun 2003 16:03:20 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MZ1o-00044P-SX for guile-devel@gnu.org; Sun, 01 Jun 2003 16:02:05 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MZ1H-00041I-DC for guile-devel@gnu.org; Sun, 01 Jun 2003 16:01:31 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MZ39-0003JG-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 22:03:27 +0200 Received: (qmail 20188 invoked by uid 1000); 1 Jun 2003 20:00:31 -0000 To: Bruce Korb References: <3ECFDA48.309D0F5@veritas.com> From: Marius Vollmer Date: 01 Jun 2003 22:00:31 +0200 In-Reply-To: <3ECFDA48.309D0F5@veritas.com> Message-ID: <87el2dlg9s.fsf@zagadka.ping.de> Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile development Subject: Re: [PATCH] for strports.c: scm_c_eval_string_from_file_line X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 20:03:24 -0000 Bruce Korb writes: > 2003-05-24 Bruce Korb > > * guile-core/libguile/strports.c(scm_c_eval_string_from_file_line): > new procedure. Facilitate error messages for applications that > extract scheme code from their input files. Hmm, I'm not sure whether we should provide such a function as a ready made unit. Evaluation from strings (maybe with embedded new lines, maybe more than one string, etc) while maintaining the line number, the current module, etc, might come in several variations, I think. We should provide the building blocks so that people can easily implement what they want cleanly so that scm_c_eval_string_from_file_line is very easy to implement. What you can do right now is, for example (and untested, sorry): void scm_c_primitive_load_from_string (const char *str, const char *filename, int line) { SCM port, exp; port = scm_open_input_string (scm_str2string (str)); scm_set_port_file_name_x (port, scm_str2string (filename)); scm_set_port_line_x (port, scm_int2num (line)); while (!SCM_EOF_OBJECT_P (exp = scm_read (port))) scm_primitive_eval_x (exp); } I think this quite straightforward, no? But we might want to offer it ready-made, anyway. Opinions? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 16:31:34 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MZTp-0002sw-2N for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 16:31:01 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MZTM-0002hY-SS for guile-devel@gnu.org; Sun, 01 Jun 2003 16:30:32 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MZT3-0002Oy-4R for guile-devel@gnu.org; Sun, 01 Jun 2003 16:30:15 -0400 Received: from bay-bridge.veritas.com ([143.127.3.10] helo=bach.veritas.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MZS6-0001sJ-MX for guile-devel@gnu.org; Sun, 01 Jun 2003 16:29:14 -0400 Received: from veritas.com (localhost [127.0.0.1]) by bach.veritas.com (Postfix) with ESMTP id CE6ED270CF; Sun, 1 Jun 2003 13:38:22 -0700 (PDT) Sender: bkorb@veritas.com Message-ID: <3EDA643E.2215A945@veritas.com> Date: Sun, 01 Jun 2003 13:38:22 -0700 From: Bruce Korb Organization: Home X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: Marius Vollmer References: <3ECFDA48.309D0F5@veritas.com> <87el2dlg9s.fsf@zagadka.ping.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: guile development cc: Bruce Korb Subject: Re: [PATCH] for strports.c: scm_c_eval_string_from_file_line X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 20:30:58 -0000 Marius Vollmer wrote: > void > scm_c_primitive_load_from_string (const char *str, > const char *filename, int line) > { > SCM port, exp; > > port = scm_open_input_string (scm_str2string (str)); > scm_set_port_file_name_x (port, scm_str2string (filename)); > scm_set_port_line_x (port, scm_int2num (line)); > > while (!SCM_EOF_OBJECT_P (exp = scm_read (port))) > scm_primitive_eval_x (exp); > } > > I think this quite straightforward, no? No. > But we might want to offer it ready-made, anyway. Opinions? Yes. It is pretty close to what I wound up with, but I don't track the preferred way to do things. For Guile 1.4, ``scm_primitive_eval_x'' gets #define-d into ``scm_eval_x'' and it works. I also try to avoid gratuitous creations of string SCM's since the file name is generally invariant. You omitted returning the final value, which is important :-). It's easier to ignore if the caller doesn't want it. And, no, I didn't find that the research required to do this was obvious. In fact, there is no ``scm_set_port_file_name_x'' in 1.6.3, so you must be talking 1.7 here. I'm still working with 1.4. Therefore, I must directly assign to ``file_name''. I may as well assign the line number, too. I'd rather it was ready made so I can just #define my ``ag_scm_c_eval_string_from_file_line'' into ``scm_c_primitive_load_from_string''. You might tweak it a bit so a NULL file pointer bypasses the scm_set_port_file_name_x call. I'd also use "file_line" in the name, but that is your call. EXPORT SCM ag_scm_c_eval_string_from_file_line( tCC* pzExpr, tCC* pzFile, int line ) { SCM port; { tSCC zEx[] = "eval-string-from-file-line"; SCM expr = scm_makfrom0str( pzExpr ); port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx ); } { static SCM file = SCM_UNDEFINED; scm_t_port* pt; if ( (file == SCM_UNDEFINED) || (strcmp( SCM_CHARS( file ), pzFile ) != 0) ) file = scm_makfrom0str( pzFile ); pt = SCM_PTAB_ENTRY( port ); pt->line_number = line - 1; pt->file_name = file; } { SCM ans = SCM_UNSPECIFIED; for (;;) { SCM form = scm_read( port ); if (SCM_EOF_OBJECT_P( form )) break; ans = scm_primitive_eval_x( form ); } return ans; // return the last answer } } From MAILER-DAEMON Sun Jun 01 17:04:04 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MZzo-0007O4-CO for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 17:04:04 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MZzl-0007ML-LZ for guile-devel@gnu.org; Sun, 01 Jun 2003 17:04:01 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MZzk-0007LO-9Z for guile-devel@gnu.org; Sun, 01 Jun 2003 17:04:00 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MZzK-0006qt-QA for guile-devel@gnu.org; Sun, 01 Jun 2003 17:03:34 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19Ma1C-0000SY-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 23:05:30 +0200 Received: (qmail 26378 invoked by uid 1000); 1 Jun 2003 21:02:34 -0000 To: guile-devel@gnu.org References: <87smrqxt3b.fsf@zip.com.au> <878yt55od2.fsf@zagadka.ping.de> <878yt3yig4.fsf@zip.com.au> <87znlfj54m.fsf@zip.com.au> <8765o3rosh.fsf@zagadka.ping.de> <87llwxnyvz.fsf@zip.com.au> From: Marius Vollmer Date: 01 Jun 2003 23:02:34 +0200 In-Reply-To: <87llwxnyvz.fsf@zip.com.au> Message-ID: <87znl1jytx.fsf@zagadka.ping.de> Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: documentation.scm close files X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 21:04:02 -0000 Kevin Ryde writes: > Marius Vollmer writes: > > > > What about saying something about 'with-input-from', etc. > > That's probably the easiest way to ensure that ports are closed even > > in the case of errors. > > Except that with-input-from-file and call-with-input-file don't > guarantee to close on error, do they? :-) Yep, you are right! I was talking too fast. > Due to being let's not dynamic-wind of course, if I'm looking at the > right code in r4rs.scm. Presumably this is deliberate, so > continuations can be captured and still use the port. Yes. I really start to think that call/cc does more harm than good. It is perfect for self contained illustrations of computer science stuff, but can cause a lot of fuzziness in larger, multi module systems. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 17:19:51 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MaEp-0006G9-2Y for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 17:19:35 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MaEd-0005ag-36 for guile-devel@gnu.org; Sun, 01 Jun 2003 17:19:23 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MaEP-00051y-Po for guile-devel@gnu.org; Sun, 01 Jun 2003 17:19:10 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MaEL-0004ob-Du for guile-devel@gnu.org; Sun, 01 Jun 2003 17:19:05 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MaGD-0001fr-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 23:21:01 +0200 Received: (qmail 27932 invoked by uid 1000); 1 Jun 2003 21:18:04 -0000 To: Jonathan Bartlett References: From: Marius Vollmer Date: 01 Jun 2003 23:18:04 +0200 In-Reply-To: Message-ID: <87vfvpjy43.fsf@zagadka.ping.de> Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: Ideas X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 21:19:33 -0000 Jonathan Bartlett writes: > Basically, have a procedure called (end-compile-time-evaluation) > which would do the following: You might want to check out this http://www-dt.e-technik.uni-dortmund.de/~mvo/guile-unexec.tar.gz It's very old and unmaintained but i might give you some hints. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 17:23:39 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MaIf-00063L-NY for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 17:23:33 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MaIZ-0005g4-CZ for guile-devel@gnu.org; Sun, 01 Jun 2003 17:23:27 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MaIX-0005ZE-6E for guile-devel@gnu.org; Sun, 01 Jun 2003 17:23:26 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MaIV-0005VY-SM for guile-devel@gnu.org; Sun, 01 Jun 2003 17:23:24 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MaKN-000202-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 23:25:19 +0200 Received: (qmail 28380 invoked by uid 1000); 1 Jun 2003 21:22:23 -0000 To: Kevin Ryde References: <878ysxl0z8.fsf@zip.com.au> From: Marius Vollmer Date: 01 Jun 2003 23:22:23 +0200 In-Reply-To: <878ysxl0z8.fsf@zip.com.au> Message-ID: <87r86djxww.fsf@zagadka.ping.de> Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: scm_t_bits versus uintptr_t X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 21:23:32 -0000 Kevin Ryde writes: > It might be necessary to include inttypes.h or stdint.h, or whichever > is available, if the intention is to use intptr_t when possible. Yes, that is the intention. Could you fix this? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 17:47:00 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MadR-0007bq-M6 for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 17:45:01 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Mad0-000731-R3 for guile-devel@gnu.org; Sun, 01 Jun 2003 17:44:34 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Macq-0006oz-8v for guile-devel@gnu.org; Sun, 01 Jun 2003 17:44:24 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MabS-0006Gi-Hq for guile-devel@gnu.org; Sun, 01 Jun 2003 17:42:58 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MadK-0003K0-00 for guile-devel@gnu.org; Sun, 01 Jun 2003 23:44:54 +0200 Received: (qmail 30360 invoked by uid 1000); 1 Jun 2003 21:41:57 -0000 To: guile-devel@gnu.org References: <87wugjhowm.fsf@zip.com.au> <87wugjqx1g.fsf@raven.i.defaultvalue.org> <87r86rqa6m.fsf@raven.i.defaultvalue.org> <87vfw1i1jq.fsf@zip.com.au> <87add5mh91.fsf@zip.com.au> From: Marius Vollmer Date: 01 Jun 2003 23:41:57 +0200 In-Reply-To: <87add5mh91.fsf@zip.com.au> Message-ID: <87isrpjx0a.fsf@zagadka.ping.de> Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco scm_remember_upto_1 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 21:45:00 -0000 Kevin Ryde writes: > I'd like to propose the words below, assuming they're true. Perhaps > experts can review the last para in particular, and decide how much > can or should be said about gc and pre-emption. We can make the guarantee that a GC wont run asynchronously. What abut this wording: In a multi-threaded program, it might be thought that a garbage collection could occur in another thread at any time, and hence mean a routine like `clear_image' would require protection too. But this is not the case, a GC will only run when all threads are in a safe place and have been stopped. But when in doubt, be conservative: include the call to scm_remember_upto_here_1 when you are not sure that it is safe to leave it out. A call to scm_remember_1 will cost at most as much as a call to an empty function. > I don't think the varargs scm_remember_upto_here should be documented, > because I don't think it can be implemented as an inline. Is that important? A note that says that the non-varargs functions might be more efficient should suffice, no? The rest is very nice! -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 17:48:09 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MagK-0000tr-Qc for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 17:48:00 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MafW-0000Ek-Dc for guile-devel@gnu.org; Sun, 01 Jun 2003 17:47:10 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MafM-0008S8-V7 for guile-devel@gnu.org; Sun, 01 Jun 2003 17:47:01 -0400 Received: from mx1.eskimo.com ([204.122.16.48]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Maf3-00085H-0H for guile-devel@gnu.org; Sun, 01 Jun 2003 17:46:41 -0400 Received: from eskimo.com (johnnyb@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.3/8.8.8) with ESMTP id OAA13643; Sun, 1 Jun 2003 14:46:07 -0700 Received: from localhost (johnnyb@localhost) by eskimo.com (8.9.1a/8.9.1) with ESMTP id OAA29132; Sun, 1 Jun 2003 14:46:07 -0700 (PDT) X-Authentication-Warning: eskimo.com: johnnyb owned process doing -bs Date: Sun, 1 Jun 2003 14:46:07 -0700 (PDT) From: Jonathan Bartlett To: Marius Vollmer In-Reply-To: <87vfvpjy43.fsf@zagadka.ping.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: guile-devel@gnu.org Subject: Re: Ideas X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 21:47:53 -0000 Thanks for the code! I'll take a look at it. Jon On 1 Jun 2003, Marius Vollmer wrote: > Jonathan Bartlett writes: > > > Basically, have a procedure called (end-compile-time-evaluation) > > which would do the following: > > You might want to check out this > > http://www-dt.e-technik.uni-dortmund.de/~mvo/guile-unexec.tar.gz > > It's very old and unmaintained but i might give you some hints. > > -- > GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 > From MAILER-DAEMON Sun Jun 01 19:32:12 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19McGK-0000lK-RX for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 19:29:16 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19McFe-0000TX-9z for guile-devel@gnu.org; Sun, 01 Jun 2003 19:28:34 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Mc5F-0006Yc-9D for guile-devel@gnu.org; Sun, 01 Jun 2003 19:17:52 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Mc2K-0005ka-1L for guile-devel@gnu.org; Sun, 01 Jun 2003 19:14:48 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19Mc4B-00017v-00 for guile-devel@gnu.org; Mon, 02 Jun 2003 01:16:43 +0200 Received: (qmail 30344 invoked by uid 1000); 1 Jun 2003 23:13:45 -0000 To: guile-devel@gnu.org References: <87u1bven62.fsf@zip.com.au> <87he7ilf5a.fsf@zip.com.au> From: Marius Vollmer Date: 02 Jun 2003 01:13:45 +0200 In-Reply-To: <87he7ilf5a.fsf@zip.com.au> Message-ID: <87llwlie6u.fsf@zagadka.ping.de> Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco array mapping X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 23:29:14 -0000 Kevin Ryde writes: > New words to propose for the array mapping chapter. Good ones. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 19:35:04 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19McAX-0007gd-Pg for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 19:23:17 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Mc1z-0005X5-HQ for guile-devel@gnu.org; Sun, 01 Jun 2003 19:14:27 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Mc1n-0005QI-HR for guile-devel@gnu.org; Sun, 01 Jun 2003 19:14:17 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Mbx4-0002EZ-F9 for guile-devel@gnu.org; Sun, 01 Jun 2003 19:09:22 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19Mbyw-0000mW-00 for guile-devel@gnu.org; Mon, 02 Jun 2003 01:11:18 +0200 Received: (qmail 29805 invoked by uid 1000); 1 Jun 2003 23:08:20 -0000 To: Kevin Ryde References: <874r3lny9l.fsf@zip.com.au> <87znldmjgw.fsf@zip.com.au> From: Marius Vollmer Date: 02 Jun 2003 01:08:20 +0200 In-Reply-To: <87znldmjgw.fsf@zip.com.au> Message-ID: <87ptlxiefv.fsf@zagadka.ping.de> Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: doco srfi-13 string-replace X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 01 Jun 2003 23:23:13 -0000 Kevin Ryde writes: > I wrote: > > * srfi-modules.texi (SRFI-13 Miscellaneous): In > > string-replace, start1 and end1 are not optional. > > Oops, no, I was looking at the wrong stuff. I see the srfi-13 spec > has them as mandatory but the guile code makes them optional. Should > that be mentioned at all? Hmmm. There is not much value in extending an SRFI, I'd say. People can't really use our extensions if they want to stay portable. However, since we have that code, we should document it. So, please document that behavior but clearly mark it as a "Guile extension". Ok? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sun Jun 01 20:03:15 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19McmQ-0006tn-AS for mharc-guile-devel@gnu.org; Sun, 01 Jun 2003 20:02:26 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19McmM-0006n1-G8 for guile-devel@gnu.org; Sun, 01 Jun 2003 20:02:22 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Mclp-0006Fj-4G for guile-devel@gnu.org; Sun, 01 Jun 2003 20:01:49 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Mcji-0005hu-7P for guile-devel@gnu.org; Sun, 01 Jun 2003 19:59:38 -0400 Received: from dialin.speedway43.dip132.dokom.de ([195.138.43.132] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19MclZ-0003kv-00 for guile-devel@gnu.org; Mon, 02 Jun 2003 02:01:33 +0200 Received: (qmail 2406 invoked by uid 1000); 1 Jun 2003 23:58:35 -0000 To: guile-devel@gnu.org References: <87isrtmhfw.fsf@zip.com.au> From: Marius Vollmer Date: 02 Jun 2003 01:58:35 +0200 In-Reply-To: <87isrtmhfw.fsf@zip.com.au> Message-ID: <87he79ic44.fsf@zagadka.ping.de> Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: while break and continue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 02 Jun 2003 00:02:24 -0000 Kevin Ryde writes: > I was going to add some words to the manual about break and continue > in a while loop, but noticed continue doesn't do what I might have > thought. Oops. Yes, that is unexpected. I think your solution is essentially correct, except that you shouldn't use procedure->memoizing-macro (use define-macro instead) and that you inject literal procedures into the expanded code. This is not good style since the procedures are created in the compile time environment but used in the run-time environment. A compiler might not like this. This old post might be interesting as well, but the 'tagbody' implementation in it is not properly tail recursive: http://sources.redhat.com/ml/guile/2000-07/msg00339.html -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Mon Jun 02 04:32:12 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Mkhq-0006J3-JQ for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 04:30:14 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MkhT-00068O-KK for guile-devel@gnu.org; Mon, 02 Jun 2003 04:29:51 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MkhM-00065L-Fl for guile-devel@gnu.org; Mon, 02 Jun 2003 04:29:45 -0400 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Mkgj-0005fE-Vp for guile-devel@gnu.org; Mon, 02 Jun 2003 04:29:06 -0400 Received: from patroclus (patroclus.uebb.cs.tu-berlin.de [130.149.23.248]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id KAA06787; Mon, 2 Jun 2003 10:27:39 +0200 (MET DST) Received: from magr by patroclus with local (Exim 3.36 #1 (Debian)) id 19MkbY-0000hM-00; Mon, 02 Jun 2003 10:23:44 +0200 Date: Mon, 2 Jun 2003 10:23:44 +0200 From: Martin Grabmueller To: Marius Vollmer Message-ID: <20030602082344.GA925@patroclus> References: <874r3lny9l.fsf@zip.com.au> <87znldmjgw.fsf@zip.com.au> <87ptlxiefv.fsf@zagadka.ping.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ptlxiefv.fsf@zagadka.ping.de> User-Agent: Mutt/1.5.4i cc: guile-devel@gnu.org Subject: Re: doco srfi-13 string-replace X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 02 Jun 2003 08:30:12 -0000 On Mon, Jun 02, 2003 at 01:08:20AM +0200, Marius Vollmer wrote: > Hmmm. There is not much value in extending an SRFI, I'd say. People > can't really use our extensions if they want to stay portable. > However, since we have that code, we should document it. So, please > document that behavior but clearly mark it as a "Guile extension". Just for information: when I wrote the code for this SRFI, I only had the draft version of the SRFI document, so there may be some more errors in the code due to this fact. It would be best to adjust the code to match the final SRFI, instead of introducing extensions. 'martin From MAILER-DAEMON Mon Jun 02 10:45:09 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MqYJ-00050Z-RL for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 10:44:47 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MqYB-0004ig-3K for guile-devel@gnu.org; Mon, 02 Jun 2003 10:44:39 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MqXs-0004HB-U0 for guile-devel@gnu.org; Mon, 02 Jun 2003 10:44:21 -0400 Received: from helena.whitefang.com ([216.254.175.50]) by monty-python.gnu.org with smtp (Exim 4.20) id 19MqXa-0003xl-PL for guile-devel@gnu.org; Mon, 02 Jun 2003 10:44:02 -0400 Received: (qmail 71470 invoked from network); 2 Jun 2003 14:44:20 -0000 Received: from helena.whitefang.com (216.254.175.50) by 0 with SMTP; 2 Jun 2003 14:44:20 -0000 Date: Mon, 2 Jun 2003 10:44:20 -0400 (EDT) From: Thamer Al-Harbash X-X-Sender: shadows@helena.whitefang.com To: guile development In-Reply-To: <3ED8F446.12425825@veritas.com> Message-ID: References: <3ED8F446.12425825@veritas.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: What is the Guile 1.4 equivalent? X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 02 Jun 2003 14:44:45 -0000 On Sat, 31 May 2003, Bruce Korb wrote: > Since 1.4.x is still in distribution, I need my code to work > against that version. In my various email exchanges, someone > suggested the following for enabling source lines in error messages. > Except is doesn't work for 1.4. Is there an equivalent, or > should I not bother? Probably shouldn't bother. I know FreeBSD ships with guile-1.4 in its ports package. If you want you can write your code for the old depreciated interface, then do. I'm writing mine with the new scm interface and asking my users to use guile 1.6 -- Thamer Al-Harbash http://www.whitefang.com/ (if (> pressure too-much-pressure) 'flame 'work) From MAILER-DAEMON Mon Jun 02 12:19:38 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MrwB-00021O-IF for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 12:13:31 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Mrvp-0001pr-8b for guile-devel@gnu.org; Mon, 02 Jun 2003 12:13:09 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Mriq-0007Ol-Pd for guile-devel@gnu.org; Mon, 02 Jun 2003 11:59:47 -0400 Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.20) id 19Mrip-0007Li-46 for guile-devel@gnu.org; Mon, 02 Jun 2003 11:59:43 -0400 Received: (qmail 13658 invoked by uid 1000); 2 Jun 2003 15:58:39 -0000 To: Martin Grabmueller References: <874r3lny9l.fsf@zip.com.au> <87znldmjgw.fsf@zip.com.au> <87ptlxiefv.fsf@zagadka.ping.de> <20030602082344.GA925@patroclus> From: Marius Vollmer Date: 02 Jun 2003 17:58:39 +0200 In-Reply-To: <20030602082344.GA925@patroclus> Message-ID: <87u1b8a2ts.fsf@zagadka.ping.de> Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: doco srfi-13 string-replace X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 02 Jun 2003 16:13:30 -0000 Martin Grabmueller writes: > It would be best to adjust the code to match the final SRFI, instead > of introducing extensions. Hmm, how long has our code being out there already? When it has been shipped with Guile 1.6, we need to be very conservative about changing things that are not outright bugs. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Mon Jun 02 20:29:13 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MzbQ-0006rV-VM for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 20:24:36 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MzaN-0006Tl-5r for guile-devel@gnu.org; Mon, 02 Jun 2003 20:23:31 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MzKa-0003O1-Ua for guile-devel@gnu.org; Mon, 02 Jun 2003 20:07:17 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MzG0-0002fq-2V for guile-devel@gnu.org; Mon, 02 Jun 2003 20:02:28 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5302QPB031475 for ; Tue, 3 Jun 2003 10:02:26 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5302PQg015038 for ; Tue, 3 Jun 2003 10:02:25 +1000 (EST) Received: from localhost (ppp92.dyn228.pacific.net.au [203.143.228.92]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5302MYZ014317 for ; Tue, 3 Jun 2003 10:02:23 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19MzFg-0002Qj-00; Tue, 03 Jun 2003 10:02:08 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Tue, 03 Jun 2003 10:02:07 +1000 Message-ID: <877k84f2ps.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco delay X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 00:24:35 -0000 --=-=-= Getting delay described, for completeness. * scheme-evaluation.texi (Delayed Evaluation): Add delay, reword promise? and force a bit, describe recursive forcing of a promise by its own code. I'm assuming the R5RS sample code for promises is to be read as a specification for what should happen in a recursive force. It's the way guile works at least. Delayed Evaluation ================== Promises are a convenient way to defer a calculation until its result is actually needed, and to run such a calculation only once. - syntax: delay expr Return a promise object which holds the given EXPR expression, ready to be evaluated by a later `force'. - Scheme Procedure: promise? obj - C Function: scm_promise_p (obj) Return true if OBJ is a promise. - Scheme Procedure: force p - C Function: scm_force (prom) Return the value obtained from evaluating the EXPR in the given promise P. If P has previously been forced then its EXPR is not evaluated again, instead the value obtained at that time is simply returned. During a `force', an EXPR can call `force' on its own promise, resulting in a further recursive evaluation of that EXPR. The first evaluation to return gives the value for the promise. Higher evaluations run to completion in the normal way, but their results are ignored, `force' always returns the first value. --=-=-= Content-Disposition: attachment; filename=scheme-evaluation.texi.delay.diff --- scheme-evaluation.texi.~1.9.~ 2002-09-25 10:06:38.000000000 +1000 +++ scheme-evaluation.texi 2003-06-03 09:58:31.000000000 +1000 @@ -319,20 +319,36 @@ @node Delayed Evaluation @section Delayed Evaluation +@cindex delayed evaluation +@cindex promises -[delay] +Promises are a convenient way to defer a calculation until its result +is actually needed, and to run such a calculation only once. + +@deffn syntax delay expr +@rnindex delay +Return a promise object which holds the given @var{expr} expression, +ready to be evaluated by a later @code{force}. +@end deffn @deffn {Scheme Procedure} promise? obj @deffnx {C Function} scm_promise_p (obj) -Return true if @var{obj} is a promise, i.e. a delayed computation -(@pxref{Delayed evaluation,,,r5rs.info,The Revised^5 Report on Scheme}). +Return true if @var{obj} is a promise. @end deffn @rnindex force -@deffn {Scheme Procedure} force x -@deffnx {C Function} scm_force (x) -If the promise @var{x} has not been computed yet, compute and -return @var{x}, otherwise just return the previously computed +@deffn {Scheme Procedure} force p +@deffnx {C Function} scm_force (prom) +Return the value obtained from evaluating the @var{expr} in the given +promise @var{p}. If @var{p} has previously been forced then its +@var{expr} is not evaluated again, instead the value obtained at that +time is simply returned. + +During a @code{force}, an @var{expr} can call @code{force} on its own +promise, resulting in a further recursive evaluation of that +@var{expr}. The first evaluation to return gives the value for the +promise. Higher evaluations run to completion in the normal way, but +their results are ignored, @code{force} always returns the first value. @end deffn --=-=-=-- From MAILER-DAEMON Mon Jun 02 20:29:23 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MzbE-0006mi-2R for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 20:24:24 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MzaV-0006XV-Cp for guile-devel@gnu.org; Mon, 02 Jun 2003 20:23:39 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MzZf-0006H3-Vn for guile-devel@gnu.org; Mon, 02 Jun 2003 20:22:48 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MzAS-0001oN-3E for guile-devel@gnu.org; Mon, 02 Jun 2003 19:56:44 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h52NrsPB025680 for ; Tue, 3 Jun 2003 09:55:30 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h52NrnQg011441 for ; Tue, 3 Jun 2003 09:53:49 +1000 (EST) Received: from localhost (ppp92.dyn228.pacific.net.au [203.143.228.92]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h52NrjYZ001374 for ; Tue, 3 Jun 2003 09:53:47 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19Mz7J-0002PY-00; Tue, 03 Jun 2003 09:53:29 +1000 To: guile-devel@gnu.org References: <873cldog5i.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Tue, 03 Jun 2003 09:53:29 +1000 Message-ID: <87fzmsf346.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: srfi-6 re-exports (was: frisk versus srfi-1 filter) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 00:24:22 -0000 --=-=-= Mikael Djurfeldt writes: > > The "frisk" script correctly uses :select to explicitly ask for the > binding "filter" in srfi-1. Of course people should be able to do > this for *all* bindings of srfi-1, which means that we must re-export > all core bindings. Is this a general rule? For instance I wonder if srfi-6 string ports should re-export similarly. (Below, untested.) Of course being entirely in the core I don't suppose it's ever occurred to anyone to use a module at all :-). --=-=-= Content-Disposition: attachment; filename=srfi-6.scm.re-export.diff --- srfi-6.scm.~1.5.~ 2003-04-07 08:05:30.000000000 +1000 +++ srfi-6.scm 2003-05-25 08:36:58.000000000 +1000 @@ -1,6 +1,6 @@ ;;; srfi-6.scm --- Basic String Ports -;; Copyright (C) 2001, 2002 Free Software Foundation, Inc. +;; Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc. ;; ;; This library is free software; you can redistribute it and/or ;; modify it under the terms of the GNU Lesser General Public @@ -22,7 +22,8 @@ ;;; Code: -(define-module (srfi srfi-6)) +(define-module (srfi srfi-6) + #:re-export (open-input-string open-output-string get-output-string)) ;; Currently, guile provides these functions by default, so no action ;; is needed, and this file is just a placeholder. --=-=-=-- From MAILER-DAEMON Mon Jun 02 20:31:56 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Mzi8-0000Ti-Jb for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 20:31:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Mzfe-00083m-5i for guile-devel@gnu.org; Mon, 02 Jun 2003 20:28:58 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MzZy-0006Nt-0t for guile-devel@gnu.org; Mon, 02 Jun 2003 20:23:06 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MzJ1-00034R-8C for guile-devel@gnu.org; Mon, 02 Jun 2003 20:05:35 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5305WPB001765 for ; Tue, 3 Jun 2003 10:05:32 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5305WQg017270 for ; Tue, 3 Jun 2003 10:05:32 +1000 (EST) Received: from localhost (ppp92.dyn228.pacific.net.au [203.143.228.92]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5305UYZ020283 for ; Tue, 3 Jun 2003 10:05:30 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19MzIn-0002Qy-00; Tue, 03 Jun 2003 10:05:21 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Tue, 03 Jun 2003 10:05:21 +1000 Message-ID: <87y90kdnzy.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco futures X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 00:31:31 -0000 --=-=-= A small start at getting some stuff out of the NEWS file and into the manual. * scheme-scheduling.texi (Futures): New section. Dunno if make-future or the C functions should appear too. I'll leave that to an executive decision. Futures ======= Futures are a convenient way to run a calculation in a new thread, and only wait for the result when it's actually needed. Futures are similar to promises (*note Delayed Evaluation::), in that they allow mainline code to continue immediately. But `delay' doesn't evaluate at all until forced, whereas `future' starts immediately in a new thread. - syntax: future expr Begin evaluating EXPR in a new thread, and return a "future" object representing the calculation. - Scheme Procedure: future-ref f Return the value computed by the future F. If F has not yet finished executing then wait for it to do so. --=-=-= Content-Disposition: attachment; filename=scheme-scheduling.texi.futures.diff --- scheme-scheduling.texi.~1.10.~ 2003-05-05 10:18:26.000000000 +1000 +++ scheme-scheduling.texi 2003-06-01 08:55:41.000000000 +1000 @@ -12,6 +12,7 @@ * Dynamic Roots:: Root frames of execution. * Threads:: Multiple threads of execution. * Fluids:: Thread-local variables. +* Futures:: Delayed execution in new threads. @end menu @@ -647,6 +648,30 @@ when control enter or leaves the established dynamic extent. @end deffn + +@node Futures +@section Futures +@cindex futures + +Futures are a convenient way to run a calculation in a new thread, and +only wait for the result when it's actually needed. + +Futures are similar to promises (@pxref{Delayed Evaluation}), in that +they allow mainline code to continue immediately. But @code{delay} +doesn't evaluate at all until forced, whereas @code{future} starts +immediately in a new thread. + +@deffn {syntax} future expr +Begin evaluating @var{expr} in a new thread, and return a ``future'' +object representing the calculation. +@end deffn + +@deffn {Scheme Procedure} future-ref f +Return the value computed by the future @var{f}. If @var{f} has not +yet finished executing then wait for it to do so. +@end deffn + + @c Local Variables: @c TeX-master: "guile.texi" @c End: --=-=-= Content-Disposition: attachment; filename=NEWS.futures.diff --- NEWS.~1.393.~ 2003-05-22 11:39:29.000000000 +1000 +++ NEWS 2003-05-31 15:12:07.000000000 +1000 @@ -278,27 +278,10 @@ version string without the final micro-version number. See "Changes to the distribution" above. -** Futures +** Futures: future, future-ref -Futures is a way of providing an alternative evaluation policy, very -similar in principle to "promises". Like promises, futures allow the -main process to continue instantly, but while promises postpone -evaluation ("lazy" evaluation) until the value is requested, futures -immediately starts evaluation in a parallel thread. - -Futures are good when you want to express that "I'll need the value of -this computation sometime soon" and want to allow processing to go on -in the background until that time arrives. - -** New syntax: future FORM - -Begin evaluation of FORM in a parallel thread and return the future -immediately. (Akin to 'delay'.) - -** New procedure: future-ref FUTURE - -Return the computed value of the future. Wait if the computation is -not finished. (Akin to 'force'.) +Futures are like promises, but begun immediately in a new thread. See +"Futures" in the reference manual. ** New syntax: parallel FORM ... --=-=-=-- From MAILER-DAEMON Mon Jun 02 20:38:02 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19MzoP-0002bL-QT for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 20:38:01 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MzHK-0002nv-RB for guile-devel@gnu.org; Mon, 02 Jun 2003 20:03:50 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MzB7-0001vW-JS for guile-devel@gnu.org; Mon, 02 Jun 2003 19:57:27 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MzAm-0001qf-7G for guile-devel@gnu.org; Mon, 02 Jun 2003 19:57:04 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h52NqSPB025348 for ; Tue, 3 Jun 2003 09:54:40 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h52NqQQg011142 for ; Tue, 3 Jun 2003 09:52:26 +1000 (EST) Received: from localhost (ppp92.dyn228.pacific.net.au [203.143.228.92]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h52NqOYZ029512 for ; Tue, 3 Jun 2003 09:52:25 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19Mz5r-0002PO-00; Tue, 03 Jun 2003 09:51:59 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Tue, 03 Jun 2003 09:51:59 +1000 Message-ID: <87of1gf36o.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: unknown # error message X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 00:37:58 -0000 --=-=-= This is a followup to my report about the error message for an unknown "#" object in the reader. (Which I've since managed to lose.) For instance interactively with the latest cvs, (call-with-input-string "#Z" read) gives an exception during display of the error. * read.c (scm_input_error): Pass arg list parameter to scm_error_scm, rather than SCM_EOL. Needed by "Unknown # object" case in scm_lreadr. * tests/reader.test (reading): Test bad # error message is formattable. I believe this is only in the head, not 1.6. I'm guessing that not passing the arg parameter to scm_error_scm was merely a typo. It looks like the intention, and that parameter is otherwise unused. --=-=-= Content-Disposition: attachment; filename=read.c.error-args.diff --- read.c.~1.90.~ 2003-05-10 10:11:50.000000000 +1000 +++ read.c 2003-06-02 17:08:54.000000000 +1000 @@ -1,4 +1,5 @@ -/* Copyright (C) 1995,1996,1997,1999,2000,2001 Free Software Foundation, Inc. +/* Copyright (C) 1995,1996,1997,1999,2000,2001,2003 Free Software + * Foundation, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -90,7 +91,7 @@ scm_error_scm (scm_str2symbol ("read-error"), scm_makfrom0str (function), string, - SCM_EOL, + arg, SCM_BOOL_F); } --=-=-= Content-Disposition: attachment; filename=reader.test.bad-hash.diff --- reader.test.~1.6.~ 2002-08-07 10:52:21.000000000 +1000 +++ reader.test 2003-06-02 17:08:25.000000000 +1000 @@ -18,7 +18,20 @@ (pass-if "1+i+i" (equal? (read-string "1+i+i") '1+i+i)) (pass-if "1+e10000i" - (equal? (read-string "1+e10000i") '1+e10000i))) + (equal? (read-string "1+e10000i") '1+e10000i)) + + ;; At one time the arg list for "Unknown # object: ~S" didn't make it out + ;; of read.c. Check that `format' can be applied to this error. + (pass-if "error message on bad #" + (catch #t + (lambda () + (read-string "#ZZZ") + ;; oops, this # is supposed to be unrecognised + #f) + (lambda (key subr message args rest) + (apply format #f message args) + ;; message and args are ok + #t)))) (pass-if-exception "radix passed to number->string can't be zero" exception:out-of-range --=-=-=-- From MAILER-DAEMON Mon Jun 02 20:38:08 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Mziy-00013g-Bf for mharc-guile-devel@gnu.org; Mon, 02 Jun 2003 20:32:24 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MziN-0000aG-4h for guile-devel@gnu.org; Mon, 02 Jun 2003 20:31:47 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MzBK-0001zP-To for guile-devel@gnu.org; Mon, 02 Jun 2003 19:57:41 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Mz8j-0001j4-1G for guile-devel@gnu.org; Mon, 02 Jun 2003 19:54:57 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h52NlGPB024243 for ; Tue, 3 Jun 2003 09:49:45 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h52NlBQg010499 for ; Tue, 3 Jun 2003 09:47:11 +1000 (EST) Received: from localhost (ppp92.dyn228.pacific.net.au [203.143.228.92]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h52Nl8YZ021838 for ; Tue, 3 Jun 2003 09:47:09 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19LupN-0000Qb-00; Sat, 31 May 2003 11:06:33 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Sat, 31 May 2003 11:06:32 +1000 Message-ID: <8765nrvs9z.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco stat fields X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 00:32:22 -0000 --=-=-= Prompted by Stefan mentioning AC_STRUCT_ST_BLOCKS, a possible few words about stat fields not always available. * posix.texi (File System): stat:rdev and stat:blocks can return #f, stat:blksize returns a sensible size if the field is not available. Formatted text for ease of contemplation. The second sentence of each is new. - Scheme Procedure: stat:rdev st Device ID; this entry is defined only for character or block special files. On some systems this field is not available at all, in which case `stat:rdev' returns `#f'. - Scheme Procedure: stat:blksize st The optimal block size for reading or writing the file, in bytes. On some systems this field is not available, in which case `stat:blksize' returns a sensible suggested block size. - Scheme Procedure: stat:blocks st The amount of disk space that the file occupies measured in units of 512 byte blocks. On some systems this field is not available, in which case `stat:blocks' returns `#f'. --=-=-= Content-Disposition: attachment; filename=posix.texi.stat.diff --- posix.texi.~1.20.~ 2003-05-26 10:56:22.000000000 +1000 +++ posix.texi 2003-05-31 11:00:34.000000000 +1000 @@ -594,8 +594,9 @@ The group ID of the file. @end deffn @deffn {Scheme Procedure} stat:rdev st -Device ID; this entry is defined only for character or block -special files. +Device ID; this entry is defined only for character or block special +files. On some systems this field is not available at all, in which +case @code{stat:rdev} returns @code{#f}. @end deffn @deffn {Scheme Procedure} stat:size st The size of a regular file in bytes. @@ -610,12 +611,14 @@ The last modification time for the attributes of the file. @end deffn @deffn {Scheme Procedure} stat:blksize st -The optimal block size for reading or writing the file, in -bytes. +The optimal block size for reading or writing the file, in bytes. On +some systems this field is not available, in which case +@code{stat:blksize} returns a sensible suggested block size. @end deffn @deffn {Scheme Procedure} stat:blocks st -The amount of disk space that the file occupies measured in -units of 512 byte blocks. +The amount of disk space that the file occupies measured in units of +512 byte blocks. On some systems this field is not available, in +which case @code{stat:blocks} returns @code{#f}. @end deffn In addition, the following procedures return the information --=-=-=-- From MAILER-DAEMON Tue Jun 03 03:05:12 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19N5r2-0003R2-7a for mharc-guile-devel@gnu.org; Tue, 03 Jun 2003 03:05:08 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19N5qr-0002x9-MX for guile-devel@gnu.org; Tue, 03 Jun 2003 03:04:57 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19N5qW-0002Ti-NA for guile-devel@gnu.org; Tue, 03 Jun 2003 03:04:37 -0400 Received: from mail.cs.tu-berlin.de ([130.149.17.13]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19N5q7-00020G-Uh for guile-devel@gnu.org; Tue, 03 Jun 2003 03:04:12 -0400 Received: from patroclus (patroclus.uebb.cs.tu-berlin.de [130.149.23.248]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id JAA08752 for ; Tue, 3 Jun 2003 09:00:30 +0200 (MET DST) Received: from magr by patroclus with local (Exim 3.36 #1 (Debian)) id 19N5in-00067L-00 for ; Tue, 03 Jun 2003 08:56:37 +0200 Date: Tue, 3 Jun 2003 08:56:37 +0200 From: Martin Grabmueller To: guile-devel@gnu.org Message-ID: <20030603065637.GA22482@patroclus> References: <874r3lny9l.fsf@zip.com.au> <87znldmjgw.fsf@zip.com.au> <87ptlxiefv.fsf@zagadka.ping.de> <20030602082344.GA925@patroclus> <87u1b8a2ts.fsf@zagadka.ping.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87u1b8a2ts.fsf@zagadka.ping.de> User-Agent: Mutt/1.5.4i Subject: Re: doco srfi-13 string-replace X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 07:05:05 -0000 On Mon, Jun 02, 2003 at 05:58:39PM +0200, Marius Vollmer wrote: > Martin Grabmueller writes: > > > It would be best to adjust the code to match the final SRFI, instead > > of introducing extensions. > > Hmm, how long has our code being out there already? When it has been > shipped with Guile 1.6, we need to be very conservative about changing > things that are not outright bugs. Well, you can call non-accordance to a standard a bug. But maybe you're right and we should just document the extension (which does not seem useful to me, by the way). Guile 1.6.3 has the extension, at least. 'martin From MAILER-DAEMON Tue Jun 03 07:22:40 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19N9sG-0007gu-JU for mharc-guile-devel@gnu.org; Tue, 03 Jun 2003 07:22:40 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19N9sE-0007gV-9v for guile-devel@gnu.org; Tue, 03 Jun 2003 07:22:38 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19N9sC-0007g5-Qd for guile-devel@gnu.org; Tue, 03 Jun 2003 07:22:37 -0400 Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19N9sC-0007fp-FG for guile-devel@gnu.org; Tue, 03 Jun 2003 07:22:36 -0400 Received: from dyna224-225.nada.kth.se ([130.237.224.225] helo=witch ident=mail) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 19N9sA-0001gH-00; Tue, 03 Jun 2003 13:22:34 +0200 Received: from mdj by witch with local (Exim 3.35 #1 (Debian)) id 19N9rK-0002Mg-00; Tue, 03 Jun 2003 13:21:42 +0200 To: guile-devel@gnu.org References: <873cldog5i.fsf@zip.com.au> <87fzmsf346.fsf@zip.com.au> From: Mikael Djurfeldt Date: Tue, 03 Jun 2003 13:21:42 +0200 In-Reply-To: <87fzmsf346.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 03 Jun 2003 09:53:29 +1000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Mikael Djurfeldt cc: djurfeldt@nada.kth.se Subject: Re: srfi-6 re-exports X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: djurfeldt@nada.kth.se List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 11:22:39 -0000 Kevin Ryde writes: > Mikael Djurfeldt writes: >> >> The "frisk" script correctly uses :select to explicitly ask for the >> binding "filter" in srfi-1. Of course people should be able to do >> this for *all* bindings of srfi-1, which means that we must re-export >> all core bindings. > > Is this a general rule? Yes. > For instance I wonder if srfi-6 string ports > should re-export similarly. (Below, untested.) Yes. Please apply your patch. Thanks, Mikael From MAILER-DAEMON Tue Jun 03 09:06:36 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NBUq-00045A-0T for mharc-guile-devel@gnu.org; Tue, 03 Jun 2003 09:06:36 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NBUm-000430-Ip for guile-devel@gnu.org; Tue, 03 Jun 2003 09:06:32 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NBUE-0003rc-S6 for guile-devel@gnu.org; Tue, 03 Jun 2003 09:05:59 -0400 Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.20) id 19NBKo-0001Lr-BU for guile-devel@gnu.org; Tue, 03 Jun 2003 08:56:14 -0400 Received: (qmail 11431 invoked by uid 1000); 3 Jun 2003 12:55:09 -0000 To: guile-devel@gnu.org References: <87y90kdnzy.fsf@zip.com.au> From: Marius Vollmer Date: 03 Jun 2003 14:55:09 +0200 In-Reply-To: <87y90kdnzy.fsf@zip.com.au> Message-ID: <87el2b9v82.fsf@zagadka.ping.de> Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco futures X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 13:06:33 -0000 Kevin Ryde writes: > A small start at getting some stuff out of the NEWS file and into the > manual. Excellent! > Dunno if make-future or the C functions should appear too. I'll leave > that to an executive decision. Yes, I think they should appear. It is good to be able to create a future with a function as well as with syntax. The C functions should appear as well. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Tue Jun 03 09:07:25 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NBVT-0004L6-FL for mharc-guile-devel@gnu.org; Tue, 03 Jun 2003 09:07:15 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NBSX-0003Sz-Gr for guile-devel@gnu.org; Tue, 03 Jun 2003 09:04:13 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NBRT-00036u-5l for guile-devel@gnu.org; Tue, 03 Jun 2003 09:03:07 -0400 Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.20) id 19NBRE-00035k-0I for guile-devel@gnu.org; Tue, 03 Jun 2003 09:02:52 -0400 Received: (qmail 13819 invoked by uid 1000); 3 Jun 2003 13:01:49 -0000 To: Martin Grabmueller References: <874r3lny9l.fsf@zip.com.au> <87znldmjgw.fsf@zip.com.au> <87ptlxiefv.fsf@zagadka.ping.de> <20030602082344.GA925@patroclus> <87u1b8a2ts.fsf@zagadka.ping.de> <20030603065637.GA22482@patroclus> From: Marius Vollmer Date: 03 Jun 2003 15:01:49 +0200 In-Reply-To: <20030603065637.GA22482@patroclus> Message-ID: <87adcz9uwy.fsf@zagadka.ping.de> Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: doco srfi-13 string-replace X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 03 Jun 2003 13:07:14 -0000 Martin Grabmueller writes: > On Mon, Jun 02, 2003 at 05:58:39PM +0200, Marius Vollmer wrote: > > Martin Grabmueller writes: > > > > > It would be best to adjust the code to match the final SRFI, instead > > > of introducing extensions. > > > > Hmm, how long has our code being out there already? When it has been > > shipped with Guile 1.6, we need to be very conservative about changing > > things that are not outright bugs. > > Well, you can call non-accordance to a standard a bug. But an extension does not necessarily violate the standard. All code written against the standard will work, in this case. > But maybe you're right and we should just document the extension > (which does not seem useful to me, by the way). Guile 1.6.3 has the > extension, at least. Yes, it's not a very important extension but we have it and removing it should not be done light-hearted. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 04 11:44:22 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NaM4-0008AC-Qw for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 11:39:12 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NaLK-0007nh-Qj for guile-devel@gnu.org; Wed, 04 Jun 2003 11:38:26 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NaKe-0007Ng-7X for guile-devel@gnu.org; Wed, 04 Jun 2003 11:37:45 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NaKD-0007Am-E5 for guile-devel@gnu.org; Wed, 04 Jun 2003 11:37:17 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h54FbFKN005067 for ; Thu, 5 Jun 2003 01:37:16 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h54FbFQg020996 for ; Thu, 5 Jun 2003 01:37:15 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h54FbDYZ018501 for ; Thu, 5 Jun 2003 01:37:15 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NaJx-0000Wo-00; Thu, 05 Jun 2003 01:37:01 +1000 To: guile-devel@gnu.org References: <8765nrvs9z.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 01:37:01 +1000 In-Reply-To: <8765nrvs9z.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 31 May 2003 11:06:32 +1000") Message-ID: <87n0gxkg6a.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco stat fields X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 Jun 2003 15:39:10 -0000 I wrote: > > * posix.texi (File System): stat:rdev and stat:blocks can return #f, > stat:blksize returns a sensible size if the field is not available. In absense of violent objections I made this change. I guess it's an addition to the documented interfaces, but one matching what the code has done anyway. From MAILER-DAEMON Wed Jun 04 11:51:24 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NaMl-0008Tm-LG for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 11:39:55 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NaJi-00075I-5P for guile-devel@gnu.org; Wed, 04 Jun 2003 11:36:46 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NaHz-0006Fh-Ve for guile-devel@gnu.org; Wed, 04 Jun 2003 11:35:00 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NaHk-00065D-Bl for guile-devel@gnu.org; Wed, 04 Jun 2003 11:34:44 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h54FYfKN004639 for ; Thu, 5 Jun 2003 01:34:41 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h54FYfQg020659 for ; Thu, 5 Jun 2003 01:34:41 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h54FYdYZ017513 for ; Thu, 5 Jun 2003 01:34:40 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NaHY-0000WF-00; Thu, 05 Jun 2003 01:34:32 +1000 To: guile-devel@gnu.org References: <87u1bven62.fsf@zip.com.au> <87he7ilf5a.fsf@zip.com.au> <87llwlie6u.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 01:34:30 +1000 In-Reply-To: <87llwlie6u.fsf@zagadka.ping.de> (Marius Vollmer's message of "02 Jun 2003 01:13:45 +0200") Message-ID: <87r869kgah.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco array mapping X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 Jun 2003 15:39:54 -0000 I applied this change. What I wondered before about array-map! on no source arrays and about what array-for-each does on different sized sources would be worth clarifying, but they need some thought about what can or should be supported. From MAILER-DAEMON Wed Jun 04 12:08:58 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Naos-0006p2-Az for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 12:08:58 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Naoq-0006oc-HQ for guile-devel@gnu.org; Wed, 04 Jun 2003 12:08:56 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Naoo-0006nw-Sn for guile-devel@gnu.org; Wed, 04 Jun 2003 12:08:55 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Naoo-0006nU-40 for guile-devel@gnu.org; Wed, 04 Jun 2003 12:08:54 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h54G8pKN010103 for ; Thu, 5 Jun 2003 02:08:51 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h54G8pQg024290 for ; Thu, 5 Jun 2003 02:08:51 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h54G8oYZ001200 for ; Thu, 5 Jun 2003 02:08:50 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19Naob-0004NC-00; Thu, 05 Jun 2003 02:08:41 +1000 To: guile-devel@gnu.org References: <87ade1t1p7.fsf@zip.com.au> <87d6ih5okm.fsf@zagadka.ping.de> <87smqxl1yq.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 02:08:40 +1000 In-Reply-To: <87smqxl1yq.fsf@zip.com.au> (Kevin Ryde's message of "Fri, 30 May 2003 10:20:29 +1000") Message-ID: <87adcxkepj.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: min, max and nans X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 Jun 2003 16:08:57 -0000 I wrote: > * numbers.c (scm_max, scm_min): For inum, bignum and real, if other > operand is NaN, then return NaN. Also avoid passing NaN to mpz_cmp_d. > > * tests/numbers.test (max, min): Add tests involving NaNs. I made this change. Actually, I had a bit of a brain fade and added the tests the other day, but not the code. From MAILER-DAEMON Wed Jun 04 12:33:33 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NayE-0000pm-9q for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 12:18:38 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NaYx-0004XZ-NA for guile-devel@gnu.org; Wed, 04 Jun 2003 11:52:31 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NaSu-0001wH-Eu for guile-devel@gnu.org; Wed, 04 Jun 2003 11:46:17 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NaST-0001sT-K3 for guile-devel@gnu.org; Wed, 04 Jun 2003 11:45:49 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h54FjmKN006508 for ; Thu, 5 Jun 2003 01:45:48 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h54FjlQg021911 for ; Thu, 5 Jun 2003 01:45:47 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h54FjiYZ021901 for ; Thu, 5 Jun 2003 01:45:46 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NaSH-0000XW-00; Thu, 05 Jun 2003 01:45:37 +1000 To: guile-devel@gnu.org References: <874r3lny9l.fsf@zip.com.au> <87znldmjgw.fsf@zip.com.au> <87ptlxiefv.fsf@zagadka.ping.de> <20030602082344.GA925@patroclus> <87u1b8a2ts.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 01:45:36 +1000 Message-ID: <87el29kfrz.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: Re: doco srfi-13 string-replace X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 Jun 2003 16:18:36 -0000 --=-=-= Marius Vollmer writes: > > So, please > document that behavior but clearly mark it as a "Guile extension". I made this addition, * srfi-modules.texi (SRFI-13 Miscellaneous): In string-replace, note start1 and end1 optional is a Guile extension. --=-=-= Content-Disposition: attachment; filename=srfi-modules.texi.string-replace-optional.diff --- srfi-modules.texi.~1.16.~ 2003-05-24 09:42:30.000000000 +1000 +++ srfi-modules.texi 2003-06-05 01:45:02.000000000 +1000 @@ -1803,6 +1803,9 @@ Return the string @var{s1}, but with the characters @var{start1} @dots{} @var{end1} replaced by the characters @var{start2} @dots{} @var{end2} from @var{s2}. + +For reference, note that SRFI-13 specifies @var{start1} and @var{end1} +as mandatory, but in Guile they are optional. @end deffn @deffn {Scheme Procedure} string-tokenize s [token-set start end] --=-=-=-- From MAILER-DAEMON Wed Jun 04 12:43:51 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NbGt-0005n4-Td for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 12:37:55 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NbFe-0005UX-9k for guile-devel@gnu.org; Wed, 04 Jun 2003 12:36:38 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Nb3S-0001vo-F7 for guile-devel@gnu.org; Wed, 04 Jun 2003 12:24:03 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Nb2W-0001l0-Ih for guile-devel@gnu.org; Wed, 04 Jun 2003 12:23:05 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h54GN3KN012415 for ; Thu, 5 Jun 2003 02:23:03 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h54GN2Qg025706 for ; Thu, 5 Jun 2003 02:23:02 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h54GN1YZ006540 for ; Thu, 5 Jun 2003 02:23:02 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19Nb2L-0004eZ-00; Thu, 05 Jun 2003 02:22:53 +1000 To: guile-devel@gnu.org References: <87y90kdnzy.fsf@zip.com.au> <87el2b9v82.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 02:22:52 +1000 In-Reply-To: <87el2b9v82.fsf@zagadka.ping.de> (Marius Vollmer's message of "03 Jun 2003 14:55:09 +0200") Message-ID: <8765nlke1v.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco futures X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 Jun 2003 16:37:53 -0000 Marius Vollmer writes: > > Yes, I think they should appear. It is good to be able to create a > future with a function as well as with syntax. > > The C functions should appear as well. Beaut, I added them. I didn't add future-cache-status, since it looks a bit like merely a development tool. From MAILER-DAEMON Wed Jun 04 12:50:57 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NbBn-0004NG-Qn for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 12:32:39 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NbBk-0004MR-U6 for guile-devel@gnu.org; Wed, 04 Jun 2003 12:32:36 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NbBi-0004LT-8e for guile-devel@gnu.org; Wed, 04 Jun 2003 12:32:35 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NbBh-0004KG-3T for guile-devel@gnu.org; Wed, 04 Jun 2003 12:32:33 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h54GWUKN013841 for ; Thu, 5 Jun 2003 02:32:30 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h54GWUQg026545 for ; Thu, 5 Jun 2003 02:32:30 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h54GWSYZ010152 for ; Thu, 5 Jun 2003 02:32:29 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NbBV-0004fz-00; Thu, 05 Jun 2003 02:32:21 +1000 To: guile-devel@gnu.org References: <877k84f2ps.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 02:32:19 +1000 In-Reply-To: <877k84f2ps.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 03 Jun 2003 10:02:07 +1000") Message-ID: <87znkxiz1o.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco delay X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 Jun 2003 16:32:38 -0000 I wrote: > > * scheme-evaluation.texi (Delayed Evaluation): Add delay, reword > promise? and force a bit, describe recursive forcing of a promise by > its own code. In absense of violent objections I applied this change. From MAILER-DAEMON Wed Jun 04 12:51:52 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NbRc-0001HJ-AY for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 12:49:00 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NbRE-0000zv-FX for guile-devel@gnu.org; Wed, 04 Jun 2003 12:48:36 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NbPi-0000Ek-5u for guile-devel@gnu.org; Wed, 04 Jun 2003 12:47:02 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NbFE-0005Ov-5c for guile-devel@gnu.org; Wed, 04 Jun 2003 12:36:12 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h54GaAKN014420 for ; Thu, 5 Jun 2003 02:36:10 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h54GaAQg026902 for ; Thu, 5 Jun 2003 02:36:10 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h54Ga9YZ011555 for ; Thu, 5 Jun 2003 02:36:09 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NbF4-0004gS-00; Thu, 05 Jun 2003 02:36:02 +1000 To: guile-devel@gnu.org References: <87of1gf36o.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 02:36:02 +1000 In-Reply-To: <87of1gf36o.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 03 Jun 2003 09:51:59 +1000") Message-ID: <87vfvliyvh.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: unknown # error message X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 04 Jun 2003 16:48:59 -0000 I wrote: > > * read.c (scm_input_error): Pass arg list parameter to scm_error_scm, > rather than SCM_EOL. Needed by "Unknown # object" case in scm_lreadr. > > * tests/reader.test (reading): Test bad # error message is formattable. I made this change. From MAILER-DAEMON Wed Jun 04 21:08:32 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NjF2-00082I-Bj for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 21:08:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NjEz-00081P-KS for guile-devel@gnu.org; Wed, 04 Jun 2003 21:08:29 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NjEx-00080W-Tc for guile-devel@gnu.org; Wed, 04 Jun 2003 21:08:28 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Nj77-0004kg-Mp for guile-devel@gnu.org; Wed, 04 Jun 2003 21:00:22 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5510HKN017487 for ; Thu, 5 Jun 2003 11:00:18 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5510HQg004461 for ; Thu, 5 Jun 2003 11:00:17 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5510GYZ025177 for ; Thu, 5 Jun 2003 11:00:16 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19Nj6u-0005FG-00; Thu, 05 Jun 2003 11:00:08 +1000 To: guile-devel@gnu.org References: <87smrqxt3b.fsf@zip.com.au> <878yt55od2.fsf@zagadka.ping.de> <878yt3yig4.fsf@zip.com.au> <87znlfj54m.fsf@zip.com.au> <20030522095953.GA10564@www> <87r86pi04f.fsf@zip.com.au> <20030524084653.GA19308@www> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 11:00:06 +1000 In-Reply-To: <20030524084653.GA19308@www> (tomas@fabula.de's message of "Sat, 24 May 2003 10:46:53 +0200") Message-ID: <877k81fieh.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: documentation.scm close files X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 Jun 2003 01:08:30 -0000 I toned down the words about the consequences of nearing fd limits, and applied this change. I was tempted to put the bits about file resources in the file ports node, but decided it followed on nicely enough from the closing and garbage collection in the ports node. From MAILER-DAEMON Wed Jun 04 21:21:37 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NjPL-0005ol-Rp for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 21:19:11 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NjP9-0005kw-S7 for guile-devel@gnu.org; Wed, 04 Jun 2003 21:18:59 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NjNj-0005Aw-Hl for guile-devel@gnu.org; Wed, 04 Jun 2003 21:17:33 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NjNe-00057J-FI for guile-devel@gnu.org; Wed, 04 Jun 2003 21:17:26 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h551HNKN026636 for ; Thu, 5 Jun 2003 11:17:23 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h551HNQg011223 for ; Thu, 5 Jun 2003 11:17:23 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h551HLYZ027366 for ; Thu, 5 Jun 2003 11:17:21 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NjNS-0005H7-00; Thu, 05 Jun 2003 11:17:14 +1000 To: guile-devel@gnu.org References: <87smrqxt3b.fsf@zip.com.au> <878yt55od2.fsf@zagadka.ping.de> <878yt3yig4.fsf@zip.com.au> <87znlfj54m.fsf@zip.com.au> <8765o3rosh.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 11:17:12 +1000 In-Reply-To: <8765o3rosh.fsf@zagadka.ping.de> (Marius Vollmer's message of "22 May 2003 17:20:30 +0200") Message-ID: <873cipfhlz.fsf_-_@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: doco with-input-from-file, with-output-to-file (was: documentation.scm close files) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 Jun 2003 01:19:09 -0000 Marius Vollmer writes: > > What about saying something about 'with-input-from', etc. Speaking of these, I wonder if it could be a documented feature that they use dynamic-wind to restore the current-input-port. Currently the docs follow the r5rs and don't say. The behaviour in respect of the port itself would still be unspecified, but getting current-input-port saved and restored nicely seems a pretty sensible thing. (Unless there's any prospect of an r6rs going in a different direction. :-) From MAILER-DAEMON Wed Jun 04 21:33:53 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NjW6-000165-KA for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 21:26:10 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NjUi-0000Il-6S for guile-devel@gnu.org; Wed, 04 Jun 2003 21:24:44 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NjUQ-00005t-9f for guile-devel@gnu.org; Wed, 04 Jun 2003 21:24:27 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NjQV-0006O0-WE for guile-devel@gnu.org; Wed, 04 Jun 2003 21:20:24 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h551KMKN028173 for ; Thu, 5 Jun 2003 11:20:22 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h551KLQg012480 for ; Thu, 5 Jun 2003 11:20:21 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h551KJYZ002853 for ; Thu, 5 Jun 2003 11:20:20 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NjQJ-0005HI-00; Thu, 05 Jun 2003 11:20:11 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 11:20:11 +1000 Message-ID: <87u1b5e2wk.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: README docs update X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 Jun 2003 01:26:08 -0000 --=-=-= A possible update for the README, assuming this is all true. * README (Guile Documentation): Update to manuals now available, remove notes about the reference manual being in progress. --=-=-= Content-Disposition: attachment; filename=README.docs.diff --- README.~1.92.~ 2003-05-19 07:57:57.000000000 +1000 +++ README 2003-06-05 11:19:42.000000000 +1000 @@ -294,21 +294,20 @@ Guile Documentation ================================================== -The doc directory contains a few articles on specific topics and some -examples, including data-rep.texi which describes the internal -representation of data types in Guile. The example-smob directory -contains example source code for the "Defining New Types (Smobs)" chapter. - -The incomplete Guile reference manual is available at - - ftp://ftp.red-bean.com/pub/guile/snapshots/guile-doc-snap.tar.gz - -Neil Jerram is working on the new reference manual, which will be -distributed with guile-core. The new manual will be synchronized with -the docstrings in the sources. Until then, please be aware that the -docstrings are likely to be more up-to-date than the old reference -manual (use `(help)' or see libguile/guile-procedures.txt which is -generated by the build process). +If you've never used Scheme before, then the Guile Tutorial +(guile-tut.info) is a good starting point. The Guile Reference Manual +(guile.info) is the primary documentation for Guile. The Goops object +system is documented separately (goops.info). A copy of the R5RS +Scheme specification is included too (r5rs.info). + +Info format versions of this documentation are installed as part of +the normal build process. The texinfo sources are under the doc +directory, and other formats like Postscript, PDF, DVI or HTML can be +generated from them with the Tex and Texinfo tools. + +The doc directory also includes an example-smob subdirectory which has +the example code from the "Defining New Types (Smobs)" chapter of the +reference manual. The Guile WWW page is at --=-=-=-- From MAILER-DAEMON Wed Jun 04 21:44:12 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Njmu-0002aP-LN for mharc-guile-devel@gnu.org; Wed, 04 Jun 2003 21:43:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Njmk-00025k-Gw for guile-devel@gnu.org; Wed, 04 Jun 2003 21:43:22 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Njmf-0001sb-P9 for guile-devel@gnu.org; Wed, 04 Jun 2003 21:43:18 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NjmP-0001Qs-Bd for guile-devel@gnu.org; Wed, 04 Jun 2003 21:43:01 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h551gwKN009930 for ; Thu, 5 Jun 2003 11:42:58 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h551gwQg023124 for ; Thu, 5 Jun 2003 11:42:58 +1000 (EST) Received: from localhost (ppp76.dyn228.pacific.net.au [203.143.228.76]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h551guYZ016760 for ; Thu, 5 Jun 2003 11:42:56 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19NjmB-0005II-00; Thu, 05 Jun 2003 11:42:47 +1000 To: guile-devel@gnu.org References: <87isrtmhfw.fsf@zip.com.au> <87he79ic44.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 05 Jun 2003 11:42:46 +1000 Message-ID: <878yshe1ux.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: while break and continue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 Jun 2003 01:43:30 -0000 Marius Vollmer writes: > > you shouldn't use procedure->memoizing-macro (use > define-macro instead) and that you inject literal procedures into the > expanded code. Ah right, yep. New code and prospective documentation below. The code is still pretty ugly, I suppose that's what you get for non-local exits :-). Maybe should have a caveat in the docs about style, to discourage their use. I wonder if the value parameter for break should be optional, and have while return unspecified when not given. That might be a reasonably common usage. Unless the whole thing is emulating some established convention. Incidentally, where would be a good place to put some tests? syntax.test maybe, or a new file? (define-macro (while cond . body) (let ((break-key (gensym " while break-key")) (continue-key (gensym " while continue-key"))) `(catch ',break-key (lambda () (do ((break (lambda (value) (throw ',break-key value))) (continue (lambda () (throw ',continue-key)))) ((not (catch ',continue-key (lambda () ,(if (null? body) cond ;; avoid some code if body empty `(and ,cond (begin ,@body #t)))) (lambda args #t)))))) (lambda (key value) value)))) - syntax: while cond body ... Run a loop executing BODY while COND is true. COND is tested at the start of each iteration, so if it's `#f' the first time then BODY is not executed at all. The return value is unspecified. Within `while' two additional bindings are provided, and can be used from both COND and BODY. - Scheme Procedure: break value Break out of the `while' form, and have it return the given VALUE. - Scheme Procedure: continue Abandon the current iteration, and continue with the next. Ie. go to the top of the loop, test COND again, etc. Each `while' provides separate `break' and `continue' procedures, and they operate on that `while'. So for instance when `while' loops are nested the outer `break' can be used from within the inner loop to get all the way out. (while (test1) (let ((outer-break break)) (while (test2) (if (something) (outer-break #f))))) Note that each `break' and `continue' procedure can only be used within the dynamic extent of their corresponding `while'. Once the `while' has been exited their behaviour is unspecified. From MAILER-DAEMON Thu Jun 05 07:39:56 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Nt37-000245-0N for mharc-guile-devel@gnu.org; Thu, 05 Jun 2003 07:36:53 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NsI0-0002eV-AO for guile-devel@gnu.org; Thu, 05 Jun 2003 06:48:12 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NsHV-0002Ua-0y for guile-devel@gnu.org; Thu, 05 Jun 2003 06:47:41 -0400 Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Ns4U-0008RO-G1 for guile-devel@gnu.org; Thu, 05 Jun 2003 06:34:15 -0400 Received: from dyna224-225.nada.kth.se ([130.237.224.225] helo=witch ident=mail) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 19Ns43-0006Fj-00; Thu, 05 Jun 2003 12:33:47 +0200 Received: from mdj by witch with local (Exim 3.35 #1 (Debian)) id 19Ns37-0000pF-00; Thu, 05 Jun 2003 12:32:49 +0200 To: guile-devel@gnu.org Message-Id: From: Mikael Djurfeldt Date: Thu, 05 Jun 2003 12:32:49 +0200 cc: djurfeldt@nada.kth.se cc: mvo@zagadka.de Subject: Futures bug X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: Mikael Djurfeldt List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 Jun 2003 11:36:51 -0000 Futures actually currently have a known bug. Also, since much of the rest of the threading is built on top of futures, much of the threading is also influenced by this bug: Futures are "recycled" in order to save the overhead of allocating data structures, filling them in and all OS overhead for creating a new thread. However, I don't reset the dynamic root, including the fluids array. I planned to reorganize this part in Guile a bit, trying to move as much as possible to fluids, and make fluids "copy-on-write" so that the fluids array wouldn't be copied until actually necessary. Now I'm heavily loaded with work... I'll try to fix this soon but if anyone wants to take it one before that, please feel free to do so. Mikael From MAILER-DAEMON Thu Jun 05 08:58:40 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19NuKF-0003tq-Hk for mharc-guile-devel@gnu.org; Thu, 05 Jun 2003 08:58:39 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NuKB-0003rU-VA for guile-devel@gnu.org; Thu, 05 Jun 2003 08:58:35 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NuK9-0003pY-M9 for guile-devel@gnu.org; Thu, 05 Jun 2003 08:58:34 -0400 Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.20) id 19NuBB-0000pq-F5 for guile-devel@gnu.org; Thu, 05 Jun 2003 08:49:17 -0400 Received: (qmail 5794 invoked by uid 1000); 5 Jun 2003 12:48:11 -0000 To: guile-devel@gnu.org References: <87ade1t1p7.fsf@zip.com.au> <87d6ih5okm.fsf@zagadka.ping.de> <87smqxl1yq.fsf@zip.com.au> <87adcxkepj.fsf@zip.com.au> From: Marius Vollmer Date: 05 Jun 2003 14:48:11 +0200 In-Reply-To: <87adcxkepj.fsf@zip.com.au> Message-ID: <87smqo7ks4.fsf@zagadka.ping.de> Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: min, max and nans X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 05 Jun 2003 12:58:37 -0000 Kevin Ryde writes: > I made this change. Actually, I had a bit of a brain fade and added > the tests the other day, but not the code. :-) I noticed because the snapshots didn't build successfully, but I thought I'd give you a day or two before sending you the build log... Should I make the build logs available as well? In what form? For a short time, they were posted to guile-cvs@gnu.org. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Fri Jun 06 02:13:54 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19OAU6-00083i-IW for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 02:13:54 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OAU3-000821-PP for guile-devel@gnu.org; Fri, 06 Jun 2003 02:13:51 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OAU1-0007ym-Uo for guile-devel@gnu.org; Fri, 06 Jun 2003 02:13:50 -0400 Received: from moutng.kundenserver.de ([212.227.126.184]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OAU1-0007yc-Lq for guile-devel@gnu.org; Fri, 06 Jun 2003 02:13:49 -0400 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19OAU0-00007a-00 for guile-devel@gnu.org; Fri, 06 Jun 2003 08:13:48 +0200 Received: from [80.131.37.246] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19OAU0-00066P-00 for guile-devel@gnu.org; Fri, 06 Jun 2003 08:13:48 +0200 Message-ID: <3EE03247.8040901@dirk-herrmanns-seiten.de> Date: Fri, 06 Jun 2003 08:18:47 +0200 From: Dirk Herrmann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de, en MIME-Version: 1.0 To: Guile-Devel Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Vacation X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 Jun 2003 06:13:52 -0000 Hi folks, I will be on vacation for the next weeks. Thus, if I have broken anything badly in CVS, I will not be able to fix it soon. (Not expecting any problems, just in case...). Afterwards, I will continue to integrate patches that allow a smooth transition to the separated memoization and execution. Best regards, Dirk From MAILER-DAEMON Fri Jun 06 12:32:33 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19OK8m-00083T-OL for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 12:32:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OK8k-00082g-JD for guile-devel@gnu.org; Fri, 06 Jun 2003 12:32:30 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OJjF-0000dM-US for guile-devel@gnu.org; Fri, 06 Jun 2003 12:06:10 -0400 Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OJhw-0000Qj-RC for guile-devel@gnu.org; Fri, 06 Jun 2003 12:04:48 -0400 Received: from dyna224-225.nada.kth.se ([130.237.224.225] helo=witch ident=mail) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 19OJhp-0006UL-00; Fri, 06 Jun 2003 18:04:41 +0200 Received: from mdj by witch with local (Exim 3.35 #1 (Debian)) id 19OJgp-0002KK-00; Fri, 06 Jun 2003 18:03:39 +0200 To: Marius Vollmer References: <87ade1t1p7.fsf@zip.com.au> <87d6ih5okm.fsf@zagadka.ping.de> <87smqxl1yq.fsf@zip.com.au> <87adcxkepj.fsf@zip.com.au> <87smqo7ks4.fsf@zagadka.ping.de> From: Mikael Djurfeldt Date: Fri, 06 Jun 2003 18:03:38 +0200 In-Reply-To: <87smqo7ks4.fsf@zagadka.ping.de> (Marius Vollmer's message of "05 Jun 2003 14:48:11 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Mikael Djurfeldt cc: guile-devel@gnu.org cc: djurfeldt@nada.kth.se Subject: Re: min, max and nans X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: djurfeldt@nada.kth.se List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 Jun 2003 16:32:31 -0000 Marius Vollmer writes: > Kevin Ryde writes: > >> I made this change. Actually, I had a bit of a brain fade and added >> the tests the other day, but not the code. > > :-) I noticed because the snapshots didn't build successfully, but I > thought I'd give you a day or two before sending you the build log... > > Should I make the build logs available as well? In what form? For a > short time, they were posted to guile-cvs@gnu.org. In my opinion, the idea of sending build logs at failure (not when Guile compiles and tests OK) to guile-cvs@gnu.org is an excellent idea. If I have at any time been critical against it, it was because it is a good idea to start off with no build failures so that people feel motivated to fix things. M From MAILER-DAEMON Fri Jun 06 18:27:03 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19OPeU-0004U8-Sf for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 18:25:38 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OPe9-00049O-3C for guile-devel@gnu.org; Fri, 06 Jun 2003 18:25:17 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OPdy-0003lA-BU for guile-devel@gnu.org; Fri, 06 Jun 2003 18:25:08 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OPdJ-0002yV-1b for guile-devel@gnu.org; Fri, 06 Jun 2003 18:24:25 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h56MOMKN019800 for ; Sat, 7 Jun 2003 08:24:22 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h56MOMQg014110 for ; Sat, 7 Jun 2003 08:24:22 +1000 (EST) Received: from localhost (ppp51.dyn228.pacific.net.au [203.143.228.51]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h56MOKYZ016464 for ; Sat, 7 Jun 2003 08:24:20 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19OPd3-00063e-00; Sat, 07 Jun 2003 08:24:09 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Sat, 07 Jun 2003 08:24:09 +1000 Message-ID: <87znku26ba.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco primitive numerics C funcs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 Jun 2003 22:25:26 -0000 --=-=-= * scheme-data.texi (Primitive Numerics): Add atan2, pow, asinh, acosh and atanh to scheme<->C table. Note asinh, acosh and atanh are C99, and scm_asinh, scm_acosh and scm_atanh are equivalents. Cross ref glibc "Mathematics". Reword this end part for clarity. I think it's clearer to have the scheme<->C table first, then the extra inverse-hyperbolics. I found the bit except `expt' and `atan2' (whose entries specifically mention an equivalent C function) a little unclear. I thought it was saying there were C "double" functions mentioned, where instead it's SCM functions. I think this can be quietly dropped now $expt<->pow and $atan2<->atan2 are in the table. For ease of contemplation, the end part proposed is, C functions for the above are provided by the standard mathematics library. Naturally these expect and return `double' arguments (*note Mathematics: (libc)Mathematics.). Scheme Procedure C Function `$abs' `fabs' `$sqrt' `sqrt' `$sin' `sin' `$cos' `cos' `$tan' `tan' `$asin' `asin' `$acos' `acos' `$atan' `atan' `$atan2' `atan2' `$exp' `exp' `$expt' `pow' `$log' `log' `$sinh' `sinh' `$cosh' `cosh' `$tanh' `tanh' `$asinh' `asinh' `$acosh' `acosh' `$atanh' `atanh' `asinh', `acosh' and `atanh' are C99 standard but might not be available on older systems. Guile provides the following equivalents (on all systems). - C Function: double scm_asinh (double x) - C Function: double scm_acosh (double x) - C Function: double scm_atanh (double x) Return the hyperbolic arcsine, arccosine or arctangent of X respectively. --=-=-= Content-Disposition: attachment; filename=scheme-data.texi.primitive-numerics.diff --- scheme-data.texi.~1.30.~ 2003-05-24 09:49:12.000000000 +1000 +++ scheme-data.texi 2003-06-06 11:48:39.000000000 +1000 @@ -1014,21 +1014,9 @@ Return the hyperbolic arctangent of @var{x}. @end deffn -For the hyperbolic arc-functions, the Guile library exports C functions -corresponding to these Scheme procedures, but taking and returning -arguments of type @code{double} rather than the usual @code{SCM}. - -@deftypefn {C Function} double scm_asinh (double x) -@deftypefnx {C Function} double scm_acosh (double x) -@deftypefnx {C Function} double scm_atanh (double x) -Return the hyperbolic arcsine, arccosine or arctangent of @var{x} -respectively. -@end deftypefn - -For all the other Scheme procedures above, except @code{expt} and -@code{atan2} (whose entries specifically mention an equivalent C -function), the equivalent C functions are those provided by the standard -mathematics library. The mapping is as follows. +C functions for the above are provided by the standard mathematics +library. Naturally these expect and return @code{double} arguments +(@pxref{Mathematics,,, libc, GNU C Library Reference Manual}). @multitable {xx} {Scheme Procedure} {C Function} @item @tab Scheme Procedure @tab C Function @@ -1041,15 +1029,28 @@ @item @tab @code{$asin} @tab @code{asin} @item @tab @code{$acos} @tab @code{acos} @item @tab @code{$atan} @tab @code{atan} +@item @tab @code{$atan2} @tab @code{atan2} @item @tab @code{$exp} @tab @code{exp} +@item @tab @code{$expt} @tab @code{pow} @item @tab @code{$log} @tab @code{log} @item @tab @code{$sinh} @tab @code{sinh} @item @tab @code{$cosh} @tab @code{cosh} @item @tab @code{$tanh} @tab @code{tanh} +@item @tab @code{$asinh} @tab @code{asinh} +@item @tab @code{$acosh} @tab @code{acosh} +@item @tab @code{$atanh} @tab @code{atanh} @end multitable -@noindent -Naturally, these C functions expect and return @code{double} arguments. +@code{asinh}, @code{acosh} and @code{atanh} are C99 standard but might +not be present on older systems. Guile provides the following +equivalents (on all systems). + +@deftypefn {C Function} double scm_asinh (double x) +@deftypefnx {C Function} double scm_acosh (double x) +@deftypefnx {C Function} double scm_atanh (double x) +Return the hyperbolic arcsine, arccosine or arctangent of @var{x} +respectively. +@end deftypefn @node Bitwise Operations --=-=-=-- From MAILER-DAEMON Fri Jun 06 18:33:45 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19OPlu-0001Kq-2B for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 18:33:18 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OPjt-0008Q9-Vd for guile-devel@gnu.org; Fri, 06 Jun 2003 18:31:13 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OPjW-00080e-3B for guile-devel@gnu.org; Fri, 06 Jun 2003 18:30:50 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OPiZ-0007MQ-5X for guile-devel@gnu.org; Fri, 06 Jun 2003 18:29:51 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h56MTnKN021217 for ; Sat, 7 Jun 2003 08:29:49 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h56MTnQg015613 for ; Sat, 7 Jun 2003 08:29:49 +1000 (EST) Received: from localhost (ppp51.dyn228.pacific.net.au [203.143.228.51]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h56MTlYZ019537 for ; Sat, 7 Jun 2003 08:29:48 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19OPiL-00065j-00; Sat, 07 Jun 2003 08:29:37 +1000 To: guile-devel@gnu.org References: <878ysxl0z8.fsf@zip.com.au> <87r86djxww.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sat, 07 Jun 2003 08:29:37 +1000 Message-ID: <87r8662626.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: Re: scm_t_bits versus uintptr_t X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 Jun 2003 22:33:17 -0000 --=-=-= Marius Vollmer writes: > > Yes, that is the intention. Could you fix this? * tags.h: Use inttypes.h and stdint.h when available, for INTPTR_MAX and friends required by scm_t_bits setups. --=-=-= Content-Disposition: attachment; filename=tags.h.inttypes.diff --- tags.h.~1.100.~ 2003-06-05 00:30:58.000000000 +1000 +++ tags.h 2003-06-07 08:26:00.000000000 +1000 @@ -29,6 +29,14 @@ /* picks up scmconfig.h too */ #include "libguile/__scm.h" +#if HAVE_INTTYPES_H +# include /* for INTPTR_MAX and friends */ +#else +# if HAVE_STDINT_H +# include /* for INTPTR_MAX and friends */ +# endif +#endif + /* In the beginning was the Word: */ #if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) --=-=-=-- From MAILER-DAEMON Fri Jun 06 18:34:21 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19OPms-0003ro-Vi for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 18:34:18 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OPmG-000246-Gd for guile-devel@gnu.org; Fri, 06 Jun 2003 18:33:40 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OPlS-0000sR-1Y for guile-devel@gnu.org; Fri, 06 Jun 2003 18:32:53 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OPkk-0000Lg-E6 for guile-devel@gnu.org; Fri, 06 Jun 2003 18:32:06 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h56MW2KN021763 for ; Sat, 7 Jun 2003 08:32:02 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h56MW2Qg016966 for ; Sat, 7 Jun 2003 08:32:02 +1000 (EST) Received: from localhost (ppp51.dyn228.pacific.net.au [203.143.228.51]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h56MVuYZ020717 for ; Sat, 7 Jun 2003 08:32:01 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19OPkL-000666-00; Sat, 07 Jun 2003 08:31:41 +1000 To: guile-devel@gnu.org References: <87isrtmhfw.fsf@zip.com.au> <87he79ic44.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sat, 07 Jun 2003 08:31:40 +1000 Message-ID: <87isri25yr.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: while break and continue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 Jun 2003 22:34:17 -0000 Marius Vollmer writes: > > inject literal procedures into the expanded code. Yes, that was for some wrong reasons. On this subject though, is it worth expanding to actual procedures rather than symbols, so one gets the intended effect irrespective of local bindings at the point used? I don't suppose anyone goes out of their way to shadow standard stuff, but it's probably nice to take precautions. From MAILER-DAEMON Fri Jun 06 18:36:51 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19OPpC-0000PB-TB for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 18:36:42 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OPoO-0008DO-DX for guile-devel@gnu.org; Fri, 06 Jun 2003 18:35:52 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OPo2-0007JK-Nt for guile-devel@gnu.org; Fri, 06 Jun 2003 18:35:36 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OPnu-0006kx-H2 for guile-devel@gnu.org; Fri, 06 Jun 2003 18:35:23 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h56MZJKN022582 for ; Sat, 7 Jun 2003 08:35:19 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h56MZJQg017846 for ; Sat, 7 Jun 2003 08:35:19 +1000 (EST) Received: from localhost (ppp51.dyn228.pacific.net.au [203.143.228.51]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h56MZHYZ022671 for ; Sat, 7 Jun 2003 08:35:18 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19OPnh-00066a-00; Sat, 07 Jun 2003 08:35:09 +1000 To: guile-devel@gnu.org References: <873cldog5i.fsf@zip.com.au> <87fzmsf346.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Sat, 07 Jun 2003 08:35:09 +1000 Message-ID: <87adcu25sy.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: srfi-6 re-exports X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 Jun 2003 22:36:40 -0000 Mikael Djurfeldt writes: > > Yes. Please apply your patch. I added a test program too, to exercise this. And some tests on the functions, just so it's not a two line file :-). * srfi-6.scm: #:re-export open-input-string, open-output-string and get-output-string, for the benefit of applications wanting to use #:select on the module. * tests/srfi-6.test: New file. From MAILER-DAEMON Fri Jun 06 19:29:43 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19OQdD-0005tl-2u for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 19:28:23 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OQYm-0003rB-UZ for guile-devel@gnu.org; Fri, 06 Jun 2003 19:23:48 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OQUH-0002TX-Ti for guile-devel@gnu.org; Fri, 06 Jun 2003 19:19:13 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OQTv-0002Ft-Eq for guile-devel@gnu.org; Fri, 06 Jun 2003 19:18:47 -0400 Received: from dialin.speedway42.dip73.dokom.de ([195.138.42.73] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19OQTu-0007EP-00 for guile-devel@gnu.org; Sat, 07 Jun 2003 01:18:46 +0200 Received: (qmail 16290 invoked by uid 1000); 6 Jun 2003 23:17:39 -0000 To: djurfeldt@nada.kth.se References: <87ade1t1p7.fsf@zip.com.au> <87d6ih5okm.fsf@zagadka.ping.de> <87smqxl1yq.fsf@zip.com.au> <87adcxkepj.fsf@zip.com.au> <87smqo7ks4.fsf@zagadka.ping.de> From: Marius Vollmer Date: 07 Jun 2003 01:17:38 +0200 In-Reply-To: Message-ID: <87r8666bjh.fsf@zagadka.ping.de> Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: min, max and nans X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 06 Jun 2003 23:28:20 -0000 Mikael Djurfeldt writes: > In my opinion, the idea of sending build logs at failure (not when > Guile compiles and tests OK) to guile-cvs@gnu.org is an excellent > idea. > > If I have at any time been critical against it, it was because it is a > good idea to start off with no build failures so that people feel > motivated to fix things. Hehe, yeah, I could totally understand your point (if I understood it ;-). For those interested: the snapshots were failing for over a week due to problems in the build environment (I think). I didn't get around to fix the build environment in a timely manner and so people saw error logs that were not relevant to them. That could only teach them to ignore these logs. So I stopped posting them automatically. We _did_ start off with no build failures but that was hard to notice since no logs are sent when there is no build failure. I think it is also OK when just I myself watch the logs and contact the people that I deem responsible for failures. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Fri Jun 06 20:23:11 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19ORTu-00081C-2n for mharc-guile-devel@gnu.org; Fri, 06 Jun 2003 20:22:50 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19ORTG-0007Z5-VC for guile-devel@gnu.org; Fri, 06 Jun 2003 20:22:10 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19ORT3-0007RA-QE for guile-devel@gnu.org; Fri, 06 Jun 2003 20:22:00 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19ORQ8-0004Ve-5i for guile-devel@gnu.org; Fri, 06 Jun 2003 20:18:56 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h570IqKN018735 for ; Sat, 7 Jun 2003 10:18:53 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h570IqQg021243 for ; Sat, 7 Jun 2003 10:18:52 +1000 (EST) Received: from localhost (ppp51.dyn228.pacific.net.au [203.143.228.51]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h570IpYZ001151 for ; Sat, 7 Jun 2003 10:18:52 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19ORPv-0006Dd-00; Sat, 07 Jun 2003 10:18:43 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Sat, 07 Jun 2003 10:18:43 +1000 Message-ID: <87isriyc2k.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco floor, ceiling xref X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 07 Jun 2003 00:22:47 -0000 --=-=-= FYI, * scheme-data.texi (Arithmetic): Cross reference glibc floor and ceil. --=-=-= Content-Disposition: attachment; filename=scheme-data.texi.round-xref.diff --- scheme-data.texi.~1.30.~ 2003-06-07 10:16:33.000000000 +1000 +++ scheme-data.texi 2003-06-07 10:16:53.000000000 +1000 @@ -802,8 +802,9 @@ @end deftypefn For @code{floor} and @code{ceiling}, the equivalent C functions are -@code{floor} and @code{ceil} from the standard mathematics library -(which also take and return @code{double} arguments). +@code{floor} and @code{ceil} from the standard mathematics library, +which also take and return @code{double} arguments (@pxref{Rounding +Functions,,, libc, GNU C Library Reference Manual}). @node Scientific --=-=-=-- From MAILER-DAEMON Sat Jun 07 21:20:14 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Ooqi-0008Ll-AQ for mharc-guile-devel@gnu.org; Sat, 07 Jun 2003 21:19:56 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Ooq2-0007cL-EY for guile-devel@gnu.org; Sat, 07 Jun 2003 21:19:14 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Oopg-0007Du-Fz for guile-devel@gnu.org; Sat, 07 Jun 2003 21:18:57 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Oop4-0006ey-QI for guile-devel@gnu.org; Sat, 07 Jun 2003 21:18:15 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h581ICYd029347 for ; Sun, 8 Jun 2003 11:18:12 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h581IBQg010176 for ; Sun, 8 Jun 2003 11:18:11 +1000 (EST) Received: from localhost (ppp79.dyn228.pacific.net.au [203.143.228.79]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h581I9YZ007902 for ; Sun, 8 Jun 2003 11:18:09 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19Ooon-00015g-00; Sun, 08 Jun 2003 11:17:57 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Sun, 08 Jun 2003 11:17:57 +1000 Message-ID: <874r318j0a.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco new parallel funcs from news file X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 08 Jun 2003 01:19:54 -0000 --=-=-= A bit more out of the news file and into the manual, * scheme-scheduling.texi (Higher level thread procedures): Add parallel, letpar, par-map, par-for-each, n-par-map, n-par-for-each, n-for-each-par-map. I haven't actually been using these, so I've only copied what the news file said and what I could guess. Needs to be checked for accuracy. - syntax: parallel form1 ... formN Evaluate each given FORM, in parallel, each in a new thread. Return the results as a set of N multiple values (*note Multiple Values::). - syntax: letpar ((var expr) ...) body... Evaluate each EXPR, in parallel, each in a new thread, then bind the results to the corresponding VAR variables and evaluate BODY. This is like `let' (*note Local Bindings::), but the expressions in the bindings are evaluated in parallel. - Scheme Procedure: par-map proc lst1 ... lstN - Scheme Procedure: par-for-each proc lst1 ... lstN Call PROC on the elements of the given lists. `par-map' returns a list comprising the return values from PROC. `par-for-each' returns an unspecified value. The PROC calls are `(PROC ELEM1 ... ELEMN)', where each ELEM is from the corresponding LST. Each LST must be the same length. The calls are made in parallel, each in a new thread. All calls are completed before the functions return. These functions are like `map' and `for-each' (*note List Mapping::), but make their PROC calls in parallel. - Scheme Procedure: n-par-map n proc lst1 ... lstN - Scheme Procedure: n-par-for-each n proc lst1 ... lstN Call PROC on the elements of the given lists, in the same way as `par-map' and `par-for-each' above, but use no more than N threads at any one time. The order in which calls are initiated within that limit is unspecified. These functions are good for controlling resource consumption if each call might be costly, or if there are many to be made. On a dual-CPU system for instance N=4 might be enough to keep the CPUs utilized, and not consume too much memory. - Scheme Procedure: n-for-each-par-map n sproc pproc lst1 ... lstN Apply PPROC to the elements of the given lists, and apply SPROC to each result returned by PPROC. The final return value is unspecified. The calls are `(SPROC (PPROC ELEM1 ... ELEMN))', where each ELEM is from the corresponding LST. Each LST must have the same number of elements. The PPROC calls are made in parallel, in new threads. The SPROC calls are made serially, in list element order, and only one at a time. PPROC calls may execute in parallel with the SPROC calls. Exactly which thread makes each SPROC call is unspecified. No more than N threads are used at any one time. The order in which PPROC calls are initiated within that limit is unspecified. All calls are completed before `n-for-each-par-map' returns. This function is designed for individual calculations that can be done in parallel, but with results needing to be handled serially, for instance to write them to a file. The N limit on parallelism controls system resource usage when there are many calculations or when they might be costly. It will be seen that `n-for-each-par-map' is like a combination of `n-par-map' and `for-each', (for-each sproc (n-par-map pproc lst1 ... lstN)) But the actual implementation is more efficient since each SPROC call, in turn, can be initiated once the relevant PPROC call has completed, it doesn't need to wait for all to finish. --=-=-= Content-Disposition: attachment; filename=NEWS.parallel.diff --- NEWS.~1.396.~ 2003-06-05 02:42:45.000000000 +1000 +++ NEWS 2003-06-07 18:01:49.000000000 +1000 @@ -283,37 +283,11 @@ Futures are like promises, but begun immediately in a new thread. See the "Futures" section in the reference manual. -** New syntax: parallel FORM ... +** New threading functions: parallel, letpar, par-map, and friends -Compute the results of FORM ... in parallel (in a separate thread for -each form) and return them as multiple values. - -** New syntax: letpar ((VAR EXP) ...) BODYFORM ... - -Like 'let' but evaluates the binding expressions EXP ... in parallel. - -** New functions: par-map, par-for-each PROC ARGLIST ... - -Like 'map' and 'for-each' but evaluate the procedure PROC in a -separate thread for each (set of) argument(s). All applications are -guaranteed to be completed before the procedure returns. - -** New functions: n-par-map, n-par-for-each N PROC ARGLIST ... - -Like 'par-map' and 'par-for-each' but evaluate the procedure PROC in N -threads. This is useful when PROC uses large amounts of resources -and/or the argument list(s) is/are long so that one thread per (set -of) argument(s) would consume too much system resources. On a -dual-CPU system, N = 4 would often be a good choice. - -** New function: n-for-each-par-map N S-PROC P-PROC ARGLIST ... - -Using N parallel processes, apply S-PROC in serial order to each -result of applying P-PROC to each set of arguments in the argument -lists ARGLIST ... - -Like a composition of 'for-each' and 'n-par-map', but allows S-PROC to -start processing while the results of P-PROC are being produced. +These are convenient ways to run calculations in parallel in new +threads. See "High level thread procedures" in the manual for +details. ** Fair mutexes and condition variables --=-=-=-- From MAILER-DAEMON Sun Jun 08 18:04:30 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19P8H8-0007B4-3Y for mharc-guile-devel@gnu.org; Sun, 08 Jun 2003 18:04:30 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19P8H5-00074u-BA for guile-devel@gnu.org; Sun, 08 Jun 2003 18:04:27 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19P8H2-00072O-Ev for guile-devel@gnu.org; Sun, 08 Jun 2003 18:04:26 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19P8H1-0006uy-41 for guile-devel@gnu.org; Sun, 08 Jun 2003 18:04:23 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h58M4IYd010985; Mon, 9 Jun 2003 08:04:20 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h58M4IQg016221; Mon, 9 Jun 2003 08:04:18 +1000 (EST) Received: from localhost (ppp18.dyn228.pacific.net.au [203.143.228.18]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h58M4FYZ006458; Mon, 9 Jun 2003 08:04:17 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19P8GD-0000Py-00; Mon, 09 Jun 2003 08:03:33 +1000 To: stefan References: From: Kevin Ryde Mail-Copies-To: never Date: Mon, 09 Jun 2003 08:03:33 +1000 Message-ID: <877k7wgrbe.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 08 Jun 2003 22:04:28 -0000 --=-=-= stefan writes: > > I just added a check for unsetenv() in the configure script and used it in > posix.c appropiately for mingw32 hosts. Which means that a > putenv("name="); would remove the environment variable 'name'. I think there's a small memory leak there, viz (while #t (putenv "FOO")) Perhaps * posix.c (s_scm_putenv): Free temporary ptr in mingw unset. Of course the main putenv bit also leaks, but that's another story :-). --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=posix.c.mingw-putenv.diff --- posix.c.~1.114.~ 2003-05-31 09:42:53.000000000 +1000 +++ posix.c 2003-06-08 17:57:04.000000000 +1000 @@ -1157,7 +1157,7 @@ "The return value is unspecified.") #define FUNC_NAME s_scm_putenv { - int rv; + int rv, e; char *ptr; SCM_VALIDATE_STRING (1, str); @@ -1177,6 +1177,7 @@ ptr[SCM_STRING_LENGTH (str)] = '='; ptr[SCM_STRING_LENGTH (str) + 1] = 0; rv = putenv (ptr); + e = errno; free (ptr); errno = e; if (rv < 0) SCM_SYSERROR; #endif --=-=-=-- From MAILER-DAEMON Sun Jun 08 18:08:30 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19P8Kp-0003xZ-AS for mharc-guile-devel@gnu.org; Sun, 08 Jun 2003 18:08:19 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19P8Km-0003p9-30 for guile-devel@gnu.org; Sun, 08 Jun 2003 18:08:16 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19P8KY-0003SP-Oy for guile-devel@gnu.org; Sun, 08 Jun 2003 18:08:03 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19P8KW-0003Gk-ES for guile-devel@gnu.org; Sun, 08 Jun 2003 18:08:00 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h58M7wYd011414 for ; Mon, 9 Jun 2003 08:07:58 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h58M7wQg016470 for ; Mon, 9 Jun 2003 08:07:58 +1000 (EST) Received: from localhost (ppp18.dyn228.pacific.net.au [203.143.228.18]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h58M7uYZ007878 for ; Mon, 9 Jun 2003 08:07:56 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19P8KH-0000QF-00; Mon, 09 Jun 2003 08:07:45 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Mon, 09 Jun 2003 08:07:45 +1000 Message-ID: <87y90cfcjy.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: parallel with no exprs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 08 Jun 2003 22:08:17 -0000 --=-=-= I tried using parallel with no expressions, (use-modules (ice-9 threads)) (call-with-values (lambda () (parallel)) (lambda () (display "hi\n"))) but got ERROR: In procedure lambda: ERROR: bad body Is parallel allowed to be called with no expressions? It'd be pretty silly to write that deliberately, but perhaps it could arise from a simple-minded macro expansion or something. * threads.scm (parallel): For no forms, use `(values)' not `(begin)'. * tests/threads.test: New file, exercising "parallel". --=-=-= Content-Disposition: attachment; filename=threads.scm.parallel-empty.diff --- threads.scm.~1.21.~ 2003-04-28 07:51:19.000000000 +1000 +++ threads.scm 2003-06-08 14:31:57.000000000 +1000 @@ -182,7 +182,7 @@ %thread-handler))) (define-macro (parallel . forms) - (cond ((null? forms) '(begin)) + (cond ((null? forms) '(values)) ((null? (cdr forms)) (car forms)) (else (let ((vars (map (lambda (f) --=-=-= Content-Disposition: attachment; filename=threads.test ;;;; threads.test --- Tests for Guile threading. -*- scheme -*- ;;;; ;;;; Copyright 2003 Free Software Foundation, Inc. ;;;; ;;;; This program is free software; you can redistribute it and/or modify ;;;; it under the terms of the GNU General Public License as published by ;;;; the Free Software Foundation; either version 2, or (at your option) ;;;; any later version. ;;;; ;;;; This program is distributed in the hope that it will be useful, ;;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;;; GNU General Public License for more details. ;;;; ;;;; You should have received a copy of the GNU General Public License ;;;; along with this software; see the file COPYING. If not, write to ;;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;;; Boston, MA 02111-1307 USA (use-modules (ice-9 threads) (test-suite lib)) (with-test-prefix "parallel" (pass-if "0" (call-with-values (lambda () (parallel)) (lambda () #t))) (pass-if "1" (call-with-values (lambda () (parallel 1)) (lambda (x) (equal? x 1)))) (pass-if "1 2" (call-with-values (lambda () (parallel 1 2)) (lambda (x y) (and (equal? x 1) (equal? y 2))))) (pass-if "1 2 3" (call-with-values (lambda () (parallel 1 2 3)) (lambda (x y z) (and (equal? x 1) (equal? y 2) (equal? z 3)))))) --=-=-=-- From MAILER-DAEMON Mon Jun 09 04:39:12 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19PIAG-0000MD-Qv for mharc-guile-devel@gnu.org; Mon, 09 Jun 2003 04:38:04 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19PI9b-0008CG-Qp for guile-devel@gnu.org; Mon, 09 Jun 2003 04:37:23 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19PI9N-00080F-D4 for guile-devel@gnu.org; Mon, 09 Jun 2003 04:37:10 -0400 Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PI89-0007SE-MY for guile-devel@gnu.org; Mon, 09 Jun 2003 04:35:53 -0400 Received: from mdj by kvast.blakulla.net with local (Exim 3.36 #1 (Debian)) id 19PI86-0003vo-00; Mon, 09 Jun 2003 10:35:50 +0200 To: guile-devel@gnu.org References: <87y90cfcjy.fsf@zip.com.au> From: Mikael Djurfeldt Date: Mon, 09 Jun 2003 10:35:50 +0200 In-Reply-To: <87y90cfcjy.fsf@zip.com.au> (Kevin Ryde's message of "Mon, 09 Jun 2003 08:07:45 +1000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: djurfeldt@nada.kth.se Subject: Re: parallel with no exprs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: djurfeldt@nada.kth.se List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 09 Jun 2003 08:38:02 -0000 Kevin Ryde writes: > I tried using parallel with no expressions, > > (use-modules (ice-9 threads)) > (call-with-values > (lambda () > (parallel)) > (lambda () > (display "hi\n"))) > > but got > > ERROR: In procedure lambda: > ERROR: bad body > > Is parallel allowed to be called with no expressions? It'd be pretty > silly to write that deliberately, but perhaps it could arise from a > simple-minded macro expansion or something. > > * threads.scm (parallel): For no forms, use `(values)' not `(begin)'. > > * tests/threads.test: New file, exercising "parallel". > > > --- threads.scm.~1.21.~ 2003-04-28 07:51:19.000000000 +1000 > +++ threads.scm 2003-06-08 14:31:57.000000000 +1000 > @@ -182,7 +182,7 @@ > %thread-handler))) > > (define-macro (parallel . forms) > - (cond ((null? forms) '(begin)) > + (cond ((null? forms) '(values)) > ((null? (cdr forms)) (car forms)) > (else > (let ((vars (map (lambda (f) Please don't apply this patch. The original code is correct. The error instead lies in the use of parallel. You'll find that for example (use-modules (ice-9 threads)) (call-with-values (lambda () (display "hello\n") (parallel)) (lambda () (display "hi\n"))) will be accepted. (lambda () (parallel)) correctly yields an error message since that is a lambda with no expressions in the body. Best regards, Mikael From MAILER-DAEMON Mon Jun 09 15:52:55 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19PSgG-0002CI-DT for mharc-guile-devel@gnu.org; Mon, 09 Jun 2003 15:51:48 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19PSfq-0001xH-Cp for guile-devel@gnu.org; Mon, 09 Jun 2003 15:51:22 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19PSdJ-0000zs-Dg for guile-devel@gnu.org; Mon, 09 Jun 2003 15:48:56 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PSc8-0008Ty-J1 for guile-devel@gnu.org; Mon, 09 Jun 2003 15:47:32 -0400 Received: from dialin.speedway42.dip223.dokom.de ([195.138.42.223] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19PScA-0004mw-00 for guile-devel@gnu.org; Mon, 09 Jun 2003 21:47:34 +0200 Received: (qmail 24794 invoked by uid 1000); 9 Jun 2003 19:46:18 -0000 To: Bruce Korb References: <87iss97ak0.fsf@zagadka.ping.de> <3EC67BA0.2C8FF637@veritas.com> <878yslps9q.fsf@zagadka.ping.de> <3EDA5A7C.D0FB7603@veritas.com> From: Marius Vollmer Date: 09 Jun 2003 21:46:17 +0200 In-Reply-To: <3EDA5A7C.D0FB7603@veritas.com> Message-ID: <87llwb9gqe.fsf@zagadka.ping.de> Lines: 95 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: Re-addition of deprecated stuff to 1.7. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 09 Jun 2003 19:51:46 -0000 Bruce Korb writes: > Marius Vollmer wrote: > > > I'd say it is a trade-off between how much pain you are willing to > > inflict upon your clients and how much pain you are willing to suffer > > yourself. > > > > I think (and hope) it is entirely tolerable to require you clients to > > install Guile 1.6 when they want to compile your code. > > As the author of a piece of code that is relatively obscure, > it is tough enough to get it test-driven, let alone test-driven > after they have had to upgrade something else. Current distributions > are still using 1.4 (leastwise the latest Red Hat 7.x and SuSE 8.1 > use it). These releases are not even a year old yet. It *will* > be a couple of years before it is reasonable to expect all potential > clients to have 1.6. Yes, maybe. What about talking the distros into providing Guile 1.6 sooner? That would make more sense, in my view. We could provide RPMs for Red Hat, Suse, and DEBs for Debian stable. That will make it easier to retrofit ones system with Guile 1.6. > I sent some macros, tho I coded around the need to use it myself. > > > These configure snippets might be collected in a central place, maybe, > > when people are willing to maintain such a thing. > > That's what I was suggesting... Ok. So how shall we proceed? I'm don't want to make it a release-critical goal of Guile 1.8 to come with such a set of snippets unless there is more demand from 'the community'. However, the snippets can be collected in the Guile CVS repo, when people want to do that. We will have to apply all the usual FSF legal rules to them, tho: copyright must be assigned, etc. > [...] I do want to say that the compatibility glue is important. I > am now developing against 1.6. However, as much as you would like > to see 1.4 retired, the bulk of the distributions at this time have > 1.4. I need to be able to jigger what I use so it can adapt to > whatever is locally installed. So you are effectively targeting 1.4 and 1.6, not just 1.6 alone. I'm not sure what kind of compatability glue you are talking about: do you want to have a layer that makes 1.4 identical to 1.6? Or do you want a layer that fixes bugs (such as the gh_scm2newstring size_t bug) so that code that worked with 1.4 continues to work with 1.6? Neither of these two types of compatability glue makes much sense to me: for the first, it is easier to use the genuine Guile 1.6 as the 'layer'. Just package it with your code when you don't want your clients to download and install it themselves. For the second type, it is easier to just stick with Guile 1.4, which should be available already on your clients system, as you say. > By the time the bulk of installations are running 1.6, you'll be > shipping 1.8 and using the same arguments. Yes. And I sill think they are sensible arguments. > [...] OTOH, when you retire ``scm_port'' you could also add: > > #if (THE_LAST_GUILE_VERSION_I_KNEW_ABOUT < GUILE_VERSION_1_6) > # define scm_port scm_t_port > #endif > > and delete that code only after 1.6 has been in the major distros > for a couple of years. Yes, we are doing this now (kind of) and are being more careful than we have been with 1.6. See the "Handling of Deprecated Features" section in the README. Incidentally, "scm_port" is available with Guile 1.6, but I see that you want to have "scm_t_port" with 1.4. That's a strange thing to do, in my view: you can't get the 'goodness' of 1.6 from 1.4. You might create the illusion in simple cases like scm_port, but this wont work in general. The result is code that is written is then a, in your own words: > The Guile version I understand is a mix of 1.4 and 1.6 'cuz I'm > transitioning. Coding for such a mixed API is not on the path of least pain, I'd say. > > It is of course good practice to minimize the needed changes, > > I'm sure you do your best. One's best cannot ever be perfect. But we are getting better! :-) -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Mon Jun 09 16:19:19 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19PT3i-00086x-LL for mharc-guile-devel@gnu.org; Mon, 09 Jun 2003 16:16:02 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19PSsq-0005Xm-0p for guile-devel@gnu.org; Mon, 09 Jun 2003 16:04:48 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19PSmx-0003ZR-Ck for guile-devel@gnu.org; Mon, 09 Jun 2003 15:58:44 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PSjV-0002yR-3T for guile-devel@gnu.org; Mon, 09 Jun 2003 15:55:09 -0400 Received: from dialin.speedway42.dip223.dokom.de ([195.138.42.223] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19PSjY-0005XT-00 for guile-devel@gnu.org; Mon, 09 Jun 2003 21:55:12 +0200 Received: (qmail 25555 invoked by uid 1000); 9 Jun 2003 19:53:56 -0000 To: Bruce Korb References: <3ECFDA48.309D0F5@veritas.com> <87el2dlg9s.fsf@zagadka.ping.de> <3EDA643E.2215A945@veritas.com> From: Marius Vollmer Date: 09 Jun 2003 21:53:56 +0200 In-Reply-To: <3EDA643E.2215A945@veritas.com> Message-ID: <87he6z9gdn.fsf@zagadka.ping.de> Lines: 56 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile development cc: Bruce Korb Subject: Re: [PATCH] for strports.c: scm_c_eval_string_from_file_line X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 09 Jun 2003 20:16:00 -0000 Bruce Korb writes: > Marius Vollmer wrote: > > > void > > scm_c_primitive_load_from_string (const char *str, > > const char *filename, int line) > > { > > SCM port, exp; > > > > port = scm_open_input_string (scm_str2string (str)); > > scm_set_port_file_name_x (port, scm_str2string (filename)); > > scm_set_port_line_x (port, scm_int2num (line)); > > > > while (!SCM_EOF_OBJECT_P (exp = scm_read (port))) > > scm_primitive_eval_x (exp); > > } > > > > I think this quite straightforward, no? > > No. Err, I mean, once you see how it is done. The manual can be improved, I'm sure. > [...] I also try to avoid gratuitous creations of > string SCM's since the file name is generally invariant. > You omitted returning the final value, which is important :-). As you see, there are quite some variants on this theme, and I think the above code is clean enough to allow for easy modification. There is no black magic in it. > It's easier to ignore if the caller doesn't want it. And, no, > I didn't find that the research required to do this was obvious. > In fact, there is no ``scm_set_port_file_name_x'' in 1.6.3, so > you must be talking 1.7 here. Oops, it is "scm_set_port_filename_x". > I'm still working with 1.4. Therefore, I must directly assign to > ``file_name''. I may as well assign the line number, too. One more reason to join the happy Guile 1.6 club... > I'd rather it was ready made so I can just #define my > ``ag_scm_c_eval_string_from_file_line'' into > ``scm_c_primitive_load_from_string''. You might tweak it a bit so a > NULL file pointer bypasses the scm_set_port_file_name_x call. I'd > also use "file_line" in the name, but that is your call. Given these minor variations, I suggest you just use the function from above. That way, you get exactly what you want. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 11 18:38:27 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QECH-0001BX-Bp for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 18:36:01 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QEB8-0000go-I5 for guile-devel@gnu.org; Wed, 11 Jun 2003 18:34:50 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QEAu-0000Vx-FE for guile-devel@gnu.org; Wed, 11 Jun 2003 18:34:37 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QEAA-0008Mk-PK for guile-devel@gnu.org; Wed, 11 Jun 2003 18:33:51 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BMXiYd019193 for ; Thu, 12 Jun 2003 08:33:45 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BMXiQg026602 for ; Thu, 12 Jun 2003 08:33:44 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BMXcYZ005594 for ; Thu, 12 Jun 2003 08:33:43 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QE9a-0000bk-00; Thu, 12 Jun 2003 08:33:14 +1000 To: guile-devel@gnu.org References: <3EBC71BF.B2264C7@veritas.com> <874r3t5o1f.fsf@zagadka.ping.de> <3EC6A6CA.94855664@veritas.com> <87of213tk0.fsf@zagadka.ping.de> <87ptmfx0i3.fsf@zip.com.au> <874r39prgm.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 08:33:13 +1000 In-Reply-To: <874r39prgm.fsf@zagadka.ping.de> (Marius Vollmer's message of "01 Jun 2003 20:45:13 +0200") Message-ID: <87r860nt1y.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: Re: How do I determine the argument type... X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 22:35:59 -0000 --=-=-= Marius Vollmer writes: > > Hmm, no, I prefer changing the docs. "size_t" is the right type, and > not many people seem to be affected by the int -> size_t change, so we > chould leave it at size_t. Not that it's much to do with me, but while I'm working on the docs I made this change. * gh.texi (Scheme to C): In gh_scm2newstr, lenp is size_t* not int*. This changed in guile 1.6, the docs weren't updated. Dunno if the manual itself needs a compatibility note. If no-one else has tripped over it and the interface itself is considered obsolete then hardly worth worrying. --=-=-= Content-Disposition: attachment; filename=gh.texi.gh_scm2newstr.diff --- gh.texi.~1.6.~ 2003-04-05 16:47:18.000000000 +1000 +++ gh.texi 2003-06-10 16:47:40.000000000 +1000 @@ -433,7 +433,7 @@ These routines convert the Scheme object to the given C type. @end deftypefun -@deftypefun char *gh_scm2newstr (SCM @var{str}, int *@var{lenp}) +@deftypefun char *gh_scm2newstr (SCM @var{str}, size_t *@var{lenp}) Given a Scheme string @var{str}, return a pointer to a new copy of its contents, followed by a null byte. If @var{lenp} is non-null, set @code{*@var{lenp}} to the string's length. --=-=-=-- From MAILER-DAEMON Wed Jun 11 18:53:24 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QES6-0008Qr-O9 for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 18:52:22 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QES2-0008M5-Fp for guile-devel@gnu.org; Wed, 11 Jun 2003 18:52:18 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QERK-0007sh-Q0 for guile-devel@gnu.org; Wed, 11 Jun 2003 18:51:35 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QER7-0007fl-Hd for guile-devel@gnu.org; Wed, 11 Jun 2003 18:51:21 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BMpIYd025193 for ; Thu, 12 Jun 2003 08:51:18 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BMpIQg001506 for ; Thu, 12 Jun 2003 08:51:18 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BMpHYZ026525 for ; Thu, 12 Jun 2003 08:51:17 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QER0-0000gH-00; Thu, 12 Jun 2003 08:51:14 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 08:51:13 +1000 Message-ID: <87k7bsns7y.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: doco deftypefun braces X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 22:52:21 -0000 FYI, more indexing fixups, * scheme-memory.texi (Memory Blocks): Use {} around types for @deftypefn, for correct name in indexes. * scheme-utility.texi (C Hooks): Ditto. * gh.texi (Scheme to C): Ditto. From MAILER-DAEMON Wed Jun 11 19:01:07 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QEYm-00057v-10 for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 18:59:16 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QEYj-00052e-Du for guile-devel@gnu.org; Wed, 11 Jun 2003 18:59:13 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QEYU-0004rg-Bu for guile-devel@gnu.org; Wed, 11 Jun 2003 18:58:59 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QEYM-0004dp-Ap for guile-devel@gnu.org; Wed, 11 Jun 2003 18:58:50 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BMwmYd027972 for ; Thu, 12 Jun 2003 08:58:48 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BMwmQg003659 for ; Thu, 12 Jun 2003 08:58:48 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BMwlYZ006701 for ; Thu, 12 Jun 2003 08:58:47 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QEYG-0000iC-00; Thu, 12 Jun 2003 08:58:44 +1000 To: guile-devel@gnu.org References: <87znku26ba.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 08:58:43 +1000 In-Reply-To: <87znku26ba.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 07 Jun 2003 08:24:09 +1000") Message-ID: <87fzmgnrvg.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco primitive numerics C funcs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 22:59:14 -0000 I wrote: > > * scheme-data.texi (Primitive Numerics): Add atan2, pow, asinh, acosh > and atanh to scheme<->C table. Note asinh, acosh and atanh are C99, > and scm_asinh, scm_acosh and scm_atanh are equivalents. Cross ref > glibc "Mathematics". Reword this end part for clarity. I made this change. From MAILER-DAEMON Wed Jun 11 19:08:46 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QEhU-0004I0-AM for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 19:08:16 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QEhO-00046l-V0 for guile-devel@gnu.org; Wed, 11 Jun 2003 19:08:10 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QEhJ-0003wq-3C for guile-devel@gnu.org; Wed, 11 Jun 2003 19:08:05 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QEhG-0003kp-Sy for guile-devel@gnu.org; Wed, 11 Jun 2003 19:08:03 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BN80Yd031697 for ; Thu, 12 Jun 2003 09:08:00 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BN7xQg006684 for ; Thu, 12 Jun 2003 09:07:59 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BN7wYZ020262 for ; Thu, 12 Jun 2003 09:07:58 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QEh8-0000iz-00; Thu, 12 Jun 2003 09:07:54 +1000 To: guile-devel@gnu.org References: <87wugjhowm.fsf@zip.com.au> <87wugjqx1g.fsf@raven.i.defaultvalue.org> <87r86rqa6m.fsf@raven.i.defaultvalue.org> <87vfw1i1jq.fsf@zip.com.au> <87add5mh91.fsf@zip.com.au> <87isrpjx0a.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 09:07:54 +1000 Message-ID: <877k7snrg5.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco scm_remember_upto_1 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 23:08:14 -0000 Marius Vollmer writes: > > But this is not the case, a GC will only run when all threads are > in a safe place and have been stopped. Right, yep. I reworded it in a more direct sense as follows, dropping the "it might be thought" business, which was only really me getting wrong ideas. In a multi-threaded program, the rule is the same. As far as a given thread is concerned, a garbage collect still only occurs within a memory allocation function, not at an arbitrary time. (Guile waits for all threads to reach a memory function, and holds them there while the collector runs.) > But when in doubt, be > conservative: include the call to scm_remember_upto_here_1 when > you are not sure that it is safe to leave it out. I think I'd rather see something unambiguous said about when a remember must be used, instead of talking about being unsure. I tried to reword a little to emphasise it's memory activity which provokes a gc. > A call to > scm_remember_1 will cost at most as much as a call to an empty > function. Or less, if the asm block approach is right, or if storing to a global "volatile" variable would similarly be right. :-) > Is that important? A note that says that the non-varargs functions > might be more efficient should suffice, no? I'm only thinking to encourage the best way. I suppose the cost is always going to be small compared to real work done, it's just a case of not wanting to go along an inferior path. In any event, I checked in the new section. From MAILER-DAEMON Wed Jun 11 19:17:20 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QEom-0004nL-LH for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 19:15:48 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QEoS-00049Z-Tw for guile-devel@gnu.org; Wed, 11 Jun 2003 19:15:28 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QEoH-0003b8-Nh for guile-devel@gnu.org; Wed, 11 Jun 2003 19:15:22 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QEoF-0003SM-DN for guile-devel@gnu.org; Wed, 11 Jun 2003 19:15:15 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BNFDYd002476 for ; Thu, 12 Jun 2003 09:15:13 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BNFDQg009202 for ; Thu, 12 Jun 2003 09:15:13 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BNFCYZ001949 for ; Thu, 12 Jun 2003 09:15:12 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QEo9-0000jq-00; Thu, 12 Jun 2003 09:15:09 +1000 To: guile-devel@gnu.org References: <877k7wgrbe.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 09:15:08 +1000 In-Reply-To: <877k7wgrbe.fsf@zip.com.au> (Kevin Ryde's message of "Mon, 09 Jun 2003 08:03:33 +1000") Message-ID: <873cignr43.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 23:15:45 -0000 I wrote: > > * posix.c (s_scm_putenv): Free temporary ptr in mingw unset. In absense of violent objections, I made this change. From MAILER-DAEMON Wed Jun 11 19:43:47 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QFFh-0001w1-PR for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 19:43:37 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QFFX-0001S0-K7 for guile-devel@gnu.org; Wed, 11 Jun 2003 19:43:27 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QFFI-0000u4-Mc for guile-devel@gnu.org; Wed, 11 Jun 2003 19:43:13 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QFFB-0000ZH-0J for guile-devel@gnu.org; Wed, 11 Jun 2003 19:43:05 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BNgvYd016065 for ; Thu, 12 Jun 2003 09:43:02 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BNgvQg020393 for ; Thu, 12 Jun 2003 09:42:57 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BNgrYZ020730 for ; Thu, 12 Jun 2003 09:42:55 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QFEs-0003Zm-00; Thu, 12 Jun 2003 09:42:46 +1000 To: guile-devel@gnu.org References: <87smqwugup.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 09:42:45 +1000 In-Reply-To: <87smqwugup.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 31 May 2003 09:58:38 +1000") Message-ID: <87r860mb9m.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 23:43:36 -0000 --=-=-= I wrote: > > Actually, I see that's a standard feature of putenv supposedly. What > systems is it not? I see freebsd for a start. I added a comment, --=-=-= Content-Disposition: attachment; filename=posix.c.unset-comment.diff --- posix.c.~1.116.~ 2003-06-12 09:24:20.000000000 +1000 +++ posix.c 2003-06-12 09:41:29.000000000 +1000 @@ -1166,8 +1166,9 @@ { #ifdef HAVE_UNSETENV /* No '=' in argument means we should remove the variable from - the environment. Not all putenvs understand this. To be - safe, we do it explicitely using unsetenv. */ + the environment. Not all putenvs understand this (for instance + FreeBSD 4.8 doesn't). To be safe, we do it explicitely using + unsetenv. */ unsetenv (SCM_STRING_CHARS (str)); #else /* On e.g. Win32 hosts putenv() called with 'name=' removes the --=-=-=-- From MAILER-DAEMON Wed Jun 11 19:55:43 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QFQT-0007pc-8w for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 19:54:45 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QFQK-0007WL-RZ for guile-devel@gnu.org; Wed, 11 Jun 2003 19:54:36 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QFQB-0007B9-Lj for guile-devel@gnu.org; Wed, 11 Jun 2003 19:54:28 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QFQA-00074Z-0y for guile-devel@gnu.org; Wed, 11 Jun 2003 19:54:26 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BNsMYd021963; Thu, 12 Jun 2003 09:54:24 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BNsMQg025312; Thu, 12 Jun 2003 09:54:22 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BNsAYZ011409; Thu, 12 Jun 2003 09:54:21 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QFPr-00043r-00; Thu, 12 Jun 2003 09:54:07 +1000 To: stefan References: From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 09:54:05 +1000 In-Reply-To: (stefan@lkcc.org's message of "Fri, 30 May 2003 11:27:37 +0200 (CEST)") Message-ID: <87k7bsmaqq.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 11 Jun 2003 23:54:43 -0000 stefan writes: > > I just added a check for unsetenv() in the configure script and used it in > posix.c appropiately for mingw32 hosts. Which means that a > putenv("name="); would remove the environment variable 'name'. I guess this means it's not possible to use putenv("name=") to set name to an empty string. I'm pretty sure it's valid to do so on other systems. On wine, which might not be the same as a real mingw, setting "name= " and then changing that space to a \0 does the trick. Bit nasty to go changing putenvs strings like that, but unless there's a setenv or some function hiding then there might be no choice. Eg, (untested), /* If str is "FOO=", ie. attempting to set an empty string, then we need to see if it's been successful. On MINGW, "FOO=" means remove FOO from the environment. As a workaround, we set "FOO= ", ie. a space, and then modify the string returned by getenv. It's not enough just to modify the string we set, because MINGW putenv copies it. */ if (ptr[SCM_STRING_LENGTH(str)-1] == '=') { SCM name = scm_substring (str, SCM_MAKINUM (0), SCM_MAKINUM (SCM_STRING_LENGTH (str) - 1)); if (getenv (SCM_STRING_CHARS (name)) == NULL) { char *alt = scm_malloc (SCM_STRING_LENGTH (str) + 2); memcpy (alt, SCM_STRING_CHARS (str), SCM_STRING_LENGTH(str)); alt[SCM_STRING_LENGTH(str)] = ' '; alt[SCM_STRING_LENGTH(str)+1] = '\0'; rv = putenv (alt); if (rv < 0) SCM_SYSERROR; free (ptr); /* don't need the old string we gave to putenv */ alt = getenv (SCM_STRING_CHARS (name)); alt[SCM_STRING_LENGTH(str)] = '\0'; } } From MAILER-DAEMON Wed Jun 11 20:59:17 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QGPP-0003QO-Ej for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 20:57:43 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QGPE-0003Gu-Ue for guile-devel@gnu.org; Wed, 11 Jun 2003 20:57:32 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QGOY-0002JR-VT for guile-devel@gnu.org; Wed, 11 Jun 2003 20:57:01 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QGOR-0001qG-Gi for guile-devel@gnu.org; Wed, 11 Jun 2003 20:56:43 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5C0ueYd018803 for ; Thu, 12 Jun 2003 10:56:40 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5C0ueQg019297 for ; Thu, 12 Jun 2003 10:56:40 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5C0ubYZ011205 for ; Thu, 12 Jun 2003 10:56:38 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QGOF-0000Et-00; Thu, 12 Jun 2003 10:56:31 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 10:56:29 +1000 Message-ID: <877k7sm7uq.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco ports verbiage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 00:57:41 -0000 --=-=-= This is in the interests of reducing duplication. For with- and call-with- I found it a bit hard to see quite what was going on with five rather similar chunks of text. * scheme-io.texi (File Ports): Describe call-with-input-file and call-with-output-file together. Describe with-input-from-file, with-output-to-file and with-error-to-file together. (Closing): Describe close-input-port and close-output-port together, tweak the wording slightly. The words are slightly rearranged in support of this, but what's specified is not changed. - Scheme Procedure: call-with-input-file filename proc - Scheme Procedure: call-with-output-file filename proc Open FILENAME for input or output, and call `(PROC port)' with the resulting port. Return the value returned by PROC. For input, FILENAME must exist. For output, if FILENAME already exists the behaviour is unspecified. In both cases if FILENAME cannot be opened an error is signalled. When PROC returns, the port is closed. If PROC does not return (eg. if it throws an error), then the port might not be closed automatically, though it will be garbage collected in the usual way if not otherwise referenced. - Scheme Procedure: with-input-from-file filename thunk - Scheme Procedure: with-output-to-file filename thunk - Scheme Procedure: with-error-to-file filename thunk Open FILENAME and call `(THUNK)' with the port setup as respectively the `current-input-port', `current-output-port', or `current-error-port'. Return the value returned by THUNK. For input, FILENAME must exist. For output and error output, if FILENAME already exists the behaviour is unspecified. In all cases if FILENAME cannot be opened, an error is signalled. When THUNK returns, the port is closed and the previous setting of the respective current port is restored. If THUNK does not return (eg. if it throws an error), then what happens to the ports is unspecified. - Scheme Procedure: close-input-port port - Scheme Procedure: close-output-port port - C Function: scm_close_input_port (port) - C Function: scm_close_output_port (port) Close the specified input or output PORT. An exception may be raised if an error occurs while closing. If PORT is already closed, nothing is done. The return value is unspecified. See also *Note close: Ports and File Descriptors, for a procedure which can close file descriptors. --=-=-= Content-Disposition: attachment; filename=scheme-io.texi.ports.diff --- scheme-io.texi.~1.12.~ 2003-06-01 10:18:51.000000000 +1000 +++ scheme-io.texi 2003-06-12 10:45:48.000000000 +1000 @@ -301,23 +301,15 @@ descriptors. @end deffn -@rnindex close-input-port @deffn {Scheme Procedure} close-input-port port +@deffnx {Scheme Procedure} close-output-port port @deffnx {C Function} scm_close_input_port (port) -Close the specified input port object. The routine has no effect if -the file has already been closed. An exception may be raised if an -error occurs. The value returned is unspecified. - -See also @ref{Ports and File Descriptors, close}, for a procedure -which can close file descriptors. -@end deffn - -@rnindex close-output-port -@deffn {Scheme Procedure} close-output-port port @deffnx {C Function} scm_close_output_port (port) -Close the specified output port object. The routine has no effect if -the file has already been closed. An exception may be raised if an -error occurs. The value returned is unspecified. +@rnindex close-input-port +@rnindex close-output-port +Close the specified input or output @var{port}. An exception may be +raised if an error occurs while closing. If @var{port} is already +closed, nothing is done. The return value is unspecified. See also @ref{Ports and File Descriptors, close}, for a procedure which can close file descriptors. @@ -709,68 +701,42 @@ @end smalllisp @end deffn +@deffn {Scheme Procedure} call-with-input-file filename proc +@deffnx {Scheme Procedure} call-with-output-file filename proc @rnindex call-with-input-file -@deffn {Scheme Procedure} call-with-input-file file proc -@var{proc} should be a procedure of one argument, and @var{file} should -be a string naming a file. The file must already exist. These -procedures call @var{proc} with one argument: the port obtained by -opening the named file for input or output. If the file cannot be -opened, an error is signalled. If the procedure returns, then the port -is closed automatically and the value yielded by the procedure is -returned. If the procedure does not return, then the port will not be -closed automatically unless it is possible to prove that the port will -never again be used for a read or write operation. -@end deffn - @rnindex call-with-output-file -@deffn {Scheme Procedure} call-with-output-file file proc -@var{proc} should be a procedure of one argument, and @var{file} should -be a string naming a file. The behaviour is unspecified if the file -already exists. These procedures call @var{proc} with one argument: the -port obtained by opening the named file for input or output. If the -file cannot be opened, an error is signalled. If the procedure returns, -then the port is closed automatically and the value yielded by the -procedure is returned. If the procedure does not return, then the port -will not be closed automatically unless it is possible to prove that the -port will never again be used for a read or write operation. -@end deffn - +Open @var{filename} for input or output, and call @code{(@var{proc} +port)} with the resulting port. Return the value returned by +@var{proc}. + +For input, @var{filename} must exist. For output, if @var{filename} +already exists the behaviour is unspecified. In both cases if +@var{filename} cannot be opened an error is signalled. + +When @var{proc} returns, the port is closed. If @var{proc} does not +return (eg.@: if it throws an error), then the port may not be closed +automatically, though it will be garbage collected in the usual way if +not otherwise referenced. +@end deffn + +@deffn {Scheme Procedure} with-input-from-file filename thunk +@deffnx {Scheme Procedure} with-output-to-file filename thunk +@deffnx {Scheme Procedure} with-error-to-file filename thunk @rnindex with-input-from-file -@deffn {Scheme Procedure} with-input-from-file file thunk -@var{thunk} must be a procedure of no arguments, and @var{file} must be -a string naming a file. The file must already exist. The file is opened -for input, an input port connected to it is made the default value -returned by @code{current-input-port}, and the @var{thunk} is called -with no arguments. When the @var{thunk} returns, the port is closed and -the previous default is restored. Returns the value yielded by -@var{thunk}. If an escape procedure is used to escape from the -continuation of these procedures, their behavior is implementation -dependent. -@end deffn - @rnindex with-output-to-file -@deffn {Scheme Procedure} with-output-to-file file thunk -@var{thunk} must be a procedure of no arguments, and @var{file} must be -a string naming a file. The effect is unspecified if the file already -exists. The file is opened for output, an output port connected to it -is made the default value returned by @code{current-output-port}, and -the @var{thunk} is called with no arguments. When the @var{thunk} -returns, the port is closed and the previous default is restored. -Returns the value yielded by @var{thunk}. If an escape procedure is -used to escape from the continuation of these procedures, their behavior -is implementation dependent. -@end deffn - -@deffn {Scheme Procedure} with-error-to-file file thunk -@var{thunk} must be a procedure of no arguments, and @var{file} must be -a string naming a file. The effect is unspecified if the file already -exists. The file is opened for output, an output port connected to it -is made the default value returned by @code{current-error-port}, and the -@var{thunk} is called with no arguments. When the @var{thunk} returns, -the port is closed and the previous default is restored. Returns the -value yielded by @var{thunk}. If an escape procedure is used to escape -from the continuation of these procedures, their behavior is -implementation dependent. +Open @var{filename} and call @code{(@var{thunk})} with the port setup +as respectively the @code{current-input-port}, +@code{current-output-port}, or @code{current-error-port}. Return the +value returned by @var{thunk}. + +For input, @var{filename} must exist. For output and error output, if +@var{filename} already exists the behaviour is unspecified. In all +cases if @var{filename} cannot be opened, an error is signalled. + +When @var{thunk} returns, the port is closed and the previous setting +of the respective current port is restored. If @var{thunk} does not +return (eg.@: if it throws an error), then what happens to the ports +is unspecified. @end deffn @deffn {Scheme Procedure} port-mode port --=-=-=-- From MAILER-DAEMON Wed Jun 11 21:09:31 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QGao-0006Ex-O7 for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 21:09:30 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QGam-0006An-5E for guile-devel@gnu.org; Wed, 11 Jun 2003 21:09:28 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QGak-00065n-6y for guile-devel@gnu.org; Wed, 11 Jun 2003 21:09:27 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QGaj-00061n-Ax for guile-devel@gnu.org; Wed, 11 Jun 2003 21:09:25 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5C19NYd024684 for ; Thu, 12 Jun 2003 11:09:23 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5C19NQg023833 for ; Thu, 12 Jun 2003 11:09:23 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5C19KYZ005827 for ; Thu, 12 Jun 2003 11:09:21 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QGaW-0001W2-00; Thu, 12 Jun 2003 11:09:12 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 11:09:11 +1000 Message-ID: <873cigm79k.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: c99 number funcs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 01:09:28 -0000 --=-=-= This is a small change to make use of c99 math functions when available, for instance in recent glibc. There shouldn't be much difference, though there's probably a good chance of getting higher accuracy or range from the library asinh etc than from an equivalent expression. Removing the private isfinite is a good thing on its own, don't want to have problems on a c99 system. * configure.in (AC_CHECK_FUNCS): Add asinh, acosh, atanh, round, trunc. * numbers.c (_GNU_SOURCE): #define, to get C99 things. (scm_asinh, scm_acosh, scm_atanh, scm_truncate, scm_round, $asinh, $acosh, $atanh, truncate, round): Use C library asinh, acosh, atanh, trunc and round, when available. (scm_inexact_to_exact): Expand isfinite to its definition !isinf. (isfinite): Remove, conflicts with C99 isfinite(). * tests/numbers.test (trunc, round, asinh, acosh, atanh): Add some tests. --=-=-= Content-Disposition: attachment; filename=configure.in.c99.diff --- configure.in.~1.219.~ 2003-05-31 09:42:52.000000000 +1000 +++ configure.in 2003-06-12 11:03:09.000000000 +1000 @@ -753,7 +753,10 @@ AC_CHECK_HEADERS(floatingpoint.h ieeefp.h nan.h) -AC_CHECK_FUNCS(finite isinf isnan copysign) +# asinh, acosh, atanh, round and trunc (all in -lm) are only C99 standard +# and older systems generally don't have them. +# +AC_CHECK_FUNCS(asinh acosh atanh copysign finite isinf isnan round trunc) # When testing for the presence of alloca, we need to add alloca.o # explicitly to LIBOBJS to make sure that it is translated to --=-=-= Content-Disposition: attachment; filename=numbers.c.c99.diff --- numbers.c.~1.191.~ 2003-06-05 01:56:18.000000000 +1000 +++ numbers.c 2003-06-12 10:59:40.000000000 +1000 @@ -39,6 +39,9 @@ */ +/* tell glibc (2.3) to give prototypes for C99 trunc() and round() */ +#define _GNU_SOURCE + #if HAVE_CONFIG_H # include #endif @@ -263,8 +266,6 @@ #endif } -#define isfinite(x) (! xisinf (x)) - SCM_DEFINE (scm_inf_p, "inf?", 1, 0, 0, (SCM n), "Return @code{#t} if @var{n} is infinite, @code{#f}\n" @@ -3643,61 +3644,87 @@ } #undef FUNC_NAME -SCM_GPROC1 (s_asinh, "$asinh", scm_tc7_dsubr, (SCM (*)()) scm_asinh, g_asinh); -/* "Return the inverse hyperbolic sine of @var{x}." - */ + double scm_asinh (double x) { +#if HAVE_ASINH + return asinh (x); +#else +#define asinh scm_asinh return log (x + sqrt (x * x + 1)); +#endif } +SCM_GPROC1 (s_asinh, "$asinh", scm_tc7_dsubr, (SCM (*)()) asinh, g_asinh); +/* "Return the inverse hyperbolic sine of @var{x}." + */ -SCM_GPROC1 (s_acosh, "$acosh", scm_tc7_dsubr, (SCM (*)()) scm_acosh, g_acosh); -/* "Return the inverse hyperbolic cosine of @var{x}." - */ double scm_acosh (double x) { +#if HAVE_ACOSH + return acosh (x); +#else +#define acosh scm_acosh return log (x + sqrt (x * x - 1)); +#endif } +SCM_GPROC1 (s_acosh, "$acosh", scm_tc7_dsubr, (SCM (*)()) acosh, g_acosh); +/* "Return the inverse hyperbolic cosine of @var{x}." + */ -SCM_GPROC1 (s_atanh, "$atanh", scm_tc7_dsubr, (SCM (*)()) scm_atanh, g_atanh); -/* "Return the inverse hyperbolic tangent of @var{x}." - */ double scm_atanh (double x) { +#if HAVE_ATANH + return atanh (x); +#else +#define atanh scm_atanh return 0.5 * log ((1 + x) / (1 - x)); +#endif } +SCM_GPROC1 (s_atanh, "$atanh", scm_tc7_dsubr, (SCM (*)()) atanh, g_atanh); +/* "Return the inverse hyperbolic tangent of @var{x}." + */ -SCM_GPROC1 (s_truncate, "truncate", scm_tc7_dsubr, (SCM (*)()) scm_truncate, g_truncate); -/* "Round the inexact number @var{x} towards zero." - */ double scm_truncate (double x) { +#if HAVE_TRUNC + return trunc (x); +#else +#define trunc scm_truncate if (x < 0.0) return -floor (-x); return floor (x); +#endif } +SCM_GPROC1 (s_truncate, "truncate", scm_tc7_dsubr, (SCM (*)()) trunc, g_truncate); +/* "Round the inexact number @var{x} towards zero." + */ -SCM_GPROC1 (s_round, "round", scm_tc7_dsubr, (SCM (*)()) scm_round, g_round); -/* "Round the inexact number @var{x}. If @var{x} is halfway between two\n" - * "numbers, round towards even." - */ double scm_round (double x) { +#if HAVE_ROUND + return round (x); +#else +#define round scm_round double plus_half = x + 0.5; double result = floor (plus_half); /* Adjust so that the scm_round is towards even. */ return (plus_half == result && plus_half / 2 != floor (plus_half / 2)) ? result - 1 : result; +#endif } +SCM_GPROC1 (s_round, "round", scm_tc7_dsubr, (SCM (*)()) scm_round, g_round); +/* "Round the inexact number @var{x}. If @var{x} is halfway between two\n" + * "numbers, round towards even." + */ SCM_GPROC1 (s_i_floor, "floor", scm_tc7_dsubr, (SCM (*)()) floor, g_i_floor); @@ -3973,7 +4000,7 @@ long lu = (long) u; if (SCM_FIXABLE (lu)) { return SCM_MAKINUM (lu); - } else if (isfinite (u) && !xisnan (u)) { + } else if (!xisinf (u) && !xisnan (u)) { return scm_i_dbl2big (u); } else { scm_num_overflow (s_scm_inexact_to_exact); --=-=-= Content-Disposition: attachment; filename=numbers.test.c99.diff --- numbers.test.~1.25.~ 2003-06-05 02:10:17.000000000 +1000 +++ numbers.test 2003-06-08 17:18:43.000000000 +1000 @@ -1863,10 +1863,30 @@ ;;; truncate ;;; +(with-test-prefix "trunc" + (pass-if "0.5" + (= 0 (trunc 0.5))) + (pass-if "1.5" + (= 2 (trunc 1.5))) + (pass-if "-0.5" + (= 0 (trunc -1.5))) + (pass-if "-1.5" + (= -2 (trunc -1.5)))) + ;;; ;;; round ;;; +(with-test-prefix "round" + (pass-if "0.5" + (= 1 (round 0.5))) + (pass-if "1.5" + (= 2 (round 1.5))) + (pass-if "-0.5" + (= -2 (round -1.5))) + (pass-if "-1.5" + (= -1 (round -1.5)))) + ;;; ;;; exact->inexact ;;; @@ -1890,6 +1910,27 @@ (pass-if "(= 1 (expt 0.0 0.0))" (= 1 (expt 0.0 0.0)))) ;;; +;;; asinh +;;; + +(with-test-prefix "asinh" + (pass-if "0" (= 0 (asinh 0)))) + +;;; +;;; acosh +;;; + +(with-test-prefix "acosh" + (pass-if "1" (= 0 (acosh 1)))) + +;;; +;;; atanh +;;; + +(with-test-prefix "atanh" + (pass-if "0" (= 0 (atanh 0)))) + +;;; ;;; make-rectangular ;;; --=-=-=-- From MAILER-DAEMON Wed Jun 11 21:29:48 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QGuS-0001QG-5L for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 21:29:48 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QGuP-0001Q0-JY for guile-devel@gnu.org; Wed, 11 Jun 2003 21:29:45 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QGuO-0001Ph-81 for guile-devel@gnu.org; Wed, 11 Jun 2003 21:29:44 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QGuN-0001JZ-BV for guile-devel@gnu.org; Wed, 11 Jun 2003 21:29:43 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5C1TeYd002019 for ; Thu, 12 Jun 2003 11:29:40 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5C1TeQg001932 for ; Thu, 12 Jun 2003 11:29:40 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5C1TcYZ015827 for ; Thu, 12 Jun 2003 11:29:39 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QGuE-0006QT-00; Thu, 12 Jun 2003 11:29:34 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 11:29:33 +1000 Message-ID: <87wufskrr6.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco remembering versus SCM_STRING_CHARS X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 01:29:46 -0000 --=-=-= Is it true the the scm_remember_upto_here_1 stuff applies also to SCM_STRING_CHARS and friends? * data-rep.texi (Vector Data): For SCM_VECTOR_BASE, SCM_STRING_CHARS and SCM_SYMBOL_CHARS, cross reference "Remembering During Operations". Text: Note that `SCM_VECTOR_BASE', `SCM_STRING_CHARS' and `SCM_SYMBOL_CHARS' return pointers to data within the respective object. Care must be taken that the object is not garbage collected while that data is still being accessed. This is the same as for a smob, *Note Remembering During Operations::. --=-=-= Content-Disposition: attachment; filename=data-rep.texi.remembering-arrays.diff --- data-rep.texi.~1.11.~ 2003-06-12 09:07:53.000000000 +1000 +++ data-rep.texi 2003-06-12 11:26:01.000000000 +1000 @@ -875,6 +875,12 @@ There are also a few magic values stuffed into memory before a symbol's characters, but you don't want to know about those. What cruft! +Note that @code{SCM_VECTOR_BASE}, @code{SCM_STRING_CHARS} and +@code{SCM_SYMBOL_CHARS} return pointers to data within the respective +object. Care must be taken that the object is not garbage collected +while that data is still being accessed. This is the same as for a +smob, @xref{Remembering During Operations}. + @node Procedures @subsubsection Procedures --=-=-=-- From MAILER-DAEMON Wed Jun 11 21:56:26 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QHJ4-00060N-Qf for mharc-guile-devel@gnu.org; Wed, 11 Jun 2003 21:55:14 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QHIy-0005rj-HU for guile-devel@gnu.org; Wed, 11 Jun 2003 21:55:08 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QHIm-0005aw-Jb for guile-devel@gnu.org; Wed, 11 Jun 2003 21:54:57 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QHIU-00056z-0m for guile-devel@gnu.org; Wed, 11 Jun 2003 21:54:38 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5C1sZYd013810 for ; Thu, 12 Jun 2003 11:54:35 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5C1sZQg011432 for ; Thu, 12 Jun 2003 11:54:35 +1000 (EST) Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5C1sXYZ005187 for ; Thu, 12 Jun 2003 11:54:34 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QHIJ-0002z1-00; Thu, 12 Jun 2003 11:54:27 +1000 To: guile-devel@gnu.org References: <87y90cfcjy.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 12 Jun 2003 11:54:26 +1000 In-Reply-To: (Mikael Djurfeldt's message of "Mon, 09 Jun 2003 10:35:50 +0200") Message-ID: <87k7bskqlp.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: parallel with no exprs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 01:55:13 -0000 Mikael Djurfeldt writes: > > (use-modules (ice-9 threads)) > (call-with-values > (lambda () > (display "hello\n") > (parallel)) > (lambda () > (display "hi\n"))) I get hello ERROR: Wrong number of arguments to # I'd seen (parallel) expanding to (begin), which was what made me think it was the (begin) that might not be right, since the following gives the same error. (call-with-values (lambda () (display "hi\n") (begin)) (lambda () (display "bye\n"))) > (lambda () (parallel)) correctly yields an error > message since that is a lambda with no expressions in the body. Ah, somehow I missed that (lambda () (begin)) is itself an empty body. Bit subtle that, since of course it doesn't look empty :-). From MAILER-DAEMON Thu Jun 12 01:06:09 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QKGn-0008Qd-6I for mharc-guile-devel@gnu.org; Thu, 12 Jun 2003 01:05:05 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QKGe-0008I9-Ni for guile-devel@gnu.org; Thu, 12 Jun 2003 01:04:56 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QKGN-0007eJ-Hb for guile-devel@gnu.org; Thu, 12 Jun 2003 01:04:39 -0400 Received: from obh.snafu.de ([213.73.92.34]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QKGC-0007Us-65 for guile-devel@gnu.org; Thu, 12 Jun 2003 01:04:28 -0400 Received: from p-164-091.zrz.tu-berlin.de ([130.149.164.91] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19QKG7-0009BL-00; Thu, 12 Jun 2003 07:04:24 +0200 Received: from localhost ([127.0.0.1] ident=ela) by bono with esmtp (Exim 3.36 #1) id 19QKDP-00007T-00; Thu, 12 Jun 2003 07:01:35 +0200 Date: Thu, 12 Jun 2003 07:01:35 +0200 (CEST) From: stefan X-X-Sender: stefan@bono.reversers.net To: Kevin Ryde In-Reply-To: <877k7wgrbe.fsf@zip.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 05:05:03 -0000 On Mon, 9 Jun 2003, Kevin Ryde wrote: > > I just added a check for unsetenv() in the configure script and used it in > > posix.c appropiately for mingw32 hosts. Which means that a > > putenv("name="); would remove the environment variable 'name'. > > I think there's a small memory leak there, viz > > (while #t (putenv "FOO")) > > Perhaps > > * posix.c (s_scm_putenv): Free temporary ptr in mingw unset. > > Of course the main putenv bit also leaks, but that's another story :-). I have applied the patch locally (exept the unused int e;) and will test the proposal you mentioned in the last mail about setting the env string to empty. Cheers, stefan@lkcc.org From MAILER-DAEMON Thu Jun 12 05:30:48 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QOP6-0007Gh-5W for mharc-guile-devel@gnu.org; Thu, 12 Jun 2003 05:29:56 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QOOy-0007Cl-G5 for guile-devel@gnu.org; Thu, 12 Jun 2003 05:29:48 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QOOs-00070d-G9 for guile-devel@gnu.org; Thu, 12 Jun 2003 05:29:43 -0400 Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QOOh-0006XG-Nz for guile-devel@gnu.org; Thu, 12 Jun 2003 05:29:31 -0400 Received: from barbara.blakulla.net ([213.212.21.238] helo=witch) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 19QOOb-0002Zb-00; Thu, 12 Jun 2003 11:29:25 +0200 Received: from mdj by witch with local (Exim 3.35 #1 (Debian)) id 19QON1-000106-00; Thu, 12 Jun 2003 11:27:47 +0200 To: guile-devel@gnu.org References: <87y90cfcjy.fsf@zip.com.au> <87k7bskqlp.fsf@zip.com.au> From: Mikael Djurfeldt Date: Thu, 12 Jun 2003 11:27:46 +0200 In-Reply-To: <87k7bskqlp.fsf@zip.com.au> (Kevin Ryde's message of "Thu, 12 Jun 2003 11:54:26 +1000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Mikael Djurfeldt cc: djurfeldt@nada.kth.se Subject: Re: parallel with no exprs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: djurfeldt@nada.kth.se List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 09:29:49 -0000 Kevin Ryde writes: > Mikael Djurfeldt writes: >> >> (use-modules (ice-9 threads)) >> (call-with-values >> (lambda () >> (display "hello\n") >> (parallel)) >> (lambda () >> (display "hi\n"))) > > I get > > hello > ERROR: Wrong number of arguments to # Oops. The second lambda should have (x) as formal parameters. But this error is independent from the problem we are discussing. (parallel) correctly expands to (begin). In our implementation, (begin) evaluates to # which is 1 value, so the second lambda must take 1 argument. > I'd seen (parallel) expanding to (begin), which was what made me think > it was the (begin) that might not be right, since the following gives > the same error. > > (call-with-values > (lambda () > (display "hi\n") > (begin)) > (lambda () > (display "bye\n"))) > >> (lambda () (parallel)) correctly yields an error >> message since that is a lambda with no expressions in the body. > > Ah, somehow I missed that (lambda () (begin)) is itself an empty body. > Bit subtle that, since of course it doesn't look empty :-). :-) From MAILER-DAEMON Thu Jun 12 10:07:57 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QSjd-00055H-Lo for mharc-guile-devel@gnu.org; Thu, 12 Jun 2003 10:07:25 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QSjX-0004zB-S2 for guile-devel@gnu.org; Thu, 12 Jun 2003 10:07:19 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QSih-0004cv-1n for guile-devel@gnu.org; Thu, 12 Jun 2003 10:06:27 -0400 Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.20) id 19QShp-0004Vr-Gb for guile-devel@gnu.org; Thu, 12 Jun 2003 10:05:33 -0400 Received: (qmail 1449 invoked by uid 1000); 12 Jun 2003 14:04:18 -0000 To: guile-devel@gnu.org References: <87wufskrr6.fsf@zip.com.au> From: Marius Vollmer Date: 12 Jun 2003 16:04:18 +0200 In-Reply-To: <87wufskrr6.fsf@zip.com.au> Message-ID: <87of138k9p.fsf@zagadka.ping.de> Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco remembering versus SCM_STRING_CHARS X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 14:07:24 -0000 Kevin Ryde writes: > Is it true the the scm_remember_upto_here_1 stuff applies also to > SCM_STRING_CHARS and friends? Yes, that is true. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Thu Jun 12 10:13:02 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QSns-0007Gy-5u for mharc-guile-devel@gnu.org; Thu, 12 Jun 2003 10:11:48 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QSmt-0006nd-Mo for guile-devel@gnu.org; Thu, 12 Jun 2003 10:10:47 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QSk7-0005QW-0h for guile-devel@gnu.org; Thu, 12 Jun 2003 10:07:56 -0400 Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.20) id 19QSg5-0003V6-Hs for guile-devel@gnu.org; Thu, 12 Jun 2003 10:03:45 -0400 Received: (qmail 1257 invoked by uid 1000); 12 Jun 2003 14:02:29 -0000 To: guile-devel@gnu.org References: <877k7sm7uq.fsf@zip.com.au> From: Marius Vollmer Date: 12 Jun 2003 16:02:28 +0200 In-Reply-To: <877k7sm7uq.fsf@zip.com.au> Message-ID: <87smqf8kcr.fsf@zagadka.ping.de> Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco ports verbiage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 12 Jun 2003 14:11:46 -0000 Kevin Ryde writes: > For input, FILENAME must exist. For output, if FILENAME already > exists the behaviour is unspecified. What does Guile do when FILENAME already exists? We should document that. We can defer to "what the OS usually does when opening an existing file for writing." or more specifically "equivalent to fopen(FILENAME, "w")". > - Scheme Procedure: with-input-from-file filename thunk > - Scheme Procedure: with-output-to-file filename thunk > - Scheme Procedure: with-error-to-file filename thunk > > ... > > When THUNK returns, the port is closed and the previous setting of > the respective current port is restored. If THUNK does not return > (eg. if it throws an error), then what happens to the ports is > unspecified. I think we need to add that the respective current port is restored. The new port might not be closed, but the old port is restored as the current port. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Fri Jun 13 18:04:20 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Qwei-0006Za-1q for mharc-guile-devel@gnu.org; Fri, 13 Jun 2003 18:04:20 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Qwee-0006YN-Ub for guile-devel@gnu.org; Fri, 13 Jun 2003 18:04:16 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Qwdi-00069P-Uf for guile-devel@gnu.org; Fri, 13 Jun 2003 18:03:19 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Qwcr-0005vw-PL for guile-devel@gnu.org; Fri, 13 Jun 2003 18:02:26 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5DM2HYd023216 for ; Sat, 14 Jun 2003 08:02:18 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5DM2HQg015134 for ; Sat, 14 Jun 2003 08:02:17 +1000 (EST) Received: from localhost (ppp109.dyn228.pacific.net.au [203.143.228.109]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5DM2FYZ022615 for ; Sat, 14 Jun 2003 08:02:16 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19Qwcb-0000Yq-00; Sat, 14 Jun 2003 08:02:09 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Sat, 14 Jun 2003 08:02:08 +1000 Message-ID: <87u1atocv3.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: doco round X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 13 Jun 2003 22:04:17 -0000 --=-=-= Bit of a gremlin in the description of round, it says the same as truncate. * scheme-data.texi (Arithmetic): round is to nearest even. This would be for the 1.6 branch too I think, since it's contrary to the r5rs and the code. - Scheme Procedure: round x Round the inexact number X to the nearest integer. When exactly halfway between two integers, round to the even one. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=scheme-data.texi.round.diff --- scheme-data.texi.~1.32.~ 2003-06-12 08:57:01.000000000 +1000 +++ scheme-data.texi 2003-06-14 07:56:20.000000000 +1000 @@ -780,7 +780,8 @@ @c begin (texi-doc-string "guile" "round") @deffn {Scheme Procedure} round x -Round the inexact number @var{x} towards zero. +Round the inexact number @var{x} to the nearest integer. When exactly +halfway between two integers, round to the even one. @end deffn @c begin (texi-doc-string "guile" "floor") --=-=-=-- From MAILER-DAEMON Fri Jun 13 18:22:14 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Qww1-0001c4-T9 for mharc-guile-devel@gnu.org; Fri, 13 Jun 2003 18:22:13 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Qwvz-0001Zi-Oy for guile-devel@gnu.org; Fri, 13 Jun 2003 18:22:11 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Qwvy-0001Yt-69 for guile-devel@gnu.org; Fri, 13 Jun 2003 18:22:10 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Qwvx-0001YH-UF for guile-devel@gnu.org; Fri, 13 Jun 2003 18:22:10 -0400 Received: from dialin.speedway42.dip217.dokom.de ([195.138.42.217] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19Qww4-0005O5-00 for guile-devel@gnu.org; Sat, 14 Jun 2003 00:22:16 +0200 Received: (qmail 13891 invoked by uid 1000); 13 Jun 2003 22:20:52 -0000 To: guile-devel@gnu.org References: <87u1atocv3.fsf@zip.com.au> From: Marius Vollmer Date: 14 Jun 2003 00:20:52 +0200 In-Reply-To: <87u1atocv3.fsf@zip.com.au> Message-ID: <87llw57h6j.fsf@zagadka.ping.de> Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco round X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 13 Jun 2003 22:22:12 -0000 Kevin Ryde writes: > This would be for the 1.6 branch too I think, since it's contrary to > the r5rs and the code. Yes, please fix this in 1.6 as well. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Fri Jun 13 19:50:03 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QyIy-00028X-9X for mharc-guile-devel@gnu.org; Fri, 13 Jun 2003 19:50:00 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QyIk-0001pr-Pp for guile-devel@gnu.org; Fri, 13 Jun 2003 19:49:46 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QyI8-0000x5-En for guile-devel@gnu.org; Fri, 13 Jun 2003 19:49:09 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QyHO-0000Fl-Gc for guile-devel@gnu.org; Fri, 13 Jun 2003 19:48:22 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5DNmJYd011205 for ; Sat, 14 Jun 2003 09:48:19 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5DNmJQg028948 for ; Sat, 14 Jun 2003 09:48:19 +1000 (EST) Received: from localhost (ppp109.dyn228.pacific.net.au [203.143.228.109]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5DNmIYZ020835 for ; Sat, 14 Jun 2003 09:48:18 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QyHF-0003KI-00; Sat, 14 Jun 2003 09:48:13 +1000 To: guile-devel@gnu.org References: <87y90cfcjy.fsf@zip.com.au> <87k7bskqlp.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Sat, 14 Jun 2003 09:48:13 +1000 In-Reply-To: (Mikael Djurfeldt's message of "Thu, 12 Jun 2003 11:27:46 +0200") Message-ID: <87y9057d4y.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: parallel with no exprs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 13 Jun 2003 23:49:51 -0000 Mikael Djurfeldt writes: > > Oops. The second lambda should have (x) as formal parameters. > But this error is independent from the problem we are discussing. > (parallel) correctly expands to (begin). Are you sure you want it that way? I guess it'd be necessary to document that parallel of N forms returns N values except that 0 forms returns 1 unspecified value. Maybe 0 forms shouldn't be documented at all, could quietly ignore it as too degenerate. (I'm not especially worried one way or the other, I only arrived at it from looking to add to the manual.) > In our implementation, > (begin) evaluates to # which is 1 value, so the second > lambda must take 1 argument. Yes I thought it might be the unspecified literalism, or rather the literalism of unspecified :-). From MAILER-DAEMON Fri Jun 13 20:03:57 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QyVb-0000cz-5e for mharc-guile-devel@gnu.org; Fri, 13 Jun 2003 20:03:03 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QyVY-0000Yw-NF for guile-devel@gnu.org; Fri, 13 Jun 2003 20:03:00 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QyVX-0000YR-EH for guile-devel@gnu.org; Fri, 13 Jun 2003 20:02:59 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QyVW-0000Xu-Lv for guile-devel@gnu.org; Fri, 13 Jun 2003 20:02:58 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5E02vYd013962 for ; Sat, 14 Jun 2003 10:02:57 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5E02uQg000913 for ; Sat, 14 Jun 2003 10:02:57 +1000 (EST) Received: from localhost (ppp109.dyn228.pacific.net.au [203.143.228.109]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5E02tYZ000054 for ; Sat, 14 Jun 2003 10:02:56 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QyVP-0003Kb-00; Sat, 14 Jun 2003 10:02:51 +1000 To: guile-devel@gnu.org References: <877k7sm7uq.fsf@zip.com.au> <87smqf8kcr.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sat, 14 Jun 2003 10:02:51 +1000 In-Reply-To: <87smqf8kcr.fsf@zagadka.ping.de> (Marius Vollmer's message of "12 Jun 2003 16:02:28 +0200") Message-ID: <87u1at7cgk.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco ports verbiage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 14 Jun 2003 00:03:01 -0000 Marius Vollmer writes: > > What does Guile do when FILENAME already exists? We should document > that. I guess on a unix-like system it truncates the file and leaves you ready to put new contents. > We can defer to "what the OS usually does when opening an > existing file for writing." or more specifically "equivalent to > fopen(FILENAME, "w")". I could imagine fopen "w" on any system truncating, for general C/Unix compatibility, though I don't know for sure. Do you want to say fopen "w", or just a general "OS convention"? > I think we need to add that the respective current port is restored. Yep, beaut. From MAILER-DAEMON Fri Jun 13 20:33:40 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19QyzE-0004xO-AC for mharc-guile-devel@gnu.org; Fri, 13 Jun 2003 20:33:40 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QyzC-0004wG-4C for guile-devel@gnu.org; Fri, 13 Jun 2003 20:33:38 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QyzA-0004u8-GT for guile-devel@gnu.org; Fri, 13 Jun 2003 20:33:37 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Qyz9-0004st-SY for guile-devel@gnu.org; Fri, 13 Jun 2003 20:33:36 -0400 Received: from dialin.speedway42.dip217.dokom.de ([195.138.42.217] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19QyzH-0002wP-00 for guile-devel@gnu.org; Sat, 14 Jun 2003 02:33:43 +0200 Received: (qmail 27839 invoked by uid 1000); 14 Jun 2003 00:32:17 -0000 To: guile-devel@gnu.org References: <877k7sm7uq.fsf@zip.com.au> <87smqf8kcr.fsf@zagadka.ping.de> <87u1at7cgk.fsf@zip.com.au> From: Marius Vollmer Date: 14 Jun 2003 02:32:16 +0200 In-Reply-To: <87u1at7cgk.fsf@zip.com.au> Message-ID: <87k7bp5wj3.fsf@zagadka.ping.de> Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco ports verbiage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 14 Jun 2003 00:33:38 -0000 Kevin Ryde writes: > Marius Vollmer writes: > > > > What does Guile do when FILENAME already exists? We should document > > that. > > I guess on a unix-like system it truncates the file and leaves you > ready to put new contents. Yeah, when FILENAME is a regular file. What about saying that on POSIX systems, you get the behavior of open (FILENAME, O_WRONLY | O_CREAT | O_TRUNC, 0666) which is what the code eventually does. Or we could stay in Scheme and say it is equivalent to (open-file FILENAME "w") and make sure that open-file is documented properly. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sat Jun 14 01:42:03 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19R3nf-0003vW-Ek for mharc-guile-devel@gnu.org; Sat, 14 Jun 2003 01:42:03 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19R3nd-0003vE-I4 for guile-devel@gnu.org; Sat, 14 Jun 2003 01:42:01 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19R3nc-0003v3-Ah for guile-devel@gnu.org; Sat, 14 Jun 2003 01:42:00 -0400 Received: from obh.snafu.de ([213.73.92.34]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19R3nb-0003tH-TA for guile-devel@gnu.org; Sat, 14 Jun 2003 01:42:00 -0400 Received: from p-165-001.zrz.tu-berlin.de ([130.149.165.1] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19R3nZ-000Iol-00; Sat, 14 Jun 2003 07:41:58 +0200 Received: from localhost ([127.0.0.1] ident=ela) by bono with esmtp (Exim 3.36 #1) id 19R3iC-0000ao-00; Sat, 14 Jun 2003 07:36:25 +0200 Date: Sat, 14 Jun 2003 07:36:24 +0200 (CEST) From: stefan X-X-Sender: stefan@bono.reversers.net To: Kevin Ryde In-Reply-To: <87k7bsmaqq.fsf@zip.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 14 Jun 2003 05:42:02 -0000 On Thu, 12 Jun 2003, Kevin Ryde wrote: > > I just added a check for unsetenv() in the configure script and used it in > > posix.c appropiately for mingw32 hosts. Which means that a > > putenv("name="); would remove the environment variable 'name'. > > I guess this means it's not possible to use putenv("name=") to set > name to an empty string. I'm pretty sure it's valid to do so on other > systems. > > On wine, which might not be the same as a real mingw, setting "name= " > and then changing that space to a \0 does the trick. Bit nasty to go > changing putenvs strings like that, but unless there's a setenv or > some function hiding then there might be no choice. Eg, (untested), > > > > /* If str is "FOO=", ie. attempting to set an empty string, then we > need to see if it's been successful. On MINGW, "FOO=" means remove > FOO from the environment. As a workaround, we set "FOO= ", ie. a > space, and then modify the string returned by getenv. It's not > enough just to modify the string we set, because MINGW putenv > copies it. */ > if (ptr[SCM_STRING_LENGTH(str)-1] == '=') > { > SCM name = scm_substring (str, SCM_MAKINUM (0), > SCM_MAKINUM (SCM_STRING_LENGTH (str) - 1)); > if (getenv (SCM_STRING_CHARS (name)) == NULL) > { > char *alt = scm_malloc (SCM_STRING_LENGTH (str) + 2); > memcpy (alt, SCM_STRING_CHARS (str), SCM_STRING_LENGTH(str)); > alt[SCM_STRING_LENGTH(str)] = ' '; > alt[SCM_STRING_LENGTH(str)+1] = '\0'; > rv = putenv (alt); > if (rv < 0) > SCM_SYSERROR; > free (ptr); /* don't need the old string we gave to putenv */ > alt = getenv (SCM_STRING_CHARS (name)); > alt[SCM_STRING_LENGTH(str)] = '\0'; > } > } I tested this piece of code on my Win95 box and modified it a bit to get it really working. Then I applied the code CVS. The (putenv) primitive now behaves equally on GNU/Linux and Win32. Cheers, stefan@lkcc.org From MAILER-DAEMON Sat Jun 14 08:26:56 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19RA76-0005cM-Fy for mharc-guile-devel@gnu.org; Sat, 14 Jun 2003 08:26:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19RA73-0005V4-FI for guile-devel@gnu.org; Sat, 14 Jun 2003 08:26:29 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RA6q-0005Be-7b for guile-devel@gnu.org; Sat, 14 Jun 2003 08:26:19 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19RA6p-00059m-DB for guile-devel@gnu.org; Sat, 14 Jun 2003 08:26:15 -0400 Received: from dialin.speedway43.dip170.dokom.de ([195.138.43.170] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19RA6x-0000Kv-00 for guile-devel@gnu.org; Sat, 14 Jun 2003 14:26:23 +0200 Received: (qmail 9585 invoked by uid 1000); 14 Jun 2003 12:24:56 -0000 To: stefan References: From: Marius Vollmer Date: 14 Jun 2003 14:24:55 +0200 In-Reply-To: Message-ID: <87d6hg6e3s.fsf@zagadka.ping.de> Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 14 Jun 2003 12:26:30 -0000 stefan writes: > I tested this piece of code on my Win95 box and modified it a bit to get > it really working. Then I applied the code CVS. The (putenv) primitive > now behaves equally on GNU/Linux and Win32. Hmm, while you are at it, could you try to clean up the code in general? That is, make it so that we always have unsetenv and can use it in scm_putenv. unsetenv could be put into libguile/unsetenv.c, ala libguile/putenv.c. Makes sense? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sat Jun 14 09:49:50 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19RBPO-00071C-M7 for mharc-guile-devel@gnu.org; Sat, 14 Jun 2003 09:49:30 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19RBPL-0006vl-Is for guile-devel@gnu.org; Sat, 14 Jun 2003 09:49:27 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RBPH-0006qU-T5 for guile-devel@gnu.org; Sat, 14 Jun 2003 09:49:24 -0400 Received: from obh.snafu.de ([213.73.92.34]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19RBPD-0006g0-K6 for guile-devel@gnu.org; Sat, 14 Jun 2003 09:49:19 -0400 Received: from p-164-122.zrz.tu-berlin.de ([130.149.164.122] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19RBPB-0007VH-00; Sat, 14 Jun 2003 15:49:18 +0200 Received: from localhost ([127.0.0.1] ident=ela) by bono with esmtp (Exim 3.36 #1) id 19RBML-00008E-00; Sat, 14 Jun 2003 15:46:21 +0200 Date: Sat, 14 Jun 2003 15:46:21 +0200 (CEST) From: stefan X-X-Sender: stefan@bono.reversers.net To: Marius Vollmer In-Reply-To: <87d6hg6e3s.fsf@zagadka.ping.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 14 Jun 2003 13:49:29 -0000 On 14 Jun 2003, Marius Vollmer wrote: > > I tested this piece of code on my Win95 box and modified it a bit to get > > it really working. Then I applied the code CVS. The (putenv) primitive > > now behaves equally on GNU/Linux and Win32. > > Hmm, while you are at it, could you try to clean up the code in > general? That is, make it so that we always have unsetenv and can use > it in scm_putenv. unsetenv could be put into libguile/unsetenv.c, ala > libguile/putenv.c. Makes sense? Unfortunately I don't know where to get the file unsetenv.c from. Could you please send me an appropriate URL? Then I am going to test it on the Win95 box and will apply the changes to CVS, if it works. Cheers, stefan@lkcc.org From MAILER-DAEMON Sat Jun 14 12:19:38 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19RDkg-0000z6-Hv for mharc-guile-devel@gnu.org; Sat, 14 Jun 2003 12:19:38 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19RDkd-0000v2-Ju for guile-devel@gnu.org; Sat, 14 Jun 2003 12:19:35 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RDkc-0000rl-32 for guile-devel@gnu.org; Sat, 14 Jun 2003 12:19:34 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19RDkb-0000pv-Oo for guile-devel@gnu.org; Sat, 14 Jun 2003 12:19:33 -0400 Received: from dialin.speedway42.dip121.dokom.de ([195.138.42.121] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19RDkj-0001aQ-00 for guile-devel@gnu.org; Sat, 14 Jun 2003 18:19:41 +0200 Received: (qmail 30452 invoked by uid 1000); 14 Jun 2003 16:18:14 -0000 To: stefan References: From: Marius Vollmer Date: 14 Jun 2003 18:18:14 +0200 In-Reply-To: Message-ID: <87znkk4oqh.fsf@zagadka.ping.de> Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 14 Jun 2003 16:19:36 -0000 stefan writes: > On 14 Jun 2003, Marius Vollmer wrote: > > > > I tested this piece of code on my Win95 box and modified it a bit to get > > > it really working. Then I applied the code CVS. The (putenv) primitive > > > now behaves equally on GNU/Linux and Win32. > > > > Hmm, while you are at it, could you try to clean up the code in > > general? That is, make it so that we always have unsetenv and can use > > it in scm_putenv. unsetenv could be put into libguile/unsetenv.c, ala > > libguile/putenv.c. Makes sense? > > Unfortunately I don't know where to get the file unsetenv.c from. Could > you please send me an appropriate URL? That file does not exist yet, you would have to create it. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Sat Jun 14 20:16:54 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19RLCH-0006l7-Ru for mharc-guile-devel@gnu.org; Sat, 14 Jun 2003 20:16:37 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19RLCB-0006Ub-Ii for guile-devel@gnu.org; Sat, 14 Jun 2003 20:16:31 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RLC2-0005yw-VS for guile-devel@gnu.org; Sat, 14 Jun 2003 20:16:26 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19RLC2-0005SQ-6h for guile-devel@gnu.org; Sat, 14 Jun 2003 20:16:22 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5F0GEYd016654 for ; Sun, 15 Jun 2003 10:16:14 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5F0GEQg029035 for ; Sun, 15 Jun 2003 10:16:14 +1000 (EST) Received: from localhost (ppp116.dyn228.pacific.net.au [203.143.228.116]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5F0G7YZ013759 for ; Sun, 15 Jun 2003 10:16:10 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19RLBf-0000ut-00; Sun, 15 Jun 2003 10:15:59 +1000 To: guile-devel@gnu.org References: From: Kevin Ryde Mail-Copies-To: never Date: Sun, 15 Jun 2003 10:15:58 +1000 Message-ID: <87llw4w5z5.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: putenv tests (was: native Win32 guile 1.7.0) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 15 Jun 2003 00:16:33 -0000 --=-=-= I think I'll add some small test cases for putenv and friends, * tests/posix.test: New file. * Makefile.am (SCM_TESTS): Add it. I don't want to gratuitously provoke failures, but the tests reflect the documentation and systems with problems need to be identified :-). --=-=-= Content-Disposition: attachment; filename=posix.test ;;;; posix.test --- Test suite for Guile POSIX functions. -*- scheme -*- ;;;; ;;;; Copyright 2003 Free Software Foundation, Inc. ;;;; ;;;; This program is free software; you can redistribute it and/or modify ;;;; it under the terms of the GNU General Public License as published by ;;;; the Free Software Foundation; either version 2, or (at your option) ;;;; any later version. ;;;; ;;;; This program is distributed in the hope that it will be useful, ;;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;;; GNU General Public License for more details. ;;;; ;;;; You should have received a copy of the GNU General Public License ;;;; along with this software; see the file COPYING. If not, write to ;;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;;; Boston, MA 02111-1307 USA (use-modules (test-suite lib)) ;; ;; putenv ;; (with-test-prefix "putenv" (pass-if "something" (putenv "FOO=something") (equal? "something" (getenv "FOO"))) (pass-if "replacing" (putenv "FOO=one") (putenv "FOO=two") (equal? "two" (getenv "FOO"))) (pass-if "empty" (putenv "FOO=") (equal? "" (getenv "FOO"))) (pass-if "removing" (putenv "FOO=bar") (putenv "FOO") (not (getenv "FOO"))) (pass-if "modifying string doesn't change env" (let ((s (string-copy "FOO=bar"))) (putenv s) (string-set! s 5 #\x) (equal? "bar" (getenv "FOO"))))) ;; ;; setenv ;; (with-test-prefix "setenv" (pass-if "something" (setenv "FOO" "something") (equal? "something" (getenv "FOO"))) (pass-if "replacing" (setenv "FOO" "one") (setenv "FOO" "two") (equal? "two" (getenv "FOO"))) (pass-if "empty" (setenv "FOO" "") (equal? "" (getenv "FOO"))) (pass-if "removing" (setenv "FOO" "something") (setenv "FOO" #f) (not (getenv "FOO")))) ;; ;; unsetenv ;; (with-test-prefix "unsetenv" (pass-if "something" (putenv "FOO=something") (unsetenv "FOO") (not (getenv "FOO"))) (pass-if "empty" (putenv "FOO=") (unsetenv "FOO") (not (getenv "FOO")))) --=-=-=-- From MAILER-DAEMON Sat Jun 14 20:18:45 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19RLE6-00083N-Fd for mharc-guile-devel@gnu.org; Sat, 14 Jun 2003 20:18:30 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19RLDz-0007sA-8w for guile-devel@gnu.org; Sat, 14 Jun 2003 20:18:23 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RLDw-0007oE-3G for guile-devel@gnu.org; Sat, 14 Jun 2003 20:18:20 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19RLDL-0007b4-AK for guile-devel@gnu.org; Sat, 14 Jun 2003 20:17:43 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5F0HfYd016851 for ; Sun, 15 Jun 2003 10:17:41 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5F0HfQg029221 for ; Sun, 15 Jun 2003 10:17:41 +1000 (EST) Received: from localhost (ppp116.dyn228.pacific.net.au [203.143.228.116]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5F0HeYZ014619 for ; Sun, 15 Jun 2003 10:17:40 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19RLDC-0000v4-00; Sun, 15 Jun 2003 10:17:34 +1000 To: guile-devel@gnu.org References: <87ade1t1p7.fsf@zip.com.au> <87d6ih5okm.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sun, 15 Jun 2003 10:17:34 +1000 Message-ID: <87d6hgw5wh.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: min, max and nans X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 15 Jun 2003 00:18:28 -0000 I notice C99 fmin and fmax return the other operand when one is a NaN, and return NaN only when both are NaNs. I tend to think of nan as indicating something evil, and it should be propagated. But the c99 way would be a possibility to consider. From MAILER-DAEMON Sat Jun 14 20:32:27 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19RLRb-0008HE-4J for mharc-guile-devel@gnu.org; Sat, 14 Jun 2003 20:32:27 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19RLRY-0008BP-IE for guile-devel@gnu.org; Sat, 14 Jun 2003 20:32:24 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RLRW-00087T-Se for guile-devel@gnu.org; Sat, 14 Jun 2003 20:32:23 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19RLRW-00084N-3t for guile-devel@gnu.org; Sat, 14 Jun 2003 20:32:22 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5F0WJYd018923 for ; Sun, 15 Jun 2003 10:32:19 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5F0WJQg001179 for ; Sun, 15 Jun 2003 10:32:19 +1000 (EST) Received: from localhost (ppp116.dyn228.pacific.net.au [203.143.228.116]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5F0WGYZ023192 for ; Sun, 15 Jun 2003 10:32:17 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19RLRK-0000wg-00; Sun, 15 Jun 2003 10:32:10 +1000 To: guile-devel@gnu.org References: <877k7sm7uq.fsf@zip.com.au> <87smqf8kcr.fsf@zagadka.ping.de> <87u1at7cgk.fsf@zip.com.au> <87k7bp5wj3.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sun, 15 Jun 2003 10:32:10 +1000 In-Reply-To: <87k7bp5wj3.fsf@zagadka.ping.de> (Marius Vollmer's message of "14 Jun 2003 02:32:16 +0200") Message-ID: <877k7ow585.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco ports verbiage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 15 Jun 2003 00:32:25 -0000 Marius Vollmer writes: > > Or we could stay in Scheme and say it is equivalent to > > (open-file FILENAME "w") Yes, that sounds like the way to go. New effort below, referring to open-input-file and open-output-file, which strike me as natural counterparts to these `with' functions. > and make sure that open-file is documented properly. I guess it already says the contents are removed (truncated) for "w". - Scheme Procedure: call-with-input-file filename proc - Scheme Procedure: call-with-output-file filename proc Open FILENAME for input or output, and call `(PROC port)' with the resulting port. Return the value returned by PROC. FILENAME is opened as per `open-input-file' or `open-output-file' respectively, and an error is signalled if it cannot be opened. When PROC returns, the port is closed. If PROC does not return (eg. if it throws an error), then the port might not be closed automatically, though it will be garbage collected in the usual way if not otherwise referenced. - Scheme Procedure: with-input-from-file filename thunk - Scheme Procedure: with-output-to-file filename thunk - Scheme Procedure: with-error-to-file filename thunk Open FILENAME and call `(THUNK)' with the new port setup as respectively the `current-input-port', `current-output-port', or `current-error-port'. Return the value returned by THUNK. FILENAME is opened as per `open-input-file' or `open-output-file' respectively, and an error is signalled if it cannot be opened. When THUNK returns, the port is closed and the previous setting of the respective current port is restored. The current port setting is managed with `dynamic-wind', so the previous value is restored no matter how THUNK exits (eg. an exception), and if THUNK is re-entered (via a captured continuation) then it's set again to the FILENAME port. The port is closed when THUNK returns normally, but not when exited via an exception or new continuation. This ensures it's still ready for use if THUNK is re-entered by a captured continuation. Of course the port is always garbage collected and closed in the usual way when no longer referenced anywhere. From MAILER-DAEMON Mon Jun 16 13:33:34 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19RxqQ-0006Nb-Ro for mharc-guile-devel@gnu.org; Mon, 16 Jun 2003 13:32:38 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Rxns-0005eL-C3 for guile-devel@gnu.org; Mon, 16 Jun 2003 13:30:00 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RxnS-0004Y7-Mr for guile-devel@gnu.org; Mon, 16 Jun 2003 13:29:36 -0400 Received: from obh.snafu.de ([213.73.92.34]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Rxmh-0003fG-Nz for guile-devel@gnu.org; Mon, 16 Jun 2003 13:28:48 -0400 Received: from p-165-091.zrz.tu-berlin.de ([130.149.165.91] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19Rxmd-000Osd-00; Mon, 16 Jun 2003 19:28:44 +0200 Received: from localhost ([127.0.0.1] ident=ela) by bono with esmtp (Exim 3.36 #1) id 19RxjA-0000Ar-00; Mon, 16 Jun 2003 19:25:08 +0200 Date: Mon, 16 Jun 2003 19:25:08 +0200 (CEST) From: stefan X-X-Sender: stefan@bono.reversers.net To: Marius Vollmer In-Reply-To: <87znkk4oqh.fsf@zagadka.ping.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 16 Jun 2003 17:32:36 -0000 On 14 Jun 2003, Marius Vollmer wrote: > > > > I tested this piece of code on my Win95 box and modified it a bit to get > > > > it really working. Then I applied the code CVS. The (putenv) primitive > > > > now behaves equally on GNU/Linux and Win32. > > > > > > Hmm, while you are at it, could you try to clean up the code in > > > general? That is, make it so that we always have unsetenv and can use > > > it in scm_putenv. unsetenv could be put into libguile/unsetenv.c, ala > > > libguile/putenv.c. Makes sense? > > > > Unfortunately I don't know where to get the file unsetenv.c from. Could > > you please send me an appropriate URL? > > That file does not exist yet, you would have to create it. Do you actually mean an implementation for *all* systems which don't support unsetenv() or an implementation for WIn32 only (i.e. win32-unsetenv.c)? Cheers, stefan@lkcc.org From MAILER-DAEMON Mon Jun 16 14:54:40 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Rz3c-0000Tv-U8 for mharc-guile-devel@gnu.org; Mon, 16 Jun 2003 14:50:20 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Rz3H-0000B0-KO for guile-devel@gnu.org; Mon, 16 Jun 2003 14:49:59 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Rz2e-0007wL-K6 for guile-devel@gnu.org; Mon, 16 Jun 2003 14:49:21 -0400 Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Rz0h-0006pr-Vq for guile-devel@gnu.org; Mon, 16 Jun 2003 14:47:20 -0400 Received: from barbara.blakulla.net ([213.212.21.238] helo=witch) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 19Rz0f-00049F-00; Mon, 16 Jun 2003 20:47:17 +0200 Received: from mdj by witch with local (Exim 3.35 #1 (Debian)) id 19Ryyl-0000dw-00; Mon, 16 Jun 2003 20:45:19 +0200 To: guile-devel@gnu.org References: <87y90cfcjy.fsf@zip.com.au> <87k7bskqlp.fsf@zip.com.au> <87y9057d4y.fsf@zip.com.au> From: Mikael Djurfeldt Date: Mon, 16 Jun 2003 20:45:19 +0200 In-Reply-To: <87y9057d4y.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 14 Jun 2003 09:48:13 +1000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Mikael Djurfeldt cc: djurfeldt@nada.kth.se Subject: Re: parallel with no exprs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: djurfeldt@nada.kth.se List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 16 Jun 2003 18:50:18 -0000 Kevin Ryde writes: > Mikael Djurfeldt writes: >> >> Oops. The second lambda should have (x) as formal parameters. >> But this error is independent from the problem we are discussing. >> (parallel) correctly expands to (begin). > > Are you sure you want it that way? I guess it'd be necessary to > document that parallel of N forms returns N values except that 0 forms > returns 1 unspecified value. No. In fact, I'm not sure at all. In fact, I am no longer the Guile developer who says "(parallel) should expand to (begin)". I am now the Guile developer who says "(parallel) should expand to (values)"! Please do apply your patch. (Sorry for not paying attention.) > (I'm not especially worried one way or the other, I only arrived at it > from looking to add to the manual.) Good thing to express things with words... >> In our implementation, >> (begin) evaluates to # which is 1 value, so the second >> lambda must take 1 argument. > > Yes I thought it might be the unspecified literalism, or rather the > literalism of unspecified :-). The question is if (begin) --> # is correct. Probably so, because (begin) is a sequence and it should probably always return 1 value... M From MAILER-DAEMON Tue Jun 17 07:53:23 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SF1Q-0008Il-AD for mharc-guile-devel@gnu.org; Tue, 17 Jun 2003 07:53:08 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SF1H-0007yj-Ka for guile-devel@gnu.org; Tue, 17 Jun 2003 07:52:59 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SF1A-0007fi-6H for guile-devel@gnu.org; Tue, 17 Jun 2003 07:52:52 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SF19-0007Xa-91 for guile-devel@gnu.org; Tue, 17 Jun 2003 07:52:51 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19SF16-0007XD-00 for guile-devel@gnu.org; Tue, 17 Jun 2003 13:52:48 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5HBqke14573; Tue, 17 Jun 2003 13:52:46 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Tue, 17 Jun 2003 13:52:46 +0200 Message-ID: Lines: 46 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: [Patch] Only use -Werror with gcc X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 17 Jun 2003 11:53:05 -0000 Guile from CVS HEAD does not build with non-gcc compilers because the -Werror flag is passed to the compiler when GUILE_ERROR_ON_WARNING is yes (the default). Here is a patch. (Does anybody test Guile with non-gcc compilers?) --- configure.in.~1.220.~ Mon Jun 16 16:49:24 2003 +++ configure.in Tue Jun 17 13:39:37 2003 @@ -969,15 +969,6 @@ fi AC_SUBST(GUILE_FOR_BUILD) =20=20=20=09=09=09 -# Do this here so we don't screw up any of the tests above that might -# not be "warning free" - -if test "${GUILE_ERROR_ON_WARNING}" =3D yes -then - CFLAGS=3D"${CFLAGS} -Werror" - enable_compile_warnings=3Dno -fi - ## If we're using GCC, ask for aggressive warnings. case "$GCC" in yes ) @@ -986,7 +977,15 @@ ## less than exasperating. ## -Wpointer-arith was here too, but something changed in gcc/glibc ## and it became equally exasperating (gcc 2.95 and/or glibc 2.1.2). - CFLAGS=3D"$CFLAGS -Wall -Wmissing-prototypes" ;; + CFLAGS=3D"$CFLAGS -Wall -Wmissing-prototypes" + # Do this here so we don't screw up any of the tests above that might + # not be "warning free" + if test "${GUILE_ERROR_ON_WARNING}" =3D yes + then + CFLAGS=3D"${CFLAGS} -Werror" + enable_compile_warnings=3Dno + fi + ;; esac =20 ## NOTE the code below sets LIBOBJS directly and so is now forbidden --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Wed Jun 18 02:30:26 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SWPR-0001d0-Ct for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 02:27:05 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SWPN-0001YO-SZ for guile-devel@gnu.org; Wed, 18 Jun 2003 02:27:01 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SWPM-0001Xq-CR for guile-devel@gnu.org; Wed, 18 Jun 2003 02:27:00 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SWOD-0001Ab-Vl for guile-devel@gnu.org; Wed, 18 Jun 2003 02:25:50 -0400 Received: from kombi4 ([141.44.75.44] helo=kombi4.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19SWOD-00024u-00 for guile-devel@gnu.org; Wed, 18 Jun 2003 08:25:49 +0200 Received: (from mkoeppe@localhost) by kombi4.math.uni-magdeburg.de (8.11.6+Sun/8.10.2) id h5I6Pli05216; Wed, 18 Jun 2003 08:25:47 +0200 (MEST) X-Authentication-Warning: kombi4.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Wed, 18 Jun 2003 08:25:47 +0200 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: Portability bug with UINTPTR_MAX in Solaris/Forte X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 06:27:03 -0000 I have trouble compiling Guile from CVS HEAD on Solaris 7 and 8 using the Forte (Sun Workshop) C compiler. The reason is the new code using `uintptr_t' (declarations in tags.h). On Solaris, there is a uintptr_t, and UINTPTR_MAX is also a defined macro, but it expands to nothing. (/usr/include/sys/int_limits.h, line 124.) This causes the compilation of libguile/print.c (for instance) to fail. I would suggest that the presence of both uintptr_t and a useful value UINTPTR_MAX should be checked at configuration time. I am not sending a patch, but I am willing to test patches that fix this problem, in case you don't have access to Solaris (or a non-gcc compiler).=20 --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Wed Jun 18 02:51:30 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SWlg-00025F-DO for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 02:50:04 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SWl8-00020z-LC for guile-devel@gnu.org; Wed, 18 Jun 2003 02:49:30 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SWkw-0001Yx-84 for guile-devel@gnu.org; Wed, 18 Jun 2003 02:49:21 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SWkt-0001TB-Qd for guile-devel@gnu.org; Wed, 18 Jun 2003 02:49:15 -0400 Received: from kombi4 ([141.44.75.44] helo=kombi4.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19SWkt-0002Nd-00 for guile-devel@gnu.org; Wed, 18 Jun 2003 08:49:15 +0200 Received: (from mkoeppe@localhost) by kombi4.math.uni-magdeburg.de (8.11.6+Sun/8.10.2) id h5I6nD305265; Wed, 18 Jun 2003 08:49:13 +0200 (MEST) X-Authentication-Warning: kombi4.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Wed, 18 Jun 2003 08:49:13 +0200 Message-ID: Lines: 85 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: [Patch] SCM_C_INLINE is used wrongly in numbers.c X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 06:50:02 -0000 When the compiler does not understand the `inline' keyword, configure arranges that SCM_C_INLINE is not defined as a macro. In this case, libguile/numbers.c (CVS HEAD) cannot be compiled. Here is a patch: --- numbers.c.~1.191.~ Mon Jun 16 16:49:58 2003 +++ numbers.c Tue Jun 17 18:42:26 2003 @@ -125,7 +125,10 @@ static const char s_bignum[] = "bignum"; -SCM_C_INLINE SCM +#ifdef SCM_C_INLINE +SCM_C_INLINE +#endif +SCM scm_i_mkbig () { /* Return a newly created bignum. */ @@ -134,7 +137,10 @@ return z; } -SCM_C_INLINE static SCM +#ifdef SCM_C_INLINE +SCM_C_INLINE +#endif +static SCM scm_i_clonebig (SCM src_big, int same_sign_p) { /* Copy src_big's value, negate it if same_sign_p is false, and return. */ @@ -144,7 +150,10 @@ return z; } -SCM_C_INLINE int +#ifdef SCM_C_INLINE +SCM_C_INLINE +#endif +int scm_i_bigcmp (SCM x, SCM y) { /* Return neg if x < y, pos if x > y, and 0 if x == y */ @@ -154,7 +163,10 @@ return result; } -SCM_C_INLINE SCM +#ifdef SCM_C_INLINE +SCM_C_INLINE +#endif +SCM scm_i_dbl2big (double d) { /* results are only defined if d is an integer */ @@ -163,7 +175,10 @@ return z; } -SCM_C_INLINE double +#ifdef SCM_C_INLINE +SCM_C_INLINE +#endif +double scm_i_big2dbl (SCM b) { double result = mpz_get_d (SCM_I_BIG_MPZ (b)); @@ -171,7 +186,10 @@ return result; } -SCM_C_INLINE SCM +#ifdef SCM_C_INLINE +SCM_C_INLINE +#endif +SCM scm_i_normbig (SCM b) { /* convert a big back to a fixnum if it'll fit */ -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Wed Jun 18 02:58:16 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SWtc-0001cG-0m for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 02:58:16 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SWtR-00013V-HV for guile-devel@gnu.org; Wed, 18 Jun 2003 02:58:05 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SWt6-0008RG-KU for guile-devel@gnu.org; Wed, 18 Jun 2003 02:57:46 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SWrh-0006Gt-7Y for guile-devel@gnu.org; Wed, 18 Jun 2003 02:56:17 -0400 Received: from kombi4 ([141.44.75.44] helo=kombi4.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19SWrV-0002X9-00 for guile-devel@gnu.org; Wed, 18 Jun 2003 08:56:05 +0200 Received: (from mkoeppe@localhost) by kombi4.math.uni-magdeburg.de (8.11.6+Sun/8.10.2) id h5I6u5Y05308; Wed, 18 Jun 2003 08:56:05 +0200 (MEST) X-Authentication-Warning: kombi4.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Wed, 18 Jun 2003 08:56:05 +0200 Message-ID: Lines: 43 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: [Patch] libguile/gc-card.c: A cast does not yield an lvalue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 06:58:14 -0000 When compiling Guile from CVS HEAD with the Sun Forte C compiler, I get the error "A cast does not yield an lvalue" when compiling gc-card.c. Here is a patch. (See also the ChangeLog entry of 2001-01-11.) Index: libguile/gc.h =================================================================== RCS file: /cvs/guile/guile-core/libguile/gc.h,v retrieving revision 1.109 diff -u -r1.109 gc.h --- libguile/gc.h 29 May 2003 14:39:13 -0000 1.109 +++ libguile/gc.h 18 Jun 2003 06:49:08 -0000 @@ -103,6 +103,7 @@ #define SCM_GC_CELL_CARD(x) ((scm_t_cell *) ((long) (x) & SCM_GC_CARD_ADDR_MASK)) #define SCM_GC_CELL_OFFSET(x) (((long) (x) & SCM_GC_CARD_SIZE_MASK) >> SCM_CELL_SIZE_SHIFT) #define SCM_GC_CELL_BVEC(x) SCM_GC_CARD_BVEC (SCM_GC_CELL_CARD (x)) +#define SCM_GC_SET_CELL_BVEC(x, bvec) SCM_GC_SET_CARD_BVEC (SCM_GC_CELL_CARD (x), bvec) #define SCM_GC_CELL_GET_BIT(x) SCM_C_BVEC_GET (SCM_GC_CELL_BVEC (x), SCM_GC_CELL_OFFSET (x)) #define SCM_GC_CELL_SET_BIT(x) SCM_C_BVEC_SET (SCM_GC_CELL_BVEC (x), SCM_GC_CELL_OFFSET (x)) #define SCM_GC_CELL_CLEAR_BIT(x) SCM_C_BVEC_CLEAR (SCM_GC_CELL_BVEC (x), SCM_GC_CELL_OFFSET (x)) Index: libguile/gc-card.c =================================================================== RCS file: /cvs/guile/guile-core/libguile/gc-card.c,v retrieving revision 1.17 diff -u -r1.17 gc-card.c --- libguile/gc-card.c 4 Jun 2003 05:28:34 -0000 1.17 +++ libguile/gc-card.c 18 Jun 2003 06:49:08 -0000 @@ -308,7 +308,7 @@ int idx = (card - seg->bounds[0]) / SCM_GC_CARD_N_CELLS; bvec_ptr += idx *SCM_GC_CARD_BVEC_SIZE_IN_LONGS; - SCM_GC_CELL_BVEC (card) = bvec_ptr; + SCM_GC_SET_CELL_BVEC (card, bvec_ptr); /* ASSUMPTION: n_header_cells <= 2. -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Wed Jun 18 04:40:00 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SYU4-0008Nl-4g for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 04:40:00 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SYU1-0008GW-Aq for guile-devel@gnu.org; Wed, 18 Jun 2003 04:39:57 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SYTj-00087v-Jb for guile-devel@gnu.org; Wed, 18 Jun 2003 04:39:40 -0400 Received: from octopussy.utanet.at ([213.90.36.45]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SYTN-0007gC-25 for guile-devel@gnu.org; Wed, 18 Jun 2003 04:39:17 -0400 Received: from plenty.utanet.at ([213.90.36.9]) by octopussy.utanet.at with esmtp (Exim 4.12) id 19SYTG-0004PY-00; Wed, 18 Jun 2003 10:39:10 +0200 Received: from dsl-240-149.utaonline.at ([212.152.240.149] helo=rotty-ipv4.yi.org) by plenty.utanet.at with esmtp (Exim 4.12) id 19SYTG-0002oo-00; Wed, 18 Jun 2003 10:39:10 +0200 Received: from alice.rhinosaur.lan ([192.168.1.3] ident=mail) by rotty-ipv4.yi.org with esmtp (Exim 3.36 #1 (Debian)) id 19SYTH-0000uL-00; Wed, 18 Jun 2003 10:39:11 +0200 Received: from andy by alice.rhinosaur.lan with local (Exim 4.20) id 19SYTG-0000VD-RK; Wed, 18 Jun 2003 10:39:10 +0200 To: Matthias Koeppe References: From: Andreas Rottmann Date: Wed, 18 Jun 2003 10:39:10 +0200 In-Reply-To: (Matthias Koeppe's message of "Wed, 18 Jun 2003 08:49:13 +0200") Message-ID: <87adcfdbkh.fsf@alice.rotty.yi.org> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Andreas Rottmann cc: guile-devel@gnu.org Subject: Re: [Patch] SCM_C_INLINE is used wrongly in numbers.c X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 08:39:58 -0000 Matthias Koeppe writes: > When the compiler does not understand the `inline' keyword, configure > arranges that SCM_C_INLINE is not defined as a macro. In this case, > libguile/numbers.c (CVS HEAD) cannot be compiled. > > Here is a patch: > [snip] Wouldn't it be more simple to define SCM_C_INLINE empty? Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Make free software, not war! From MAILER-DAEMON Wed Jun 18 05:21:46 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SZ6R-0000lb-LE for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 05:19:39 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SZ5o-000054-KN for guile-devel@gnu.org; Wed, 18 Jun 2003 05:19:00 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SZ5e-0008LX-G2 for guile-devel@gnu.org; Wed, 18 Jun 2003 05:18:51 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SZ50-0007z0-Kf for guile-devel@gnu.org; Wed, 18 Jun 2003 05:18:10 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19SZ4z-0005AH-00 for guile-devel@gnu.org; Wed, 18 Jun 2003 11:18:09 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5I9I8K29001; Wed, 18 Jun 2003 11:18:08 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Wed, 18 Jun 2003 11:18:08 +0200 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: [Patch] Fix configure test for __libc_stack_end X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 09:19:37 -0000 The test for `guile_cv_have_libc_stack_end' does not work reliably because the compiler can optimize away the use of the variable in the test program. This happened to me on Solaris with the Sun Forte C compiler. Here is a patch. --- configure.in.~1.220.~ Mon Jun 16 16:49:24 2003 +++ configure.in Wed Jun 18 10:49:17 2003 @@ -603,8 +603,9 @@ AC_MSG_CHECKING(for __libc_stack_end) AC_CACHE_VAL(guile_cv_have_libc_stack_end, -[AC_TRY_LINK([extern char *__libc_stack_end;], - [char *p = __libc_stack_end;], +[AC_TRY_LINK([#include +extern char *__libc_stack_end;], + [printf("%s", (char*) __libc_stack_end);], guile_cv_have_libc_stack_end=yes, guile_cv_have_libc_stack_end=no)]) AC_MSG_RESULT($guile_cv_have_libc_stack_end) -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Wed Jun 18 06:35:11 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SaG9-0000fq-2c for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 06:33:45 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SaFq-0000RK-EA for guile-devel@gnu.org; Wed, 18 Jun 2003 06:33:26 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SaFZ-0000IE-DO for guile-devel@gnu.org; Wed, 18 Jun 2003 06:33:10 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Sa9o-0006WH-1i for guile-devel@gnu.org; Wed, 18 Jun 2003 06:27:12 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19Sa9m-0006AI-00 for guile-devel@gnu.org; Wed, 18 Jun 2003 12:27:10 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5IAR5B29970; Wed, 18 Jun 2003 12:27:05 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Wed, 18 Jun 2003 12:27:05 +0200 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: [Patch] configure.in: Find library of sched_yield X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 10:33:43 -0000 On Solaris, when compiling Guile from CVS HEAD with --with-threads=yes, Guile cannot be linked because the symbol `sched_yield' is unresolved. The following patch arranges that at configure time, the library is searched that is needed to define `sched_yield'. --- configure.in.~1.220.~ Mon Jun 16 16:49:24 2003 +++ configure.in Wed Jun 18 11:34:51 2003 @@ -906,6 +907,10 @@ AC_DEFINE_UNQUOTED(SCM_MUTEX_RECURSIVE, $guile_cv_have_mutex_recursive, [The mutex kind enum for recursive mutexes.]) fi + + # On Solaris, sched_yield lives in -lrt. + AC_SEARCH_LIBS(sched_yield, rt) + ;; esac -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Wed Jun 18 18:37:52 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SlW5-0000e8-KC for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 18:34:57 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SlSd-0007J6-Id for guile-devel@gnu.org; Wed, 18 Jun 2003 18:31:23 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SlRE-0006Yc-69 for guile-devel@gnu.org; Wed, 18 Jun 2003 18:29:59 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SlOr-0005Fv-5G for guile-devel@gnu.org; Wed, 18 Jun 2003 18:27:29 -0400 Received: from dialin.speedway43.dip206.dokom.de ([195.138.43.206] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19SlP3-0000oe-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 00:27:41 +0200 Received: (qmail 602 invoked by uid 1000); 18 Jun 2003 22:26:08 -0000 To: guile-devel@gnu.org References: <87u1b5e2wk.fsf@zip.com.au> From: Marius Vollmer Date: 19 Jun 2003 00:26:08 +0200 In-Reply-To: <87u1b5e2wk.fsf@zip.com.au> Message-ID: <87r85r10qn.fsf@zagadka.ping.de> Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: README docs update X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 22:34:55 -0000 Kevin Ryde writes: > A possible update for the README, assuming this is all true. Yes, I think it is all true. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 18 19:03:08 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SlxC-0005ec-VJ for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 19:02:58 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SluB-0004bx-DU for guile-devel@gnu.org; Wed, 18 Jun 2003 18:59:51 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Sltb-0004IL-AD for guile-devel@gnu.org; Wed, 18 Jun 2003 18:59:16 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Slta-0004H8-Ja for guile-devel@gnu.org; Wed, 18 Jun 2003 18:59:14 -0400 Received: from dialin.speedway43.dip206.dokom.de ([195.138.43.206] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19Sltm-0002Ca-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 00:59:26 +0200 Received: (qmail 3804 invoked by uid 1000); 18 Jun 2003 22:57:52 -0000 To: guile-devel@gnu.org References: <87isrtmhfw.fsf@zip.com.au> <87he79ic44.fsf@zagadka.ping.de> <87isri25yr.fsf@zip.com.au> From: Marius Vollmer Date: 19 Jun 2003 00:57:52 +0200 In-Reply-To: <87isri25yr.fsf@zip.com.au> Message-ID: <87isr30z9r.fsf@zagadka.ping.de> Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: while break and continue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 23:02:51 -0000 Kevin Ryde writes: > On this subject though, is it worth expanding to actual procedures > rather than symbols, so one gets the intended effect irrespective of > local bindings at the point used? I don't understand. What usage are you worried about? Can you give an example? > I don't suppose anyone goes out of their way to shadow standard stuff, > but it's probably nice to take precautions. Yes, definitely. That's what (ice-9 syncase) is for... -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 18 19:03:25 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SlxN-0005uN-7K for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 19:03:09 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SlwZ-0005Bx-Db for guile-devel@gnu.org; Wed, 18 Jun 2003 19:02:19 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Sluh-0004sa-7R for guile-devel@gnu.org; Wed, 18 Jun 2003 19:00:24 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Slse-0003uK-QB for guile-devel@gnu.org; Wed, 18 Jun 2003 18:58:16 -0400 Received: from dialin.speedway43.dip206.dokom.de ([195.138.43.206] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19Slsr-00029Q-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 00:58:29 +0200 Received: (qmail 3706 invoked by uid 1000); 18 Jun 2003 22:56:55 -0000 To: guile-devel@gnu.org References: <87isrtmhfw.fsf@zip.com.au> <87he79ic44.fsf@zagadka.ping.de> <878yshe1ux.fsf@zip.com.au> From: Marius Vollmer Date: 19 Jun 2003 00:56:55 +0200 In-Reply-To: <878yshe1ux.fsf@zip.com.au> Message-ID: <87n0gf0zbc.fsf@zagadka.ping.de> Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: while break and continue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 23:03:07 -0000 Kevin Ryde writes: > The code is still pretty ugly, I suppose that's what you get for > non-local exits :-). Maybe should have a caveat in the docs about > style, to discourage their use. Discourage the use of 'while' or merely 'continue' and 'break'? I think, pointing in the docs of 'while' to 'do' and the other ways of doing loops in Scheme would be good. I do think we definitely need to efficiently support non-Schemey styles, for the translators and maybe also for people used to them. But that should probably be done together with a compiler so that the common usage can be properly optimized. (A 'while' that doesn't use 'break' should not have a 'catch', etc...) Your macro is not necessarily he most efficient, but it is as efficient as possible without some kind of comiler-style analysis, I'd say. What is more important is the interface: does it have the right semantics? I think it does, and we should change our old while to your new version, even if the implementation is ugly and maybe inefficient. > I wonder if the value parameter for break should be optional, and > have while return unspecified when not given. That might be a > reasonably common usage. I think the value of a while loop is ill-specified anyway and we should always return unspecified. What should be returned when the condition becomes false? Your macro arranges to return #t, wich seems arbitrary. People who want their loop to return a specific value should use 'do', named 'let', or some other mechanism, I'd say. > Unless the whole thing is emulating some established > convention. Not that I know of. > Incidentally, where would be a good place to put some tests? > syntax.test maybe, or a new file? syntax.test seems fine. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 18 19:40:58 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SmX8-0003r1-9l for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 19:40:06 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SmWI-0003cu-Bj for guile-devel@gnu.org; Wed, 18 Jun 2003 19:39:14 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SmUo-0003Kk-WF for guile-devel@gnu.org; Wed, 18 Jun 2003 19:37:43 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SmUd-00038k-Qy for guile-devel@gnu.org; Wed, 18 Jun 2003 19:37:31 -0400 Received: from dialin.speedway43.dip206.dokom.de ([195.138.43.206] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19SmUq-0003tR-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 01:37:44 +0200 Received: (qmail 7639 invoked by uid 1000); 18 Jun 2003 23:36:10 -0000 To: guile-devel@gnu.org References: <87wugjhowm.fsf@zip.com.au> <87wugjqx1g.fsf@raven.i.defaultvalue.org> <87r86rqa6m.fsf@raven.i.defaultvalue.org> <87vfw1i1jq.fsf@zip.com.au> <87add5mh91.fsf@zip.com.au> <87isrpjx0a.fsf@zagadka.ping.de> <877k7snrg5.fsf@zip.com.au> From: Marius Vollmer Date: 19 Jun 2003 01:36:10 +0200 In-Reply-To: <877k7snrg5.fsf@zip.com.au> Message-ID: <87adcf0xhx.fsf@zagadka.ping.de> Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco scm_remember_upto_1 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 23:40:04 -0000 Kevin Ryde writes: > In a multi-threaded program, the rule is the same. As far as a > given thread is concerned, a garbage collect still only occurs > within a memory allocation function, not at an arbitrary time. > (Guile waits for all threads to reach a memory function, and holds > them there while the collector runs.) Don't say "memory allocation function", that is too specific. A GC can occur in any libguile function, since all of them might eventually allocate memory or run a async that does so, or simply invoke SCM_TICK which is also a safe point for stopping a thread. > > But when in doubt, be > > conservative: include the call to scm_remember_upto_here_1 when > > you are not sure that it is safe to leave it out. > > I think I'd rather see something unambiguous said about when a > remember must be used, instead of talking about being unsure. I tried > to reword a little to emphasise it's memory activity which provokes a > gc. Hmm, the most concrete I can think of is: If there is a call to any libguile function after you have extracted the innards of some SCM object (from a smob, or with SCM_STRING_CHARS, etc.) you can't count on that innard still being there unless the associated SCM is used again later on (and that use is not being optimized away), if only by virtue of appearing in a call to scm_remember_upto_here. The "doubt" would come when one isn't sure whether a libguile function is being called because one doesn't know what kind of stuff third party functions do. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 18 19:45:32 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Smbr-0005fP-W9 for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 19:44:59 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Smbi-0005OL-RM for guile-devel@gnu.org; Wed, 18 Jun 2003 19:44:50 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Smb0-0004ws-8h for guile-devel@gnu.org; Wed, 18 Jun 2003 19:44:06 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SmXo-0003xF-Ul for guile-devel@gnu.org; Wed, 18 Jun 2003 19:40:49 -0400 Received: from dialin.speedway43.dip206.dokom.de ([195.138.43.206] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19SmY1-00040n-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 01:41:01 +0200 Received: (qmail 7972 invoked by uid 1000); 18 Jun 2003 23:39:27 -0000 To: guile-devel@gnu.org References: <877k7sm7uq.fsf@zip.com.au> <87smqf8kcr.fsf@zagadka.ping.de> <87u1at7cgk.fsf@zip.com.au> <87k7bp5wj3.fsf@zagadka.ping.de> <877k7ow585.fsf@zip.com.au> From: Marius Vollmer Date: 19 Jun 2003 01:39:27 +0200 In-Reply-To: <877k7ow585.fsf@zip.com.au> Message-ID: <871xxr0xcg.fsf@zagadka.ping.de> Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco ports verbiage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 23:44:57 -0000 Kevin Ryde writes: > New effort below, referring to > open-input-file and open-output-file, which strike me as natural > counterparts to these `with' functions. Excellent! Thanks. > When THUNK returns, [...] I'm sure it is just me, but I don't particularly like the word "THUNK". It's just a procedure of zero arguments, nothing special about it! -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 18 19:49:52 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SmeZ-00075y-VZ for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 19:47:47 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SmcI-0005tw-L5 for guile-devel@gnu.org; Wed, 18 Jun 2003 19:45:26 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SmbE-00054S-19 for guile-devel@gnu.org; Wed, 18 Jun 2003 19:44:20 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Smb1-0004xK-BF for guile-devel@gnu.org; Wed, 18 Jun 2003 19:44:07 -0400 Received: from dialin.speedway43.dip206.dokom.de ([195.138.43.206] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19SmbE-0004Ae-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 01:44:20 +0200 Received: (qmail 8305 invoked by uid 1000); 18 Jun 2003 23:42:46 -0000 To: stefan References: From: Marius Vollmer Date: 19 Jun 2003 01:42:46 +0200 In-Reply-To: Message-ID: <87wufjymtl.fsf@zagadka.ping.de> Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: native Win32 guile 1.7.0 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 23:47:33 -0000 stefan writes: > > That file does not exist yet, you would have to create it. > > Do you actually mean an implementation for *all* systems which don't > support unsetenv() or an implementation for WIn32 only (i.e. > win32-unsetenv.c)? Hmm, that would be something for you to decide. :-) The main objective is to make the code cleaner, while keeping the current behavior. I.e., it should work on all systems it does work on now, but the portability cruft should be moved out of the main code somewhere into a corner. I don't know whether that is really feasible, I just wondered if you would like to try it out... -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 18 19:50:02 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SmeG-00070F-TP for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 19:47:28 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Smdi-0006oO-Jn for guile-devel@gnu.org; Wed, 18 Jun 2003 19:46:54 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SmcI-0005u1-PY for guile-devel@gnu.org; Wed, 18 Jun 2003 19:45:28 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SmVE-0003Ta-Pr for guile-devel@gnu.org; Wed, 18 Jun 2003 19:38:08 -0400 Received: from dialin.speedway43.dip206.dokom.de ([195.138.43.206] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19SmVR-0003vj-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 01:38:21 +0200 Received: (qmail 7707 invoked by uid 1000); 18 Jun 2003 23:36:47 -0000 To: guile-devel@gnu.org References: <87ade1t1p7.fsf@zip.com.au> <87d6ih5okm.fsf@zagadka.ping.de> <87d6hgw5wh.fsf@zip.com.au> From: Marius Vollmer Date: 19 Jun 2003 01:36:47 +0200 In-Reply-To: <87d6hgw5wh.fsf@zip.com.au> Message-ID: <8765n30xgw.fsf@zagadka.ping.de> Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: min, max and nans X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 18 Jun 2003 23:47:27 -0000 Kevin Ryde writes: > I notice C99 fmin and fmax return the other operand when one is a NaN, > and return NaN only when both are NaNs. > > I tend to think of nan as indicating something evil, and it should be > propagated. But the c99 way would be a possibility to consider. Yep. Does the IEEE standard say aomething about max and min? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Wed Jun 18 21:41:29 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19SoQb-0002hd-A1 for mharc-guile-devel@gnu.org; Wed, 18 Jun 2003 21:41:29 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19SoQN-0002Wj-5i for guile-devel@gnu.org; Wed, 18 Jun 2003 21:41:15 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SoPz-0001XK-1Z for guile-devel@gnu.org; Wed, 18 Jun 2003 21:40:53 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SoPi-0001GU-Mp for guile-devel@gnu.org; Wed, 18 Jun 2003 21:40:35 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5J1eVYd028515 for ; Thu, 19 Jun 2003 11:40:31 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5J1eUQg025128 for ; Thu, 19 Jun 2003 11:40:30 +1000 (EST) Received: from localhost (ppp13.dyn228.pacific.net.au [203.143.228.13]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5J1eSnh016830 for ; Thu, 19 Jun 2003 11:40:29 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19SoPT-0006jU-00; Thu, 19 Jun 2003 11:40:19 +1000 To: guile-devel@gnu.org References: <87y90cfcjy.fsf@zip.com.au> <87k7bskqlp.fsf@zip.com.au> <87y9057d4y.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Thu, 19 Jun 2003 11:40:17 +1000 In-Reply-To: (Mikael Djurfeldt's message of "Mon, 16 Jun 2003 20:45:19 +0200") Message-ID: <87el1qetfi.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: parallel with no exprs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 19 Jun 2003 01:41:27 -0000 Mikael Djurfeldt writes: > > Please do apply your patch. Done. I added my little test file too. > Good thing to express things with words... Though of course that's not to privilege literature over other arts. :-) From MAILER-DAEMON Thu Jun 19 08:59:22 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Sz03-0007P1-Ip for mharc-guile-devel@gnu.org; Thu, 19 Jun 2003 08:58:47 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Syzz-0007Eo-FB for guile-devel@gnu.org; Thu, 19 Jun 2003 08:58:43 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19SyzR-0006fG-47 for guile-devel@gnu.org; Thu, 19 Jun 2003 08:58:10 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19SytZ-0004f1-1O for guile-devel@gnu.org; Thu, 19 Jun 2003 08:52:05 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19SytV-0003Zj-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 14:52:01 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5JCptU17866; Thu, 19 Jun 2003 14:51:55 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Thu, 19 Jun 2003 14:51:55 +0200 Message-ID: Lines: 361 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: [Patch] inline.h should not define inline functions with "extern" linkage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 19 Jun 2003 12:58:45 -0000 I am now building Guile from CVS HEAD with a version of the Sun Forte C compiler that supports the "inline" keyword. The "inline" keyword does not imply static linkage, and in fact inline.h defines the functions `scm_cell' and `scm_double_cell' explicitly with "extern" linkage. Therefore, every file that includes inline.h defines a copy of these two functions, each copy with external linkage. This makes it impossible to link Guile. (I do not know why this would work with gcc; it is definitely wrong.) The patch below fixes it. inline.c defines the functions with external linkage, and every file including inline.h defines static inline copies. The same trick needs to be applied to the external/inline functions in numbers.h. The patch fixes them as well. Index: libguile/inline.h =================================================================== RCS file: /cvs/guile/guile-core/libguile/inline.h,v retrieving revision 1.15 diff -u -c -r1.15 inline.h *** libguile/inline.h 5 Apr 2003 19:10:23 -0000 1.15 --- libguile/inline.h 19 Jun 2003 12:45:59 -0000 *************** *** 53,59 **** #if defined SCM_C_INLINE && ! defined SCM_INLINE_C_INCLUDING_INLINE_H /* definitely inlining */ ! extern SCM_C_INLINE #endif SCM scm_cell (scm_t_bits car, scm_t_bits cdr) --- 53,59 ---- #if defined SCM_C_INLINE && ! defined SCM_INLINE_C_INCLUDING_INLINE_H /* definitely inlining */ ! static SCM_C_INLINE #endif SCM scm_cell (scm_t_bits car, scm_t_bits cdr) *************** *** 145,151 **** #if defined SCM_C_INLINE && ! defined SCM_INLINE_C_INCLUDING_INLINE_H /* definitely inlining */ ! extern SCM_C_INLINE #endif SCM scm_double_cell (scm_t_bits car, scm_t_bits cbr, --- 145,151 ---- #if defined SCM_C_INLINE && ! defined SCM_INLINE_C_INCLUDING_INLINE_H /* definitely inlining */ ! static SCM_C_INLINE #endif SCM scm_double_cell (scm_t_bits car, scm_t_bits cbr, Index: libguile/numbers.h =================================================================== RCS file: /cvs/guile/guile-core/libguile/numbers.h,v retrieving revision 1.72 diff -u -c -r1.72 numbers.h *** libguile/numbers.h 30 May 2003 09:39:34 -0000 1.72 --- libguile/numbers.h 19 Jun 2003 12:45:59 -0000 *************** *** 272,282 **** --- 272,284 ---- /* bignum internal functions */ + #if !defined(SCM_NUMBERS_INLINE_H) SCM_API SCM scm_i_mkbig (void); SCM_API SCM scm_i_normbig (SCM x); SCM_API int scm_i_bigcmp (SCM a, SCM b); SCM_API SCM scm_i_dbl2big (double d); SCM_API double scm_i_big2dbl (SCM b); + #endif SCM_API SCM scm_i_short2big (short n); SCM_API SCM scm_i_ushort2big (unsigned short n); SCM_API SCM scm_i_int2big (int n); Index: libguile/numbers.c =================================================================== RCS file: /cvs/guile/guile-core/libguile/numbers.c,v retrieving revision 1.191 diff -u -c -r1.191 numbers.c *** libguile/numbers.c 4 Jun 2003 16:09:38 -0000 1.191 --- libguile/numbers.c 19 Jun 2003 12:45:59 -0000 *************** *** 55,63 **** #include "libguile/strings.h" #include "libguile/validate.h" #include "libguile/numbers.h" #include "libguile/deprecation.h" - /* --- 55,63 ---- #include "libguile/strings.h" #include "libguile/validate.h" + #include "libguile/numbers_inline.h" #include "libguile/numbers.h" #include "libguile/deprecation.h" /* *************** *** 124,189 **** static const char s_bignum[] = "bignum"; - - SCM_C_INLINE SCM - scm_i_mkbig () - { - /* Return a newly created bignum. */ - SCM z = scm_double_cell (scm_tc16_big, 0, 0, 0); - mpz_init (SCM_I_BIG_MPZ (z)); - return z; - } - - SCM_C_INLINE static SCM - scm_i_clonebig (SCM src_big, int same_sign_p) - { - /* Copy src_big's value, negate it if same_sign_p is false, and return. */ - SCM z = scm_double_cell (scm_tc16_big, 0, 0, 0); - mpz_init_set (SCM_I_BIG_MPZ (z), SCM_I_BIG_MPZ (src_big)); - if (!same_sign_p) mpz_neg (SCM_I_BIG_MPZ (z), SCM_I_BIG_MPZ (z)); - return z; - } - - SCM_C_INLINE int - scm_i_bigcmp (SCM x, SCM y) - { - /* Return neg if x < y, pos if x > y, and 0 if x == y */ - /* presume we already know x and y are bignums */ - int result = mpz_cmp (SCM_I_BIG_MPZ (x), SCM_I_BIG_MPZ (y)); - scm_remember_upto_here_2 (x, y); - return result; - } - - SCM_C_INLINE SCM - scm_i_dbl2big (double d) - { - /* results are only defined if d is an integer */ - SCM z = scm_double_cell (scm_tc16_big, 0, 0, 0); - mpz_init_set_d (SCM_I_BIG_MPZ (z), d); - return z; - } - - SCM_C_INLINE double - scm_i_big2dbl (SCM b) - { - double result = mpz_get_d (SCM_I_BIG_MPZ (b)); - scm_remember_upto_here_1 (b); - return result; - } - - SCM_C_INLINE SCM - scm_i_normbig (SCM b) - { - /* convert a big back to a fixnum if it'll fit */ - /* presume b is a bignum */ - if (mpz_fits_slong_p (SCM_I_BIG_MPZ (b))) - { - long val = mpz_get_si (SCM_I_BIG_MPZ (b)); - if (SCM_FIXABLE (val)) - b = SCM_MAKINUM (val); - } - return b; - } SCM_DEFINE (scm_exact_p, "exact?", 1, 0, 0, (SCM x), --- 124,129 ---- *** /dev/null Thu Jun 19 13:27:05 2003 --- libguile/numbers_inline.h Thu Jun 19 14:37:45 2003 *************** *** 0 **** --- 1,119 ---- + #ifndef SCM_NUMBERS_INLINE_H + #define SCM_NUMBERS_INLINE_H + + /* Copyright (C) 1995,1996,1998,2000,2001,2003 Free Software Foundation, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + + + + #include "libguile/__scm.h" + #include "libguile/_scm.h" + #include + + #if defined SCM_C_INLINE && ! defined SCM_NUMBERS_INLINE_C_INCLUDING_NUMBERS_INLINE_H + /* definitely inlining */ + static SCM_C_INLINE + #endif + SCM + scm_i_mkbig () + { + /* Return a newly created bignum. */ + SCM z = scm_double_cell (scm_tc16_big, 0, 0, 0); + mpz_init (SCM_I_BIG_MPZ (z)); + return z; + } + + #if defined SCM_C_INLINE && ! defined SCM_NUMBERS_INLINE_C_INCLUDING_NUMBERS_INLINE_H + /* definitely inlining */ + static SCM_C_INLINE + #else + static + #endif + SCM + scm_i_clonebig (SCM src_big, int same_sign_p) + { + /* Copy src_big's value, negate it if same_sign_p is false, and return. */ + SCM z = scm_double_cell (scm_tc16_big, 0, 0, 0); + mpz_init_set (SCM_I_BIG_MPZ (z), SCM_I_BIG_MPZ (src_big)); + if (!same_sign_p) mpz_neg (SCM_I_BIG_MPZ (z), SCM_I_BIG_MPZ (z)); + return z; + } + + #if defined SCM_C_INLINE && ! defined SCM_NUMBERS_INLINE_C_INCLUDING_NUMBERS_INLINE_H + /* definitely inlining */ + static SCM_C_INLINE + #endif + int + scm_i_bigcmp (SCM x, SCM y) + { + /* Return neg if x < y, pos if x > y, and 0 if x == y */ + /* presume we already know x and y are bignums */ + int result = mpz_cmp (SCM_I_BIG_MPZ (x), SCM_I_BIG_MPZ (y)); + scm_remember_upto_here_2 (x, y); + return result; + } + + #if defined SCM_C_INLINE && ! defined SCM_NUMBERS_INLINE_C_INCLUDING_NUMBERS_INLINE_H + /* definitely inlining */ + static SCM_C_INLINE + #endif + SCM + scm_i_dbl2big (double d) + { + /* results are only defined if d is an integer */ + SCM z = scm_double_cell (scm_tc16_big, 0, 0, 0); + mpz_init_set_d (SCM_I_BIG_MPZ (z), d); + return z; + } + + #if defined SCM_C_INLINE && ! defined SCM_NUMBERS_INLINE_C_INCLUDING_NUMBERS_INLINE_H + /* definitely inlining */ + static SCM_C_INLINE + #endif + double + scm_i_big2dbl (SCM b) + { + double result = mpz_get_d (SCM_I_BIG_MPZ (b)); + scm_remember_upto_here_1 (b); + return result; + } + + #if defined SCM_C_INLINE && ! defined SCM_NUMBERS_INLINE_C_INCLUDING_NUMBERS_INLINE_H + /* definitely inlining */ + static SCM_C_INLINE + #endif + SCM + scm_i_normbig (SCM b) + { + /* convert a big back to a fixnum if it'll fit */ + /* presume b is a bignum */ + if (mpz_fits_slong_p (SCM_I_BIG_MPZ (b))) + { + long val = mpz_get_si (SCM_I_BIG_MPZ (b)); + if (SCM_FIXABLE (val)) + b = SCM_MAKINUM (val); + } + return b; + } + + #endif /* SCM_NUMBERS_INLINE_H */ + + /* + Local Variables: + c-file-style: "gnu" + End: + */ Index: libguile/Makefile.am =================================================================== RCS file: /cvs/guile/guile-core/libguile/Makefile.am,v retrieving revision 1.187 diff -u -c -r1.187 Makefile.am *** libguile/Makefile.am 29 May 2003 14:39:13 -0000 1.187 --- libguile/Makefile.am 19 Jun 2003 12:47:49 -0000 *************** *** 98,110 **** gh_io.c gh_list.c gh_predicates.c goops.c gsubr.c guardians.c hash.c \ hashtab.c hooks.c init.c inline.c ioext.c keywords.c \ lang.c list.c \ ! load.c macros.c mallocs.c modules.c numbers.c objects.c objprop.c \ options.c pairs.c ports.c print.c procprop.c procs.c properties.c \ random.c rdelim.c read.c root.c rw.c scmsigs.c script.c simpos.c smob.c \ sort.c srcprop.c stackchk.c stacks.c stime.c strings.c strop.c \ strorder.c strports.c struct.c symbols.c threads.c throw.c values.c \ variable.c vectors.c version.c vports.c weaks.c DOT_X_FILES = alist.x arbiters.x async.x backtrace.x boolean.x chars.x \ continuations.x debug.x deprecation.x deprecated.x dynl.x dynwind.x \ environments.x eq.x \ --- 98,110 ---- gh_io.c gh_list.c gh_predicates.c goops.c gsubr.c guardians.c hash.c \ hashtab.c hooks.c init.c inline.c ioext.c keywords.c \ lang.c list.c \ ! load.c macros.c mallocs.c modules.c numbers.c numbers_inline.c objects.c objprop.c \ options.c pairs.c ports.c print.c procprop.c procs.c properties.c \ random.c rdelim.c read.c root.c rw.c scmsigs.c script.c simpos.c smob.c \ sort.c srcprop.c stackchk.c stacks.c stime.c strings.c strop.c \ strorder.c strports.c struct.c symbols.c threads.c throw.c values.c \ variable.c vectors.c version.c vports.c weaks.c DOT_X_FILES = alist.x arbiters.x async.x backtrace.x boolean.x chars.x \ continuations.x debug.x deprecation.x deprecated.x dynl.x dynwind.x \ environments.x eq.x \ *************** *** 185,191 **** goops.h gsubr.h guardians.h hash.h hashtab.h hooks.h init.h \ inline.h ioext.h \ iselect.h keywords.h lang.h list.h load.h macros.h mallocs.h modules.h \ ! net_db.h numbers.h objects.h objprop.h options.h pairs.h ports.h posix.h \ regex-posix.h print.h procprop.h procs.h properties.h random.h ramap.h \ rdelim.h read.h root.h rw.h scmsigs.h validate.h script.h simpos.h smob.h \ snarf.h socket.h sort.h srcprop.h stackchk.h stacks.h stime.h strings.h \ --- 185,191 ---- goops.h gsubr.h guardians.h hash.h hashtab.h hooks.h init.h \ inline.h ioext.h \ iselect.h keywords.h lang.h list.h load.h macros.h mallocs.h modules.h \ ! net_db.h numbers.h numbers_inline.h objects.h objprop.h options.h pairs.h ports.h posix.h \ regex-posix.h print.h procprop.h procs.h properties.h random.h ramap.h \ rdelim.h read.h root.h rw.h scmsigs.h validate.h script.h simpos.h smob.h \ snarf.h socket.h sort.h srcprop.h stackchk.h stacks.h stime.h strings.h \ -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Thu Jun 19 12:06:32 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19T1oJ-0006c7-7F for mharc-guile-devel@gnu.org; Thu, 19 Jun 2003 11:58:51 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19T1o8-00063X-Ju for guile-devel@gnu.org; Thu, 19 Jun 2003 11:58:40 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19T1nm-0004rc-4O for guile-devel@gnu.org; Thu, 19 Jun 2003 11:58:21 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19T1nk-0004mW-KW for guile-devel@gnu.org; Thu, 19 Jun 2003 11:58:16 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19T1nf-0003rz-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 17:58:11 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5JFwAi20406; Thu, 19 Jun 2003 17:58:10 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org From: Matthias Koeppe Date: Thu, 19 Jun 2003 17:58:10 +0200 Message-ID: Lines: 154 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: [Patch] Re-implement srfi-1 partition in C to avoid stack overflow X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 19 Jun 2003 15:58:45 -0000 The partition procedure in srfi-1 does not work well in Guile. Even for not-very-long input lists (like 500 elements), a stack overflow is signaled. The reason seems to be the recursive use of receive and values. Here is the srfi/ChangeLog entry: 2003-06-19 Matthias Koeppe * srfi-1.c (scm_srfi1_partition), srfi-1.scm (partition): Re-implement in C to avoid stack overflows for long input lists. Index: test-suite/tests/srfi-1.test =================================================================== RCS file: /cvs/guile/guile-core/test-suite/tests/srfi-1.test,v retrieving revision 1.2 diff -u -c -r1.2 srfi-1.test *** test-suite/tests/srfi-1.test 12 May 2003 23:05:50 -0000 1.2 --- test-suite/tests/srfi-1.test 19 Jun 2003 15:52:41 -0000 *************** *** 183,185 **** --- 183,229 ---- (pass-if "'(a b . c) 2" (equal? '(a b) (take '(a b . c) 2)))) + + ;; + ;; partition + ;; + + (define (test-partition pred list kept-good dropped-good) + (call-with-values (lambda () + (partition pred list)) + (lambda (kept dropped) + (and (equal? kept kept-good) + (equal? dropped dropped-good))))) + + (with-test-prefix "partition" + + (pass-if "with dropped tail" + (test-partition even? '(1 2 3 4 5 6 7) + '(2 4 6) '(1 3 5 7))) + + (pass-if "with kept tail" + (test-partition even? '(1 2 3 4 5 6) + '(2 4 6) '(1 3 5))) + + (pass-if "with everything dropped" + (test-partition even? '(1 3 5 7) + '() '(1 3 5 7))) + + (pass-if "with everything kept" + (test-partition even? '(2 4 6) + '(2 4 6) '())) + + (pass-if "with empty list" + (test-partition even? '() + '() '())) + + (pass-if "with reasonably long list" + ;; the old implementation from SRFI-1 reference implementation + ;; would signal a stack-overflow for a list of only 500 elements! + (call-with-values (lambda () + (partition even? + (make-list 10000 1))) + (lambda (even odd) + (and (= (length odd) 10000) + (= (length even) 0)))))) + Index: srfi/srfi-1.c =================================================================== RCS file: /cvs/guile/guile-core/srfi/srfi-1.c,v retrieving revision 1.6 diff -u -c -r1.6 srfi-1.c *** srfi/srfi-1.c 21 Apr 2003 01:59:57 -0000 1.6 --- srfi/srfi-1.c 19 Jun 2003 15:52:41 -0000 *************** *** 319,324 **** --- 319,364 ---- } #undef FUNC_NAME + SCM_DEFINE (scm_srfi1_partition, "partition", 2, 0, 0, + (SCM pred, SCM list), + "Partition the elements of @var{list} with predicate @var{pred}.\n" + "Return two values: the list of elements satifying @var{pred} and\n" + "the list of elements @emph{not} satisfying @var{pred}. The order\n" + "of the output lists follows the order of @var{list}. @var{list}\n" + "is not mutated. One of the output lists may share memory with @var{list}.\n") + #define FUNC_NAME s_scm_srfi1_partition + { + /* In this implementation, the output lists don't share memory with + list, because it's probably not worth the effort. */ + scm_t_trampoline_1 call = scm_trampoline_1(pred); + SCM kept = scm_cons(SCM_EOL, SCM_EOL); + SCM kept_tail = kept; + SCM dropped = scm_cons(SCM_EOL, SCM_EOL); + SCM dropped_tail = dropped; + + SCM_ASSERT(call, pred, 2, FUNC_NAME); + + for (; !SCM_NULL_OR_NIL_P (list); list = SCM_CDR(list)) { + SCM elt = SCM_CAR(list); + SCM new_tail = scm_cons(SCM_CAR(list), SCM_EOL); + if (SCM_NFALSEP(call(pred, elt))) { + SCM_SETCDR(kept_tail, new_tail); + kept_tail = new_tail; + } + else { + SCM_SETCDR(dropped_tail, new_tail); + dropped_tail = new_tail; + } + } + /* re-use the initial conses for the values list */ + SCM_SETCAR(kept, SCM_CDR(kept)); + SCM_SETCDR(kept, dropped); + SCM_SETCAR(dropped, SCM_CDR(dropped)); + SCM_SETCDR(dropped, SCM_EOL); + return scm_values(kept); + } + #undef FUNC_NAME + void scm_init_srfi_1 (void) { Index: srfi/srfi-1.scm =================================================================== RCS file: /cvs/guile/guile-core/srfi/srfi-1.scm,v retrieving revision 1.24 diff -u -c -r1.24 srfi-1.scm *** srfi/srfi-1.scm 12 May 2003 23:02:01 -0000 1.24 --- srfi/srfi-1.scm 19 Jun 2003 15:52:41 -0000 *************** *** 662,676 **** ;;; Filtering & partitioning - (define (partition pred list) - (if (null? list) - (values '() '()) - (if (pred (car list)) - (receive (in out) (partition pred (cdr list)) - (values (cons (car list) in) out)) - (receive (in out) (partition pred (cdr list)) - (values in (cons (car list) out)))))) - (define (remove pred list) (filter (lambda (x) (not (pred x))) list)) --- 662,667 ---- -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Thu Jun 19 16:17:04 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19T5oW-0004lQ-Rc for mharc-guile-devel@gnu.org; Thu, 19 Jun 2003 16:15:20 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19T5oG-0004D0-TT for guile-devel@gnu.org; Thu, 19 Jun 2003 16:15:04 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19T5nr-0003Ni-Tz for guile-devel@gnu.org; Thu, 19 Jun 2003 16:14:40 -0400 Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19T5kX-0001QN-NW for guile-devel@gnu.org; Thu, 19 Jun 2003 16:11:13 -0400 Received: from dialin.speedway43.dip48.dokom.de ([195.138.43.48] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19T5kl-0003E9-00 for guile-devel@gnu.org; Thu, 19 Jun 2003 22:11:27 +0200 Received: (qmail 8680 invoked by uid 1000); 19 Jun 2003 20:09:47 -0000 To: Matthias Koeppe References: From: Marius Vollmer Date: 19 Jun 2003 22:09:46 +0200 In-Reply-To: Message-ID: <87r85plth1.fsf@zagadka.ping.de> Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: [Patch] Only use -Werror with gcc X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 19 Jun 2003 20:15:18 -0000 Matthias Koeppe writes: > Here is a patch. Applied, thanks! -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 From MAILER-DAEMON Fri Jun 20 19:58:00 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19TVl6-0006W1-Po for mharc-guile-devel@gnu.org; Fri, 20 Jun 2003 19:57:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19TVkq-0005zY-TB for guile-devel@gnu.org; Fri, 20 Jun 2003 19:57:16 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19TVkj-0005iy-EA for guile-devel@gnu.org; Fri, 20 Jun 2003 19:57:10 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19TVkg-0005RG-HL for guile-devel@gnu.org; Fri, 20 Jun 2003 19:57:06 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5KNv3Yd002532 for ; Sat, 21 Jun 2003 09:57:04 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5KNv3Qg004705 for ; Sat, 21 Jun 2003 09:57:03 +1000 (EST) Received: from localhost (ppp78.dyn228.pacific.net.au [203.143.228.78]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5KNv1nh007668 for ; Sat, 21 Jun 2003 09:57:02 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TVkW-0000ws-00; Sat, 21 Jun 2003 09:56:56 +1000 To: guile-devel@gnu.org References: <87isrtmhfw.fsf@zip.com.au> <87he79ic44.fsf@zagadka.ping.de> <87isri25yr.fsf@zip.com.au> <87isr30z9r.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sat, 21 Jun 2003 09:56:56 +1000 Message-ID: <87isr0ti9j.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: while break and continue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 20 Jun 2003 23:57:31 -0000 Marius Vollmer writes: > > What usage are you worried about? Only the sort of thing you can imagine. Eg. with the current "while", (let ((not 1) (sensible 2)) (while (< sensible 4) (set sensible (+ sensible not)))) gives ERROR: Wrong type to apply: 1 > Yes, definitely. That's what (ice-9 syncase) is for... Yep. I guess it's a bit big and ugly to drag into boot-9.scm though. From MAILER-DAEMON Fri Jun 20 20:14:08 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19TW0a-0002VZ-Jo for mharc-guile-devel@gnu.org; Fri, 20 Jun 2003 20:13:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19TW0Q-0001q4-T9 for guile-devel@gnu.org; Fri, 20 Jun 2003 20:13:22 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19TW0G-00018n-6F for guile-devel@gnu.org; Fri, 20 Jun 2003 20:13:13 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19TVzy-0000PY-J2 for guile-devel@gnu.org; Fri, 20 Jun 2003 20:12:54 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5L0CnYd005135 for ; Sat, 21 Jun 2003 10:12:49 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5L0CnQg006553 for ; Sat, 21 Jun 2003 10:12:49 +1000 (EST) Received: from localhost (ppp78.dyn228.pacific.net.au [203.143.228.78]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5L0Cmnh018630 for ; Sat, 21 Jun 2003 10:12:49 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TVwd-0000yW-00; Sat, 21 Jun 2003 10:09:27 +1000 To: guile-devel@gnu.org References: <873cigm79k.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Sat, 21 Jun 2003 10:09:26 +1000 In-Reply-To: <873cigm79k.fsf@zip.com.au> (Kevin Ryde's message of "Thu, 12 Jun 2003 11:09:11 +1000") Message-ID: <87d6h8thop.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: c99 number funcs X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 21 Jun 2003 00:13:28 -0000 I made this change. I realized though I had the c99 "round" function doesn't do what's desired, so I left scm_round etc alone. From MAILER-DAEMON Fri Jun 20 21:20:53 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19TX3i-0007AR-JO for mharc-guile-devel@gnu.org; Fri, 20 Jun 2003 21:20:50 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19TX3T-00073x-Lo for guile-devel@gnu.org; Fri, 20 Jun 2003 21:20:35 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19TX3R-00072a-1B for guile-devel@gnu.org; Fri, 20 Jun 2003 21:20:33 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19TX3P-0006xj-Tm for guile-devel@gnu.org; Fri, 20 Jun 2003 21:20:32 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5L1KSYd019453; Sat, 21 Jun 2003 11:20:29 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5L1KSQg018018; Sat, 21 Jun 2003 11:20:28 +1000 (EST) Received: from localhost (ppp78.dyn228.pacific.net.au [203.143.228.78]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5L1KPnh009615; Sat, 21 Jun 2003 11:20:26 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TX3B-0006He-00; Sat, 21 Jun 2003 11:20:17 +1000 To: Matthias Koeppe References: From: Kevin Ryde Mail-Copies-To: never Date: Sat, 21 Jun 2003 11:20:16 +1000 In-Reply-To: (Matthias Koeppe's message of "Wed, 18 Jun 2003 08:25:47 +0200") Message-ID: <87isr0cjlb.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" cc: guile-devel@gnu.org Subject: Re: Portability bug with UINTPTR_MAX in Solaris/Forte X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 21 Jun 2003 01:20:37 -0000 --=-=-= Matthias Koeppe writes: > > On Solaris, there is a uintptr_t, and UINTPTR_MAX is also a defined > macro, but it expands to nothing. Literally nothing? Perhaps the change below would do the trick. Does the same apply to INTPTR_MAX? --=-=-= Content-Disposition: attachment; filename=tags.h.solaris-uintptr.diff --- tags.h.~1.103.~ 2003-06-12 10:58:55.000000000 +1000 +++ tags.h 2003-06-21 11:19:56.000000000 +1000 @@ -49,7 +49,9 @@ #define SCM_T_SIGNED_BITS_MIN LONG_MIN #endif -#if SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) +/* On solaris 7 and 8, Sun workshop cc has UINTPTR_MAX defined to empty. To + avoid uintptr_t in this case we require UINTPTR_MAX-0 != 0. */ +#if SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) && UINTPTR_MAX-0 != 0 typedef uintptr_t scm_t_bits; #define SIZEOF_SCM_T_BITS SCM_SIZEOF_UINTPTR_T #define SCM_T_BITS_MAX UINTPTR_MAX --=-=-=-- From MAILER-DAEMON Fri Jun 20 21:31:00 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19TXDY-000751-I9 for mharc-guile-devel@gnu.org; Fri, 20 Jun 2003 21:31:00 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19TXDV-00074t-Mk for guile-devel@gnu.org; Fri, 20 Jun 2003 21:30:57 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19TXDU-00074T-DZ for guile-devel@gnu.org; Fri, 20 Jun 2003 21:30:56 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19TXDT-00072x-JA for guile-devel@gnu.org; Fri, 20 Jun 2003 21:30:55 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5L1UsYd022392; Sat, 21 Jun 2003 11:30:54 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5L1UmQg020461; Sat, 21 Jun 2003 11:30:48 +1000 (EST) Received: from localhost (ppp78.dyn228.pacific.net.au [203.143.228.78]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5L1Ulnh018455; Sat, 21 Jun 2003 11:30:47 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TXDG-0006Hr-00; Sat, 21 Jun 2003 11:30:42 +1000 To: Matthias Koeppe References: From: Kevin Ryde Mail-Copies-To: never Date: Sat, 21 Jun 2003 11:30:42 +1000 In-Reply-To: (Matthias Koeppe's message of "Thu, 19 Jun 2003 14:51:55 +0200") Message-ID: <87el1ocj3x.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: [Patch] inline.h should not define inline functions with "extern" linkage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 21 Jun 2003 01:30:58 -0000 Matthias Koeppe writes: > > The "inline" keyword does not imply static linkage, and in fact > inline.h defines the functions `scm_cell' and `scm_double_cell' > explicitly with "extern" linkage. "extern inline" is a gcc-ism, as far as I'm aware. We use it in gmp.h, but only with gcc. > The patch below fixes it. inline.c defines the functions with > external linkage, and every file including inline.h defines static > inline copies. One possibility would be to do these things as macros, so as to avoid depending on the compiler having an inline, or whether it only actually inlines at certain optimization levels. You can imagine the sort of thing, setting a variable given to the macro, rather than a return value, #define SCM_I_MKBIG(big) do { SCM __scm_i_mkbig__temp = scm_double_cell (scm_tc16_big, 0, 0, 0); mpz_init (SCM_I_BIG_MPZ (__scm_i_mkbig__temp)); (big) = __scm_i_mkbig__temp; } while (0) From MAILER-DAEMON Sat Jun 21 19:03:01 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19TrNs-0004gA-SV for mharc-guile-devel@gnu.org; Sat, 21 Jun 2003 19:03:00 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19TrNq-0004d1-Ho for guile-devel@gnu.org; Sat, 21 Jun 2003 19:02:58 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19TrNp-0004cq-4P for guile-devel@gnu.org; Sat, 21 Jun 2003 19:02:57 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19TrNo-0004Z7-Bh for guile-devel@gnu.org; Sat, 21 Jun 2003 19:02:56 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5LN2rYd017239 for ; Sun, 22 Jun 2003 09:02:53 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5LN2rQg001274 for ; Sun, 22 Jun 2003 09:02:53 +1000 (EST) Received: from localhost (ppp116.dyn228.pacific.net.au [203.143.228.116]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5LN2pnh000997 for ; Sun, 22 Jun 2003 09:02:52 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TrNe-0003nF-00; Sun, 22 Jun 2003 09:02:46 +1000 To: guile-devel@gnu.org References: <87wugjhowm.fsf@zip.com.au> <87wugjqx1g.fsf@raven.i.defaultvalue.org> <87r86rqa6m.fsf@raven.i.defaultvalue.org> <87vfw1i1jq.fsf@zip.com.au> <87add5mh91.fsf@zip.com.au> <87isrpjx0a.fsf@zagadka.ping.de> <877k7snrg5.fsf@zip.com.au> <87adcf0xhx.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sun, 22 Jun 2003 09:02:46 +1000 In-Reply-To: <87adcf0xhx.fsf@zagadka.ping.de> (Marius Vollmer's message of "19 Jun 2003 01:36:10 +0200") Message-ID: <87of0rm3u1.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: doco scm_remember_upto_1 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 21 Jun 2003 23:02:59 -0000 Marius Vollmer writes: > > Don't say "memory allocation function", that is too specific. Ah, good. I changed to "guile library function". > The "doubt" would come when one isn't sure whether a libguile function > is being called because one doesn't know what kind of stuff third > party functions do. Right. I hope "calling a Guile library function or doing something that might" can cover that. From MAILER-DAEMON Sat Jun 21 19:28:46 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Trmo-0006NP-Ce for mharc-guile-devel@gnu.org; Sat, 21 Jun 2003 19:28:46 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Trml-0006Gy-K7 for guile-devel@gnu.org; Sat, 21 Jun 2003 19:28:43 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Trmj-0006DT-7t for guile-devel@gnu.org; Sat, 21 Jun 2003 19:28:41 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Trmi-000688-BN for guile-devel@gnu.org; Sat, 21 Jun 2003 19:28:40 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5LNSaYd022123 for ; Sun, 22 Jun 2003 09:28:36 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5LNSaQg005389 for ; Sun, 22 Jun 2003 09:28:36 +1000 (EST) Received: from localhost (ppp116.dyn228.pacific.net.au [203.143.228.116]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5LNSYnh014578 for ; Sun, 22 Jun 2003 09:28:34 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TrmV-0003pj-00; Sun, 22 Jun 2003 09:28:27 +1000 To: guile-devel@gnu.org References: <87isrtmhfw.fsf@zip.com.au> <87he79ic44.fsf@zagadka.ping.de> <878yshe1ux.fsf@zip.com.au> <87n0gf0zbc.fsf@zagadka.ping.de> From: Kevin Ryde Mail-Copies-To: never Date: Sun, 22 Jun 2003 09:28:26 +1000 In-Reply-To: <87n0gf0zbc.fsf@zagadka.ping.de> (Marius Vollmer's message of "19 Jun 2003 00:56:55 +0200") Message-ID: <87fzm3m2n9.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: while break and continue X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 21 Jun 2003 23:28:44 -0000 Marius Vollmer writes: > > Discourage the use of 'while' or merely 'continue' and 'break'? Oh, well, continue and break I guess. > I > think, pointing in the docs of 'while' to 'do' and the other ways of > doing loops in Scheme would be good. Might have a go at more in the introductory para of the "while do" node. > I think the value of a while loop is ill-specified anyway and we > should always return unspecified. What should be returned when the > condition becomes false? Your macro arranges to return #t, wich seems > arbitrary. I think I return unspecified, since there's no final value expr in the "do" loop. I'll make sure that's the case though. > People who want their loop to return a specific value > should use 'do', named 'let', or some other mechanism, I'd say. As long as no-one has peeked at boot-9.scm and used break with a value. Would seem unlikely, but could perhaps make it optional, for maximum compatibility. I suppose a radical alternative would be to drop break and continue completely, having never been documented (and continue not really working). I simplified my code, per below. The theory is to have only one catch, for efficiency, and to have an inner "do" loop so that if break and continue are not used then the catch isn't re-established on each iteration. (define-macro (while cond . body) (let ((key (make-symbol "while-key"))) `(do ((break (lambda () (throw ',key #t))) (continue (lambda () (throw ',key #f)))) ((catch ',key (lambda () (do () ((not ,cond)) ,@body) #t) (lambda (key arg) arg)))))) From MAILER-DAEMON Sat Jun 21 20:20:17 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Tsaf-0007Dr-2M for mharc-guile-devel@gnu.org; Sat, 21 Jun 2003 20:20:17 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Tsab-00075N-59 for guile-devel@gnu.org; Sat, 21 Jun 2003 20:20:13 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19TsYS-0005dz-V0 for guile-devel@gnu.org; Sat, 21 Jun 2003 20:18:08 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19TsYO-0005Ff-85 for guile-devel@gnu.org; Sat, 21 Jun 2003 20:17:56 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5M0HqYd031863 for ; Sun, 22 Jun 2003 10:17:52 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5M0HqQg014037 for ; Sun, 22 Jun 2003 10:17:52 +1000 (EST) Received: from localhost (ppp116.dyn228.pacific.net.au [203.143.228.116]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5M0Hlnh013405 for ; Sun, 22 Jun 2003 10:17:50 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TsY4-0003wj-00; Sun, 22 Jun 2003 10:17:36 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Sun, 22 Jun 2003 10:17:36 +1000 Message-ID: <87y8zvklsv.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: srfi-1 delete and delete! X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 22 Jun 2003 00:20:15 -0000 This is new srfi-1 delete and delete!, as threatened. They avoid the non-tail-recursions in the current code, and delete saves consing by tail sharing, as the spec allows. For the two-arg case the plain core delete/delete! is called, so there's no loss of efficiency when using the srfi-1 module. The current core delete doesn't do tail sharing, I wonder if that's something it (and friends) could get. Code and test cases below, for contemplation. delete! is a warmed over copy of the core code, delete is new. SCM_DEFINE (scm_srfi1_delete, "delete", 2, 1, 0, (SCM x, SCM lst, SCM pred), "Return a list containing the elements of @var{lst} but with\n" "those equal to @var{x} deleted. The returned elements will be\n" "in the same order as they were in @var{lst}.\n" "\n" "Equality is determined by @var{pred}, or @code{equal?} if not\n" "given. An equality call is made just once for each element,\n" "but the order in which the calls are made on the elements is\n" "unspecified.\n" "\n" "The equality calls are always @code{(pred x elem)}, ie.@: the\n" "given @var{x} is first. This means for instance elements\n" "greater than 5 can be deleted with @code{(delete 5 lst <)}.\n" "\n" "@var{lst} is not modified, but the returned list might share a\n" "common tail with @var{lst}.") #define FUNC_NAME s_scm_srfi1_delete { scm_t_trampoline_2 equal_p; SCM ret, *p, keeplst; if (SCM_UNBNDP (pred)) return scm_delete (x, lst); equal_p = scm_trampoline_2 (pred); SCM_ASSERT (equal_p, pred, SCM_ARG3, FUNC_NAME); /* ret is the return list being constructed. p is where to append to it, initially &ret then the SCM_CDRLOC of the last pair. lst progresses as elements are considered. Elements to be retained are not immediately copied, instead keeplst is the last pair in lst which is to be retained but not yet copied. When there's no more deletions, *p can be set to keeplst to share the remainder of the original lst. (The entire original lst if there's no deletions at all.) */ keeplst = lst; ret = SCM_EOL; p = &ret; for ( ; SCM_CONSP (lst); lst = SCM_CDR (lst)) { if (! SCM_FALSEP (equal_p (pred, x, SCM_CAR (lst)))) { /* delete this element, so copy from keeplst (inclusive) to lst (exclusive) onto ret */ while (keeplst != lst) { SCM c = scm_cons (SCM_CAR (keeplst), SCM_EOL); *p = c; p = SCM_CDRLOC (c); keeplst = SCM_CDR (keeplst); } keeplst = SCM_CDR (lst); } } /* final retained elements */ *p = keeplst; /* demand that lst was a proper list */ SCM_ASSERT_TYPE (SCM_NULL_OR_NIL_P (lst), lst, SCM_ARG2, FUNC_NAME, "list"); return ret; } #undef FUNC_NAME SCM_DEFINE (scm_srfi1_delete_x, "delete!", 2, 1, 0, (SCM x, SCM lst, SCM pred), "Return a list containing the elements of @var{lst} but with\n" "those equal to @var{x} deleted. The returned elements will be\n" "in the same order as they were in @var{lst}.\n" "\n" "Equality is determined by @var{pred}, or @code{equal?} if not\n" "given. An equality call is made just once for each element,\n" "but the order in which the calls are made on the elements is\n" "unspecified.\n" "\n" "The equality calls are always @code{(pred x elem)}, ie.@: the\n" "given @var{x} is first. This means for instance elements\n" "greater than 5 can be deleted with @code{(delete 5 lst <)}.\n" "\n" "@var{lst} may be modified to construct the returned list.") #define FUNC_NAME s_scm_srfi1_delete_x { scm_t_trampoline_2 equal_p; SCM walk; SCM *prev; if (SCM_UNBNDP (pred)) return scm_delete_x (x, lst); equal_p = scm_trampoline_2 (pred); SCM_ASSERT (equal_p, pred, SCM_ARG3, FUNC_NAME); for (prev = &lst, walk = lst; SCM_CONSP (walk); walk = SCM_CDR (walk)) { if (! SCM_FALSEP (equal_p (pred, x, SCM_CAR (walk)))) *prev = SCM_CDR (walk); else prev = SCM_CDRLOC (walk); } /* demand the input was a proper list */ SCM_ASSERT_TYPE (SCM_NULL_OR_NIL_P (walk), walk, SCM_ARG2, FUNC_NAME, "list"); return lst; } #undef FUNC_NAME (define (ref-delete x lst . proc) "Reference implemenation of srfi-1 `delete'." (set! proc (if (null? proc) equal? (car proc))) (do ((ret '()) (lst lst (cdr lst))) ((null? lst) (reverse! ret)) (if (not (proc x (car lst))) (set! ret (cons (car lst) ret))))) ;; ;; delete and delete! ;; (let () ;; Call (PROC lst) for all lists of length up to 6, with all combinations ;; of elements to be retained (numbers 0 upwards) or deleted (#f). (define (test-lists proc) (do ((n 0 (1+ n))) ((>= n 6)) (do ((limit (ash 1 n)) (i 0 (1+ i))) ((>= i limit)) (let ((lst '())) (do ((bit 0 (1+ bit))) ((>= bit n)) (set! lst (cons (if (logbit? bit i) bit #f) lst))) (proc lst))))) (define (common-tests delete-proc) (pass-if-exception "too few args" exception:wrong-num-args (delete-proc 0)) (pass-if-exception "too many args" exception:wrong-num-args (delete-proc 0 '() equal? 99)) (pass-if "empty" (eq? '() (delete-proc 0 '()))) (pass-if "equal? (default)" (equal? '((1) (3)) (delete-proc '(2) '((1) (2) (3))))) (pass-if "eq?" (equal? '((1) (2) (3)) (delete-proc '(2) '((1) (2) (3)) eq?))) (pass-if "called arg order" (equal? '(1 2 3) (delete-proc 3 '(1 2 3 4 5) <)))) (with-test-prefix "delete" (common-tests delete) (test-lists (lambda (lst) (let ((lst-copy (list-copy lst))) (with-test-prefix lst-copy (pass-if "result" (equal? (delete #f lst) (ref-delete #f lst))) (pass-if "non-destructive" (equal? lst-copy lst))))))) (with-test-prefix "delete!" (common-tests delete!) (test-lists (lambda (lst) (pass-if lst (equal? (delete! #f lst) (ref-delete #f lst))))))) From MAILER-DAEMON Sat Jun 21 20:24:13 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19TseR-00025Y-5j for mharc-guile-devel@gnu.org; Sat, 21 Jun 2003 20:24:11 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Tse4-0001OI-2w for guile-devel@gnu.org; Sat, 21 Jun 2003 20:23:48 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Tse0-0001GE-By for guile-devel@gnu.org; Sat, 21 Jun 2003 20:23:45 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19TsdV-0000cU-GR for guile-devel@gnu.org; Sat, 21 Jun 2003 20:23:13 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5M0NBYd000647 for ; Sun, 22 Jun 2003 10:23:11 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5M0NBQg015162 for ; Sun, 22 Jun 2003 10:23:11 +1000 (EST) Received: from localhost (ppp116.dyn228.pacific.net.au [203.143.228.116]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5M0N7nh016804 for ; Sun, 22 Jun 2003 10:23:09 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19TsdJ-0003wu-00; Sun, 22 Jun 2003 10:23:01 +1000 To: guile-devel@gnu.org From: Kevin Ryde Mail-Copies-To: never Date: Sun, 22 Jun 2003 10:23:01 +1000 Message-ID: <87u1ajklju.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: srfi-1 delete-duplicates X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 22 Jun 2003 00:24:01 -0000 This is new delete-duplicates and delete-duplicates!, avoiding the non-tail-recursions of the current implementations. Code and test cases below for contemplation. The loops are a bit hairy, but seem to run ok. I'm intending to give them a bit more of a think before actually checking them in. SCM_DEFINE (scm_srfi1_delete_duplicates, "delete-duplicates", 1, 1, 0, (SCM lst, SCM pred), "Return a list containing the elements of @var{lst} but without\n" "duplicates.\n" "\n" "When elements are equal, only the first in @var{lst} is\n" "retained. Equal elements can be anywhere in @var{lst}, they\n" "don't have to be adjacent. The returned list will have the\n" "retained elements in the same order as they were in @var{lst}.\n" "\n" "Equality is determined by @var{pred}, or @code{equal?} if not\n" "given. Calls @code{(pred x y)} are made with element @var{x}\n" "being before @var{y} in @var{lst}. A call is made at most once\n" "for each combination, but the sequence of the calls across the\n" "elements is unspecified.\n" "\n" "@var{lst} is not modified, but the return might share a common\n" "tail with @var{lst}.\n" "\n" "In the worst case, this is an @math{O(N^2)} algorithm because\n" "it must check each element against all those preceding it. For\n" "long lists it is more efficient to sort and then compare only\n" "adjacent elements.") #define FUNC_NAME s_scm_srfi1_delete_duplicates { scm_t_trampoline_2 equal_p; SCM ret, *p, keeplst, item, l; /* skip to end if an empty list (or something invalid) */ ret = lst; if (SCM_CONSP (lst)) { if (SCM_UNBNDP (pred)) equal_p = equal_trampoline; else { equal_p = scm_trampoline_2 (pred); SCM_ASSERT (equal_p, pred, SCM_ARG2, FUNC_NAME); } /* ret is the new list constructed. p is where to append, initially &ret then SCM_CDRLOC of the last pair. lst is advanced as each element is considered. Elements retained are not immediately appended to ret, instead keeplst is the last pair in lst which is to be kept but is not yet copied. Initially this is the first pair of lst, since the first is always retained. *p is kept set to keeplst, so ret (inclusive) to lst (exclusive) is all the elements retained, making the equality search easy. If an item must be deleted, elements from keeplst (inclusive) to lst (exclusive) must be copied and appended to ret. When there's no more deletions, *p is left set to keeplst, so ret shares structure with the original lst. (ret will be the entire original lst if there's no deletions.) */ keeplst = lst; p = &ret; /* loop over lst elements starting from second */ for (;;) { lst = SCM_CDR (lst); if (! SCM_CONSP (lst)) break; item = SCM_CAR (lst); /* loop searching ret upto lst */ for (l = ret; l != lst; l = SCM_CDR (l)) { if (SCM_NFALSEP (equal_p (pred, SCM_CAR (l), item))) { /* duplicate, don't want this element, so copy keeplst (inclusive) to lst (exclusive) onto ret */ while (keeplst != lst) { SCM c = scm_cons (SCM_CAR (keeplst), SCM_EOL); *p = c; p = SCM_CDRLOC (c); keeplst = SCM_CDR (keeplst); } keeplst = SCM_CDR (keeplst); *p = keeplst; break; } } } } /* demand that lst was a proper list */ SCM_ASSERT_TYPE (SCM_NULL_OR_NIL_P (lst), lst, SCM_ARG1, FUNC_NAME, "list"); return ret; } #undef FUNC_NAME SCM_DEFINE (scm_srfi1_delete_duplicates_x, "delete-duplicates!", 1, 1, 0, (SCM lst, SCM pred), "Return a list containing the elements of @var{lst} but without\n" "duplicates.\n" "\n" "When elements are equal, only the first in @var{lst} is\n" "retained. Equal elements can be anywhere in @var{lst}, they\n" "don't have to be adjacent. The returned list will have the\n" "retained elements in the same order as they were in @var{lst}.\n" "\n" "Equality is determined by @var{pred}, or @code{equal?} if not\n" "given. Calls @code{(pred x y)} are made with element @var{x}\n" "being before @var{y} in @var{lst}. A call is made at most once\n" "for each combination, but the sequence of the calls across the\n" "elements is unspecified.\n" "\n" "@var{lst} may be modified to construct the returned list.\n" "\n" "In the worst case, this is an @math{O(N^2)} algorithm because\n" "it must check each element against all those preceding it. For\n" "long lists it is more efficient to sort and then compare only\n" "adjacent elements.") #define FUNC_NAME s_scm_srfi1_delete_duplicates_x { scm_t_trampoline_2 equal_p; SCM ret, endret, item, l; /* skip to end if an empty list (or something invalid) */ ret = lst; if (SCM_CONSP (lst)) { if (SCM_UNBNDP (pred)) equal_p = equal_trampoline; else { equal_p = scm_trampoline_2 (pred); SCM_ASSERT (equal_p, pred, SCM_ARG2, FUNC_NAME); } /* ret is the return list, constructed from the pairs of lst. endret is the last pair of ret, initially the first. lst is advanced as elements are considered. */ endret = ret; for (;;) { lst = SCM_CDR (lst); if (! SCM_CONSP (lst)) break; /* is item equal to any element from ret to endret (inclusive)? */ item = SCM_CAR (lst); l = ret; for (;;) { if (SCM_NFALSEP (equal_p (pred, SCM_CAR (l), item))) break; /* equal, forget this element */ if (l == endret) { /* not equal to any, so append this pair */ * SCM_CDRLOC (endret) = lst; endret = lst; break; } l = SCM_CDR (l); } } /* terminate, in case last element was deleted */ * SCM_CDRLOC (endret) = SCM_EOL; } /* demand that lst was a proper list */ SCM_ASSERT_TYPE (SCM_NULL_OR_NIL_P (lst), lst, SCM_ARG1, FUNC_NAME, "list"); return ret; } #undef FUNC_NAME (define (ref-delete-duplicates lst . proc) "Reference version of srfi-1 `delete-duplicates'." (set! proc (if (null? proc) equal? (car proc))) (if (null? lst) '() (do ((keep '())) ((null? lst) (reverse! keep)) (set! keep (cons (car lst) keep)) (set! lst (ref-delete (car lst) lst proc))))) ;; ;; delete-duplicates and delete-duplicates! ;; (let () ;; Call (PROC lst) for all lists of length n <= 4, with all combinations ;; of numbers 1 to n in the elements (define (test-lists proc) (do ((n 1 (1+ n))) ((> n 4)) (do ((limit (integer-expt n n)) (i 0 (1+ i))) ((>= i limit)) (let ((lst '())) (do ((j 0 (1+ j)) (rem i (quotient rem n))) ((>= j n)) (set! lst (cons (remainder rem n) lst))) (proc lst))))) (define (common-tests delete-duplicates-proc) (pass-if-exception "too few args" exception:wrong-num-args (delete-duplicates-proc)) (pass-if-exception "too many args" exception:wrong-num-args (delete-duplicates-proc '() equal? 99)) (pass-if "empty" (eq? '() (delete-duplicates-proc '()))) (pass-if "equal? (default)" (equal? '((2)) (delete-duplicates-proc '((2) (2) (2))))) (pass-if "eq?" (equal? '((2) (2) (2)) (delete-duplicates-proc '((2) (2) (2)) eq?))) (pass-if "called arg order" (let ((ok #t)) (delete-duplicates-proc '(1 2 3 4 5) (lambda (x y) (if (> x y) (set! ok #f)) #f)) ok))) (with-test-prefix "delete-duplicates" (common-tests delete-duplicates) (test-lists (lambda (lst) (let ((lst-copy (list-copy lst))) (with-test-prefix lst-copy (pass-if "result" (equal? (delete-duplicates lst) (ref-delete-duplicates lst))) (pass-if "non-destructive" (equal? lst-copy lst))))))) (with-test-prefix "delete-duplicates!" (common-tests delete-duplicates!) (test-lists (lambda (lst) (pass-if lst (equal? (delete-duplicates! lst) (ref-delete-duplicates lst))))))) From MAILER-DAEMON Mon Jun 23 04:42:04 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19UMt9-0003Rl-0q for mharc-guile-devel@gnu.org; Mon, 23 Jun 2003 04:41:23 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19UMt5-0003I2-LL for guile-devel@gnu.org; Mon, 23 Jun 2003 04:41:19 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19UMsz-0003BN-Hx for guile-devel@gnu.org; Mon, 23 Jun 2003 04:41:14 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19UMsW-0002uZ-Pf for guile-devel@gnu.org; Mon, 23 Jun 2003 04:40:44 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19UMsT-0005XY-00 for guile-devel@gnu.org; Mon, 23 Jun 2003 10:40:41 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5N8eeH20736; Mon, 23 Jun 2003 10:40:40 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org References: <87el1ocj3x.fsf@zip.com.au> From: Matthias Koeppe Date: Mon, 23 Jun 2003 10:40:40 +0200 In-Reply-To: <87el1ocj3x.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 21 Jun 2003 11:30:42 +1000") Message-ID: Lines: 46 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.3.50 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: Re: [Patch] inline.h should not define inline functions with "extern" linkage X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 23 Jun 2003 08:41:21 -0000 Kevin Ryde writes: > Matthias Koeppe writes: >> >> The "inline" keyword does not imply static linkage, and in fact >> inline.h defines the functions `scm_cell' and `scm_double_cell' >> explicitly with "extern" linkage. > > "extern inline" is a gcc-ism, as far as I'm aware. We use it in > gmp.h, but only with gcc. Yes. >> The patch below fixes it. inline.c defines the functions with >> external linkage, and every file including inline.h defines static >> inline copies. > > One possibility would be to do these things as macros, so as to avoid > depending on the compiler having an inline, or whether it only > actually inlines at certain optimization levels. > > You can imagine the sort of thing, setting a variable given to the > macro, rather than a return value, > > #define SCM_I_MKBIG(big) > do { > SCM __scm_i_mkbig__temp = scm_double_cell (scm_tc16_big, 0, 0, 0); > mpz_init (SCM_I_BIG_MPZ (__scm_i_mkbig__temp)); > (big) = __scm_i_mkbig__temp; > } while (0) CVS Guile uses a different method to deal with possibly inlined functions. inline.c defines ("extern", non-"inline") versions for use in user programs. If the C compiler recognizes an "inline" keyword, inline.h defines "inline" versions of the functions. However, there the gcc-ism of "extern inline" was used. My patch gets rid of this gcc-ism. This makes the compilation work with the Sun Forte compiler. I have adapted this approach to the inline functions in numbers.c. -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Mon Jun 23 05:15:56 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19UNQX-0005h4-Lr for mharc-guile-devel@gnu.org; Mon, 23 Jun 2003 05:15:53 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19UNQQ-0005OV-4l for guile-devel@gnu.org; Mon, 23 Jun 2003 05:15:46 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19UNQM-0005JU-Fl for guile-devel@gnu.org; Mon, 23 Jun 2003 05:15:43 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19UNQ8-0005CI-Tw for guile-devel@gnu.org; Mon, 23 Jun 2003 05:15:29 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19UNQ8-0005wY-00 for guile-devel@gnu.org; Mon, 23 Jun 2003 11:15:28 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5N9FRn21108; Mon, 23 Jun 2003 11:15:27 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org References: <87isr0cjlb.fsf@zip.com.au> From: Matthias Koeppe Date: Mon, 23 Jun 2003 11:15:27 +0200 In-Reply-To: <87isr0cjlb.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 21 Jun 2003 11:20:16 +1000") Message-ID: Lines: 45 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.3.50 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: Re: Portability bug with UINTPTR_MAX in Solaris/Forte X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 23 Jun 2003 09:15:51 -0000 Kevin Ryde writes: > Matthias Koeppe writes: >> >> On Solaris, there is a uintptr_t, and UINTPTR_MAX is also a defined >> macro, but it expands to nothing. > > Literally nothing? Perhaps the change below would do the trick. > Does the same apply to INTPTR_MAX? Thanks, your trick does the change. (I still think that tricky things like this should be checked at `configure' time, rather than during compilation, though.) The same does not apply to the signed version because INTPTR_MIN is not defined at all. I have updated your patch to check this anyway, for "completeness". --- tags.h.~1.103.~ Mon Jun 16 16:50:07 2003 +++ tags.h Mon Jun 23 11:13:09 2003 @@ -39,7 +39,11 @@ /* In the beginning was the Word: */ -#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) +/* On Solaris 7 and 8, /usr/include/sys/int_limits.h defines + INTPTR_MAX and UINTPTR_MAX to empty, INTPTR_MIN is not defined. + To avoid uintptr_t and intptr_t in this case we require + UINTPTR_MAX-0 != 0 etc. */ +#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) && INTPTR_MAX-0 != 0 && INTPTR_MIN-0 != 0 typedef intptr_t scm_t_signed_bits; #define SCM_T_SIGNED_BITS_MAX INTPTR_MAX #define SCM_T_SIGNED_BITS_MIN INTPTR_MIN @@ -49,7 +53,7 @@ #define SCM_T_SIGNED_BITS_MIN LONG_MIN #endif -#if SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) +#if SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) && UINTPTR_MAX-0 != 0 typedef uintptr_t scm_t_bits; #define SIZEOF_SCM_T_BITS SCM_SIZEOF_UINTPTR_T #define SCM_T_BITS_MAX UINTPTR_MAX -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Mon Jun 23 19:14:05 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19UaR2-0002by-H9 for mharc-guile-devel@gnu.org; Mon, 23 Jun 2003 19:09:16 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19UaPX-00025H-A8 for guile-devel@gnu.org; Mon, 23 Jun 2003 19:07:43 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19UaPM-0001rV-K4 for guile-devel@gnu.org; Mon, 23 Jun 2003 19:07:35 -0400 Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19UaNm-0001NG-Gh for guile-devel@gnu.org; Mon, 23 Jun 2003 19:05:54 -0400 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5NN5oYd015028; Tue, 24 Jun 2003 09:05:51 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5NN5oQg003038; Tue, 24 Jun 2003 09:05:50 +1000 (EST) Received: from localhost (ppp97.dyn228.pacific.net.au [203.143.228.97]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5NN5lnh024100; Tue, 24 Jun 2003 09:05:48 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19UaNT-0000WU-00; Tue, 24 Jun 2003 09:05:35 +1000 To: Matthias Koeppe References: <87isr0cjlb.fsf@zip.com.au> From: Kevin Ryde Mail-Copies-To: never Date: Tue, 24 Jun 2003 09:05:34 +1000 In-Reply-To: (Matthias Koeppe's message of "Mon, 23 Jun 2003 11:15:27 +0200") Message-ID: <87wufcqts1.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: guile-devel@gnu.org Subject: Re: Portability bug with UINTPTR_MAX in Solaris/Forte X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 23 Jun 2003 23:09:11 -0000 Matthias Koeppe writes: > > (I still think that tricky > things like this should be checked at `configure' time, rather than > during compilation, though.) Oh, well, no need to add to the configure script if a cpp conditional can do it cleanly and portably. > +/* On Solaris 7 and 8, /usr/include/sys/int_limits.h defines > + INTPTR_MAX and UINTPTR_MAX to empty, INTPTR_MIN is not defined. That's a typo there is it? Only UINTPTR_MAX defined to empty. > +#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) && INTPTR_MAX-0 != 0 && INTPTR_MIN-0 != 0 While you're at it you might like to merge the tests so scm_t_bits and scm_t_signed_bits are both based on "intptr" stuff, or both on "long", rather than having separate conditionals. Wouldn't want them to come out different. From MAILER-DAEMON Tue Jun 24 23:10:21 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19V0e6-0003H6-A9 for mharc-guile-devel@gnu.org; Tue, 24 Jun 2003 23:08:30 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19V0dp-0002eF-OS for guile-devel@gnu.org; Tue, 24 Jun 2003 23:08:13 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19V0dj-0002Sh-4e for guile-devel@gnu.org; Tue, 24 Jun 2003 23:08:07 -0400 Received: from obh.snafu.de ([213.73.92.34]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19V0di-0002I1-99 for guile-devel@gnu.org; Tue, 24 Jun 2003 23:08:06 -0400 Received: from p-164-211.zrz.tu-berlin.de ([130.149.164.211] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19V0db-000Fei-00; Wed, 25 Jun 2003 05:08:02 +0200 Received: from localhost ([127.0.0.1]) by bono with esmtp (Exim 3.36 #1) id 19V0Ut-00004C-00; Wed, 25 Jun 2003 04:58:59 +0200 Date: Wed, 25 Jun 2003 04:58:59 +0200 (CEST) From: stefan X-X-Sender: stefan@bono.reversers.net To: David Mosberger In-Reply-To: <15307.10445.674412.197780@napali.hpl.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: guile-devel@gnu.org cc: linux-ia64@linuxia64.org Subject: Guile garbage collector on ia64-linux X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 25 Jun 2003 03:08:29 -0000 Hello David, some time ago I was asking about the use of setcontext()/getcontext() on ia64-linux for porting the garbage collector of GNU Guile to ia64 and with your help I was able to write code something like this which initially worked fine for Guile. ========================================================================= /* This declares us ucontext_t but leaves setcontext()/getcontext() undeclared. */ #ifdef __ia64__ #include #include extern unsigned long * __libc_ia64_register_backing_store_base; #endif /* __ia64__ */ /* [ ... ] */ #ifdef __ia64__ /* Extern declaration of getcontext()/setcontext() in order to redefine getcontext() since on ia64-linux the second return value indicates whether it returned from getcontext() itself or by running setcontext(). */ struct rv { long retval; long first_return; }; extern struct rv getcontext (ucontext_t *); extern int setcontext (ucontext_t *); #endif /* __ia64__ */ #ifdef __ia64__ rv = getcontext (&continuation->ctx); if (rv.first_return) { continuation->backing_store_size = continuation->ctx.uc_mcontext.sc_ar_bsp - (unsigned long) __libc_ia64_register_backing_store_base; continuation->backing_store = NULL; continuation->backing_store = scm_gc_malloc (continuation->backing_store_size, "continuation backing store"); memcpy (continuation->backing_store, (void *) __libc_ia64_register_backing_store_base, continuation->backing_store_size); *first = 1; return cont; } else { SCM ret = continuation->throw_value; *first = 0; continuation->throw_value = SCM_BOOL_F; return ret; } #else /* !__ia64__ */ /* [ ... ] */ #endif /* !__ia64__ */ ========================================================================= This piece of code worked perfectly for us determining the location and size of the backing store of the machine. With newer installations this has changed and the code does not work anymore. I know you stated somewhere in the past the set of functions/structures has been introduced in glibc-2.2.3. I do not know exactly which version is current know. The problem we need to solve for the Guile garbage collection are as follows: * have some header where ucontext_t is declared but setcontext()/getcontext() is not -> so we can redeclare it to make getcontext() return the 'struct rv'. * determination of the size and location of the backing store; this has been previously achieved by: ctx.uc_mcontext.sc_ar_bsp -> the top __libc_ia64_register_backing_store_base -> the bottom Newer glibc headers don't have 'sc_ar_bsp', but things like 'ar_bsp_base' or 'ar_bspstore'. Can something in the structure ucontext_t be used to achieve the same? Will this change often in the future? Thanks in advance, stefan@lkcc.org PS: I also CC'ed this to guile-devel, because the issue is a debian bug for guile-1.6.4 and is still unresolved. From MAILER-DAEMON Wed Jun 25 05:35:27 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19V6gS-0001Wm-Jm for mharc-guile-devel@gnu.org; Wed, 25 Jun 2003 05:35:20 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19V6gA-0001Dh-DQ for guile-devel@gnu.org; Wed, 25 Jun 2003 05:35:02 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19V6fk-0000j0-AC for guile-devel@gnu.org; Wed, 25 Jun 2003 05:34:37 -0400 Received: from ns.suse.de ([213.95.15.193] helo=Cantor.suse.de) by monty-python.gnu.org with esmtp (Exim 4.20) id 19V6fY-0000Zb-Bn for guile-devel@gnu.org; Wed, 25 Jun 2003 05:34:24 -0400 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 1F25D15113; Wed, 25 Jun 2003 11:34:23 +0200 (MEST) To: stefan References: From: Andreas Schwab X-Yow: Now KEN is having a MENTAL CRISIS because his "R.V." PAYMENTS are OVER-DUE!! Date: Wed, 25 Jun 2003 11:34:22 +0200 In-Reply-To: (stefan@lkcc.org's message of "Wed, 25 Jun 2003 04:58:59 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: guile-devel@gnu.org cc: linux-ia64@linuxia64.org cc: David Mosberger Subject: Re: [Linux-ia64] Guile garbage collector on ia64-linux X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 25 Jun 2003 09:35:10 -0000 stefan writes: |> With newer installations this has changed and the code does not work |> anymore. I know you stated somewhere in the past the set of |> functions/structures has been introduced in glibc-2.2.3. I do not know |> exactly which version is current know. The problem we need to solve for |> the Guile garbage collection are as follows: |> |> * have some header where ucontext_t is declared but |> setcontext()/getcontext() is not -> so we can redeclare it to make |> getcontext() return the 'struct rv'. Alternatively you could name getcontext differently on the C level, but give it getcontext as the assembler name, like this: extern struct rv ia64_getcontext (ucontext_t *) __asm__ ("getcontext"); Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From MAILER-DAEMON Wed Jun 25 13:57:56 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19VEQV-0008IN-Iu for mharc-guile-devel@gnu.org; Wed, 25 Jun 2003 13:51:23 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19VEMh-0007Tb-VH for guile-devel@gnu.org; Wed, 25 Jun 2003 13:47:27 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19VED1-0004NH-K9 for guile-devel@gnu.org; Wed, 25 Jun 2003 13:37:30 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19VDc7-0002pY-KO for guile-devel@gnu.org; Wed, 25 Jun 2003 12:59:19 -0400 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel13.hp.com (Postfix) with ESMTP id E14FC1C00F51; Wed, 25 Jun 2003 09:58:17 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) h5PGwGeb025380; Wed, 25 Jun 2003 09:58:17 -0700 (PDT) Received: from napali.hpl.hp.com (localhost [127.0.0.1]) h5PGwGrK028846; Wed, 25 Jun 2003 09:58:16 -0700 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-5) id h5PGw7Bl028840; Wed, 25 Jun 2003 09:58:07 -0700 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16121.54431.794996.977946@napali.hpl.hp.com> Date: Wed, 25 Jun 2003 09:58:07 -0700 To: stefan In-Reply-To: References: <15307.10445.674412.197780@napali.hpl.hp.com> X-Mailer: VM 7.07 under Emacs 21.2.1 X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ cc: guile-devel@gnu.org cc: linux-ia64@linuxia64.org cc: David Mosberger Subject: Re: Guile garbage collector on ia64-linux X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list Reply-To: davidm@hpl.hp.com List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 25 Jun 2003 17:51:21 -0000 >>>>> On Wed, 25 Jun 2003 04:58:59 +0200 (CEST), stefan said: Stefan> * have some header where ucontext_t is declared but Stefan> setcontext()/getcontext() is not -> so we can redeclare it Stefan> to make getcontext() return the 'struct rv'. One way of achieving this is to do: #define getcontext hide_getcontext #include #undef getcontext Andreas suggested another method. Both have their ups and downs. Stefan> * determination of the size and location of the backing Stefan> store; this has been previously achieved by: Stefan> ctx.uc_mcontext.sc_ar_bsp -> the top Stefan> __libc_ia64_register_backing_store_base -> the bottom Newer Stefan> glibc headers don't have 'sc_ar_bsp', but things like Stefan> 'ar_bsp_base' or 'ar_bspstore'. Can something in the Stefan> structure ucontext_t be used to achieve the same? Will this Stefan> change often in the future? This doesn't sound right. There were no member-name changes "struct sigcontext". I just checked the current libc CVS tree and it has: struct sigcontext { : unsigned long int sc_ar_bsp; /* backing store pointer */ So I don't know why this isn't working for you. What distro are you using? --david From MAILER-DAEMON Wed Jun 25 15:03:44 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19VFUh-0002Gv-UV for mharc-guile-devel@gnu.org; Wed, 25 Jun 2003 14:59:47 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19VFNx-0000Zt-KI for guile-devel@gnu.org; Wed, 25 Jun 2003 14:52:49 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19VFDM-0005Ue-BL for guile-devel@gnu.org; Wed, 25 Jun 2003 14:41:52 -0400 Received: from obh.snafu.de ([213.73.92.34]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19VEfQ-000469-DB for guile-devel@gnu.org; Wed, 25 Jun 2003 14:06:48 -0400 Received: from p-164-156.zrz.tu-berlin.de ([130.149.164.156] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19VEfO-000Fdn-00; Wed, 25 Jun 2003 20:06:47 +0200 Received: from localhost ([127.0.0.1] ident=ela) by bono with esmtp (Exim 3.36 #1) id 19VEc0-00009b-00; Wed, 25 Jun 2003 20:03:16 +0200 Date: Wed, 25 Jun 2003 20:03:15 +0200 (CEST) From: stefan X-X-Sender: stefan@bono.reversers.net To: David Mosberger In-Reply-To: <16121.54431.794996.977946@napali.hpl.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: guile-devel@gnu.org cc: linux-ia64@linuxia64.org Subject: Re: Guile garbage collector on ia64-linux X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 25 Jun 2003 18:59:46 -0000 On Wed, 25 Jun 2003, David Mosberger wrote: > >>>>> On Wed, 25 Jun 2003 04:58:59 +0200 (CEST), stefan said: > > Stefan> * have some header where ucontext_t is declared but > Stefan> setcontext()/getcontext() is not -> so we can redeclare it > Stefan> to make getcontext() return the 'struct rv'. > > One way of achieving this is to do: > > #define getcontext hide_getcontext > #include > #undef getcontext > > Andreas suggested another method. Both have their ups and downs. > > Stefan> * determination of the size and location of the backing > Stefan> store; this has been previously achieved by: > Stefan> ctx.uc_mcontext.sc_ar_bsp -> the top > Stefan> __libc_ia64_register_backing_store_base -> the bottom Newer > Stefan> glibc headers don't have 'sc_ar_bsp', but things like > Stefan> 'ar_bsp_base' or 'ar_bspstore'. Can something in the > Stefan> structure ucontext_t be used to achieve the same? Will this > Stefan> change often in the future? > > This doesn't sound right. There were no member-name changes "struct > sigcontext". I just checked the current libc CVS tree and it has: > > struct sigcontext > { > : > unsigned long int sc_ar_bsp; /* backing store pointer */ > > So I don't know why this isn't working for you. What distro are you > using? I've been using the Compaq testdrive account 'SuSE Linux 7.2a (ia64) - Kernel 2.4.4-SMP (2)' ... looks like a glibc 2.2.2 Well may be too an old one. Thanks for the quick response, stefan@lkcc.org From MAILER-DAEMON Wed Jun 25 15:04:30 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19VFIu-0007Lr-Os for mharc-guile-devel@gnu.org; Wed, 25 Jun 2003 14:47:36 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19VFGE-0006ct-GI for guile-devel@gnu.org; Wed, 25 Jun 2003 14:44:50 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19VF4m-0003JH-AZ for guile-devel@gnu.org; Wed, 25 Jun 2003 14:33:02 -0400 Received: from obh.snafu.de ([213.73.92.34]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19VElO-000662-4w for guile-devel@gnu.org; Wed, 25 Jun 2003 14:12:58 -0400 Received: from p-164-156.zrz.tu-berlin.de ([130.149.164.156] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19VElG-000FnK-00 for guile-devel@gnu.org; Wed, 25 Jun 2003 20:12:55 +0200 Received: from localhost ([127.0.0.1] ident=ela) by bono with esmtp (Exim 3.36 #1) id 19VEfn-0000TZ-00 for guile-devel@gnu.org; Wed, 25 Jun 2003 20:07:12 +0200 Date: Wed, 25 Jun 2003 20:07:11 +0200 (CEST) From: stefan X-X-Sender: stefan@bono.reversers.net To: guile-devel@gnu.org In-Reply-To: <16121.54431.794996.977946@napali.hpl.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-150945042-1056564431=:594" Subject: Re: Guile garbage collector on ia64-linux X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 25 Jun 2003 18:47:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323584-150945042-1056564431=:594 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Jun 2003, David Mosberger wrote: > >>>>> On Wed, 25 Jun 2003 04:58:59 +0200 (CEST), stefan said: > > Stefan> * have some header where ucontext_t is declared but > Stefan> setcontext()/getcontext() is not -> so we can redeclare it > Stefan> to make getcontext() return the 'struct rv'. > > One way of achieving this is to do: > > #define getcontext hide_getcontext > #include > #undef getcontext > > Andreas suggested another method. Both have their ups and downs. > > Stefan> * determination of the size and location of the backing > Stefan> store; this has been previously achieved by: > Stefan> ctx.uc_mcontext.sc_ar_bsp -> the top > Stefan> __libc_ia64_register_backing_store_base -> the bottom Newer > Stefan> glibc headers don't have 'sc_ar_bsp', but things like > Stefan> 'ar_bsp_base' or 'ar_bspstore'. Can something in the > Stefan> structure ucontext_t be used to achieve the same? Will this > Stefan> change often in the future? > > This doesn't sound right. There were no member-name changes "struct > sigcontext". I just checked the current libc CVS tree and it has: > > struct sigcontext > { > : > unsigned long int sc_ar_bsp; /* backing store pointer */ Finally I applied a patch to CVS Guile. This should work now. Could please someone backport it (attached) to Guile 1.6.x recent? Then the Debian builders may succeed... Cheers, stefan@lkcc.org --8323584-150945042-1056564431=:594 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="g.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="g.diff" PyBnLmRpZmYNCkluZGV4OiBsaWJndWlsZS9jb250aW51YXRpb25zLmMNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvY3Zzcm9vdC9ndWls ZS9ndWlsZS9ndWlsZS1jb3JlL2xpYmd1aWxlL2NvbnRpbnVhdGlvbnMuYyx2 DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDkNCmRpZmYgLXUgLXIxLjQ5IGNv bnRpbnVhdGlvbnMuYw0KLS0tIGxpYmd1aWxlL2NvbnRpbnVhdGlvbnMuYwky MCBBcHIgMjAwMyAwNzoxOTozOCAtMDAwMAkxLjQ5DQorKysgbGliZ3VpbGUv Y29udGludWF0aW9ucy5jCTI1IEp1biAyMDAzIDE4OjA3OjEyIC0wMDAwDQpA QCAtOTcsOCArOTcsNyBAQA0KICAgbG9uZyByZXR2YWw7DQogICBsb25nIGZp cnN0X3JldHVybjsNCiB9Ow0KLWV4dGVybiBzdHJ1Y3QgcnYgZ2V0Y29udGV4 dCAodWNvbnRleHRfdCAqKTsNCi1leHRlcm4gaW50IHNldGNvbnRleHQgKHVj b250ZXh0X3QgKik7DQorZXh0ZXJuIHN0cnVjdCBydiBpYTY0X2dldGNvbnRl eHQgKHVjb250ZXh0X3QgKikgX19hc21fXyAoImdldGNvbnRleHQiKTsNCiAj ZW5kaWYgLyogX19pYTY0X18gKi8NCiANCiAvKiB0aGlzIG1heSByZXR1cm4g bW9yZSB0aGFuIG9uY2U6IHRoZSBmaXJzdCB0aW1lIHdpdGggdGhlIGVzY2Fw ZQ0KQEAgLTEzOCw3ICsxMzcsNyBAQA0KICAgbWVtY3B5IChjb250aW51YXRp b24tPnN0YWNrLCBzcmMsIHNpemVvZiAoU0NNX1NUQUNLSVRFTSkgKiBzdGFj a19zaXplKTsNCiANCiAjaWZkZWYgX19pYTY0X18NCi0gIHJ2ID0gZ2V0Y29u dGV4dCAoJmNvbnRpbnVhdGlvbi0+Y3R4KTsNCisgIHJ2ID0gaWE2NF9nZXRj b250ZXh0ICgmY29udGludWF0aW9uLT5jdHgpOw0KICAgaWYgKHJ2LmZpcnN0 X3JldHVybikNCiAgICAgew0KICAgICAgIGNvbnRpbnVhdGlvbi0+YmFja2lu Z19zdG9yZV9zaXplID0gDQpJbmRleDogbGliZ3VpbGUvY29udGludWF0aW9u cy5oDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2c3Jv b3QvZ3VpbGUvZ3VpbGUvZ3VpbGUtY29yZS9saWJndWlsZS9jb250aW51YXRp b25zLmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMwDQpkaWZmIC11IC1y MS4zMCBjb250aW51YXRpb25zLmgNCi0tLSBsaWJndWlsZS9jb250aW51YXRp b25zLmgJMjAgQXByIDIwMDMgMDc6MTk6MzggLTAwMDAJMS4zMA0KKysrIGxp Ymd1aWxlL2NvbnRpbnVhdGlvbnMuaAkyNSBKdW4gMjAwMyAxODowNzoxMiAt MDAwMA0KQEAgLTI2LDcgKzI2LDcgQEANCiANCiAjaWZkZWYgX19pYTY0X18N CiAjaW5jbHVkZSA8c2lnbmFsLmg+DQotI2luY2x1ZGUgPHN5cy91Y29udGV4 dC5oPg0KKyNpbmNsdWRlIDx1Y29udGV4dC5oPg0KIGV4dGVybiB1bnNpZ25l ZCBsb25nICogX19saWJjX2lhNjRfcmVnaXN0ZXJfYmFja2luZ19zdG9yZV9i YXNlOw0KICNlbmRpZiAvKiBfX2lhNjRfXyAqLw0KIAwNCg== --8323584-150945042-1056564431=:594-- From MAILER-DAEMON Wed Jun 25 15:08:29 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19VEYz-00028o-5E for mharc-guile-devel@gnu.org; Wed, 25 Jun 2003 14:00:09 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19VETx-0000Vn-Et for guile-devel@gnu.org; Wed, 25 Jun 2003 13:54:57 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19VDzx-0000l0-2O for guile-devel@gnu.org; Wed, 25 Jun 2003 13:23:59 -0400 Received: from gnuftp.gnu.org ([199.232.41.6]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19VD9D-0000WW-JS for guile-devel@gnu.org; Wed, 25 Jun 2003 12:29:27 -0400 Received: from merkur.math.uni-magdeburg.de ([141.44.75.40]) by gnuftp.gnu.org with esmtp (Exim 4.20) id 19VC6F-0001JE-6w for guile-devel@gnu.org; Wed, 25 Jun 2003 11:22:19 -0400 Received: from beta ([141.44.75.78] helo=beta.math.uni-magdeburg.de) by merkur.math.uni-magdeburg.de with esmtp (Exim 4.10) id 19VC1D-0006fc-00 for guile-devel@gnu.org; Wed, 25 Jun 2003 17:17:07 +0200 Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.11.7+Sun/8.11.7) id h5PFH6s21310; Wed, 25 Jun 2003 17:17:06 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f To: guile-devel@gnu.org References: <87isr0cjlb.fsf@zip.com.au> <87wufcqts1.fsf@zip.com.au> From: Matthias Koeppe Date: Wed, 25 Jun 2003 17:17:05 +0200 In-Reply-To: <87wufcqts1.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 24 Jun 2003 09:05:34 +1000") Message-ID: Lines: 73 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.3.50 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Warning: no 'abuse'-account in domain mail.math.uni-magdeburg.de (cf. RFC2142/4.) Subject: Re: Portability bug with UINTPTR_MAX in Solaris/Forte X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 25 Jun 2003 18:00:07 -0000 Kevin Ryde writes: > Matthias Koeppe writes: >> +/* On Solaris 7 and 8, /usr/include/sys/int_limits.h defines >> + INTPTR_MAX and UINTPTR_MAX to empty, INTPTR_MIN is not defined. > > That's a typo there is it? Only UINTPTR_MAX defined to empty. No, it's exactly as I wrote. From int_limits.h: | /* | * The following 2 macros are provided for testing whether the types | * intptr_t and uintptr_t (integers large enough to hold a void *) are | * defined in this header. They are needed in case the architecture can't | * represent a pointer in any standard integral type. | */ | #define INTPTR_MAX | #define UINTPTR_MAX >> +#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) && INTPTR_MAX-0 != 0 && INTPTR_MIN-0 != 0 > > While you're at it you might like to merge the tests so scm_t_bits and > scm_t_signed_bits are both based on "intptr" stuff, or both on "long", > rather than having separate conditionals. Wouldn't want them to come > out different. OK, here is an updated patch. Will you commit this change? (I don't have CVS write permissions.) --- tags.h.~1.103.~ Mon Jun 16 16:50:07 2003 +++ tags.h Wed Jun 25 16:51:10 2003 @@ -39,24 +39,30 @@ /* In the beginning was the Word: */ -#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) +/* On Solaris 7 and 8, /usr/include/sys/int_limits.h defines + INTPTR_MAX and UINTPTR_MAX to empty, INTPTR_MIN is not defined. + To avoid uintptr_t and intptr_t in this case we require + UINTPTR_MAX-0 != 0 etc. */ +#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) \ + && INTPTR_MAX-0 != 0 && INTPTR_MIN-0 != 0 \ + && SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) && UINTPTR_MAX-0 != 0 + typedef intptr_t scm_t_signed_bits; #define SCM_T_SIGNED_BITS_MAX INTPTR_MAX #define SCM_T_SIGNED_BITS_MIN INTPTR_MIN -#else -typedef signed long scm_t_signed_bits; -#define SCM_T_SIGNED_BITS_MAX LONG_MAX -#define SCM_T_SIGNED_BITS_MIN LONG_MIN -#endif - -#if SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) typedef uintptr_t scm_t_bits; #define SIZEOF_SCM_T_BITS SCM_SIZEOF_UINTPTR_T #define SCM_T_BITS_MAX UINTPTR_MAX + #else + +typedef signed long scm_t_signed_bits; +#define SCM_T_SIGNED_BITS_MAX LONG_MAX +#define SCM_T_SIGNED_BITS_MIN LONG_MIN typedef unsigned long scm_t_bits; #define SIZEOF_SCM_T_BITS SCM_SIZEOF_UNSIGNED_LONG #define SCM_T_BITS_MAX ULONG_MAX + #endif /* But as external interface, we use SCM, which may, according to the desired -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe From MAILER-DAEMON Thu Jun 26 07:56:37 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19VVKh-0006m2-Ip for mharc-guile-devel@gnu.org; Thu, 26 Jun 2003 07:54:31 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19VVDH-0004TY-Ch for guile-devel@gnu.org; Thu, 26 Jun 2003 07:46:51 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19VV1l-0001M6-8b for guile-devel@gnu.org; Thu, 26 Jun 2003 07:34:57 -0400 Received: from main.gmane.org ([80.91.224.249]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19VUxU-0008KO-TQ for guile-devel@gnu.org; Thu, 26 Jun 2003 07:30:33 -0400 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19VUxA-00030k-00 for ; Thu, 26 Jun 2003 13:30:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: guile-devel@gnu.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19VUhL-0001ox-00 for ; Thu, 26 Jun 2003 13:13:51 +0200 From: Clemens Fischer Date: Thu, 26 Jun 2003 11:42:43 +0200 Lines: 9 Message-ID: <4r2djht8.fsf@ID-23066.news.dfncis.de> References: <3ED8F446.12425825@veritas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (berkeley-unix) Cancel-Lock: sha1:K3TvnKoc08Gzj3vGRaSf1VXjvG4= Sender: news Subject: Re: What is the Guile 1.4 equivalent? X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 26 Jun 2003 11:54:30 -0000 * 2003-06-02 Thamer Al-Harbash: > Probably shouldn't bother. I know FreeBSD ships with guile-1.4 in > its ports package. must have been a while since you checked. the current ports version on freebsd is 1.6.4. clemens From MAILER-DAEMON Fri Jun 27 12:45:28 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19Vw6x-0004Zu-Ld for mharc-guile-devel@gnu.org; Fri, 27 Jun 2003 12:30:07 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Vw4m-0003aN-UV for guile-devel@gnu.org; Fri, 27 Jun 2003 12:27:52 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19VvdZ-0002r2-GC for guile-devel@gnu.org; Fri, 27 Jun 2003 11:59:46 -0400 Received: from multivac.student.cwru.edu ([129.22.114.26] helo=multivac.cwru.edu) by monty-python.gnu.org with smtp (Exim 4.20) id 19Vvcv-0002QR-9m for guile-devel@gnu.org; Fri, 27 Jun 2003 11:59:05 -0400 Received: (qmail 30444 invoked by uid 500); 27 Jun 2003 15:59:00 -0000 To: Marius Vollmer In-Reply-To: (Paul Jarc's message of "Mon, 19 May 2003 10:52:06 -0400") References: <87ade0zwwe.fsf@raven.i.defaultvalue.org> <87he7t5olk.fsf@zagadka.ping.de> From: prj@po.cwru.edu (Paul Jarc) Organization: What did you have in mind? A short, blunt, human pyramid? Mail-Copies-To: nobody Mail-Followup-To: Marius Vollmer , Rob Browning , guile-devel@gnu.org Date: Fri, 27 Jun 2003 11:58:37 -0400 Message-ID: Lines: 9 User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Rob Browning cc: guile-devel@gnu.org Subject: Re: libguile/print.c fixes X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 27 Jun 2003 16:30:05 -0000 I wrote: > I've also submitted my paperwork request. I'll post again when it's > done. My copyright paperwork for Guile is now done. Rob, can you install my setgroups and symbol-printing patches? paul From MAILER-DAEMON Mon Jun 30 19:02:13 2003 Received: from list by monty-python.gnu.org with archive (Exim 4.20) id 19X7TF-0007Wm-KN for mharc-guile-devel@gnu.org; Mon, 30 Jun 2003 18:50:01 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19X7PH-0006h6-WB for guile-devel@gnu.org; Mon, 30 Jun 2003 18:45:55 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19X7MD-0005iP-E6 for guile-devel@gnu.org; Mon, 30 Jun 2003 18:42:47 -0400 Received: from multivac.student.cwru.edu ([129.22.114.26] helo=multivac.cwru.edu) by monty-python.gnu.org with smtp (Exim 4.20) id 19X7Jz-0005RH-N6 for guile-devel@gnu.org; Mon, 30 Jun 2003 18:40:27 -0400 Received: (qmail 25955 invoked by uid 500); 30 Jun 2003 22:40:24 -0000 To: Marius Vollmer In-Reply-To: (Paul Jarc's message of "Fri, 27 Jun 2003 11:58:37 -0400") References: <87ade0zwwe.fsf@raven.i.defaultvalue.org> <87he7t5olk.fsf@zagadka.ping.de> From: prj@po.cwru.edu (Paul Jarc) Organization: What did you have in mind? A short, blunt, human pyramid? Mail-Copies-To: nobody Mail-Followup-To: Marius Vollmer , Rob Browning , guile-devel@gnu.org Date: Mon, 30 Jun 2003 18:40:01 -0400 Message-ID: Lines: 17 User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" cc: Rob Browning cc: guile-devel@gnu.org Subject: Re: libguile/print.c fixes X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 30 Jun 2003 22:49:59 -0000 --=-=-= I wrote: > My copyright paperwork for Guile is now done. Rob, can you install my > setgroups and symbol-printing patches? In case someone else is less busy... top-level ChangeLog: * configure.in: check for setgroups. libguile/ChangeLog: * posix.c (scm_setgroups): new function. * print.c (scm_print_symbol_name): add comments and fix bugs for #{1}#, #{'x}#, and #{}\#\ }#. paul --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=setgroups.patch Index: configure.in =================================================================== RCS file: /cvsroot/guile/guile/guile-core/configure.in,v retrieving revision 1.222 diff -u -r1.222 configure.in --- configure.in 21 Jun 2003 00:15:09 -0000 1.222 +++ configure.in 30 Jun 2003 22:32:37 -0000 @@ -591,7 +591,7 @@ [Define if the system supports Unix-domain (file-domain) sockets.]) fi -AC_CHECK_FUNCS(socketpair getgroups setpwent pause tzset) +AC_CHECK_FUNCS(socketpair getgroups setgroups setpwent pause tzset) AC_CHECK_FUNCS(sethostent gethostent endhostent dnl setnetent getnetent endnetent dnl Index: libguile/posix.c =================================================================== RCS file: /cvsroot/guile/guile/guile-core/libguile/posix.c,v retrieving revision 1.118 diff -u -r1.118 posix.c --- libguile/posix.c 14 Jun 2003 05:36:02 -0000 1.118 +++ libguile/posix.c 30 Jun 2003 22:32:38 -0000 @@ -228,6 +228,46 @@ #undef FUNC_NAME #endif +#ifdef HAVE_SETGROUPS +SCM_DEFINE (scm_setgroups, "setgroups", 1, 0, 0, + (SCM group_vec), + "Set the supplementary group IDs to those found in the vector argument.") +#define FUNC_NAME s_scm_setgroups +{ + size_t ngroups; + size_t size; + size_t i; + int result; + int save_errno; + GETGROUPS_T *groups; + + SCM_VALIDATE_VECTOR (SCM_ARG1, group_vec); + + ngroups = SCM_VECTOR_LENGTH (group_vec); + + /* validate before allocating, so we don't have to worry about leaks */ + for (i = 0; i < ngroups; i++) + SCM_VALIDATE_INUM (0, SCM_VECTOR_REF (group_vec, i)); + + size = ngroups * sizeof (GETGROUPS_T); + /* XXX - if (size / sizeof (GETGROUPS_T) != ngroups) out-of-range */ + groups = scm_malloc (size); + if (groups == NULL) + SCM_MEMORY_ERROR; + for(i = 0; i < ngroups; i++) + groups [i] = SCM_INUM (SCM_VECTOR_REF (group_vec, i)); + + result = setgroups (ngroups, groups); + save_errno = errno; /* don't let free() touch errno */ + free (groups); + errno = save_errno; + if (result < 0) + SCM_SYSERROR; + return SCM_UNSPECIFIED; +} +#undef FUNC_NAME +#endif + #ifdef HAVE_GETPWENT SCM_DEFINE (scm_getpwuid, "getpw", 0, 1, 0, (SCM user), --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=print_symbol.patch Index: libguile/print.c =================================================================== RCS file: /cvsroot/guile/guile/guile-core/libguile/print.c,v retrieving revision 1.150 diff -u -r1.150 print.c --- libguile/print.c 12 May 2003 20:46:52 -0000 1.150 +++ libguile/print.c 30 Jun 2003 22:32:38 -0000 @@ -300,27 +300,34 @@ void scm_print_symbol_name (const char *str, size_t len, SCM port) { - size_t pos; + /* This points to the first character that has not yet been written to the + * port. */ + size_t pos = 0; + /* This points to the character we're currently looking at. */ size_t end; - int weird; - int maybe_weird; + /* If the name contains weird characters, we'll escape them with + * backslashes and set this flag; it indicates that we should surround the + * name with "#{" and "}#". */ + int weird = 0; + /* Backslashes are not sufficient to make a name weird, but if a name is + * weird because of other characters, backslahes need to be escaped too. + * The first time we see a backslash, we set maybe_weird, and mw_pos points + * to the backslash. Then if the name turns out to be weird, we re-process + * everything starting from mw_pos. */ + int maybe_weird = 0; size_t mw_pos = 0; - - pos = 0; - weird = 0; - maybe_weird = 0; - - /* XXX - Lots of weird symbol names are missed, such as "12" or - "'a". */ + /* If the name is purely numeric, then it's weird as a whole, even though + * none of the individual characters is weird. But we won't know this + * until we reach the end of the name. This flag describes the part of the + * name we've looked at so far. */ + int all_digits = 1; - if (len == 0) - scm_lfwrite ("#{}#", 4, port); - else if (str[0] == '#' || str[0] == ':' || str[len-1] == ':') + if (len == 0 || str[0] == '\'' || str[0] == ':' || str[len-1] == ':') { scm_lfwrite ("#{", 2, port); weird = 1; } - + for (end = pos; end < len; ++end) switch (str[end]) { @@ -332,8 +339,10 @@ case ')': case '"': case ';': + case '#': case SCM_WHITE_SPACES: case SCM_LINE_INCREMENTORS: + all_digits = 0; weird_handler: if (maybe_weird) { @@ -346,9 +355,7 @@ weird = 1; } if (pos < end) - { - scm_lfwrite (str + pos, end - pos, port); - } + scm_lfwrite (str + pos, end - pos, port); { char buf[2]; buf[0] = '\\'; @@ -358,6 +365,7 @@ pos = end + 1; break; case '\\': + all_digits = 0; if (weird) goto weird_handler; if (!maybe_weird) @@ -366,14 +374,18 @@ mw_pos = pos; } break; - case '}': - case '#': - if (weird) - goto weird_handler; + case '0': case '1': case '2': case '3': case '4': + case '5': case '6': case '7': case '8': case '9': break; default: + all_digits = 0; break; } + if (all_digits) + { + scm_lfwrite ("#{", 2, port); + weird = 1; + } if (pos < end) scm_lfwrite (str + pos, end - pos, port); if (weird) --=-=-=--