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
t
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 c
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:
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 Extensio
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 82aa
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
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/w
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 treatin
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
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!
>
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
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
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
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
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
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
-- libr
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 d
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 questi
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 permi
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,
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 PRO
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
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 wo
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
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)
>
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 ini
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 af
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> Loading of the following code:
>
> foo.scm:
> --
> (define-module (foo))
>
> (define (encapsulate proc)
> (lambda (_) (proc _)))
>
> (displa
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
Loading of the following code:
foo.scm:
--
(define-module (foo))
(define (encapsulate proc)
(lambda (_) (proc _)))
(display round)
(newline)
(define round (encapsulate round))
--
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 b
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 fo
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
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.)
(F
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.)
__
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
e 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
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 macr
read
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
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 t
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 -00
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 th
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
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
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 b
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
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 h
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]:
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 yo
"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 appl
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
"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
"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
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 experi
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 pos
"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 t
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 b
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.
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 funct
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-stac
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 al
[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
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.
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.
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 th
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
> >
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
>
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
>
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.
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&#
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 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.
guile-core/emacs/multistring.el yields an error when first loaded.
set-procedure-property! doesn't do proper type check on first arg
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 re
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
fre
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.
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
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
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
forgi
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_de
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, an
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);
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 s
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.
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
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
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-overfl
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 s
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
conta
[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
> c
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 diffe
[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
[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 PROTECT
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 i
"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
"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
configur
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
1 - 100 of 146 matches
Mail list logo
