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

URL: Summary: guile 1.8.1 regular expressions die on #\nul (character zero) in operand Project: Guile Submitted by: gremio Submitted on: Sunday 06/03/2007 at 01:29 Category: None

[bug #20083] sigaction lambda appears not to get called in 1.8.1

URL: Summary: sigaction lambda appears not to get called in 1.8.1 Project: Guile Submitted by: gremio Submitted on: Tuesday 06/05/2007 at 10:27 Category: None Severity

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

Follow-up Comment #2, bug #20056 (project guile): Thank you. ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.org/

1.8.2 srfi-19 warns about current-time

In guile-1.8.2 (use-modules (srfi srfi-19)) warns: WARNING: (guile-user): imported module (srfi srfi-19) overrides core binding `current-time' Apparently one can control this using the #:replace keyword: http://www.gnu.org/software/guile/manual/html_node/Creating-Guile-Modules.html#Creating

Re: 1.8.2 srfi-19 warns about current-time

Thanks Jon, Ludovic, I indeed hadn't noticed that it was intentional, but I'm in agreement with Ludovic. I'm concerned that my customer shouldn't be confused and worried by a warning, and I see no way to override the warning myself. This is a bit of overkill, but I thought it might work: (w

Re: 1.8.2 srfi-19 warns about current-time

Thank you! On Mon, 8 Oct 2007, Ludovic Courtès wrote: Hi, Gregory Marton <[EMAIL PROTECTED]> writes: I indeed hadn't noticed that it was intentional, but I'm in agreement with Ludovic. I'm concerned that my customer shouldn't be confused and worried by a wa

Re: 1.8.2 srfi-19 warns about current-time

module-replace! forces the list of symbols in its second argument to be put into the :replace list? (could not find documentation) Correct. It's not documented (yet). Can I help? I mean, presuming that the sentence above, or some extension, is reasonable documentation? I get a sense that

hashx -set! and -ref

I may be misunderstanding something, but I thought this should yield 'bar: guile> (let ((ht (make-hash-table))) (hashx-set! (lambda (k s) 1) equal? ht 'foo 'bar) (hashx-ref (lambda (k s) 1) equal? ht 'foo)) #f guile> (version) "1.8.1" much as this does: guile> (let ((ht (make-

Re: hashx -set! and -ref

l pointers in the right general direction? Thanks, Grem On Thu, 10 Jan 2008, Gregory Marton wrote: I may be misunderstanding something, but I thought this should yield 'bar: guile> (let ((ht (make-hash-table))) (hashx-set! (lambda (k s) 1) equal? ht 'foo 'bar)

Re: hashx -set! and -ref

in both cases. I'm inclined to start poking at guile's source code for the first time. Could someone give me helpful pointers in the right general direction? Thanks, Grem On Thu, 10 Jan 2008, Gregory Marton wrote: I may be misunderstanding something, but I thought this should

Re: hashx -set! and -ref

g a Segmentation Fault for bus error in the last case. Guile 1.3.4 simply returns #f in both cases. I'm inclined to start poking at guile's source code for the first time. Could someone give me helpful pointers in the right general direction? Thanks, Grem On Thu, 10 Jan 2008, G

Re: hashx -set! and -ref

eally big hash table. Thanks, Grem Gregory Marton <[EMAIL PROTECTED]> writes: I may be misunderstanding something, but I thought this should yield 'bar: guile> (let ((ht (make-hash-table))) (hashx-set! (lambda (k s) 1) equal? ht 'foo 'bar) (hashx-r

[bug #22022] hashx-set! and -ref

URL: Summary: hashx-set! and -ref Project: Guile Submitted by: gremio Submitted on: Monday 01/14/2008 at 22:40 Category: None Severity: 3 - Normal Item G

Re: [bug #22022] hashx-set! and -ref

Yes, thank you. Apologies again for my carelessness. Grem Gregory Marton <[EMAIL PROTECTED]> writes: Ack. I think I meant to replace assoc as well, with something like (lambda (k alist) (cdar alist)). That wouldn't be assoc-like. (lambda (k al) (car al)) accesses the corre

Re: [bug #22022] hashx-set! and -ref

Thanks, yes. I initially had a one in there. Hmmm... it doesn't matter. 33 is enough to trigger resize. Thanks, Grem Follow-up Comment #2, bug #22022 (project guile): Another one: (pass-if (equal? "#" (with-output-to-string (lambda () (write table))) Actual outpu

Re: [bug #22022] hashx-set! and -ref

What do you think? I didn't read that part of the spec, so I was confused, and I'll grant that the cases may be out of scope. Moreover, I think the hash specification is problematic. (a) the representation seems to wish to hide the current size of the hash vector, or at least that w

Re: [bug #22022] hashx-set! and -ref

Thank you. I did something far less elegant already, but it's good to have this. I should also read all of my email before responding. :-) Best wishes, Grem Gregory Marton <[EMAIL PROTECTED]> writes: As an enhancement request, it would be nice for the common case to be abl

Re: [bug #22022] hashx-set! and -ref

Ack. I think I meant to replace assoc as well, with something like (lambda (k alist) (cdar alist)). My intention was to get it to give me back 'bar because the hash functions would accept anything, rather than because it was "right" in any sense. Sorry, Grem Follow-up Comment #1, bug #2202

sending and and or as an argument links their behavior

Hi folks, I'm wondering what to make of this behavior, seen in both guile 1.8.1 and 1.8.3, discovered by my colleague L. Brown Westrick, cc:ed above: guile> (define (apply2 f a b) (f a b)) guile> (apply2 or #t #f) #t guile> (apply2 and #t #f) #t [ #f expected ] guile> (quit) [because we're d

A passing test case

Hi folks, I just wanted to send in a test case for a bug that is fixed as of guile 1.8.2, but recently bit me, and it's just not that obvious to test for. It is essentially exposed in 1.8.1 by (let ((x 1/2)) (display x) (equal? x 1/2)) ===> #f ! Thanks for being so responsive to a

comparing procedures

Hi folks, I'm trying to write a meaningful comparison operator for procedures. Clearly this wants more than procedure-source, because variables in the source may be bound to different values in the procedure-environment. I expected something like this to work: (define foo 3) (define bar (lamb

Re: A passing test case

The differences are not significant. I guess I wanted to make clear in the test case that this isn't something to do with literal rationals, and I didn't want the test case to be printing things to the console. Thanks, Grem Gregory Marton <[EMAIL PROTECTED]> writes: H

Re: sending and and or as an argument links their behavior

`or' and `and' are macros, and it doesn't work to pass them as procedure arguments. I forget for the moment what R5RS says; I suspect the above is not allowed, and so perhaps Guile should detect it and report an error. The detailed reason for this is Guile's memoization - but that's not really t

Re: A passing test case

Gregory Marton <[EMAIL PROTECTED]> writes: The differences are not significant. I guess I wanted to make clear in the test case that this isn't something to do with literal rationals, and I didn't want the test case to be printing things to the console. OK, thanks for exp

Re: Module introspection API doc

Hi Ludovic, I'm in the process of getting signed and sending in the copyright agreement. Thanks for your patience on this doc. I've replied below only on the places where you suggested a change that I didn't take verbatim with thanks, or where I wanted to clarify. I truly appreciate your ti

(no subject)

Dear guile devel folks, Having failed to reach either: [EMAIL PROTECTED] Unrouteable address [EMAIL PROTECTED] Unrouteable address I turn to you. I installed guile-dbi-2.0.0 and guile-dbd-postgresql-2.0.0 on a debian system with guile 1.8.3, apparently successfully, and went to tr

signal handling different in 1.8.3 than 1.8.1?

Hi folks, Now that I've upgraded to 1.8.3 from 1.8.1, some old test cases are failing. In particular: (define (ensure body-lambda ensuring-lambda) (dynamic-wind (lambda () #t) body-lambda ensuring-lambda)) (define (with-sigaction signum handler flags lamb) (let (

Re: signal handling different in 1.8.3 than 1.8.1?

Hi Ludovic, The following message is a courtesy copy of an article that has been posted to gmane.lisp.guile.bugs as well. Is bug-guile@gnu.org now out of date? I may have to get a newsreader. Are they mirrored? Now that I've upgraded to 1.8.3 from 1.8.1, some old test cases are failing.

Re: signal handling different in 1.8.3 than 1.8.1?

it effectively doesn't reach the sleeps: the program passes the tests very quickly. Grem On Tue, 3 Jun 2008, Ludovic Courtès wrote: The following message is a courtesy copy of an article that has been posted to gmane.lisp.guile.bugs as well. Hello, Gregory Marton <[EMAIL PROTECTED]&g

Re: signal handling different in 1.8.3 than 1.8.1?

then it passes. I thought it should never reach those sleeps -- what's going on? Also, it effectively doesn't reach the sleeps: the program passes the tests very quickly. Grem On Tue, 3 Jun 2008, Ludovic Courtès wrote: The following message is a courtesy copy of an article t

Re: signal handling different in 1.8.3 than 1.8.1?

Hi Ludovic, Thanks for the handholding Re: git-bisect. there are frustrating failures like there not being a ./configure script in many older versions even though the INSTALL document says there should be, and ./autogen.sh complaining that aclocal:configure.in:704: warning: macro `AM_GNU_GETTEX

Re: signal handling different in 1.8.3 than 1.8.1?

have appears to be 0.16.1. I am not sure how to use apt to search for a string like AM_GNU_GETTEXT in all available packages. Thanks again, Grem Hi Gregory, Gregory Marton <[EMAIL PROTECTED]> writes: I'm still having no luck building even the first intermediate stage, however.

Re: signal handling different in 1.8.3 than 1.8.1?

ian's stable gettext is too old (as it was with git)? The version I have appears to be 0.16.1. I am not sure how to use apt to search for a string like AM_GNU_GETTEXT in all available packages. Thanks again, Grem Hi Gregory, Gregory Marton <[EMAIL PROTECTED]> writes: I'm

Re: signal handling different in 1.8.3 than 1.8.1?

o search for a string like AM_GNU_GETTEXT in all available packages. Thanks again, Grem Hi Gregory, Gregory Marton <[EMAIL PROTECTED]> writes: I'm still having no luck building even the first intermediate stage, however. $ ./autogen.sh ERROR: could not find workbook dir re

Re: signal handling different in 1.8.3 than 1.8.1?

e/guile ../test-timeout.scm 1.8.1 fell asleepExpected: specified handler Observed: # should time out with specified handler $ git log | head -1 # tag release_1-8-1 commit 2e726f11258f3d77557310fd50c02774fdcf014f Hi, Gregory Marton <[EMAIL PROTECTED]> writes: Now with automake 1.10, autoreconf

Re: signal handling different in 1.8.3 than 1.8.1?

r: stray '@' in program gen-scmconfig.c:394: error: 'SCM_I_GSC_HAVE_STRUCT_DIRENT64' undeclared (first use in this function) during make, with or without having invoked config with --without-threads Help? Grem Hi, Gregory Marton <[EMAIL PROTECTED]> writes: It turns out I can't

Re: signal handling different in 1.8.3 than 1.8.1?

Excellent. Having done these steps, it did indeed make check, and with the --without-threads flag, it even passed the timeout tests! I'm happy with this for now. Is non-threading ever likely to be unsupported? Thanks, Grem Hi Gregory, Gregory Marton <[EMAIL PROTECTED]> writ

Re: signal handling different in 1.8.3 than 1.8.1?

Gregory Marton <[EMAIL PROTECTED]> writes: Having done these steps, it did indeed make check, and with the --without-threads flag, it even passed the timeout tests! You mean that the problem that triggered this thread vanished? Yes. The with-timeout test script I sent a few emai

Re: signal handling different in 1.8.3 than 1.8.1?

They're taking a while to run, but so far all my other tests are also passing in mono-threaded guile 1.8.5 commit 9143131b2766d1e29e05d61b5021395b4c93a6bc Neil Jerram, July 11 Just to be clear: do you mean that they are passing _after_ this commit, but were failing _before_? That's nice to kno

Re: signal handling different in 1.8.3 than 1.8.1?

Hello, Gregory Marton <[EMAIL PROTECTED]> writes: I would surmise that this is an extremely longstanding issue that was introduced some time before 1.8.1, and that I only noticed it now because I was trying to use the default build. As I suggested earlier [0], I think it's just

Re: with-timeout and asynchronous alarm (was: signal handling different in 1.8.3 than 1.8.1?)

eone didn't write their library with this in mind... I haven't written much multithreaded code, and none in guile, so I'm probably misunderstanding something. How would force-asyncs help? Many thanks, Grem Hi, Gregory Marton <[EMAIL PROTECTED]> writes: As I suggested

procedure-source inconsistencies

Hi folks, We're running into an issue where we're trying to associate some information about functions by associating the info with their serialized form, which is in part their procedure-source. Unfortunately, the procedure-source changes when a function is invoked: (define (equal-source-a

Re: procedure-source inconsistencies

Thank you, Neil! Do you have to use the procedure source as your assoc key? Why not use the procedure itself? We have to serialize the procedure-qua-association-key to a file between when we set the value and when we'll need it next time. I can imagine one solution to be remembering the

and-map and or-map not documented in the manual

Hi Folks, A colleague just noticed that and-map and or-map, defined in boot-9.scm with some helpful comments above them, are not actually documented in the Guile Manual. How might I go about adding them? Many thanks, Grem -- -- __@ Gregory A. Martonhttp://csail.mit.edu

Re: and-map and or-map not documented in the manual

From a user's perspective, reading code containing these functions, it can be confusing that they're undocumented and not defined in the user portion of the code. Either deprecating them or documenting them with the caveats mentioned would be better than the status quo. I would prefer to docu

Error during GC: how can I find out more?

Hi folks, We are working with dbi postgres and suspect that we may have made a mistake while modifying it that causes guile occasionally to die with Guile: error during GC. from what looks like line 88 of error.c here: http://guile-1.8.sourcearchive.com/documentation/1.8.5plus-p1/error_8