t be in /usr/local/share instead?
--
David Kastrup
Ralf Mattes writes:
> On Mon, Nov 13, 2017 at 04:00:11PM +0100, David Kastrup wrote:
>> > So I got me an older version guile-1.7.91 (as I couldn't find any
>> > 1.8, this was the nearest to <1.9.0).
>>
>> 1.8.8 is the latest. Current compilers and T
sion: it may be that joining forces
with him while Guile-2.x remains unsuitable for use with LilyPond is a
good idea.
--
David Kastrup
g
like
(string->symbol "blablaa")
in order to get different addresses: a literal symbol in the code would
be protected.
--
David Kastrup
t decision considerably.
> Sometimes, with scheme, I get the sense that if you haven't read SICP
> you can't understand what the code does: that you can't understand the
> code cause it's well-written.
Well, that does not sound like a good language design goal either.
--
David Kastrup
> lis)
> (else
> (loop (cons (number->string cnt) longer)
> (- cnt 1))
>
> This does indeed spend much less time in GC, but its memory usage is
> still rising rapidly. Did I unknowingly create a memory leak?
>
> Best wishes,
> Arne
--
David Kastrup
ly, although as an application programmer you should be able
> to trust that GC just works.
s/although/because/
--
David Kastrup
.
But the main point of using format (rather than string appends) is to
avoid creating lots of garbage-collected temporary expressions. A
factor of 6 seems to suggest that this expectation is not actually being
accommodated.
--
David Kastrup
efine-method (< (a ) . rest)
(apply string #f
--
David Kastrup
l-eval))
(let ((foo 12)) (local-eval 'foo (the-environment)))
--
David Kastrup
ing that this includes _all_ C++ STL container
classes (like std::vector). If you want to employ them in connection
with Guile2's automatic memory scanning, you need to use them with
custom allocators.
--
David Kastrup
help the data handling speed of any sweeped
garbage-collecting language, and there are numerous of them by now) and
that procedure handling might be made more compatible with it
eventually.
It's probably worth mentioning that "ChickenScheme" does this sort of
garbage-collection on the stack without actually executing function
returns in C.
--
David Kastrup
several active at the same time, making resource management via
dynamic-wind even more tricky.
--
David Kastrup
smobs.cc,
lily/include/smobs.hh, lily/include/smobs.tcc,
lily/include/small-smobs.hh since LilyPond routes all its Scheme-wrapped
data structures through these constructs.
A repository viewer can be found at
<http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=tree>
--
David Kastrup
Mark H Weaver writes:
> I'm sorry David, but _everything_ that you wrote below is incorrect.
Well, let me try again. It's not all that easy to understand.
> David Kastrup writes:
>
>> Chris Marusich writes:
>>
>>> I think I'm missing
ditional values returned by f. If list were a procedure/continuation
accepting multiple values, this would likely work as you expected.
--
David Kastrup
le-value accepting contexts"
is similar to what Lua uses in the context of "..." argument lists.
--
David Kastrup
Andy Wingo writes:
> Hi :)
>
> On Fri 10 Mar 2017 16:31, David Kastrup writes:
>
>> a) Guile already uses two different internal representations: basically
>> UCS-8 and UCS-32. Adding more internal representations could be done
>> using a number of tables indexed
Arne Babenhauserheide writes:
> David Kastrup writes:
>
>> Arne Babenhauserheide writes:
>>> This choice is much, much better than before. The choice before was "I’m
>>> losing Lilypond!" (and not much of a choice).
>>
>> No, the choice was
erpreter to run) and
besides, much of the core functionality is defined using "embedded
Scheme" as well, making it just as crash-prone as user-defined code.
--
David Kastrup
ers and output functions and similar for material somewhat more
performance-critical than what we can reasonably do now.
But at the moment the drawbacks (including performance of interpreted
code) we take in a number of other respects don't make up for those
benefits which are rather marginal given the current code base. Of
course that is partly due to the current code base being fit to the
shortcomings and tradeoffs of Guile 1 specifically.
--
David Kastrup
ot; to "it’s a lot
> slower but it fully works"
AFAIR, either or both of "make doc" and "make check" doesn't work and/or
delivers wrong output.
--
David Kastrup
Arne Babenhauserheide writes:
> David Kastrup writes:
>
>> Arne Babenhauserheide writes:
>>> PS: Just saying "it’s a scripting language now" will not cut it.
>>
>> With an implied "rather than an extension language": that _would_ cut
>&
Matt Wette writes:
>> On Mar 10, 2017, at 7:31 AM, David Kastrup wrote:
>> I've been mulling a bit over enabling UTF-8 as an internal string
>> representation. There are several interesting points to consider:
>
> One point to consider on this topic is th
Andy Wingo writes:
> Hi :)
>
> On Fri 10 Mar 2017 16:31, David Kastrup writes:
>
>> a) Guile already uses two different internal representations: basically
>> UCS-8 and UCS-32. Adding more internal representations could be done
>> using a number of tables indexed
costs.
So it should provide a _large_ opportunity for the sakes of applications
with profiles akin to Emacs or LilyPond.
--
David Kastrup
Arne Babenhauserheide writes:
> David Kastrup writes:
>
>> To a certain degree one can chalk this off as "growing pains" that
>> long-standing users have to shoulder, at least when working with
>> development rather than stable versions.
>
> I’d li
degree than making
Emacs-on-Guile more than an academic option. And make no mistake: there
is quite an overlap in problems that need solving for making
Emacs-Guile2 viable and making LilyPond-Guile2 viable.
But Emacs does not suffer the same amount of migration pressure since
there is no independent Elisp project in different iterations involved.
It can just stick with what works, short of a political decision (like
the one that put MULE into Emacs 20, costly then, amortized by now).
--
David Kastrup
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> I’m sure we already discussed it and then I forgot, but would
>>> anything prevent the use of specific C++ allocators in this case?
>>>
Thien-Thi Nguyen writes:
> () David Kastrup
> () Thu, 09 Mar 2017 00:00:48 +0100
>
>[...] rather than [...] fork Guile 1.8 in order to actually
>have some dependable functionality to base other work on.
>
> I intend to maintain 1.8 for the time being. More precise
> I'm aware noone is interested in developing 1.8.8 further,
There was just a question on the developer list (I think) how to best
maintain a fork of 1.8.
--
David Kastrup
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Andy Wingo skribis:
>>>
>>>> I am not so sure about about this one. I think it's not accurate to
>>>> characteriz
condensed into few C++
classes, so it is comparatively easy to migrate to a different API as
long as it offers comparable functionality.
Which it doesn't (namely the ability of marking objects reached through
STL-managed data structures). So it's pretty pointless to "push users
towards an improved API" and hardly "the right thing".
--
David Kastrup
sion 2.1 or later.
> No idea whether this may have an impact on lilyponds compiling-time
> I'll have to test.)
> lilypond-2.19.56, build from local branch dev/guile-v2.2-work
>
> real67m29.132s
> user93m14.812s
> sys0m7.332s
Same compilation options? This looks like a surprisingly serious
regression compared to 2.0.
--
David Kastrup
a beneficial aspect I liked it.
Everything falls into place once you understand that Scheme does not
offer a programming language as user interface. Instead, you directly
write down the parse trees in Scheme's compact list representation.
That's not exactly readable but makes structure-preservin
Nala Ginrut writes:
> On Fri, Mar 3, 2017 at 5:18 PM, David Kastrup wrote:
>
>> Frankly, I doubt that migration of large Python-based applications is
>> going to be a thing when nobody can even be bothered with immersing
>> himself in the problems with migrating Li
om Python land? Given
> we'll have good JIT compiler in the future.
Frankly, I doubt that migration of large Python-based applications is
going to be a thing when nobody can even be bothered with immersing
himself in the problems with migrating LilyPond from Guile-1.8 to
Guile-2.
--
David Kastrup
(if I am not mistaken) and LilyPond
is cross-compiled for a number of architectures with different byte
orders and type sizes, it seems tricky to get this under wraps.
The next largest performance impact will be redecoding issues.
> Can you run lilypond under callgrind under 1.8 and 2.1.7 and attach the
> generated callgrind.out.PID for each run? Run like this:
>
> valgrind --tool=callgrind --num-callers=20 lilypond foo.ly
>
> Thanks,
>
> Andy
--
David Kastrup
Andy Wingo writes:
> On Mon 27 Feb 2017 10:10, David Kastrup writes:
>
>>> String ports have nothing to do with the discussion AFAIU. (Ports in
>>> Guile are sequences of bytes also. They may be accessed using
>>> textual interfaces as well.
>>
>&
Andy Wingo writes:
> Hello,
>
> I feel the need to correct points in this mail for the benefit of
> guile-user. No reply is needed.
>
> On Wed 15 Feb 2017 00:58, David Kastrup writes:
>
>> Mike Gran writes:
>>
>>> But, for what it is worth, the Lati
a few text editors would throw in the
towel as well. But once you view Emacs as a text processing platform,
it's a reasonable conclusion that failure is not a good option.
For a general-purpose programming language like Python or Guile, I
should think it should be at least as important that strings can
represent input accurately without having to degress outside of string
processing and use stuff like byte arrays.
--
David Kastrup
gt; representation for these raw bytes that would allow lossless
> round-trip, and at the same time avoid the pitfalls some of which were
> mentioned here.
>
--
David Kastrup
s bytes.
Code points are an abstraction while the discussion is about the actual
implementation.
--
David Kastrup
Marko Rauhamaa writes:
> David Kastrup :
>> It's still irrelevant since split does not _use_ the existing file name
>> for constructing new file names.
>
> Split was just an example of a command that concatenates bytes sequences
> to get pathnames, nothing mo
Marko Rauhamaa writes:
> David Kastrup :
>
>> Marko Rauhamaa writes:
>>> You probably cannot produce valid UTF-8 out of invalid UTF-8 snippets
>>> with split(1). However split(1) does form filenames out of its
>>> arguments by concatenation:
>>&g
Marko Rauhamaa writes:
> David Kastrup :
>
>> Marko Rauhamaa writes:
>>> That operation fails if you try to translate the snippets to strings
>>> before concatenation. Such concatenation operations are commonplace
>>> when dealing with filenames (eg, s
th filenames (eg, split(1)).
split(1) does not "deal with filenames" when splitting, but the
individual files may be split inside of UTF-8 sequences. See above.
--
David Kastrup
Marko Rauhamaa writes:
> David Kastrup :
>
>> If you tell Emacs that some external entity is in UTF-8, it will
>> represent all valid UTF-8 sequences as properly decoded characters,
>> and it has special codes for all bytes not part of valid UTF-8.
>>
>> As
decoded characters, and
it has special codes for all bytes not part of valid UTF-8.
As a result, it works with valid UTF-8 perfectly as expected but will
reproduce arbitrary byte streams thrown at it perfectly when decoding as
UTF-8 and then reencoding into UTF-8 again.
Guile is lacking this byte stream reproducibility when
decoding/reencoding. That makes it a whole lot less robust for dealing
with externally provided material.
--
David Kastrup
rimental support has
encoding and stability problems and runs about a factor of 5 slower than
Guile-1). The less one hears of that, the better for morale.
--
David Kastrup
it does not help with narrowing down on
a solution but rather with extending the problem space. It is too
generic to provide guidance and a cohesive framework: if two different
people solve problems using GOOPS, the likelihood that those solutions
can be connected in interface or design better than non-GOOPS solutions
is slim.
--
David Kastrup
storing any
>> 8-bit string of bytes, even if they weren't Latin-1.
>
> Latin-1 has holes in the 0..255 range, so it isn't very appropriate in
> this situation.
What Guile calls "Latin-1" is really unibyte.
--
David Kastrup
Marko Rauhamaa writes:
> David Kastrup :
>
>> Marko Rauhamaa writes:
>>> Guile's mistake was to move to Unicode strings in the operating system
>>> interface.
>>
>> Emacs uses an UTF-8 based encoding internally [...]
>
> C uses 8-bit chara
Eli Zaretskii writes:
>> From: David Kastrup
>> Date: Mon, 30 Jan 2017 19:32:14 +0100
>> Cc: guile-user@gnu.org
>>
>> Emacs uses an UTF-8 based encoding internally: basically, valid UTF-8 is
>> represented as itself, there is a number of coding points beyo
Marko Rauhamaa writes:
> David Kastrup :
>
>> But at any rate, this cannot easily be fixed since Guile uses libraries
>> for encoding/decoding that cannot deal reproducibly with improper byte
>> patterns.
>
> Guile's mistake was to move to Unicode strings
t seems strange that Guile is unable to just pass what it received to
the file open call: if it is in 8bit-mode, this should work, and if it
is in UTF-8 mode (and the error messages suggest that it is), this
should work as well.
--
David Kastrup
Marko Rauhamaa writes:
> David Kastrup :
>
>> Marko Rauhamaa writes:
>>> l...@gnu.org (Ludovic Courtès):
>>>> Guile assumes its command-line arguments are UTF-8-encoded and
>>>> decodes them accordingly.
>>>
>>> I'm afraid that
>
Apparently, Guile can open the file just fine, and it sees the command
line just fine as encoded in utf-8.
But during command line processing rather than afterwards, it fails
opening the file.
So I really, really, really suggest that before people post their
theories that they actually bother cross-checking them with Guile.
--
David Kastrup
apply-smob/1 #]
In ice-9/boot-9.scm:
66: 6 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
432: 5 [eval # #]
In ice-9/boot-9.scm:
2404: 4 [save-module-excursion #]
4056: 3 [#]
1727: 2 [%start-stack load-stack ...]
1732: 1 [#]
In unknown file:
?: 0 [primitive-load "/tmp/f\u266f.scm"]
ERROR: In procedure primitive-load:
ERROR: In procedure open-file: No such file or directory: "/tmp/f\u266f.scm"
dak@lola:/usr/local/tmp/lilypond$ ls -l /tmp/f*.scm
-rw-rw-r-- 1 dak dak 0 Jan 30 16:42 /tmp/f♯.scm
--
David Kastrup
Marko Rauhamaa writes:
> David Kastrup :
>
>> That's more economical than Python's method which uses the encodings
>> of surrogate words not allowed in properly encoded UTF-8, taking
>> 3 bytes rather than the 2 Emacs makes do with. Using high codepoints
>
ve the
Unicode space would even take 4 bytes.
--
David Kastrup
you write down the parse tree and save the computer the
work.
GUILE has tree-il and other representation which are _later_ stages in
the compilation than the "syntax tree" is: see
https://www.gnu.org/software/guile/manual/html_node/Compiler-Tower.html>.
--
David Kastrup
d (test a b c . rest)
(if (null? rest) (test (test a b) c)
(apply test (test (test a b) c) rest)))
(define-method (test (a ) (b )) (string-append a b))
(display (test "a" "b" "c" "d" "e"))
--
David Kastrup
David Kastrup writes:
> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> Artyom Poptsov writes:
>>
>>> Hello Guilers,
>>>
>>> it seems that currently there's no way to 'read' back an
>>> '
at #1 Guile can decide to do something else in
> the future where it currently returns *unspecified*, #2 code has
> clearer semantics, #3 code can be ported more easily to other Scheme
> platforms (say GNU Kawa), and possibly more such benefits.
[...]
> Just my two cents. The maintainers should decide what to do. :-)
Or not.
--
David Kastrup
Chris Vine writes:
> On Wed, 23 Sep 2015 10:54:50 +0200
> David Kastrup wrote:
>> Chris Vine writes:
>>
>> > On Wed, 23 Sep 2015 09:26:27 +0200
>> > David Kastrup wrote:
>> >
>> >> Also, a pointer to an array (rather than someth
Chris Vine writes:
> On Wed, 23 Sep 2015 09:26:27 +0200
> David Kastrup wrote:
>
>> Also, a pointer to an array (rather than something more opaque like
>> SCM) is much more likely to be subject to strength reduction and
>> address arithmetic by the compiler, l
ooping through
some array does not leave a live pointer in registers and stack frame in
a form recognizable by libgc.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> In practice scm_remember_upto_here_* is useless with libgc, since libgc
>>> also tracks pointers in registers.
>>
>> Sounds like a big non-sequitur.
onversion of an SCM
value to some other data depending on it will not protect the SCM value
as such and may lead to collection/finalization of the SCM cell (calling
guardians, removing from weak hashtables and so on).
--
David Kastrup
g files are those created from scratch in the patch (green in
the diffstat).
--
David Kastrup
...) -> (every identity ...
(or ...) -> (any identity ...
(define (list-of-string? lst) (every string? lst))
Of course, this definition returns #t for '() while your definition
returns #f for '(). I'd argue the former is more correct. But of
course you can just write
(define (list-of-string lst) (and (pair? lst) (every string? lst)))
if you want the latter.
--
David Kastrup
Michael Tiedtke writes:
> GNU for me was bit of fascinating self enforcing libertarian ideology
Whatever. This discussion group is about GUILE. If you want to tell
everybody about your discovery of the GNU project and your unique
insights regarding it, try gnu.misc.discuss instead.
--
Da
nux. The GNU project never was about reinventing the wheel when
free alternatives were already available.
--
David Kastrup
Michael Tiedtke writes:
> On 29/06/2015 16:54, David Kastrup wrote:
>> At any rate, it's the license. Abide by it or don't use the software
>> or risk legal action which can be costly.
>
> You all know the concept of mark&sweep. The marking phase it isn'
Michael Tiedtke writes:
> On 29/06/2015 09:55, David Kastrup wrote:
>> Marco Maggi writes:
>>
>>> Michael Tiedtke wrote:
>>>
>>>> Today the first successful clean room build of Viper's System
>>>> Interface (still heavily recogni
. Therefore, Subsection 2d requires that any
application-supplied function or table used by this function must
be optional: if the application does not supply it, the square
root function must still compute square roots.)
--
David Kastrup
that may be, its development certainly seems to have come to a
stop mostly. Certainly no GUILEv2 in sight for it, and that may be
reason for a removal from Jessie just like LilyPond will likely soon be
subjected to.
--
David Kastrup
78 matches
Mail list logo
