bug#10488: guile-config deprecation?
On Thu 12 Jan 2012 19:42, Mike Gran writes:
> There's a bit of confusion on the guile-config deprecation.
Indeed.
> NEWS says that guile-config "will be deprecated"
This reflects what I would like to happen, but I share your concern that
we not create a situation in which "guile-config will just disappear
with no equally powerful, documented replacement in place". Hence the
slowness of this transition. Thanks for bringing it up.
> meta/guile-config.in says it "has been deprecated"
I changed the text to "will be deprecated". It's somewhat
weasel-worded, I guess.
> meta/guile.m4's GUILE_PROGS rule will error "guile-config required
> but not found"
Uf, this is a can of worms. I hacked on this a bit this morning, and
came up with the following. What do you think?
# GUILE_PKG -- find Guile development files
#
# Usage: GUILE_PKG([VERSIONS])
#
# This macro runs the @code{pkg-config} tool to find development files
# for an available version of Guile.
#
# By default, this macro will search for the latest stable version of
# Guile (e.g. 2.0), falling back to the previous stable version
# (e.g. 1.8) if it is available. If no guile-@var{VERSION}.pc file is
# found, an error is signalled. The found version is stored in
# @var{GUILE_EFFECTIVE_VERSION}.
#
# If @code{GUILE_PROGS} was already invoked, this macro ensures that the
# development files have the same effective version as the Guile
# program.
#
# @var{GUILE_EFFECTIVE_VERSION} is marked for substitution, as by
# @code{AC_SUBST}.
#
AC_DEFUN([GUILE_PKG],
[PKG_PROG_PKG_CONFIG
_guile_versions_to_search=m4_default([$1], [2.0 1.8])
if test -z "$GUILE_EFFECTIVE_VERSION"; then
_guile_tmp=""
for v in $_guile_versions_to_search; do
if test "$v" = "$GUILE_EFFECTIVE_VERSION"
_guile_tmp=$v
fi
done
if test -z "$_guile_tmp"; then
AC_MSG_FAILURE([searching for guile development files for versions
$_guile_versions_to_search, but previously found $GUILE version
$GUILE_EFFECTIVE_VERSION])
fi
_guile_versions_to_search=$GUILE_EFFECTIVE_VERSION
fi
GUILE_EFFECTIVE_VERSION=""
_guile_errors=""
for v in $_guile_versions_to_search; do
AC_MSG_NOTICE([checking for guile $v])
if test -z "$GUILE_EFFECTIVE_VERSION"; then
PKG_CHECK_EXISTS([guile-$v], [GUILE_EFFECTIVE_VERSION=$v], [])
fi
done
if test -z "$GUILE_EFFECTIVE_VERSION"; then
AC_MSG_ERROR([
No Guile development packages were found.
Please verify that you have Guile installed. If you installed Guile
from a binary distribution, please verify that you have also installed
the development packages. If you installed it yourself, you might need
to adjust your PKG_CONFIG_PATH; see the pkg-config man page for more.
])
fi
AC_MSG_NOTICE([found guile $v])
AC_SUBST([GUILE_EFFECTIVE_VERSION])
])
# GUILE_FLAGS -- set flags for compiling and linking with Guile
#
# Usage: GUILE_FLAGS
#
# This macro runs the @code{pkg-config} tool to find out how to compile
# and link programs against Guile. It sets four variables:
# @var{GUILE_CFLAGS}, @var{GUILE_LDFLAGS}, @var{GUILE_LIBS}, and
# @var{GUILE_LTLIBS}.
#
# @var{GUILE_CFLAGS}: flags to pass to a C or C++ compiler to build code that
# uses Guile header files. This is almost always just one or more @code{-I}
# flags.
#
# @var{GUILE_LDFLAGS}: flags to pass to the compiler to link a program
# against Guile. This includes @code{-lguile-@var{VERSION}} for the
# Guile library itself, and may also include one or more @code{-L} flag
# to tell the compiler where to find the libraries. But it does not
# include flags that influence the program's runtime search path for
# libraries, and will therefore lead to a program that fails to start,
# unless all necessary libraries are installed in a standard location
# such as @file{/usr/lib}.
#
# @var{GUILE_LIBS} and @var{GUILE_LTLIBS}: flags to pass to the compiler or to
# libtool, respectively, to link a program against Guile. It includes flags
# that augment the program's runtime search path for libraries, so that shared
# libraries will be found at the location where they were during linking, even
# in non-standard locations. @var{GUILE_LIBS} is to be used when linking the
# program directly with the compiler, whereas @var{GUILE_LTLIBS} is to be used
# when linking the program is done through libtool.
#
# The variables are marked for substitution, as by @code{AC_SUBST}.
#
AC_DEFUN([GUILE_FLAGS],
[AC_REQUIRE([GUILE_PKG])
PKG_CHECK_MODULES(GUILE, [guile-$GUILE_EFFECTIVE_VERSION])
dnl GUILE_CFLAGS and GUILE_LIBS are already defined and AC_SUBST'd by
dnl PKG_CHECK_MODULES. But GUILE_LIBS to pkg-config is GUILE_LDFLAGS
dnl to us.
GUILE_LDFLAGS=$GUILE_LIBS
dnl Determine the platform dependent parameters needed to use rpath.
dnl AC_LIB_LINKFLAGS_FROM_LIBS is defined in gnulib/m4/lib-link.m4 and needs
dnl the file gnulib/build-aux/config.rpath.
AC_LIB_LINKFLAGS_FROM_LIBS([GUILE_LIBS], [$GUILE_LDFLAGS], [])
GUILE_LIBS="$GUILE_LDFLAGS
bug#10485: Patches to improve variable name usage in docstrings
On Thu 12 Jan 2012 06:07, Bake Timmons writes: > Attached are patches to improve variable name usage in docstrings. > These patches cover simple, blatant inconsistencies. Applied; thanks! Note that I applied them to stable-2.0. One of your patches applied to weak-vector.c and weak-table.c, which are only on master. Since we seem to be mainly working on stable-2.0 these days, it seemed appropriate. Cheers, Andy -- http://wingolog.org/
bug#10486: Patch: Fix case in identifiers starting sentences in doc/r5rs/r5rs.texi
On Thu 12 Jan 2012 17:11, Bake Timmons writes: > The GNU coding standards advise sticking with proper case for > identifiers, even if the identifier starts with a lowercase letter and > appears at the beginning of a sentence. > > The Guile manual seems to follow this convention, with the exception of > r5rs.texi, hence the attached patch. Applied, thanks. Note that as R5RS is a historical document, we probably won't be accepting textual changes to this file, though you probably knew that already. Andy -- http://wingolog.org/
bug#10481: Simple patches to Texinfo docs
On Wed 11 Jan 2012 19:08, Bake Timmons writes: > Months ago I proposed some improvements to the manual. With a gentle > reminder from Andy Wingo, I have finally started breaking up my original > giant patch into some manageable patches. Thank you! I applied both of these patches. Sorry we didn't get around to it until after the release; things were a bit hectic. Cheers, Andy -- http://wingolog.org/
bug#10486: Patch: Fix case in identifiers starting sentences in doc/r5rs/r5rs.texi
Andy Wingo writes: > On Thu 12 Jan 2012 17:11, Bake Timmons writes: > >> The GNU coding standards advise sticking with proper case for >> identifiers, even if the identifier starts with a lowercase letter and >> appears at the beginning of a sentence. >> >> The Guile manual seems to follow this convention, with the exception of >> r5rs.texi, hence the attached patch. > > Applied, thanks. Note that as R5RS is a historical document, we > probably won't be accepting textual changes to this file, though you > probably knew that already. Note that according to the R5RS, identifiers are not case sensitive, so e.g. 'Let*' is no less correct than 'let*'. In that context, it does not make sense to say "the identifier starts with a lowercase letter". Also, as Andy notes, it is an historical document. I would advocate reverting this patch. Thanks, Mark
bug#10481: Simple patches to Texinfo docs
Andy Wingo writes: > On Wed 11 Jan 2012 19:08, Bake Timmons writes: > >> Months ago I proposed some improvements to the manual. With a gentle >> reminder from Andy Wingo, I have finally started breaking up my original >> giant patch into some manageable patches. > > Thank you! I applied both of these patches. Sorry we didn't get around > to it until after the release; things were a bit hectic. Note that according to the R5RS, identifiers are not case sensitive, so e.g. 'Radix' is no less correct than 'radix'. In that context, it does not make sense to say "the identifier starts with a lowercase letter". Also, as Andy noted elsewhere, the R5RS is an historical document. I would advocate reverting the R5RS portion of this patch. The rest of the patch looks great, many thanks! :) Mark
bug#10474: Building guile 2.x under mingw + msys
Hi! Andy Wingo skribis: > I would like to take this task off his back, assuming he's OK with it: > the release process was terribly long, and Ludo deserves a rest ;) Thank you. :-) > One thing: Ludo mentions that he had success with a cross-compiled MinGW > 3.18 (IIRC?). That’s on Hydra, and MinGW has since been upgraded to 3.20 there. Note that it’s a ‘--disable-networking’ build too, which is easier. Thanks, Ludo’.
bug#10474: Building guile 2.x under mingw + msys
> From: l...@gnu.org (Ludovic Courtès) > Cc: Eli Zaretskii , 10...@debbugs.gnu.org, > commander.si...@googlemail.com > Date: Thu, 02 Feb 2012 17:39:44 +0100 > > Note that it’s a ‘--disable-networking’ build too, which is easier. That might just explain at least some of the problems that I hit, but Ludo didn't. As you can see in my reports, quite a few of them were related to network code in some way.
bug#10474: Building guile 2.x under mingw + msys
> From: Andy Wingo
> Cc: l...@gnu.org (Ludovic Courtès), 10...@debbugs.gnu.org,
> commander.si...@googlemail.com
> Date: Thu, 02 Feb 2012 01:59:21 +0100
>
> I will assume that the canonicalize_file_name issues will get resolved
> eventually in gnulib, once your assignment completes. I will go
> through the rest of the issues.
As promised, the diffs that I suggest to install to take care of the
problems I bumped into are at the end of this message.
For your convenience, I grouped the changes into several related
groups, in case you'd like to make them separate commits. Each group
is preceded by a short description (a candidate for a commit log
message) and ChangeLog entries for the changes.
In addition to the diffs, there are a few other changes for which I
don't show my changes, because they were ad-hoc and not very clean.
Instead, I describe what I think should be the "right" solutions for
them:
. lib/canonicalize-lgpl.c -- does not support Windows absolute file
names. Will be fixed in gnulib.
. libguile/dynl.c -- lacks setenv. Gnulib's setenv should be used.
. libguile/expand.c -- Defines CONST and VOID. Should define
SCM_CONST and SCM_VOID (or some other, less
ubiquitous, symbols) instead.
. libguile/fports.c -- Doesn't implement fport_input_waiting when
neither poll nor select nor FIONREAD are
available, without which interactive guile
won't start. Should use the gnulib select
module.
. libguile/socket.c -- Lacks implementation of `times' for
MS-Windows, without which guile.exe aborts
during startup. Should use the gnulib times
module.
. module/ice-9/boot-9.scm -- absolute-path? does not support Windows
file names with drive letters. Windows
absolute file names match the regex
"\([a-zA-Z]:\)?[\\/]". I don't know
Scheme well enough to write this in a
clean way, sorry...
Here are the diffs:
Fix startup of guile.exe on MS-Windows.
* module/system/base/compile.scm (call-with-output-file/atomic):
Call close-port before deleting the temporary file name, otherwise
deletion fails on MS-Windows (cannot delete a file that is still
open).
* libguile/load.c (scm_init_load_path) [__MINGW32__]: Convert
backslashes to forward slashes in values of GUILE_LOAD_PATH and
GUILE_LOAD_COMPILED_PATH.
--- module/system/base/compile.scm~02011-10-08 01:49:48.0 +0200
+++ module/system/base/compile.scm 2012-01-19 16:49:26.528084600 +0200
@@ -61,6 +61,7 @@
(close-port tmp)
(rename-file template filename))
(lambda args
+ (close-port tmp)
(delete-file template)))
(define (ensure-language x)
--- libguile/load.c~0 2011-10-08 01:49:48.0 +0200
+++ libguile/load.c 2012-01-17 16:47:19.325381400 +0200
@@ -310,10 +309,36 @@ scm_init_load_path ()
}
env = getenv ("GUILE_LOAD_PATH");
+#ifdef __MINGW32__
+ if (env)
+{
+ char *p = env;
+
+ while (*p)
+ {
+ if (*p == '\\')
+ *p = '/';
+ p++;
+ }
+}
+#endif
if (env)
path = scm_parse_path (scm_from_locale_string (env), path);
env = getenv ("GUILE_LOAD_COMPILED_PATH");
+#ifdef __MINGW32__
+ if (env)
+{
+ char *p = env;
+
+ while (*p)
+ {
+ if (*p == '\\')
+ *p = '/';
+ p++;
+ }
+}
+#endif
if (env)
cpath = scm_parse_path (scm_from_locale_string (env), cpath);
Avoid compiler warnings on MS-Windows.
* libguile/print.c (display_string_using_iconv): Cast 2nd arg of
`iconv' to `const char **', to avoid compiler warnings.
* libguile/ports.c (get_iconv_codepoint): Cast 2nd arg of `iconv'
to `const char **', to avoid compiler warnings.
* libguile/deprecation.c (vsnprintf) [__MINGW32__]: Don't redefine
if already defined. Avoids compiler warnings.
* libguile/filesys.c (mkdir) [__MINGW32__]: Don't redefine if
GNULIB_defined_rpl_mkdir is defined, meaning that the gnulib
replacement is being used.
(fchmod) [__MINGW32__]: Define to zero, to avoid gratuitous failures
of many file operations on MS-Windows.
--- libguile/print.c~0 2011-10-08 01:49:48.0 +0200
+++ libguile/print.c2012-01-15 15:10:51.450848400 +0200
@@ -899,7 +899,7 @@ display_string_using_iconv (const void *
output = encoded_output;
output_left = sizeof (encoded_output);
- done = iconv (pt->output_cd, &input, &input_left,
+ done = iconv (pt->output_cd, (const char **)&input, &input_left,
bug#10488: guile-config deprecation?
Andy Wingo wrote: > On Thu 12 Jan 2012 19:42, Mike Gran writes: > > > There's a bit of confusion on the guile-config deprecation. > > Indeed. > > > NEWS says that guile-config "will be deprecated" > > This reflects what I would like to happen, but I share your concern that > we not create a situation in which "guile-config will just disappear > with no equally powerful, documented replacement in place". Hence the > slowness of this transition. Thanks for bringing it up. > > > meta/guile-config.in says it "has been deprecated" > > I changed the text to "will be deprecated". It's somewhat > weasel-worded, I guess. > > > meta/guile.m4's GUILE_PROGS rule will error "guile-config required > > but not found" > > Uf, this is a can of worms. I hacked on this a bit this morning, and > came up with the following. What do you think? How about adding something for extensiondir ? -Dale
bug#10488: guile-config deprecation?
On Thu 02 Feb 2012 19:49, writes: > How about adding something for extensiondir ? That's a good idea. The dir for the .go files, too. Andy -- http://wingolog.org/
bug#10693: guild compile --load-path value is not processed with scm_parse_path, GUILE_LOAD_PATH env variable value is parsed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Copy of reply sent to Mark alone by mistake) Hi Mark On 02/02/12 05:05, Mark H Weaver wrote: > Hi Ian, > > Ian Hulin writes: >> ian@nanny-ogg ~/src/lilypond (T2026-1)>> guild compile >> --load-path="/home/ian/src/lilypond:/home/ian/src/lilypond/scm" > > According to both the Guile manual and the output of "guile compile > -h": > > -L, --load-path=DIR add DIR to the front of the module load path > > In other words, it behaves as documented. The idea is that you > should pass multiple --load-path options, one for each DIR. > > Having said this, one could reasonably argue that the long option > name is misleading, and I tend to agree. On the other hand, the > current behavior has the advantage of allowing _any_ directory to > be added, even if its name contains a colon, and thus allows the > creation of more robust code. > > We might want to change the long option name (while continuing to > accept --load-path for backward compatibility), but I can't think > of a good name. Any suggestions? > - --add-to-load-path, then it matches the new procedure/macro that does the same thing? Note too that the guile command line does not have a long option name for -L. Also, how about documenting somewhere the difference in behaviour between setting the environment variable and using the long option name. Thanks very much for pointing out the bear-traps, Mark. Cheers, Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPKvkhAAoJEBqidDirZqAShiUIAJEy0qTxa9nfOTsidTG5DGmM CM0rvAOUPoBii39nUNX/vkpBtTPWRLerY7QhTVPNMNbu7T7+rify12KwDxYaz/bM 8CDXYzYD7ypTiBHYlJ4ZJaGPt+CZs7PR9JobtaGT3AuRx8S4iGRGEL6x0G2hByiy M7sEHkxU8D1FGgavTFxvWI9MLypde44xcjagv6Da3ATUD3nYO4HRDVSAMp9g1cmy 6dAGDtzEccbzlYfRtb126MtskAqD4Z9Fl/zfFIhN06CLXyJBi1xS+WL3F5EwI0lv evAN5VXwb1xkVaHFkjM1xaM4ny2BFAJEkJeBx7KTTqQJNWrplVBPJGUyzJWM7QU= =YiMF -END PGP SIGNATURE-
bug#10684: guile-2.0.5 test failures on powerpc-darwin8
Hi David,
David Fang skribis:
>> Can you try this (in a UTF-8 terminal):
>>
>> (use-modules (ice-9 i18n))
>> (setlocale LC_ALL "tr_TR.UTF-8")
>> (char-locale-upcase #\i)
[...]
> scheme@(guile-user)> (use-modules (ice-9 i18n))
> scheme@(guile-user)> (setlocale LC_ALL "tr_TR.UTF-8")
> $1 = "tr_TR.UTF-8"
> scheme@(guile-user)> (char-locale-upcase #\i)
> $2 = #\I
> scheme@(guile-user)>
>
> Does that look right?
No, it should be İ, so it means that this version of Darwin has invalid
Turkish locale data.
Can show what %host-type is on your system? I’ll add an exception to
skip these tests on this platform.
>>> FAIL: net-db.test: getaddrinfo: wrong service name
>>
>> Can you try this:
>>
>> (getaddrinfo "127.0.0.1" "does-not-exist" AI_NUMERICHOST)
>
> scheme@(guile-user)> (getaddrinfo "127.0.0.1" "does-not-exist"
> AI_NUMERICHOST)
> ERROR: In procedure getaddrinfo:
> ERROR: In procedure getaddrinfo: No address associated with nodename
Can you apply this patch, run ‘./check-guile net-db.test’, and report
back?
diff --git a/test-suite/tests/net-db.test b/test-suite/tests/net-db.test
index 89ebb1b..8b14a92 100644
--- a/test-suite/tests/net-db.test
+++ b/test-suite/tests/net-db.test
@@ -102,5 +102,7 @@
;; According to POSIX, both error codes are valid (glibc 2.11
;; chooses `EAI_SERVICE'; Darwin chooses `EAI_NONAME'.)
(and (or (= errcode EAI_SERVICE)
- (= errcode EAI_NONAME))
+ (= errcode EAI_NONAME)
+ (and (defined? 'EAI_NODATA)
+ (= errcode EAI_NODATA)))
(string? (gai-strerror errcode
> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>
>
>>> ERROR: regexp.test: regexp-quote: regexp/extended: (char 254 #\þ
>>> "þ") -
>>> arguments: ((regular-expression-syntax "make-regexp" "empty
>>> (sub)expression" #f ("þ")))
>>
>> Hm?
>>
>>> FAIL: regexp.test: regexp-quote: regexp/extended: (string "aX" 254
>>> #\þ "aþ" "aþ")
>>> FAIL: regexp.test: regexp-quote: regexp/extended: string of all chars
>>
>> Can you try:
>>
>> (setlocale LC_ALL "en_US.ISO-8859-1") ;; or some other ISO-8859-1 locale
>> (let* ((s (string (integer->char 254)))
>> (q (regexp-quote s)))
>>(regexp-exec (make-regexp q regexp/extended) s))
[...]
> scheme@(guile-user)> (setlocale LC_ALL "en_US.ISO8859-1")
> $1 = "en_US.ISO8859-1"
> scheme@(guile-user)> (let* ((s (string (integer->char 254))) (q
> (regexp-quote s))) (regexp-exec (make-regexp q regexp/extended) s))
> ERROR: In procedure make-regexp:
> ERROR: In procedure make-regexp: empty (sub)expression
This looks like a bug of Darwin’s regcomp that’s likely to be solved by
using Gnulib’s ‘regex’ module. If you don’t mind, I’ll provide you
with a new tarball to test when we’re done with the other issues.
Thanks for your patient investigation!
Ludo’.
bug#9776: case-lambda should accept zero clauses
Hi Mark, Mark H Weaver skribis: > Thanks for tackling this. Of course this is Andy's area, but psyntax is > still fresh in my mind, so I'll attempt a review as well as my own > tentative approach. Psyntax is not yet a place where I feel comfortable, so I appreciate. :-) > l...@gnu.org (Ludovic Courtès) writes: >> So, here’s a tentative patch for review: >> >> >> Modified module/ice-9/psyntax.scm >> diff --git a/module/ice-9/psyntax.scm b/module/ice-9/psyntax.scm >> index 728ab12..c3aa6d8 100644 >> --- a/module/ice-9/psyntax.scm >> +++ b/module/ice-9/psyntax.scm >> @@ -1778,7 +1778,19 @@ >>r* w* mod) >> >> (syntax-case clauses () >> - (() (values '() #f)) >> + (() ; zero clauses >> + (values >> +'() >> +(build-lambda-case s '() '() 'rest #f '() >> + (list (build-lexical-var s 'rest)) >> + (build-application s >> + (make-toplevel-ref s >> 'throw) > > This 'make-toplevel-ref' should instead be 'build-primref', so that it > refers to the 'throw' in the 'guile' module. As it is now, this won't > work in modules that have bound 'throw' to something else. Oh, OK. >> + (list >> + (build-data >> +s 'wrong-number-of-args) >> + (build-data >> +s "Wrong number of >> arguments"))) >> + #f))) > > Unfortunately, the above case is not only triggered for an empty > case-lambda; it is the base case at the end of iteration over the > clauses, so this code will be added to _every_ case-lambda. Oops, indeed. > Apart from the extra bloat, this will make error reporting much worse. > Right now, if you call a procedure created by 'case-lambda' with an > incorrect number of arguments, the VM will generate a nice error message > that includes the procedure itself, including the procedure's name. > > By adding this "catch-all" clause to the end of every 'case-lambda', you > have taken over the job of error reporting for _all_ case-lambdas, but > you produce a much less useful error message than the VM does. > > This also destroys the arity information for all case-lambdas. OK, I see. [...] > Here's how it reports errors: > >> scheme@(guile-user)> (define foo (case-lambda)) >> scheme@(guile-user)> (foo) >> ;;; :2:0: warning: possibly wrong number of arguments to `foo' >> ERROR: In procedure foo: >> ERROR: Wrong number of arguments to #> with no clauses a b c d e f g h i j k l m n o p q r s t u v w x y z)> [...] > + ;; a terrible hack to produce helpful error > messages in most cases > + #`(lambda (created by case-lambda with no > clauses > +a b c d e f g h i j k l m n > o p q r s t u v w x y z) > + (scm-error > + '#,'wrong-number-of-args #f > + "Wrong number of arguments to a procedure > created by case-lambda with no clauses" > + '() #f)) But this is terible! What about something along these lines instead (untested): diff --git a/module/ice-9/psyntax.scm b/module/ice-9/psyntax.scm index 728ab12..da7f16a 100644 --- a/module/ice-9/psyntax.scm +++ b/module/ice-9/psyntax.scm @@ -1704,7 +1704,7 @@ orig-args (req orig-args '( -(define expand-lambda-case +(define expand-lambda-case* (lambda (e r w s mod get-formals clauses) (define (parse-req req opt rest kw body) (let ((vars (map gen-var req)) @@ -1795,6 +1795,25 @@ (build-lambda-case s req opt rest kw inits vars body else* +(define expand-lambda-case + (lambda (e r w s mod get-formals clauses) +(syntax-case clauses () + (() + (values +'() +(build-lambda-case s '() '() 'rest #f '() + (list (build-lexical-var s 'rest)) + (build-application s + (build-primref s 'throw) + (list + (build-data +s 'wrong-number-of-args) + (build-data +s "Wrong number of arguments"))) + #f))) + (((args e1 e2
bug#10693: guild compile --load-path value is not processed with scm_parse_path, GUILE_LOAD_PATH env variable value is parsed.
Hi, Mark H Weaver skribis: > Ian Hulin writes: >> ian@nanny-ogg ~/src/lilypond (T2026-1)>> guild compile >> --load-path="/home/ian/src/lilypond:/home/ian/src/lilypond/scm" > > According to both the Guile manual and the output of "guile compile -h": > > -L, --load-path=DIR add DIR to the front of the module load path > > In other words, it behaves as documented. The idea is that you should > pass multiple --load-path options, one for each DIR. [...] > We might want to change the long option name (while continuing to accept > --load-path for backward compatibility), but I can't think of a good > name. Any suggestions? As discussed on IRC, I agree that the long name can be misleading. Yet, I’d rather keep it, especially since the doc is non-ambiguous and ‘-L’ looks familiar. Done? :-) Thanks, Ludo’.
bug#10481: Simple patches to Texinfo docs
On Thu 02 Feb 2012 15:37, Mark H Weaver writes: > I would advocate reverting the R5RS portion of this patch. Reverted. Thanks for the feedback :) Andy -- http://wingolog.org/
bug#10486: Patch: Fix case in identifiers starting sentences in doc/r5rs/r5rs.texi
Hi, Mark H Weaver skribis: > Andy Wingo writes: > >> On Thu 12 Jan 2012 17:11, Bake Timmons writes: >> >>> The GNU coding standards advise sticking with proper case for >>> identifiers, even if the identifier starts with a lowercase letter and >>> appears at the beginning of a sentence. >>> >>> The Guile manual seems to follow this convention, with the exception of >>> r5rs.texi, hence the attached patch. >> >> Applied, thanks. Note that as R5RS is a historical document, we >> probably won't be accepting textual changes to this file, though you >> probably knew that already. > > Note that according to the R5RS, identifiers are not case sensitive, so > e.g. 'Let*' is no less correct than 'let*'. In that context, it does > not make sense to say "the identifier starts with a lowercase letter". > Also, as Andy notes, it is an historical document. > > I would advocate reverting this patch. Agreed. I would consider r5rs.texi read-only. Thanks, Ludo’.
bug#10684: guile-2.0.5 test failures on powerpc-darwin8
Hi, Answers below. David Fang skribis: Can you try this (in a UTF-8 terminal): (use-modules (ice-9 i18n)) (setlocale LC_ALL "tr_TR.UTF-8") (char-locale-upcase #\i) [...] scheme@(guile-user)> (use-modules (ice-9 i18n)) scheme@(guile-user)> (setlocale LC_ALL "tr_TR.UTF-8") $1 = "tr_TR.UTF-8" scheme@(guile-user)> (char-locale-upcase #\i) $2 = #\I scheme@(guile-user)> Does that look right? No, it should be ÿÿ, so it means that this version of Darwin has invalid Turkish locale data. Can show what %host-type is on your system? Iÿÿll add an exception to skip these tests on this platform. scheme@(guile-user)> %host-type $1 = "powerpc-apple-darwin8.11.0" FAIL: net-db.test: getaddrinfo: wrong service name Can you try this: (getaddrinfo "127.0.0.1" "does-not-exist" AI_NUMERICHOST) scheme@(guile-user)> (getaddrinfo "127.0.0.1" "does-not-exist" AI_NUMERICHOST) ERROR: In procedure getaddrinfo: ERROR: In procedure getaddrinfo: No address associated with nodename Can you apply this patch, run ÿÿ./check-guile net-db.testÿÿ, and report back? Looks better: [fangism:guile20-2.0.5-0/guile-2.0.5/build] fang% ./check-guile net-db.test Testing /Volumes/Mercedes2/sw/src/fink.build/guile20-2.0.5-0/guile-2.0.5/build/meta/guile ... net-db.test with GUILE_LOAD_PATH=/Volumes/Mercedes2/sw/src/fink.build/guile20-2.0.5-0/guile-2.0.5/test-suite Running net-db.test Totals for this test run: passes: 6 failures: 0 unexpected passes: 0 expected failures: 0 unresolved test cases: 0 untested test cases:0 unsupported test cases: 0 errors: 0 Thanks for the proposed fixes/workarounds! Fang -- David Fang http://www.csl.cornell.edu/~fang/
