Ludovic Courtès writes:
> Hi,
>
> David Kastrup skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> Thus we could go with the patch below, though I doubt it would make a
>>> measurable difference (and it actually adds tests for other cases).
>&
Ludovic Courtès writes:
> David Kastrup skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hi David,
>>>
>>> David Kastrup skribis:
>>
>> Symbols comparing as _unequal_ have no special path in equal?.
>
> I was going to say th
Ludovic Courtès writes:
> Hi David,
>
> David Kastrup skribis:
>
>> In Scheme, symbols can be compared using eq? for equality. However,
>> since they have garbage-collected content attached, they do not meet the
>> predicate SCM_IMP in the short-circuit ev
ments."
Note that (thunk? (lambda x x)) also returns #t and that ((const 1))
returns 1.
--
David Kastrup
of tests and end up in a general structural comparison
comparing their underlying string names.
This completely sabotages the semantics symbols are intended for.
Behavior for eqv? is similar but the fall-through at least is not as
expensive as it is for equal? .
--
David Kastrup
an the former) but might be less confusing to the human reader.
Or find a better name for SCM_NUMP in the first place.
At any rate, the minimally invasive option would be to restore the
original comment albeit with typographic fixes, namely writing `eq?'
instead of just eq.
--
David Kastrup
this is "fixing" only the titular symptom of the quite larger
underlying set of problems underlying this issue report.
--
David Kastrup
Andy Wingo <wi...@pobox.com> writes:
> On Thu 23 Jun 2016 18:59, David Kastrup <d...@gnu.org> writes:
>
>> I don't see anything protecting sym_big or sym_little (more accurately,
>> 'big or 'little which are non-immediate SCM values) from collection
>> whi
tecting sym_big or sym_little (more accurately,
'big or 'little which are non-immediate SCM values) from collection
which would make sym_big and sym_little useless for comparison.
I'm assuming that not the whole bss segment is getting scanned by
BoehmGC.
--
David Kastrup
Andy Wingo <wi...@pobox.com> writes:
> On Fri 17 Apr 2015 07:17, Mark H Weaver <m...@netris.org> writes:
>
>> David Kastrup <d...@gnu.org> writes:
>>
>>> In 2.0.9, the following patch/code for getting what amounts to a
Andy Wingo <wi...@pobox.com> writes:
> Hi,
>
> On Tue 13 May 2014 12:47, David Kastrup <d...@gnu.org> writes:
>
>> The following code results in an error:
>>
>> (use-modules (srfi srfi-1))
>> (reduce-right + 0 (make-list 1 1))
>>
>>
> I'll make sure this bug is fixed in 2.0.12.
Any perspective on this yet? It's been more than 4 months.
--
David Kastrup
chance wrong-type-arg
can guard against uninitialized/invalid types specifically? There is a
reasonably high chance that bad/uninitialized SCM will wash up there.
The more thorough way would be to check the type tag to be in valid
range before doing any smob callback.
--
David Kastrup
Scheme
rather than C were not successful. That does not necessarily mean much.
It's not hard to guess that this is yet another roadblock on the way to
get LilyPond working with GUILE2.
Any ideas regarding what may be causing this error and how to work
around it?
--
David Kastrup
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
This hack of giving Guile a buffer containing UTF-8, but claiming that
it is Latin-1, is not good. It will cause Guile to see non-ASCII
characters as garbage.
For one thing we
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
In 2.0.9, the following patch/code for getting what amounts to a binary
string port worked.
commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
Author: David Kastrup d...@gnu.org
Date: Sun Sep 21 18:40:06 2014 +0200
In 2.0.9, the following patch/code for getting what amounts to a binary
string port worked.
commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
Author: David Kastrup d...@gnu.org
Date: Sun Sep 21 18:40:06 2014 +0200
Source_file::init_port: Keep GUILEv2 from redecoding string input
diff --git
all. With
regard to making our life easier: it's a sunk cost since all the work
has obviously been done for GUILEv1 already.
--
David Kastrup
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
This is embarrassing: I used the wrong executable in connection with the
core dump. With the matching executable, the coredump makes a lot
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
Shrug. I'll put a link to this bug report to a suitable LilyPond issue.
Thank you. Though I want other LilyPond developers to get involved, and
I’m afraid it would be easy for them to just ignore a side bug report
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
This is embarrassing: I used the wrong executable in connection with the
core dump. With the matching executable, the coredump makes a lot more
sense:
#0 0x in ?? ()
#1 0x0804aee0 in Smob_baseFamily
dependencies on
other parts of LilyPond) of the Smob organizing classes used in
LilyPond. If one wants to compile for Guile v1 for comparison, one
probably needs
typedef void * scm_t_func;
or so somewhere.
guile-bug.tgz
Description: application/gtar-compressed
--
David Kastrup
previously.
--
David Kastrup
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
In Guile 2.0, at the time a string port is opened, the value of the
fluid %default-port-encoding is used for deciding how to encode the
string into a byte stream, [...]
I agree that this was a mistake. The issue
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
For error messages, yes. For associating a position in a string with a
previously parsed closure, no.
But wouldn’t a line/column pair
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
Line/column info remains identical regardless of the encoding, so I tend
to think it’s more robust to use that.
Column info remains identical regardless of the encoding? Since when?
The character on line L
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
Line/column info remains identical regardless of the encoding, so I tend
to think it’s more robust to use that.
Column info remains
* libguile/ports.c (scm_ungetc_unlocked): Fix bad reencoding.
The code
(with-input-from-string
(lambda () (unread-string \ä\ (current-input-port)) (read)))
returns ? instead of ä. This bug was introduced in
commit be7ecef05c1eea66f30360f658c610710c5cb22e
Signed-off-by: David Kastrup d
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
Guile-2.2 does not consult %default-port-encoding but uses UTF-8
consistently (I guess, overriding set-port-encoding! will again change
that).
That still is not satisfactory. For example, using ftell on the input
no sense
and detaches things like ftell and fseek from the actual input into the
port.
--
David Kastrup
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its
own UTF-8 verification, error flagging, processing and indexing.
Do I understand correctly that LilyPond expects Guile strings to be byte
vectors
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
I can take care of doing this myself, and will of course still credit
you in whatever manner you prefer, but I've run into a legal problem: we
don't currently have copyright
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
For error messages, yes. For associating a position in a string with a
previously parsed closure, no.
But wouldn’t a line/column pair be as suitable as a unique identifier as
the position in the file?
As long
to ports does not make sense. The
relation is one of characters to characters.
--
David Kastrup
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
* module/srfi/srfi-1.scm (take-right, drop-right, drop-right!): The
definitions tended to be overly complicate and/or rely on pushing
material on the VM stack, detrimental to scalability for Guile 2.0 and
also
* libguile/smob.h (SCM_SMOB_OBJECT_LOC): This elementary API macro has
been broken by commit 56164dc47f6616b359f0ad23be208f01a77b55fa in 2009
Signed-off-by: David Kastrup d...@gnu.org
---
libguile/smob.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libguile/smob.h b
Any suggestions what non-deprecated alternative should be used instead
of SCM_SMOB_OBJECT_LOC in the year that it will take until this fix is
generally available?
--
David Kastrup
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Three months after its original submission with a working patch series,
this issue is not going anywhere for no discernible reason.
As I've already said, I'm strongly opposed to your patch series.
Rigging the core
at least classifying it correctly as being Patch Available
to make its state more conspicuous?
--
David Kastrup
Numeric values cannot reliably be distinguished using eq? and have no
guaranteed object identity.
Signed-off-by: David Kastrup d...@gnu.org
---
doc/ref/api-utility.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref/api-utility.texi b/doc/ref/api-utility.texi
index
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
Otherwise, this function looks good to me, but I'd prefer to give it a
new name and move it into list.c, rather than extending SRFI-1's
'length+'.
It's not an extension of SRFI-1's length+: it just does the same
(:
ice-9/psyntax.scm:1081:18: Syntax error:
/tmp/bug13.scm:2:0: source expression failed to match any pattern in form
(define (styled-metronome-markup #:optional (glyph-font (quote default)))
(lambda* (event context) What a mess))
--
David Kastrup
David Kastrup d...@gnu.org writes:
Otherwise, this function looks good to me, but I'd prefer to give it a
new name and move it into list.c, rather than extending SRFI-1's
'length+'.
It's not an extension of SRFI-1's length+: it just does the same as
the SRFI-1 reference implementation
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Fixes http://bugs.gnu.org/17147
* module/ice-9/boot-9.scm (and, or): Add syntax rules that only do one
pattern matching operation per and/or rather than per argument.
Thanks, but I ended up simply changing
operator for. We don't
have any such operator in GUILE, and that's awkward.
commit 9539272d26f2954a253ed1365a6704ed197a79be
Author: David Kastrup d...@gnu.org
Date: Mon Jun 2 15:05:55 2014 +0200
Let length+ return the length of dotted lists rather than #f
* libguile/srfi-1.c
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
So the behavior for length+ on a dotted list is strictly unspecified.
It is not even stated it is an error.
Actually, it is. At the end of the section that defines the types
such a clist and flist, it states
Mark H Weaver m...@netris.org writes:
Hi David,
David Kastrup d...@gnu.org writes:
* libguile/srfi-1.c (scm_srfi1_length_plus): Previously, length+
returned #f for dotted lists. This leaves the user with no efficient
means for determining the length of dotted lists. While the Scheme
lis (- (length lis) k)))
should be all that is needed.
--
David Kastrup
to key `vm-error' with args `(vm-run VM: Stack
overflow ())'.
Using guile --no-auto-compile on the same file, I just get
Backtrace:
In ice-9/psyntax.scm:
1259: 19 Aborted (core dumped)
That's the stable version of GUILE included with Ubuntu 14.04.
--
David Kastrup
)
(define-syntax or
(syntax-rules ()
((_) #f)
((_ x ... y) (%cond (x) ... (#t y)
and we have no inherently quadratic behavior here since the rules are
not applied recursively and the ... pattern is just matched once per
construct.
--
David Kastrup
the actual work, the
third patch documents the changed semantics.
From 85917446d03e2562b978575b34c1f3dda105c026 Mon Sep 17 00:00:00 2001
From: David Kastrup d...@gnu.org
Date: Sat, 10 May 2014 16:05:12 +0200
Subject: [PATCH 1/3] Coverage test should not require (if #f #f) to return a
value
* test
an error, but
Guile already fills in a different unspecified behavior than throwing an
error for multiple values.
So this behavior is neither out of line, nor against the standard. It
is merely a more convenient behavior for a situation that the standard
left unspecified.
--
David Kastrup
l...@gnu.org (Ludovic Courtès) writes:
David Kastrup d...@gnu.org skribis:
l...@gnu.org (Ludovic Courtès) writes:
R5RS defines ‘values’ as:
(define (values . things)
(call-with-current-continuation
(lambda (cont) (apply cont things
Thus, a conforming
I think this may be related to issue #17147
URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17147 as a problem of
scale for syntax-case or similar mechanisms.
--
David Kastrup
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
Okay, good point. Indeed, the expansion time of our 'and' and 'or'
macros is quadratic in the number of operands. They are implemented in
boot-9.scm as follows:
(define
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
When running the following program
(define void 6)
(use-modules (ice-9 syncase))
(define-syntax absurd
(lambda (x)
(syntax-case x ()
((_ var) (syntax var)
through Guile 1.8, I get the error
* libguile/list.c (scm_reverse_x): Do not check first argument to
reverse! to be a proper list in advance. This provides the
performance of a version without validation (tests show a speedup by a
factor of 1.8) except for the error case.
Signed-off-by: David Kastrup d...@gnu.org
fixing it yourself.
--
David Kastrup
David Kastrup d...@gnu.org writes:
If Guile is not going to optimize ..., I think it would be good if it
led by example (its sources _are_ going to teach people how to program)
and simply avoided using ... altogether, at the very least where
recursive expansion rules are concerned.
I have
* libguile/list.c (scm_reverse_x): Do not validate first argument to
reverse! in advance. Instead undo reversal in error case.
Signed-off-by: David Kastrup d...@gnu.org
---
libguile/list.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff
...
--
David Kastrup
in an
infinite loop but arrives back at the start when given an eventually or
fully circular list. Because of that, one can save the cost of an
upfront proper list check at the price of having to do a double reversal
in the error case.
Signed-off-by: David Kastrup d...@gnu.org
---
Formatting changes
estimate (rather a factor of 1.88),
probably because I forgot that the CPU does not have to wait for the
write cycle to complete for continuing.
Now that's a somewhat artificial benchmark, but still: almost a factor
of 2 for the operation itself is pretty good.
--
David Kastrup
in an
infinite loop but arrives back at the start when given an eventually or
fully circular list. Because of that, one can save the cost of an
upfront proper list check at the price of having to do a double reversal
in the error case.
Signed-off-by: David Kastrup d...@gnu.org
---
libguile/list.c | 45
.
--
David Kastrup
(/ 1000 3))
$22 = 600.0
scheme@(guile-user) (format #f ~S (/ 1000 3))
$23 = 1000/3
scheme@(guile-user)
--
David Kastrup
--
David Kastrup
---
doc/ref/srfi-modules.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index d97f498..32ff271 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -677,8 +677,8 @@ Maps each seed value to
Symbols printed with `#{...#}' notation need to double backslashes when
displaying as they serve as escape characters when reading. The
behavior before this patch is clearly erroneous:
GNU Guile 2.0.7
[...]
scheme@(guile-user) (string-symbol \\()
$1 = #{\\x28;}#
scheme@(guile-user)
-weak hash
tables.
--
David Kastrup
, it is not helpful when it
does not behave like one.
--
David Kastrup
Mark H Weaver m...@netris.org writes:
Hi David,
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
'eqv?' is Scheme's fundamental operational equivalence predicate.
'eq?' is just an ugly efficiency hack, a poor cousin of 'eqv?' that
fails in surprising ways
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
David Kastrup d...@gnu.org writes:
Mark H Weaver m...@netris.org writes:
object identity is checked by eq? and is conceptually different from
value equality.
The Scheme
distinguishable by eq? (which
means that equal integers might not be eq). So something seems wrong in
that description. Either integer values can _not_ be given properties
reliably, or the above needs to specify distinguishable by `eqv?' or
whatever else may be the underlying reality.
--
David Kastrup
Andy Wingo wi...@pobox.com writes:
On Thu 07 Feb 2013 10:12, David Kastrup d...@gnu.org writes:
Rationale: GUILE already supports a number of escapes not defined in the
Scheme standard. Emacs Lisp modes and derivative modes treat opening
parens in the first column of a file specially
The following code displayed #f:
(define a (make-fluid))
(define b (make-fluid))
(with-fluids ((a 3) (a 1) (b 2))
(display (fluid-ref b)))
In general, removing any duplicate that is not right at the end of the
(remaining) list will exhibit this problem. The fluids and vals
The following code displayed 2:
(define a (make-fluid))
(with-fluids ((a 1) (a 2) (a 3))
(display (fluid-ref a)))
---
libguile/fluids.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libguile/fluids.c b/libguile/fluids.c
index bd59e26..11309c9 100644
---
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 (simplified from an actual
use case that blew up around my ears) like
SCM
my_tree_copy (SCM src)
{
if
/emacs/manual/html_node/emacs/Left-Margin-Paren.html
Being able to escape opening parens makes it possible to write
Emacs-friendly Guile code.
--
David Kastrup
(if not everywhere) among
those links:
URL:http://www.gnu.org/software/guile/manual/html_node/Definition.html#Definition
URL:http://www.gnu.org/software/guile/manual/html_node/Lambda-Alternatives.html#Lambda-Alternatives
--
David Kastrup
) a))
and thence to
(define x (lambda (a) (lambda (b) a)))
And if it is not supposed to be supported, why is it supported with
define-public?
--
David Kastrup
list of
values in an object (Guile itself uses scm_struct_ref (value,SCM_INUM0)).
While there is a macro VALUESP for figuring out whether an SCM is a
values object, it is not documented either.
--
David Kastrup
developer
(David Kastrup, d...@gnu.org) noticed the advertised API and decided to
use it in part of an ongoing clean-up of the Lily parser. Meanwhile I
was working on the Guile V2 migration stuff and it broke.
More concretely regarding the advertised API: the Guilev1.8
documentation does neither
Andy Wingo wi...@pobox.com writes:
Hi David,
This bug was forked from bug 10099, where David has a longer
explanation.
On Fri 25 Nov 2011 11:37, David Kastrup d...@gnu.org writes:
So much for that. The next quote is for a totally different issue, the
availability of local environments
Andy Wingo wi...@pobox.com writes:
I am going to be away from the machine for the weekend, but before I
headed out, I just wanted to put out one idea:
On Fri 25 Nov 2011 14:35, David Kastrup d...@gnu.org writes:
What do you use to parse the lilypond code? What does it parse to?
Classical
Andy Wingo wi...@pobox.com writes:
On Tue 12 Apr 2011 14:00, David Kastrup d...@gnu.org writes:
In the guile manual (listed as
ii guile-1.6-doc
For words that aren't ten years old, try Guile 2.0, which fixes this
issue, among others.
It is the version of guile with the API used
Andy Wingo wi...@pobox.com writes:
On Thu 14 Apr 2011 10:18, David Kastrup d...@gnu.org writes:
Andy Wingo wi...@pobox.com writes:
On Tue 12 Apr 2011 14:00, David Kastrup d...@gnu.org writes:
In the guile manual (listed as
ii guile-1.6-doc
For words that aren't ten years old, try Guile
' is a variant of `reduce'. If LST is `()', RIDENTITY is
returned. Otherwise, `(fold (car LST) (cdr LST))' is returned.
The first and the last sentence look pretty much nonsensical to me.
--
David Kastrup
88 matches
Mail list logo
