headers
Mike Gran | 1 Aug 2010 14:12
Picon

[bug #30611] [1.8.7] (ice-9 optargs) mixes keyword and optional args


Follow-up Comment #2, bug #30611 (project guile):

Even if one were to make the argument that 1.8.7's behavior of having a key
be read as an optional argument was valid, silently dropping the "3" in the
(func 1 #:c 3) in the previous example is problematic.

Consider the following behavior.

$ (define* (funk #:key a) #t)
$ (funk 1 2 3)
=> #t

$ (define* (funk) #t)
$ (funk 1 2 3)
=> ABORT: wrong number of args

IMHO, the first of these two examples should also trigger a
wrong-number-of-args error.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30611>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andy Wingo | 1 Aug 2010 10:41
Picon

[bug #30611] [1.8.7] (ice-9 optargs) mixes keyword and optional args


Follow-up Comment #1, bug #30611 (project guile):

How do you know one is correct and the other is not?

If you are saying that 1.9.11's behavior is more intuitive, I agree. We
probably need to document this incompatibility in the 1.9.11 NEWS, however.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30611>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 2 comments |
headers
Patrick McCarty | 1 Aug 2010 23:00
Picon

[bug #30623] `module-public-interface' returns #f for `the-scm-module'


URL:
  <http://savannah.gnu.org/bugs/?30623>

                 Summary: `module-public-interface' returns #f for
`the-scm-module'
                 Project: Guile
            Submitted by: pnorcks
            Submitted on: Sun 01 Aug 2010 02:00:24 PM PDT
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hello,

LilyPond relies on `the-scm-module' having a public interface, but it seems
that this interface is not detected with Guile 1.9 (git):

  scheme <at> (guile-user)> (module-public-interface the-scm-module)
  $1 = #f
  scheme <at> (guile-user)>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Patrick McCarty | 1 Aug 2010 23:27
Picon

[bug #30623] `module-public-interface' returns #f for `the-scm-module'


Follow-up Comment #1, bug #30623 (project guile):

I just noticed that using `the-root-module' seems to work with both Guile 1.8
and 1.9:

  scheme <at> (guile-user)> (module-public-interface the-root-module)
  $1 = #<interface (guile) 1573d80>
  scheme <at> (guile-user)>

Should LilyPond use `the-root-module' instead?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30623>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 5 comments |
headers
Yan Li | 4 Aug 2010 09:02
Picon
Favicon

[PATCH] Compiling DOT_X_FILES requires version.h

There was a race condition when building Guile since DOT_X_FILES didn't
depend on version.h, which is dynamically generated. Sometimes the
DOT_X_FILES are compiled before the version.h is generated and leads to
build failure. This patch fixed this problem.

Signed-off-by: Yan Li <yan.i.li <at> intel.com>
---
 libguile/Makefile.am |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libguile/Makefile.am b/libguile/Makefile.am
index a899b85..9836aa1 100644
--- a/libguile/Makefile.am
+++ b/libguile/Makefile.am
 <at>  <at>  -670,7 +670,7  <at>  <at>  AM_V_FILTER_0 =  <at> echo "  FILTER" $ <at> ;
 .c.doc:
 	-$(AM_V_FILTER)$(AWK) -f $(srcdir)/guile-func-name-check $< && (./guile-snarf-docs
$(snarfcppopts) $< | ./guile_filter_doc_snarfage$(EXEEXT) --filter-snarfage) > $ <at>  || { rm $ <at> ; false; }

-$(DOT_X_FILES) $(EXTRA_DOT_X_FILES): scmconfig.h snarf.h guile-snarf.in
+$(DOT_X_FILES) $(EXTRA_DOT_X_FILES): scmconfig.h snarf.h guile-snarf.in version.h

 $(DOT_DOC_FILES) $(EXTRA_DOT_DOC_FILES): scmconfig.h snarf.h guile-snarf-docs.in guile_filter_doc_snarfage$(EXEEXT)

-- 
1.7.1

--

-- 
Best regards,
Li, Yan
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andy Wingo | 4 Aug 2010 20:21
Picon
Favicon

Re: [PATCH] Compiling DOT_X_FILES requires version.h

On Wed 04 Aug 2010 09:02, Yan Li <yan.i.li <at> intel.com> writes:

> There was a race condition when building Guile since DOT_X_FILES didn't
> depend on version.h, which is dynamically generated. Sometimes the
> DOT_X_FILES are compiled before the version.h is generated and leads to
> build failure. This patch fixed this problem.

Applied. Thanks!

Andy
--

-- 
http://wingolog.org/
Permalink | Reply | 0 comments |
headers
Andy Wingo | 4 Aug 2010 20:58
Picon
Favicon

Re: Bug in Guile 1.8.7, ice-9/debugging/ice-9-debugger-extensions,scm

Hi Ian,

On Sat 09 Jan 2010 16:34, Ian Hulin <ian <at> hulin.org.uk> writes:

> The finish command in the debugger crashes with the following error:
>
> Internal debugger error:
> usr/share/guile/1.8/ice-9/debugger/command-loop.scm:51:6:
> In procedure throw in expression (apply throw key ...):
> usr/share/guile/1.8/ice-9/debugger/command-loop.scm:51:6:
> Unbound variable: trace-trap
>
> If you change Line 41 of
> ice-9/debugging/ice-9-debugger-extensions.scm
>  from
>   (use modules (ice-9 debugging steps)
> to
>   (use-modules (ice-9 debugging steps)
> 	     (ice-9 debugging trace))
>
> This fixes the crash and the debug finish command works as expected.

Thanks, applied. (8 months late, but better late than never, right?)

> We are using guile in for the Lilypond project and it would be helpful
> if this could be fixed in the guile sources.
>
> Also has this been fixed in Guile V1.9?

In 1.9 the debugging interfaces are being rewritten, and this code will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Wingo | 4 Aug 2010 21:48
Picon
Favicon

Re: Bug in vector-move-right!

Hi Michael,

Late reply, but better than never...

On Fri 26 Mar 2010 08:06, Michael Lucy <MichaelGLucy <at> Gmail.com> writes:

> I think there's a bug in vector-move-right!.  I'm using guile 1.9.9 as
> built from the git repository earlier today.
>
> This is the behavior I see:
> "
> scheme <at> (guile-user)> (define *v1* #(1 2 3 4 5 6 7 8 9))
> scheme <at> (guile-user)> (define *v2* #(10 20 30 40 50 60 70 80 90))
> scheme <at> (guile-user)> (vector-move-right! *v1* 0 2 *v2* 5)
> scheme <at> (guile-user)> *v2*
> #(10 20 30 1 2 60 70 80 90)
> "
>
> It seems to interpret the argument start2 as an ending index.  I
> thought for a second that this might be intended behavior, but it says
> in the documentation that start2 is supposed to be an inclusive index,
> which it isn't.
>
> This is the behavior I expect:
> "
> scheme <at> (guile-user)> (define *v1* #(1 2 3 4 5 6 7 8 9))
> scheme <at> (guile-user)> (define *v2* #(10 20 30 40 50 60 70 80 90))
> scheme <at> (guile-user)> (vector-move-right! *v1* 0 2 *v2* 5)
> scheme <at> (guile-user)> *v2*
> #(10 20 30 40 50 1 2 80 90)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Wingo | 4 Aug 2010 21:51
Picon
Favicon

Re: High run time variance

On Mon 29 Mar 2010 18:09, Luca Saiu <positron <at> gnu.org> writes:

> To sum up, within each run the computation time of (fibo n) is the same,
> but the time varies widely from one run to another. This anomaly seems
> to have become much more accentuated in 1.9.

I suspect this is related to the GC issues brought up recently on
guile-user. Something is being misidentified as a Scheme object.

We'll poke this problem once we have a heap profiler.

Andy
--

-- 
http://wingolog.org/
Permalink | Reply | 4 comments |
headers
Andy Wingo | 5 Aug 2010 16:45
Picon
Favicon

Re: High run time variance

Hi,

On Thu 05 Aug 2010 15:42, Luca Saiu <positron <at> gnu.org> writes:

> ;;; Why does this GCs after creating b?  Try running this with GC_PRINT_STATS=1,
> ;;; or with GC_DONT_GC=1 if you want to see the memory use rise.
>
> (define size 100000)
> (define times 100)
>
> (define b (make-bitvector size))
>
> (do ((t 0 (1+ t)))
>     ((= t times) 'done)
>   (do ((i 0 (1+ i)))
>       ((= i size) 'done)
>     (bitvector-set! b i #t)))

The toplevel references to bitvector-set! don't get cached, so the
bitvector-set! gets looked up every time, and there is some unfortunate
allocation in scm_from_locale_symboln. If you put it in a function,
the variable gets cached, and there's no allocation.

Andy
--

-- 
http://wingolog.org/
Permalink | Reply | 2 comments |

Gmane