bug#70144: system* affects signal handlers
system* temporarily re-binds signal handlers to prevent the child process from killing the parent. Thus, it is not thread safe with regard to SIGINT (or SIGQUIT if available). So, your code has a race condition with respect to the signal handler. This common resource can, in principle, be handled the usual way by, for example, utilizing a mutex: (use-modules (ice-9 threads)) (define sigint-mutex (make-mutex)) (define thread (call-with-new-thread (lambda () (with-mutex sigint-mutex (system* "echo" "foo") (with-mutex sigint-mutex (sigaction SIGINT (lambda (sig) (peek "SIGINT handler") (exit 1))) (for-each (lambda _ (sleep 1)) (iota 30))) (join-thread thread) (display "normal exit\n") But if this was real code, another way would be to make sure that the code blocks are run in the order that you wish (which you did not want here since your very purpose was to provoke the collision of resources). I'm leaving this bug open. *Should* system* re-bind the signal handlers? Should it really protect itself from the child? If so, we should probably document this behaviour in the reference manual. Best regards, Mikael On Tue, Apr 2, 2024 at 4:28 PM Christopher Baines wrote: > I've encountered a situation where signal handlers don't seem to > run. With the following program, sending it SIGINT won't trigger the > handler, however if you remove the system* call, then the handler will > run. > > (use-modules (ice-9 threads)) > > (call-with-new-thread >(lambda () > ;; Remove the following system* call to fix the handler > (system* "echo" "foo"))) > > (sigaction SIGINT > (lambda (sig) > (peek "SIGINT handler") > (exit 1))) > > (for-each >(lambda _ > (sleep 1)) >(iota 30)) > > (display "normal exit\n") >
bug#67487: Minor typo in the manual.
bug#67487: Minor typo in the manual.
close 67487 Fixed in commit d8df317b. On Mon, Nov 27, 2023 at 3:47 PM 無無 wrote: > In < > https://www.gnu.org/software/guile/manual/html_node/Modules-and-the-File-System.html > >: > > When a program evaluates (use-modules (ice-9 popen)), and the > module is not loaded, Guile searches for a conventionally-named file > from in the load path. > > "from in the" should probably be "in the". > > > >
bug#66135: Unable to download Guile tar file
It (the link you provided) works for me. Can you try again? Den tors 21 sep. 2023 15:12ahmad khizir skrev: > Dear team, > > I tried to download a guile tar file from the below listed url, but it is > not working. > Please help to provide the correct url to download the guile tar file. > > https://ftp.gnu.org/gnu/guile/guile-3.0.9.tar.gz > https://ftp.gnu.org/gnu/guile/ > > > Thanks, >
bug#62456: [PATCH] Fix typo.
Oops...
Fixed in commit 1ae50a7f80654f04d93d900e17f3160205700a75
On Wed, Apr 5, 2023 at 8:36 PM Mikael Djurfeldt
wrote:
> Fixed in commit 62501-d...@debbugs.gnu.org
>
> On Sun, Mar 26, 2023 at 10:58 AM jgart via Bug reports for GUILE, GNU's
> Ubiquitous Extension Language wrote:
>
>> ---
>> libguile/list.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libguile/list.c b/libguile/list.c
>> index 82aab8a5d..cd05e77b8 100644
>> --- a/libguile/list.c
>> +++ b/libguile/list.c
>> @@ -224,7 +224,7 @@ SCM_DEFINE (scm_length, "length", 1, 0, 0,
>>
>> SCM_DEFINE (scm_append, "append", 0, 0, 1,
>> (SCM args),
>> - "Return a list consisting of the elements the lists passed
>> as\n"
>> + "Return a list consisting of the elements of the lists passed
>> as\n"
>> "arguments.\n"
>> "@lisp\n"
>> "(append '(x) '(y)) @result{} (x y)\n"
>> --
>> 2.39.2
>>
>>
>>
>>
>>
bug#62456: [PATCH] Fix typo.
Fixed in commit 62501-d...@debbugs.gnu.org
On Sun, Mar 26, 2023 at 10:58 AM jgart via Bug reports for GUILE, GNU's
Ubiquitous Extension Language wrote:
> ---
> libguile/list.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libguile/list.c b/libguile/list.c
> index 82aab8a5d..cd05e77b8 100644
> --- a/libguile/list.c
> +++ b/libguile/list.c
> @@ -224,7 +224,7 @@ SCM_DEFINE (scm_length, "length", 1, 0, 0,
>
> SCM_DEFINE (scm_append, "append", 0, 0, 1,
> (SCM args),
> - "Return a list consisting of the elements the lists passed
> as\n"
> + "Return a list consisting of the elements of the lists passed
> as\n"
> "arguments.\n"
> "@lisp\n"
> "(append '(x) '(y)) @result{} (x y)\n"
> --
> 2.39.2
>
>
>
>
>
bug#58297: GOOPS slot accessor specialization and inheritance do not compose
Unfortunately, I do not have time right now to look in the code, but this might actually originally have been intended behavior. The motivation for creating new accessor methods for child classes by default could have been to ensure that it is possible to access slots using a constant offset once the type dispatch is done. (There were originally plans to actually also eliminate a lot of the type dispatch in GOOPS.) It should be possible to get the CLOS behavior by defining a suitable meta class. If *that* is not possible, it might be a bug, or at least a target for a feature request. Best regards, Mikael Den ons 5 okt. 2022 02:23Thompson, David skrev: > In Guile, slot accessor specialization and inheritance do not compose. > For example, you can't specialize an accessor's setter for a parent > class and have it apply to a child class. Every child class defines > new slot accessor methods. which means that the specialized parent > methods will not be called since the new methods take precedence. > > The code below demonstrates the issue: > > (use-modules (oop goops)) > > (define-class () > (name #:init-keyword #:name #:accessor name)) > > (define-method ((setter name) (person ) new-name) > (display "renaming!\n") > (slot-set! person 'name new-name)) > > (define-class ()) > > (define p1 (make #:name "Alice")) > (define p2 (make #:name "Bob")) > > ;; Only the first set! call uses the specialized setter method defined > ;; above. > (set! (name p1) "Ada") > (set! (name p2) "Ben") > > I would have expected the specialized setter method to apply to both > and since does not shadow the 'name' slot. > > I compared this behavior with that of Common Lisp and found that CLOS > does not clobber the method from the parent class, as demonstrated by > this example program that I tested with SBCL: > > (defclass person () > ((name :initarg :name :accessor name))) > > (defmethod (setf name) (new-name (obj person)) > (format t "renaming!~&") > (setf (slot-value obj 'name) new-name)) > > (defclass child (person) ()) > > (defvar p1 (make-instance 'person :name "Alice")) > (defvar p2 (make-instance 'child :name "Bob")) > > ;; Both of these setf calls use the specialized setf method defined > ;; above. > (setf (name p1) "Ada") > (setf (name p2) "Ben") > > I find the Common Lisp behavior much more desirable. Is this a bug or > intended behavior? > > Thanks for reading, > > - Dave > > > >
bug#47568: [PATCH] Fix typos in examples
This is applied in commit #88e70308.
Thanks!
On Fri, Apr 2, 2021 at 10:09 PM Eugene Klimov via Bug reports for GUILE,
GNU's Ubiquitous Extension Language wrote:
> * examples/box-dynamic-module/box.c
> * examples/box-dynamic/box.c
> * examples/box/box.c
> * examples/modules/README
> * examples/web/debug-sxml.scm
> ---
> examples/box-dynamic-module/box.c | 2 +-
> examples/box-dynamic/box.c| 2 +-
> examples/box/box.c| 4 ++--
> examples/modules/README | 2 +-
> examples/web/debug-sxml.scm | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/examples/box-dynamic-module/box.c
> b/examples/box-dynamic-module/box.c
> index 8cf940909..b950e019a 100644
> --- a/examples/box-dynamic-module/box.c
> +++ b/examples/box-dynamic-module/box.c
> @@ -55,7 +55,7 @@ print_box (SCM b, SCM port, scm_print_state *pstate)
> }
>
>
> -/* This defines the primitve `make-box', which returns a new smob of
> +/* This defines the primitive `make-box', which returns a new smob of
> type `box', initialized to `#f'. */
> static SCM
> #define FUNC_NAME "make-box"
> diff --git a/examples/box-dynamic/box.c b/examples/box-dynamic/box.c
> index 7bc791613..4954e88ba 100644
> --- a/examples/box-dynamic/box.c
> +++ b/examples/box-dynamic/box.c
> @@ -55,7 +55,7 @@ print_box (SCM b, SCM port, scm_print_state *pstate)
> }
>
>
> -/* This defines the primitve `make-box', which returns a new smob of
> +/* This defines the primitive `make-box', which returns a new smob of
> type `box', initialized to `#f'. */
> static SCM
> #define FUNC_NAME "make-box"
> diff --git a/examples/box/box.c b/examples/box/box.c
> index 53c022ab1..f9b3a55a7 100644
> --- a/examples/box/box.c
> +++ b/examples/box/box.c
> @@ -55,7 +55,7 @@ print_box (SCM b, SCM port, scm_print_state *pstate)
> }
>
>
> -/* This defines the primitve `make-box', which returns a new smob of
> +/* This defines the primitive `make-box', which returns a new smob of
> type `box', initialized to `#f'. */
> static SCM
> #define FUNC_NAME "make-box"
> @@ -109,7 +109,7 @@ box_set_x (SCM b, SCM value)
>
>
> /* Create and initialize the new smob type, and register the
> - primitives withe the interpreter library. */
> + primitives with the interpreter library. */
> static void
> init_box_type (void)
> {
> diff --git a/examples/modules/README b/examples/modules/README
> index ddad881cc..80569c98d 100644
> --- a/examples/modules/README
> +++ b/examples/modules/README
> @@ -17,7 +17,7 @@ installed and available with the standard installation
> prefix
>
>The main program, which uses the modules described below to perform
>some actions. Module usage and selective importing as well as
> - renaming is demonstrated here.n
> + renaming is demonstrated here.
>
>$ ./main
>
> diff --git a/examples/web/debug-sxml.scm b/examples/web/debug-sxml.scm
> index 724a9bd6c..5970c47d3 100644
> --- a/examples/web/debug-sxml.scm
> +++ b/examples/web/debug-sxml.scm
> @@ -1,6 +1,6 @@
> ;;; Commentary:
>
> -;;; A simple debugging server that responds to all responses with a
> +;;; A simple debugging server that responds to all requests with a
> ;;; table containing the headers given in the request.
> ;;;
> ;;; As a novelty, this server uses a little micro-framework to build up
> --
> 2.31.0
>
>
>
>
>
bug#47550: [PATCH] elisp mode doesn't support non-list argument lists
bug#47550: [PATCH] elisp mode doesn't support non-list argument lists
Fixed in commit 01bfd18f. Thanks! On Thu, Apr 1, 2021 at 6:19 PM Vasilij Schneidermann wrote: > When I've tried porting existing elisp code, I've found that `(defun foo > nil 1)` errors out (on Guile 3 and master) , but `(defun foo () 1)` > doesn't. The following patch rectifies this by treating `nil` the same > as `()` when compiling a lambda. >
bug#40008: Backtraces can contain very long strings
On Wed, Mar 11, 2020 at 12:14 PM Ludovic Courtès wrote: > Hi, > > skribis: > > > On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote: > >> I have the following backtrace: > >> > >> Backtrace: > >> In ice-9/boot-9.scm: > >> 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) > >> In unknown file: > >>8 (apply-smob/0 #) > >> In ice-9/boot-9.scm: > >> 718:2 7 (call-with-prompt _ _ #) > >> In ice-9/eval.scm: > >> 619:8 6 (_ #(#(#))) > >> In ice-9/boot-9.scm: > >>2806:4 5 (save-module-excursion _) > >> 4351:12 4 (_) > >> In /home/jsynacek/./git.scm: > >> 72:0 3 (_) > >> 61:16 2 (change-spec _ _ "66.33" _ #) > >> 48:12 1 (change-release "# We ship a .pc file but don't want t…" …) > >> In unknown file: > >>0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …) > >> > >> ERROR: In procedure make-regexp: > >> Wrong type (expecting exact integer): " > >> > >> " > >> > >> While this is probably not considered an error, I guess it might be > better > >> to ellipsize strings in errors such is mine that are over a certain > length > >> long. The important part of the backtrace was scrolled away and I got > >> confused about the string, as I thought it was part of the output and > >> started wondering why (display ...) keeps the escaped newlines in the > >> string. > > > > Some want it, some want it not. I remember a couple of discussions > > in guile-user and guile-devel about this topic. > > > > Have you tried setting debug options `width' and/or `depth' (cf. > procedure > > `debug-options')? > > > > (my current defaults are 79 columns/20 rows, this is Guile 3.0). > > The backtrace itself is ellipsized, but the value displayed in the > exception (the long string above) is not. > > I would rather not ellipsize anything in the exception itself. > > Thoughts? > It would be nice if this was configurable. As Tomas pointed out this kind of thing can be a matter of taste. Also, if debugging some specific problem involving large strings it might be convenient to switch on for anyone. There could be a debug-option (see (debug-options '?)) `exception-width' (similar to `width' but for errors and exceptions). But how is the debug-options interface regarded nowadays? Is it going to be deprecated? I notice that the `width' option doesn't seem to have an effect anymore. Looking into backtrace.c and (system repl debug) the width nowadays rather seems to be controlled by the terminal width only. Best regards, Mikael
bug#39573: [3.0.0] Compiler fails to optimize out side-effect-free expression
Den tors 13 feb. 2020 12:37Ludovic Courtès skrev: > Yay! It’s nice to see how 7dc90a17e03045c7cd8894b14b027b845b68aa4f is > short and clear. > > Thanks, > Ludo’. > (You're lucky, Ludo', that we don't take that statement literally. :-)) Thanks! >
bug#37461: define-generic doesn't promote equal? to generic
On Mon, Sep 23, 2019 at 5:01 PM Mikael Djurfeldt wrote: > > (define-method (equal? (a ) (b )) ...) > > on the other hand, means that you want to *extend* the current behavior of > equal? with a specialization to two strings. The method is then added to > equal?, which in guile-1.8 was from scratch a "primitive-generic". > > Actually, this is misguided. I should have examined this problem more carefully, and also read your later emails more carefully. You see, I was under the impression that primitive-generic capability had been removed for equal?. It has not. It's only the printed representation which has changed. Your bug report contains two problems. One concerns why define-generic doesn't create a new generic. I believe this is an intentional or unintentional change at some version. The other problem concerns the dispatch rules for primitive generics. You are right that the dispatch rules are special for primitive generics. The purpose of primitive generics is to get around any performance penalty for standard behavior, so primitive generics first try standard dispatch. Then, if that fails, GOOPS method dispatch is used. The standard behavior of equal? is to simply return #t when applied to a single argument regardless of type. This is the explanation why you get #t for (equal? ). One way to view this is that the dispatch of primitive-generics is partially constrained.
bug#37461: define-generic doesn't promote equal? to generic
Hi Rob, I left GOOPS development at Guile version 1.8. The way this was then intended to work was that (define-generic equal?) means that you want to create a new generic equal?. This discards the old binding for equal?. (define-method (equal? (a ) (b )) ...) on the other hand, means that you want to *extend* the current behavior of equal? with a specialization to two strings. The method is then added to equal?, which in guile-1.8 was from scratch a "primitive-generic". Here's the actual output of guile-1.8: guile> equal? # guile> (use-modules (oop goops)) guile> (define-method (equal? (a ) (b )) (string=? a b)) guile> equal? # guile> (primitive-generic-generic equal?) #< equal? (2)> guile> (define-generic equal?) guile> equal? #< equal? (0)> I don't know if the changes between 1.8 and 2.2.6 is intentional or a bug. Does someone here know? Best regards, Mikael On Sat, Sep 21, 2019 at 7:09 PM Rob Browning wrote: > Rob Browning writes: > > > A re-export doesn't affect the module using the re-exporter, and export > > and replace both fail with "Unbound variable: equal?", even though > > there's a (define equal? ...) in the module. > > Perhaps there was something else going on, but now :replace does appear > to work, e.g. if I define a completely new generic and then > > (define equal? new-equal) > > a "replace: (equal?)" in the define-module does appear to work when you > use the module. > > Though define-method still ignores attempts to specialize (or change the > specialization) for existing types like , etc. (as mentioned in > my other message). > > Thanks > -- > Rob Browning > rlb @defaultvalue.org and @debian.org > GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A > GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 > > > >
Re: letrec bug
2008/10/28 Bill Schottstaedt <[EMAIL PROTECTED]>: > I believe this shows a bug in letrec: > > guile> (let ((x 1)) (let ((x 32) (y x)) y)) > 1 > guile> (let ((x 1)) (letrec ((x 32) (y x)) y)) > > Backtrace: > In standard input: > 2: 0* (let* ((x 1)) (letrec ((x 32) (y x)) y)) > 2: 1 (letrec ((x 32) (y x)) y) > > standard input:2:14: In expression (letrec (# #) y): > standard input:2:14: Variable used before given a value: x > ABORT: (unbound-variable) Nope. >From R5RS: "One restriction on `letrec' is very important: it must be possible to evaluate each without assigning or referring to the value of any ."
Re: letrec bug
2008/10/28 Mikael Djurfeldt <[EMAIL PROTECTED]>: > 2008/10/28 Bill Schottstaedt <[EMAIL PROTECTED]>: >> I believe this shows a bug in letrec: >> >> guile> (let ((x 1)) (let ((x 32) (y x)) y)) >> 1 >> guile> (let ((x 1)) (letrec ((x 32) (y x)) y)) >> >> Backtrace: >> In standard input: >> 2: 0* (let* ((x 1)) (letrec ((x 32) (y x)) y)) >> 2: 1 (letrec ((x 32) (y x)) y) >> >> standard input:2:14: In expression (letrec (# #) y): >> standard input:2:14: Variable used before given a value: x >> ABORT: (unbound-variable) > > Nope. > > From R5RS: > > "One restriction on `letrec' is very important: it must be possible > to evaluate each without assigning or referring to the > value of any ." Sorry. I missed the surrounding let. Yes, it is a bug.
Re: letrec bug
2008/10/28 Mikael Djurfeldt <[EMAIL PROTECTED]>: > 2008/10/28 Mikael Djurfeldt <[EMAIL PROTECTED]>: >> 2008/10/28 Bill Schottstaedt <[EMAIL PROTECTED]>: >>> I believe this shows a bug in letrec: >>> >>> guile> (let ((x 1)) (let ((x 32) (y x)) y)) >>> 1 >>> guile> (let ((x 1)) (letrec ((x 32) (y x)) y)) >>> >>> Backtrace: >>> In standard input: >>> 2: 0* (let* ((x 1)) (letrec ((x 32) (y x)) y)) >>> 2: 1 (letrec ((x 32) (y x)) y) >>> >>> standard input:2:14: In expression (letrec (# #) y): >>> standard input:2:14: Variable used before given a value: x >>> ABORT: (unbound-variable) >> >> Nope. >> >> From R5RS: >> >> "One restriction on `letrec' is very important: it must be possible >> to evaluate each without assigning or referring to the >> value of any ." > > Sorry. I missed the surrounding let. Yes, it is a bug. Sorry again (should never easily throw out comments when its about letrec :). The binding of x which letrec introduces covers the entire letrec expression. This means that it *is* an error to refer to it in another init. We should be grateful that Guile detects this, because such code will likely behave in an implementation dependent, and not standard conforming, manner. R5RS again: "The s are bound to fresh locations holding undefined values, the s are evaluated in the resulting environment (in some unspecified order)"
Re: (gcd -2) -> -2
2008/8/12 Neil Jerram <[EMAIL PROTECTED]>: > 2008/8/12 Bill Schottstaedt <[EMAIL PROTECTED]>: >> gcd is supposed to ignore factors of -1. > > According to? (I'm not suggesting that you're wrong. I'd just like > you to be precise about your references.) R5RS: 6.2.5 Numerical operations -- library procedure: gcd n1 ..., -- library procedure: lcm n1 ..., These procedures return the greatest common divisor or least common multiple of their arguments. The result is always non-negative. (gcd 32 -36) ==> 4 (gcd) ==> 0 (lcm 32 -36) ==> 288 (lcm 32.0 -36) ==> 288.0 ; inexact (lcm) ==> 1 >> "<" is restricted to reals -- a complex arg should be an error. > > Again, is that specified? > > Mathematically, I can't help wondering about Lim(x + iy) as y -> 0. > Or, in Scheme terms, about inexact numbers. Does inexactness in > Scheme pertain only to the real dimension? Mathematically, < doesn't have a meaning if its arguments complex, i.e. if y above isn't exactly zero. In Scheme terms, I guess one has to consider a number real if the imaginary part is 0.0 even though it is an inexact real number...
Re: generic * and 0
2006/12/6, Marius Vollmer <[EMAIL PROTECTED]>: Kevin Ryde <[EMAIL PROTECTED]> writes: > The only case I can think of where a common zero may not be good is > with matrices, where "(* 0 matrix) => matrix" could preserve the > dimensions of the input matrix in the output matrix. I would have to dig for the specifics (having forgotton most of my math by now), but 'scaling' matrices and 'multiplying' them are actually two different operations. They certainly are different operations: (C complex space, M space of matrices) 1. Scaling: C x M --> M 2. Matrix multiplikation: M x M --> M They are unfortunately notated the same. That they are notated similarly on paper does not necessarily imply that they should be notated the same way in computer code. (* scalar matrix) is scaling, and (* matrix matrix) is multiplying. A special case of this is the more familiar vector scaling versus the vector dot product, I think. It's actually a third operation: 3. Dot product: V x V --> C (V space of vectors) Thus, it makes sense to me to let the 'unknown' object in a call to an arithmetic operation decide how to interpret it, and not doing any shortcuts. In general, it is not guaranteed that (* 0 something) is even well-defined, it might be an error. Yes. And I think you raise another important point: that one might want to use the same generic function to represent different operators. It is probably Right to make it possible for the primitive generic to dispatch on all arguments (that is skipping the 0 and 1 trick which we have inherited from the original SCM code). However, doing this kind of "improvements" in an incremental manner, given the current structure of the Guile evaluator, makes the thing dog slow. Also, if hanging methods on * implies performance penalty for ordinary arithmetic, it leads to strange practise in structuring code. So I would vote "no" for just "fixing" this, and "yes" for a total restructuring of invocation of primitive procedures so that they would be true generic functions. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: generic * and 0
2006/12/5, SZAVAI Gyula <[EMAIL PROTECTED]>: Kevin Ryde wrote: > "Mikael Djurfeldt" <[EMAIL PROTECTED]> writes: > >> (Not entirely sure that the common zero is a good idea, but I tend >> to think so.) >> > > I suppose it's a question of whether "*" should do that, or leave it > up to the application. > I think there are 3 solution: 1, make * really generic (non-associative, no 0, no 1) In Guile, this might be tricky to do without large damage to performance. 2, make * non-generic This would make it impossible to extend the arithmetic system with matrices etc. 3, document this strange behaviour Absolutely. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: generic * and 0
2006/12/4, Kevin Ryde <[EMAIL PROTECTED]>: While nosing around nearby stuff I noticed (* 0 1.0) => 0 (* 0 1+1i) => 0 but (* 1.0 0) => 0.0 (* 1+1i 0) => 0.0 which seems a bit inconsistent. Indeed. R5RS "Exactness" reads like either exact or inexact is permitted, but I imagine it ought to be the same whichever way around you write the args. I think I'll change the latter two to exact 0. Good idea. Because of paragraph 6.2.2, a program cannot expect to get the result 0.0, and it seems like a strength of the implementation to provide the additional piece of information that the result is indeed *exactly* 0. An added bonus is that it doesn't break the idea to have a common abstract zero for the * operator. (Not entirely sure that the common zero is a good idea, but I tend to think so.) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: generic * and 0
2006/12/1, Kevin Ryde <[EMAIL PROTECTED]>: SZAVAI Gyula <[EMAIL PROTECTED]> writes: > > (use-modules (oop goops)) > (define-class ()) > (define-method (* a (b )) #t) > (* 0 (make )) > ==> 0 Thanks, that's a bug. Are you sure? If you want to use an operator which is common for numbers and :s, why don't you want to use a common zero? If you don't, the behavior of the operator will be inconsistent. If one still don't want 0 as zero (in the abstract sense), maybe one should use another name for the operator, or, tie a different generic to the name "*". M ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Problem with random numbers on the EM64T platform
On 2/18/06, Mikael Djurfeldt <[EMAIL PROTECTED]> wrote: > I've compiled CVS HEAD on the EM64T platform (Xeon processor). > > (random:uniform) gives results outside the intended interval [0,1[. I've now fixed this in CVS HEAD: 2006-02-19 Mikael Djurfeldt <[EMAIL PROTECTED]> * random.c: Test for SCM_HAVE_T_UINT64 instead of SCM_HAVE_T_INT64. (scm_i_uniform32, scm_i_uniform32, scm_i_init_rstate): Use scm_t_uint64 and scm_t_uint32 instead of scm_t_int64 and scm_t_int32. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Problem with random numbers on the EM64T platform
I've compiled CVS HEAD on the EM64T platform (Xeon processor). (random:uniform) gives results outside the intended interval [0,1[. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Anomalous results from is-a? and instance? on current-input-port
On Wed, 16 Feb 2005 06:55:44 -0500, Alan Grover <[EMAIL PROTECTED]> wrote: > It's confusing to have an "object" with class, superclasses, etc., but > not be "an instance". Since "class-of" returns a value (the Goops > class), that implies it is a Goops instance. Well, ideally every item of data would be a true instance, but that is difficult to achieve. Historically, neither Scheme nor Guile was object oriented. GOOPS is an add-on. The reason why all data in Guile has an explicit representation of its type in terms of a class is to enable specialization of generic functions to the data. I think the cost in terms of confusion is payed back by the utility. I know from my own experience that it is extremely limiting not to be able to specialize generic functions to strings, numbers etc. > What would be the predicate for determining that something is an > instance of a class, capable of the introspection procedures, works with > specialization by inheritance, but not a Goops object? I'm not aware of any such object. Objects that can be introspected using GOOPS introspection procedures, such as slot-ref, *are* GOOPS objects. Instance? would be the predicate to use to test for that. The only GOOPS:y thing you can do with an input-port is to ask for its class (which also implies that you can specialize generic functions to that class). The fact that instance? returns #f informs you that it isn't a normal GOOPS object, doesn't have slots etc. M ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Anomalous results from is-a? and instance? on current-input-port
On Tue, 15 Feb 2005 18:39:44 -0500, Alan Grover <[EMAIL PROTECTED]> wrote: > Guile 1.6.4 > Linux 2.6.5-7.145-default #1 Thu Jan 27 09:19:29 UTC 2005 i686 i686 > i386 GNU/Linux > SuSe 9.1 > > Some instance and class introspection procedures give anomalous results. > Specifically, they seem to give false when they shouldn't. > > My results (from code below, just for current-input-port). Note the #f's": > ; from interactive guile > (class #< 8087280> > instance? #f > (is-a? ) #f > class-direct-supers (#< 80872b0> #< > 8084110>) > (is-a? ) #t > > Results are repeatable if tried in the same interactive interpreter, or > run from a script. However, I get the following variations: > > * Run from a script: (is-a? ) #t > * Use my .guile: (is-a? ) #t * instance? should give #f since the port is not a normal GOOPS instance but rather a built-in datatype. * the class-direct-supers list looks OK * (is-a? ) gives the correct value #t The only thing anomalous above is that (is-a? x ) gives #f in the interpreter. I can't repeat that in the development version, so it seems specific to Guile-1.6.4. Can someone else look into that? Thanks, M ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Strange undefined binding bug coupled to module system
On Wed, 22 Dec 2004 16:35:18 +0100, Marius Vollmer <[EMAIL PROTECTED]> wrote: > I have changed module-make-local-var! a bit: > > (define (module-make-local-var! m v) > [...] > (let ((imported-var (module-variable m v)) > (local-var (or (and (module-binder m) > ((module-binder m) m v #t)) > (begin > (let ((answer (make-undefined-variable))) > (module-add! m v answer) > answer) > [...] > > That should do it, or? Well, unfortunately I don't have time to update myself on the module system code well enough to know, but it seems OK. It's a relief that it was much simpler to fix than I anticipated. M ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Strange undefined binding bug coupled to module system
Marius Vollmer <[EMAIL PROTECTED]> writes: > I'd say a good behavior for 'define' then is the following: > > - When the defined name has a local binding, use that binding. > > - When the defined name has an imported binding, look up the value of >that binding and make a new local binding initialized with that >value. > > - When the defined name has no binding, make a new one and initialize >it with #. > > Then the expression is evaluated and the new (or old local) binding > from above is set to the resulting value. > > Ok? Yes, and, in addition, you need to do - Evaluate the body - Set! the binding to the resulting value Most of this is trivial. However, step 2 requires some coding. Let's break down step 2: 2.1 When the defined name has an imported binding 2.2 Look up the value of that binding 2.3 Make a new local binding initialized with that value Steps 2.1 and 2.2 could be done by calling scm_sym2var with definep = #f, but what you would *not* want to do is to call scm_sym2var with definep = #t in step 2.3, because that would result in two traversals of the module tree. What's needed seems to be to factorize scm_sym2var a little. Or, we could switch to the environments.c implementation! :-) M ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Strange undefined binding bug coupled to module system
Marius Vollmer <[EMAIL PROTECTED]> writes: > Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > > > 2004-04-22 Dirk Herrmann <[EMAIL PROTECTED]> > > > > (scm_m_define): Change order to first create binding and > > evaluating the expression afterwards. > > > > While this change works in the R5RS situation without a module system, > > the presence of a module system, with the difference between imported > > and local bindings, introduces complications. > > What would happen if you just revert that change? The change is a bugfix for another bug, so reverting it would swap one bug for another. The bug which Dirk fixed is that Guile previously created the binding after the expression of the define had been evaluated, while R5RS section 5.2.1 specifies that a define is like a set! to an existing binding. Thus, R5RS allows an expression like: (define foo (begin (set! foo 3) (* 5 foo))) Chez Scheme accepts the above expression and Guile does it after Dirk's change. If we reverted the change, Guile would complain that foo is an unbound variable, which is inconsistent with R5RS. M ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Strange undefined binding bug coupled to module system
Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > Loading of the following code: > > foo.scm: > -- > (define-module (foo)) > > (define (encapsulate proc) > (lambda (_) (proc _))) > > (display round) > (newline) > (define round (encapsulate round)) > -- > > Gives (since some change during last spring): > > guile> (load "foo.scm") > # > > Backtrace: > In unknown file: >?: 0* [primitive-load "foo.scm"] > In foo.scm: >8: 1* (define round (encapsulate round)) >8: 2* [encapsulate ... > > foo.scm:8:15: While evaluating arguments to encapsulate in expression (encapsulate > round): > foo.scm:8:15: Unbound variable: round > ABORT: (unbound-variable) OK, I've found the change which causes it: 2004-04-22 Dirk Herrmann <[EMAIL PROTECTED]> (scm_m_define): Change order to first create binding and evaluating the expression afterwards. While this change works in the R5RS situation without a module system, the presence of a module system, with the difference between imported and local bindings, introduces complications. It seems like, in the case where no local binding exists before, that local binding should be created *initialized* to the value of the corresponding imported binding, if that exists. That is not done now, which causes the above described non-intuitive behavior. Since it's not immediately obvious to me how to fix this in a good way, I'll leave that to you guys. But please keep in mind that variable lookup is a substantial part of loading time in Guile. We wouldn't want to make *two* eval closure traversals by invoking scm_sym2var twice (with different value of definep) or something like that. M ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Error executing autogen.sh
Execution of guilw-core/autogen.sh yields: Makefile.am:24: required directory ./libltdl does not exist autoreconf: automake failed with exit status: 1 ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Strange undefined binding bug coupled to module system
Loading of the following code: foo.scm: -- (define-module (foo)) (define (encapsulate proc) (lambda (_) (proc _))) (display round) (newline) (define round (encapsulate round)) -- Gives (since some change during last spring): guile> (load "foo.scm") # Backtrace: In unknown file: ?: 0* [primitive-load "foo.scm"] In foo.scm: 8: 1* (define round (encapsulate round)) 8: 2* [encapsulate ... foo.scm:8:15: While evaluating arguments to encapsulate in expression (encapsulate round): foo.scm:8:15: Unbound variable: round ABORT: (unbound-variable) ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Reader bug in 1.7
Roland Orre <[EMAIL PROTECTED]> writes: > A uniform vector of type double is read as a vector. > > guile-user> (array-prototype #i(1 2 3 4)) > () > guile-user> (array-prototype #s(1 2 3 4)) > 1.0 > > I'm mostly using 1.7 now (I'm in research, not production) but I hadn't > noticed this until now because most often I'm using float vectors. I > found it when testing one of my uniform vector routines. This is most likely caused by using older versions of libguile.h and the other Guile includes when compiling your routines. The mismatch in binary type identifier between object file and Guile library causes the effect above. When I do the above in my 1.7 I, correctly, get: guile> (array-prototype #i(1 2 3 4)) 1/3 guile> (array-prototype #s(1 2 3 4)) 1.0 M ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [PATCH] GOOPS MOP no-method doesn't work
Andreas Rottmann <[EMAIL PROTECTED]> writes: > I noticed that besides that specialization does not work > (see [0], this is apparently related to bugs/goops-apply-generic), the > no-method generic isn't invoked, because the C-based protocol does not > use it at all. Here is an example: Thanks for your patch. However, I think we should deprecate no-method rather than put it in the MOP. It doesn't seem particularly useful to have a function which is called only if you try to invoke a generic which totally lacks methods. I mean---it's such an exotic case. It would be much more useful to have a function which is invoked whenever there aren't any applicable methods for a generic. This is also the choice made in CLOS. M ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Introduction of fractions exposes uniform vector prototype bug
In the silly uniform vector (and array) prototype system, the canonical prototype for uniform double vectors is (according to the entry on uniform arrays in the manual) 1/3. However, since 1/3 is no longer a real, uniform vector creation with this prototype fails... I have no good suggestion for what to do about this, but one thing is certain: We can't suggest people to use 1/3 as prototype for double arrays (at least now without modifying scm_make_uve). Note also, that prototypes like 1.0 menas uniform float array... M (Who leaves this problem for somebody else to fix.) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: procedure-source of procedure-with-setter
Bill Schottstaedt <[EMAIL PROTECTED]> writes: > I think the fact that procedure-source returns a "wrong type error" > if passed a procedure-with-setter is less than ideal: Indeed. * debug.c (scm_procedure_source): Handle all objects for which procedure? is #t. (Thanks to Bill Schottstaedt.) (Fixed in both 1.6 and 1.7.) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: latest cvs and srfi-1 for-each
Kevin Ryde <[EMAIL PROTECTED]> writes: > In the latest cvs built on a recent i386 debian, srfi-1 for-each seems > to have stopped working, * srfi-1.c (srfi1_for_each): Corrected argument checking for the case of two argument lists. (Thanks to Kevin Ryde.) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: weak key hash versus display
Kevin Ryde <[EMAIL PROTECTED]> writes: > In guile 1.6.1 or the cvs on a recent i386 debian, I noticed that > doing a display of a weak key hash table can seemingly prevent a key > from being garbage collected. For instance > > (define h (make-weak-key-hash-table 7)) > > (define k "mykey") > (hash-set! h (string-copy k) 12345) > > (display (hash-ref h k)) (newline) > (display h) (newline) > (gc) > (display (hash-ref h k)) (newline) > > run with "guile -s foo.scm" produces > > 12345 > #wh(() () () () () ((mykey . 12345)) ()) > 12345 > > whereas I might have expected the gc to have collected the entry just > set, making the second hash-ref give #f rather than 12345. This is > what happens if the (display h) is not present. And if you keep (display h) but add (display ), hash-ref will give #f again. The reason is that in order to avoid infinite loops due to circular data-structures print functions need to keep track of printed references. These are stored in a "print-state" attached to the port. After displaying h, the print-state contains the reference to the pair (mykey . 12345) which protects it from GC. We should probably replace this vector with a weak vector, or (perhaps more efficient) clear the references from the vector. > I don't really know if this is a bug, or ignorance on my part, but it > seemed more than a little strange. Well, it's not really a bug. The Guile GC doesn't make any guarantees that objects will get GC:d. For example, if the C stack happens to contain an integer which happens to coincide with a reference on the heap, that object won't get GC:d. A conservative GC only behaves nicely in a statisticial sense. Thanks for your observation. Best regards, Mikael Djurfeldt ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: export in syntax-rules
Kevin Ryde <[EMAIL PROTECTED]> writes: > In guile 1.6.1 on a recent i386 debian, I thought to use "export" > inside a syntax-rules in a module definition, for instance > > (define-module (abc def) > #:use-module (ice-9 syncase)) You might want to use #:use-syntax (ice-9 syncase) here instead, otherwise syntax-case expansion is only invoked when syntax-case macros are called in an s-expression. That disables singleton macros and can cause unexpected errors with regard to scope. > (define-syntax foo > (syntax-rules () > ((foo name) > (export name > > (define x 123) > (foo x) > > But I got an error, > > ERROR: In procedure variable-ref: > ERROR: Wrong type argument in position 1 (expecting variable): #f > > Is this sort of thing meant to work, or have I made some basic error? > > (I was looking to make "-public" versions of some macros. I got the > effect I wanted with a procedure->macro, but just wondered if the > syntax-rules style was valid.) This is caused by a bug in syncase.scm. I've fixed this in CVS 1.7.0 and in the 1.6 branch. 1.6.2 will contain the fix. 2003-01-27 Mikael Djurfeldt <[EMAIL PROTECTED]> * syncase.scm (guile-macro): Strip syntactic information from expression before trying to treat it as a Guile macro call. (Thanks to Kevin Ryde.) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Endless loop in guile 1.6.1 if using macros
Christian Neukirchen <[EMAIL PROTECTED]> writes: > Therefore I think, all macros used by exported guile functions have to > get exported too. That is correct. Finally, that won't be necessary, but currently it is. This has to do with the fact that the original implementation of syntax-case macros which Guile uses is not written for use with a module system. We have in mind to fix it, but it is not fixed yet. > This bug seems to appear in guile 1.6 only, since I talked to the mixp > developer, he uses guile 1.7 and can't reproduce it. I recently got the syncase module to expand Guile macros as well. The effect is that the (ds ...) form in your example is expanded already at the definition of f. So while syncase macros are still not fully integrated with the module system => you *should* always export bindings inserted by the macro as well, it happens to work in 1.7 in this particular case. > If you have patches, could you please CC: them to me? The development source tree of guile-1.7 is publicly available via the Guile homepage. You can use the cvs diff command to obtain patches. Best regards, Mikael D. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [Bug #2110] bug in threading implementation using guile-1.6.1
[EMAIL PROTECTED] writes: > === BUG #2110: LATEST MODIFICATIONS == > http://savannah.gnu.org/bugs/?func=detailbug&bug_id=2110&group_id=39 > > Changes by: Stan Pinte <[EMAIL PROTECTED]> > Date: 2003-Jan-10 13:38 (GMT) > > -- Additional Follow-up Comments > This only seems to happen when I make two calls two (gtk-main), indirectly. > > -> one via the (gtk-ensure-handler) call > -> one afterwards, via the (gtk-main) call. Well, this is not a correct usage pattern. (gtk-ensure-handler) spawns a gtk handler which handles all events of the application. That is, it is an *alternative* to (gtk-main). If your intention with calling gtk-main is to wait for the application to quit, I suggest that you wait on a condition variable instead. Then make sure that it is signalled when the application quits. (But maybe someone else more versed in guile-gtk have a better suggestion.) If I do what you describe in an interactive guile session, I get a lot of glib warning messages which are properly informative: g_main_iterate(): main loop already active in another thread It would of course be nicer not to get stuck in a loop but just get *one* error message... Best regards, Mikael Djurfeldt ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Can't build current CVS snapshot!
I have a very strange build problem with the current CVS snapshot. goops.info refuses to build because makeinfo can't find the @image hierarchy.txt (see compile log below). It seem to me like makeinfo only looks for the image file in the current directory, which fails if we have a separate build tree... I would have expected makeinfo to look for it in its include path, but separate tests indicate that it doesn't (makeinfo bug?). Presumably we need to run makeinfo in the source tree instead of the build tree... make[2]: Entering directory `/usr/local/guile/obj/sys-guile-core/doc/goops' /bin/sh /usr/local/guile/guile-core-new/missing --run makeinfo -I ../../../../guile-core-new/doc/goops \ -o goops.info `test -f '../../../../guile-core-new/doc/goops/goops.texi' || echo '../../../../guile-core-new/doc/goops/'`../../../../guile-core-new/doc/goops/goops.texi ../../../../guile-core-new/doc/goops/goops.texi:2660: warning: unlikely character ( in @var. ../../../../guile-core-new/doc/goops/goops.texi:2660: warning: unlikely character ) in @var. ../../../../guile-core-new/doc/goops/goops.texi:2660: warning: unlikely character ( in @var. ../../../../guile-core-new/doc/goops/goops.texi:2660: warning: unlikely character ) in @var. ../../../../guile-core-new/doc/goops/goops.texi:2691: warning: unlikely character ( in @var. ../../../../guile-core-new/doc/goops/goops.texi:2691: warning: unlikely character ) in @var. ../../../../guile-core-new/doc/goops/goops.texi:2691: warning: unlikely character ( in @var. ../../../../guile-core-new/doc/goops/goops.texi:2691: warning: unlikely character ) in @var. ../../../../guile-core-new/doc/goops/goops-tutorial.texi:183: @image file `hierarchy.txt' (for text) unreadable: No such file or directory. makeinfo: Removing output file `goops.info' due to errors; use --force to preserve. make[2]: *** [goops.info] Error 1 make[2]: Leaving directory `/usr/local/guile/obj/sys-guile-core/doc/goops' ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Threads
Neil Jerram <[EMAIL PROTECTED]> writes: > > "Gary" == Gary Houston <[EMAIL PROTECTED]> writes: > > >> Date: Mon, 1 Oct 2001 01:02:30 -0700 From: Thien-Thi Nguyen > >> <[EMAIL PROTECTED]> > >> > >> From: Gary Houston <[EMAIL PROTECTED]> Date: 29 Sep 2001 > >> 21:13:35 - > >> > >> It seems to work OK in Guile 1.3.4. > >> > >> data point: works w/ 1.5.2 (i686-pc-linux-gnu). > > Gary> I get the same behaviour with 1.4 and 1.7 CVS: > > Gary> Run the script once and it works. Run it again and it locks > Gary> up. Reboot and repeat... > > Sounds like a 1.6 ship-stopping bug to me. Does anyone disagree? Me! 'Cause I just fixed it. :) Mikael ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: doc/version-tutorial.texi
Rob Browning <[EMAIL PROTECTED]> writes: > > I believe there are two options: > > > > - Only include a versioning file in one of the Texinfo manuals. In > > this case, I'd choose the reference manual. > > > > - Move each Texinfo manual into its own subdirectory. > > > > I'd rather not do the second when we're already in the middle of a > > stable release. What do you think? > > Another option might be to see if we can come up with a rule or rules > in the Makefile.am that would temporarily provide the missing one(s). > > I'm happy with any of these solutions. As long as the subdir approach > doesn't involve too many changes, other than the move itself and a > little bit of automakery, I'm even OK with that approach if it's the > right solution. Since the current tools assume one manual per directory I'd suggest we split the various documents into subdirectories (i.e. Neils second alternative). This also has the advantage to clean up the doc directory, which currently contains a mix of a lot of stuff. I've been away from Guile for some time now (nice work has been done during that time---thanks everybody!), but I guess I still have the authority to give you a "go" to perform this change, and if Rob is willing to include the change in the 1.5 branch, that seems good too. Best regards, /mdj ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Vectors should not evaluate to themselves
Martin Grabmueller <[EMAIL PROTECTED]> writes: > according to R5RS, literally entered vectors do not evaluate to > themselves and must always be quoted. Guile does not detect this > error: > > guile> #(as) > #(as) > > Should this be fixed, and can it be fixed easily? It should be fixed and it is easy to fix. We only need to remove a case in a switch at the top of the evaluator. Best, Mikael ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: bad binding in guile-config.in (related to duplicate binding in let*)
Bill Schottstaedt <[EMAIL PROTECTED]> writes: > I think the current CVS Guile guile-config.in has not been > reverted to a working version -- it now gets "bad binding" > >From the let that was originally a let*; apologies if > this is incorrect -- we're having disk troubles here > and I may have a messed up copy. You're right. Fixed now. Thanks! ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: duplicate bindings in let*
Martin Grabmueller <[EMAIL PROTECTED]> writes: > Wow, the second report on this within 20 minutes ;-) > > > /home/bil/cl/ ../test/bin/guile-config --version > > guile-config - Guile version 1.4.1 > > /home/bil/cl/ ../test/bin/guile-config link > > ERROR: In procedure let*: > > ERROR: duplicate bindings > > > > perhaps caused by the two "flags" in build-link? > > Correct, but the bug is not in let*, but in guile-config. Recently, > let* was changed to detect this error. > > I have committed a fix to guile-config.in to CVS. (Actually, the bug is in let*, not in guile-config. I have comitted a fix to eval.c to CVS. :) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Reference manual bug
The node "C Port Interface" in the reference manual contains the following paragraph: Port basics --- There are two main data structures. A port type object (ptob) is of type `scm_ptob_descriptor'. A port instance is of type `scm_port'. Given an `SCM' variable which points to a port, the corresponding C port object can be obtained using the `SCM_PTAB_ENTRY' macro. The ptob can be obtained by using `SCM_PTOBNUM' to give an index into the `scm_ptobs' global array. I think I can call me a "Guile veteran". However, I have to confess that I hardly understand this text. There are too many concept labels here: "port type object", "ptob", "port type object type", "scm_ptob_descriptor", "port instance", "port instance type", "scm_port", "port" and "port object". It seems like one can use fewer labels. For example, why introduce the notion of a port type object at all? Why not just call it a scm_ptob_descriptor? (Or, maybe we should just rename scm_ptob_decriptor into scm_port_type in the source? If so, we should probably rename scm_ptobs to scm_port_types.) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Doc patches
Marius Vollmer <[EMAIL PROTECTED]> writes: > Martin Grabmueller <[EMAIL PROTECTED]> writes: > > > I have looked through the top-level doc files of guile-core, mainly to > > correct references to CVS repository locations, mailing lists etc., > > and corrected everything I found. > > Thanks! I have applied your patch. > > Mikael, since you know the most about lsh, can you update HACKING to > talk about lsh instead of ssh? Sure, I'll do that. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Problems installing guile
Michele Midrio <[EMAIL PROTECTED]> writes: > gcc -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -g -O2 -Wall > -Wmissing-prototypes -c net_db.c -fPIC -DPIC -o .libs/net_db.lo > net_db.c:85: conflicting types for `inet_aton' > /usr/include/arpa/inet.h:69: previous declaration of `inet_aton' > make[1]: *** [net_db.lo] Error 1 > make[1]: Leaving directory `/home/michele/WORK/MIT/guile-1.4/libguile' > make: *** [all-recursive] Error 1 Please compare the types of arguments between the declaration at line 69 in /usr/include/arpa/inet.h and the declaration at line 85 of guile-1.4/libguile/net_db.c. Adjust the declaration in net_db.c to fit the one in inet.h, and I'm sure Guile will compile for you. We'd also appreciate if you could inform us of how that line 69 in inet.h looks like. Best regards, /mdj ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: goops 0.9.0 patch: scm_shared_array*
Ralf Stephan <[EMAIL PROTECTED]> writes: > abovementioned functions aren't in guile-1.3.4 (distributed with > SuSE Linux 7.0 PPC) but appear again in 1.4, so... But they are provided by libgoopscore if they aren't provided by libguile, so we should not need this patch. However, I assume that you experienced some trouble which led you to write the report. Could you please explain what happened? Best regards, /mdj ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: bug in apply-generic (goops 0.9.0)
"Lars J. Aas" <[EMAIL PROTECTED]> writes:
> What is this all about?
[...]
> (apply-generic generic-method (list 5 "hello"))
>
> [RESULT]
>
> generic-method arguments:
> arg 1: #
> arg 2: 5
> rest : ("hello")
The apply-generic MOP is not completed. Therefore there's no reason
to use apply-generic. Use apply instead.
(I had no idea that apply-generic was bit-rotted to this extent,
though. Thanks for the bug-report.)
/mdj
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: generic methods and trailing arguments
Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > "Lars J. Aas" <[EMAIL PROTECTED]> writes: > > > With Goops' generic methods, it seems like trailing arguments are > > ignored when method arbitration is done. Take for instance this > > example: > > > > (define-method (hello arg) (display "1 arg\n")) > > (define-method (hello arg arg2) (display "2 args\n")) > > > > (hello 1) > > => 1 arg > > (hello 1 2) > > => 2 args > > (hello 1 2 3) > > => 2 args > > > > Is there a way to make the method arbitration more strict? Maybe > > it's a bug? > > It's a bug. The bug should be fixed now in the CVS version of guile-core. If/when I make an independent release of GOOPS, the bugfix will be included there as well. Thanks, Mikael ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: generic methods and trailing arguments
"Lars J. Aas" <[EMAIL PROTECTED]> writes: > With Goops' generic methods, it seems like trailing arguments are > ignored when method arbitration is done. Take for instance this > example: > > (define-method (hello arg) (display "1 arg\n")) > (define-method (hello arg arg2) (display "2 args\n")) > > (hello 1) > => 1 arg > (hello 1 2) > => 2 args > (hello 1 2 3) > => 2 args > > Is there a way to make the method arbitration more strict? Maybe > it's a bug? It's a bug. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: generic methods and trailing arguments
"Lars J. Aas" <[EMAIL PROTECTED]> writes: > With Goops' generic methods, it seems like trailing arguments are > ignored when method arbitration is done. Take for instance this > example: > > (define-method (hello arg) (display "1 arg\n")) > (define-method (hello arg arg2) (display "2 args\n")) > > (hello 1) > => 1 arg > (hello 1 2) > => 2 args > (hello 1 2 3) > => 2 args > > Is there a way to make the method arbitration more strict? Maybe > it's a bug? It's a bug. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Self evaluated `t' in Guile 1.4
Ivan Toshkov <[EMAIL PROTECTED]> writes: > I'm using Guile 1.4 and 1.4.1 on an i386 RedHat Linux 6.2 and here's > what happens: > > $ guile > guile> (version) > "1.4.1" > guile> t > t > > I've tried 1.3, and it's giving me the correct error message. This is not a bug. It's part of some experimental language translation support. If you want a pure R5RS environment, do: (define-module (foo) :pure :use-module (ice-9 r5rs) :export (bar)) ;;; We're pure R5RS below this point! Normally, however, the existince of bindings for `t' and `nil' should not be a problem. Best regards, Mikael D. ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: eq? and friends accept more than two parameters
Dirk Herrmann <[EMAIL PROTECTED]> writes: > If I understand R5RS correctly, then eq?, eqv? and equal? should accept > exactly two parameters. The current CVS guile, however, accepts more > parameters as well. On the one hand, this seems to be a sensible > extension, but it should somehow be possible to be strictly R5RS > compliant. > > Hmmm? You're right that we would need to support both the R5RS primitives and the more generous primitives if we wanted to keep the extra support. However, I don't think multiple parameters of eq? and friends is sufficiently useful to motivate extra support for it. I suggest you just remove this extra functionality. Best regards, Mikael ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: gensym
"Dale P. Smith" <[EMAIL PROTECTED]> writes: > gensym is supposed to be called with a symbol, not a string. It still > fails. I apologize for all of these incomplete fixes. I think I've been trying to do too many things simultaneously lately. What I should have done already from the start is to check with the Common LISP API which has inspired Guile's gensym and gentemp functions. The first arg to these two functions should actually be a string. I hope I've finally fixed this everywhere. Please tell me if not. Thanks, /mdj
Re: still unsolved macro problem
Dirk Herrmann <[EMAIL PROTECTED]> writes: > I remember that the last time this bug was reported, the conclusion was > that this would require changes to psyntax.ss or so. Since I did not > understand anything within the corresponding files, I did not look any > further into it. Thanks for the bug report. Yes, this can be solved by introducing syntax-case macros. I now know a way to integrate old Guile macros and syntax-case macros, the eventual goal is to get rid of the old macros. However, we've also just got the new syntax-case code and need to think a little about how we would like to integrate that with Guile.
Error reporting mechanism segfaults if invoked too early
The error reporting mechanism should not try to use Guile facilities such as the dynwind chain before the Guile library is initialized, because that leads to a segmentation fault. If scm_initialized_p is 0, it should instead just print a message and abort.
Re: bug in scm_misc_error
Dirk Herrmann <[EMAIL PROTECTED]> writes: > I don't understand what you mean here. All that I do is to catch errors > with scm_internal_catch and collect the error flags in a list. Do I have > to fiddle around with stacks when using scm_internal_catch? If so, what > is the purpose of the function scm_internal_stack_catch? While it may > very well be that I miss something here, your suggestion seems like a > workaround for a problem that should be solved in a different way. You're right. Sorry, I'm so busy right now and try to steal time in-between other things, so I've got this bad habit to answer before giving things enough that (for example, I should read the environment proposal before trying to answer your questions ;-). It *is* a problem that the currently saved error stack has side effects on all subsequent error reporting. We need to somehow make sure that this doesn't happen. You're right that you shouldn't need to bother about such side-effects in your example. I'll think about this later.
Re: bug in scm_misc_error
Actually, thinking about it, this is an unintended use of the error reporting mechanism. It's not good to keep the copy of the stack from the last error. While the fix I suggested in the previous message probably should be implemented, you should also clear the stack by setting the the-last-stack fluid (scm_the_last_stack_fluid) to #f.
Re: bug in scm_misc_error
Dirk Herrmann <[EMAIL PROTECTED]> writes:
> scm_misc_error
> (name,
> "Observers of `~A' have signalled the following errors: ~S",
> scm_cons2 (env, ordered_errors, SCM_UNDEFINED));
^
(I assume that should be SCM_EOL.)
> It's almost the way I want it to be, except for the fact, that the `name'
> parameter is completely ignored by scm_misc_error (or, rather, scm_ithrow
> and where that ends). It seems as if the last error on the scheme level
> somehow still influences the generation of the error message.
Here's a piece of backtrace.c:display_error_body:
if (SCM_DEBUGGINGP
&& SCM_STACKP (a->stack)
&& SCM_STACK_LENGTH (a->stack) > 0)
{
current_frame = scm_stack_ref (a->stack, SCM_INUM0);
source = SCM_FRAME_SOURCE (current_frame);
prev_frame = SCM_FRAME_PREV (current_frame);
if (!SCM_MEMOIZEDP (source) && !SCM_FALSEP (prev_frame))
source = SCM_FRAME_SOURCE (prev_frame);
if (SCM_FRAME_PROC_P (current_frame)
&& SCM_EQ_P (scm_procedure_p (SCM_FRAME_PROC (current_frame)), SCM_BOOL_T))
pname = scm_procedure_name (SCM_FRAME_PROC (current_frame));
}
if (!SCM_ROSTRINGP (pname))
pname = a->subr;
^^^
if (SCM_ROSTRINGP (pname) || SCM_MEMOIZEDP (source))
{
display_header (source, a->port);
display_expression (current_frame, pname, source, a->port);
}
display_header (source, a->port);
scm_display_error_message (a->message, a->args, a->port);
The underlined statement lets the information from the last saved
stack (pname) override the name passed in the throw (a->subr) by not
using the latter in case the stack info is valid.
I don't remember why this is so. But probably, the stack frame
information was a lot more reliable at the time when this code was
written.
Maybe the code should be changed so that the name passed by throw
should override the stack frame info.
[I apologize for the shape of the code in stacks.c and backtrace.c.]
Re: format "~A" not tail-recursive with lists and vectors
[EMAIL PROTECTED] (Matthias Köppe) writes: > In Guile 1.4, (format "~A" (make-vector 500 0)) leads to a stack > overflow. The reason is a non-tail-recursive implementation of > format:obj->str in (ice-9 format). Here is a patch that fixes this. * format.scm (format:obj->str): Made tail-recursive. (Thanks to Matthias Köppe.)
Re: Problem with current validate macros
Marius Vollmer <[EMAIL PROTECTED]> writes: > Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > > > If we could, somehow, store the signature with the primitives, and > > look it up at errors, that would be even better. > > Isn't that information contained in the online docs? No, not currently.
Re: Problem with current validate macros
Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > I propose that we let SCM_MAKE_VALIDATE take a fourth argument which > is the expected type in plain English. If we could, somehow, store the signature with the primitives, and look it up at errors, that would be even better.
Problem with current validate macros
Look at the following dialogue: guile> (define x '(1 2 . 3)) guile> (append x x) ERROR: In procedure append in expression (append x x): ERROR: Wrong type argument (expecting NULLP): 3 ABORT: (wrong-type-arg) guile> This error message is confusing. 1. Guile says that I have given the argument 3 to append which isn't true. 2. It is not obvious to the user that "expecting NULLP" means "expecting the empty list". 3. Guile is *not* expecting the empty list as argument. Problem 1 and 3 are due to misuse of an SCM_VALIDATE_XXX macro. Such macros can only be used when the type test is applied directly to the procedure argument. Problem 2 is a problem with the current validate macros that we have to solve. I propose that we let SCM_MAKE_VALIDATE take a fourth argument which is the expected type in plain English. Note that sometimes might want to make several validate macros for the same test: #define SCM_VALIDATE_CONS(pos, scm) \ SCM_MAKE_VALIDATE (pos, scm, CONSP, "pair") #define SCM_SLOPPY_VALIDATE_LIST(pos, scm) \ SCM_MAKE_VALIDATE (pos, scm, CONSP, "list")
Re: How often are continuations created?
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> Keisuke Nishida <[EMAIL PROTECTED]> writes:
>
> > Oh, should it? But Guile does restart it from 0:
> >
> > guile> (define some-cont #f)
> > guile> (define magic-computation
> >(let ((capture #t))
> > (lambda (x)
> >(if capture
> >(begin
> > (set! capture #f)
> > (set! some-cont (call-with-current-continuation id)))
> > guile> (do ((v (make-vector 5 #f))
> > (i 0 (1+ i)))
> > ((= i 5))
> >(vector-set! v i (magic-computation i))
> >(display i))
> > 01234guile> (some-cont #f)
> > 01234guile>
> >
> > Which one is the correct behavior?
>
> Miroslav is right.
> Guile is wrong.
>
> This is a Guile bug.
Here's the Guile do code:
case SCM_BIT8(SCM_IM_DO):
x = SCM_CDR (x);
proc = SCM_CAR (SCM_CDR (x)); /* inits */
t.arg1 = SCM_EOL; /* values */
while (SCM_NIMP (proc))
{
t.arg1 = scm_cons (EVALCAR (proc, env), t.arg1);
proc = SCM_CDR (proc);
}
env = EXTEND_ENV (SCM_CAR (x), t.arg1, env);
x = SCM_CDR (SCM_CDR (x));
while (proc = SCM_CAR (x), SCM_FALSEP (EVALCAR (proc, env)))
{
for (proc = SCM_CADR (x); SCM_NIMP (proc); proc = SCM_CDR (proc))
{
t.arg1 = SCM_CAR (proc); /* body */
SIDEVAL (t.arg1, env);
}
for (t.arg1 = SCM_EOL, proc = SCM_CDDR (x);
SCM_NIMP (proc);
proc = SCM_CDR (proc))
t.arg1 = scm_cons (EVALCAR (proc, env), t.arg1); /* steps */
env = EXTEND_ENV (SCM_CAR (SCM_CAR (env)), t.arg1, SCM_CDR (env));
^
The problem is here: Guile creates a *new* frame instead of mutating
the old, so call/cc will look at the fresh version of the first frame
instead of the *mutated* version of the fresh form.
}
x = SCM_CDR (proc);
if (SCM_NULLP (x))
RETURN (SCM_UNSPECIFIED);
PREP_APPLY (SCM_UNDEFINED, SCM_EOL);
goto begin;
This can be fixed by mutating the frame when updating it.
Re: How often are continuations created?
Keisuke Nishida <[EMAIL PROTECTED]> writes: > Oh, should it? But Guile does restart it from 0: > > guile> (define some-cont #f) > guile> (define magic-computation >(let ((capture #t)) > (lambda (x) >(if capture >(begin > (set! capture #f) > (set! some-cont (call-with-current-continuation id))) > guile> (do ((v (make-vector 5 #f)) > (i 0 (1+ i))) > ((= i 5)) >(vector-set! v i (magic-computation i)) >(display i)) > 01234guile> (some-cont #f) > 01234guile> > > Which one is the correct behavior? Miroslav is right. Guile is wrong. This is a Guile bug. /mdj
Re: How often are continuations created?
Keisuke Nishida <[EMAIL PROTECTED]> writes: > Oh, should it? But Guile does restart it from 0: > > guile> (define some-cont #f) > guile> (define magic-computation >(let ((capture #t)) > (lambda (x) >(if capture >(begin > (set! capture #f) > (set! some-cont (call-with-current-continuation id))) > guile> (do ((v (make-vector 5 #f)) > (i 0 (1+ i))) > ((= i 5)) >(vector-set! v i (magic-computation i)) >(display i)) > 01234guile> (some-cont #f) > 01234guile> > > Which one is the correct behavior? Miroslav is right. Guile is wrong. This is a Guile bug. /mdj
Re: eval 2nd arg in ppsyntax.ss?
Bill Schottstaedt <[EMAIL PROTECTED]> writes: > ERROR: In expression (eval (list noexpand x592)): > ERROR: Wrong number of arguments to # > ABORT: (wrong-number-of-args) [...] > emacs.scm: (not (procedure? (eval symbol) (interaction-environment Thanks, I'll fix this.
Re: set-procedure-property! doesn't do proper type check on first arg
Marius Vollmer <[EMAIL PROTECTED]> writes: > Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > > > set-procedure-property! doesn't do proper type check on first arg > > Incidentally, I'm in favour of unifying object and procedure > properties. I'm in favor of dropping properties altogether. (But maybe we can continue that discussion on the guile list.) [...] > Looking closer into procprops.c, I would say that unifying procedure > and object properties would be an improvement anyway, because we could > remove that scm_stand_in_scm_proc ickyness. Here I really would like to say that I did *not* implement that thing! :) BTW, primitive procedures now *have* a procedure slot. scm_stand_in_scm_proc can be removed any day regardless of unification. > ObBUG: set-procedure-properties! does the same wrong thing. Are you > going to fix it, Mikael? I suggest that the one who fix it first fix it. (I'm not working on it right now, though.) Best, /mdj
guile-doc-snarf
guile-doc-snarf doesn't understand ANSI C string syntax. For example: If a docstring "looks like \"this\"", the backslashes are put verbatim in the .doc-file => gets in verbatim in the docstring system. (Possibly some other component should be adjusted to fix this.)
multistring.el: Doesn't handle delimiters properly
multistring.el gets confused if a docstring contains an odd number of quotes or certain combinations of backslahed citation marks. The bug lies in the C parsing code provided by the cc-mode. Probably, multistring.el should quit using that code.
multistring.el yields an error when first loaded
guile-core/emacs/multistring.el yields an error when first loaded.
set-procedure-property! doesn't do proper type check on first arg
set-procedure-property! doesn't do proper type check on first arg
Re: can't compile goops
Dave Cottingham <[EMAIL PROTECTED]> writes: > Can anyone fill me in about what this type is, where it's supposed > to be defined, and/or what version of goops works with what version > of guile? The latest released version (0.9.0 which you can find at ftp.gnu.org) works with all Guiles except recent CVS Guiles. The CVS GOOPS works with all Guiles starting with 1.3.2.
Real old-timer
I think this must be the survival record for severe Guile bugs. :) This one has been there from the (almost) very beginning when the structs were implemented. The following code segfaults because the vtable gets freed and the freed memory reused before all structs using that vtable have been freed (both calls to `foo' are therefore needed to evoke the bug): -- (define v (make-vtable-vtable "" 0)) (define (foo) (do ((i 0 (+ 1 i)) (ls '() (cons (make-struct v 0) ls))) ((= i 5000) ls))) (foo) (define v (make-vtable-vtable "" 0)) (foo) --
Re: struct bug
Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > (make-struct vtable tail_array_size init) > (make-vtable-vtable user_fields tail_array_size init) Oops. Need to fix these.
Re: struct bug
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> I'll try to get time later today to update the documentation. I'll
> then mail Clark, you, and the list.
OK, here it goes. At least the `make-vtable-vtable' docs is a bit
long for a docstring. Maybe something can be moved to the manual?
I actually found a bug in simple-format which is invoked by the
example in the docstring. For those of you who doesn't update your
CVS Guile every ten minutes, you can replace the call to format with
multiple calls to display.
guile> (help make-struct)
(guile): make-struct
(make-struct vtable tail_array_size init)
Create a new structure.
@var{type} must be a vtable structure (@xref{Vtables}).
@var{tail-elts} must be a non-negative integer. If the layout
specification indicated by @var{type} includes a tail-array,
this is the number of elements allocated to that array.
The @var{init1}, @dots are optional arguments describing how
successive fields of the structure should be initialized. Only fields
with protection 'r' or 'w' can be initialized, except for fields of
type 's', which are automatically initialized to point to the new
structure itself; fields with protection 'o' can not be initialized by
Scheme programs.
If fewer optional arguments than initializable fields are supplied,
fields of type 'p' get default value #f while fields of type 'u' are
initialized to 0.
Structs are currently the basic representation for record-like data
structures in Guile. The plan is to eventually replace them with a
new representation which will at the same time be easier to use and
more powerful.
For more information, see the documentation for @code{make-vtable-vtable}.
[../../../guile-core/libguile/struct.c:379]
guile> (help make-vtable-vtable)
(guile): make-vtable-vtable
(make-vtable-vtable user_fields tail_array_size init)
Return a new, self-describing vtable structure.
@var{user-fields} is a string describing user defined fields of the
vtable beginning at index @code{vtable-offset-user}
(see @code{make-struct-layout}).
@var{tail-size} specifies the size of the tail-array (if any) of
this vtable.
@var{init1}, @dots are the optional initializers for the fields of
the vtable.
Vtables have one initializable system field---the struct printer.
This field comes before the user fields in the initializers passed
to @code{make-vtable-vtable} and @code{make-struct}, and thus works as
a third optional argument to @code{make-vtable-vtable} and a fourth to
@code{make-struct} when creating vtables:
If the value is a procedure, it will be called instead of the standard
printer whenever a struct described by this vtable is printed.
The procedure will be called with arguments STRUCT and PORT.
The structure of a struct is described by a vtable, so the vtable is
in essence the type of the struct. The vtable is itself a struct with
a vtable. This could go on forever if it weren't for the
vtable-vtables which are self-describing vtables, and thus terminates
the chain.
There are several potential ways of using structs, but the standard
one is to use three kinds of structs, together building up a type
sub-system: one vtable-vtable working as the root and one or several
\"types\", each with a set of \"instances\". (The vtable-vtable should be
compared to the class which is a class of itself.)
@example
(define ball-root (make-vtable-vtable \"pr\" 0))
(define (make-ball-type ball-color)
(make-struct ball-root 0
(make-struct-layout \"pw\")
(lambda (ball port)
(format port \"#"
(color ball)
(owner ball)))
ball-color))
(define (color ball) (struct-ref (struct-vtable ball) vtable-offset-user))
(define (owner ball) (struct-ref ball 0))
(define red (make-ball-type 'red))
(define green (make-ball-type 'green))
(define (make-ball type owner) (make-struct type 0 owner))
(define ball (make-ball green 'Nisse))
ball @result{} #
@end example
[../../../guile-core/libguile/struct.c:465]
guile>
Re: struct bug
Clark McGrew <[EMAIL PROTECTED]> writes: > > "Dirk" == Dirk Herrmann <[EMAIL PROTECTED]> writes: > > Dirk> On Fri, 28 Jul 2000, Clark McGrew wrote: > >> I was playing with structs this morning, and I noticed that the > >> documentation example snarfed into struct.doc doesn't work > >> right. > > Dirk> That part of the struct code is a mess: The documentation > Dirk> and implementation both hold inconsistencies. > > Quite! ...except that it is totally wrong. What has happened here is that the documentation has set you on the wrong tracks. I did not write the struct system, and I did not write the documentation, but I can tell you that it works well, is used in Guile at various places, and is the current basis for GOOPS objects.
Re: struct bug
Dirk Herrmann <[EMAIL PROTECTED]> writes: > That part of the struct code is a mess: The documentation and > implementation both hold inconsistencies. [...] It's actually only the documentation which is wrong. Remember that this documentation was written fairly recently, so I think it is forgivable that it contains inconsistencies. > ** There is now a fourth (optional) argument to make-vtable-vtable and >make-struct when constructing new types (vtables). This argument >initializes field vtable-index-printer of the vtable. > > However, this is IMO complete rubbish: How do you distinguish an optional > fourth argument from the other rest arguments ? And, the way the code > works, there is no distinction made. Thus, any first initializer is used > to initialize the printing function slot. In the normal case (I've never seen another case than the normal case so far), a vtable-vtable doesn't contain any further fields, so the printer init arg is last, and may be omitted, like all other init args. Therefore it can be considered optional, even though this should be clarified. If anyone would like to have a new kind of vtable-vtable and therefore adds further fields, they are considered optional as well. It's not uncommon to have several optional fields. I'll try to get time later today to update the documentation. I'll then mail Clark, you, and the list. And, I think there's a risk that Guile gets unnecessary bad PR if we developers go out self-bashing like this. The current struct system is not something we would like to keep, but it is not at all as bad as you try to paint it in your letter.
Re: Bug in assq/v/oc-remove! primitives (with patch)
Marius Vollmer <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: > > > I agree. Would you like a further patch for this, or will you just > > change the 3 "while"s back to "if"s? > > Yep, I'll do the changes myself. The final patch then looks like a > bug fix, where scm_delv_x and scm_delete_x is merely replaced by > scm_delq_x, right? I'm not up-to-date on what you're talking about, but since you mention removing *one* item, it seems like you should use scm_delq1_x instead of scm_delq_x. /mdj
Re: [PATCH] bug in scm_make_struct?
Dirk Herrmann <[EMAIL PROTECTED]> writes: > Since I don't know if the removal of scm_struct_init from struct.h > is considered an API change, I will wait for approval before > applying that patch. I appreciate that. In this case, I don't think scm_struct_init is a meaningful part of the API, and I don't think anyone is using it. Since, in addition, we have a good reason for chaing it, we'll just go ahead and apply your patch. Thanks a lot!
Re: bug in scm_make_struct?
Dirk Herrmann <[EMAIL PROTECTED]> writes: > In scm_make_struct, there is the following initialization sequence: > > SCM_SET_CELL_WORD_1 (handle, data); > SCM_SET_CELL_WORD_0 (handle, (scm_bits_t) SCM_STRUCT_DATA (vtable) + >scm_tc3_cons_gloc); > scm_struct_init (handle, tail_elts, init); > > I. e. the cell type (word 0) is set before the object is initialized. The > initialization is enclosed within SCM_DEFER/ALLOW_INTS, but as I > understand it these are basically no-ops now. Is this a bug and should it > be fixed? It is a bug and should be fixed.
Re: New guile release
Joris van der Hoeven <[EMAIL PROTECTED]> writes: > TeXmacs does not compile correctly anymore with the new Guile release. > Can you tell me which things have changed incompatably? > Another user told me that many other Guile projects did not compile > anymore either with the new distribution. A suggest that you try to > recompile all existing guile projects before launching a new release ; > this would greatly help guile application developers to maintain their > software... Sorry, we can't do that. It would take too much resources from the core developers. What we instead do is announcing on the guile list that a new release is being prepared and asking people to test it. Ideally, the Guile application developers are on the guile list and can test their applications. Unfortunately, we sometimes have to correct earlier bad decisions, thus introducing incompatibilities. When we do this, we try to do it in a well-controlled way: For example. When removing an old function, we 1. mark the function as deprecated in the code and in the NEWS file and tell at both places what to use instead 2. make one Guile release in this state 3. remove the function in next release Sometimes, however, we might have missed proceeding in this way. In any case, once the new reference manual is finished, it will contain a definition of what should be considered Guile's API. We will then make sure that applications can rely on this API for long periods of time.
Re: [PATCH]: Bug with expt
Dirk Herrmann <[EMAIL PROTECTED]> writes: > -> exponent is a negative integer --> result could be a rational if those >were supported. This could be handled nicely: > >cond ((and (integer? z2) (< z2 0)) (/ 1 (integer-expt z1 (- z2 > >Shall I add this special case to expt? Yes. It doesn't make much sense now, but can serve as a reminder. (Actually, it *does* make sense for those trying to plug in a rational module via GOOPS.) > -> exponent is a negative rational --> result will be a real, except for >the rare cases that the square root (or whatever root) can be solved >exactly. I don't know how to handle this nicely. I don't think we should care too much about this one. Best, /mdj
Re: [PATCH]: Bug with expt
Dirk Herrmann <[EMAIL PROTECTED]> writes: > The test for exactness if wrong here: Rationals (if supported) could > fulfill that predicate as well. I will apply the following patch: > > diff -u -r1.208 boot-9.scm > --- boot-9.scm 2000/07/01 17:01:22 1.208 > +++ boot-9.scm 2000/07/12 07:23:07 > @@ -793,7 +793,7 @@ > (define expt >(let ((integer-expt integer-expt)) > (lambda (z1 z2) > - (cond ((exact? z2) > + (cond ((and (integer? z2) (>= z2 0)) > (integer-expt z1 z2)) > ((and (real? z2) (real? z1) (>= z1 0)) > ($expt z1 z2)) Did you check with R5RS that it is OK to return an inexact in the case of exact negative exponent? (I presume it ius.) > > I noticed also that list-tail does no longer accept a second negative > > argument. R5RS say it is an error if the list length is shorter > > than the second argument, but is silent for the negative case. > > But the example implementation given in R5RS relies on the fact that the > parameter is positive or zero. Further, I can not think of any reasonable > behaviour for the case of negative indexes. Thus, IMO it is a bug fix > rather than a bug that negative indexes are not accepted. Indeed.
Re: stack overflow from 'help' and goops
Bill Schottstaedt <[EMAIL PROTECTED]> writes: > > > I think 'help' has trouble with goops entities: > > > guile-oops-0.1.8 is buggy. Please use 0.9.0. > > Humph! I was using 0.9.0: > > /home/bil/test/guile-oops-0.9.0/ ./guile-oops > guile> (use-modules (ice-9 session)) > guile> (use-modules (oop goops)) > guile> (goops-version) > "0.9.0" > guile> (help define-class) > ERROR: Stack overflow > ABORT: (stack-overflow) > > I even watched strace to make sure it's picking up the correct > guile/oop/goops/ files. Sorry, this was not a bug in GOOPS. It was a bug in one of the Guile versions just before the 1.4 release. (The bug could have been discovered and fixed even just after the version number was bumped to 1.4.) What is the origin of your currently running Guile? I'm sorry not to be able to reproduce the bug on my system. If I can't do that, I can't debug it... /mdj
Re: stack overflow from 'help' and goops
Bill Schottstaedt <[EMAIL PROTECTED]> writes: > I think 'help' has trouble with goops entities: > > /home/bil/cl/ guile > guile> (version) > "1.4" > guile> (use-modules (ice-9 session)) > guile> (use-modules (oop goops)) > guile> (help define-class) > ERROR: Stack overflow > ABORT: (stack-overflow) guile-oops-0.1.8 is buggy. Please use 0.9.0.
Re: another nit.
Clark McGrew <[EMAIL PROTECTED]> writes: > Here's a patch so that assq-ref and friends behave like hash-ref. I > just added an optional default argument. This should not break any > existing user code, but does make hash-ref and assq-ref > "interchangable". It does break applications calling scm_assq_ref. We will save your patch for Guile-2.0. Thanks, /mdj
Re: another nit.
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > why do assq-ref and friends return #f when the key is not found, in > stead of #? This makes it kind of hard to distinguish > between an alist not containing KEY and (KEY . #f) Well, that would make it hard to distinguish between an alist not containing KEY and (KEY . #)... Actually, # is not intended to be used this way. The return value of some forms and procedures in R5RS is unspecified. Since all forms and procedures in the evaluator actually do return a value, they return #. I think #f is the proper value to return from assq-ref. This enables you to do things like (and (assq-ref ...) ...).
Re: simple question
[EMAIL PROTECTED] writes: > #!/usr/local/bin/guile \ > -s > !# > (use-modules (ice-9 slib)) > (require 'format) > (format #t "Hello ~a~%" "bill") > > I mean that the format expansion only works in "interactive" > mode. Can I have it working in script mode (or whatever it's > called) too? The problem occurs because, currently, scripts are evaluated in the core module (guile) which provides a simple form of `format'. Normally when you tell Guile to use a module, bindings from that module will shadow bindings imported from (guile). But bindings imported from another module can't shadow bindings within the module your code resides in. There are two Guile bugs here: 1. That scripts are evaluated in the (guile) module is a bug. The question is in which module scripts should be evaluated. I propose `(guile-script)'. `(guile-user)' is a dedicated interactive environment containing bindings for interactive use. 2. The simple format provided by (guile) should be case independent. (format #t "Hello ~A~%" "bill") currently works also for simple format.
Re: Inconsistant Results
Dirk Herrmann <[EMAIL PROTECTED]> writes: > Thus, you see, guile should not have accepted that macro as a parameter > for reduce. However, stupidly, guile accepted it and then 'rewrote' that > function in memory. Thus, (procedure-source reduce) before and after > passing that macro looked different. Yes. However, I don't think we should try to fix this problem in the current system. There are further problems with Guile macros. The problem is not so much in the implementation as in the design of the current Guile macros. The correct solution is to write a new hygienic macro system. We have that in the (ice-9 syncase) module, but it should be rewritten in C (and probably in a different way). Until then, using (define-module (my-module) :use-syntax (ice-9 syncase)) will detect this kind of problems.
Re: guile-1.4pre3: guile-readline configuration fails - wrong permissions
[EMAIL PROTECTED] writes: > guile-readline configuration fails - wrong permissions > > On my system (RedHat 5.2) the configuration step falls over because the > conftest directory in guile-readline has permissions dr-xr-xr-x. At least one > write bit is needed, otherwise the test files cannot be created. > > I suggest changing the permission to 755. Hmm... Isn't this a local problem on your system? I don't think `configure' tries to set any permissions other than +x on config.status.
Re: Bug in ice-9 slib/ice-9 session with Guile-1.4
[EMAIL PROTECTED] (Matthias Köppe) writes: > This is what I typed: > > guile> (use-modules (ice-9 slib)) > guile> (use-modules (ice-9 session)) > guile> (help begin) > ERROR: Stack overflow > ABORT: (stack-overflow) 2000-06-20 Mikael Djurfeldt <[EMAIL PROTECTED]> * session.scm (make-fold-modules): Detect circular references in module graph. (Thanks to Matthias Köppe.)
Re: bugs in guile-1.4pre3 on HP-PA
bernard URBAN <[EMAIL PROTECTED]> writes: > 1) When compiling ltdl.c, the compiler has not options >-Aa -D_HPUX_SOURCE We'll report this as a libtool bug. > 2) The following #ifdef must be added, as by default the HP C compiler >does not recognize long long (for this, you must use -Ae instead > of -Aa). I'll apply this patch. > 3) guile-doc-snarf produces this: (file alist.x) > > scm_make_gsubr (s_ ## scm_acons, 3, 0, 0, (SCM (*)()) scm_acons); x ## y means concatenate the two to xy. This is ANSI C. Doesn't your compiler support this? > 4) In file ice-9/boot-9.scm, the definition > > (define (try-using-sharlib-name libdir libname) > (in-vicinity libdir (string-append libname ".so"))) > > requires that shared objects end with .so, but the dynamic linker of > HP-PA needs .sl. Actually I have an equivalent dynamic linking method > in hobbit, which picks up the correct suffix from the .la files. > (See definition of path-from in hobbit4d/link.scm) > > But this point 4) does not crash the installation. Yes, the entire dynamic linking framework needs some attention until next release. Thanks for your report! /mdj
Re: readline messing with SA_RESTART for SIGWINCH
"Dale P. Smith" <[EMAIL PROTECTED]> writes: > Mikael Djurfeldt wrote: > > If anyone provides the code for rl_pre_input_hook and a test for > > configure (code is sufficient), then I'll include it in the 1.4 > > release. > > Ok, here is a test to see if readline turns off SA_RESTART. Could you please verify if the current CVS snapshot behaves as you want?
Re: readline messing with SA_RESTART for SIGWINCH
"Dale P. Smith" <[EMAIL PROTECTED]> writes: > You can set rl_pre_input_hook to a function that does siginterrupt(SIGWINCH, 0) or >uses sigaction to set SA_RESTART. This provides a fix and lets readline handle >SIGWINCH. If anyone provides the code for rl_pre_input_hook and a test for configure (code is sufficient), then I'll include it in the 1.4 release. However, we're *really* close to release now, so I'd better have it tonight to be able to include it. But it's of course OK to include it later also. /mdj
Re: Bug in goops-snarf.h
Keisuke Nishida <[EMAIL PROTECTED]> writes: > Isn't this a bug of GOOPS? Yeah, it is--sorry. Actually, the entire fdi.c thing was written in a couple of hours in order to show to my boss that such a thing could be done, so that he would start using Guile. :) It's very experimental and we want to design a real C API. BTW, Maurizio Vitale already reported this long ago, but since I'm a lazy bastard, I haven't taken care of that yet...
