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 that 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
r more
so than 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
"fixing" only the titular symptom of the quite larger
underlying set of problems underlying this issue report.
--
David Kastrup
Andy Wingo writes:
> On Thu 23 Jun 2016 18:59, David Kastrup 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
>> which would make sym_big and sym_l
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 writes:
> On Fri 17 Apr 2015 07:17, Mark H Weaver writes:
>
>> David Kastrup writes:
>>
>>> In 2.0.9, the following patch/code for getting what amounts to a binary
>>> string port worked.
>>>
>>> commit 7f7a124d3470b0d566f796
Andy Wingo writes:
> Hi,
>
> On Tue 13 May 2014 12:47, David Kastrup writes:
>
>> The following code results in an error:
>>
>> (use-modules (srfi srfi-1))
>> (reduce-right + 0 (make-list 1 1))
>>
>> Backtrace:
>> In srfi/srfi-1.scm:
>
* libguile/alist.c (scm_sloppy_assv, scm_sloppy_assoc):
Shortcircuit to scm_sloppy_assq where feasible
(scm_assv, scm_assoc): Shortcircuit to scm_assq where feasible
---
libguile/alist.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/libguile/a
> 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
Mark H Weaver writes:
> David Kastrup writes:
>> So you think that it will be more "lightweight" if (values) does not
>> have an immediate representation but rather creates a multiple-values
>> object on the heap?
>
> I don't have time to continue thi
t)))
;; Outputs b 3 but should output b 13
This is using
guile (GNU Guile) 2.0.11
Packaged by Debian (2.0.11-deb+1-1)
--
David Kastrup
7;s also a rather inscrutable error symptom. Any 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
me crash from 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
not automagically switch itself away from the
nominal #f encoding which is not actually present.
Putting (with-fluids ((%default-port-encoding #f)) ...) around the
open-bytevector-input-port call results in the output
#f #t
#xc3
ISO-8859-1 #f
ISO-8859-1 #f
#x9f
ISO-8859-1 #f
which actually corresponds to the documentation.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver 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
Mark H Weaver writes:
> David Kastrup writes:
>
>> In 2.0.9, the following patch/code for getting what amounts to a binary
>> string port worked.
>>
>> commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
>> Author: David Kastrup
>> Date: Sun Sep 21
In 2.0.9, the following patch/code for getting what amounts to a binary
string port worked.
commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
Author: David Kastrup
Date: Sun Sep 21 18:40:06 2014 +0200
Source_file::init_port: Keep GUILEv2 from redecoding string input
diff --git a/lily
positives
when marking.
And we are talking about an advertised GUILE feature after 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
code changes mostly relevant for multithreading These changes
have been suggested by Mark H Weaver in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883#41>
--
David Kastrup
Mark H Weaver writes:
> Hi David,
>
> Thank you for the minimal test case. This is enormously helpful.
>
> David Kastrup writes:
>
>> The symptom likely occurs when an object is collected and consequently
>> its free_smob function gets called.
>
> Afte
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> Three years ago in August there was a meeting of developers at my house,
>> a lot of information was passed around and in a concerted effort
>> LilyPond-2.16.0 was released.
>>
>> Since the
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup 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 jus
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> David Kastrup skribis:
>>>
>>>> This is embarrassing: I used the wrong executable in connection with the
>>>> core d
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup 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
:85
(gdb)
So the core indeed occurs when trying to call scm_gc_mark on a smob no
longer (or not yet?) associated with a valid structure in memory, in a
garbage collection apparently triggered during normal allocation of smob
data.
Sorry for the nonsensical core dump previously.
--
David Kastrup
86-linux-gnu.
The headers are somewhat cooked-down variants (to remove 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
Mark H Weaver writes:
> David Kastrup 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 mista
ing on LilyPond merely
shines a light on it.
So please stop painting this as a request for help. It isn't. It is a
request for change.
The subject line is "string ports should not have an encoding". It
isn't "help, I don't understand string ports".
--
David Kastrup
* 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 be7ecef05c1e
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> David Kastrup skribis:
>>>
>>>>> Line/column info remains identical regardless of the encoding, so I tend
>>>>> to
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup 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 w
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> David Kastrup skribis:
>>>>
>>>> For error messages, yes. For associating a position in a string with a
>>>> previou
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup 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 positio
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver 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 cu
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup 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
nd by hardwired UTF-8 in GUILE-2.2.
But strings are already decoded characters. Reencoding makes 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 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. F
But for me, associating
encodings for connecting strings to ports does not make sense. The
relation is one of characters to characters.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup 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
SCM_SMOB_OBJECT_N_LOC will be supported for several
years? Or is one supposed to use the undocumented SCM_CELL_OBJECT_LOC
instead?
I don't see any _documented_ accessor to SMOB cell locations that would
not be broken in the current source.
This is sort of important.
--
David Kastrup
* libguile/smob.h (SCM_SMOB_OBJECT_LOC, SCM_SMOB_OBJECT_0_LOC)
(SCM_SMOB_OBJECT_1_LOC, SCM_SMOB_OBJECT_2_LOC)
(SCM_SMOB_OBJECT_3_LOC): These elementary API macros have been broken
by commit 56164dc47f6616b359f0ad23be208f01a77b55fa in 2009
Signed-off-by: David Kastrup
---
libguile/smob.h
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
* libguile/smob.h (SCM_SMOB_OBJECT_LOC): This elementary API macro has
been broken by commit 56164dc47f6616b359f0ad23be208f01a77b55fa in 2009
Signed-off-by: David Kastrup
---
libguile/smob.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libguile/smob.h b/libguile/smob.h
Mark H Weaver writes:
> David Kastrup 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.
&g
Nala Ginrut writes:
> I can't reproduce it, but I'm using the latest mater. Could you provide
> your version?
My version is 2.0.9, but more importantly my architecture is 32bit.
Just add enough zeros to move beyond the largest immediate integer, and
you'll likely see the sa
re is no guarantee just
which numbers may be represented by immediate values, there is no
context in which an object property on a number may safely be retrieved.
--
David Kastrup
s may establish
arbitrary relations regarding key uniqueness that have no clear relation
to the object identity used by garbage collection.
--
David Kastrup
about 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
---
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 ffdf276
Mark H Weaver writes:
> David Kastrup writes:
>
>> It is worth pointing out that the current state of Guile is inconsistent
>> regarding the return value of control structures: one primitive control
>> structure builder is call/cc, and its normal use does not return
>
een major releases.
In the current form of the patch, it's surprisingly backwards compatible
but of course one would not call it a mere bug fix.
It will take a number of major releases to get more than step 1 done.
But every journey starts with the first step.
--
David Kastrup
/cc (lambda (exit)
(exit list)
$5 = ()
--
David Kastrup
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 writes:
> David Kastrup 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 "
Mark H Weaver writes:
> David Kastrup 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 end
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.
Signed-off-by: David Kastrup
---
module/ice-9/boot-9.scm | 26 ++
1 file changed, 26 inse
David Kastrup 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 do
Mark H Weaver writes:
> Hi David,
>
> David Kastrup 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.
Mark H Weaver writes:
> David Kastrup 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 &q
* module/srfi/srfi-1.scm (reduce-right): Avoid use of drop-right in
connection with last as a single upfront reverse is more efficient and
simpler to understand.
Signed-off-by: David Kastrup
---
module/srfi/srfi-1.scm | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a
ill happen to accept dotted lists as the shortest list.
Previously, this caused an error late during processing.
Signed-off-by: David Kastrup
---
libguile/srfi-1.c| 28 ++--
module/srfi/srfi-1.scm | 10 +-
test-suite/tests/srfi-1.test |
exceptions
being raised. They rely on length+ returning the length of dotted
lists, behavior that is not specified by the SRFI-1 definition but
available in GUILE.
Signed-off-by: David Kastrup
---
module/srfi/srfi-1.scm | 44
test-suite
g at is that I was going to submit the
following patch as a part of a series fixing other bugs, bugs that I
need a working "get the length of a dotted list" operator for. We don't
have any such operator in GUILE, and that's awkward.
commit 9539272d26f2954a253ed1365a6704ed1
Mark H Weaver writes:
> David Kastrup writes:
>
>> For all the cleverness involved here, one has to run through the whole
>> list anyway. It makes no real sense to do this in this manner. The
>> motivation may be to have a warm cache when k is small, but the res
`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
se of VM stack buildup.
(define (drop-right lis k)
(drop lis (- (length lis) k)))
should be all that is needed.
--
David Kastrup
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> R5RS defines ‘values’ as:
>>>
>>> (define (values . things)
>>>(call-with-current-continuation
>>>
illing in a different unspecified behavior than throwing 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
does the actual work, the
third patch documents the changed semantics.
>From 85917446d03e2562b978575b34c1f3dda105c026 Mon Sep 17 00:00:00 2001
From: David Kastrup
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
* te
)
(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
I think this may be related to issue #17147
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17147> as a problem of
scale for syntax-case or similar mechanisms.
--
David Kastrup
* 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
---
libguile/list.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a
David Kastrup 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.
&g
ver fixing it yourself.
--
David Kastrup
* 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
---
libguile/list.c
Mark H Weaver writes:
> David Kastrup 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
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver 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
nd/or (the form generated by or
actually seems more prone to buildup and churn). But for syntax
replacements in general? Sure. You don't want quadratic behavior in
bare-bones replacements like these.
--
David Kastrup
Mark H Weaver writes:
> severity 17147 wishlist
> thanks
>
> David Kastrup writes:
>
>> The following program goes from 2.3ms execution time to 80s execution
>> time when going from Guile-1.8 to current master.
>>
>> (use-modules (srfi srfi-1
t give a clue as to where Guile-v2 is spending all its time.
--
David Kastrup
al error behavior, it would likely make
sense to move to the somewhat more specific scm_wrong_type_arg_msg,
possibly even for the whole of SCM_VALIDATE_LIST.
Of course all this is water under the drawbridge if not even the
original patch is going anywhere.
--
David Kastrup
umented as being anything here...
--
David Kastrup
le 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
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
---
Formatting changes. Also
those memory accesses should by far dominate the timing. And
with a large list, all of those data accesses need to get their cache
line at a different time.
> On Thu 20 Mar 2014 12:23, David Kastrup writes:
>
>> + /* We did not start with a proper list. Undo the reversal. */
>
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
---
As opposed to the previous patch
want a patch amended accordingly.
--
David Kastrup
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
---
libguile/list.c | 45
:
scheme@(guile-user)> (format #f "~g" (/ 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 next
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)> (symbol->
or use in key-weak hash
tables.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> David Kastrup writes:
>>>
>>>> Mark H Weaver writes:
>>>>
>>>> object identity is checked by eq? and is conceptually different from
>>
Mark H Weaver writes:
> Hi David,
>
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> 'eqv?' is Scheme's fundamental "operational equivalence" predicate.
>>> 'eq?' is just an ugly efficiency hack, a poor cous
ject properties?
object identity is checked by eq? and is conceptually different from
value equality.
When calling a thing an "object property", it is not helpful when it
does not behave like one.
--
David Kastrup
1 - 100 of 115 matches
Mail list logo
