bug#26027: (system vm trace) creates no output

-procedure write-hi) (trace-instructions-in-procedure write-hi) (outer) Thanks, Mike Gran

bug#25384: Compiler mis-identifies source location of erroneous parenthesis pairs

In guile 2.0.13, both the compiler and the interpreter fail to identify the source location of errors of the following form. It instead reports the errors as occurring in boot-9.scm. (unknown-func unknown-symbol () #t) GUILD COMPILE ERROR ;;; WARNING: compilation of /home/mike/projects/bug1.scm fa

bug#20907: [PATCH] Manual bug for scm_gc_protect_object

On Wednesday, September 2, 2015 11:06 AM, Mark H Weaver wrote: >Would it help to replace all uses of the term "scan" with "mark", in >connection with garbage collection? In the papers I've read on GC, >"mark" is the word I usually see, and it seems much clearer to me, >because anyone who knows

bug#20907: [PATCH] Manual bug for scm_gc_protect_object

Manual claims C globals weren't scanned by GC in 1.8. The opposite is true. * doc/ref/api-memory.texi [scm_gc_protect_object]: modified --- doc/ref/api-memory.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/ref/api-memory.texi b/doc/ref/api-memory.texi index 0e37d16..3

bug#13611: SEGV during SMOB GC

> From: Ludovic Courtès >>> I’m confident that the SMOB mark procedure is never called with null >>> scm_i_current_thread with 7.2 compiled with the default options (the >>> GnuTLS bindings rely on this, and I had not seen any such report until >>> someone tried with GC 7.3pre, which uses the

bug#13611: SEGV during SMOB GC

>> Is that expected that GC is sometimes called from a >> thread where scm_i_current_thread is null and sometimes >> called from a thread where scm_i_current_thread is >> not null? > > Can you check whether your GC was built with --enable-parallel-mark? > > I’m confident that the SMOB mark

bug#13611: SEGV during SMOB GC

arks from current thread: 825 Is that expected that GC is sometimes called from a thread where scm_i_current_thread is null and sometimes called from a thread where scm_i_current_thread is not null? -Mike From 807b00d91fa3b7016987ecfd6992e7b7e943d1e3 Mon Sep 17 00:00:00 2001 From: Mike Gran Date: T

bug#13611: SEGV during SMOB GC

Hello- I have a reproducible SEGV during GC of SMOBs on Guile 2.0.7. It was also present in 2.0.6. To reproduce compile main.c as $ gcc -std=gnu99 -shared -o smobbug.so -Wall -Wextra `pkg-config guile-2.0 --cflags --libs` -fPIC main.c Then with $ LD_PRELOAD=./smobbug.so LD_LIBRARY_PATH=. GU

bug#10488: guile-config deprecation?

Hi- There's a bit of confusion on the guile-config deprecation. NEWS says that guile-config "will be deprecated" meta/guile-config.in says it "has been deprecated" meta/guile.m4's GUILE_PROGS rule will error "guile-config required but not found" likewise those rules that depend on GUILE_PROGS,

bug#10388: Assoc list confusion in set-procedure-properties!

Wrong type argument in position 2 (expecting association list): arity   Thanks,   Mike Gran

Re: Guile with win32 cross compiling

>     "Portability fixes for win32 cross compiling" >     http://www.mail-archive.com/guile-devel@gnu.org/msg05308.html > > > In any case, I don't understand the mechanism here, but I believe the > > point was to make it so that #include would not pull in > > iconv headers.  gen-scmconfig looks u

Re: exit & dynamic wind

- Original Message - > From:Neil Jerram > To:Andy Wingo > Cc:bug-guile@gnu.org; Ian Price ; guile-devel > > Sent:Wednesday, March 30, 2011 11:31 AM > Subject:Re: exit & dynamic wind > > Andy Wingo writes: > > >>> |  GEN    guile-procedures.texi > >>> | guile: uncaught throw to wron

guile-snarf chokes on -g3 flag

Hi, When compiling guile with the gcc -g3 flag, compilation of alist.c fails with the following error In file included from alist.c:379:0: ../libguile/alist.x: In function 'scm_init_alist': ../libguile/alist.x:2:1: error: 'X' undeclared (first use in this function) ../libguile/alist.x:2:1

[bug #32365] psyntax error has bad format, causes exception during error

URL: Summary: psyntax error has bad format, causes exception during error Project: Guile Submitted by: mike121 Submitted on: Sat 05 Feb 2011 04:36:33 PM GMT Category: None

[bug #32340] non-local exit may cause wrong-type-arg error

URL: Summary: non-local exit may cause wrong-type-arg error Project: Guile Submitted by: mike121 Submitted on: Thu 03 Feb 2011 02:48:55 PM GMT Category: None Severity:

[bug #32243] guile-tools errors if PROGRAM can't be found

URL: Summary: guile-tools errors if PROGRAM can't be found Project: Guile Submitted by: mike121 Submitted on: Tue 25 Jan 2011 01:25:50 PM GMT Category: None Severity:

[bug #30162] "abort to unknown prompt" can be infinitely recursive

Follow-up Comment #3, bug #30162 (project guile): An easier way to replicate the bug is to just call "nohup guile". ___ Reply to this item at: ___ Mess

[bug #31680] R6RS string literal intraline whitespace removal

Follow-up Comment #7, bug #31680 (project guile): > OK, why don't we implement the escape sequence, > * -> nothing, > then. Does that sound right to you, Mike? Sounds great. I'll commit something this weekend if you don't get to it first. _

[bug #31680] R6RS string literal intraline whitespace removal

Follow-up Comment #5, bug #31680 (project guile): > I think the deal is that all (?) of the other escapes can be > dealt with via the equivalent of a `case' expression. This > one requires a property lookup. It's not as nice. > Also note the thread at > http://lists.r6rs.org/pipermail/r6rs-d

[bug #31680] R6RS string literal intraline whitespace removal

Follow-up Comment #1, bug #31680 (project guile): Yeah it is true that this isn't implemented and should be. Ludo, Andy, I did in fact write an implementation of this in r6rs-strings tree, but, I never committed it to master. The commit was cff6adf899dbc0336c7c017d52504f8138c89b3d and the part

[bug #31293] [HEAD] repl debugger "expected a positive width" error

Update of bug #31293 (project guile): Status:None => Fixed Assigned to:None => mike121 ___ Follow-up Comment #1: I found a workaround

[bug #31293] [HEAD] repl debugger "expected a positive width" error

URL: Summary: [HEAD] repl debugger "expected a positive width" error Project: Guile Submitted by: mike121 Submitted on: Sun 10 Oct 2010 04:03:41 PM GMT Category: None

[bug #31234] [1.9.12] errors in macroexpand don't give line numbers of source

URL: Summary: [1.9.12] errors in macroexpand don't give line numbers of source Project: Guile Submitted by: mike121 Submitted on: Sun 03 Oct 2010 06:08:46 PM GMT Category: None

[bug #30851] [1.9.11] %site-dir different from pkg-config, guile-config

URL: Summary: [1.9.11] %site-dir different from pkg-config, guile-config Project: Guile Submitted by: mike121 Submitted on: Mon 23 Aug 2010 02:37:00 PM GMT Category: None

[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. $ (de

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

URL: Summary: [1.8.7] (ice-9 optargs) mixes keyword and optional args Project: Guile Submitted by: mike121 Submitted on: Sat 31 Jul 2010 04:49:35 AM GMT Category: None

[bug #29643] Current locale has higher precedence than `coding:' when determining file port encoding [1.9.10]

Update of bug #29643 (project guile): Status: Ready For Test => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: I pushed a branch th

Re: [r6rs] #\x0 is a perfectly valid character datum representation

> >> r6rs hex *character* escapes and Guile 1.8.x octal > >> character escapes could logically coexist without confusion. > > > Let's do that. Shall you, or shall I? I pushed this change into git. Thanks, Mike

Re: [r6rs] #\x0 is a perfectly valid character datum representation

> From: Andy Wingo wi...@pobox.com > Hi Mike, > Thanks for the explanation :-) >> r6rs hex *character* escapes and Guile 1.8.x octal >> character escapes could logically coexist without confusion. > Let's do that. Shall you, or shall I? It would happen more quickly if you did it. You'd just h

Re: [r6rs] #\x0 is a perfectly valid character datum representation

> From: Andy Wingo wi...@pobox.com >> #\x0 > Add (read-enable 'r6rs-hex-escapes) to your > guile init file. > Mike: is there a more sensible default than the one we > have? The idea behind not enabling it by default is because the r6rs *string* escapes are not backwards compatible with the he

[bug #30162] "abort to unknown prompt" can be infinitely recursive

Follow-up Comment #2, bug #30162 (project guile): I came across the problem when I built Guile master on a Cygwin box with a misconfigured iconv/libunistring that didn't have any encodings other than "C" and "POSIX" available. With only those encodings, the guile-tools compilation process on non

[bug #30162] "abort to unknown prompt" can be infinitely recursive

URL: Summary: "abort to unknown prompt" can be infinitely recursive Project: Guile Submitted by: mike121 Submitted on: Thu 17 Jun 2010 03:57:33 AM GMT Category: None S

[bug #29643] Current locale has higher precedence than `coding:' when determining file port encoding [1.9.10]

Update of bug #29643 (project guile): Status: Confirmed => Ready For Test ___ Follow-up Comment #1: I pushed a new branch to the repo "mike-port-encodings" that may solve the problem. Consider the

[bug #29643] Current locale has higher precedence than `coding:' when determining file port encoding [1.9.10]

Update of bug #29643 (project guile): Status:None => Confirmed Assigned to:None => mike121 ___ Reply to this item at:

Re: Portability fixes for win32 cross compiling

> From: Volker Grabsch v...@notjusthosting.com > Is it really necessary to #include the > "uniconv.h" from the cross system and to provide corresponding > SCM_ICONVEH_* > constants? Probably not.  I doubt that the libunistring constants are going to change upstream, so you could hack around it

Re: UTF-8 regression in guile 1.9.5

e early on startup... The parsing of any source code files after locale is set will be done in that context. I don't think it would do anything unexpected. The reader and the port routines tend to do their own parsing, and don't tend to rely on libc locale-specific routines. Even so, it would take some auditing to prove that there would be no effect. If you were to set the locale in Guile, you would need to add a condition to catch if the current LANG envvar isn't set to a valid locale so you can fall back to the "C" locale. -Mike Gran

Re: 1.9.5 alpha does not install ice-9/quasisyntax.scm

> From: Andy Wingo > > It looks like 1.9.5 alpha fails to install a file required by boot-9: > > quasisyntax.scm. > > It should be compiled into boot-9.go. Perhaps you are tweaking your > boot-9.scm after installation? Sometimes the server runs guile in a chroot jail, and the script used to co

Re: UTF-8 regression in guile 1.9.5

> From: Andy Wingo > Hi, > > On Sun 06 Dec 2009 21:43, Linas Vepstas writes: > > > 2009/12/6 Mike Gran : > >> > >>> > need to call (setlocale LC_ALL "") > >> > >> But for Guile to store characters as codepoints, declaring a

1.9.5 alpha does not install ice-9/quasisyntax.scm

Hi- It looks like 1.9.5 alpha fails to install a file required by boot-9: quasisyntax.scm. I copied the file from the build to site dir and it worked fine. -Mike Gran

Re: UTF-8 regression in guile 1.9.5

> > Hmm. The "ã" is a dead giveaway that you are printing a UTF-8 string > > that is being interpreted as a ISO-8859-1 string. > > > > You've already said that you're in a UTF-8 locale. It could be that you > > need to call (setlocale LC_ALL "") > > That cured it. > > > as well as having a se

Re: UTF-8 regression in guile 1.9.5

fore entering (new-node "てみました。") as well as having a setlocale call in your program. Thanks, Mike Gran

Re: mitem_current man page

Doh! Wrong list.

mitem_current man page

. It took me awhile to figure that out. Thanks, Mike Gran

Re: guile.m4 may need serial number

it's trivial, but it > will give a useful check that we agree on exactly what the new serial > line should contain.) Since this would be guile.m4 version 1.9 in HEAD, I went with # serial 9. -- Mike Gran guile.m4.diff Description: Binary da

guile.m4 may need serial number

search path, and if at least one of them use a ‘#serial’ line, aclocal will ignore the file that has the older ‘#serial’ line (or the file that has none). Thanks, Mike Gran ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman

1.8.2 manual describes debugger breakpoint functionality that doesn't exist

oints procedural) I seem to recall that there was a thread about moving these to their own package, right? Thanks, Mike Gran ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile

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

Hi- It appears that there is no @include in the reference manual guile.texi for the section autoconf.texi for the 1.8.x branch and the MAIN branch. I think the autoconf.texi info is still relevant, right? Thanks, Mike Gran ___ Bug-guile mailing

Re: 1.8.0: C++-style cast

--- Kevin Ryde <[EMAIL PROTECTED]> wrote: > I don't think it's c++. I'm guessing X_CAST is an OSF macro. Dunno > if it does anything good. John Eaton contributed that, maybe he can > say (Cc'ed). > You're right. When I googled for X_CAST, I came across this... http://www.belgeler.org/autobo

1.8.0: C++-style cast

In guile-core-1.8-20060711, in libguile/numbers.c, in guile_ieee_init(), a C++ style cast is used instead of a C-style cast. Also, a declaration block occurs in a code block. These bend the rules of old-school ANSI C. --- numbers.c.orig 2006-05-09 16:15:10.0 -0700 +++ numbers.c 20

1.8.0: The ?: operator used in an lvalue context

In guile-core-1.8-20060705, in libguile/environments.c in core_environments_unobserve(), the question mark/colon operator is being used without being an rvalue. Also the value to the left of the colon appears to be void and the value to the right appears to be a pointer. This gets flagged as an e

1.8.0: $< in makefile w/o an implicit rule

; to "sed < version.h.in > $.tmp" perhaps. - Mike Gran __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Bug-guile mailing li

pedantic stuff: unif.c: void function returns void value

In 1.8.0, in unif.c, the static void function string_set() "returns" the value of void function scm_c_string_set_x(). That type of construction is non-standard, I think, (but I couldn't find a good reference for it). FWIW, the AIX xlc compiler believes it to be an error, even though GCC has no pr

1.8.0: SCM_C_INLINE used instead of SCM_C_INLINE_KEYWORD

In libguile/srfi-4.c and libguile/strings.c, the SCM_C_INLINE_KEYWORD needs to be used instead of SCM_C_INLINE for compilers w/o an inline keyword. *** strings.c Mon Feb 27 17:20:47 2006 --- strings.c.0 Mon Feb 27 17:18:33 2006 *** *** 124,130 /* Return a new stringbuf whos

srfi-4.c: arithmetic on void pointers

Hi, In srfi-4.c, pointer arithmetic on void pointers is done. This is a GNU C extension, and I think it is not C99. For non-GCC C, you might consider a cast to (char *) or something. The flag -Wpointer-arith catches this in GCC. Attached is the diff to 1.8.0 Thanks, Mike Gran

Re: 1.8.0: SCM_C_INLINE used instead of SCM_C_INLINE_KEYWORD

Maybe I should attach those files instead? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com srfi.4.c.patch Description: 4124077230-srfi.4.c.patch strings.c.patch Description: 1312687027-stri

pedantic stuff: C++ comments in 1.8.0

There are some C++-style comments in 1.8.0. *** posix.c Mon Feb 27 18:38:55 2006 --- posix.c.0 Mon Feb 27 18:29:56 2006 *** *** 1877,1883 { const int save_errno = errno; ! /* No guile exceptions can occur before we have freed p's memory. */ scm

Unexpanded ~S macro in error msg

urn an error message "Already unlinked: ~S" -- Mike Gran [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Bug-guile mailing list [EMAIL

Inaccurate deprication warning in scm_dbl2big

In Guile 1.6.4, numbers.c, in the definition of scm_dbl2big(), the function issues a deprecation warning, advising the programmer to use 'scm_dbl2num' instead. 'scm_dbl2num' doesn't exist. Should it actually be 'scm_double2num'? This doesn't seem to be a problem with the CVS version of numbers

Trivial Documentation Path

Here is a super-trivial document patch to the reference manual. Bug: punctuation error. 2000-05-02 Mike Gran [EMAIL PROTECTED] * preface.texi: Minor punctuation mistakes. Hyphens should link compound adjectives. Commas should be placed after a "ther