bug#15370: weirdness w/ uniform-vector-read! compat

[Thien-Thi Nguyen]

Proc ‘uniform-vector-read!’ is deprecated (ugh), and its implementation
rebased onto ‘(rnrs io ports) get-bytevector-n!’.  Unfortunately, there
seems to be a glitch in the arg shuffling.  Here is /tmp/foo.scm:



foo.scm
Description: application/scheme

and here is a series of invocations that demonstrate the discrepency
between ‘get-bytevector-n!’ (ok) and ‘uniform-vector-read!’ (ko):

set -x ; guile --version ; guile -s foo.scm ; guile -s foo.scm ok ; guile -s 
foo.scm ko
+ guile --version
guile (GNU Guile) 2.0.9
Copyright (C) 2013 Free Software Foundation, Inc.

License LGPLv3+: GNU LGPL 3 or later <http://gnu.org/licenses/lgpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ guile -s foo.scm
uve: #s16(0) (2)
uve: #s16(0)
+ guile -s foo.scm ok
uve: #s16(0) (2)
uve: #s16(10794)
+ guile -s foo.scm ko
uve: #s16(0) (2)
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
Backtrace:
In ice-9/boot-9.scm:
 157: 11 [catch #t # ...]
In unknown file:
   ?: 10 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 9 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 8 [eval # #]
In ice-9/boot-9.scm:
2320: 7 [save-module-excursion #]
3968: 6 [#]
1645: 5 [%start-stack load-stack ...]
1650: 4 [#]
In unknown file:
   ?: 3 [primitive-load "/tmp/foo.scm"]
   ?: 2 [call-with-input-string "" ...]
In ice-9/eval.scm:
 432: 1 [eval # #]
In unknown file:
   ?: 0 [uniform-vector-read! #s16(0) # ...]

ERROR: In procedure uniform-vector-read!:
ERROR: In procedure get-bytevector-n!: Value out of range: 4

FWIW, Guile 1.8.8 produces same output as ‘ok’ on a similar (sans the
‘use-modules’ and ‘uniform-vector-element-size’ noise) input, so i think
this situation is a regression.  Am i missing something?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
  read my lisp: (responsep (questions 'technical)
   (not (via 'mailing-list)))
 => nil


pgpIP6V3o_U0U.pgp
Description: PGP signature

bug#14128: web/http.scm: bad-header date check (UTC?)

[Thien-Thi Nguyen]

() Daniel Hartwig 
() Wed, 3 Apr 2013 17:47:01 +0800

   Apparently we are supposed to do this a bit more and accomodate yet
   another non-compliant service?

Maybe that stuff should be exposed to the user.  Do a best effort
conversion and if not successful, return a pair ‘(raw-string . STRING)’
or whatever -- it's enough that it has a different type and that the
type is documented.  This way, you avoid carrying forward lots of cruft.
Do it now before it's too late!

   Erk.  What is the point of defining protocols and standards then?

One purpose is to challenge programmers to learn how and when to say "no".

-- 
Thien-Thi Nguyen
GPG key: 4C807502


pgp8YeIY0NhOd.pgp
Description: PGP signature

bug#12892: ‘gc-stats’ w/o ‘bytes-malloced’

[Thien-Thi Nguyen]

() Andy Wingo 
() Thu, 07 Mar 2013 20:21:53 +0100

   [...] Dunno.

As an experiment, i've changed the cc to bug-guile in this response.
Maybe that will work.  Anyway, i'll followup w/ the debbugs folks.

-- 
Thien-Thi Nguyen
GPG key: 4C807502

bug#12892: ‘gc-stats’ w/o ‘bytes-malloced’

[Thien-Thi Nguyen]

In pre-2.x Guile, ‘gc-stats’ returns an alist w/ keys:

 gc-time-taken
 cells-allocated
 total-cells-allocated
 cell-heap-size
 bytes-malloced
 gc-malloc-threshold
 gc-times
 gc-mark-time-taken
 cells-marked
 cells-swept
 malloc-yield
 cell-yield
 protected-objects
 cell-heap-segments

In Guile 2.0.6, the keys are now:

 gc-time-taken
 heap-size
 heap-free-size
 heap-total-allocated
 heap-allocated-since-gc
 protected-objects gc-times

I think the NEWS should mention this change and the documentation should
summarize what the fields mean.  Practically speaking, i am interested
mostly in the 2.x equivalent for pre-2.x ‘bytes-malloced’, as its lack
causes Guile-SDL to fail "make check DEBUG=1":



.ttn.make-check.log.gz
Description: Binary data

by tripping up proc:

 (define (malloced)
   ;; prudence or superstition?  you be the judge!
   (gc) (gc)
   (assq-ref (gc-stats) 'bytes-malloced))
 
in test/leak.scm.  A related issue is how the error is reported.  It
seems strange that the file is "unknown".

-- 
Thien-Thi Nguyen . GPG key: 4C807502
.  NB: ttn at glug dot org is not me   .
. (and has not been since 2007 or so)  .
.ACCEPT NO SUBSTITUTES .
... please send technical questions to mailing lists ...


pgpw21Cvh0lLr.pgp
Description: PGP signature

Re: [Bug-autogen] test failure with guile-2.0.2

[Thien-Thi Nguyen]

() Thien-Thi Nguyen 
() Wed, 13 Jul 2011 17:01:17 +0200

   Try to jump up and see things from a perspective that includes the motion
   of the people who follow the leader.  That will make you a better leader.

A little bird had two things to say to me:
- that was a pretty wise-ass way to say things (w/ emphasis on ASS);
- what makes you an expert at being a leader?

To the first, i guess everyone is entitled to their preferred analogy.
Perhaps a better blend might have been to take the recent post by Andy wrt
lambda tribalism and draw the analogy between the benefits of functional style
programming and functional style interface design, or rather the latent woe
associated with their non-functional practice.  In this case, "semantics
changed while name unchanged" is basically a big fat ‘set!’ to the libguile
API.  Reasoning and optimizations are out the window because the trust is
broken.  We revert to coping behaviors and ugly gnashing (e.g., Guile-BAUX).

But i didn't have the energy to say that then, and this brings me to the
second answer: i am no expert at being a leader, but i know regret when i feel
it.  I feel regret now for not finding the energy then, but i also felt regret
then, as a feeling i would not wish upon Andy in the future, with the ‘set!’
fanout growing ever larger, with long-time Guile users dying a little inside
at every thought of balancing new-and-shiny cool w/ new-and-shiny pain, with
that soreness manifesting in mostly-offtopic threads, etc, etc.  That way lies
dissipation.

It doesn't need to be that way if with functional style interface design, but
of course, w/ more bindings, the burden of unfettered generation can indeed
weigh heavy.  Hopefully, this serves to push back onto the designer the need
to really think things through, to account for continuity and compatability in
the quest for new functionality.  I suppose the trick is to use the regret you
know you will feel to fuel the intensity of the design process, kind of like
consciously structuring code to avoid ‘set!’.

To get back on-topic, since the change was relatively recent, one way forward
would be to revert it and redesign.  We could simply say "ok, that was a
mistake, please avoid Guile 2.0.[01] (or whatever), sorry we will be more
careful in the future".  The other way is to do as Bruce suggests, add another
interface element.  To me, the former takes some chutzpah but is preferable
anyway -- it shows a balance of strength and gentleness, not to mention regret.

Re: [Bug-autogen] test failure with guile-2.0.2

[Thien-Thi Nguyen]

() Andy Wingo 
() Wed, 13 Jul 2011 15:41:42 +0200

   I realize that this is irritating to you, but it is the right thing,
   improves the situation for loads of users, and is largely compatible.

I think when you say "it is the right thing", you are missing the point.
Try to jump up and see things from a perspective that includes the motion
of the people who follow the leader.  That will make you a better leader.

Re: Typos in the manual

[Thien-Thi Nguyen]

() Mark Harig 
() Tue, 15 Feb 2011 22:03:39 -0500

   (Why do they miss the large similarities but see the small differences?)

This is a human condition that afflicts even programmers.

[bug #30167] libguile/Makefile.am ugly

[Thien-Thi Nguyen]

Update of bug #30167 (project guile):

 Summary: func-name (#define FUNC_NAME) check not applied
fully => libguile/Makefile.am ugly

___

Follow-up Comment #1:

Actually, both those files are indeed checked, so this is really a non-bug! 
(Nice mini-rant there, however...)

Changing the title.


___

Reply to this item at:

  

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/

[bug #30167] func-name (#define FUNC_NAME) check not applied fully

[Thien-Thi Nguyen]

URL:
  

 Summary: func-name (#define FUNC_NAME) check not applied
fully
 Project: Guile
Submitted by: ttn
Submitted on: gio 17 giu 2010 14:42:17 CEST
Category: None
Severity: 2 - Minor
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: ttn
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

In libguile/Makefile.am, the awk script guile-func-name-check is not being
applied to pairs.c and memoize.c because those files are not derivable from
the *DOT_DOC_FILES variables.  This incomplete coverage ensures ignorance of
(possible, future) func-name bugs there, which is undesirable.

Running the check manually on those files produces spurious warnings (false
positives), which is probably one reason why they were omitted in the first
place.

There are some related infelicities surrounding this situation:

1/ The awk script is run in the .c.doc pattern rule.  Is that really
necessary?  It's a static check -- why not move it some dedicated target, like
"make function-name-check", that can be called less frequently (by
maintainers)?  See 3/ below.

2/ The long lists of mostly-redundant filenames is bug-prone.  Better to
restructure the groupings additively and make use of Automake support for
$(VAR:OLD=NEW) syntax.

3/ It's awk.  That is an affront to my scheming sensibilities.
The doc extraction/processing flow tail already uses Scheme, why not the
nose, as well?!





___

Reply to this item at:

  

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/

Re: make-glil-local ?

[Thien-Thi Nguyen]

() Neil Jerram 
() Mon, 01 Mar 2010 19:28:07 +

   I'm sorry, I should have been clearer.  "correct" would mean
   that the bug, and hence the fix needed, is in the code that the
   warning is pointing to.  As opposed to the warning-generation
   code itself being bugged.

OK, that's what i suspected you meant.

   > Does this mean i'm not being cavalier in the right way?

   No :-)  It means I wasn't clear enough!

Thanks for explaining. :-)

thi

Re: make-glil-local ?

[Thien-Thi Nguyen]

() l...@gnu.org (Ludovic Courtès)
() Mon, 01 Mar 2010 00:54:05 +0100

   > Is the warning correct?

   Of course it is!  :-)

I don't understand the question or the answer.
(That is, what does "correct" mean?)

Does this mean i'm not being cavalier in the right way?

thi

Re: libguile/read.c warning

[Thien-Thi Nguyen]

() l...@gnu.org (Ludovic Courtès)
() Mon, 15 Feb 2010 10:26:49 +0100

   Which platform & compiler?

$ uname -a
Linux ambire 2.6.18-6-k7 #1 SMP Thu Nov 5 16:59:00 UTC 2009 i686 GNU/Linux
$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Inspection shows that (at least, as of commit 69f90b0b0):

  overflow = read_token (port, buffer, READER_CHAR_NAME_MAX_SIZE, &bytes_read);
  if (overflow)
goto char_error;

  ...

 char_error:
  scm_i_input_error (FUNC_NAME, port, "unknown character name ~a",
 scm_list_1 (charname));

if there is an overflow condition, `scm_i_input_error' is called with
`charname' not yet initialized.  This is in `scm_read_character',
which differs from the function indicated in the warning message.

I think the fix would be to do:
  if (overflow)
scm_i_input_error (FUNC_NAME, port, "character overflow error", SCM_EOL);

or somesuch.

   GNU/Linux builds at http://hydra.nixos.org/jobset/gnu/guile-master/all
   are done with ‘-Werror’ on GCC 4.4.3 and they don’t have this problem.

Yeah, i'm still clinging onto personal happiness on Debian Etch.  It's
high time for a dist-upgrade, but then again, look at all the interesting
bugs we find on the trailing edge! :-D

thi

libguile/read.c warning

[Thien-Thi Nguyen]

../../GG/libguile/read.c: In function 'scm_read_expression':
../../GG/libguile/read.c:893: warning: 'charname' may be used uninitialized in 
this function

make-glil-local ?

[Thien-Thi Nguyen]

There was a warning in about possibly undefined `make-glil-local'
in module/language/glil/decompile-assembly.scm and indeed i can't
find that symbol anywhere...

(This is from a "make clean ; make", but i unfortunately deleted
the *Compilation* buffer.)

thi

Re: [PATCH] Update configure script hints wrt precious env vars.

[Thien-Thi Nguyen]

() Andy Wingo 
() Wed, 13 Jan 2010 22:06:23 +0100

   Yes I tried that one, but it did the wrong thing.

How about `gnus-summary-pipe-output'?

thi

Re: [PATCH] Update configure script hints wrt precious env vars.

[Thien-Thi Nguyen]

() Andy Wingo 
() Wed, 13 Jan 2010 20:52:08 +0100

   I figured out how to use shell-command-on-region, M-|, so I
   don't care any more about whether there's comments before or
   after, though Ludovic is probably right about where they should
   go. So submit as you like.

See also `gnus-summary-pipe-message'.

thi

Re: [PATCH] Fix bug: Init auto var to unrandomize `stack_depth' rv.

[Thien-Thi Nguyen]

() l...@gnu.org (Ludovic Courtès)
() Wed, 13 Jan 2010 11:02:47 +0100

   I would advise adding explanatory comments in the code,
   rather than in the log.

Good point.  Will keep it in mind.

thi

[PATCH] Use `mkstemp' instead of `mktemp'.

[Thien-Thi Nguyen]

>From 030349a79946f992eb2bd58653c39321e9794e95 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Wed, 13 Jan 2010 09:49:44 +0100
Subject: [PATCH] Use `mkstemp' instead of `mktemp'.

* test-suite/standalone/test-unwind.c (check_ports):
Use `mkstemp' instead of `mktemp'.

Signed-off-by: Thien-Thi Nguyen 
---


According to mktemp(3):

BUGS
   Never  use  mktemp().  Some  implementations follow 4.3BSD and replace
   XX by the current process ID and a single letter, so that at  most
   26  different  names can be returned.  Since on the one hand the names
   are easy to guess, and on the other hand there is a race between test‐
   ing  whether  the  name  exists  and  opening  the  file, every use of
   mktemp() is a security risk.  The race is avoided by mkstemp(3).


 test-suite/standalone/test-unwind.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/test-suite/standalone/test-unwind.c 
b/test-suite/standalone/test-unwind.c
index f9820cc..f333c8c 100644
--- a/test-suite/standalone/test-unwind.c
+++ b/test-suite/standalone/test-unwind.c
@@ -210,7 +210,9 @@ check_ports ()
   strcpy (filename, tmpdir);
   strcat (filename, FILENAME_TEMPLATE);
 
-  if (mktemp (filename) == NULL)
+  /* Sanity check: Make sure that `filename' is actually writeable.
+ We used to use mktemp(3), but that is now considered a security risk.  */
+  if (0 > mkstemp (filename))
 exit (1);
 
   scm_dynwind_begin (0);
-- 
1.6.3.2

Re: [PATCH] Update configure script hints wrt precious env vars.

[Thien-Thi Nguyen]

>From eb2713038b601abd59fdf377847510f27fd17e83 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Sat, 9 Jan 2010 10:07:48 +0100
Subject: [PATCH] Update configure script hints wrt precious env vars.

* README: Don't suggest setting vars before running configure.
Instead, suggest specifying them on the configure command-line.

Signed-off-by: Thien-Thi Nguyen 
---
BTW, apparently, this is the space for comments;
"git am" should ignore all this stuff.

thi

 README |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/README b/README
index 5669ce8..ea68081 100644
--- a/README
+++ b/README
@@ -50,16 +50,19 @@ names (where that is supported), makes it impossible to 
later move the
 built executables and libraries to an installation location other than
 the one that was specified at build time.
 
-Another possible approach is to set CPPFLAGS and LDFLAGS before
-running configure, so that they include -I options for all the
+Another possible approach is to set CPPFLAGS and LDFLAGS on the
+configure command-line, so that they include -I options for all the
 non-standard places where you have installed header files and -L
 options for all the non-standard places where you have installed
 libraries.  This will allow configure and make to find those headers
-and libraries during the build.  The locations found will not be
-hardcoded into the build executables and libraries, so with this
-approach you will probably also need to set LD_LIBRARY_PATH
-correspondingly, to allow Guile to find the necessary libraries again
-at runtime.
+and libraries during the build.  E.g.:
+
+  ../configure [...] CPPFLAGS='-I/my/include' LDFLAGS='-L/my/lib'
+
+The locations found will not be hardcoded into the build executables and
+libraries, so with this approach you will probably also need to set
+LD_LIBRARY_PATH correspondingly, to allow Guile to find the necessary
+libraries again at runtime.
 
 
 Required External Packages 
@@ -93,8 +96,8 @@ Guile requires the following external packages:
 Guile's ./configure script uses pkg-config to discover the correct
 compile and link options for libgc.  If you don't have pkg-config
 installed, or you have a version of libgc that doesn't provide a
-.pc file, you can work around this by setting some environment
-variables before running ./configure:
+.pc file, you can work around this by setting some variables as
+part of the configure command-line:
 
 - PKG_CONFIG=true
 
-- 
1.6.3.2

Re: [PATCH] Declare `GC_dump' ourselves if doesn't.

[Thien-Thi Nguyen]

() l...@gnu.org (Ludovic Courtès)
() Tue, 12 Jan 2010 18:19:44 +0100

   > | dnl See note for PKG_CHECK_MODULES in aclocal.m4.
   > | PKG_PROG_PKG_CONFIG
   > | if test "$BDW_GC_CFLAGS" || test "$BDW_GC_LIBS" ; then :
   > |   dnl We don't need to declare those env vars precious;
   > |   dnl PKG_CHECK_MODULES does that.
   > | else
   > |   PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
   > | fi

   This patch shouldn’t be necessary since it duplicates what
   ‘PKG_CHECK_MODULES’ does.

Not exactly.  If there is no bdw-gc.pc on the system (as is the
case here on a Debian Etch installation),  PKG_CHECK_MODULES dies,
and so does the configure script.  The original README recommends
in such case to munge three variables.  Two of them are valid:
BDW_GC_CFLAGS and BDW_GC_LIBS.  The other (PKG_CONFIG) is bogus
because munging it interferes with "make installcheck".

   ... without reading ‘README’, so you basically shoot yourself
   in the foot and there’s not much we can do.  :-)

I don't know where you got that idea.  Here's what actually
happened: I read the README, applied the bogus advice, noticed the
breakage, and then worked on the patch so that the now-updated
README gives good advice, supported by the now-updated configure
script.  Lastly, i posted the patch for review.

There IS something you can do: take a stand against pkg-config and
DTRT (the Autoconf Way).  I know there are other packages that are
heavily reliant on pkg-config, but Guile doesn't seem to be one of
them.  You can do this by helping identify what are the features
of libgc (whatever version) that Guile requires.  With that info,
it would not be hard to write a test for the configure script.
So, please help answer that question (if you can).

thi

Re: [PATCH] Declare `GC_dump' ourselves if doesn't.

[Thien-Thi Nguyen]

() l...@gnu.org (Ludovic Courtès)
() Tue, 12 Jan 2010 15:17:06 +0100

   So how did ‘configure’ find your libgc?

I've modified configure.ac (see "Don't clobber..." patch) to look like:

| dnl See note for PKG_CHECK_MODULES in aclocal.m4.
| PKG_PROG_PKG_CONFIG
| if test "$BDW_GC_CFLAGS" || test "$BDW_GC_LIBS" ; then :
|   dnl We don't need to declare those env vars precious;
|   dnl PKG_CHECK_MODULES does that.
| else
|   PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
| fi

Then, i call configure like so:

$ .../configure -C \
  --with-threads \
  --prefix /tmp/a/b/z \
  BDW_GC_LIBS='-lgc' \
  LDFLAGS='-L/home/ttn/local/lib'

(The `LDFLAGS' is incidentally for finding libltdl.)

thi

Re: [PATCH] Declare `GC_dump' ourselves if doesn't.

[Thien-Thi Nguyen]

() l...@gnu.org (Ludovic Courtès)
() Mon, 11 Jan 2010 23:09:15 +0100

   Andy Wingo  writes:

   > On Sat 09 Jan 2010 14:28, Thien-Thi Nguyen  writes:
   >
   >> +# `GC_dump' is available in GC 6.8 but not declared.
   >
   > Neil, you also compile with pre-7.x, no? Do we need to support this?

   No.  Normally checking for bdw-gc.pc rules out 6.8, but apparently
   Debian (?) is shipping the .pc file for 6.8 too.

Debian Etch doesn't ship with a .pc file (AFAICT).
I infer the version from the output of

  M-x apt-utils-show-package RET libgc-dev RET

reproduced below.  Am i missing something?

thi

___
Package: libgc-dev (Installed)
Priority: optional
Section: libdevel
Installed-Size: 516
Maintainer: Ryan Murray 
Architecture: i386
Source: libgc
Version: 1:6.8-1
Depends: libgc1c2 (= 1:6.8-1), libc-dev
Filename: pool/main/libg/libgc/libgc-dev_6.8-1_i386.deb
Size: 160808
MD5sum: 8fd9c6b5451059499b79c4334e907c87
SHA1: bc60de45dbd3b506497ec6a697e959ea6858
SHA256: e7cbb58a14758a914168fa617e5f3b0a46f9f703e481a00d805047862c98663f
Description: conservative garbage collector for C (development)
 Boehm's GC is a garbage collecting storage allocator that is
 intended to be used as a plug-in replacement for C's malloc.
 This package is required to compile and link programs that use
 libgc1.
 .
 Since the collector does not require pointers to be tagged, it does
 not attempt to ensure that all inaccessible storage is reclaimed.
 However it has typically been more successful at reclaiming unused
 memory than most C programs using explicit deallocation.  Unlike
 manually introduced leaks, the amount of unreclaimed memory typically
 stays bounded.
 .
 This version of the collector is thread safe, has C++ support, and uses the
 defaults for everything else.  Particularly, it does not work as a malloc()
 replacement.

Re: [PATCH] Declare `GC_dump' ourselves if doesn't.

[Thien-Thi Nguyen]

() l...@gnu.org (Ludovic Courtès)
() Mon, 11 Jan 2010 23:32:57 +0100

   l...@gnu.org (Ludovic Courtès) writes:

   > Guile doesn’t requires 7.x (the ‘README’ file says so.)

   I meant “Guile requires 7.x”.

Hmm, requiring versions is not the Autoconf Way.  What feature /
interface elements of libgc 7.x could we use in the configure
script to check for it?  If someone would tell me this (or point
me towards a 6 vs 7 comparison relevant to Guile), i will prepare
a new patch.

thi

Re: [PATCH] Fix bug: Init auto var to unrandomize `stack_depth' rv.

[Thien-Thi Nguyen]

() Andy Wingo 
() Sat, 09 Jan 2010 23:29:34 +0100

   Applied, along with some other patches.

Cool, thanks.

   If you're going to send patches like this, I'm very happy to
   apply them; but it would be easier for me if you just sent the
   messages produced by git-format-patch, so I could just pipe
   your whole message through git-am.

   As it is I have to edit the commit logs to cut until the
   git-format-patch body.

Often i include some kind of commentary describing the patch or
the motivation of the patch, etc.  Where should i include that
info?  Maybe "git-format-patch --attach"?

thi

Re: [PATCH] Update configure script hints wrt precious env vars.

[Thien-Thi Nguyen]

() Andy Wingo 
() Sat, 09 Jan 2010 23:31:55 +0100

   >  .pc file, you can work around this by setting some environment
   > -variables before running ./configure:
   > +as part of the configure command-line:

   Can you fix this one and resend?

Yes, if you can tell me what's wrong w/ the above.

thi

[PATCH] Fix bug: Don't clobber `PKG_CONFIG' when overriding pkg-config search for bdw-gw.

[Thien-Thi Nguyen]

`PKG_CONFIG' is AC_SUBSTed into one of the "make installcheck" tests,
so clobbering it results in "make installcheck" failure.

With this change (and building upon previously submitted patches), i can:

$ .../configure -C \
--with-threads \
--prefix /tmp/a/b/z \
BDW_GC_LIBS='-lgc' \
LDFLAGS='-L/home/ttn/local/lib'
$ make all check install installcheck

to an empty /tmp/a/b/z directory on a Debian Etch Sempron (~35 minutes).
Moving right along!

thi

_
>From d6d765a2fcb0354146be6492a1212d5ad45fa385 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Sat, 9 Jan 2010 22:40:10 +0100
Subject: [PATCH] Fix bug: Don't clobber `PKG_CONFIG' when overriding pkg-config 
search for bdw-gw.

* configure.ac (PKG_PROG_PKG_CONFIG): New top-level call.
(PKG_CHECK_MODULES): Call only if both vars `BDW_GC_FLAGS'
and `BDW_GC_LIBS' have no, or empty, value.
* README: Remove bogus advice to specify "PKG_CONFIG=true".

Signed-off-by: Thien-Thi Nguyen 
---
 README   |3 ---
 configure.ac |9 -
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/README b/README
index e799495..55bfad2 100644
--- a/README
+++ b/README
@@ -99,10 +99,7 @@ Guile requires the following external packages:
 .pc file, you can work around this by setting some environment
 as part of the configure command-line:
 
-- PKG_CONFIG=true
-
 - BDW_GC_CFLAGS=
-
 - BDW_GC_LIBS=
 
 
diff --git a/configure.ac b/configure.ac
index 78c6418..20e2d62 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1222,7 +1222,14 @@ main ()
 # Boehm's GC library
 #
 #
-PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
+dnl See note for PKG_CHECK_MODULES in aclocal.m4.
+PKG_PROG_PKG_CONFIG
+if test "$BDW_GC_CFLAGS" || test "$BDW_GC_LIBS" ; then :
+  dnl We don't need to declare those env vars precious;
+  dnl PKG_CHECK_MODULES does that.
+else
+  PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
+fi
 
 CFLAGS="$BDW_GC_CFLAGS $CFLAGS"
 LIBS="$BDW_GC_LIBS $LIBS"
-- 
1.6.3.2

[PATCH] Fix bug: Use correct `FUNC_NAME' for `scm_macro_binding'.

[Thien-Thi Nguyen]

Basta con la copy pasta!
(Enough of the copy/paste errors! ;-D)

thi

_
>From bf621def5b353221f486fe3a7c369120ba5a0c57 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Sat, 9 Jan 2010 15:09:15 +0100
Subject: [PATCH] Fix bug: Use correct `FUNC_NAME' for `scm_macro_binding'.

* libguile/macros.c (scm_macro_binding): Use correct FUNC_NAME.

Signed-off-by: Thien-Thi Nguyen 
---
 libguile/macros.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libguile/macros.c b/libguile/macros.c
index edb6538..b3fea93 100644
--- a/libguile/macros.c
+++ b/libguile/macros.c
@@ -170,7 +170,7 @@ SCM_DEFINE (scm_macro_binding, "macro-binding", 1, 0, 0,
"Return the binding of the syntax transformer @var{m}, as passed 
to\n"
 "@code{make-syntax-transformer}. If @var{m} is a primitive 
syntax\n"
 "transformer, @code{#f} will be returned.")
-#define FUNC_NAME s_scm_macro_transformer
+#define FUNC_NAME s_scm_macro_binding
 {
   SCM_VALIDATE_MACRO (1, m);
   return SCM_MACRO_BINDING (m);
-- 
1.6.3.2

[PATCH] Add cast in `make_vm' to silence compiler warning.

[Thien-Thi Nguyen]

As advertized...

thi

___
>From e08a92c5f21bab837ab051f5f1866cd066938262 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Sat, 9 Jan 2010 15:05:34 +0100
Subject: [PATCH] Add cast in `make_vm' to silence compiler warning.

* libguile/vm.c (make_vm): Add cast for .stack_base assignment.

Signed-off-by: Thien-Thi Nguyen 
---
 libguile/vm.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libguile/vm.c b/libguile/vm.c
index 0da915b..9f4a2d8 100644
--- a/libguile/vm.c
+++ b/libguile/vm.c
@@ -346,8 +346,8 @@ make_vm (void)
   vp->stack_size  = VM_DEFAULT_STACK_SIZE;
 
 #ifdef VM_ENABLE_PRECISE_STACK_GC_SCAN
-  vp->stack_base = GC_generic_malloc (vp->stack_size * sizeof (SCM),
- vm_stack_gc_kind);
+  vp->stack_base = (SCM *)
+GC_generic_malloc (vp->stack_size * sizeof (SCM), vm_stack_gc_kind);
 
   /* Keep a pointer to VP so that `vm_stack_mark ()' can know what the stack
  top is.  */
-- 
1.6.3.2

[PATCH] Update configure script hints wrt precious env vars.

[Thien-Thi Nguyen]

Personally, i dislike environment variable dependence.
Maybe that's exposure to lexical binding poisoning my tastes...
In any case, (info "(autoconf) Defining Variables") has more info.

thi

_
>From 7a7b846cc2eb1f6aadfb06ccb445642f2bc2dfa7 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Sat, 9 Jan 2010 10:07:48 +0100
Subject: [PATCH] Update configure script hints wrt precious env vars.

* README: Don't suggest setting vars before running configure.
Instead, suggest specifying them on the configure command-line.

Signed-off-by: Thien-Thi Nguyen 
---
 README |   19 +++
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/README b/README
index 5669ce8..e799495 100644
--- a/README
+++ b/README
@@ -50,16 +50,19 @@ names (where that is supported), makes it impossible to 
later move the
 built executables and libraries to an installation location other than
 the one that was specified at build time.
 
-Another possible approach is to set CPPFLAGS and LDFLAGS before
-running configure, so that they include -I options for all the
+Another possible approach is to set CPPFLAGS and LDFLAGS on the
+configure command-line, so that they include -I options for all the
 non-standard places where you have installed header files and -L
 options for all the non-standard places where you have installed
 libraries.  This will allow configure and make to find those headers
-and libraries during the build.  The locations found will not be
-hardcoded into the build executables and libraries, so with this
-approach you will probably also need to set LD_LIBRARY_PATH
-correspondingly, to allow Guile to find the necessary libraries again
-at runtime.
+and libraries during the build.  E.g.:
+
+  ../configure [...] CPPFLAGS='-I/my/include' LDFLAGS='-L/my/lib'
+
+The locations found will not be hardcoded into the build executables and
+libraries, so with this approach you will probably also need to set
+LD_LIBRARY_PATH correspondingly, to allow Guile to find the necessary
+libraries again at runtime.
 
 
 Required External Packages 
@@ -94,7 +97,7 @@ Guile requires the following external packages:
 compile and link options for libgc.  If you don't have pkg-config
 installed, or you have a version of libgc that doesn't provide a
 .pc file, you can work around this by setting some environment
-variables before running ./configure:
+as part of the configure command-line:
 
 - PKG_CONFIG=true
 
-- 
1.6.3.2

[PATCH] Declare `GC_dump' ourselves if doesn't.

[Thien-Thi Nguyen]

This patch removes a harmless but annoying warning.

thi

___
>From 39fd870610ff2cc1177e0cd0aba845806f0213c6 Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Sat, 9 Jan 2010 14:17:20 +0100
Subject: [PATCH] Declare `GC_dump' ourselves if  doesn't.

* configure.ac: Check for `GC_dump' declaration.
Define `HAVE_DECL_GC_DUMP' if  provides it.
* libguile/gc.c [!HAVE_DECL_GC_DUMP] (GC_dump): Declare it.

Signed-off-by: Thien-Thi Nguyen 
---
 configure.ac  |8 
 libguile/gc.c |4 
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5143dcc..78c6418 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1227,6 +1227,14 @@ PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
 CFLAGS="$BDW_GC_CFLAGS $CFLAGS"
 LIBS="$BDW_GC_LIBS $LIBS"
 
+# `GC_dump' is available in GC 6.8 but not declared.
+AC_CHECK_FUNCS([GC_dump])
+AC_CHECK_DECL([GC_dump],
+  [AC_DEFINE([HAVE_DECL_GC_DUMP], [1],
+[Define this if the `GC_dump' function is declared])],
+  [],
+  [#include ])
+
 # `GC_do_blocking ()' is available in GC 7.1 but not declared.
 AC_CHECK_FUNCS([GC_do_blocking])
 AC_CHECK_DECL([GC_do_blocking],
diff --git a/libguile/gc.c b/libguile/gc.c
index 700f3a4..295b663 100644
--- a/libguile/gc.c
+++ b/libguile/gc.c
@@ -69,6 +69,10 @@ extern unsigned long * 
__libc_ia64_register_backing_store_base;
 #include 
 #endif
 
+#ifndef HAVE_DECL_GC_DUMP
+extern void GC_dump (void);
+#endif
+
 /* Lock this mutex before doing lazy sweeping.
  */
 scm_i_pthread_mutex_t scm_i_sweep_mutex = SCM_I_PTHREAD_MUTEX_INITIALIZER;
-- 
1.6.3.2

[PATCH] Fix bug: Init auto var to unrandomize `stack_depth' rv.

[Thien-Thi Nguyen]

Below is a revised patch, with updated ChangeLog entry
(includes "libguile/" prefix).

thi



>From 666e9de72a7dbaff3ee67a77b3efc981b33c44eb Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen 
Date: Sat, 9 Jan 2010 09:12:49 +0100
Subject: [PATCH] Fix bug: Init auto var to unrandomize `stack_depth' rv.

* libguile/stacks.c (stack_depth): Init `n'.

Signed-off-by: Thien-Thi Nguyen 
---
 libguile/stacks.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libguile/stacks.c b/libguile/stacks.c
index 61b7be3..ce16063 100644
--- a/libguile/stacks.c
+++ b/libguile/stacks.c
@@ -66,7 +66,7 @@ static SCM stack_id_with_fp (SCM frame, SCM **fp);
 static long
 stack_depth (SCM frame, SCM *fp)
 {
-  long n;
+  long n = 0;
   /* count frames, skipping boot frames */
   for (; scm_is_true (frame) && SCM_VM_FRAME_FP (frame) > fp;
frame = scm_frame_previous (frame))
-- 
1.6.3.2

[PATCH] Fix bug: Init auto var to unrandomize `stack_depth' rv.

[Thien-Thi Nguyen]

First patch to Guile 1.9!

I prepared the following with "git format-patch -s", recopying the
Subject line, sans "[PATCH] ", and prefixing with a horizontal rule.
Is this ok?  Do you prefer some other format?  Most importantly:
Am i on the right path to regaining official repo write privs?

thi

___
Fix bug: Init auto var to unrandomize `stack_depth' rv.

* stacks.c (stack_depth): Init `n'.

Signed-off-by: Thien-Thi Nguyen 
---
 libguile/stacks.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libguile/stacks.c b/libguile/stacks.c
index 61b7be3..ce16063 100644
--- a/libguile/stacks.c
+++ b/libguile/stacks.c
@@ -66,7 +66,7 @@ static SCM stack_id_with_fp (SCM frame, SCM **fp);
 static long
 stack_depth (SCM frame, SCM *fp)
 {
-  long n;
+  long n = 0;
   /* count frames, skipping boot frames */
   for (; scm_is_true (frame) && SCM_VM_FRAME_FP (frame) > fp;
frame = scm_frame_previous (frame))
-- 
1.6.3.2

Re: Guile 1.9: bug in load

[Thien-Thi Nguyen]

() Andy Wingo 
() Mon, 16 Nov 2009 20:23:07 +0100

   However the use case is important. We need to implement a (current-file)
   macro, I think, which should allow for file-relative loads.

Is `current-load-port' still around for official Guile?
If so,

(define (current-file)
  (port-filename (current-load-port)))

might be sufficient.

thi

Re: guile 1.9.0 scm_read_hash_extend gc trouble

[Thien-Thi Nguyen]

() "Bill Schottstaedt" 
() Sun, 21 Jun 2009 05:10:09 -0700

   code to implement #|..|# block comment processing triggers either a
   glibc memory complaint or a segfault.

FWIW, below is the implementation from Guile 1.4.1.118 (not yet released).
It handles nesting (per R6RS, i believe) and a weird lookahead case.

thi

_
/* Skip #|...|# block comments.  */

static void
skip_hashpipe_block_comment (SCM port)
{
#define FUNC_NAME s_scm_read
  int c;
  bool pipep = false;
  int oline = SCM_LINUM (port);
  int ocol = SCM_COL (port);

  for (;;)
{
  if (EOF == (c = GETC ()))
  toosoon:
{
  char buf[149];

  snprintf (buf, 149, "%s\n%s:%d:%d: (starting here)",
"unterminated `#| ... |#' comment",
c_port_filename (port),
1 + oline, ocol - 1);
  BADNESS (0, buf);
}

  if (pipep && '#' == c)
return;

  /* Handle nested comments.  */
retry:
  if ('#' == c)
{
  if (EOF == (c = GETC ()))
goto toosoon;
  if ('|' == c)
{
  skip_hashpipe_block_comment (port);
  pipep = false;
}
  else
/* Don't get fooled by ##|...|# (ugh).  */
goto retry;
}

  pipep = ('|' == c);
}
#undef FUNC_NAME
}

Re: string-ci* oddity

[Thien-Thi Nguyen]

FYI, below is the code that all ci comparison
funcs will be using in the next Guile 1.4.x release.

This means, for example:
(char-ci #f.

thi


___
// libguile/chars.c

#define ISLOWER(c)  (islower (c) ? (1 + c - 'a') : 0)
#define ISUPPER(c)  (isupper (c) ? (1 + c - 'A') : 0)

static int
ccmp_ci (int x, int y)
{
  int lx, ux = 0, ly, uy = 0, rv;

  rv = ((! ((lx = ISLOWER (x)) || (ux = ISUPPER (x
||
(! ((ly = ISLOWER (y)) || (uy = ISUPPER (y)
/* One or both do not satisfy `isalpha'; subtract directly.  */
? (x - y)
/* Both satisfy `isalpha'; subtract in one domain or another.  */
: (lx
   ? (lx - (ly
? ly
: uy))
   : (ux - (uy
? uy
: ly)));
  return !rv
? 0
: (GOOD (rv)
   ?  1
   : -1);
}

Re: string-ci* oddity

[Thien-Thi Nguyen]

() "Bill Schottstaedt" 
() Fri, 19 Dec 2008 06:55:21 -0800

   Why do both Guile and Gauche give this result in string-ci

[patch] maintain output column

[Thien-Thi Nguyen]

before, we see:
(guile-user) (port-column (current-output-port))
13

after, we see:
(guile-user) (port-column (current-output-port))
0

here is the ChangeLog entry for guile 1.4.x:

2007-11-13  Thien-Thi Nguyen  <[EMAIL PROTECTED]>

* running-repls.scm (scm-style-repl consume-trailing-whitespace):
On #\newline, zero the output port's column.

i'm sure you can figure out where this would fit for other versions.

thi



--- running-repls.scm   12 Sep 2007 12:50:46 -  1.22
+++ running-repls.scm   13 Nov 2007 14:12:55 -  1.23
@@ -287,6 +287,9 @@
   (read-char)
   (consume-trailing-whitespace))
  ((char=? ch #\newline)
+  ;; Conspire w/ the typical user interface (ok, let's just be frank:
+  ;; Emacs' comint.el or derivative) to keep things straight.
+  (set-port-column! (current-output-port) 0)
   (read-char)
 
 (define (-read)



___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Need to include autoconf.texi into Ref Manual guile.texi

[Thien-Thi Nguyen]

() [EMAIL PROTECTED] (Ludovic Courtès)
() Fri, 10 Aug 2007 09:58:49 +0200

   I'd like to know what others think.

i think by end of 2007 we should aim to merge guile 1.4.x niceties
(including autofrisk and other reflective and otherwise things) into
guile HEAD, assuming there is some aligned interest.  the auto* tools
interop and documentation[1] is one of the areas that would benefit.

sooner is better, since next guile 1.4.x will be released under GPLv3 or
later (note: NOT *L*GPL), at which point merging from 1.4.x to HEAD can
be drearily complicated for HEAD maintainers (although the reverse, from
HEAD to 1.4.x, won't pose any problems for me).

thi


[1]
http://www.gnuvola.org/software/guile/doc/Using-Autoconf-Macros.html
http://www.gnuvola.org/software/guile/doc/index.html


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: [bug #20056] guile 1.8.1 regular expressions die on #nul (character zero) in operand

[Thien-Thi Nguyen]

() Gregory Marton <[EMAIL PROTECTED]>
() Sun, 03 Jun 2007 01:29:35 +

   This used to work in guile 1.3.4 but I haven't
   checked the versions in between.

data point:

 guile> (version)
 "1.4.1.107.9.0.7"
 guile> (regexp-exec (make-regexp ".") (string #\nul))
 #f
 
thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile-www 1.1.1 & 2.16 problems under guile 1.8.

[Thien-Thi Nguyen]

() [EMAIL PROTECTED] (r. clayton)
() 11 May 2007 19:25:51 -0400

   I downloaded 2.16 and 2.18 and both installed correctly.

i'm glad to hear that.

(let's hope next release maintains this property. :-)

thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile-www 1.1.1 & 2.16 problems under guile 1.8.

[Thien-Thi Nguyen]

() [EMAIL PROTECTED] (Ludovic Courtès)
() Fri, 11 May 2007 16:43:09 +0200

   Nice that it can detect such things and adapt!

that's the theory, anyway.

   However, the `s/make-shared-substring/substring/' occurs only at
   module-installation time, which precludes one from running the examples
   from within the source directory.

good point.  i hadn't thought of that.

   Also, while `id.cgi' DTRT (except for `make-shared-substring') so
   that it can be run from within the source directory, `you-are-here'
   just makes plain `use-modules' that are bound to fail when invoked
   from within the source directory.

true.

   Maybe all the modules could be moved to a `www' subdir, and then
   examples could be generated from `.in' files at configure-time that
   start with something like:

 ${GUILE-guile} -L @top_srcdir@ ...

   This way, `(use-modules (www ...))' would work fine.

   What do you think?

i think the approach (or something like it) is sound.  certainly making
the modules and examples usable pre-install is a worthy goal.  thanks
for the suggestion.

thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile-www 1.1.1 & 2.16 problems under guile 1.8.

[Thien-Thi Nguyen]

() [EMAIL PROTECTED] (Ludovic Courtès)
() Fri, 11 May 2007 09:16:31 +0200

   So your fix seems reasonable, _provided_ `guile-www' doesn't rely on
   string mutations and interactions between substrings and their parent
   string.

the easy way is to use configure script option --disable-shsub.  i have
updated the README to mention this for the next release (2.19), like so:

You can use the configure script option `--disable-shsub' to
explicitly build a version where `make-shared-substring' is
replaced w/ simply `substring'.  By default, configure arranges
for the replacement only if it can't detect that your Guile has
`make-shared-substring'.

if the configure script is NOT detecting missing `make-shared-substring',
then that's a bug -- please post the output of the ./configure run (w/o
the `--disable-shsub' option).

   Maybe you could provide him with a patch allowing `guile-www'
   to be used with both Guile versions?

this should likewise be handled automatically by configure (if not,
that's a bug).  in the configure run output, there should be something
like "acts like (ice-9 optargs-kw) ...yes", and the installation script
module-install will read `need_optargs_kludge="no"'.

improvements to the detection routines welcome, in any case!

thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Failure while building Guile-SDL 0.3.6.

[Thien-Thi Nguyen]

() [EMAIL PROTECTED] (Ludovic Courtès)
() Mon, 02 Apr 2007 10:02:33 +0200

   [EMAIL PROTECTED] (r. clayton) writes:

   > I was trying to build http://www.gnuvola.org/software/guile-sdl/
   > under guile-1.8 on a debian testing system (updated weekly) and ran
   > into a problem:

   You should direct this question to its maintainer, Thien-Thi Nguyen
   <[EMAIL PROTECTED]> (not sure whether he reads this list).

the error seemed to emanate from __scm.h.  unfortunately, the grep
output was not useful to figure out the nature of the problem.  perhaps
"grep -C 10" will show more info.

thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile 1.4 compilation error with gcc4

[Thien-Thi Nguyen]

   From: Aaron Voisine <[EMAIL PROTECTED]>
   Date: Sat, 20 Aug 2005 14:38:16 -0700

scm_make_gsubr (s_ ## scm_acons,  3,  0,  0, (SCM (*)()) scm_acons); 

   configure options as follows:

   export LIBRARY_PATH=/sw/lib
   export CPPFLAGS=-no-cpp-precomp
   export CPATH=/sw/include
   ./configure --prefix=/sw --infodir=/sw/share/info

on first glance, the CPPFLAGS looks suspicious.  the ## is supposed to
"glue" the tokens surrounding it together producing a single identifier,
in this case `s_scm_acons', during the C preprocessing pass.  thus
options that disable (or otherwise inhibit normal operation) of the C
preprocessor are questionable.  what happens when you configure without
setting CPPFLAGS?  (why is it necessary to set it?)

   and the configure output: [...]

ok, i'll save this to compare w/ the non-CPPFLAGS output (unless we get
lucky and things magically work w/o further investigation :-).

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile 1.4 compilation error with gcc4

[Thien-Thi Nguyen]

   From: Aaron Voisine <[EMAIL PROTECTED]>
   Date: Fri, 19 Aug 2005 23:42:59 -0700

   I'm trying to compile guile 1.4 with apple's gcc 4.0.0 (from xcode
   tools 2.2 preview 1) and I get the following compilation error:

   [...]
   ../libguile/alist.x:5: error: stray '##' in program

   looking at alist.x the syntax doesn't look like anything i've ever
   seen in k&r (course I'm no expert). Any ideas?

could you post the first few lines of alist.x?  this file is generated
at compile-time, and should not be in the distribution tarball -- if it
is, that's probably (another) methodology bug.

please also post the output of running the configure script, including
some mention of what options you passed to it, etc.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile-www-2.9 (www cgi) Tests for query-string parsing

[Thien-Thi Nguyen]

   From: Alan Grover <[EMAIL PROTECTED]>
   Date: Mon, 11 Apr 2005 21:16:26 -0400

   This script [...]

thanks for posting this.  i have touched it up a bit (attached), and
used it to verify operation of recently installed changes to cgi.scm
(available, along w/ other changes, from cvs).  the "not necessary"
comment reflects the thinking that introducing a var is a step away
from the encapsulation work that cgi.scm needs prior to the next
guile-www release.

basically, it's ok to add procedures to the module's interface, but
not so ok to add data structures.  if possible, it's even better to
avoid adding new interface elements altogether, instead extending
the current procedures by adding optional args, so that they work w/
old code.

more on this later...

thi




ag-check
Description: Binary data
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile-www uses obsolete optargs-kw

[Thien-Thi Nguyen]

   From: Alan Grover <[EMAIL PROTECTED]>
   Date: Mon, 11 Apr 2005 20:45:23 -0400

   It appears that module (ice-9 optargs-kw) is
   renamed (ice-9 optargs) in guile 1.6.4?

originally, (ice-9 optargs) used #& style keywords.  at
some point, someone changed it to use #: style keywords,
which broke all the code using the old style.  in 1.4.x,
there is both (ice-9 optargs) and (ice-9 optargs-kw), so
as to be able to support both #& and #: style (perhaps
"uncleanly" but nonetheless).  to accomodate 1.6.x and
other forgetful guiles, the guile-www configure script
checks the behavior of the installed "(ice-9 optargs)"
module; if it seems to support #: then during guile-www
installation, the references to "(ice-9 optargs-kw)" are
rewritten without the "-kw".  see script "module-install"
for gory details.

the upshot is that if you are using guile 1.6.x,
guile-www "make install" should DTRT.  that has worked
for awhile because "make check" doesn't do anything;
there has been no need to use pre-installed modules.

however, i see that you are doing some testing (cool!),
so perhaps we need to move this particular kludge to
"make all" time, to support pre-installed usage on those
systems w/o (ice-9 optargs-kw).

thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile-www-2.9 (www cgi) does not support mod-lisp/fastcgi style uses

[Thien-Thi Nguyen]

   From: Alan Grover <[EMAIL PROTECTED]>
   Date: Mon, 11 Apr 2005 19:44:37 -0400

   [patch]

   I'm working on a suggested change to (www cgi) that will
   include this patch. It should be available within the
   next 2 days.

i've just installed changes to the env var support.  the
gist is that promises are no longer used, there is a hash
table instead of the alist, and the table is updated on
every call to `cgi:init'.  i think this should be enough to
support fastcgi, but have not tested it.

btw, anoncvs instructions are in dir:
http://www.glug.org/people/ttn/software/guile-www/

thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: guile-www-2.9 (www cgi) names in query-string not url-decoded

[Thien-Thi Nguyen]

   From: Alan Grover <[EMAIL PROTECTED]>
   Date: Mon, 11 Apr 2005 19:10:24 -0400

   cgi.scm

   286c286
   <   (and p (subs pair 0 p
   ---
>   (and p (url-coding:decode (subs pair 0 p)

thanks, installed.

here is the ChangeLog entry i used:

2005-04-12  Alan Grover  <[EMAIL PROTECTED]>  (tiny change)

* cgi.scm (parse-form): Fix omission bug:
Also url-decode name in each name/value pair.

feel free to include something along these lines for future patches.
(also, i find "diff -u" output easier to evaluate.)

thi


___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Bug in http module of guile-www

[Thien-Thi Nguyen]

   From: Robert Marlow <[EMAIL PROTECTED]>
   Date: Wed, 14 Jul 2004 15:38:17 +0800

   I happened accross a bug in the HTTP module of guile-www which seemed to
   trigger when I visited a page which gave no headers and just whitespace
   in the body. In such a case the variable "second" of parse-status-line
   gets bound to #f which messes up the later make-shared-substrings which
   use it.

in the status line (which has the form: VERSION CODE TEXT), i believe
TEXT is optional, but i don't have the http spec (RFC 2616) handy to
confirm this.  if TEXT is actually optional, that indicates a bug in
http.scm.  if TEXT is required, that indicates a bug in the server's
http implementation.

note that the status line cannot be omitted altogether; the most minimal
valid HTTP response a server can send is STATUS-LINE, CRLF, CRLF.  you
may wish to check the server response for conformance using a command
like "w3m -dump_head" or similar.

   [patch]

unfortunately the patch is incorrect because it allows the possibility
to derive #f for CODE, which is illegal (CODE must be a 3-digit sequence
like "404" or "200").  assuming TEXT is indeed optional, i have changed
`parse-status-line' (in cvs) to handle a missing TEXT component by
returning the empty string.  the proc now reads as follows:

(define (parse-status-line statline)
  ;; Handle: VERSION CODE
  ;; as well as: VERSION CODE TEXT
  ;; For the former, use the null string for TEXT.
  (let* ((first (string-index statline #\space))
 (second (string-index statline #\space (1+ first
(list (make-shared-substring statline 0 first)
  (make-shared-substring statline (1+ first)
 (or second (string-length statline)))
  (if second
  (make-shared-substring statline (1+ second))
  ""

and will appear in guile-www 2.6 (to be released shortly).

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: fink guile make error

[Thien-Thi Nguyen]

   From: Chris Beamis <[EMAIL PROTECTED]>
   Date: Thu, 4 Dec 2003 20:28:16 -0800

   [...]
   ld: warning -dylib_install_name /sw/lib/libguile.9.dylib not found in 
   segment address table LD_SEG_ADDR_TABLE 
   /sw/var/lib/fink/prebound/seg_addr_table
   ld: warning -undefined suppress disables -prebind

i don't undertstand these warnings.

   [...]
   /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -Wmissing-prototypes 
   -L/sw/lib -o guile -dlpreopen force guile.o libguile.la  -lm
   rm -f .libs/guile.nm .libs/guile.nmS .libs/guile.nmT
   creating .libs/guileS.c
   (cd .libs && gcc -c -fno-builtin "guileS.c")
   rm -f .libs/guileS.c .libs/guile.nm .libs/guile.nmS .libs/guile.nmT
   gcc -g -O2 -Wall -Wmissing-prototypes -L/sw/lib -o .libs/guile 
   .libs/guileS.o guile.o -L.libs -lguile -ldl -lm -lm
   ld: warning prebinding disabled because dependent library: 
   /sw/lib/libguile.12.dylib is not prebound
   ld: warning multiple definitions of symbol _environ
   /usr/lib/crt1.o definition of _environ in section (__DATA,__data)
   /sw/lib/libguile.dylib(libguile.12.3.0.dylib-master.o) definition of 
   _environ
   ld: Undefined symbols:
   _lt_dlpreload_default

to fix the lt_dlpreload_default problem probably requires that you
determine whether or not that symbol is available in the libltdl
installed on your system.  i don't know how to go about that remotely,
but if you give me an account on your machine i can try to look into it.
(ping me off-list if you are amenable.  same goes for any osx users
reading this.  gpg key: )

to fix the "environ" problem, change the naked "extern char **environ;"
in posix.c to read like so:

#ifdef __APPLE__
#include 
__private_extern__ char **environ;
#else
extern char **environ;
#endif

you can hint the guile-w/-fink maintainer to look at:

 http://www.glug.org/snap/core-1-4/libguile/posix.c

where one can see this change applied in guile-1.4.x (in cvs), including
an informative comment by Aurelien Chanudet.  also fyi, this change made
it into guile 1.4.1.97, available at: .  since
you are already brave enough to build from source, i recommend grabbing
1.4.1.97 and giving it a try.  IIRC there are some other osx-specific
modifications already applied in that version.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: substantial performance loss when running long-lived or computationally intensive programs

[Thien-Thi Nguyen]

   From: "Michael A. Wells" <[EMAIL PROTECTED]>
   Date: Mon, 05 May 2003 22:36:26 -0500 (CDT)

   Although this problem is present in Guile-1.6.4, the problem dates
   back to at least Guile 1.4.

thanks for the bug report.  i have started to clean up the 1.4.x branch
(in cvs) as a result.  the following functions have been fixed to date:

 scm_getcwd
 scm_readlink
 scm_getgroups
 scm_fill_sockaddr
 scm_regexp_exec
 scm_localtime
 scm_mktime
 scm_strftime

i expect to finish the audit for the 1.4.1.97 release.  please feel
free to share further observations (in case i miss something).

fyi, below is a simple program i use like so: "guile -s stress.scm" to
eyeball-check for improved behavior (before/after changing the function
in question).

thi


[cc trimmed]


(define (report)
  (format #t "~A : ~A\n"
  (strftime "%Y-%m-%d %H:%M:%S" (localtime (current-time)))
  (assq-ref (gc-stats) 'bytes-malloced)))

;;- (define stress getcwd)

;;- (define stress getgroups)

;;- (define (stress)
;;-   ;; fports.c -- "fport_close"
;;-   ;; ports.c -- "scm_remove_from_port_table"
;;-   (with-output-to-string (lambda ()
;;-(display "1234567890")
;;-(display "1234567890"

;;- (define *token* (make-regexp "^[A-Za-z0-9_]*"))
;;- 
;;- (define (stress)
;;-   ;; libguile/regex-posix.c -- "scm_regexp_exec"
;;-   (regexp-exec *token* "foo"))

(define now (localtime (current-time)))

(define (stress)
  (strftime "%Y-%m-%d %H:%M:%S" now))

(report)
(let loop ((n 0))
  (stress) (stress) (stress) (stress) (stress)
  (stress) (stress) (stress) (stress) (stress)
  (if (= 0 n)
  (begin (report) (loop 10))
  (loop (1- n


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Fix for guile-www/cgi.scm (cgi:make-cookie)

[Thien-Thi Nguyen]

   From: Thamer Al-Harbash <[EMAIL PROTECTED]>
   Date: Fri, 29 Aug 2003 09:00:57 -0400 (EDT)

   If this patch works fine with the optargs module why not use it
   for the sake of simplicity? Does my patch break something?

the "optargs module" has an interface and a name.  its interface was
changed for guile-1.6 while its name remained the same.  this broke old
code (a mistake that is not too late to correct).

your patch would reinforce the confusion.

(btw, simplicity is a matter of how much you leave out of the
picture. ;-)

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Fix for guile-www/cgi.scm (cgi:make-cookie)

[Thien-Thi Nguyen]

   From: Thamer Al-Harbash <[EMAIL PROTECTED]>
   Date: Thu, 28 Aug 2003 10:53:34 -0400 (EDT)

   This cgi::make-cookie breaks under guile-1.6 because it's using a
   #&key and the (bound?) macro which seem to be no longer available
   or depreciated. Please accept my patch below which fixes the
   problem:

sounds like guile-1.6 breaks guile-www, not the other way around.

the solution to supporting both #&foo and #:foo style taken for
guile-1.4.x is to leave (ice-9 optargs) alone and introduce (ice-9
optargs-kw) which handles the #:foo style.  perhaps this can be done for
guile-1.6 so that it supports interoperability w/ old code.

another idea if guile-1.6 has no desire to support #&foo, is to provide
(ice-9 optargs-kw) as a simple wrapper/alias for its changed (ice-9
optargs), at which point i would be happy to change guile-www to use
(ice-9 optargs-kw) since that would be available in guile-1.4.x and 1.6.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: FW: problem compiling guile on IA64 by Intel compiler

[Thien-Thi Nguyen]

   Delivery-date: Wed, 09 Jul 2003 08:23:23 -0400
   From: "Sysoltsev, Vyatcheslav" <[EMAIL PROTECTED]>

   void __memory_barrier(void);
   Is this what is needed?

i believe so.  perhaps inhibition of only data-access instructions is
not as strong as is necessary, but it's a start.  code for 1.4.x now
reads as follows:

#if defined (__INTEL_COMPILER) && defined (__ia64)
#define SCM_FENCE __memory_barrier()
#else
...
#endif

we can update this should it prove insufficient.  thanks for the info.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: FW: problem compiling guile on IA64 by Intel compiler

[Thien-Thi Nguyen]

   From: "Sysoltsev, Vyatcheslav" <[EMAIL PROTECTED]>
   Date: Wed, 9 Jul 2003 13:49:20 +0400 

   No, Intel compiler doesn't plan to support ia64 asm inlines in
   foreseeable future.

looking at __scm.h closely, i see the inline asm is just an
implementation detail of SCM_FENCE, but SCM_FENCE is important
anyway (having it be defined to be nothing is indeed dangerous).

so the question becomes: does the intel compiler have an alternate
method to guarantee ordering as required by SCM_FENCE?  sorry for
not asking this earlier, when you had said you would be willing to
dig into the issue.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: FW: problem compiling guile on IA64 by Intel compiler

[Thien-Thi Nguyen]

   From: "Sysoltsev, Vyatcheslav" <[EMAIL PROTECTED]>
   Date: Wed, 9 Jul 2003 09:03:57 +0400 

   Starting from 8.0 Intel compiler defines GNUC macroses.

that's very strange (IMHO).  anyway, does the intel compiler have plans
to support ia64 inline asm in the future?  we would have to change the
code again at that time.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Autoconf macro GUILE_CHECK

[Thien-Thi Nguyen]

   From: Wolfgang Jaehrling <[EMAIL PROTECTED]>
   Date: Sun, 9 Mar 2003 17:30:25 +0100

   made unambigous.  In any case, _something_ is wrong here. :-)

no worries, just figure out what is unambiguous and strive to emulate.
i have seen in scripts: (exit #f).

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Antiquated (?) Gush fails to run

[Thien-Thi Nguyen]

   From: Michael Burschik <[EMAIL PROTECTED]>
   Date: Sat, 8 Mar 2003 08:31:05 +0100

   I downloaded the archive gush-0.0b.tar.gz from 
   http://www.glug.org/people/ttn/software/gush/ and built it successfully. 
   Whenever I try to run gush, however, I get the following error:

   Initializing Guile... ERROR: In procedure set-current-module:
   ERROR: Wrong type argument in position 1 (expecting MODULEP): #

   I also noticed that none of the files in the tar archive were more recent 
   than 1998, despite the fact that the changelog available at the above website 
   lead me to believe otherwise.

   Any help appreciated.

generally, the changelog is more live than the versioned tarballs.  gush
has suffered bit-rot compounded by underlying platform (guile) interface
instability.  the development sources are presently on an unconnected
hard disk, else i'd offer to send them to you (or publish a snapshot).
unfortunately, i don't expect to find time for gush for a few months at
least.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: virtual host support

[Thien-Thi Nguyen]

   From: "Jose Roberto B. de A. Monteiro" <[EMAIL PROTECTED]>
   Date: Thu, 27 Feb 2003 13:50:39 -0300

   In guile-www package: in http:request procedure, I am sending a patch
   to support virtual hosts retrieving.

thanks for the patch.  currently low-bandwidth, will probably take a
look at it in a week or so, after having completed a (residential) move.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Failing test from r4rstest.scm

[Thien-Thi Nguyen]

   From: Neil Jerram <[EMAIL PROTECTED]>
   Date: 06 Jan 2003 19:55:26 +

   ... but it fails.  Any idea why?

what messages do you see?

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile and readline on MacOS X

[Thien-Thi Nguyen]

   From: Aurelien Chanudet <[EMAIL PROTECTED]>
   Date: Sat, 28 Dec 2002 16:06:02 +0100

   Would anyone be 
   interested in a patch ?

if the patch is small, post it to [EMAIL PROTECTED]

thanks,
thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Updated [PATCH] Some fixes to doc/ref/scheme-data.texi

[Thien-Thi Nguyen]

   From: Stephen Compall <[EMAIL PROTECTED]>
   Date: Sun, 27 Oct 2002 19:48:53 -0600

   Have done. /me foolishly overlooked (guile)Manual Conventions, and
   drew mental connection to "many typos of if."? :-S

no worries.

   http://csserver.evansville.edu/~sc87/scheme-data-2S11.patch

thanks.  looks like it's time for me to re-read the texinfo manual -- i
didn't realize there was @math and @acronym.

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: [PATCH] Some fixes to doc/ref/scheme-data.texi

[Thien-Thi Nguyen]

   From: Stephen Compall <[EMAIL PROTECTED]>
   Date: Sat, 26 Oct 2002 16:11:41 -0500

   2002-10-26  Stephen Compall  <[EMAIL PROTECTED]>

   * scheme-data.texi: Addition and change of many Texinfo tags,
   particularly usage of @var and @samp, as well as reformatting of
   some lists into tables and usage of @result.

   Notes about some things I didn't understand, as well as a
   missing section on non-control characters.

   http://csserver.evansville.edu/~sc87/scheme-data-1S11.patch

the changelog entry neglects to mention some incorrect replacements of
"iff" w/ "if".  the former is a notational shorthand for "if and only
if" (see node "Manual Conventions").  could you correct these and post
another patch?

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: possible bug in srfi-19 implementation (fix included)

[Thien-Thi Nguyen]

   From: [EMAIL PROTECTED]
   Date: Fri, 27 Sep 2002 14:03:19 +0200

   (define (mydatetoweeknumber dt) [...])

   Is my solution acceptable? If not, is there anyone who can implement
   a better solution?

looks like your solution codifies ISO-8601, but srfi-19 does not specify
ISO-8601.  if it is possible to implement a "date-week-number-ISO-8601"
using srfi-19 date-week-number (perhaps by providing an appropriate
second arg to date-week-number), it would be good to include that as an
example in the documentation.  would you like to try this approach?

this is a separate issue from whether or not guile's (srfi srfi-19)
date-week-number implementation fulfills the srfi-19 specification.  i
see there is no test for that in test-suite/tests/srfi-19.test.  would
you like to write one?

thi


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile 1.4.1 w/ guile-oops 1.0.2

[Thien-Thi Nguyen]

   From: Michael Carmack <[EMAIL PROTECTED]>
   Date: Fri, 6 Sep 2002 08:21:18 +

   Is guile-oops/1.0.2 not intended to be used with guile/1.4.1?

more like guile-snarf invocation changing should be considered a bug,
especially in light of 1.4.x goal of compatibility (mea culpa)!  i've
since reverted the behavior for 1.4.2, but that's not available yet.
1.4.1.84, a snapshot precursor, is available under:

  http://www.glug.org/tmp/2002-09/

if you are building guile-1.4.1 from source, you can replace
guile-snarf.in (note the .in extension) w/ the file appended below.

thi


___
#!/bin/sh
# Extract the initialization actions from source files.
#
#  Copyright (C) 1996, 97, 98, 99, 2000, 2001, 2002 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

# Commentary:

# Usage: guile-snarf --help
# Usage: guile-snarf --version
#
# Usage: guile-snarf [-o OUTFILE] [CPP-ARGS ...]
#
# Process CPP-ARGS using the C pre-processor and some other programs.
# Write output to a file named OUTFILE or to the standard output when no
# OUTFILE has been specified or when OUTFILE is "-".  CPP-ARGS should
# include an input filename.
#
# If there are errors during processing, delete OUTFILE and exit with
# non-zero status.
#
# During snarfing, the pre-processor macro SCM_MAGIC_SNARFER is
# defined.
#
# If env var CPP is set, use its value instead of the C pre-processor
# determined at Guile configure-time: "@CPP@".

# Code:

## support

do_the_snarf () # writes stdout
{
${cpp} -DSCM_MAGIC_SNARFER "$@" > ${temp} && cpp_ok_p=true
sed -e '/^ *SCM__I/!d' -e 's/^ *SCM__I//' -e 's/ *SCM__D.*$//' ${temp}
}

## main

# process command line
if [ x"$1" = x--help ] ; then
@AWK@ '/^#.Commentary:/,/^#.Code:/' $0 | grep -v Code: \
| sed -e 1,2d -e 's/^. *//g'
exit 0
fi
if [ x"$1" = x--version ] ; then
echo "guile-snarf @VERSION@"
exit 0
fi
if [ x"$1" = x-o ]
then outfile=$2 ; shift ; shift
else outfile="-"
fi

# set vars and handler -- handle CPP override
cpp_ok_p=false
temp="/tmp/snarf.$$"
if [ x"$CPP" = x ] ; then cpp="@CPP@" ; else cpp="$CPP" ; fi

trap "rm -f $temp" 0 1 2 15

if [ ! "$outfile" = "-" ]; then
do_the_snarf "$@" > $outfile
else
do_the_snarf "$@"
fi

# zonk outfile if errors occurred
if $cpp_ok_p ; then
exit 0
else
[ ! "$outfile" = "-" ] && rm -f $outfile
exit 1
fi

# guile-snarf ends here


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: open-output-pipe problem

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <[EMAIL PROTECTED]>
   Date: Wed, 07 Aug 2002 20:20:48 -0700

   i have experimented w/ back-porting the new popen.scm (including
   associated support in libguile) w/o success [...]

turns out i was laboring under the classic stupidity of forgetting to
unpack an SCM... live and learn.  in any case, please find below a
uuencoded tarball containing

   libguile/ioext.h
   libguile/ioext.c
   ice-9/popen.scm

that you should be able to able to unpack in the guile-1.4.1 top-level
directory.  as you may notice, popen.scm `open-process' now closes file
descriptors instead of ports, following the change in HEAD.  however,
the implementation is more straightforward than in HEAD, w/ only one
addition to libguile (`scm_close_all_fdes_except' and associated scheme
binding).  you might notice other changes to popen.scm; those are
related to the documentation methodology and are not relevant to its
operation.

please rebuild and let me know of any problems.

thi


___
begin 644 popen-fix.tar.gz
M'XL(`+<04ST``^P\:7/;1I;Y*M7\B(Y<:Y,.)%/RM;$L)[1$V=K1M225C,MQ
M84"P(<(&`2X`BM:X^-_W'7T!/&3/5O8JLQ(9!+I?O_OJ!I-X<#V-$_DHSN3G
MX\?/?V@]?[KWY%GKV>/=71B_
M]_A9ZP?1^C.0J7^F11GD0OQ0ENG:<7<]_S_Z>?1PXS";W.;Q]:@4C<.FV/WY
MYZ<>_GU&?Y_3WW^EOS][8@\$1G_WQ'$NI>AE43D+*<8R:$8$!R)Z+&YD7\%WL>0*0:`0EXIF+;(*CF@@F2&]%
M$I1V["IZ+5E#$:>T_"B;``DC@`I$S>(D$0,IIH6,IHF'(&"P^/VD__;BJB_:
MY^_$[^UNMWW>?[3QQ?=$5;7+:[_9/#J]-V5UQ>=2\O>IT=(7H2T9((8`U/
M(Q(+\&THRR!."DWX.Y!D`=@E0S$*;B1(-)3Q#>`6B!#TZVYI$5N3++TF,F$P
M<,\J2L'(B0AMY^*JUU;$M@L@JYC(,`8R
MY.=03ACXNJ7%-;`#=`-T-RY091`0E^".@74I<#EEY8G+
M`MB:R`#$`(/>7)V<=JS>28L(*AXJF"?BB$PLB=-/S'Z<`U\'>9#?,J,S4GGD
M:T'C169*\&II0MFIC%V\B((VD,O3-0N]R=D#V7A*46F*CE%`$/'S[:W-S\"_Q_+T[#9`H,?UF4PSC;&;VRM[82G3GZ13C>&6TM
M>S3)\K)8\0PL9[CB4;1NWC2-HQ6/PE&0KYH621!X+E&`-",H9#T+L'9[Y1YWCD_..:("@?&2[#PH0@T[)H?_9$UO_@O>V
MS;T?MSSQF/[#:.A\&@!+T#"P$+P>3".^N,X&%"/P&F7'5YA9JTM`I^EM;B"4
MK2ZL)E!4`7CMO&`3^O4FR+_@U#E[$OH.\.?@L,HX$6B]'!G_2+<4(`>&RJUH
M%F,X%\P]M"V94E1`Y\NNCL8QTK_,+4",F_D4Z(#PGW/"H;F26XQQ,8L>N)29
M3))]=I1@9-*S`"']"X-\B$'&KJNHY.!"601Z'D^H,"I`HZ9(K`7S*WJ]+XUP
MFNE2`QBMLJ^*B&(&50IP&F!RP
MT\_5\A8B1<+I>`!3`(:C4N2?B+LYQQ'4BLD$4]J2HQ53@!'#J\*S6.2$+^9O
MA550F47;V>`C4#C?QQ3-\@""6($`$^E@:-)^K<5$@UU$I6:L-G!!:]R+YCM;
MS.\N6QWPV%+5[O4ZW[T,%^*8#H[1/Y5'BU8%HB?OW]=>71-O=JSWS
M4'HDPI(G+%D,ZG\C8_%*+P&+T8V7!\Y:BJ.L#?`=DYO&1[BCE$9\5*C!U4\_
M,3^_J-"""O*)9N$G5"R^EF6HV+^O'A'03_"\M2\^`3Q'J\0GA+KQ!0T&1:B4
MY_VG#^(`D&BR(7WA?ZR4C]NGO0Y(F0,!R'EC`]>>IKQZZ`DM/#61K9EU`!,Z
M@G+6_FO'AWJ["S,PQFVHP30,;64/,$5V;"MV-`$BC9EO;LPW+4HA(MNY.`8\
MEBX$CU"BO,0ZX)J7H-7O/WY`,3`/<;&ED%]?7)SZQ]Y:H//->Q@"(NM*-C^!J='%O_)H(99NQC$O0^#9L7H+@?)C+U)TWR.3B63.OAI%1&>=EO
MO_8[Y_WN.T<#:FMH37L$6:Y`]X@EEO;3N&9!KK3`#@FFM&W-+%/
MY<1X#*EO""7,"]_)$^\)R;.'9;N&.:3=;9'T';%\T%#A-_35G,55B=%`]C;JQLB&B!A!+CR3H")#[,=B%JZ,QD,,L9[`*BW-9@H+E`+F"$C3`"!^
M4F#>R))[R%:WG!G(9$R!?2IS5`BPH='(3N.#"U-+E;)B5CZ%ERX+*457#D''
M
MCMPP@YI;=3P;7Q<]5)K1^`KWH&.)"B9PZ<2.VEC466W<\TWC*<0LHZ[A*)L)
M^7DBP9AO5/M(6T)<6&/_!F-9%T96.O[57K_J\^>0M&QN/J*VG`5-O;Q\FJ(G
M*ZB3JZM$U""M.=24P(X[::%')2M#I[YD0+6G-D555^(2-!#GN4"-G@./CC+5
MDBPR,0X^8><42KN@H$8>I2MCC`2T4P0U[JWXN\'\@=J"(@QD%,5A#$.I>A>]
M<`03L>WW:$7/APW5Y3$V>)#OR]H\9'65CHVQ]FVGJK:\LJT-3P<*53/GP35V
M7FU!F\I0%D604[\6@ZCBN8:+[AS,`$33%*1BXPQWDG2K5;';JW8?5K8$"+26
MBJW,"3`7YXR&T[4Q@\;!+69W:E_0<$"H2+>LFJ]W;2R_J><3!EC<+VLAH!XH
M#6/_#N0LM(#NO83E7HD=P1?-NXM\4OEZIFU+=5.D%\J(4/BL*B@.BK#?7!6O
M*(9WG6)X?;:/*Y)CFOD!]8'0_]-H`.3_WCWI=WA](JK,!L5[AG7Q&BI=!>C#
M3I1,BY$!BSQ`O\>$-\5BF<(A]7[!D5'A4>#:YU>GI[PB<@6@T`3&2=5EE7:`
M2=<1P'L$N+U+Q2AZ;UVJ*E"U(I)&4-AP)BK/A\Z;%T;D2W`?/A@#+.$)'JHF
M$F6I-(F5?H!+G9P?GI)G4&PQ-2@ASYB!TS^./[_`\*@V=<&]A)\H7H'>X4Z;
M3D'`/B*,Y4%13,>\V8:Q@*.G0Z'ATATT6$0/+TYU](QG:==5.(.3S$
M10PQ%7CR/Z;Q39!06,I>N.W87PO4L`1HL/<:0T424"/>XS(?FLY33=C"DU_1
M&1IX:]R:9;[Q:WK)!C'9N!%'T'I9K?5?(^6HE$D"`J9_MY1@5\D6_+\3+]F-
M!RFZ5GE-C>!)+@M@H=Z/UB4?I%VT_6_Z[='P$8=1RYHQY`?3W`V!II<.@NO4
MQ+-6.)"X?V*[;8E>I_-7__"J^\\(@7A"_'>83,`;S`Q/.9NKLY:G7=P).6>S
M[`HQX"X7!YRCSNNK-_#WLMLYA%!RA`X44MA%0>'"*"C\=TMM7:T

Re: Latest guile reports version "1.4" which appears to break guile-xlib3.0 configure

[Thien-Thi Nguyen]

   From: "David Hull" <[EMAIL PROTECTED]>
   Date: Thu, 1 Aug 2002 12:53:32 -0700

   I just downloaded what I thought was the latest version, which
   reports (version) as "1.4".  The guile-xlib configure script checks
   for (string>= (version) "1.4.1") and then reports that my guile is
   too old.

did you build from source?  which tarball?

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: open-output-pipe problem

[Thien-Thi Nguyen]

   From: Satoru Takabayashi <[EMAIL PROTECTED]>
   Date: Sat, 13 Jul 2002 22:56:57 +0900

   I tried guile 1.4.1 and found a problem on open-output-pipe.

hi, thanks for the bug report.  i have reproduced the problem and
noticed that it is gone in guile-HEAD, but have not yet figured out
which of the (many) changes is responsible for the fixed behavior.

i plan to devote some hours looking into this because it is an area of
libguile i'd like to learn more about.  will let you know what i find.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile Builds but Core dumps on 11.20

[Thien-Thi Nguyen]

   From: Stephanie Nile <[EMAIL PROTECTED]>
   Date: Mon,  1 Jul 2002 09:55:59 +0100 (BST)

   Unfortuantly the 11.20 version of guile coredumps.  We are using gcc
   3.0.  Can you help?  What info should I send about the build?  We are
   using the same compile flags on both (11.00 and 11.20) systems.

some useful things to know would be:

 - ./configure options and env vars
 - ./config.guess output
 - guile version
 - "make check" output (do this after "make")

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: MacOS X

[Thien-Thi Nguyen]

   From: richmit <[EMAIL PROTECTED]>
   Date: Mon, 17 Jun 2002 23:12:11 -0500

   After struggling for a few hours I have finally managed to get guile
   to build on MacOS X.  In order to do this, I had to remove readline
   from my development system -- I don't know how to get guile to build
   without readline support.  We are using readline 4.2.

perhaps "--disable-readline" would be a useful configure option to add.

   I also had to use the following command line for configure to get a
   valid build environment:

   CPPFLAGS=-traditional-cpp CC=/usr/bin/gcc3 ./configure 
   --prefix=/usr/local/ --disable-threads

normally `--prefx=/usr/local' is the default and can be omitted.  is
this not the case on MacOS X?  (or is the difference the extra "/" ?)

   During the compile, a few warnings came out: [bad decls]

these should be cleaned up for sure.  thanks for the tip.

   Will MacOS X be officially supported in the future?

personally, i don't see the value of "official support" at this time in
theory or in practice (guile maintainership is pretty losing, IMHO).  by
the same token (also personally), i'd like to see if i can munge guile
to be as near hassle-free as possible on as many platforms as possible,
to gain confidence in my own configury skills.  bottom line: this will
likely result in guile on MacOS X being supported by its users in some
form or another (as it should be ;-).  no worries, just keep the bug
reports flowing...

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: [PATCH] lambda* fails with #:key and rest argument

[Thien-Thi Nguyen]

   From: Christopher Cramer <[EMAIL PROTECTED]>
   Date: Thu, 30 May 2002 13:44:11 -0500

   Index: ice-9/optargs.scm

thanks for the patch.  i've applied it for 1.4.2.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-1.4.1: test failures under shared library, -O3

[Thien-Thi Nguyen]

fyi, i've added this as:

  1007-cc-optimizations-break-r4rs-test

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: (dynamic-link) ignores PREFIX/lib and $LD_LIBRARY_PATH

[Thien-Thi Nguyen]

   From: [EMAIL PROTECTED] (Paul Jarc)
   Date: Tue, 18 Jun 2002 14:13:42 -0400

   So in a future version, this will Just Work?

yes.  to be fair, the 1.6.x and HEAD approach Just Works too (that is,
for now, i'm not so sure about future robustness in the face of
ambiguous interfaces and growing libdir pollution); i screwed up the
1.4.1 adaptation of that approach by not changing readline.scm
`dynamic-link' arg appropriately.  there is a TODO item to document
these things.

   http://multivac.cwru.edu./sptools/>

i'm glad to see more packagers and distributors of free software.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: (dynamic-link) ignores PREFIX/lib and $LD_LIBRARY_PATH

[Thien-Thi Nguyen]

   From: [EMAIL PROTECTED] (Paul Jarc)
   Date: Tue, 18 Jun 2002 13:57:39 -0400

   but it would still be nice if guile could tell libtool where to look
   for libguilereadline.la, since it's known to be in PREFIX/lib.

yes.  btw, another (smaller scope) fix would be to munge readline.scm
`dynamic-link' call.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: (dynamic-link) ignores PREFIX/lib and $LD_LIBRARY_PATH

[Thien-Thi Nguyen]

   From: [EMAIL PROTECTED] (Paul Jarc)
   Date: Tue, 18 Jun 2002 12:02:21 -0400

   I have guile 1.4.1 installed in an unusual place, so PREFIX/lib isn't
   in the usual search path for shared libraries.  It seems guile should
   always search PREFIX/lib, preferably before the systemwide directories
   and after those listed in $LD_LIBRARY_PATH.  (Actually, it should
   search all the -rpath directories that the binary was linked with,
   which should (and does) include PREFIX/lib.)

   When I evaluate (use-modules (ice-9 readline)), guile search only /lib
   when looking for libguilereadline.so (not even /usr/lib).  If I set
   $LD_LIBRARY_PATH to include PREFIX/lib, then guile looks there first
   and finds it, but keeps looking anyway and still fails:
   access("/package/host/localhost/guile-1.4.1-1/lib/libguilereadline.so", R_OK) = 0
   access("/lib/libguilereadline.so", R_OK) = -1 ENOENT (No such file or directory)
   open("/lib/libguilereadline.so", O_RDONLY) = -1 ENOENT (No such file or directory)

yeah, 1.4.1 tries to follow the nascent conventions cobbled together in
1.6.x and HEAD, which require these kinds of env var weirdness.  the fix
is to install libguilereadline et al "internally" (under $pkglibdir) and
reference them directly.

personally, i use as ~/bin/guile for now (until 1.4.2 release):

 #!/bin/bash
 # (prefix is /tmp/a/b/c)
 export LD_LIBRARY_PATH=/tmp/a/b/c/lib:$LD_LIBRARY_PATH
 export PATH=/tmp/a/b/c/bin:$PATH
 exec guile "$@"

could you post platform info?

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: inet_aton conflict

[Thien-Thi Nguyen]

   From: [EMAIL PROTECTED]
   Date: Sat, 25 May 2002 03:58:51 +0300

   obvious enough.

presuming you encountered this w/ guile-1.4, you should check out:

  ftp://ftp.gnu.org/gnu/guile/guile-1.4.1.tar.gz

(it has this fix and other changes -- see NEWS).

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Segfault on setting file-position on sockets

[Thien-Thi Nguyen]

   From: Arno Peters <[EMAIL PROTECTED]>
   Date: Mon, 20 May 2002 16:43:21 +0200

   The following 2 line snippet will segfault guile 1.4

   (let ((sock (socket AF_INET SOCK_STREAM 0)))
 (file-set-position sock 0))

thanks.  this is now recorded in the bugs db as:

  1005-fseek-0-on-socket-dumps-core

cvs HEAD and branch_release-1-6 signal "ERROR: unbound variable: fseek"
but do not segfault.

[bug-guile added to cc.]

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Fix for 1001-local-eval-error-backtrace-segfaults - please review

[Thien-Thi Nguyen]

   From: Neil Jerram <[EMAIL PROTECTED]>
   Date: 05 May 2002 15:00:59 +0100

   No; the new way doesn't mutate at all.  It creates a new environment
   that shares some substructure with the old environment.

ok i see this now.

   But, does this test need a different execution environment?  It's true
   for any existing test case that, if it causes a SEGV, the following
   test cases won't run.  This doesn't worry us much because SEGVs aren't
   an important part of our plans :-)

sorry, "different" was unclear.  it needs to have an independent
execution environment, which may be the same in construction as for the
other tests, for precisely the reason you give.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: regexp-exec fails for long strings

[Thien-Thi Nguyen]

   From: =?iso-8859-1?Q?Wolfgang_J=E4hrling?= <[EMAIL PROTECTED]>
   Date: Wed, 15 May 2002 08:04:20 +0200

   AFAIK, the glibc-people are rewriting the regex code for 2.3, because
   the current implementation got unmaintainable and has various strange
   limitations. This could be one of those.

that's good news (that i wouldn't have known w/o this tip -- thanks!).
i suppose i could contribute this as a test case.  i wonder what glibc
testing framework is like.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: regexp-exec fails for long strings

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <[EMAIL PROTECTED]>
   Date: Thu, 25 Apr 2002 16:29:40 -0700

   i traced this to `regexec' (glibc 2.2.4) and stopped -- it's not a guile
   bug after all, as far as i could tell.  (also, could not reproduce the
   behavior under FreeBSD 4.4-RELEASE.)

   probably time to apt-get update...

this problem persists w/ glibc 2.2.5.  hmmm

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: RedHat-7.3 & gcc-2.95.3.2

[Thien-Thi Nguyen]

thanks for the report.  this will be fixed along w/ some other things in
guile 1.4.1 release -- see guile web pages for details on how to get a
cvs checkout (cvs module "hack").

i am curious: what is your use for guile?

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Compilation fix for guile 1.4

[Thien-Thi Nguyen]

   From: Davide Angelocola <[EMAIL PROTECTED]>
   Date: Fri, 3 May 2002 13:18:23 +0200

 I've downloaded guile version 1.4 to learn on how to program
   in C under UNIX. However, when I try to compile it on my
   RedHat 7.2 machine I get an error in net_db.c line 85. Well, I've 
   just put a comment at the beginning of line and all works fine 
   now.

thanks for trying out guile.  the problem you report will be fixed in
1.4.1 and later versions.

   o  add readline and history support

this is already available, but the documentation doesn't tell you how to
enable it (it's a documentation bug).  for now, see NEWS for more info.

   o  add a welcome message like this:
   guile v. [build info?]
   Copyright 

   Type (help) for more information

   o  add "(copyright)", "(license)" functions
   o  the "(help)" output in one page
   o  add a TODO file in the source dist
   (this can very useful for me)

   I hope that this email can be useful for you! 

it's useful to let us know what you want.  now that you are learning to
program, the next logical step (for both of us) is for you to learn how
to implement these requirements either by writing new code or modifying
existing code.  i would suggest looking first at the latter class of
changes since (you) going through that process would result in a patch
that could be easily applied (by us).

because the TODO file changes relatively rapidly, we publish it online,
along w/ everything else.  check out:

  http://www.glug.org/snap/workbook/tasks/TODO
  http://www.glug.org/snap/
  http://www.glug.org/

what programming experience do you have presently?  why do you want to
program in C under UNIX?

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

install-data-local scheduling not guaranteed

[Thien-Thi Nguyen]

in branch_release-1-6 ice-9/Makefile.am, we use `install-data-local' to
install "and-let*.scm".  w/ automake 1.5 (no idea what was before), this
frag is run before the rest of the install, and fails if there is no
destination directory already set up.  the failure is masked by the "-"
action prefix, which is fine (considering the reason for using this
mechanism in the first place -- slackful handling of sites where "*" is
not a valid file name).

automake documentation sez:

> Extending installation
> ==
> 
>It is possible to extend this mechanism by defining an
> `install-exec-local' or `install-data-local' target.  If these targets
> exist, they will be run at `make install' time.  These rules can do
> almost anything; care is required.
> 
>Automake also supports two install hooks, `install-exec-hook' and
> `install-data-hook'.  These hooks are run after all other install rules
> of the appropriate type, exec or data, have completed.  So, for
> instance, it is possible to perform post-installation modifications
> using an install hook.

so probably we should use `install-data-hook' instead.  i'll test this
and commit changes shortly, presuming all goes well.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Fix for 1001-local-eval-error-backtrace-segfaults - please review

[Thien-Thi Nguyen]

   From: Neil Jerram <[EMAIL PROTECTED]>
   Date: 02 May 2002 13:59:06 +0100

   -  SCM_SETCAR (SCM_CAR (env), scm_cons (n, SCM_CAR (SCM_CAR (env;

   The copy in scm_unmemocopy, which looks as though it might be
   intended to fix this problem [...]

was this used previously?  (i'm trying to crawl inside the head of
whoever wrote it this way in the first place.)

   Fix isn't very elegant, though;
   is there a nicer way of doing this?

both the old way and the new way involve mutating some nested list
structure, so i'm guessing that doesn't play into "elegance".  i'm
wondering what is it about this fix that makes it not very elegant?

   2. Rerun of problem scenarios:

cool.  this touches upon the need to extend the testing framework to
handle interactive cases.  actually, i believe that's already possible
w/ the current framework via (ice-9 expect); the limitation really is
that all tests share an execution environment -- this is fine for the
most part, but undesirable for this kind of bug.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: regexp-exec fails for long strings

[Thien-Thi Nguyen]

   From: [EMAIL PROTECTED]
   Date: Thu, 25 Apr 2002 23:47:13 +0200

   |  guile> (test ok)
   |  string-length 42  => ok
   |  guile> (test (+space ok 11672))
   |  string-length 11714   => ok
   |  guile> (test (+space ok 11673))
   |  string-length 11715   => ok
   |  guile> (test (+space ok 11674))
   |  string-length 11716   => FAIL
   |  guile> (test (+space ok 11675))
   |  string-length 11717   => FAIL
   |  guile> (test (+space ok 11700))
   |  string-length 11742   => FAIL
   |  guile> 

i traced this to `regexec' (glibc 2.2.4) and stopped -- it's not a guile
bug after all, as far as i could tell.  (also, could not reproduce the
behavior under FreeBSD 4.4-RELEASE.)

probably time to apt-get update...

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

regexp-exec fails for long strings

[Thien-Thi Nguyen]

well, good and bad news.

the good news is that another guile project was recently added to the
projects list.  the bad news is that for www.gnu.org, template.scm now
fails due to unfulfilled regexp matching.  (this has resulted in an
empty project page there.)  below is a test case that demonstrates the
problem.  running "pre-inst-guile -s" on it shows three "ok" and three
"FAIL" for both HEAD and branch_release-1-6.

if someone can confirm similar behavior on another system (perhaps by
varying the appended string length), i will add this to the bugs db.
(i ask for this confirmation because my system's old sdrams are prone to
mysterious failures, and i want to rule that out as a reason.)

thi


(use-modules (ice-9 regex))

(define ok "Projects List")

(define rx (make-regexp "(.*)"))

(define (+space s n)
  (string-append s (make-string n #\space)))

(define (test s)
  (format #t "string-length ~A\t=> ~A\n"
  (string-length s)
  (if (regexp-exec rx s)
  "ok"
  "FAIL")))

;; do it
(test ok)   ; ok
(test (+space ok 11672)); ok
(test (+space ok 11673)); ok
(test (+space ok 11674)); FAIL
(test (+space ok 11675)); FAIL
(test (+space ok 11700)); FAIL

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Rob Browning <[EMAIL PROTECTED]>
   Date: Tue, 23 Apr 2002 18:09:04 -0500

   Furthermore, as I've said several times before,

this should give you a clue that saying things on mailing lists isn't as
useful to other people understanding you, as writing them down somewhere
under workbook/ and inviting review and refinement there.

   [...]

what are the areas of divergence?  why not add an item for each (as in
"port foo to HEAD") to TODO?  this would help us understand things more
precisely.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Rob Browning <[EMAIL PROTECTED]>
   Date: Tue, 23 Apr 2002 17:42:58 -0500

   Depends on the problem.  For example, the recent library name changes
   relating to libltdl/dlopen issues may or may not belong in HEAD, but
   they're critical for 1.6.

the recent changes may or may not belong in HEAD but the questions i'm
asking are: (1) what *does* belong in HEAD?
(2) how does the 1.6 library handling relate to (1)?

   Since it's very likely we'll choose a different long-term solution
   for this problem, and we won't know until we have the discussion, in
   my judgement there was little point in trying to integrate the
   changes into HEAD right now.

of course these things follow.  i'm not questioning the consequence of
the approach, but the wisdom of using that approach in the first place,
which seems backwards and make-work-ful to me.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Rob Browning <[EMAIL PROTECTED]>
   Date: Wed, 10 Apr 2002 16:10:56 -0500

   I've been trying to make sure to migrate all my 1.6 patches to HEAD,
   but there are still some outstanding.  Of course some of the lag is
   because I'm not sure we'll want to handle things the same in 1.8.

hmmm, this is very different way of looking at things from what i would
expect...  i'm operating on the assumption that we want to look at
things from long-term perspective first and foremost, and interpolate
current decisions/activities from that.  that is, figure out LATER and
then figure out NOW as it relates to LATER, rather than the reverse.

in practice, this means changing HEAD branch to conform to LATER first,
and branch_release-1-6 to conform to NOW.  to me this seems like less
work.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile 1.5.6 build failure on OpenBSD 3.0

[Thien-Thi Nguyen]

   From: "Dale P. Smith" <[EMAIL PROTECTED]>
   Date: Wed, 10 Apr 2002 11:11:39 -0400

   It appears that the preprocessor #define i386 isn't defined, while
   __i386__ is.  Using __i386__ seems to fix things.  Here is a diff:

thanks for the patch.  before being applied, a few questions:

is this due to a change in openbsd?  (did this work before?)  i'm
concerned that this replacement will break other openbsd versions.
also, which compiler?

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Marius Vollmer <[EMAIL PROTECTED]>
   Date: 09 Apr 2002 19:03:29 +0200

   I'm totally open as to what will happen for 1.8, so I didn't change
   it there as well.

ok, noted in TODO.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Marius Vollmer <[EMAIL PROTECTED]>
   Date: 08 Apr 2002 18:45:44 +0200

   A VPATH build is when you compile in a directory other than the source
   directory.  This is useful when you want to compile a package for
   different configurations but from a common source.  The name stems
   from the fact that it is implemented using the VPATH variable of make.

could you describe VPATH as "configure in place, make from elsewhere"?
or is configure done elsewhere also?  i've heard the latter referred to
as srcdir!=builddir (and usually make is done where configure is).

   > if you remove cleaning you need to promote SCM_MAGIC_SNARFER to required
   > status and document accordingly.

   It is already.

all i see is this:

  During snarfing, the pre-processor macro @code{SCM_MAGIC_SNARFER} is
  defined.

i'm assuming that whatever changes made to branch_release-1-6 that are
long-term applicable would be also made in HEAD roughly concurrently,
but i guess this is saved for later?

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Marius Vollmer <[EMAIL PROTECTED]>
   Date: 08 Apr 2002 00:55:38 +0200

   Sigh, I've seen this coming...

   guile-snarf writes its $cleanfile into the $srcdir, which is not a
   supported thing to do during a VPATH build.

looks like some coding cowboy should've figured out what kind of builds
are to be supported before doing this kind of thing.  (sorry for that.)
what is a "VPATH build", specifically?  what other kinds of builds are
there?

   (This was uncovered by a simple "make distcheck", which thankfully
   write-protects the source directory.  I hope everybody uses "make
   distcheck" freely before checking in their changes, eh?)

you can do more than hope: why not write down some good tips under
workbook/build/ somewhere?

   [cleaning not required in the presence of SCM_MAGIC_SNARFER]

if you remove cleaning you need to promote SCM_MAGIC_SNARFER to required
status and document accordingly.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Badness with TODO at dist time

[Thien-Thi Nguyen]

   From: Marius Vollmer <[EMAIL PROTECTED]>
   Date: 08 Apr 2002 00:22:35 +0200

   (One tempting thing is
   to not distribute TODO at all.)

i wouldn't mind if we didn't distribute TODO.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Guile fails tests on Tru64 4.0F

[Thien-Thi Nguyen]

   From: David C Sterratt <[EMAIL PROTECTED]>
   Date: Fri, 5 Apr 2002 12:55:24 +0100

   $ ./autogen.sh .
   aclocal: configure.in: 167: macro `AM_PROG_LIBTOOL' not found in library

   I'm using autoconf version 2.53 and automake 1.4p5

   Should I be using different versions?  Or is there some environment
   variable I need to set?

i would recommend using automake 1.5.  for me, AM_PROG_LIBTOOL is
defined in /usr/local/share/aclocal/libtool.m4.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: unhandled keywords to goops "make" should signal errors

[Thien-Thi Nguyen]

   From: "Neil W. Van Dyke" <[EMAIL PROTECTED]>
   Date: Thu, 28 Mar 2002 02:00:06 -0500

   If I understand Bug 11 correctly, then it appears to be a very
   different problem than the one I report.

what you request for consideration must surely have been considered
before.  if we figure out precisely how it is different and how it is
the same, perhaps we can apply that understanding.

because my personal coding has not yet advanced to using goops
regularly, my conjecture from reading related material is that keyword
handling in goops follows a non-blocking scheme reflecting its original
design model.  i imagine when i do finally get to designing classes and
instantiating objects, i would view mixin techniques darkly if they were
(in return) so opaque.

perhaps i misunderstand the nature of keywords in goops and compare it
against other keyword disciplines, fruitlessly.  how would i tell?

goops can be extended to do such error checking, in any case.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: unhandled keywords to goops "make" should signal errors

[Thien-Thi Nguyen]

   From: "Neil W. Van Dyke" <[EMAIL PROTECTED]>
   Date: Sat, 9 Mar 2002 21:10:54 -0500

   Thank you for considering this suggestion.

could this be related to:

http://www.glug.org/snap/bugs/guile-core/11.html ?

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: bug 9 -- sibling threads not infinite looping

[Thien-Thi Nguyen]

   From: Neil Jerram <[EMAIL PROTECTED]>
   Date: 08 Mar 2002 17:57:57 +

   - `guile -s bug9.scm' outputs about 15 `a's and `b's, and then stops,
 as the main thread has exited

   - `guile -l bug9.scm' continues outputting `a's and `b's forever, and
 also performs normal REPL interaction at the same time.

   In both cases, this is what I would expect.

i've added this info and two "fixed" headers to bugs/9.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cvs guile build/install problems

[Thien-Thi Nguyen]

   From: Lynn Winebarger <[EMAIL PROTECTED]>
   Date: Sat, 16 Mar 2002 01:24:07 -0500

   The documentation is a little vague on the library paths - that is,
   whether "library" refers to a library of scheme code, a compiled
   library, or both [ which may vary from context to context in the
   docs, I'm just pointing out it should be made clear ].

i've add this to bug 10 (embedded libltdl masks system version
unconditionally) since fully documenting our (perhaps currently
incomplete) understanding of libltdl's expected and actual usage, is a
good idea.

thi

___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile