Re: [PATCH] Fix continuation problems on IA64.
Hi, Neil Jerram [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Ludovic Courtès) writes: This breaks ABI compatibility on IA64, but if Guile wasn't usable on IA64 (was it?) that's probably not a problem. Good point, and I don't think it was completely unusable before, so this could be an issue. The problems were sufficient to break Lilypond on IA64, but many simpler programs could have been fine. Who is ABI compatibility an issue for? If it's only the distros, we're probably OK, as I believe they won't have promoted something that failed make check. If we change the ABI, we should increase `LIBGUILE_INTERFACE_CURRENT' and set `AGE' to zero because it's not going to be backward-compatible---and we can't do that only for IA64, unfortunately... For people building their own Guile libs, can we cover this by a sentence in the next release notes, to say that programs using scm_i_thread should be recompiled? Programs necessarily access it, through `SCM_I_CURRENT_THREAD', etc. I'm happy with adding SCM_NORETURN; but why the SCM_API? I don't think a libguile application should call scm_ia64_longjmp itself, so do not intend to document it. Right, but `SCM_API' is just `extern' (except on Windows), which is normal in such a declaration; and whether declared `extern' or not, the symbol will be exported anyway. Thanks, Ludovic.
[patch] make readline pay attention to the current-reader fluid
From a488aa59468f60133fc8767b3ffafa2e098bda4f Mon Sep 17 00:00:00 2001 From: Andy Wingo [EMAIL PROTECTED] Date: Fri, 9 May 2008 13:07:32 +0200 Subject: [PATCH] make readline's `repl-reader' impl check the current-reader fluid * guile-readline/ice-9/readline.scm (activate-readline): Use the current binding of the current-reader fluid, if it is available. --- guile-readline/ice-9/readline.scm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/guile-readline/ice-9/readline.scm b/guile-readline/ice-9/readline.scm index 363b7c0..dce7755 100644 --- a/guile-readline/ice-9/readline.scm +++ b/guile-readline/ice-9/readline.scm @@ -212,7 +212,7 @@ (set-buffered-input-continuation?! (readline-port) #f) (set-readline-prompt! prompt ... ) (set-readline-read-hook! read-hook)) - (lambda () (read)) + (lambda () ((or (fluid-ref current-reader) read))) (lambda () (set-readline-prompt! ) (set-readline-read-hook! #f) -- 1.5.5-rc2.GIT -- http://wingolog.org/
support thunks as prompts without readline
Hi, From 69fc67efaad628a866e14ead4cb96f102316b82b Mon Sep 17 00:00:00 2001 From: Andy Wingo [EMAIL PROTECTED] Date: Fri, 9 May 2008 16:42:44 +0200 Subject: [PATCH] support thunks as prompts, as readline does. * ice-9/boot-9.scm (repl-reader): Support thunks as prompts. --- ice-9/boot-9.scm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ice-9/boot-9.scm b/ice-9/boot-9.scm index d1e6306..b92cfd6 100644 --- a/ice-9/boot-9.scm +++ b/ice-9/boot-9.scm @@ -2518,7 +2518,7 @@ ;;; the readline library. (define repl-reader (lambda (prompt) -(display prompt) +(display (if (string? prompt) prompt (prompt))) (force-output) (run-hook before-read-hook) ((or (fluid-ref current-reader) read) (current-input-port -- 1.5.5-rc2.GIT -- http://wingolog.org/
git and changelogs
Hi, Now that we've switched to git, hows about moving our changelogs to ChangeLog.old, and just using commit logs? We can still generate changelogs on release, if that's a desire. I can do something about the latter, if you all think it's a good idea. Andy -- http://wingolog.org/
Re: git and changelogs
Hi, Andy Wingo [EMAIL PROTECTED] writes: Now that we've switched to git, hows about moving our changelogs to ChangeLog.old, and just using commit logs? We can still generate changelogs on release, if that's a desire. I'd be tempted to do that, but among the many GNU projects that switched to Git, apparently none of them did away with ChangeLogs, and I would understand reluctance to remove them. Simon Josefsson wrote `git2cl' (http://josefsson.org/git2cl/), which could be helpful if we are to generate ChangeLogs upon release. Thanks, Ludovic.
Re: [PATCH] Fix continuation problems on IA64.
[EMAIL PROTECTED] (Ludovic Courtès) writes: If we change the ABI, we should increase `LIBGUILE_INTERFACE_CURRENT' and set `AGE' to zero because it's not going to be backward-compatible---and we can't do that only for IA64, unfortunately... Agreed, but I'm not sure the ABI is really changing... Programs necessarily access it, through `SCM_I_CURRENT_THREAD', etc. Yes, but only as a pointer, whose only practical use is to pass back to other libguile functions. That usage doesn't require recompilation. Usages which would require recompilation are - accessing any particular fields in the scm_i_thread structure - declaring a scm_i_thread on the stack - allocating a scm_i_thread on the heap (or in general, anything involving sizeof(scm_i_thread)). In my view, all of these uses are unsupported, and I think it incredibly unlikely that anyone has done any of them in practice. Overall, then, I think we're OK to regard this as _not_ an ABI change. Right, but `SCM_API' is just `extern' (except on Windows), which is normal in such a declaration; I disagree that it is normal always to put `extern' on function prototypes. It isn't needed (as I'm sure you know), and I'm sure I could find lots of examples of projects that don't do it. and whether declared `extern' or not, the symbol will be exported anyway. True (except on Windows), but in my view being exported doesn't make something a supported API. I haven't checked again just now, but I think I've seen other cases where SCM_API is used on a prototype of a function that I would not regard as a supported libguile API. I dislike this, because the name SCM_API clearly implies that the prototype concerned is an API! I definitely don't think that we should create more cases like this. FWIW, my preferred position would be that something is only a supported API if it is documented in the manual. It should then follow that SCM_API can only be used on something that is documented in the manual (including anything that is needed for the expansions of documented macros). Regards, Neil
Re: [patch] make readline pay attention to the current-reader fluid
Andy Wingo [EMAIL PROTECTED] writes: From a488aa59468f60133fc8767b3ffafa2e098bda4f Mon Sep 17 00:00:00 2001 From: Andy Wingo [EMAIL PROTECTED] Date: Fri, 9 May 2008 13:07:32 +0200 Subject: [PATCH] make readline's `repl-reader' impl check the current-reader fluid * guile-readline/ice-9/readline.scm (activate-readline): Use the current binding of the current-reader fluid, if it is available. That looks good to me, but I think we'll also need a corresponding NEWS item and documentation. Could you add those in? Regards, Neil
Re: git and changelogs
Andy Wingo [EMAIL PROTECTED] writes: Hi, Now that we've switched to git, hows about moving our changelogs to ChangeLog.old, and just using commit logs? We can still generate changelogs on release, if that's a desire. Do you mean that we would still have the same level of detail that we currently put in ChangeLog, but we would put that in the commit message instead? Or do you mean that we'd have less formal detail (but possibly a better overall explanation!)? If the former, I'm worried that there isn't AFAIK anything as nice as `C-x 4 a' for adding one detail of a change to a pending commit message. (Or is there?) Regards, Neil
