Andy Wingo writes:
> I tried reimplementing weak tables using finalizers. (The finalizers
> remove elements from the table). As long as we ensure that the
> guardian's finalizers run first, which is possible for Guile to do, that
> does fix this bug.
>
> However, using finalizers has the downsid
Tobias Brandt writes:
> Applying any of the f/u/s*vector-length functions to
> a bytevector returns the wrong size. Specifically they
> multiply (instead of dividing) the size of the bytevector
> by the size of one element.
>
> scheme@(guile-user)> (use-modules (rnrs bytevectors))
> scheme@(guile
Tobias Brandt writes:
> Guile segfaults when a vector is created with size >= 2^16 = 65535.
> Observe:
>
> scheme@(guile-user)> (define v1 (make-vector 65534))
> scheme@(guile-user)> (define v2 (make-vector 65535))
> Segmentation fault
I cannot reproduce this. Please give us more details. What
Hi Ian,
Ian Price writes:
> From 8a9524014ce85fb34fe5cfd7a2667395ce0cdf5d Mon Sep 17 00:00:00 2001
> From: Ian Price
> Date: Fri, 27 Jan 2012 06:38:09 +
> Subject: [PATCH] Fix flush on soft ports, so that it actually runs.
>
> * libguile/vports.c (sf_flush): Remove conditional testing the
>
Andy Wingo writes:
> On Wed 08 Feb 2012 00:04, l...@gnu.org (Ludovic Courtès) writes:
>
>> scheme@(guile-user)> ,optimize (define (foo) (define bar (@ (chbouib) bar))
>> bar)
>> $11 = (define foo
>> (lambda ()
>> (let ((bar-1510 (if #f #f)))
>> (letrec*
>> ()
>> (begi
And here's the actual patch.
Mark
>From 13668b618c4345d51a5667056d1d515c21a874a9 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Thu, 8 Mar 2012 01:24:25 -0500
Subject: [PATCH] Fix @ and @@ to not capture lexicals; new @@ @@ form for
R6RS libraries
MIME-Version: 1.0
Content-Ty
l...@gnu.org (Ludovic Courtès) writes:
> Ian Price skribis:
>
>>
>> - if (pt->write_pos > pt->write_buf)
>> -{
>> - /* write the byte. */
>> - scm_call_1 (SCM_SIMPLE_VECTOR_REF (stream, 0),
>> - SCM_MAKE_CHAR (*pt->write_buf));
>> - pt->write_pos = pt->write_buf
Stefan Israelsson Tampe writes:
> Hi,
>
>
> I wanted to enter meta data where the symbols are important into a
> syntax object and tried to be smart
> in doing that but stumbled on this because loading (a simplified
> example) the attached file I get an annoying error e.g.
>
> ERROR: bad src
> $7
Kiyoshi KANAZAWA writes:
> I'm trying to install guile-2.0.5 on Solaris 10 x86-64 system.
> I have some problems.
>
> (1) make fails with threads
> make fails with configure CC="gcc -I/usr/local/GNU/include
> -L/usr/local/GNU/lib" --prefix=/usr/local/GNU
> make stops with messages as:
> make[3]:
Kiyoshi KANAZAWA writes:
> Thank you Mark,
> Sending this again with Cc:
>
> (1) Now, make succeeds with threads
> Version of libgc is 7.1, but I found some macro define is required for
> threads on Solaris.
> After re-install gc-7.1 with -DGC_SOLARIS_THREADS or -DGC_THREADS,
> make succeeds.
Th
Kiyoshi KANAZAWA writes:
> I analysed the problems.
> (1) Why can not link libguile-2.0.so.22
> LD_LIBRARY_PATH_64 is not set correctly.
> I changed "LD_LIBRARY_PATH" to "LD_LIBRARY_PATH_64" in all the files
> in guile-2.0.5, and found libguile-2.0.so.22 can be linked.
This is a libtool issue. S
Hi Ludovic,
It appears that 'environ_locale_charset' returns a bad address on
Solaris 10, but only when Guile is compiled with '-m64'. Kiyoshi says
that 5de0053178b4acc793ae62838175e5f3ab56c603 is applied in his tree.
Do you have time to look into this?
Regards,
Mark
Kiyoshi KANAZ
Hi Kiyoshi,
I wrote:
> It appears that 'environ_locale_charset' returns a bad address on
> Solaris 10, but only when Guile is compiled with '-m64'.
Kiyoshi: would you be willing to help investigate further? I would
recommend running the 64-bit version of Guile in a debugger, setting a
breakpoint
l...@gnu.org (Ludovic Courtès) writes:
> It may be that your string ports are created with a non-Unicode-capable
> encoding. Try something like:
>
> (define p
> (with-fluids ((%default-port-encoding "UTF-8"))
> (open-input-string "čtyří")))
IMO, this should not be needed. Port encodi
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>> l...@gnu.org (Ludovic Courtès) writes:
>>> It may be that your string ports are created with a non-Unicode-capable
>>> encoding. Try something like:
>>>
>>> (define p
l...@gnu.org (Ludovic Courtès) writes:
> Klaus Stehle skribis:
>
>> (read-hash-extend #\R read-R)
>
> Unlike previous versions, Guile 2.0 has distinct compilation and
> run-time phases. Here you probably want the reader extension to become
> effective at compile-time (when compiling), and at eval
Klaus Stehle writes:
> On Wed, 11 Apr 2012, Mark H Weaver wrote:
>> l...@gnu.org (Ludovic Courtès) writes:
>> > Klaus Stehle skribis:
>> >
>> >> (read-hash-extend #\R read-R)
>> >
>> > Unlike previous versions, Guile 2.0 has distinct comp
Mark Skilbeck writes:
> Hi, all. I've encountered an issue when compiling from the git
> repo. The relevant output from make follows:
[Guile crashed on its first execution while trying to build docs]
I've spoken with Mark on irc and determined that this was due to
building stable-2.0 within a wor
Thien-Thi Nguyen writes:
>[crash] was due to building stable-2.0 within a working
>directory that had previously built master and not been cleaned
>properly before rebuilding.
>
> What does "cleaned properly" mean?
All I know is that he built and installed the master branch, and then
On 09/11/2012 01:17 PM, LRN wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Any progress on this? I've tried 2.0.6, and it's still a mess.
Compiled with a few hacks (disabled networking and posix, copied
getpid definition to random.c), but it still fails with
Throw to key system-error with
Panicz Maciej Godek writes:
> guile 2.0.5-deb+1-1
> (string-match "[\\[]" "[")
> ===> #("[" (0 . 1))
> (string-match "[\\]]" "]")
> ===> #f
As documented in "Syntax of Regular Expressions" of the Emacs manual
(to which section 6.15 of the Guile manual refers):
To include a `]' in a characte
This is a duplicate of bug #12808, so I'm closing this one.
Mark
Jozef Chraplewski writes:
> I use guile 2.0.6, compiled on macbook pro 7.1 osx 10.8.2
>
> I've compiled guild via home-brew package manager.
Could you please run "make check" in the build directory and show us the
output if any errors are reported?
Thanks!
Mark
Hi Jozef,
Jozef Chraplewski writes:
> It looks that guile returns incorrect results when it works with really big
> numbers.
Please disregard my earlier request. Can you please run the following
code and send us the output?
(let ((modulus (expt 10 10)))
(define (last10 n) (modulo n modu
Hi Jozef,
I guess that on your system, (* 65536 65536) evaluates to 0.
Is that right?
If so, I believe the problem is caused by an aggressive optimization in
recent versions of Clang, which breaks Guile's logic for detecting
overflow when multiplying two fixnums.
Currently, Guile computes kk = x
I wrote:
> I guess that on your system, (* 65536 65536) evaluates to 0.
> Is that right?
I should have mentioned that if you're on a 64-bit system, then it may
instead be the case that (* (expt 2 32) (expt 2 32)) evaluates to 0.
Same bug either way, and the rest of my previous email still applies.
Hi Jozef,
Jozef Chraplewski writes:
> Yes, I use 64-bit machine and (* (expt 2 32) (expt 2 32)) produces 0 (without
> the patch).
>
> I've applied your fix and it works perfectly.
Excellent! Thanks for bringing this problem to our attention,
and for helping us track it down :)
> I suppose tha
s for an unrelated bug that I discovered during
my investigation.
Reviews solicited, otherwise I'll commit these in a week or so.
Mark
>From 2b8587d090d13f044f3cc4d221e832a655dcc1cd Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Wed, 23 Jan 2013 17:27:50 -0500
Subject: [PATCH
Daniel Llorens writes:
> Ok, it seems that this was fixed before I reported it. Close?
I see that ",arg0" was changed to ",(car args)" but you also wrote:
> ,arg0 should be ,(car args)
>
> However, even after fixing this, there are problems with the load path
Can you verify that the "problems
Hi Ludovic,
Thanks for looking into this! I think I understand the problem now.
l...@gnu.org (Ludovic Courtès) writes:
> Consider this example:
>
> #include
>
> int64_t
> test_sum (int8_t a, int64_t b)
> {
> return a + b;
> }
>
> When compiled with GCC 4.6, the assembly is:
>
> test_sum:
> .L
FYI, I've posted about this to the libffi-discuss mailing list.
http://sourceware.org/ml/libffi-discuss/2013/msg00012.html
Mark
Marco Maggi writes:
> #!r6rs
> (import (rnrs))
> (define (alpha)
> (define-syntax define-special
> (syntax-rules ()
> ((_ ?who ?val)
>(define ?who ?val
> (define-special beta #t)
> #f)
> (alpha)
>
> should succeed, but instead it
Hi Peter,
Peter Teeson writes:
> Would you please report this over at LLVM since you did the work to
> discover it.
Okay, I'll take care of it.
I'm also working with the libffi folks to work around this problem in
the interim. The next libffi release (due out fairly soon) will
interface proper
Hi Peter,
Peter Teeson wrote:
> When you think things are ready to test I'll be glad to do so on my
> Mac setup.
I believe that this libffi patch will fix the problem. Would you like
to test it? It would also be helpful if you could run "make check" on
both libffi and Guile and let us know of
Peter Teeson writes:
> …...
> PASS: test-asmobs
> PASS: test-ffi
> PASS: test-list
> ……
> ===
> All 29 tests passed
> ===
Excellent! We can now submit the libffi patch upstream.
Thanks,
Mark
l...@gnu.org (Ludovic Courtès) writes:
> However, it’s fundamentally wrong to rely on eq? to compare numbers. So
> the test case you mention seems buggy, to start with.
Agreed. I removed the buggy test.
Thanks,
Mark
Daniel Hartwig writes:
> * test-suite/tests/00-socket.test:
> * test-suite/tests/alist.test:
> * test-suite/tests/elisp.test:
> * test-suite/tests/encoding-iso88591.test:
> * test-suite/tests/encoding-iso88597.test:
> * test-suite/tests/encoding-utf8.test:
> * test-suite/tests/hash.test:
> * test-
Hi Daniel,
Daniel Hartwig writes:
> * Terminology
>
> The terminology used in latest URI spec. (RFC 3986) is not widely used
> elsewhere. Not by Guile, not by the HTTP spec., or other sources.
> Specifically, it defines these terms:
>
> - URI: scheme rest ... [fragment]
> - Absolute-URI: scheme
Daniel Hartwig writes:
> On 24 February 2013 18:45, Mark H Weaver wrote:
>> I would argue that Absolute-URIs are more often appropriate in typical
>> user code. The reason is that outside of URI-handling libraries, most
>> code that deals with URIs simply use them as unive
Hi Andy,
Andy Wingo writes:
> On Sat 28 Jan 2012 11:21, Mark H Weaver writes:
>
>> The R5RS specifies that if 'char-ready?' returns #t, then the next
>> 'read-char' operation is guaranteed not to hang. This is not currently
>> the case for ports u
Andy Wingo writes:
> On Sun 24 Feb 2013 21:14, Mark H Weaver writes:
>
>> Maybe I'm missing something, but I don't see any semantic problem here,
>> and it seems straightforward to implement. 'char-ready?' should simply
>> read bytes until either a
The current limitation of 10 arguments to foreign functions is proving
to be a problem for some libraries, in particular the Allegro game
library.
Is there a reason why raising this limit to 16 or 20 would be
undesirable? What tradeoffs are involved?
Thanks,
Mark
reopen 13768
thanks
Andy Wingo writes:
> On Wed 20 Feb 2013 00:38, Jan Schukat writes:
>
>> What happens is, in random.c in random_state_of_last_resort on line 668
>> scm_getpid is used to seed the random generator. So either a
>> preprocessor switch or a hand constructed scm like in scm_getpid
Hi Hans. Following up on an old bug report:
Hans Aberg wrote:
> bad return from expression `(f-sum -1 2000 -3 400)': expected
> 3971999; got 3972255
> FAIL: test-ffi
This turns out to be due to a bug in LLVM, namely that it improperly
assumes that signed integer arguments w
Hi Andy,
Andy Wingo writes:
> Our PRNG is not secure. We should not be making arguments from the
> perspective of security. (I think including the PID is a good thing,
> but not because of security.)
Indeed, point well taken.
> Why don't we just add the result of getpid() without relying on t
Andy Wingo writes:
> Are you proposing that `char-ready?' do a nonblocking read if
> the buffer is empty? That could work.
Yes. I suspect that something along these lines is already implemented,
because I don't see how 'u8-ready?' could work properly without it.
> Do what you like to do :) Bu
Hi Andy,
Andy Wingo writes:
> On Mon 25 Feb 2013 01:34, Mark H Weaver writes:
>
>> The current limitation of 10 arguments to foreign functions is proving
>> to be a problem for some libraries, in particular the Allegro game
>> library.
>>
>> Is there a reaso
Ian Price writes:
> After some talk on #guile, Mark and I believe it comes down to the range
> check in INTEGER_ACCESSOR_PROLOGUE in bytevectors.c
Going a bit further: INTEGER_ACCESSOR_PROLOGUE uses 'scm_to_uint', which
I believe should fail for 2^32 on a 32-bit machine. According to
numbers.h:4
Hi Andy,
Andy Wingo writes:
> On Tue 26 Feb 2013 23:40, Mark H Weaver writes:
>
>> I've attached a patch that implements dynamic allocation of objcode
>> stubs for larger arities. What do you think?
>
> LGTM. Please lazily initialize the vector as well.
Okay.
l...@gnu.org (Ludovic Courtès) writes:
> Ian Price skribis:
>
>> Branch: master
>> Commit: 9b977c836bf147d386944c401113aba32776fa68
>> System: 32 bit x86 Fedora 16
>>
>> (use-modules (rnrs bytevectors))
>> (define not-32-bit (expt 2 32))
>> (define bv (make-bytevector 4))
>> (bytevector-u32-set!
David Kastrup writes:
> There is no reason to restrict the type of the second argument to proper
> lists as it is added as last CDR to the list without interpretation.
>
> This allows for stack-depth friendly usage [...]
Looks good to me. Applied, thanks!
Mark
Applied, thanks.
Mark
Andy Wingo writes:
> Looks great, please apply. Thank you!
Pushed. Thanks!
Mark
Fixed in 8dd01861a9a0331b912a1ae6310e64eb6b47c29c.
Thanks!
Mark
I wrote:
> Daniel Hartwig writes:
>> * test-suite/tests/00-socket.test:
>> * test-suite/tests/alist.test:
>> * test-suite/tests/elisp.test:
>> * test-suite/tests/encoding-iso88591.test:
>> * test-suite/tests/encoding-iso88597.test:
>> * test-suite/tests/encoding-utf8.test:
>> * test-suite/tests/h
Daniel Hartwig writes:
> On 18 February 2013 17:16, Ludovic Courtès wrote:
>> Quoth R5RS:
>>
>> `Eq?''s behavior on numbers and characters is
>> implementation-dependent, but it will always return either true or
>> false, and will return true only when `eqv?' would also return
>>
Hi Andy,
Andy Wingo writes:
> A ping on this bug on getting Guile to have the possibility of using an
> embedded copy of mini-gmp.
I'm embarrassed to admit that the integration of mini-gmp into guile has
long been waiting on my pending numerics patches. I'll try to get going
on this (and some o
Andy Wingo writes:
> On Mon 09 Jul 2012 14:29, Ian Price writes:
>
>> If the number contains a division by zero, we get a numerical overflow
>> error.
>>
>> scheme@(guile−user)> (string->number "3/0")
>> ERROR: In procedure string−>number:
>> ERROR: Throw to key `numerical−overflow' with args `(
Hello all,
I wrote:
> I'm embarrassed to admit that the integration of mini-gmp into guile has
> long been waiting on my pending numerics patches. I'll try to get going
> on this (and some other things) for the 2.0.8 release.
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10519#8
I've posted a
Daniel Llorens writes:
> I think this isn't working as it should either.
>
> scheme@(guile-user)> +1i
> $1 = 0.0+1.0i
> scheme@(guile-user)> 1i
> ;;; : warning: possibly unbound variable `#{1i}#'
> ERROR: In procedure #:
> ERROR: In procedure module-lookup: Unbound variable: #{1i}#
No, this is c
Here's a patch to fix these problems. Comments and suggestions welcome.
Mark
>From a1926777b03445d397bb1069b325d243e765f84b Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Wed, 6 Mar 2013 12:52:39 -0500
Subject: [PATCH] Improve standards conformance of string->number.
Hi Peter,
Peter Bex writes:
> On Tue, Mar 05, 2013 at 02:04:55PM -0500, Mark H Weaver wrote:
>> FYI, I produced a simple patch a while back to fix this (see below), but
>> it had an interesting side effect: it caused the reader to read things
>> like "3/0"
I wrote:
> Here's a patch to fix these problems. Comments and suggestions welcome.
I went ahead and pushed this to stable-2.0. I'm closing this bug.
Thanks,
Mark
tags 13905 notabug
close 13905
thanks
Daniel Llorens writes:
> Not necessarily a bug, but I'd like to hear some thoughts on this.
>
> In current Guile
>
> (max -inf.0 9) => 9.0
Yes, and this is correct. In general, the error of an inexact number is
unbounded. Consider the inexact infinities (
Daniel Llorens writes:
> My interest in this is that I don't want
>
> (fold max -inf.0 exact-number-list)
>
> to return an inexact number.
By the way, there's an easy way to accomplish what you want. Simply use
'reduce' (from SRFI-1) instead of 'fold':
(reduce max -inf.0 exact-number-list)
Andy Wingo writes:
> On Wed 13 Mar 2013 14:09, "David A. Wheeler" writes:
>
>> Andy Wingo:
>>
>>> So, we are repeating ourselves here :) I agree with you but I can't see
>>> a good way of implementing this.
>>
>> Would the per-port reader options be reasonable place to store the info
>> about E
Andy Wingo writes:
> On Wed 13 Mar 2013 19:10, Mark H Weaver writes:
>
>> I don't know, it might not be that bad, now that we've agreed on a way
>> to extend the port structure in 2.0. Maybe we could just have a "last
>> peek-char returned EOF" fl
I've pushed 1ea37620c2c1794f7685b312d2530676a078ada7 to stable-2.0,
which fixes our number printer. Closing this bug.
Thanks,
Mark
FYI, I've pushed patches to Guile's git repository (stable-2.0 branch)
which eliminate the known obstacles to mini-gmp integration.
Mark
I wrote:
> I've pushed 1ea37620c2c1794f7685b312d2530676a078ada7 to stable-2.0,
> which fixes our number printer. Closing this bug.
Sorry, I sent this to the wrong bug. Oops :)
Mark
I've pushed 1ea37620c2c1794f7685b312d2530676a078ada7 to stable-2.0,
which fixes our number printer. Closing this bug.
Thanks,
Mark
Consider the following module:
--8<---cut here---start->8---
(define-module (foo)
#:export (foo))
(define-syntax-rule (foo bar)
(begin
(define-syntax-rule (blah x) x)
(define (bar val) (blah val
--8<---cut here---end-
Andy Wingo writes:
> Have you tried master?
I just did, and my toy example works there. Do you think that commit
de41e56492666801078e73860a358e1c63cbc8c2 is the reason?
It would be nice to get this working in stable-2.0 as well, but I guess
that would require working through our disagreement ov
Marijn writes:
> On 22-03-13 13:48, Ludovic Courtès wrote:
>>
>> Thanks for the report. The failure is:
>>
>> FAIL: gc.test: gc: Lexical vars are collectable
>>
>> Unfortunately, this test exercises the garbage collector, and its
>> failure does not always indicate a problem.
>>
>> Since th
Hi John,
johnanth...@lavabit.com writes:
> I grabbed 2.0.7 to see if it was fixed here and it appears to be.
Excellent, thanks for letting us know!
> Apologies if I was re-reporting an existing bug that was both known about
> and fixed.
No need to apologize. Thanks for taking the time to file
Hi Niels,
ni...@lysator.liu.se (Niels Möller) writes:
> For the small integer gcd code, you may want to have a look at the
> tricks used in
> http://gmplib.org:8000/gmp/file/304af17b9ccc/mpn/generic/gcd_1.c, the
> code under GCD_1_METHOD == 2
>
> 1. Shift out the least significant bit of both a an
Nala Ginrut writes:
> But I'm still puzzled with the performance of par-map:
> cut---
> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota
> 1)))
> ;; 0.008019s real time, 0.007979s run time. 0.00s spent in GC.
> scheme@(guile-user
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> It only makes sense to use 'par-map' when the procedure is fairly
>> expensive to compute.
>
> Indeed.
>
>> There is inevitably a lot of overhead in creating and joining t
Mark Sutton writes:
> I can ./configure make make install guile-2.0.7 from source, however,
> when I then try in build guile-clutter or guile-ncurses from source I
> get errors in both. After googling I found that I should have
> ./configure PKG_CONFIG=true.
You shouldn't need PKG_CONFIG=true.
Andy Wingo writes:
> Maybe if it is somehow confined to scm_peek_char and scm_fill_input it
> could be doable.
I think I now see a reasonable way to fix this.
First of all, all interfaces that do something like 'peek' would, when
returning an EOF, set a 'pending_eof' flag in the port structure.
Hi Mark,
In your replies, please keep <14...@debbugs.gnu.org> in the CC line, so
that your emails will be recorded in this bug entry.
Mark Sutton writes:
> On 30/03/13 07:21, Mark H Weaver wrote:
>> Mark Sutton writes:
>>
>>> I can ./configure make make i
Also, what version of g-wrap are you trying to build?
Thanks,
Mark
Hi,
"d.henman" writes:
> I'm not sure if this is a confgure script problem or not. Please take a look
> at the related configure error message.
>
> $ configure
>
>
> checking for LIBFFI... configure: error: Package requirements (libffi) were
> not met:
>
> No package 'libffi' found
>
> C
Cojocaru Alexandru writes:
> what about using the gcd module from gnulib?
> See: https://www.gnu.org/software/gnulib/MODULES.html#module=gcd
That module is under the GPLv3+, and we must keep Guile under LGPLv3+.
Mark
hould add the directory containing `libffi.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libffi' found
>
> I'm looking for information at cygwin and also
> about gettnig the ffi.h file as Mark suggested.
>
>
> Regards
"d.henman" writ
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Cojocaru Alexandru writes:
>>> what about using the gcd module from gnulib?
>>> See: https://www.gnu.org/software/gnulib/MODULES.html#module=gcd
>>
>> That module is under the G
Mark H Weaver writes:
> Andy Wingo writes:
>> Maybe if it is somehow confined to scm_peek_char and scm_fill_input it
>> could be doable.
>
> I think I now see a reasonable way to fix this.
>
> First of all, all interfaces that do something like 'peek'
Ian Price writes:
> Nikita Karetnikov writes:
>
>> The mentioned functions are documented [1]. However, I'll get the
>> "Unbound variable" error if I try to import them:
>>
>> scheme@(guile-user)> ,use (rnrs io ports)
>> scheme@(guile-user)> string->bytevector
>> ;;; : warning: possibly unboun
The prerequisite patches are now in stable-2.0. Here's an updated patch
that applies against current stable-2.0. Otherwise it has not changed.
Mark
>From 7d9ebc691519af7236e1fec8dfefd5fc8784f875 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Sun, 31 Mar 2013 19:06:51 -0400
Hi Andy,
Andy Wingo writes:
> Looks like a good start. Two comments:
>
> On Mon 01 Apr 2013 23:27, Mark H Weaver writes:
>
> 1. I don't much like the addition of this call to this inline function.
> Can we move all the non-fast-path code into some other function? T
Andy Wingo writes:
> Looks great to me. Thanks for following up on this!
Excellent! I pushed this to stable-2.0, so it will be in Guile 2.0.8.
Closing this bug now.
Thanks!
Mark
Nikita Karetnikov writes:
> According to the manual [1], this snippet:
>
> (letrec ((a 42)
> (b (+ a 10)))
> (* a b))
>
> should return "Error: unbound variable: a."
The manual doesn't say anything nearly that specific. It says "Note
that while the init expressions may refer to the n
Nikita Karetnikov writes:
>>> According to the manual [1], this snippet:
>>>
>>> (letrec ((a 42)
>>> (b (+ a 10)))
>>> (* a b))
>>>
>>> should return "Error: unbound variable: a."
>
>> The manual doesn't say anything nearly that specific.
>
> Either you missed it or I misunderstood thi
Nikita Karetnikov writes:
>> I'll fix the manual.
>
> Thanks.
>
> So what's the difference between 'letrec' and 'letrec*', then? I fail
> to grasp it.
The difference is that in 'letrec*', the initializers are guaranteed to
be evaluated in order, and they are allowed to access earlier bindings
b
Touching ports.h fails to rebuild sockets.o and posix.o. Both sockets.c
and posix.c include fports.h, which includes ports.h, so this rebuild
should be automatic.
Andy pointed out that this probably has to do with the special handling
of sockets.c and posix.c:
* Both are conditionally included d
"Jan Schukat" writes:
> Ok, did use this package: guile-2.0.9.2-f480a-dirty.tar.gz and can
> build and run guile-2.0 on mingw when I --disable-posix, which makes
> sense, since Windows is not posix :) Can even use threads.
> I guess I try to get the test-suite to run now.
> I'm pretty happy now th
Nikita Karetnikov writes:
> I think this example [1,2]:
>
> (define-syntax my-or
> (syntax-rules ()
> ((my-or)
> #t)
> ((my-or exp)
> exp)
> ((my-or exp rest ...)
> (let ((t exp))
>(if exp
>exp
>(my-or rest ...))
>
> should look lik
754506...@qq.com writes:
> checking size of char... configure: error: cannot compute sizeof
> (char)
> See `config.log' for more details.
Can you send us the "config.log" file? Please keep
"14...@debbugs.gnu.org" in the CC line.
Out of curiosity, what language is your real name written in? My
Shane Celis writes:
> If a goto label is followed by an SCM variable declaration, a
> compilation error will result. I've written up this piece of code
> that demonstrates the behavior and how to work around it, available
> here:
>
> https://gist.github.com/shanecelis/5728982
In the future, ple
Hi Eric,
"Eric Sheibley" writes:
> Ludo,
> I figured it out but now I am getting another error when running 'make all'
> CCLD guile
> Undefined symbol first referenced in file
> ffi_closure_alloc ./.libs/libguile-2.0.so
> ffi_type_pointer
> ffi_prep_closure_loc
> ffi_typ
1 - 100 of 517 matches
Mail list logo
